首先需要著重指出的一點是，本文所針對的僅是當前最流行的戰爭策略類webgame，對於其它型別webgame並不適用。
事實上，在當前的webgame市場上所充斥的這些戰爭策略遊戲的高度同質化，已經使得我們在很大程度上對於webgame品質的好壞喪失了判斷力。究 竟一款webgame設計成什麼樣子才能夠成功，這個問題是行業內沒有任何乙個人可以回答的了的。在當前以運營和宣傳能力作為評判一款webgame成敗 的標準是一種很可行和可信的方法，但是對於webgame的設計者和開發者（尤其是策劃），這樣的現狀卻是致命的。究竟我們如何去設計一款 webgame，應當遵循什麼樣的設計原則？在找到這個問題的答案前，我們的遊戲設計者被迫處在乙個迷茫期中。事實上，本文無意於去找到這一設計原則，僅 僅是嘗試在開發過程中尋求一些減少和避免設計失誤的方法。
數值設計被認為是戰爭策略類webgame設計中最難的一環，其原因就在於我 們對於數值設計的評價標準知之甚少。從表面上看，webgame的數值設計是存在有很大的隨意性的，尤其是作為webgame核心的各項時間和資源增長速 度的設計，由於它們對於各個玩家來講是公平的，而且相互之間往往很難看出直接的數值關聯，因此很多對此並不精通的遊戲策劃在設計它們時往往過分隨意。而隱 藏在這種隨意背後的，往往就是災難性的遊戲程序。無論是資源生產速度和資源消耗速度的不匹配，遊戲戰略程序和玩家部隊生產速度的不匹配，主城和分城建設因 不同資源和科技起點造成的數值漏洞，都屬於容易帶給玩家很嚴重的遊戲體驗挫折，但並不容易在設計階段快速發現的問題。因此的，在戰爭策略類webgame 的設計開發過程中，我們需要引入設計測試的方法。
傳統的軟體測試和遊戲測試更加偏重的都是程式漏洞（一般稱為bug） 而不是設計漏洞。究其原因，很重要的一點就是測試的測試文件（或稱測試用例）是基於既有的設計文件的，測試的評判標準是實現的程式（遊戲）是否符合既有的 需求文件。但是在這一過程中，設計的錯誤往往被忽略。大量的設計漏洞由於測試不充分而沒有在遊戲開發測試階段被發現，而是被保留到了正式的外部測試階段。 尤其是一些後期的數值型漏洞，往往是在遊戲開始公測甚至於正式運營後才暴露出來的。由於遊戲數值的普遍關聯性，以及玩家角色積累的連續性，在這一階段暴露 出的設計漏洞能否被彌補，彌補需要多少時間都成為了未知數。因此的，在遊戲開發過程中，我們需要針對設計漏洞的測試流程和測試方法。
事 實上，在遊戲行業的開發過程中，針對單一玩法，單一流程的設計測試（或者叫內容測試）是存在的，而且也可以說是比較到位的，但是，戰爭策略類 webgame的特殊性就在於它的設計漏洞往往出現在多個系統，多個玩法，多個流程共同作用的乙個混合的玩家遊戲過程中，而不是存在於某乙個個體中，這樣 的，傳統的基於模組的測試方法在應對戰爭策略類webgame時往往是很不充分的。那麼，webgame測試中還需要什麼樣的測試方法呢？很簡單的，就是 測試者（事實上，這個測試者的角色建議以遊戲策劃而不是專門的遊戲測試人員擔任）以不同的遊戲陣營和遊戲角色加入遊戲，整體體驗遊戲程序，並且記錄各種體 驗性資料（一般為混合性資料，即不存在於遊戲數值策劃文件內的資料，例如玩家主城公升級到x級所需的整體時間，玩家從進入遊戲到開出第一座分城所需要的時間 等）。
我們來看乙個近期比較火熱的戰爭策略類webgame：《熱血三國》中所出現的兩個最為嚴重的，也是遊戲設計者在近期更新中著重解決的兩個設計漏洞：
1.遊戲中後期很容易出現資源堆積現象（尤其是石頭和鐵），繼而頻繁的發生「人禍」。乙個玩家因故兩天不上遊戲就可能導致接近致命的非pvp損失。
2.玩家頻繁刷十級npc城快速提公升聲望。
我們會注意到，以上的設計漏洞恰恰反映了兩種最常見的容易在設計開發測試流程中被忽略的漏洞：一是多個混合系統長時間作用所發生的混合效應（漏洞一反映 了資源生產，資源儲存，資源消耗和人禍系統四個系統共同作用過程中的配合問題）；二是單一系統的效果沒有直觀反應出其漏洞（十級npc城的掠奪收益是在遊 戲策劃的規劃之內的，但他並沒有清晰的意識到這一規劃到底會導致什麼樣的整體結果）。而對於絕大部分在遊戲中進行到這一階段的玩家而言，這些漏洞都是顯而 易見的。同樣的，我們可以意識到，如果我們有這樣乙個基於玩家整體遊戲過程的測試的話，那麼很多問題是可以在遊戲面世之前被發現和解決的。
1.在遊戲開發早期預留速度調整和用於中斷的遊戲控制介面。對於測試過程來講，測試者有需要簡化和跳過一般玩家的長時間等待過程，但又要保持在這一過程 中的資料可以與遊戲正常執行時一般玩家同步變化，這就需要遊戲開發過程中為測試預留出可以控制遊戲速度的介面。需要控制的遊戲速度主要包括：玩家資源獲取 的速度，建築單位的建築速度，科技研發速度，軍隊和其他物 品的生產度，以及玩家單位在地圖上的移動速度等。需要特殊指出的是，由於測試者測試的是當前數值體系下的數值平衡問題，因此不應該提供給遊戲測試者改變兩 個速度間相對比例的介面，換言之，遊戲測試者需要的僅僅是乙個調整遊戲整體執行速度的介面。另一方面，遊戲測試者會有測試玩家離開遊戲一段時間後遊戲狀況 變化的需求，以及遊戲測試者本人因為下班，休息或其他原因暫時離開遊戲的需求，因此需要在程式上提供給測試者乙個暫時中斷遊戲進行的介面。這兩個介面應該 在遊戲開發早期即預留，這樣可以讓遊戲設計者在第乙個可執行版本出來時即可開始初步的數值測試。事實上，考慮到當前webgame主流使用的頁面指令碼的後 臺開發模式，遊戲策劃可以在早期進行的測試應該是非常方便和快捷的。
2.為遊戲設計測試提供自動化的指令碼式的測試機械人。無論我們的遊 戲在實際的玩家介面和功能上是否支援玩家連續指定多個任務（ogame預設允許玩家安排長達10個的任務序列，其他戰爭策略類webgame則大多將這一 點作為收費點），遊戲開發者都應該為遊戲設計測試開發這一功能。這將大大有助於提高設計測試的效率，並為乙個測試人員同時測試多個角色，多個流程提供可能 性。為了達到這一目的，乙個可能的程式架構原則是盡量粒子化各個玩家單一過程（例如公升級1座兵營或者公升級1級民房），並至少在開發測試過程中為各個玩家單 一過程提供外部的驅動介面，從而從外部直接接受玩家的指令碼式的測試指令集。這一指令集的乙個可能的形式是：（官府（id：1）公升級到2級；建造民房 （id：2）；民房（id：2）公升級到2級…………）。當然，如果測試人員能夠略有一點程式基礎，將會大大有利於這一自動化測試流程的建立。
3.提供便於非開發人員使用的單一玩家日誌。 事實上，我是支援在遊戲的正式介面中為一般玩家提供檢視個人行為日誌的功能的，並且非常建議在伺服器上盡量保留玩家的玩家行為日誌，這將成為日後遊戲設計 者進行基於玩家遊戲行為的資料分析和挖掘的基礎，這一思路在傳統的網際網路運營和設計中是非常普遍的，但在遊戲行業並沒有得到足夠的重視。但至少，在遊戲開 發測試過程中，需要為遊戲的設計測試人員（他們往往是非技術開發人士）提供便於他們使用的玩家日誌。這一日誌將成為他們發現問題，以及發現問題成因的根本 **。以前面講到的《熱血三國》的設計漏洞為例，玩家日誌中頻繁出現的人禍將成為遊戲設計測試人員發現設計漏洞的乙個重要著眼點。事實上，在遊戲的正式運 營過程中，對遊戲日誌進行資料分析和總結，也是找到遊戲設計漏洞的乙個重要方法。
4.明確需要進行測試的玩家行為模式。由於遊戲設計測 試往往是以10倍甚至100倍於一般玩家遊戲過程的速度在進行的，因此的，我們需要更加明確我們需要關注的玩家行為模式有哪些，並將其對映到我們的測試環 境下，來進行有針對性的行為模式模擬。典型的需要關注的玩家行為模式包括：
（3）夜晚玩家。以學生和從事某些行業的工作（4）不定時玩家，這些玩家可能以在校學生以及其他低端玩家為主體，他們往往以網咖為主要上網地點，遊戲時間非常不固定，日上網時間也可能發生很大的波動。對於這樣的玩家，我們可以模擬乙個以隨機時間驅動的遊戲過程。
（5）雙休日及節假日現象。雙休日意味著會有一大批玩家頻繁的出現連續兩天半（即從周五下
班到周一上班）的離線情況，而節假日則意味著會出現（但不會頻繁出現）大批玩家連續3天~7天不上線的情況。事實上，只要遊戲測試人員在遊戲測試過程中 有意識的停止一段時間的遊戲操作，很容易模擬這一現象。事實上，前文中《熱血三國》的第乙個設計漏洞恰恰出在了對於雙休日及節假日現象的忽略。
建議對這一測試過程不夠了解或者存有疑慮的朋友可以去嘗試一下ogame的第三方伺服器，該第三方伺服器提供了管理員隨時手動管理遊戲速度的功能（事實 上，這一功能的開發難度基本可以忽略），從而使得我們可以很直觀的體驗遊戲中乙個玩家整體的發展流程。乙個額外的話題是，當你在遊戲中發現以100倍速公升 級乙個科技需要幾十個小時時，大概你也會感覺到在標準的遊戲過程中這會帶給玩家什麼樣的體驗了。
戰爭策略類Webgame的設計測試方法
首先需要著重指出的一點是，本文所針對的僅是當前最流行的戰爭策略類webgame，對於其它型別webgame並不適用。事實上，在當前的webgame市場上所充斥的這些戰爭策略遊戲的高度同質化，已經使得我們在很大程度上對於webgame品質的好壞喪失了判斷力。究竟一款webgame設計成什麼樣子才能夠成...
C 設計抽象基類的策略
1 分析相關物件的需求，設計出一組實現公共功能的函式。2 將這些函式作為基類的虛函式 或純虛函式 它們定義了乙個 統一的公共介面。3 由該類基類派生出若干子類，在各子類中實現這些虛函式。includeusing namespace std class container 抽象類 virtual do...
C 泛型程式設計 基於策略 Policy 的類設計
基於策略 policy 的類設計是將templates和多重繼承組合起來，這樣可以產生程式庫中的 設計元素 policies由templates和多重繼承組成。乙個class如果使用了policies,就稱其為host class,那是乙個擁有多個template引數的class template,...