游戏测试入门
-
游戏测试
要了解如何测试游戏必需了解如何做
游戏,了解它的开发过程,才能真正的测好游戏。游戏要成功,其基
本的必要条件有三。
分别为
Vision(
设计
)
、
technology(
技术
)
和
Process(
过程<
/p>
)
。
游戏情节的测试:主要指游戏世界中的任务系统的组成。
游戏世
界的平衡测试:主要表现在经济平衡,能力平衡(包含技能,属性等等),保证游戏世界竞争公平。
< br>游戏文化的测试:比如整个游戏世界的风格,是中国文化主导,还是日韩风格等等,大到游戏整体,小到< /p>
NPC
(游戏世界人物)对话,比如一个书生,他的对话就必需斯
文,不可以用江湖语言。
游戏测试
游戏设计与测试:设计阶段
是做测试案例设计的最好时机。很多组织要么根本不做测试计划和测试设计,
要么在即将
开始执行测试之前才飞快地完成测试计划和设计。在这种情况下,测试只是验证了程序的正确
性,而不是验证整个系统本该实现的东西。而测试则会很明确,因为测试计划已经写的很明确,需要测试 p>
那些游戏系统,但是还需要了解系统的组成,而设计阶段则是设计系统的过程,所有的重要系
统均是用
UML
状态图进行了详细的描述,比如用户登陆情况。
游戏测试
-
策划测试
游戏测试
测试过程不可能在真空中进行。如果测试人员不了解游戏是由那几个部分组成的,那么执行测试就非常的
困难,同时测试计划可以明确测试的目标,需要什么资源,进度的安排,通过测试计划,既可以让
测试人
员了解此次游戏测试中那些是测试重点,又可以与产品开发小组进行交流。在企业
开发中,测试计划书来
源于需求说明文档,同样在游戏开发过程中,测试计划的来源则是
策划书。
策划书包含了游戏定位,
风
格,
故事情节,
要求的配制等等。
从里
面了解到游戏的组成,
可玩性,
平衡
(
经
济与能力),与形式(单机版还是网络游戏),而测试在这一阶段主要的事情就是通过
策划书来制定详细
的测试计划,主要分两个方面一是游戏程序本身的测试计划,比如任务
系统,聊天,组队,地图等等由程
序来实现的功能测试计划,二是游戏可玩性有测试计划
,比如经济平衡标准是否达到要求,各个门派技能
平衡测试参数与方法,游戏风格的测试
,三是关于性能测试的计划,比如客户端的要求,网络版的对服务
器的性能要求。同时测
试计划书中还写明了基本的测试方法,要设计的自动化工具的需求,为后期的测试
打下良
好的基础。同时由于测试人员参与到策划评审,对游戏也有很深入的了解,会对策划提出自己的看
法,包含可玩性,用户群,性能要求等等并形成对产品的风险评估分析报告,但这份报告不同于策划部门
自己的风险分析报告,主要从旁观者的角度对游戏本身的品质作充分的论证,从而更有效
的对策划起到控
制的作用。
游戏测试
-
经典解析
游戏测试
在团队中若是有资深的测试
人员要具备的一项基本的素质就是可以针对
UML
的用例图,时
序图,状态图
来设计出重要系统的测试案例,只有重要系统的质量得到充分的测试,游戏
程序的质量才可以得到充分的
保证。一个用户登陆游戏系统的时序图。从这里我们可以很
明确的了解玩家是如何验证并登陆系统的,在
这个过程中要与那些对象进行交互,比如这
里我们就是三个系统之间的交互,客户端(玩家部分),网关,
账号服务之间的一个时序
变化关系,为了能够完整的对这个流程进行测试,我们必需设计出可以覆盖整个
流程的测
试案例,并考虑其中可能的非法情况,因为这个时序图只是考虑了用户正常登陆成功的情况,并
< br>没有考虑密码错误,通信失败等许多可能存有的情况,并形成完整的测试案例库,从而对登陆系统的系统< /p>
化测试做了充分的准备。同时通过这张图,性能分析人员还可以分析出可能存的性能瓶颈,
比如这里可能
有的瓶颈如下,总网关是否可以达到多少用户的并发,是如果达不到,是否
可以采用分布式部署或是支持
负载平衡,三者之间的网络带宽的比例分配,账号服务器是
否可以承载多个网关的连接请求,最大连接请
求可以达到多少等等,同时会针对这些风险
做性能测试的设计,并提出自动化测试的需求,比如模拟玩家
登陆的压力工具等等。
p>
性能测试与优化:最后要单独提一下的是性能优化,在单机版的时
代,性能的要求并不是很高,但是在网
络版的时代,则是两个完全不同的概念,主要包含
了以下几个方面:应用在客户端性能的测试、应用在网
络上性能的测试和应用在服务器端
性能的测试。通常情况下,三方面有效、合理的结合,可以达到对系统
性能全面的分析和
瓶颈的预测。不过在测试过程中有这样一个原则,就是由于测试是在集成测试完成或接
近
完成时进行,要求测试的功能点能够走通,这时你首先要进行优化的是数据库或是网络本身的配制,只
有这样才可以规避改动程序的风险。同时性能的测试与优化是一个逐步完善的过程,需要前期的很多 的工
作,比如性能需求,测试工具等等,不过由于前期工作的完善,这些都在前期完成了
。
游戏测试
-
设计评审
游戏测试
在设计评审时,测试人员的介入可以充分的对当前的系统构架发表自己的意见,由于测试人员的眼光是最
苛刻的,并且有多年的测试经验,可以比较早的发现曾经出现的设计上的问题,比如在玩家转换服
务器时
是否作了事务的支持与数据的校验,
在过去设计中由于没
有事务支持与数据的校验从而导致玩家数据丢失
,
而这些风险可
以在早期就规避掉。上面所说的是对游戏程序本身的测试设计,对于游戏情节的测试则可以
从策划获得,由于前期的策划阶段只是对游戏情节大方向上的描述,并没有针对某一个具体的情节进行设
计,进入设计阶段时,某个游戏情节逻辑已经完整的形成了,策划可以给出情节的详细设计说明
书,称为
任务说明书,通过任务说明书我们可以设计出任务测试案例,比如某一个门派的
任务由那些组成,我们可
以设计出完整的任务测试案例,从而保证测试可能最大化的覆盖
到所有的任务逻辑,如果是简单任务,还
可以提出自动化需求,采用机器人自动完成。<
/p>
集成测试阶段:集成测试是对整个系统的测试。由于前期测试与
开发的并行,集成测试已经基本完成,这
时只需要对前期在设计阶段中设计的系统测试案
例运行一下就可以。我们主要的重心在集成测试中的兼容
性测试,由于游戏测试的特殊性
,对兼容性的要求特别高,所以我们采用了外部与内部同部进行的方式,
内部我们有自己
的平台试验室,搭建主流的硬软件测试环境,同时我们还通过一些专业的兼容性测试机构
对我们的游戏软件做兼容性分析,让我们的游戏软件可以跑在更多的机器上。
游戏测试
-
可玩性测试
游戏测试
游戏可玩性测试:游戏可玩
性测试也是非常重要的一块,主要包含四个方面:
1
、游戏
世界的搭建,包含聊天功能,交易系统,组队等可以让玩家在游戏世界交互的平台。
2
p>
、游戏世界事件的驱动,主要指任务。
3
、游戏世界的竞争与平衡。
4
p>
、游戏世界文化蕴涵,游戏的风格与体现。
这种测
试主要体现在游戏可玩性方面,虽然策划时我们对可玩性作了一定的评估,但这是总体上的,但一
些具体的涉及到某个数据的分析,比如
PK
参数的调整
,技能的增加等一些增强可玩性的测试则需要职业
玩家对它进行分析,这里我们主要通过
三种方式来进行:
1
、内部的测试人员,他们都是精选
的职业玩家分析人员,对游戏有很深的认识,在内部测试时,对上面
的四点进行分析。<
/p>
2
、利用外部游戏媒体专业人员对游戏作分析与介绍,既可以达到宣传
的效果,又可以达到测试的目的,
通常这种方式是比较好的。
3
p>
、利用外部一定数量的玩家,对外围系统的测试,他们是普通的玩家,但却是我们最主要的目
标,主要
的来源是大中院校的学生等等,主要测试游戏的可玩性与易用性,发现一些外围
的
Bug
。
4
、
p>
游戏进入到最后阶段时,
还要做内测,
公测
,
有点像应用软件的
beta
版的测试
,
让更多的人参与测试,
测试大量玩家下的运行情况。
游戏中的场景测试
场景测试就是基于场景的测试
。
p>
什么是场景,就是一段假想出来的在现实中可能发生的故事(有联系的连续行为),用来帮助
人们理解一
个问题或者系统。举一个简单的例子说明:玩家背包满时去领取道具,这就是
一个场景。
为什么要使用场景测试?
1.
便于学习产品
对游戏测试而言,除了
需要熟悉所测试功能外,还需要对周边的系统功能,甚至整个游戏有较深入的了
解。如果
能假想自己是一个玩家,模拟玩家可能的操作,这样就能减少从单一功能点角度出发去了解一个
< br>功能的枯燥性,并且可以提升对功能系统内部以及功能点之间关联的理解程度。
2.
将需求文档和测试联系起来
在策划文
档中,会对规则进行详细的定义和说明,但是,对于这些规则下的玩法则需要在测试中体现出
来。测试人员除了要对策划案中所列出的规则进行测试外,还需要考虑玩家所有可能的操作。由这些操作,< /p>
就组成了我们测试的场景。
3.
暴露产品设计上的缺陷
缺陷不仅仅是
存在于代码层面上,产品设计上也可能会有不合理的地方。我们常用的测试方法,一般都
是针对如何发现代码问题的,在发现设计上的缺陷方面有局限。要发现设计上的问题,就需要从玩家的角
度出发,结合玩家的玩法,设计出特定的场景,在这样的场景下进行测试。
4.
探索产品的用法
对游戏测试,规则是
死的,玩家是活的。玩家的行为是不可预期的,玩法是多种多样的。把规则转化为
玩法,
建立对应的测试场景,就可以预先把这些可能的玩法在测试时过一遍,更有利于保证我们游戏产品
的质量。这些场景还可以保留下来,作为既定玩法,还能应用于
其他
系统功能的测试中。
5.
将需求相关的问题引出到台面上
场景
测试能有效暴露出产品设计上的缺陷。需求是抽象的,有时只有在实际的运行过程里面才能暴露出
问题。这个实际的运行过程,就是场景测试。
综上,
在游戏测试时,引入场景测试,对提升游戏的品质是十分必要的。
创建游戏场景的方法
1.
写出功能系统中对象的生命历程。
2.
列出
可能的玩家群体,分析他们的兴趣和目标。
3.
考虑恶意玩家,他们可能怎么攻
击你的游戏,怎么利用现有规则。
4.
列出系统事件,考察系统怎么处理这些事件。
5.
列出特殊事件,考察系统怎么容纳这些事件。
6.
列出收益并创建端到端的任务来
检查他们。
7.
与玩家沟通,找出原有功能
or
系统中他们最不满意的地方。
8.
与玩家一起参与,观察他们是怎么玩游戏的,经常做些什么
。
9.
参考本游戏中类似的系统会做什么。
10.
研究对这个系统以前版本和竞
争对手的不足。
11.
创建模拟的外网玩家群体(可使用随机导入外网账号的方式),使用这个
模拟玩家群体,模拟外网
真实情况。
一个完美的场景测试应包含几个特征:
1.
一个
基于真实玩家怎么玩游戏的场景,包括玩家的动机。
2.
场景具有感染力,有影响力的干
系人会促使让这个场景测试失败的原因得到修复。
3.
场景要可信,不仅在真实的世界
中可能发生,而且将很可能发生。
4.
场景包含对游戏的复杂的操作,或者复杂的环境或者一套复
杂的数据。
5.
测试结果容易评估
场景
测试
不是盲目的,想到哪个场景就测试哪个,而
是需要事前规划出一系列的可能场景,设计出在
该场景下的测试用例,最后按照用例来执
行测试。下面就介绍一种场景测试用例的生成方法。
使用用例场景设计测试用例
为了方便
测试,我们一般会根据所测试功能的大小,将其划分成一个或几个在逻辑上相对完整的功能
流程(按照
UML
的定义可称为
用例
)。对用例进行分析后,我们就可以整理出用例的场景,再针对这些场
< br>景,设计出场景测试用例。
将要测试的用例按照实际情
况排出经过用例的路径,确定出基本流和备选流,列出所有从开始到结束
的可能路径,从
而形成测试可用的,有特定意义的用例场景。
举个例子来说明如何生成用例场景:
上图中经过用例的每条不同路径都反映了基本流和备选流,
都用
箭头来表示。
基本流用直黑线来表示,
是经过用例的最简单的路
径。每个备选流自基本流开始,之后,备选流会在某个特定条件下执行。备选流
可能会重
新加入基本流中(备选流
1
和
4
),还可能起源于另一个备选流(备选流
2
)
,或者终止用例而
不再重新加入某个流(备选流
2
和
3
)
< br>遵循上图中每个经过用例的可能路径,可以确定不同的用例场景。从基本流开始,再将基本流和备选
流结合起来,可以确定以下用例场景:
场景
1
基本流
场景
2
基本流备选流
1
场景
3
基本流备选流
1
备选流
2
场景
4
基本流备选流
1
备选流
3
场景
5
基本流备选流
1
备选流
4
场景
6
基本流备选流
3
场景
7
基本流备选流
4
注:为方便起见,场景
2
、
3
p>
和
4
只描述了备选流
1
指示的循环执行一次的情况。
当
我们的场景确定好以后,就要确定出每一个场景的测试用例。生成测试用例的方法很多,这里就不
一一累述了。就说一下大的原则吧:
1.
基本流的全面测试除了正
面的测试用例外,
还必须包括负面测试用例,
以确保只有在符合
条件的情况下才执
行基本流。
2.
对于每个备选流而言,至少存在一个负面测试用例。
3.
每个场景只具有一个正面
测试用例和负面测试用例可能是不充分的。
举一个结合游戏的实例
假设有这样一
个活动:玩家在特定
npc
处点击菜单后,可从一系列道具中随
机获得一件。某些道具有
上限限制。每个玩家只能领一次。当随机到某些道具的时候,需
要有走马灯提示。
用例:与
npc<
/p>
对话,领取道具
分析领取道具的整个基本流程顺序,得出基本流:
步骤
1
步骤
2
步骤
3
步骤
4
步骤
5
步骤
6
步骤
7
与<
/p>
npc
对话,选择领取菜单
检查已领取状态:检查玩家是否已经领取过奖励了
检查背包:检查背包空间是否足够
随机道具:根据既定规则,随机要发给玩家的道具
标记已领取:对验证码和玩家做已领取的标记
发放道具:把随机到的道具加到玩家背包中
< br>记录
log
:记录领取时间,角色名
再考虑到玩家在领取道具的过程中可能出现的情况,得出备选流:
备选流
1-
玩家领取过奖励
在基本流步骤
2
中,如果是已经领取过奖励的玩家,即使用有效
的验证码,也不能再发放道具
备选流
2-
玩家背
包空间不足
在基本流步骤
3
中,如果玩家背包空间不足,给出提示,不发道
具
备选流
3-
随机到达到上限道
p>
具
在基本流步骤
4
中,如果随机到的道具已到达发放上限,需要重
新随机
备选流
4-
玩家活
动贵重道具
在基本流步骤
6
中,如果玩家随机到了贵重道具,则发送走马灯
消息
用例图解:
按照从“开始用例”到“结束用例”流经的路径,得出以下场景:
场景
1-
成功领取
p>
场景
2-
已领取过奖励的玩家再次领取
p>
场景
3-
背包空
间不足的玩家领取奖励
场景
4-
p>
随机到已达上限的道具
场景
5-
玩家领取到贵重道具
场景
6--
随机到已达上限的道具,再次随机,并得到贵重道具
基本流
基本流备选流
1
基本流备选流
2
基本流备选流
3
基本流备选流
4
基本流备选流
3
备选流
4
三种网络游戏的性能测试方法
进入游
戏行业也有一段时间了,在日常的工作中对游戏的性能测试也产生了一些想法,因此写出来与
大家讨论讨论。
网络游戏行业现在越做越大,面也越来越广了,依我的观点主要分为以下几个方面:
1
、传统的
c/s
架构的网络游戏;
2
、现在
越来越风靡的
b/s
架构的网络游戏;
3
、越来
越多的
wap
网络游戏
那么我接下来就上面所说的
3
种网络游戏的性能测试怎么去做,发表一下自己的想法。
第一种
传统的
c/s
架构的网络游戏
这种网络游戏历史最悠久,也是目前最主流的网络游戏类型。
这类游戏需要用户下载客户端,然
后通过客户端来访问服务器进行登录和游戏。
这类游戏的性能测试方法大体有三种:
一目前较常规的做法就是由自主研
发一个机器人程序,模拟玩家登陆与游戏。这种方法的好处一
是操作方便,对执行性能测
试的人员无要求,二是能够较真实的模拟出玩家的部分操作。但是缺点也不少,
如对开发
人员要求较高,因为不仅需要模拟用户访问服务器,还需要收集多种数据,并且将数据进行实时
< br>计算等,成本较大,而且也不易维护。除此之外,机器人发生问题的时候,维护起来也不够方便。在复杂< /p>
架构下不利于判断瓶颈所在位置。最重要的是一旦机器人开发进度拖迟或者出现致命
bug
,性能测试将无
法进行。
二使用现成的性能测
试工具来进行性能测试。可以使用工具来模拟用户与服务器交互的底层协议
来进行测试。
这种方法的优点是灵活方便、易于维护,开发成本小。增加删除性能点及其容易,发生问题
也能立即维护。开发成本相对于机器人来说减少很多,并可以较容易的判断性能瓶颈所在的位置。这种方
式的缺点也有不少,如对性能测试人员的要求比较高,需要根据用例来编写模拟用户与服务器之
间的协议
交互脚本。对于模拟真实性方面也比机器人程序差些。
三使用最广泛,且与上面两条不冲
突,那就是进行封测、内测、公测等开放性测试方法。这种方
法是最真实的啦:
)
。让广大的玩家在测试服务器中进行游戏,帮助游戏公司找到游戏中的
bug
的同时,也
对服务器的压力进行
的真实的测试。
第二种
b/s
架构的网游
b/s
架构的网游现在越来越流行,
现在越来越多的人喜欢上了这种类型的网游。
它没有传统的
p>
c/s
架构的网游那种炫目的效果、唯美的画面,也没有传统网游那
种直观的人物动作,但是却吸引了越来越多
的上班族去玩它。因为它有着传统的
c/s
架构的网游所没有的优势,那就是方便,简单,要求低。只要可<
/p>
以上网,只要有浏览器,就可以进行游戏。无需下载客户端,无需担心机器配置不够,也无
需长时间去投
入,就可以享受到网游的乐趣。
这类游戏的性能测试方法大体有两种:
一、使用工具来模拟用户访问,这
个和其他的
b/s
架构的软件产品一样。通过各种工具,各种协
议来模拟用户访问服务器,与服务器进行交互。
二、和传统的
c/s
架构的网游一样,它也有封测、内测、公测等活动,让广大的玩家为游戏公司
进行性能测试。
第三种
wap
网络游戏
wap
网游现在也是越来越多了。这
类游戏的性能测试方法大体有两种:
一
使用模
拟器在电脑上模拟
wap
环境,然后使用工具来进行性能测试。
使用的协议可以是
wap
,
也可以是<
/p>
soap
等其他协议。
二
与其他两种网游一样,都少不了开发性测试这个环节。
以上就是我这些日子来对网游性能
测试的想法,希望对大家有用。
战争策
略类
Webgame
的设计测试方法
首先需要着重指出的一点是,
本文所针对的仅是当前最流行的战
争策略类
Webgame
,
对于其它类
型
Webgame
并不适用。
事实上,在当前的
Webgame
市场上所充
斥的这些战争策略游戏的高度同质化,已经使得我们在很大程度上
对于
< br>Webgame
品质的好坏丧失了判断力。究竟一款
We
bgame
设计成什么样子才能够成功,这个问题是行业
内没有
任何一个人可以回答的了的。在当前以运营和宣传能力作为评判一款
Webgame
p>
成败的标准是一种很
可行和可信的方法,但是对于
< br>Webgame
的设计者和开发者(尤其是策划),这样的现状却是致命的。究竟
我们如何去设计一款
Webgame
,
应当遵循什么样的设计原则?在找到这个问题的答案前,我们的游戏设计
者被迫处在一个
迷茫期中。事实上,本文无意于去找到这一设计原则,仅仅是尝试在开发过程中寻求一些
减少和避免设计失误的方法。
数值设计被认为是战争策略类<
/p>
Webgame
设计中最难的一环,其原因就在于我们对于数值设
计的评价标准知
之甚少。从表面上看,
Webgame
的数值设计是存在有很大的随意性的,尤其是作为
Webgame
核心的各项时
间和资源增长速度的设计,由于它们对于各个玩家来讲是
公平的,而且相互之间往往很难看出直接的数值
关联,因此很多对此并不精通的游戏策划
在设计它们时往往过分随意。而隐藏在这种随意背后的,往往就
是灾难性的游戏进程。无
论是资源生产速度和资源消耗速度的不匹配,游戏战略进程和玩家部队生产速度
的不匹配
,主城和分城建设因不同资源和科技起点造成的数值漏洞,都属于容易带给玩家很严重的游戏体
< br>验挫折,但并不容易在设计阶段快速发现的问题。因此,在战争策略类
Webga
me
的设计开发过程中,我们
需要引入设计测试的方法。
传统的软件测试和游戏测试更加偏重的都是程序漏洞(一般称为
p>
Bug
)而不是设计漏洞。究其原因,很重
要的一点就是测试的测试文档(或称测试用例)是基于既有的设计文档的,测试的评判标准是实现的程序
(游戏)是否符合既有的需求文档。但是在这一过程中,设计的错误往往被忽略。大量的设计漏洞
由于测
试不充分而没有在游戏开发测试阶段被发现,而是被保留到了正式的外部测试阶段
。尤其是一些后期的数
值型漏洞,往往是在游戏开始公测甚至于正式运营后才暴露出来的
。由于游戏数值的普遍关联性,以及玩
家角色积累的连续性,在这一阶段暴露出的设计漏
洞能否被弥补,弥补需要多少时间都成为了未知数。因
此,在游戏开发过程中,我们需要
针对设计漏洞的测试流程和测试方法。
事实上,在游戏行业的
开发过程中,针对单一玩法,单一流程的设计测试(或者叫内容测试)是存在的,
而且也
可以说是比较到位的,但是,战争策略类
Webgame
的特
殊性就在于它的设计漏洞往往出现在多个系
统,多个玩法,多个流程共同作用的一个混合
的玩家游戏过程中,而不是存在于某一个个体中,这样的,
传统的基于模块的测试方法在
应对战争策略类
Webgame
时往往是很不充分的。那么,<
/p>
Webgame
测试中还需
要什么样的测
试方法呢?很简单的,就是测试者(事实上,这个测试者的角色建议以游戏策划而不是专门
的游戏测试人员担任)以不同的游戏阵营和游戏角色加入游戏,整体体验游戏进程,并且记录各种体验性
数据(一般为混合性数据,即不存在于游戏数值策划文档内的数据,例如玩家主城升级到
X
级所需的整体
时间,玩家从进入游戏到开出
第一座分城所需要的时间等)。
我们来看一个近期比较火热的
战争策略类
Webgame
:《热血三国》中所出现的两个最为
严重的,也是游戏
设计者在近期更新中着重解决的两个设计漏洞:
1.
游戏中后期很容易出现资源堆积现象(尤其是石头和铁
),继而频繁的发生“人祸”。一个玩家因故两
天不上游戏就可能导致接近致命的非
p>
PVP
损失。
2
.
玩家频繁刷十级
NPC
城快速提升声
望。
我们会注意到,以上的设计漏洞恰恰反映了两种最常见的
容易在设计开发测试流程中被忽略的漏洞:一是
多个混合系统长时间作用所发生的混合效
应(漏洞一反映了资源生产,资源储存,资源消耗和人祸系统四
个系统共同作用过程中的
配合问题);二是单一系统的效果没有直观反应出其漏洞(十级
NPC
< br>城的掠夺收
益是在游戏策划的规划之内的,但他并没有清晰的意识到这一规划到底
会导致什么样的整体结果)。而对
于绝大部分在游戏中进行到这一阶段的玩家而言,这些
漏洞都是显而易见的。同样的,我们可以意识到,
如果我们有这样一个基于玩家整体游戏
过程的测试的话,那么很多问题是可以在游戏面世之前被发现和解
决的。
当然的,另一个问题也摆在了我们面前:战争策略类
Webgame
以游戏进程缓慢,周期长为主要特征,难道
我们
的一环测试需要测试者连续去玩上几个月么?是否还需要游戏测试者
24
小时在线?因此的,
我们接下
来要指出的,就是这一基
于设计的测试所应采取的正确方法。
1.
在游戏开发早期预留速度调整和用于中断的游戏控制接口
。
对于测试过程来讲,测试者有需要
简化和跳过一般玩家的长时间等待过程,但又要保持在这一过程中的数
据可以与游戏正常
运行时一般玩家同步变化,这就需要游戏开发过程中为测试预留出可以控制游戏速度的
接
口。需要控制的游戏速度主要包括:玩家资源获取的速度,建筑单位的建筑速度,科技研发速度,军队
和其他物品的生产度,以及玩家单位在地图上的移动速度等。需要特殊指出的是,由于测试者测试的 是当
前数值体系下的数值平衡问题,因此不应该提供给游戏测试者改变两个速度间相对比
例的接口,换言之,
游戏测试者需要的仅仅是一个调整游戏整体运行速度的接口。另一方
面,游戏测试者会有测试玩家离开游
戏一段时间后游戏状况变化的需求,
以及游戏测试者本人因为下班,
休息或其他原因暂时离开游戏的需求,
因此需要在程序上提供给测试者一个暂时中断游戏进行的接口。这两个接口应该在游戏开发早期即
预留,
这样可以让游戏设计者在第一个可运行版本出来时即可开始初步的数值测试。
p>
事实上,
考虑到当前
Webgame
主流使用的页面脚本的后台开发模式,游戏策划可以在早期进行的测试应该是非常方便和快捷的
。
2.
为游戏设计测试提供自动化的
脚本式的测试机器人
。
无论我们的游戏在实际的玩家界面和功能上是否支持玩家连续指定多个任务(
Ogame
默认允许玩家安排长
达
1
0
个的任务序列,其他战争策略类
Webgame
则大多将这一点作为收费点),游戏开发者都应该为游戏
设计测试开发这一
功能。这将大大有助于提高设计测试的效率,并为一个测试人员同时测试多个角色,多
个
流程提供可能性。为了达到这一目的,一个可能的程序架构原则是尽量粒子化各个玩家单一过程(例如
升级
1
座兵营或者升级
1
级民房),并至少在开发测试过程中为各个玩家单一过程提供外部的驱动接口,
从而从外部直接接受玩家的脚本式的测试指令集。这一指令集的一个可能的形式是:
(官府(
ID
:
1
)升级
到
2
级;建造民
房(
ID
:
2
);民房(
ID
:
2
< br>)升级到
2
级„„„„)。当然,如果测试人员能够略有
一点
程序基础,将会大大有利于这一自动化测试流程的建立。
3.
提供便于非开发人员使用的单一玩家日志
< br>
。
事实上,我是支持在游戏
的正式界面中为一般玩家提供查看个人行为日志的功能的,并且非常建议在服务
器上尽量
保留玩家的玩家行为日志,这将成为日后游戏设计者进行基于玩家游戏行为的数据分析和挖掘的
< br>基础,这一思路在传统的互联网运营和设计中是非常普遍的,但在游戏行业并没有得到足够的重视。但至< /p>
少,在游戏开发测试过程中,需要为游戏的设计测试人员(他们往往是非技术开发人士)提
供便于他们使
用的玩家日志。这一日志将成为他们发现问题,以及发现问题成因的根本来
源。以前面讲到的《热血三国》
的设计漏洞为例,玩家日志中频繁出现的人祸将成为游戏
设计测试人员发现设计漏洞的一个重要着眼点。
事实上,在游戏的正式运营过程中,对游
戏日志进行数据分析和总结,也是找到游戏设计漏洞的一个重要
方法。
< br>
4.
明确需要进行测试的玩家行为模式
。
由于游戏设计测试往往是以
10
倍甚至
100
倍
于一般玩家游戏过程的速度在进行的,
因此的,
我们需要更加<
/p>
明确我们需要关注的玩家行为模式有哪些,并将其映射到我们的测试环境下,来进行有针对
性的行为模式
模拟。典型的需要关注的玩家行为模式包括:
<
/p>
(1)
深度游戏玩家。他们可以在自己需要的任意时刻保持在线,
而且每天可以保持
12
个小时甚至更长的在
线游戏时间。对于这样的玩家,我们需要模拟的是长时间连续操作的游戏过程,以及一个模拟玩家每日在 p>
线
12
小时以上的周期性游戏过程。
(2)
办公室型玩家。
他们每天白天可以基本保证长时间在线,
但是他们每天的在线时间往往局限在上班时
间
的
9
小时内。对于这样的玩家,我们
需要模拟的是一个每日在线
9
小时以下的周期性游戏过程。
p>
(3)
夜晚玩家。以学生和从事某些行业
的工作者为主的,他们每天的主要游戏时间在晚上下班(放学)后的
几个小时。对于这样
的玩家,我们需要模拟的是一个每日在线
5
小时以下的周期性游
戏过程。
(4)
不定时玩家,这些玩
家可能以在校学生以及其他低端玩家为主体,他们往往以网吧为主要上网地点,游
戏时间
非常不固定,日上网时间也可能发生很大的波动。对于这样的玩家,我们可以模拟一个以随机时间
驱动的游戏过程。
(5)
双
休日及节假日现象。双休日意味着会有一大批玩家频繁的出现连续两天半(即从周五下
班到周一上班)的离线情况,而节假日则意味着会出现(但不会频繁出现)大批玩家连续
3
天
~7
天不
上线
的情况。事实上,只要游戏测试人员在游戏测试过程中有意识的停止一段时间的游戏
操作,很容易模拟这
一现象。事实上,前文中《热血三国》的第一个设计漏洞恰恰出在了
对于双休日及节假日现象的忽略。
5.
明确需要达到和避免的玩家体验和游戏局面
。
我们希不希望玩家每次在线都有事
可作?我们希望玩家被卡在建设时间还是资源上?我们希不希望玩家的
资源很容易达到城
市的储存上限?在各种玩家行为流程下,我们希望各种负体验设置(例如天灾人祸)以
多
大频度发生?诸如以上的设计目标越明确,测试时越能做到有的放矢,测试效果也会越好。事实上,如
果设计测试者能够将这些设计目标量化为明确的数值目标,那么我们的程序开发者完全可以将这些设 计目
标作为游戏系统的报警机制,从而在这些设计目标被突破时直接给予游戏设计测试者
以反馈。这样的测试
流程效果会大大好于盲目的体验式测试。另一点需要指出的是,由于
设计测试过程往往处在一个高速的非
正常的游戏过程中,因此诸如
“玩家建造一个建筑所需时间造成的体验”这样的问题是不适合于在我们的
测试过程中去解决的。
建议对这一测试过程不
够了解或者存有疑虑的朋友可以去尝试一下
Ogame
的第三方
服务器,该第三方服务
器提供了管理员随时手动管理游戏速度的功能(事实上,这一功能
的开发难度基本可以忽略),从而使得
我们可以很直观的体验游戏中一个玩家整体的发展
流程。一个额外的话题是,当你在游戏中发现以
100
倍
速升级一个科技需要几十个小时时,
大概你也会感觉到在标准的游戏过
程中这会带给玩家什么样的体验了。
深度解析:游戏文案策划
文案策划主要负责的内容是游戏文字相关部分的工作,包括游戏“内”和游戏
“外”。
表面上看来,游戏文
案策划的工作似乎不是游戏的核心,但实际上游戏文案策划却是游戏文化中相当重要
的组
成部分,缺少他们,游戏文化的魅力将大打折扣。他们是将游戏世界付诸文字,将其具象化的实施者,
同时他们还是游戏周边化的重要参与者。
光有好
的文笔并不足以成为一名出色的游戏文案策划。一般而言是先有游戏,再有游戏文案策划,需要其
在有限的创作范围和时间内完成任务。游戏文案策划还需要合作的协调性、对游戏性的了解、收集分析资
料等
多方面能力。好的游戏文案策划
,
不
光要有过人的想象力、创造力,还要学会使用一些必要的资料。
策划一个历史游戏的时候
,兵器的名字你就不能靠想象,而是靠翻阅历史资料。但仅仅查阅是不够
的,一
个好的游戏剧情设定和剧情不是靠各种资料拼在一起,灵活运用资料需
要时间的积累。
根据不同公司架构及不同项目内的职业分工,
一般而言,其工作范围主要包括以下内容:
游戏“内”
按照游戏主策划的设计要
求,设定、撰写游戏的世界观并具体展开,以达到游戏主策划的世界观设定要求
等。
p>
游戏“外”
撰
写玩家手册、宣传新闻、各类公告、论坛文章、网媒平媒文章以及市场需求等文档;根据游戏剧情设计
的内容,撰写游戏周边小说等文字读物,丰富游戏周边内容等。
就国内情况而言,文案策划的职位多半只在
RPG
类型或具有
RPG
风格的游戏项目的开打中才具备。故本文<
/p>
所述的内容,也主要以
RPG
游戏的角度
出发,同时集中于游戏“内”的相关工作。
一、文案策划的工作
在国外,除系统
与世界观、背景剧情等结合极其紧密的游戏外,剧情、脚本和对话大都由专业的作家或专
职游戏作家写好;某些具体的特殊对话,则由关卡设
计师和游
戏设计师一起讨论后进行调整。当然,如果
策划经验比较丰富,游戏剧情和对话会由他们
直接完成。至于那些剧情对游戏内容影响不大,剧情只是以
游戏内
容表现为中心进行搭建的游戏,可能会在游戏各项内容确定之后再找人撰写脚本。无
论哪种情况,
关卡设计师都对文案部分内容拥有一定的权力,可以根据自己关卡
的需要对具体对话和剧情描述进行调
整。
p>
那么在游戏开发中,文案策划具体的工作内容有哪些呢?
1
.建构游戏世界观
无论电影还是小说都需要一个背景舞台,
游戏也是一样。
于是需要有人来讲述这个世界的来龙去脉及现况。
然后才能在上面展开故事、玩家也才
能在这个世界上
游弋。这一部分就叫做世界观搭建。就游戏而
言,世
界观是灵魂也是铁则,游戏中表现出来的一切都不可与世界观相悖。世界观是贯穿
游戏始终而恒久不变的
任何要
素。设
定一个游戏的世界观,就是设定一个未必存在于现实和历史之中的完整世界的所有法则,它
必须可信,完整,符合逻辑而不存在自我冲突。它不仅仅是整个世
< br>界,更有这个“世界”所附带的历史、
地理、文化、民风民俗等因素。
一个游戏的世界观将对这个游戏产生极为重要的影响。从游戏画面风格到
系统玩法无一不是围绕着其进行
的。而一个世界观最终会是服务于最最原始的游戏创意。
好的世界观必须完整、必须可信、必须一致。首
先它要将各地的历史地理等因素很好地勾
勒出来,并且完全和剧情溶为一体。
2
.创作游戏剧情
< br>有了背景和舞台便可以开始写故事了。当然也有小故事和大故事之分。大故事是指主线剧情、小故事是指< /p>
分支或区域剧情。
主线剧情是长篇而且贯通的很多时候
会影响到世界观的修订,
而区域剧情可能只是针
对
某个特殊舞台某个特殊背景的一段小故事。当然游戏剧情和电视、电影的剧情有少许的
不同,有不少时候
要考虑关
卡的设计
和玩法的设计,比如设置一个大魔头,这个大魔头有怎样的绝招。
3
.游戏文字内容的撰写或润色
p>
通常
RPG
游戏中会出现大量的文字,例如
人名、地名、技能名称、技能描述、物品名称、物品描述、人物
对话等。
其中部分内容可能是在设定世界观和剧情的过程中就已经完成
,
有的则可能是设计游戏系统的策
划或者关卡设计人员
初步拟定,
甚至有些世界观部分在游戏后期需要修订。
这便需要
文案策划来进行撰写、
修改或润色。其实这一部分也属于世界观搭建的内容,但由于工作
流程和方式不一样,故单独列出。
二、单机
< br>RPG
游戏的文案设计
游戏的
自身性质决定了一般单机
RPG
游戏的世界观必须向小而精发展
,不能求大。西方奇幻游戏的世界观
之所以宏大奇伟,并非源于游戏自身,而是奇幻文学
无数作品多年来所架构的一个整体气氛,和中国的武
侠是一个道理。下面简要描述一下单
机
RPG
文案设计的流程和方式,通常在确定主题之后,大致上
按照地
点时代、社会、故事等顺序来逐步展开。
1
.背景
通
常游戏的背景分为现实背景和架空背景。直接将某个时代、某个地点作为环境,这是采用较多的一种设
定手法,众多的西方游戏都定在中世纪的欧洲,使其容
< br>易被大多数受众接受。但反过来说,这种设定也带
来一定的难度,文案策划需要向
细考证那一时代的社会风气、衣着服饰、人文习俗、建筑装饰、教育经济
等具有这一时代
的各类特征以及这一时代所特有的口语和文字,如此才会有很鲜明的时代特色。至于架空
背景,设定起来更为自由,但很容易出现逻辑混乱、文化杂糅等问题,故采用的并不多,就算采用也多半
建立于民间传说和神话故事之上。
2
.游戏场合
即游戏剧情发生的场合。确定背景之后,需要更加明确地将游戏发生的场合描述清晰。以古代来说,就可
以简单的分成中国的古代或是西洋的中古时期,若是要更详细的分类,就还可以依时间来标明这
个场合是
发生在什么样的时代里。场合除了用来作为时代的补充之外,也可以用来做更进
一步的说明。
3
.主题
不
同的主题适合不同的文化背景,《星球大战》可以吸引美国人一辈子,但不见得能长久打动我们的心;
同样,
轩辕剑的内涵也并非西方大众所能深刻体会。
但是爱
情、
战争等主题无论国度,
总是容易引起共鸣。
无论是旧瓶新酒还是新瓶旧酒,最紧要的是
让主题在保证最大的受众面的前提下体现出新鲜感。
4
.社会结构
游戏中的人物或者是人类,或者是具有人类思想的其他生物或机械,因此不可避免涉及社会设定
.
。游戏中
是否有国家,实行什么政体,有什么机构?
游戏中是
否涉及职业、种族,如果有,他们的特点各是什么?
除此之外,经济、文化、语言、交通等都需要一一建立,有了这些基础之后,故事情节就很容易展
开了。
5
.地图
在
开始更为细致的工作之前,地图的设计必不可少。游戏的故事发生在海上或是陆地,如果是陆地,是否
有高原、
山脉、
河流这些地理特征?气候怎么样?
有什么物产
?
城市有多大?城市里有哪些建筑?实际的设
计过程要根据游戏的实际需要来定,可能复杂也可能异常的简单。
6.人物塑造
在游戏中,我们是通过
角色的眼睛来经历整个故事。不管是哪种视角,最终遇到问题并解决问题的还是角
色本身
。所以各主要角色是游戏的灵魂,只有出色的主
人公才能使人
流连于故事世界中。因此,成功的设
定出各式各样的人物,游戏就有了成功的把握。完整
的故事里有八类角色原型。关于这方面内容,可以参
阅著名的
D&D
作家崔西·希克曼的相关文章,这里就不再占用篇幅。
7.故事大纲
我们的意识倾向于将世
界当作一个故事来观察。从某种意义上来说,一个完整的故事代表了人的意识,也
就是处
理一个问题,
并找到解决办法的过程。
故事和故事里
人物深层次动机的原型代表了解决故事里所展
示
的问题的不同途径。所有完整故事的核心是一个基本结构,一个坚实的框架,围绕这个框架所有故事的
血肉才能得以
找到栖身之所。如果没有这个核心
框架,故事就会变得松散拖沓、不知所云。故事的好坏是
由其内在结构决定的。
随便翻开一本介绍如何撰写剧作的书籍,都会发现一些通用的规则,如
:
故事必须提出一个问题或是两难的抉择
故事必须有冲突
故事必须有其意义与解决之道
如此等
等,当然,戏剧理论并不会替你做任何事情,就象不会指望把凿子放在一块大理石旁,它就会自动
雕刻出雕像一样。戏剧理论能做的只是帮助你检查你正
在塑造的故事,并告诉你其弱点何在。戏剧中的两
个重要因素是推动故事情节的动力:
障碍与冲突。具体应用到游戏中,可以将障碍变成为在游戏过程中,
需要游戏
者解决的难题;冲突变成为游戏者前进的阻碍,迫使游戏者根据自己目前
的状况,想出有效的解
决办法。再具体的说明就是障碍是谜题,冲突是战斗。在
RPG
游戏中,这两种因素应用最为广泛。
<
/p>
恰当地为游戏者设置障碍和冲突,是游戏者有不断克服困难前进的动力,从而带动故事情节
向前发展。
标
准
RPG
游戏的故事流程一般是:
┌────┐
┌────┐
┌────┐
┌────┐
│游戏开始├→│收集情报├→│战斗成长├→│更换装备├┐
└────┘
└────┘
└────┘
└────┘│
┌────────
────────────────────┘
│
┌────┐
┌────┐
┌────┐
┌────┐
└→│解决事件├→│
向前推进├→│打败头目├→│游戏结束│
└────┘
└────┘
└────┘
└────┘
在这个标准的单线式角
色扮演游戏的流程图中,可以看到影响游戏进行的就是其中“解决事件”这一步骤。
这个
解决事件,也就影响到游戏剧情的有趣与否,设计者如何去规划一个又一个的事件让玩家去解决,也
就是角色扮演游戏的最大目的。
RPG
的故事流程还
包括树状、网状以及其他非线性的模式,限于篇幅,读
者可以自行参考相关的书籍。
p>
8.对话撰写
对话其实也是故事的一部分,之所以单独提出来,是因为游戏毕竟不同于小说,对话在
R
PG
中占据了非常
重要的位置。一定要保证各人有各人说话的风
格,使每个人的性格和特点在对话中表现出来,同时,游戏
的主题要在对话中得以体现。
对话是体现主人公性格特点的最佳方法。
写对话的时候,要始
终把注意力集中在人物的性格之上,以期闻其声知其人。一旦人物性格确定,就容易
想出
他们的语气和习惯用哪些词汇。要想创作出充满新意
的、性格
鲜活的对话不是一件容易的事。这就象
齐白石之画白菜,虽然仅仅是了了数笔,便能跃然
纸上,这却是多年实践的结果。如果平日不多作些观察
和训练,要
想几笔就写出一个鲜活的人物是不可能的。
9.设计具体化
包括主次要
NPC
、场景、道具等等众多游戏要素。用表格的形式将各部分内容逐一
整理,成为策划案并交
付给美术制作和程序调用。
简单的一个
NPC
描述:
NPC
的名字:伊修
NPC
的用途:在酒馆中提供给玩家重要的情报
p>
NPC
的简介:从小是孤儿,十二岁起由帝国的将军抚养,受过严厉
且专业的训练,成为帝国特殊任务机关
的一员,负责执行很多秘密任务,参与过多次战争
,后来得知帝国的内幕之后,叛变逃往中立的国家,目
前受到帝国的通缉。
NPC
的个性设定:沉默寡言、找寻生存的意义、
充满爱心、擅于战斗
„„
简单地说,这份文件是编辑对话时的参考资料,因为写
NPC
设定的和编辑
NPC
对话的策划可能不会是同一<
/p>
个人,容易造成衔接有问题,因此文件是越详细越好,其他的部份也是一样。
这份文件也需要提供给美术看,因为美术要依照此
NPC
的个性去设定
2D
原画再进行<
/p>
3D
模型制作。至于程
序,更多的只是需
要
NPC
的名字列表,以便导入游戏数据中。
< br>
如果说系统设计实现了游戏的玩法需求,那么世界观的设计则无疑是为了营造游
戏世界的氛围,体现游戏
世界的文化感。其实所有的设计都是围绕着功能而展
开,游戏的文化感,氛围也是一种功能,其目的是在
于能够使玩家更好的融入到游戏环境中,并能够对自己在游戏中的所有行为找到合理的环境支撑以及成长 p>
动力,
更上层的要求则是使玩家能够在游
戏的过程中,逐渐的了解设计者的思想意图和精神传递,产生一
定程度的共鸣,引发一定
程度的思考。因此,文案的工作决不是写
写剧本这么简单的事情。
三、
MMORPG
的文案设计
< br>RPG
游戏,故名思义指的是游戏玩家融入所扮演的角色和游戏中的世界的
过程,游戏的扮演观就是对玩家
如何融入自
己扮演的游戏角色的看法。
而
MMORPG
则更多的是以实现自我为主的角色扮演,
它可以不需要剧
情
来实现游戏体验,
所以
MMORPG
中的角色是现实世界中的玩家在游戏的虚拟世界中的延伸,
形成
了
MMORPG
以玩家为中心的角色扮演观。与单机
RPG
相同的是,在
MMORPG
中一样有多种多样的
NPC
存在,他们各自
有着不同的出场背景及人物设定。他们和玩家们在同一个世界中共同生活,在游戏进行过程的各必
要环节
中
出现:买卖道具、四处行走
、对玩家或怪物做出反应等。而角色扮演的差异只会从剧情表现和玩家个人
的侧面中体现
出来,说白了就是在游戏中选择不同职业或种族
的玩家,其游
戏方式、游戏风格或者游戏目
的不同。当然,
MMORPG
p>
归根结底还是大家共同组队后的共同冒险。
重视世界观的
MMORPG
能呈现出非常明确的故事价值。尽
管大多数玩家可能会说“游戏是游戏,故事并不重
要”,但游戏世界对玩家的影响仍然隐
隐可见。一般来说游戏的世界观往往反映出某种文化的特质。例如
脱胎于希腊故事的“天
堂
2
”,游戏创作者经心设计了
24
章节的游戏故事背景,并以此故事为核心,发展
出所扮演的角色
、游戏的场景、人物怪兽的特质及游戏的价值观等。
WOW
这一
非常强调“
World
”
(世界感)<
/p>
的游戏,更是从整体到细节无不阐释着西方文化的二元对立:黑暗
/
光明、混乱
/
秩序、战争
/
和平、瓦解
/
重建、恶
魔
/
天神、自私
/
牺牲、贪婪
/
慷慨等。尽管
WOW
的魅力很大程度在于其战斗的节奏,但其世界设计
之宏大和剧本
设定之行云流水也是深为吸引玩家的一个因素。
国内开发的<
/p>
RPG
游戏大多数以
MMORPG
为主,故下面将以较大篇幅具体说明
MMORPG
中文案策划的内容,并
重点介绍其与单机
RPG
不同的部分。
1
.文案人员结构
< br>任何从事过专业写作的人都知道,光会写对话成就不了一本动人的小说,同样会写新闻的人不见得会写剧< /p>
本。
MMORPG
中的文案设计也是一样
,包括故事、任务、
NPC
对话、帮助、物品描述等海量内容,
需要各方
面的知识和能力。也许你会认为,只要不考虑资金预算和时间期限,那也不过是
一个人写上一两年的工作
量。但无论从效率或是经济角度而言,如果要制作一个庞大的<
/p>
MMORPG
,以上的方式显然不合理,因此我们
需要一个文案团队。
首先,项目中需要一个主文案(
Lead
Writer
)。主文案是团队中的核心人物。在一款游戏中,从头到尾保
持一致的风格是很重要的。
风格一致包括人物与背景的一致、
游戏风格定位的一致等。
故
事有不同的风格,
角色有不同的腔调,还有各种细节都必须前后一致、吻合环境,才
能让人感觉到角色栩栩如生。这一切都
依赖于主文案的功力:
让
不同人笔下的内
容体现出整体统一的风格,
< br>给玩家带来幕后只有一人操刀的感受。
主文案也是与其
它策划、其他部门之间沟通的桥梁。举例而言,当文案组要对某个任务进行修改的时候,
需要由主文案对其他各部门的负责人进行通知,否则不免出现剧情小说与任务不符等往往到产品上市才发
现的隐藏错误。
其他的文案(
Stuff
)则在主文案的指导之下将概要扩充,通力将制定的各项任务完成,
最终交于主文案定
稿。对于文案而言,最需要的能力是文字表达能力和对游戏产品特征的
了解。一般
MMORPG
中文案的个数视
游戏产品的规模限制在
1~4
人左右。
2
.游戏主调
< br>文章有主旨,游戏有主调。游戏的主调也是游戏创作者在游戏中固化的剧情部分想传达给玩家最主要的感< /p>
受。
游戏延续了好几个礼拜,带给玩家
的感受可能就只是种“愤怒”、“悲伤”、“欢乐”或“悬疑”等,以
上种种要让玩者感
受到的情绪,也正是游戏主调中重要的元
素。在单机
RPG
的游戏设计中,如前文所述,
通常会先把
要设计的世界观主调明确的定下来。然后以这个主题为出发点,所有的世界观设计都围绕着这
个主调而深
入,贯穿于整个世界观乃至整个游戏中都无时
无刻的可以感受到这一主调。
以冰风谷这款电脑游戏为例,讲
述的是一支冒险队伍接受任务,解决侵扰小镇的邪恶势力,最后终于使小
镇恢复和平的故
事。这个游戏故事的主调是什么呢?其实我
们从游戏开始时的
CG
中就能发现有一定的脉
络可循,也
就是坦帕斯大祭司杰若的象征:无私奉献的高贵情操。在整个游戏的进行中,这样的主调也一
再重复出现,
例如在库达哈的大德鲁伊,为了保护这个小
镇而奉献出自己的性命;断手塔大法师杰瑞的女
儿也为精灵与矮人的团结牺牲奉献;
p>
甚至到游戏的最后,
坦帕斯神庙的牧
p>
师也为了恢复小镇旧有的和平而
献上了生命。这诸多桥段所呈显的,
不只是一个个分别的小故事,而是以无私奉献这种高贵的情操来做整
个冒险的主调。
p>