淺析Webgame的設計測試方法

近兩年，webgame成為了平臺商和用戶熱棒的對象，今天我們就來侃侃webgame的設計及測試的方法。

首先需要著重指出的一點是，本文所針對的僅是當前最流行的戰爭策略類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倍速升級一個科技需要幾十個小時時，大概你也會感覺到在標準的游戲過程中這會帶給玩家什么樣的體驗了。