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