战争策略类Webgame的设计测试方法
引用来源：http://leyeslau.blog.sohu.com/首先需要着重指出的一点是，本文所针对的仅是当前最流行的战争策略类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倍速升级一个科技需要几十个小时时，大概你也会感觉到在标准的游戏过程中这会带给玩家什么样的体验了。 我挖一下
页:
[1]
