web游戏测试资料

web游戏测试资料 。 什么是场景，就是一段假想出来的在现实中可能发生的故事（有联系的连续行为），用来帮助人们理解一 个问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 或者系统。举一个简单的例子说明：玩家背包满时去领取道具，这就是一个场景。 1. 便于学习产品 对游戏测试而言，除了需要熟悉所测试功能外，还需要对周边的系统功能，甚至整个游戏有较深入的了 解。如果能假想自己是一个玩家，模拟玩家可能的操作，这样就能减少从单一功能点角度出发去了解一个 功能的枯燥性，并且可以提升对功能系统内部以及功能点之间关联的理解程度。 2. 将需求文档和测试联系起来 在策划文档中，会对规则进行详细的定义和说明，但是，对于这些规则下的玩法则需要在测试中体现出 来。测试人员除了要对策划案中所列出的规则进行测试外，还需要考虑玩家所有可能的操作。由这些操作， 就组成了我们测试的场景。 3. 暴露产品 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 上的缺陷 缺陷不仅仅是存在于代码层面上，产品设计上也可能会有不合理的地方。我们常用的测试方法，一般都 是针对如何发现代码问题的，在发现设计上的缺陷方面有局限。要发现设计上的问题，就需要从玩家的角 度出发，结合玩家的玩法，设计出特定的场景，在这样的场景下进行测试。 4. 探索产品的用法 对游戏测试，规则是死的，玩家是活的。玩家的行为是不可预期的，玩法是多种多样的。把规则转化为 玩法，建立对应的测试场景，就可以预先把这些可能的玩法在测试时过一遍，更有利于保证我们游戏产品 的质量。这些场景还可以保留下来，作为既定玩法，还能应用于其他系统功能的测试中。 5. 将需求相关的问题引出到台面上 场景测试能有效暴露出产品设计上的缺陷。需求是抽象的，有时只有在实际的运行过程里面才能暴露出 问题。这个实际的运行过程，就是场景测试。 综上，在游戏测试时，引入场景测试，对提升游戏的品质是十分必要的。 1.写出功能系统中对象的生命历程。 2.列出可能的玩家群体，分析他们的兴趣和目标。 3.考虑恶意玩家，他们可能怎么攻击你的游戏，怎么利用现有规则。 4.列出系统事件，考察系统怎么处理这些事件。 5.列出特殊事件，考察系统怎么容纳这些事件。 6.列出收益并创建端到端的任务来检查他们。 7.与玩家沟通，找出原有功能or系统中他们最不满意的地方。 8.与玩家一起参与，观察他们是怎么玩游戏的，经常做些什么。 9.参考本游戏中类似的系统会做什么。 10.研究对这个系统以前版本和竞争对手的不足。 11.创建模拟的外网玩家群体（可使用随机导入外网账号的方式），使用这个模拟玩家群体，模拟外网 真实情况。 1.一个基于真实玩家怎么玩游戏的场景，包括玩家的动机。 2.场景具有感染力，有影响力的干系人会促使让这个场景测试失败的原因得到修复。 3.场景要可信，不仅在真实的世界中可能发生，而且将很可能发生。 4.场景包含对游戏的复杂的操作，或者复杂的环境或者一套复杂的数据。 5.测试结果容易评估 场景测试不是盲目的，想到哪个场景就测试哪个，而是需要事前规划出一系列的可能场景，设计出在 该场景下的测试用例，最后按照用例来执行测试。下面就介绍一种场景测试用例的生成方法。 为了方便测试，我们一般会根据所测试功能的大小，将其划分成一个或几个在逻辑上相对完整的功能 流程（按照UML的定义可称为）。对用例进行分析后，我们就可以整理出用例的场景，再针对这些场 景，设计出场景测试用例。 将要测试的用例按照实际情况排出经过用例的路径，确定出基本流和备选流，列出所有从开始到结束 的可能路径，从而形成测试可用的，有特定意义的用例场景。 举个例子来说明如何生成用例场景： 上图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示， 是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流 可能会重新加入基本流中（备选流1和4），还可能起源于另一个备选流（备选流2），或者终止用例而不再重新加入某个流（备选流2和3） 遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选 流结合起来，可以确定以下用例场景： 场景1 基本流 场景2 基本流备选流1 场景3 基本流备选流1备选流2 场景4 基本流备选流1备选流3 场景5 基本流备选流1备选流4 场景6 基本流备选流3 场景7 基本流备选流4 注：为方便起见，场景2、3和4只描述了备选流1指示的循环执行一次的情况。 当我们的场景确定好以后，就要确定出每一个场景的测试用例。生成测试用例的方法很多，这里就不 一一累述了。就说一下大的原则吧： 1. 基本流的全面测试除了正面的测试用例外，还必须包括负面测试用例，以确保只有在符合条件的情况下才执 行基本流。 2. 对于每个备选流而言，至少存在一个负面测试用例。 3. 每个场景只具有一个正面测试用例和负面测试用例可能是不充分的。 举一个结合游戏的实例 假设有这样一个活动：玩家在特定npc处点击菜单后，可从一系列道具中随机获得一件。某些道具有 上限限制。每个玩家只能领一次。当随机到某些道具的时候，需要有走马灯提示。 用例：与npc对话，领取道具 分析领取道具的整个基本流程顺序，得出基本流： 步骤1 与npc对话，选择领取菜单 步骤2 检查已领取状态：检查玩家是否已经领取过奖励了 步骤3 检查背包：检查背包空间是否足够 步骤4 随机道具：根据既定规则，随机要发给玩家的道具 步骤5 标记已领取：对验证码和玩家做已领取的标记 步骤6 发放道具：把随机到的道具加到玩家背包中 步骤7 记录log：记录领取时间，角色名 再考虑到玩家在领取道具的过程中可能出现的情况，得出备选流： 备选流1-玩家领取过奖励 在基本流步骤2中，如果是已经领取过奖励的玩家，即使用有效 的验证码，也不能再发放道具 备选流2-玩家背包空间不足 在基本流步骤3中，如果玩家背包空间不足，给出提示，不发道 具 备选流3-随机到达到上限道在基本流步骤4中，如果随机到的道具已到达发放上限，需要重具新随机 备选流4-玩家活动贵重道具 在基本流步骤6中，如果玩家随机到了贵重道具，则发送走马灯 消息 用例图解： 按照从“开始用例”到“结束用例”流经的路径，得出以下场景： 场景1-成功领取 基本流 场景2-已领取过奖励的玩家再次领取 基本流备选流1 场景3-背包空间不足的玩家领取奖励 基本流备选流2 场景4-随机到已达上限的道具 基本流备选流3 场景5-玩家领取到贵重道具 基本流备选流4 场景6--随机到已达上限的道具，再次随机，并得到贵重道具 基本流备选流3备选流4 进入游戏行业也有一段时间了，在日常的工作中对游戏的性能测试也产生了一些想法，因此写出来与 大家讨论讨论。 网络游戏行业现在越做越大，面也越来越广了，依我的观点主要分为以下几个方面： 1、传统的c/s 架构 酒店人事架构图下载公司架构图下载企业应用架构模式pdf监理组织架构图免费下载银行管理与it架构pdf 的网络游戏； 2、现在越来越风靡的b/s架构的网络游戏； 3、越来越多的wap网络游戏 那么我接下来就上面所说的3种网络游戏的性能测试怎么去做，发表一下自己的想法。 第一种 传统的c/s架构的网络游戏 这种网络游戏历史最悠久，也是目前最主流的网络游戏类型。这类游戏需要用户下载客户端，然 后通过客户端来访问服务器进行登录和游戏。 这类游戏的性能测试方法大体有三种： 一目前较常规的做法就是由自主研发一个机器人程序，模拟玩家登陆与游戏。这种方法的好处一 是操作方便，对执行性能测试的人员无要求，二是能够较真实的模拟出玩家的部分操作。但是缺点也不少， 如对开发人员要求较高，因为不仅需要模拟用户访问服务器，还需要收集多种数据，并且将数据进行实时 计算等，成本较大，而且也不易维护。除此之外，机器人发生问题的时候，维护起来也不够方便。在复杂 架构下不利于判断瓶颈所在位置。最重要的是一旦机器人开发进度拖迟或者出现致命bug，性能测试将无 法进行。 二使用现成的性能测试工具来进行性能测试。可以使用工具来模拟用户与服务器交互的底层协议 来进行测试。这种方法的优点是灵活方便、易于维护，开发成本小。增加删除性能点及其容易，发生问题 也能立即维护。开发成本相对于机器人来说减少很多，并可以较容易的判断性能瓶颈所在的位置。这种方 式的缺点也有不少，如对性能测试人员的要求比较高，需要根据用例来编写模拟用户与服务器之间的协议 交互脚本。对于模拟真实性方面也比机器人程序差些。 三使用最广泛，且与上面两条不冲突，那就是进行封测、内测、公测等开放性测试方法。这种方 法是最真实的啦：)。让广大的玩家在测试服务器中进行游戏，帮助游戏公司找到游戏中的bug的同时，也 对服务器的压力进行的真实的测试。 第二种 b/s架构的网游 b/s架构的网游现在越来越流行，现在越来越多的人喜欢上了这种类型的网游。它没有传统的c/s 架构的网游那种炫目的效果、唯美的画面，也没有传统网游那种直观的人物动作，但是却吸引了越来越多 的上班族去玩它。因为它有着传统的c/s架构的网游所没有的优势，那就是方便，简单，要求低。只要可 以上网，只要有浏览器，就可以进行游戏。无需下载客户端，无需担心机器配置不够，也无需长时间去投 入，就可以享受到网游的乐趣。 这类游戏的性能测试方法大体有两种： 一、使用工具来模拟用户访问，这个和其他的b/s架构的软件产品一样。通过各种工具，各种协 议来模拟用户访问服务器，与服务器进行交互。 二、和传统的c/s架构的网游一样，它也有封测、内测、公测等活动，让广大的玩家为游戏公司 进行性能测试。 第三种 wap网络游戏 wap网游现在也是越来越多了。这类游戏的性能测试方法大体有两种： 一 使用模拟器在电脑上模拟wap环境，然后使用工具来进行性能测试。使用的协议可以是wap， 也可以是soap等其他协议。 二 与其他两种网游一样，都少不了开发性测试这个环节。 以上就是我这些日子来对网游性能测试的想法，希望对大家有用。 首先需要着重指出的一点是，本文所针对的仅是当前最流行的战争策略类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倍速升级一个科技需要几十个小时时，大概你也会感觉到在标准的游戏过程中这会带给玩家什么样的体验了。 文案策划主要负责的内容是游戏文字相关部分的工作，包括游戏“内”和游戏 “外”。 表面上看来，游戏文案策划的工作似乎不是游戏的核心，但实际上游戏文案策划却是游戏文化中相当重要 的组成部分，缺少他们，游戏文化的魅力将大打折扣。他们是将游戏世界付诸文字，将其具象化的实施者， 同时他们还是游戏周边化的重要参与者。 光有好的文笔并不足以成为一名出色的游戏文案策划。一般而言是先有游戏，再有游戏文案策划，需要其 在有限的创作范围和时间内完成任务。游戏文案策划还需要合作的协调性、对游戏性的了解、收集分析资 料等 多方面能力。好的游戏文案策划, 不光要有过人的想象力、创造力，还要学会使用一些必要的资料。 策划一个历史游戏的时候，兵器的名字你就不能靠想象，而是靠翻阅历史资料。但仅仅查阅是不够 的，一个好的游戏剧情设定和剧情不是靠各种资料拼在一起，灵活运用资料需要时间的积累。 根据不同公司架构及不同项目内的职业分工，一般而言，其工作范围主要包括以下内容： 游戏“内” 按照游戏主策划的设计要求，设定、撰写游戏的世界观并具体展开，以达到游戏主策划的世界观设定要求 等。 游戏“外” 撰写玩家手册、宣传新闻、各类公告、论坛文章、网媒平媒文章以及市场需求等文档；根据游戏剧情设计 的内容，撰写游戏周边小说等文字读物，丰富游戏周边内容等。 就国内情况而言，文案策划的职位多半只在RPG类型或具有RPG风格的游戏项目的开打中才具备。故本文 所述的内容，也主要以RPG游戏的角度出发，同时集中于游戏“内”的相关工作。 一、文案策划的工作 在国外，除系统与世界观、背景剧情等结合极其紧密的游戏外，剧情、脚本和对话大都由专业的作家或专 职游戏作家写好；某些具体的特殊对话，则由关卡设 计师和游戏设计师一起讨论后进行调整。当然，如果 策划经验比较丰富，游戏剧情和对话会由他们直接完成。至于那些剧情对游戏内容影响不大，剧情只是以 游戏内 容表现为中心进行搭建的游戏，可能会在游戏各项内容确定之后再找人撰写脚本。无论哪种情况， 关卡设计师都对文案部分内容拥有一定的权力，可以根据自己关卡 的需要对具体对话和剧情描述进行调整。 那么在游戏开发中，文案策划具体的工作内容有哪些呢？ 1．建构游戏世界观 无论电影还是小说都需要一个背景舞台，游戏也是一样。于是需要有人来讲述这个世界的来龙去脉及现况。 然后才能在上面展开故事、玩家也才能在这个世界上 游弋。这一部分就叫做世界观搭建。就游戏而言，世界观是灵魂也是铁则，游戏中表现出来的一切都不可与世界观相悖。世界观是贯穿游戏始终而恒久不变的 任何要 素。设定一个游戏的世界观，就是设定一个未必存在于现实和历史之中的完整世界的所有法则，它 必须可信，完整，符合逻辑而不存在自我冲突。它不仅仅是整个世 界，更有这个“世界”所附带的历史、地理、文化、民风民俗等因素。 一个游戏的世界观将对这个游戏产生极为重要的影响。从游戏画面风格到系统玩法无一不是围绕着其进行 的。而一个世界观最终会是服务于最最原始的游戏创意。好的世界观必须完整、必须可信、必须一致。首 先它要将各地的历史地理等因素很好地勾勒出来，并且完全和剧情溶为一体。 2．创作游戏剧情 有了背景和舞台便可以开始写故事了。当然也有小故事和大故事之分。大故事是指主线剧情、小故事是指 分支或区域剧情。主线剧情是长篇而且贯通的很多时候 会影响到世界观的修订，而区域剧情可能只是针对某个特殊舞台某个特殊背景的一段小故事。当然游戏剧情和电视、电影的剧情有少许的不同，有不少时候 要考虑关 卡的设计和玩法的设计，比如设置一个大魔头，这个大魔头有怎样的绝招。 3．游戏文字内容的撰写或润色 通常RPG游戏中会出现大量的文字，例如人名、地名、技能名称、技能描述、物品名称、物品描述、人物 对话等。其中部分内容可能是在设定世界观和剧情的过程中就已经完成 ，有的则可能是设计游戏系统的策划或者关卡设计人员初步拟定，甚至有些世界观部分在游戏后期需要修订。这便需要文案策划来进行撰写、 修改或润色。其实这一部分也属于世界观搭建的内容，但由于工作流程和方式不一样，故单独列出。 二、单机RPG游戏的文案设计 游戏的自身性质决定了一般单机RPG游戏的世界观必须向小而精发展，不能求大。西方奇幻游戏的世界观 之所以宏大奇伟，并非源于游戏自身，而是奇幻文学无数作品多年来所架构的一个整体气氛，和中国的武 侠是一个道理。下面简要描述一下单机RPG文案设计的流程和方式，通常在确定主题之后，大致上按照地 点时代、社会、故事等顺序来逐步展开。 1．背景 通常游戏的背景分为现实背景和架空背景。直接将某个时代、某个地点作为环境，这是采用较多的一种设 定手法，众多的西方游戏都定在中世纪的欧洲，使其容 易被大多数受众接受。但反过来说，这种设定也带来一定的难度，文案策划需要向细考证那一时代的社会风气、衣着服饰、人文习俗、建筑装饰、教育经济 等具有这一时代的各类特征以及这一时代所特有的口语和文字，如此才会有很鲜明的时代特色。至于架空 背景，设定起来更为自由，但很容易出现逻辑混乱、文化杂糅等问题，故采用的并不多，就算采用也多半 建立于民间传说和神话故事之上。 2．游戏场合 即游戏剧情发生的场合。确定背景之后，需要更加明确地将游戏发生的场合描述清晰。以古代来说，就可 以简单的分成中国的古代或是西洋的中古时期，若是要更详细的分类，就还可以依时间来标明这个场合是 发生在什么样的时代里。场合除了用来作为时代的补充之外，也可以用来做更进一步的说明。 3．主题 不同的主题适合不同的文化背景，《星球大战》可以吸引美国人一辈子，但不见得能长久打动我们的心； 同样，轩辕剑的内涵也并非西方大众所能深刻体会。但是爱 情、战争等主题无论国度，总是容易引起共鸣。无论是旧瓶新酒还是新瓶旧酒，最紧要的是让主题在保证最大的受众面的前提下体现出新鲜感。 4．社会结构 游戏中的人物或者是人类，或者是具有人类思想的其他生物或机械，因此不可避免涉及社会设定.。游戏中 是否有国家，实行什么政体，有什么机构？游戏中是 否涉及职业、种族，如果有，他们的特点各是什么？ 除此之外，经济、文化、语言、交通等都需要一一建立，有了这些基础之后，故事情节就很容易展开了。 5．地图 在开始更为细致的工作之前，地图的设计必不可少。游戏的故事发生在海上或是陆地，如果是陆地，是否 有高原、山脉、河流这些地理特征？气候怎么样？有什么物产?城市有多大？城市里有哪些建筑？实际的设计过程要根据游戏的实际需要来定，可能复杂也可能异常的简单。 ６．人物塑造 在游戏中，我们是通过角色的眼睛来经历整个故事。不管是哪种视角，最终遇到问题并解决问题的还是角 色本身。所以各主要角色是游戏的灵魂，只有出色的主 人公才能使人流连于故事世界中。因此，成功的设 定出各式各样的人物，游戏就有了成功的把握。完整的故事里有八类角色原型。关于这方面内容，可以参 阅著名的 D&D作家崔西?希克曼的相关文章，这里就不再占用篇幅。 ７．故事大纲 我们的意识倾向于将世界当作一个故事来观察。从某种意义上来说，一个完整的故事代表了人的意识，也 就是处理一个问题，并找到解决办法的过程。故事和故事里 人物深层次动机的原型代表了解决故事里所展示的问题的不同途径。所有完整故事的核心是一个基本结构，一个坚实的框架，围绕这个框架所有故事的 血肉才能得以 找到栖身之所。如果没有这个核心框架，故事就会变得松散拖沓、不知所云。故事的好坏是 由其内在结构决定的。 随便翻开一本介绍如何撰写剧作的书籍，都会发现一些通用的规则，如： 故事必须提出一个问题或是两难的抉择 故事必须有冲突 故事必须有其意义与解决之道 如此等等，当然，戏剧理论并不会替你做任何事情，就象不会指望把凿子放在一块大理石旁，它就会自动 雕刻出雕像一样。戏剧理论能做的只是帮助你检查你正 在塑造的故事，并告诉你其弱点何在。戏剧中的两个重要因素是推动故事情节的动力：障碍与冲突。具体应用到游戏中，可以将障碍变成为在游戏过程中， 需要游戏 者解决的难题；冲突变成为游戏者前进的阻碍，迫使游戏者根据自己目前的状况，想出有效的解 决办法。再具体的说明就是障碍是谜题，冲突是战斗。在RPG游戏中，这两种因素应用最为广泛。 恰当地为游戏者设置障碍和冲突，是游戏者有不断克服困难前进的动力，从而带动故事情节向前发展。 标 准RPG游戏的故事流程一般是： ?????? ?????? ?????? ?????? ?游戏开始???收集情报???战斗成长???更换装备?? ?????? ?????? ?????? ??????? ?????????????????????????????? ? ?????? ?????? ?????? ?????? ???解决事件???向前推进???打败头目???游戏结束? ?????? ?????? ?????? ?????? 在这个标准的单线式角色扮演游戏的流程图中，可以看到影响游戏进行的就是其中“解决事件”这一步骤。 这个解决事件，也就影响到游戏剧情的有趣与否，设计者如何去规划一个又一个的事件让玩家去解决，也 就是角色扮演游戏的最大目的。RPG的故事流程还包括树状、网状以及其他非线性的模式，限于篇幅，读 者可以自行参考相关的书籍。 ８．对话撰写 对话其实也是故事的一部分，之所以单独提出来，是因为游戏毕竟不同于小说，对话在RPG中占据了非常 重要的位置。一定要保证各人有各人说话的风格，使每个人的性格和特点在对话中表现出来，同时，游戏 的主题要在对话中得以体现。对话是体现主人公性格特点的最佳方法。 写对话的时候，要始终把注意力集中在人物的性格之上，以期闻其声知其人。一旦人物性格确定，就容易 想出他们的语气和习惯用哪些词汇。要想创作出充满新意 的、性格鲜活的对话不是一件容易的事。这就象齐白石之画白菜，虽然仅仅是了了数笔，便能跃然纸上，这却是多年实践的结果。如果平日不多作些观察 和训练，要 想几笔就写出一个鲜活的人物是不可能的。 ９．设计具体化 包括主次要NPC、场景、道具等等众多游戏要素。用表格的形式将各部分内容逐一整理，成为策划案并交 付给美术制作和程序调用。 简单的一个NPC描述： NPC的名字：伊修 NPC的用途：在酒馆中提供给玩家重要的情报 NPC的简介：从小是孤儿，十二岁起由帝国的将军抚养，受过严厉且专业的训练，成为帝国特殊任务机关 的一员，负责执行很多秘密任务，参与过多次战争，后来得知帝国的内幕之后，叛变逃往中立的国家，目 前受到帝国的通缉。 NPC的个性设定：沉默寡言、找寻生存的意义、充满爱心、擅于战斗 „„ 简单地说，这份文件是编辑对话时的参考资料，因为写NPC设定的和编辑NPC对话的策划可能不会是同一个人，容易造成衔接有问题，因此文件是越详细越好，其他的部份也是一样。 这份文件也需要提供给美术看，因为美术要依照此NPC的个性去设定2D原画再进行3D模型制作。至于程序，更多的只是需要NPC的名字列表，以便导入游戏数据中。 如果说系统设计实现了游戏的玩法需求，那么世界观的设计则无疑是为了营造游戏世界的氛围，体现游戏 世界的文化感。其实所有的设计都是围绕着功能而展 开，游戏的文化感，氛围也是一种功能，其目的是在 于能够使玩家更好的融入到游戏环境中，并能够对自己在游戏中的所有行为找到合理的环境支撑以及成长 动力， 更上层的要求则是使玩家能够在游戏的过程中，逐渐的了解设计者的思想意图和精神传递，产生一 定程度的共鸣，引发一定程度的思考。因此，文案的工作决不是写 写剧本这么简单的事情。 三、MMORPG的文案设计 RPG游戏，故名思义指的是游戏玩家融入所扮演的角色和游戏中的世界的 过程，游戏的扮演观就是对玩家如何融入自己扮演的游戏角色的看法。而MMORPG则更多的是以实现自我为主的角色扮演，它可以不需要剧 情来实现游戏体验， 所以MMORPG中的角色是现实世界中的玩家在游戏的虚拟世界中的延伸，形成了MMORPG以玩家为中心的角色扮演观。与单机RPG相同的是，在 MMORPG中一样有多种多样的NPC存在，他们各自有着不同的出场背景及人物设定。他们和玩家们在同一个世界中共同生活，在游戏进行过程的各必要环节 中 出现：买卖道具、四处行走、对玩家或怪物做出反应等。而角色扮演的差异只会从剧情表现和玩家个人 的侧面中体现出来，说白了就是在游戏中选择不同职业或种族 的玩家，其游戏方式、游戏风格或者游戏目 的不同。当然，MMORPG归根结底还是大家共同组队后的共同冒险。 重视世界观的MMORPG能呈现出非常明确的故事价值。尽管大多数玩家可能会说“游戏是游戏，故事并不重 要”，但游戏世界对玩家的影响仍然隐隐可见。一般来说游戏的世界观往往反映出某种文化的特质。例如 脱胎于希腊故事的“天堂2”，游戏创作者经心设计了 24章节的游戏故事背景，并以此故事为核心，发展 出所扮演的角色、游戏的场景、人物怪兽的特质及游戏的价值观等。WOW这一非常强调“World”（世界感）的游戏，更是从整体到细节无不阐释着西方文化的二元对立：黑暗/光明、混乱/秩序、战争/和平、瓦解/重建、恶魔/天神、自私/牺牲、贪婪/慷慨等。尽管WOW的魅力很大程度在于其战斗的节奏，但其世界设计 之宏大和剧本设定之行云流水也是深为吸引玩家的一个因素。 国内开发的RPG游戏大多数以MMORPG为主，故下面将以较大篇幅具体说明MMORPG中文案策划的内容，并重点介绍其与单机RPG不同的部分。 1．文案人员结构 任何从事过专业写作的人都知道，光会写对话成就不了一本动人的小说，同样会写新闻的人不见得会写剧 本。MMORPG中的文案设计也是一样，包括故事、任务、NPC对话、帮助、物品描述等海量内容，需要各方 面的知识和能力。也许你会认为，只要不考虑资金预算和时间期限，那也不过是一个人写上一两年的工作 量。但无论从效率或是经济角度而言，如果要制作一个庞大的MMORPG，以上的方式显然不合理，因此我们需要一个文案团队。 首先，项目中需要一个主文案（Lead Writer）。主文案是团队中的核心人物。在一款游戏中，从头到尾保 持一致的风格是很重要的。风格一致包括人物与背景的一致、游戏风格定位的一致等。故 事有不同的风格，角色有不同的腔调，还有各种细节都必须前后一致、吻合环境，才能让人感觉到角色栩栩如生。这一切都 依赖于主文案的功力：让不同人笔下的内 容体现出整体统一的风格，给玩家带来幕后只有一人操刀的感受。 主文案也是与其它策划、其他部门之间沟通的桥梁。举例而言，当文案组要对某个任务进行修改的时候， 需要由主文案对其他各部门的负责人进行通知，否则不免出现剧情小说与任务不符等往往到产品上市才发 现的隐藏错误。 其他的文案（Stuff）则在主文案的指导之下将概要扩充，通力将制定的各项任务完成，最终交于主文案定 稿。对于文案而言，最需要的能力是文字表达能力和对游戏产品特征的了解。一般MMORPG中文案的个数视游戏产品的规模限制在1~4人左右。 2．游戏主调 文章有主旨，游戏有主调。游戏的主调也是游戏创作者在游戏中固化的剧情部分想传达给玩家最主要的感 受。 游戏延续了好几个礼拜，带给玩家的感受可能就只是种“愤怒”、“悲伤”、“欢乐”或“悬疑”等，以 上种种要让玩者感受到的情绪，也正是游戏主调中重要的元 素。在单机RPG的游戏设计中，如前文所述，通常会先把要设计的世界观主调明确的定下来。然后以这个主题为出发点，所有的世界观设计都围绕着这 个主调而深 入，贯穿于整个世界观乃至整个游戏中都无时无刻的可以感受到这一主调。 以冰风谷这款电脑游戏为例，讲述的是一支冒险队伍接受任务，解决侵扰小镇的邪恶势力，最后终于使小 镇恢复和平的故事。这个游戏故事的主调是什么呢？其实我 们从游戏开始时的CG中就能发现有一定的脉络可循，也就是坦帕斯大祭司杰若的象征：无私奉献的高贵情操。在整个游戏的进行中，这样的主调也一 再重复出现， 例如在库达哈的大德鲁伊，为了保护这个小镇而奉献出自己的性命；断手塔大法师杰瑞的女 儿也为精灵与矮人的团结牺牲奉献；甚至到游戏的最后，坦帕斯神庙的牧 师也为了恢复小镇旧有的和平而献上了生命。这诸多桥段所呈显的，不只是一个个分别的小故事，而是以无私奉献这种高贵的情操来做整 个冒险的主调。 游戏有了主调之后，剧情也就较能顺利推进。就像刚才所提及的冰风谷，一经确定游戏主调是无私奉献的 高贵情操，故事的主线剧情就不会掺入一些要玩家偷鸡摸狗 的桥段；相反地，这样的主调会在主线的几个 段落以不同的面貌重复出现，也因此让整个故事能够较为深刻地印在玩家们的心中。 而在设计MMORPG的世界观时，在注重主调的同时需要考虑如何营造一种虚拟世界的氛围，而所营造的这个 虚拟世界将带给玩家一种什么样的感觉。也就是在这 样的一个虚拟世界中，希望带给玩家一种什么样的印 象，并在这种印象之下应该出现哪些世界构成的要素，在这种世界氛围之下会引导玩家产生哪些行为，其 所有的 设计都会以突显世界的氛围感而平铺。而在这样的虚拟世界中，由于他的氛围，也会衍生出各种各 样的故事及主题。 这样的设计原则第一是增强了游戏的沉浸感并保证游戏的拓展性。作为MMORPG，其游戏时间很长，需要努力营造出一种虚拟世界的感觉。玩家置身与虚拟世界 中，在MMORPG中，作为玩家的个体其行为更多的时候是被环境所制约和影响；而不应该是在很大程度上去影响环境。同时，这种制约和影响是真实的，合情 合 理的，这样才能被玩家所接受，并加强游戏环境的存在感。再者，MMORPG的自由度远远高于单机RPG， 加之世界的庞大，游戏过程是完全以第一人称视角呈 现，完全不能得到全知视角的感受，因此玩家用自身 的方式来体验剧情、创造剧情是最重要的。以玩家来到一个村庄为例，最理想的效果是玩家通过观察村民 的言 行、周围的环境和一些材料的记载来明白事情的前因，主动去建立和NPC的交互甚至在此交互中与其他玩家产生冲突，而不是一股脑地被告知所有的情节和要做的 事情。最后， MMORPG作为制作、运营周期都很长的游戏产品，必须在规划之初就对未来的版本拓展做详细的规划。在丰富的世界氛围基础之上，很 容易在一个多元化的结构 中拓展出不同的主题和剧情来满足资料片或新版本游戏的需要。而玩家在游戏过 程中，由于不断有新的主题、内容和挑战出现，也会保持着一种持续性的热情。而当产品需要添加这些新 元素时，也不容易产生背离原始设计的错误。 3．剧情设计 通常，游戏剧情的创作者必须对熟悉的情感和玩家的情感异常了解。如果创作者一点情感都没有，那么他 所创造出来的游戏也就不太容易引人入胜。相反地，创作者如果对某种情感有特别深刻的感动，那么他对 于游戏剧情主调的刻画，也就容易扣人心弦。 创作者需要对于各种情感多多加以体会。当自己能够感觉到感动的时候，我们才会了解，为什么玩家在这 一段故事里也会觉得感动。而这也就指向游戏剧情设计的一 个确定点：创作者想让玩家感受的是什么？我 们在游戏中塑造出一个幻想的世界，是因为我们想要传达某些感受给玩游戏的人。如果知道要给玩家什么 样的感受，那 么创作的方向就会照这个方向前进；玩家在游戏进行的过程中，才会找到可以依凭的指南， 同时也才能体会游戏的妙处。 有些人可能会说，这样一来游戏的自由性不就大大降低了吗？这样的担心其实是不必要的——就如同几何 平面中，两点决定一条直线，但通过这两点的线可以有无限 多条。确立游戏的主调是给创作者创作游戏故 事的依据，但游戏的进行除了必须完成的剧情任务外，玩家可以有各种不同的游戏方式的选择。 当然，MMORPG中的剧情不是仅仅写作那么简单，而是需要完整的“设计”。单机RPG的叙事（Storytelling）可能是模块化、环状或是网 状，而MMORPG中甚至会出现更为复杂的结构。“设计”的过程展现出故事本 身与游戏其他部分的紧密联系。而在MMORPG中如何让故事与海量的玩家接触 并产生互动，本身就是非常 重要的一项“设计”。这种设计需要非常的自然，而不是强加给玩家。毕竟MMORPG的玩家类型众多，很难期望他们都对我们所做的 设计产生兴趣，然而我们所努力的目标应该且必须是所有的玩家。 MMORPG中的剧情部分——游戏进程的推进，通常以完成任务为前提，在不断解决各任务的过程中通过NPC对话、得到物品等方式来加深对游戏剧情的理 解。现在的MMORPG一般都为玩家准备尽可能多的任务，在 量的基础上同时注重质的提高。当然，玩家在同时接受大量任务后反而迷失了主线剧情的局面也不是 我们想看到的，因此在系统上可以尝试的方法是让玩家同时只能接到两个但极具深度的任务，通过任务一个接 一个的解决让玩家享受到游戏的剧情。除此之外，让玩 家之间互动发生各种活生生的故事是更加完美的解 决方式，这一点将在后面的“剧情转化为任务”部分做更深入的阐述。 在单人RPG中，每个玩家都能成为英雄或成就传奇， 独一无二、如临实境。与之不同的是MMORPG中如果玩家成为游戏故事中的“英雄”但没有其他玩家的认可，这种英雄感则荡然无存。真正的英雄需要众人的 欢 呼！事实上，这一问题在几乎所有的MMORPG中都是利用英雄NPC的概念来解决。如果说单机RPG是由“选择”+“完成”来递进剧情，那么MMORPG 的方式更多的体现在“完成”，因为大多数选择都交给了英 雄NPC，而完成的部分则交给众多玩家。使用英雄NPC的另一个优势是可以赋予他们负面遭遇——这 些负面遭遇如果在玩家身上发生，会带来或多或少的不适感。举个不恰当的例子，在Warcraft3这样RTS游戏的剧情部分（可以部分理解为RPG）中， 当Pladin英雄Arthas加入Undead时，很多玩家都会感觉情绪 低落。当MMORPG中需要一些主要角色遭遇戏剧性际遇，如丧友、发狂、变得邪 恶甚至被谋杀等，将这些事件安排给NPC，可以在保证情节张力的同时稳定玩家的情绪。 对于MMORPG而言，很重要的一点是需要把背景故事想象成永远不会结束。也许你只需要写出当前的故事， 仅仅几页，但是你对将来故事的发展变化了然于 心。实际操作中，则需要根据玩家的行为和游戏的设计来 进行调整。这是具有很强技巧性的工作：一方面对于玩家的需求要灵活变通，另一方面又不能和你先期制 定 好的全局架构产生冲突。可以与之类比的是美国情节剧的编剧，无论剧集会拍多久，一开始便打好了可 以拓展几年的底子，然后根据演员的变动、剧情的转折、收视 率的起伏逐一铺展出每段剧情，甚至可能因 为玩家的集体意志而改换某些情节。 对于新手而言需要牢记的是，千万不要试图一上来就写宏观的大故事，那会带来非常大的工作量，而且面 临调整之时几乎是不可完成的任务，因为涉及的不仅仅 是故事，还有对话、任务、道具、怪物等等。故事 线应该是动态的，随着游戏运营慢慢发展，游戏中的NPC也会同样产生相应的变化（前提是这种变化是有 益的， 而且不对玩家产生困扰）。 一个新的文案策划常犯的错误是几乎把所有的剧情信息都放在在NPC的对话中。但事实上，有很多内容不 适合放在NPC的对话当中，如闲话、谣言等等。也 许大家对柏德之门中丰富的NPC对话记忆犹新，但是这 在MMORPG中不对路。表达剧情可以利用几乎所有的场合，如游戏中的书籍、日志、公告板、路标、地 图、屏幕（科幻游戏）等，我们可以称之为“故事点”。还有一点需要说的是，并非所有的“故事点”都需要 精确地描述剧情，有时候根据需要混入一些歪曲搞怪的 内容，往往能起到意想不到的效果——NPC会说谎，书也会印错，这很自然，不是么？ 另一个常犯的错误是把所有的剧情都交代给玩家，这一点在前面也有所提及。尽管生动而且充分满足了自 身的成就感，但事无巨细的讲述并没有增添多少游戏的乐 趣。众所周知，MMORPG对玩家而言不存在任何秘密。有很多方式可以利用，常见的是通过系统设计产生随机的剧情元素。当然，要保证这些随机的要素 在游戏 全局故事的控制范围之内。 4．剧情转化为任务 单机RPG中的任务大多数对于玩家是不可逆的，杀死的人物不会复活，得到的宝物只有一件，而MMORPG中 大多数任务则是可重复的。在MMORPG中令任务产生重复性的方式一般有两种：一种是“菜单式”的任务， 即NPC告知玩家“某种怪物是邪恶的，去尽量消灭 他们”、“消灭10只独眼怪”、“我需要15张狼皮”等；另一种任务是单个玩家只能完成一次，但对于满足条件的任何玩家都可以完成，这类任务只是单机 RPG任务的一种变种，并不属于地道的可重复任务。很多游戏开发者使用任务编辑器来从大量任务模板中来产 生任务，这些任务看起来似乎遍布游戏世界各地，从而玩家将花上大量时间来完成。但这些随机生成的任 务除了给玩家带来奖励和经验值，对游戏世界及其展没有任何影响。如果游戏中所有的任务都是这类任务， 那简直是文案策划的失败，NPC不再是有血有肉的人物，而是一段木桩。 “EQ2”中“A mysterious Medallion”这一杀死300兽人的任务，如果没有剧情的铺垫和NPC合情合理的对话交代，那么这不过是场无意义的屠杀。不过，近年来流行的副本， 解决了以往常遇到完成任务的玩家 拥挤一团的问题，对于文案策划而言，副本是更大福音。因为副本的存在，流畅真实的剧情体验成为现实。 试想一下过去常见的情 形：一个NPC前围绕着密密麻麻的玩家与之交谈以获得任务，这简直是给乞丐发放 食物的场景。有了副本以后，对于突出独立体验的任务，可以进入副本房间独自 一人与NPC交谈，然后去完成光荣或邪恶的使命。 在MMORPG中，情境与背景历史的设定是作为任务丰富叙事的基础，而更重要的一点是玩家可以即兴完成一 些剧情任务，因为MMORPG的环境是不确定的，什么事都可能发生。在WOW中 玩家可以邀请好友来协助自己完成任务，如“爱与家庭”任务的最后阶段，玩家要化妆成血色十字军深入山谷里戒备森严的城堡，护 送一名骑士进入森林中的空地， 首先要从NPC那里接受任务的玩家才能化妆，可以和其他没做过任务的玩 家共享任务协同完成，而请来协助支援的玩家多数是没有任务的，或者已经完成了这个任 务，则需要这些玩家清空山路上的敌对NPC并在城堡外接应，等护送骑士的玩家大约快走出城堡时会有四个精英怪来袭击， 这时来接应的玩家则可先引开它们，或 者被护送的骑士会主动攻击，则所有玩家都需投入战斗。 在这一剧情任务的过程中可能出现一种“另类”的情况，即敌对阵营的玩家会来干扰护送任务，他们故意把周围 的敌对NPC（对于两个对立阵营的玩家来说这些 NPC都是敌对的）引到正在任务的玩家周围以加重他们的 负担，因为被护送的骑士会主动攻击敌对NPC，而他们可能会因为寡不敌众而任务失败。这类交互虽然 在 玩家群体中被认为是不道德行为，但其本身产生了富有戏剧性的玩家间交互，这也是游戏设计的最新趋势， 从规则性系统向涌现型系统转变。规则性游戏系统要求设计者必须精确制定游戏中发生的每件事，而涌现 型游戏系统则以许多基本的规定为基础，规定的相互作用导致出现复杂的事件，甚至连设计者都不能预先 知道这些事件的发生。这些都是任务设计中需要考虑的因素。 最近的一些MMORPG其任务中还特有“服务器事件”这一概念，一般是指游戏服务器世界的大环境剧情发展 进程，每个服务器里的玩家角色都受到一定程度的影 响。服务器事件可以是系统预设，如WOW中根据现实 同步会有圣诞节、万圣节、情人节之类的节日事件；或者是需要整个服务器玩家协同来完成一个任务来激 发服 务器事件，安其拉之门任务是首个服务器事件，在游戏预设前史中暗夜精灵和龙族军团以极其惨痛的 代价在一处名叫希利苏斯的地方竖起了魔法屏障，将亿万只虫人 封印在甲虫墙内。一面安其拉铜锣被放置在虫墙之外，还有一枚流沙节杖由上古之龙阿纳克洛斯交给大德鲁伊鹿盔，并叮嘱他好好保存，当未来的 盟友们能够集合起 足够的力量，就用这节杖敲响安其拉铜锣开启大门，率领大军冲进安其拉。之后整个服 务器的玩家们会轮流使用一个指定角色帐号作为英雄角色来为全阵营的玩家接 受任务，并负责收取玩家们 所收集的任务物资来交给NPC，最终这个角色可以获得开启安其拉之门的至高荣耀使命，触发当前服务器 的重大事件，开门当天会有众 多玩家角色聚集安其拉迎战开门后涌出的巨兽，守卫当地的要塞；保卫战结 束后这个地方会增加全新的剧情任务。在这其中玩家所体验的是一种即兴的随机叙事，强 调一大群玩家共 享一个游戏空间并共同经历探索庞大的事件，虽然也有高度设计的情境和一部分剧情，但是每个玩家以及 每个玩家团队所经历的叙事路径都不同。 就目前的情形而言，现有MMORPG存在的问题是玩家一直在自娱性扮演，庞大的玩家群体还没能有效的被系 统组织起来进一步互动扮演形成更多的事件。 MMORPG应该提供一种可预计的交互性模式，玩家可以按自己所选择角色和任务提示来做相应的事，给予玩家即兴的互动模式。设计者应更多地给出交互所依赖 的规 则，创造场景和叙事可能性，最大限度地加强游戏的沉浸感。尽管从剧情出发很容易展开任务的设计，但 如何产生满足各种玩家类型、各种娱乐风格的任务、如 何在游戏中根据现时场景而产生任务、如何使玩家通过完成任务来影响游戏世界、如何使任务更有趣，从而使玩家愿意花时间来做任务、如何产生能加强玩 家与游戏 本身、玩家之间的联系的任务、如何使玩家自己产生任务给别的玩家等等问题都是值得每个设计 者认真思考的。 5．拓展游戏外的世界 对于MMORPG而言，设计者流畅精美地完成了自己的叙事设计可以算作成功，但只有激发出玩家自己的叙事 欲望，才能称之为大成功。这需要使创造出来的世界留有无限的扩展空间供玩家们继承。游戏自身需要有 一个庞大完整的背景故事，当玩家产生兴趣的时候可以深入研究，背景故事越真实丰富，就越能抓住玩家 的心。背景故事庞大的时候，无论是语言风格还是内容导向都一定要明确，尤其是当文案策划有多个人或 者发生人员流动的时候。 拓展游戏世界的方式有很多种，例如：给玩家发言的平台，无论是在网站论坛中发表自己的同人小说还是 在游戏中提供任何可供玩家编辑的事物；建立一个访问 排行榜或者组织专人评论，甚至给写出好作品的作 者一定奖励，让好的玩家作品为更多的玩家所看到，诸如此类。总之，将游戏世界的影响拓展到现实世界 中并产生 互动，能让玩家对游戏产生更浓厚的兴趣和更深刻的记忆。 MMORPG的制作是一件庞大的工程，每一部分都有不同的工作方式和实践技巧。毕竟MMORPG的发展并不算悠久，笔者也只是在诸多前人的指点下自我 摸索，故贻笑大方之处不可避免。以上所探讨的内容实为抛砖 引玉，希望更多人了解、喜爱游戏文案策划这一工作并找出更好的工作方式和实际经验。对于单机游戏 感兴趣的读者，可以阅读IGDA组织诸位成员合作编写的《Game Writing Narrative Skills for Videogames》一书，其中介绍得十分详尽，这里就不班门弄斧了。 四、游戏文案的书写 在大致介绍完单机RPG和MMORPG的文案设计之后，最后介绍一下游戏文案写作中需要特别注意的一些事项。 在为一款游戏写对话或者剧情的时候，大多数文案策划都努力把内容写得更加生动有趣，然而又时常事与 愿违。经常出现的是以下两种情况，一种是作品的可读性很 好，却让开发人员将其实现时出现困扰，易于 阅读却难于实现；另一种则恰好相反，可能会很很有条理利于开发，但却缺乏作品的美感和感染力。这时， 我们不妨借 鉴一下游戏策划案的写作方式，来找寻并得出双赢的解决方案。 大多数游戏的策划文档都是诠释性或描述性而非叙事型文档。策划人员将复杂的观念进行分解，然后以清 晰明了的语言表述出来，并用数据表明其意图。显然这些策划案不可能扣人心弦或引人入胜，因为它仅仅 是在表述一些信息。 借用程序的术语，凡是游戏策划案都应遵循OOD（Object Oriented Documenting，面向对象写作）的原则，借鉴OO中的抽象、分类、封装、消息等基本原则进行写作，有益于发挥思维，更重要的是保证了概念的一 致性，使参与开发的各类人员在开发时具有共同语言。 同时，由于阅读这些文档的对象是需要详细信息的读者，如程序开发人员或美术设计人员，因此这类文章 通常都会描述得比较精确并且具备以下一些特点。它会将内 容简要而准确地表述出来；它具备群体性，因 为文档需要不断地交流数据；它们会十分清晰，并使用合适且有组织的风格和用词。 文案策划书写的文档同样符合上述标准。文案策划需要分解复杂的观念，比如情节、角色设计、场景以及 游戏世界，并且用简单明晰的语言表述出来。接下来，我们将探讨如何将上述的文档特征应用于游戏的叙 事及描写过程中。 1．条理性 我们首先要注意并确保的是将自己的想法完整条例地表达出来，保证没有任何遗漏，因此以何种顺序来完 成文档就显得十分重要。新闻写作中著名的金字塔写作模式 中强调任何一个故事都要明确5个W： “Who”即故事中的人物、 “What”即故事情节、 “Where” 即故事发生的场景、“When”即故事发生的时间顺 序、 “Why”即故事的动机、“How”则是叙述方式。单纯写作游戏故事时，可以集中于想象的发挥和文笔 的优美，但是作为游戏的剧情文案，则要同金字塔式写作 一般，按一定条理来陈述。 再比如，设计一套剧情任务时，任务流程中有一系列领取、过程和交接的步骤，可能还涉及计时、组队方 面的额外要求，那么在书写文档时就应该按照任务完成的顺 序来展开。在做这样一个流程的描述时，剧情 显然不能大范围地出现，只能使用剧情中可能用到的NPC名字和相关的术语，并且以最简洁明了的语句逐 条详细的书 写。如果单纯把所有对白提取出来，会发现由于角色的不断变化对白缺乏表现力，但对于任务 设计而言，可以保证不会出现任何差错。在这一过程中，最需要强调的 就是描述剧情时的条理。 2．准确性 在开发团队中，对策划案产生任何误解都会导致额外的工作，因此确保所有内容的准确性十分重要。例如 制作一个内部场景时，风格、布局、方位、距离、立体结构 和玩家位置等众多信息缺一不可。任何一个部 分的描述不准确，都可能导致场景的修改甚至重新制作。与返工的时间相比，多投入一些时间来准确描述 这些场景，可 以节约大量的人力和时间。 在保证准确性的同时，策划文档应该尽可能简短，无关的内容应尽量删除。很多文案策划喜欢添加用夸张 的词汇来增强文档的可读性，这是不合适的，即使游戏需要 一些有趣或感人的剧情，文档本身也并不需要 象小说一样绘声绘色，充满喜剧感，因为过多的无关元素只会减慢阅读者的阅读速度。 同样，文档也不需要写得很“好”。策划文档是直接而易懂的，而不是如诗歌般深刻或朦胧。毕竟开发人 员读策划案的目的不是为了解闷。通常策划文档将被多次阅 读，尤其是直接的工作伙伴，他们可能会反复 阅读数十遍，再有魅力的文档也会在反复不断的阅读后变得毫无乐趣，毕竟这些文档不是小说。 3．清晰度 用简单而准确的表述来达到内容清晰的目的，也是文案策划必备的能力之一。明了的陈述、良好的语句结 构、适当的遣词造句，才能写出明晰的优秀文档。 除非因为一些特殊的目的，通常不要在游戏和策划案中使用生僻的词语。因为阅读者没有时间和耐心去翻 词典，碰上这种情况大多数的开发者都会选择直接去询问设 计者本人。没有人乐意去阅读这样的文档，实 在是太费力了。当然，如果因为某些原因必须用到这类内容，则文案策划务必需要对其进行注释。 同时，良好的文档组织结构，同样可以使文档更加清晰，开发者都愿意看到结构整齐、清晰易读的文档。 除了常用的写作工具Word、Excel，一些公司甚至采用Html或数据库的形式，为了便于建立文档内容或文 档之间的引用。 这方面的能力不是一朝一夕可以培养，但绝对是文案策划必备，需要在平时的工作中不断培养和锻炼。 4．一致性 对于大型的游戏项目而言，很难做到但必须要做到的一点，是保持文档的一致性。在写大量故事文档时， 可能会花费很长时间，例如几个月，这时保证文档的一致性就变得尤其重要。 因此，在把文档交给开发团队的其他成员之前，需要仔细校对一遍，以检查别字、错词以及角色名称、技 能名称、物品名称等是否统一，这个看起来虽是是小事，但在文档撰写的过程中，却不容忽视，因为细节 往往决定着成败。 5．可信度 文档的一致性，在某种程度上也体现出文档的可信度，而一份文档的可信度，则往往关系到这份文档的价 值。 经常在文档中出现错误或疏漏，会导致同伴对你的信任降低，严重的甚至会给团队的信心蒙上阴影。撰写 文档的时候，最好能为所有的主张都加以实际的证据支持或 者明确的上下文提示，尤其是那些有争议的主张。例如，设定一段剧情中一个NPC被黑暗魔王杀死，作为该NPC同伴的游戏主角虽然不喜欢他但仍然向黑暗魔王 复仇，但玩家真的能够理解游戏主角会这么做么？ 可信度同样要依赖于对内容本身的了解，包括游戏的游戏性、主题、类型、前后叙述，甚至系列游戏中的 历史等，因此主文案需要对游戏系统的设计了如指掌，而执行文案则要对相关的内容做详尽的了解及分析。 6．适应不同读者 游戏开发的前期和后期，经常需要对公司的其他人员，如管理层或游戏市场人员描述游戏中的内容，这时 需要明确地传达他们所需要的信息。他们可能会对故事的大 概轮廓和主要角色感兴趣，但一份完整详细多达几十页的剧情及角色的细节描述文档，会给工作带来额外的负担，而令人完全丧失兴趣。 对于类似市场部门的人员而言，前面所述的新闻行业金字塔模式更为有效，阅读文档的前两段，就可以了 解到基本内容，在后面的段落添加更多的细节描述，但第一 段一定要能够大致说明主要内容。因为一个简洁、描述事实的大纲，后面接着长篇幅的细节描述文档，可以更好地将内容传递给市场部门，并使他们容 易阅读及理 解。 好的故事类文案可以在某种程度上起到鼓舞士气的效果，当团队每个成员都阅读打动人心的故事情节、精 彩的任务时；当美术设计人员、关卡设计人员以及其他开发者参照包含在任务中角色的特征、场景、主要 事件的任务说明进行开发制作时，兴趣和动力都会有明显的增加。因此，我们应当用更专业和更有效的方 式，来撰写一份好的文档，相信通过上述的一些介绍，会对读者有一定学习借鉴的作用。 1.游戏简介 2.游戏运行前的配置要求 3.视觉效果:(1)色调设计 (2)画面设计 4.音乐音效 5.游戏可玩性 6.道具设定 7.玩家互动:(1)交流沟通 (2)团队配合 8.任务系统 9.可操作性 10.界面设定:(1)设计人性化界面 (2)避免游戏界面干扰游戏显示区域 (3)游戏产品的其他情况调查 11.特色,平衡性, 12.综合评价 13.商业化模式 14.游戏的技术分析 一份完整的评测报告主要包括: 简介游戏类型背景,世界观等. 游戏特点分析与相关作品的对比. 游戏中的系统 游戏的潜力 游戏可能面临的问题 提出适当的意见. 结论. 一般测评一款游戏，会从以上的各个方面进行一一的测试评论，写明优缺点，以及改进 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 。当然， 不一定每个项都必须要去评论，你可深入就某一个主题进行评论。 不过，最好能保证一个游戏测评的完整性，条理性和逻辑性。 如题，列条详述。 1.辅助过程裁减、细致化、明确项目规范.清晰产品在面向最终用户时的形态，对策划案（产品需求） 中阐述不清晰或者有逻辑冲突的地方提出质疑.实际开发中，程序员受限于工作的焦点，所以QA/QC人员必 须做到更了解产品将要达到一个什么样的形态，期间QA/QC人员的思路应保持在最终用户的身份上，而非 开发参与者。 要求: 仔细阅读策划案(产品需求) 对阐述不清或者产品需求本身逻辑冲突所导致的疑问，要求做出释疑 依照开发目标，清晰该开发阶段产品的目标形态，以及与最终形态的差距 2. 制定〈质量保证计划〉参考相应的产品策划案，严谨斟酌产品需求的合理性以及大胆假设在即定需 求下有可能产生的BUG，以此制定出质量保证计划（测试流程）产品将要实现的功能必须严格遵守产品需 求，对于产品需求本身的合理性以及需求中所忽略的重要缺憾及时的对开发团队提出见解 要求: 确保《质量保证计划》严格的依照产品的需求 对需求合理性及缺憾性需求提出成熟的见解 制定出完善的质量保证计划，测试流程中不仅要保证每项功能的实现还必须最大程度的假设可能出现 的情况 3.产品检查.确保产品在严格依照策划案（产品需求）实现了有效功能的同时，最大力度的保证实际开 发人员所未预料到的BUG得到如实的反馈.依照制定的《质量保证计划》严谨的落实测试项，并且如实详尽 的以书面形式（BUGZILLA）反馈。 要求: 遵照已有的测试计划完整的进行测试 参考现有产品需求，以用户的角度斟酌是否合理和完善，并且如实向开发团队反馈成熟建议 在确保测试流程完全落实，并且所有已知BUG已经反馈的情况下，进行大量重复性的测试。（就公司 产品而言，就是反复玩，实际工作中，仅仅有30%左右的BUG是在预先制定的测试流程中可以体现的，其他大部分BUG在无序测试中反而更容易被侦测到） 未预料到的BUG出现，则总结该BUG的类型，并且将非偶然性的BUG添加入《质量保证计划》中。偶然性BUG权衡后记录。见注? 4.过程审计 统计反馈BUG的隶属对象 明确BUG会将由谁来处理，并且依照项目进度对BUG划分优先 级 要求: 明确BUG的处理方，并且在BUGZILLA中指定正确的对象（不排除A的代码出现的BUG将由B处理的情 况，具体实际对象应参考项目进度或服从安排） 明确目前的进度下将要处理的BUG 将反馈BUG的ID对应告知相应的开发人员 5.跟踪问题处理.根据项目的实际开发进度，跟踪已知的产品BUG处理情况.已处理的BUG经过反复测试后，及时反馈。 要求: 重复产品检查过程 核实BUG是否完全处理，以及最大程度的保证没有延伸BUG 及时在如:bugzilla中反馈BUG目前状态 6.度量及报告.资源有限的情况下，面对多个项目或者单元需要测试，QA/QC人员需要评估并且如实反馈。 要求: 在项目进行中，有核心部分需要有较大的把握保证其稳定性，在人力和时间资源有限的情况下，将精 力更多的花费在此方向上，对于整个项目来说，是更优选择 7.经验积累 自身的工作经验的累积以外，对日渐成熟的工作方式及流程做书面保留，以实现公司非物 质财富的累积 注?：偶然性BUG的处理在权衡后，明确其产生环境并加以记录。如：使用不同引擎开发的产品 开发环境的不同其偶然性BUG总有着必然联系，对此加以记录方便后续工作者的快速任职。 近两年，IT业一直经历着“寒冬”，但是游戏软件业却呈现出了勃勃生机。网络游戏仅在中国游戏市 场出现不过两三年，正式投入商业运营的游戏数目已超过100款，但众所周知，都是国外的（主要是韩国 的游戏）统治着国内大部分的市场，国内游戏软件想要突围而出，主要从二个方面，一是可玩性，由于中 国有上下五千年的传统文化，博大精深，是我们得天独厚的优势，二是游戏的质量，游戏测试作为游戏开 发中质量保证的最重要的环节，在游戏设计与开发的过程中发挥着越来越重要的作用。 游戏测试作为软件测试的一部分，它具备了软件测试所有的一切共同的特性：测试的目的是发现软件中存在的缺陷。测试都是需要测试人员按照产品行为描述来实施。产品行为描述可以是书面的规格说 明书，需求文档，产品文件，或是用户手册，源代码，或是工作的可执行程序。 总而言之，测试就是发现问题并进行改进，从而提升软件产品的质量。游戏测试也具备了以上的所有特性，不过由于游戏的特殊性，所以游戏测试则主要分为两部分组成，一是传统的软件测试，二游戏 本身的测试，由于游戏特别是网络游戏，它相当于网上的虚拟世界，是人类社会的另一种方式的体现，所 以也包含了人类社会的一部分特性，同时它又是游戏所以还涉及到娱乐性，可玩性等独有特性，所以测试 的面相当的广。 称之为游戏世界测试，主要有以下几个特性： 游戏情节的测试：主要指游戏世界中的任务系统的组成。 游戏世界的平衡测试：主要表现在经济平衡，能力平衡（包含技能，属性等等），保证游戏世界竞争公平。 游戏文化的测试：比如整个游戏世界的风格，是中国文化主导，还是日韩风格等等，大到游戏整体，小到NPC（游戏世界人物）对话，比如一个书生，他的对话就必需斯文，不可以用江湖语言。 要了解如何测试游戏必需了解如何做游戏，了解它的开发过程，才能真正的测好游戏。游戏要成功，其基本的必要条件有三。分别为Vision(设计)、technology(技术)和Process(过程)。 游戏策划与测试计划：测试过程不可能在真空中进行。如果测试人员不了解游戏是由那几个部分组成的，那么执行测试就非常的困难，同时测试计划可以明确测试的目标，需要什么资源，进度的安排， 通过测试计划，既可以让测试人员了解此次游戏测试中那些是测试重点，又可以与产品开发小组进行交流。 在企业开发中，测试计划书来源于需求说明文档，同样在游戏开发过程中，测试计划的来源则是策划书。 策划书包含了游戏定位，风格，故事情节，要求的配制等等。从里面了解到游戏的组成，可玩性，平衡（经 济与能力），与形式（单机版还是网络游戏），而我们测试在这一阶段主要的事情就是通过策划书来制定 详细的测试计划，主要分两个方面一是游戏程序本身的测试计划，比如任务系统，聊天，组队，地图等等 由程序来实现的功能测试计划，二是游戏可玩性有测试计划，比如经济平衡标准是否达到要求，各个门派 技能平衡测试参数与方法，游戏风格的测试，三是关于性能测试的计划，比如客户端的要求，网络版的对 服务器的性能要求。同时测试计划书中还写明了基本的测试方法，要设计的自动化工具的需求，为后期的 测试打下良好的基础。同时由于测试人员参与到策划评审，对游戏也有很深入的了解，会对策划提出自己 的看法，包含可玩性，用户群，性能要求等等并形成对产品的风险评估分析报告，但这份报告不同于策划 部门自己的风险分析报告，主要从旁观者的角度对游戏本身的品质作充分的论证，从而更有效的对策划起 到控制的作用。 游戏设计与测试：设计阶段是做测试案例设计的最好时机。很多组织要么根本不做测试计划和测试设计，要么在即将开始执行测试之前才飞快地完成测试计划和设计。在这种情况下，测试只是验证了程 序的正确性，而不是验证整个系统本该实现的东西。而我们的测试则会很明确，因为我们的测试计划已经 写的很明确，需要测试那些游戏系统，但是我们还需要了解系统的组成，而设计阶段则是设计系统的过程， 所有的重要系统均是用UML状态图进行了详细的描述，比如用户登陆情况。 在团队中若是有资深的测试人员要具备的一项基本的素质就是可以针对UML的用例图，时序图， 状态图来设计出重要系统的测试案例，只有重要系统的质量得到充分的测试，游戏程序的质量才可以得到 充分的保证。比如上图中就是一个用户登陆游戏系统的时序图。从这里我们可以很明确的了解玩家是如何 验证并登陆系统的，在这个过程中要与那些对象进行交互，比如这里我们就是三个系统之间的交互，客户 端（玩家部分），网关，账号服务之间的一个时序变化关系，为了能够完整的对这个流程进行测试，我们 必需设计出可以覆盖整个流程的测试案例，并考虑其中可能的非法情况，因为这个时序图只是考虑了用户 正常登陆成功的情况，并没有考虑密码错误，通信失败等许多可能存有的情况，并形成完整的测试案例库， 从而对登陆系统的系统化测试做了充分的准备。同时通过这张图，性能分析人员还可以分析出可能存的性 能瓶颈，比如这里可能有的瓶颈如下，总网关是否可以达到多少用户的并发，是如果达不到，是否可以采 用分布式部署或是支持负载平衡，三者之间的网络带宽的比例分配，账号服务器是否可以承载多个网关的 连接请求，最大连接请求可以达到多少等等，同时会针对这些风险做性能测试的设计，并提出自动化测试 的需求，比如模拟玩家登陆的压力工具等等。 在设计评审时，测试人员的介入可以充分的对当前的系统构架发表自己的意见，由于测试人员的 眼光是最苛刻的，并且有多年的测试经验，可以比较早的发现曾经出现的设计上的问题，比如在玩家转换 服务器时是否作了事务的支持与数据的校验，在过去设计中由于没有事务支持与数据的校验从而导致玩家 数据丢失,而这些风险可以在早期就规避掉。上面所说的是对游戏程序本身的测试设计，对于游戏情节的测 试则可以从策划获得，由于前期的策划阶段只是对游戏情节大方向上的描述，并没有针对某一个具体的情 节进行设计，进入设计阶段时，某个游戏情节逻辑已经完整的形成了，策划可以给出情节的详细设计说明 书，称为任务 说明书 房屋状态说明书下载罗氏说明书下载焊机说明书下载罗氏说明书下载GGD说明书下载 ，通过任务说明书我们可以设计出任务测试案例，比如某一个门派的任务由那些组成， 我们可以设计出完整的任务测试案例，从而保证测试可能最大化的覆盖到所有的任务逻辑，如果是简单任 务，还可以提出自动化需求，采用机器人自动完成。 集成测试阶段：集成测试是对整个系统的测试。由于前期测试与开发的并行，集成测试已经基本完成， 这时只需要对前期在设计阶段中设计的系统测试案例运行一下就OK了。我们主要的重心在集成测试中的兼容性测试，由于游戏测试的特殊性，对兼容性的要求特别高，所以我们采用了外部与内部同部进行的方式， 内部我们有自己的平台试验室，搭建主流的硬软件测试环境，同时我们还通过一些专业的兼容性测试机构 对我们的游戏软件做兼容性分析，让我们的游戏软件可以跑在更多的机器上。 游戏可玩性测试：游戏可玩性测试也是非常重要的一块，主要包含四个方面： 1.游戏世界的搭建，包含聊天功能，交易系统，组队等可以让玩家在游戏世界交互的平台。 2.游戏世界事件的驱动，主要指任务。 3.游戏世界的竞争与平衡。 4.游戏世界文化蕴涵，游戏的风格与体现。 这种测试主要体现在游戏可玩性方面，虽然策划时我们对可玩性作了一定的评估，但这是总体上 的，但一些具体的涉及到某个数据的分析，比如PK参数的调整，技能的增加等一些增强可玩性的测试则需 要职业玩家对它进行分析，这里我们主要通过三种方式来进行： 1.内部的测试人员，他们都是精选的职业玩家分析人员，对游戏有很深的认识，在内部测试时， 对上面的四点进行分析。 2.利用外部游戏媒体专业人员对游戏作分析与介绍，既可以达到宣传的效果，又可以达到测试的 目的，通常这种方式是比较好的。 3.利用外部一定数量的玩家，对外围系统的测试，他们是普通的玩家，但却是我们最主要的目标， 主要的来源是大中院校的学生等等，主要测试游戏的可玩性与易用性，发现一些外围的Bug。 4.游戏进入到最后阶段时，还要做内测，公测，有点像应用软件的beta版的测试，让更多的人参与测试 1. 测试的定义 如果给个定义，我觉得：测试工作是，解决玩家所遇非正常问题的预测工作，同时也是不断调试平 衡的一个长期观察任务。无论在什么时间段，功能实现、内测、公测等。测试都应该是分硬件与软件两部 分测试。 2. 硬性问题 硬件的BUG部分是指会引起不能让游戏流程进行的BUG。死机、画面出错等硬性问题。这种问题只 要按照一定流程进行游戏，就会发生。但对一些会不断增加服务器负担的高级BUG，应该不会短期测试出来。而对这种在有计算机就出现的问题，现在的游戏在制作过程中都有可自动记录问题的LOG功能，所出现的BUG大多会被程序部门解决掉。部分的LOG功能可保留到正式客户端，以收集因为升级客户端，而不 断产生的新问题。这里应该不会在讨论范围内吧。 3. 软性问题 而软件的逻辑部分大多会在后期进行，比如公测。是各种功能的数值调整。主要为游戏的世界定 义一个平衡。除了初级的数值设定外，内部测试人员很少有能把一个功能测试千万遍的。于是有可能产生 出猫耍的老虎团团转，这种经典的寓言故事。策划及相关测试人员注重的应该是这部分的测试原理及方法。 而这部分问题的测试，同硬性问题一样，需要一定流程及要求。而具体流程只有根据具体游戏来决 定，大多是将问题分裂存放，并将理由归纳。但有几点是不变的。 3.1 平衡的目标 而如何让各种设定不偏离主题，明确世界背景及制定等级概念应该是首要的。尤其在一些角色等 系统十分复杂的情况下。那种变态ADD的规则，可由主角的5~6种基础属性影响到数十种战斗、非战斗技能。还可根据各种物品来休整这些数值。而无论如何。他们都有个明确的等级观念。从弱到普通，再到强， 甚至到最强的龙。这是因为他们知道一个人，最强也不能强过龙。这样就给自己定下上限目标。 所以，测试时首先不要去看玩家可选择的职业技能等等是否足够多。都会获得什么强大的技能、体 力等等。先了解到这个世界里，各个种族之间的关系、职业的互补、各个角色的互相的关系，在整个世界 中是什么位置，是否够合理、让常人可以现实中的逻辑去衡量，这个角色在游戏是否合理。之后才需要针 对每个种族、每类职业、每个角色的平衡。最后到一个一个角色的测试。有人会说这是前期策划制定讨论 的部分，没错，因为测试从这里就已经在策划的头脑中开始了。 在这里定义的过程，正好与现实世界中相反。现实世界是总结出整体的平衡，而游戏世界则要定义 平衡，再将世界整理成平衡的状态。 3.2 划分等级 测试时同样要明确问题的严重等级，一个数值影响的事物越多，那他的严重等级越高。现在的MMRPG 整个属性结构，基本都类似树形结构，之间也有着一些交错的枝叶。力量等最基本的角色属性，为根。这 类属性会影响到的其他属性，最终到达游戏的胜负，任务的完成等等。而这些属性的等级自然也就十分明 确。根为最高，枝叶最低。而修整树木永远不会从根开始。 力量，最基础的属性，结合自己的命中率，对方的敏捷等，会影响物理攻击。同样也影响着可拿的 武器。但如果这个人攻击力过高。那是谁的原因？是武器，还是角色的力量。需要修改那一个？那些角色 的基础属性是最不能随便修改的。因此，还是武器吧。实在不行在从由属性引发的其他部分着手，如技能 的熟练度等。越基础的部分，影响力越大，也最容易出错。角色的基础属性是一切测试的根源，同样也是 最不能随便更改的一类。更不应该因为某个问题而被指明要求更改。而添加删除任何一个属性，更会让之 前的测试工作有2/3付之一炬，也许更多。而对于各种武器，基本可以与角色测试分开。在角色属性有数 十条的游戏中，武器更不会容易出现大的问题。 严重等级之间从高到底可分为，角色，物品，技能。要修正这三大类属性，尽量在自己的范围内修 正。不要妄想在其他级别动手，更别想在比自己之前高的级别里动手脚。而在这些属性里面同样还各种属 性，就需要根据具体游戏进行划分测试。虽然这里以属性距离，但任务也同样如此，相互关连的任务网同 样十分重要。只不过之前变化较属性掠少。 3.3 玩家是否付出与获得成正比 现实世界中，没有可能可用捷径获得某一种事物、，只有拼搏。游戏世界里是否也是？获得一个 强大技能之前，给角色的锻炼是否足够。让他足够珍惜这一种技能或物品。这是游戏中较为关键的一部分， 多体现在任务上。时间、精力的消耗，是否足够让玩家获得物品时有足够的满足感。以及对得起测试人员 的劳动。 3.4 记录、调整，总结 软性问题应该同硬性问题一样拥有足够多的文档资料来记录，同时也方便对以往数值的效果再思 考。这也应该是所有文档资料应该具备的，记录每次关键更新的工作。调整方面Sid Meier说过，每一次 调整都要多一些。这样可以看到数值中的巨大差别，从中找到合适的数值。这几乎是知道Sid Meier的人 都知道的一句话。（大意相似，具体内容没办法记起来，惭愧） 很多时候，测试时会直接将测试的内容按自己的想法修改。即便记录下来也是只要改好就好。其 实很多时候这些修改都有一定规律，一些修正往往是没改变任何事情。多一些时间去探讨大家是否按照原 来制定的目标去修正，会更合理的利用剩下的时间测试。同样，全部结束后的总结也会让下次制作时避免 出现需要大量修正的设计。 测试方案属于软件工程的范畴，对于策划人员来讲是测试游戏的主力军。好象没听说过哪个策划将测 试过程描绘的很愉快，因为测试本身是一个非常枯燥和痛苦的事情。一套合理的测试方案可以尽可能减少 测试人员的工作量，也能够让测试出的问题能够尽快解决，这就需要测试方案的制订人员对游戏开发有全 面的了解，并能够掌握好测试的进度，其中的难度可想而知了。 测试是游戏开发一个极为重要的组成部分，其所需要的时间一般要占去整个开发周期的1/3左右。测 试贯穿于整个开发进程，小规模的模块测试是由程序人员自行完成的，对策划来讲，如何完成最终的产品 测试才是真正需要关心的。按照软件工程的理论，测试方法主要有两种：黑盒测试与白盒测试。所谓黑盒 测试就是把要测试的对象当作一个黑盒子，不需要知道里面是怎么处理的，只要对输入和输出数据进行测 试就可以了；而白盒测试正好相反，测试者必须对测试对象的内部处理过程非常了解，对里面所有的分支 和循环进行实验从而达到测试的目的。黑盒测试与白盒测试都是最基本的测试方法，属于低层的测试理论， 实际的测试方案都是在这两种测试方法基础上产生出来的。 对于游戏的测试，也不外乎这两种测试方法。基于黑盒测试所产生的测试方案属于高端测试，主要是 在操作层面上对游戏进行测试；基于白盒测试所产生的测试方案属于低端测试，是对各种设计细节方面的 测试。黑盒测试中不需要知道里面是如何运行的，也不用知道内部算法如何设计，只要看游戏中战斗或者 情节发展是否是按照要求来进行的就可以了。这种测试可以找一些对游戏不是很了解的玩家来进行，只要 写清楚要干什么，最后达到什么样的效果，并记录下游戏过程中所出现的问题。而白盒测试就需要知道内 部的运算方法，比如A打B一下，按照A和B现在的状态应该掉多少血之类都应当属于这种测试。白盒测 试需要策划人员自己来完成，因为内部的算法只有开发人员自己才清楚，而且发现问题策划是最容易知道 如何解决该问题的人。由于测试的工作量巨大，合理安排好测试和修正BUG的时间比例非常关键，否则很容易出现发现了问题却没有时间改正或者问题堆在一起无法解决的矛盾。测试设计应当在开发的设计阶段 就要完成，如果开发初期没有给安排出合理的时间，那么最后的结果肯定是不停的跳票！ 在测试方案中，设计人员要根据需要把黑盒测试、白盒测试有效的结合在一起，并且按照步骤划分好 测试的时间段。根据游戏开发过程，测试大致可以分成单元测试、模块测试、总体测试和产品测试几个部 分。单元测试一般集中在细节部分，主要是在游戏引擎开发阶段对引擎的构造能力和完善性进行检测。该 部分的工作要求细致严禁，因为任何一点小的纰漏都可能导致后期大量的BUG产生。这时要求程序开发人员与策划达到无隔阂的交流，策划人员要清楚该引擎任何一个功能单元的使用方法和效果，这样才能够保 证测试中能即使发现问题并指出问题的所在。 模块测试是在游戏开发进程中按照阶段进行的，每当一个模型产生后就需要对该部分进行一次集中测 试，从而保证系统的坚固和完善。模块之间的接口测试也属于该部分的工作，就是说各个游戏模块之间如 何实现过度，数据如何进行交换都要进行严格的测试。往往在模块内部测试时一切正常，把模块拼装在一 起后反而问题百出，这就需要在阶段性模块测试中及时解决！总体测试属于比较高层的测试，在游戏的DEMO 基本完成后，要从宏观上把整个游戏合成在一起，这时就要求有全面控制进度的能力。最终的产品测试是 游戏质量保证的最后一道关卡，要求大量的非开发人员介入进行地毯式轰炸！产品测试往往也会伴随一些 市场活动，这就不是我们现在要讨论的范畴了。 我们已经知道了测试过程分成几个阶段，下面就一起来看看具体要包括那些内容： 1、测试的时间分配：测试时间如何分配会直接影响到开发的进度，它包含测试时间、测试结果汇总时 间以及修改错误的时间等几个部分。一般来说，开发人员只认为测试时间才是需要分配的，其实合理的安 排测试总结和修改BUG等工作占用的时间才是更多的！如果不进行测试情况汇总，项目管理者就无法弄清 到底是哪些部分出了问题；不马上对发现的问题进行修改就会导致更多的问题发生。所以定期测试、发现 问题、解决问题才是最合理的，把整个开发周期划分为几个阶段定期测试是对产品质量的根本保证！科学 安排测试的时间能够用最少的代价解决最多的问题，否则把测试都堆积在最后结果只会是一团糟！ 2、测试人员的安排：测试人员的选择和调配对游戏质量来讲是非常关键的。测试人员尽量不要选择游 戏的开发人员，只有对游戏没有任何了解的人才能真正的发现程序或设计中的问题，虽然他可能对程序和 游戏设计一点都不懂。如果能有一支专门的测试队伍当然是最好的，在经费和人员实在紧张的情况下把其 他非开发部门的人借调一下不失为一个好办法。 3、测试内容清单：这部分要求测试方案设计人员精心的考虑计算，尽量把测试内容精确到操作级。意 思就是说最好细化到某测试人员点击鼠标几百次这种程度，因为测试人员是对你的游戏内容一点都不了解 的，只有你把任务全都明确后才可以收到预期的效果。只规定某人去玩这个游戏然后给予反馈是不负责任 的做法，这种测试方案只能当作垃圾给丢到废纸桶里面去！要对每个测试人员的工作明确下去，用测试表 格的形式进行填写测试报告并签字写清楚测试时间，才算是合格的测试方案。 4、测试结果汇报：最终测试报告汇总上来，策划人员要对全部方案进行评估并进行分类，把测试中发 现的问题确定解决优先级然后反馈给相关部门。问题特别严重的要敢于要求返工，任何一点小问题也不能 放过，严格的测试才能带来高质量的游戏产品，这个法则适用于任何产业，游戏也不例外！ 5、调整开发进度：由于测试发现的问题所带来的进度影响要及时反馈给上级领导，然后马上更新项目 进度表，并注明更改原因。因为开发进度的调整关系到很多部门的工作，所以最好在早期设计进度时就把 测试时间预算进去，但实际上大多数情况下开发进度的变化是非常频繁的。如何休整进度还不影响到游戏 完成的最终时间，对于任何项目管理人员来说都是一个挑战！ 测试方案一旦确立，剩下的就是烦琐和枯燥的机械工作了。测试是最痛苦的，但没有测试游戏是不可 能成为产品，这也是国内大多数赶工期的游戏BUG百出的问题所在。科学的制订测试方案并协调好各部门之间的进度，对任何一个项目来说都是至关重要的事情，对于刚入门的策划来讲，学会写测试方案是必修 的课程之一。 测试工作的全面完工，标志着项目开发的结束。但对于策划来说，你的工作还没有完，接下来你就要 开始教给玩家如何玩这个游戏，让我们来看看如何完成游戏手册吧！ 1. 游戏安装： 智能机可能在安装上不会出现比较明显的问题，小容量机就比较明显，受制于容量和处理器， 在安装的时候很容易会造成死机，或者安装成功后不能游戏。还 有一类问题，就是当测试机已经有一个此游戏的老版本，再覆盖安装新版本的时候，可能会出现一些奇怪的问题，不过发生几率比较低 2. 游戏开始： LOGO SCREEN 必须要有，作为一个公司的品牌，这个是必须的。如果是腾讯渠道的项目，那么 开始游戏的时候需要有腾讯的 LOGO （不过腾讯的 LOGO 一直在变）。开始游戏之后，游戏主页面应该包含 开始游戏（ start ）、继续游戏（ continue ）、设置（ option ） / 音乐（ music ）、帮助（ help ）、 关于（ about ）、退出游戏（ exit ），这些缺一不可。 开始游戏，点击后开始新游戏 继续游戏，从上次存档点开始继续游戏 设置或者音乐项，主要是此项的功能就是为了开启和关闭游戏音乐，有可能会附带其他功能， 大多数游戏会只有一个开始关闭音乐功能，所以可能会直接写成音乐，或者打开 / 关闭音乐，这要看每个公司自己的定义。 帮助，主要内容就是游戏世界观介绍，游戏按键说明。其中游戏按键说明必须与游戏中的按 键完全相同 关于，主要内容是关于此游戏制作公司等相关信息，这要看每个公司自己的定义了。 退出游戏，点击后游戏关闭 3. 游戏中： 这个就是一个很庞大的问题了， RPG 、动作、运动、射击 „„ 等等各种类型的游戏都有自己不同的测试内容。 RPG 类：游戏内容：主线任务、支线任务、物品、技能、宠物 ( 如果有的话 ) 、数值 图像：像素残余、像素残缺、图像出屏 音效：音效流畅、可以正确的打开及关闭音效 文字：文字出屏、错别字、敏感字 动作类：游戏内容：人物属性，技能 图像：像素残余、像素残缺、图像出屏 音效：音效流畅、可以正确的打开及关闭音效 文字：文字出屏、错别字、敏感字 帧速率 : 好的公司会在设计说明中规定游戏的帧速率值，确保游戏的流畅性，可是 却缺少工具来衡量实际的帧速率，只能靠感觉了。如果觉得游戏卡，就报帧速率过低的错误吧 PS: 其他类型的游戏我没怎么接触过，实在是不太好归纳。以上 2 点是我平时公司时想到的一些，肯定不全面，我会继续补充的 4. 游戏后： 此阶段是指游戏通关后的情形 结束画面 PS ：呵呵，说实话，游戏结束画面，我还真没见过几次。公司项目特别紧张，经常是只给几 天的时间，能把所有机型跑一遍已经是万幸了，从来没通关过 „„. 5. 计费点： 国外的项目基本上都是下载付费的，跟国内的百宝箱差不多，这块其实就不用测试人员去测试 了。国内项目就不太相同，现在很多项目都使用了游戏中相关功能开通 收费的形式，我们称之为计费点。高级物品，钱，经验，关卡开通等等。每次在使用一个计费点模块的时候，手机都会发送一条短信，收到 下行后，游戏就会开通这 个计费点的功能。比如说你想购买 10000 金币，当选择购买后，游戏会最小化， 然后手机发送出一条短信，此时，游戏会自动最大化，并提示你购买成功，然后 你就获得 10000 金币。 流程是这样的，那么问题就来了，手机在频繁的获取计费点时，游戏来来回回的最小化、最大 化，可能会出问题。 6. 广告： 国外项目有些会在游戏开始页面加入广告，点击后会打开一个 WAP 页面。此模块测试目标就是频繁的打开页面会不会引起游戏死机，页面是否能打开。