>>>  創業先鋒 眾人拾柴火焰高  >>>

簡體     傳統

游戏数据：
发行商：Microsoft Game Studios
全职核心团队：40人
全盛时期团队大小(包括测试、授权、本地化以及其他支持资源)：102人
发布日期：2003年11月
平台：Xbox
开发硬件环境: Pentium 600 MHz-2.4GHz、256-1024MB RAM、GeForce 2-4 Series、ATI Radeon 9700 Pro显卡
开发软件环境：Microsoft Visual Studio.NET、Microsoft SourceSafe、Alienbrain、built-in 3D Editor、Softimag XSI、Araxis Merge
2001、SoundForge
项目大小：37,174个文件，219,538行代码，41GB数据
开发经验
    Gotham Racing 2 是Xbox上销售业绩最好的赛车游戏的续集, 由Bizarre Creation(利物浦，英国)开发，Microsoft Game Studios提供了制作和发行方面的帮助。在2002年2月份完成了PGR的国际版本后，我们的两只团队直接启动了续集的开发。我们极大地扩展了合并后团队的规模和质量，招募了新的美工，程序员和测试员。这个项目的最终目的是在2003年假期推出一款基于PGR基本要素的AAA级游戏，并且在游戏中创新性地应用Xbox的在线游戏系统Xbox Live。最终游戏及时上市，并且在超过70个专业评论中得到了综合92.4%的高分(参考自www.gameranking.com)，我们感觉到我们达到了我们的目标。
 

    我们把成功归功于我们员工的努力和对挑战的了解。聪明、高效、努力工作的员工是达到既定目标的关键。坦率的说, 我们的两支团队都具备那些素质。虽然在战术方向我们存在一些争执，在最后阶段也做了一些改变，但团队中的每个成员对项目的战略方向十分明确并且为之努力。我们最后成功的一个关键因素就是开发商与发行商之间稳固的关系： Bizarre在设计、技术和美工的能力能够很好地与微软在测试、授权、可用性、创意写作和制作管理方面的能力匹配起来。没有相互之间的高度信任，我们将不可能去发挥每个团队的最大潜力，而PGR2也不会如
此成功。

    我们的希望是：本制作案例能够提供一些对我们如何一起工作开发PGR2的认识，比如我们做的比较成功的地方，还有我们做的不太成功的地方，如果我们有机会再做一遍这个游戏，我们将会有哪些改进。我们希望其他团队能够从这些经验教训中受益，从而改善他们的流程并且避免重犯我们的错误。

成功经验：
1、很早就确定的强烈的创新意图
    为了在PGR前作的市场成功之上更进一步，我们深知要保持并发扬前作的成功要素。我们已决定将汽车的种类从25种拓展至100种，并把城市的数量从最初的4个增加到11个。我们的艺术家投入了大量的时间去研究各个城市中的路线——那些有趣、容易辨识、并且有驾驶乐趣的路线。我们在增加汽车数量的同时，也增加了不同种类的汽车，比如老式汽车、强健型跑车、超级跑车、甚至SUV。设计者们同时增强了Kudos奖励系统，增加了对良好驾驶技巧的奖励，比如转弯时转得干净利索，干净的甩尾, 保持在跑道内部不压线（不撞墙）等。

    不过作为一个新的PGR游戏，我们知道我们更应该体现一种创新精神。虽然Xbox Live在我们最初设计游戏的时候还是一项不为人所知的技术，我们仍努力推动PGR 2的联网模式。我们预测游戏玩家会十分喜欢在网上和他们的朋友竞争赛车，因此决定为游戏中的每一次赛车提供Xbox Live排分榜。这些互动的高分排名让每个拥有Xbox Live帐号的玩家能够贴出游戏的结果，排名前十的玩家可以贴出他们游戏时的重放以供其他人下载并观看（或者作为对手进行游戏）。

    每项决定都会带来一些艰巨挑战。为了创建新的汽车和城市，我们需要将原画设计队伍扩大一倍，但同时增加了团队管理和交流的困难。

依靠外部团队还未完成的技术也使开发进程遭遇瓶颈，因为我们不得不等待其他团队完成他们的产品。然而，为了拓展整个游戏所包含的内容，我们选择接受这些挑战并不断努力。

2、精简全球管理
    Bizarre Creations团队包括我们所有的核心开发人员、美工、游戏和音效设计师，以及产品人员。位于华盛顿州雷德蒙市的微软团队，包括许多产品和设计支持人员、授权经理、 一支完整的测试队伍、以及市场推广团队。由于游戏要在全球范围内发布，我们在日本、 韩国、台湾和爱尔兰全职工作的本地化人员。我们同样在澳大利亚和英国雇佣了3D临时美工，在法国雇佣了临时翻译工。  

    在制作期间，团队成员访问了世界各地来收集研究参考材料和记录资料。我们在每个城市拍摄了上千张照片和上百小时的视频。我们在莫斯科和东京录下了真实的DJ。我们甚至去希望之地（Promised Land）作了个特别旅行，参观了位于意大利Maranello市的法拉利工厂，拍下照片并录下法拉利恩佐（Enzo）的引擎声音（在法拉利恩佐向公众开放之前）。借用一句古老的英国谚语: PGR2团队上的太阳永不落。
 

    管理这样一支全球性团队，在沟通和进度管理方面导致了很多问题。 我们解决这些问题的措施实际是减少而不是增加管理。我们在所有的团队成员中构建了强大的沟通渠道，去除了可能出现在游戏制作人级别的沟通瓶颈。微软制作支持部门的全体职员被授权可以相互之间以及与Bizarre团队的其他成员直接交流。雷德蒙的测试人员和利物浦的开发人员通过bug数据库、e-mail和电话进行直接交流。利物浦美工组和雷德蒙的授权经理紧密合作，接受汽车制造商和其他外部授权者的批准和改变需求。我们国际本地化（international localization）团队的所有
成员都直接与我们UI开发人员进行交流。

    正如大多数团队那样，在贯穿产品开发的整个过程中，我们为每个里程碑做出计划目标和需要交付的工作成果（deliverables）。不过，让我们有能力迅速解决问题并且能够赶在假期前发售的，是我们在合适的位置上有合适的人，以及我们全团队范围的开放的沟通渠道。

3、尽早验证在线游戏模式的稳定性
    对于任何游戏来说，在线多人功能经常是风险最高的区域，因为多人功能可能是最难实现的，并且需要重要的优化和调整。我们及早处理了这个问题。我们实现了大部分网络代码，针对汽车速度和轨迹的插值计算的物理优化，所有的Xbox Live功能后。这一切都是在2003年的四月，即距发布时间还有5个月的时候就完成了。这样，我们整个的多人网络游戏功能的实现是相对顺利的，到最后的代码优化阶段只有一些性能和声音方面的小问题需要解决。

    通过雇佣一个优秀的网络程序员，让他和Xbox Live团队亲密的合作去完全理解Xbox Live的新技术，并且协调我们的实现和测试过程，我们获得了很好的效果。根据Xbox认证团队的需求实现游戏中Xbox Live的主要功能集，需要立即教育我们的团队。该项投资事半功倍，使得我们在Xbox Live 2.0的一些功能，如stats with attachment（支持ghost回放的上传），没有按时完成的情况下，能够快速实现新的API来弥补。

    我们很早开始测试，找出了一些延迟和插值问题，这使得我们可以给新的Xbox Live功能纠错，诸如friends、声音和记分板等。这样做，使得开发团队能够更早的提高新功能的稳定性。

    由于在早期就验证了多人游戏的稳定性，因此我们能够消除产品计划的主要风险，并在项目的最后阶段，把我们的精力放在其他诸如游戏性、性能微调和改善上。

4、将用户反馈在产品设计中反映出来
    在巨大的时间压力下设计一个游戏，通常会导致界面设计和游戏平衡性方面的近视。由于团队在整个开发过程中距离游戏是如此近，对游戏内在的问题和可用性做出客观评估变得非常困难，如果不是不可能的话。进度需求限制了有效的迭进修改时间（iteration time），开发团队的成员也不能代表所有最终用户所拥有的不同技巧。“一个用户只会成为‘新用户’一次”的理论，认为你的每个玩家将会乐于挑战陌生的游戏界面和难度级别不均衡的关卡，并会很喜欢游戏的整体设想。

    虽然我们在处理PGR2这些挑战上取得了成功，这部分归因于在发布前的最后几个月时间里，我们还是投入了巨大的人力和迭进修改时间。

我们实实在在地花费了几百个小时手动微调每辆汽车，来平衡操作的易用性（ease of use）和驾驶的真实性。我们频繁地使用Microsoft的可用性实验室（usability lab）来得到赛车玩家的反馈，并观察了解玩家在玩我们的游戏时的最初体验，在界面浏览方面所遇到的问题，是否理解排名系统以及是否能完成每种竞赛模式的小目标。

    除了查找和修改所有的功能和内容方面的bugs以外，我们在最后阶段的最大部分精力放在了平衡我们游戏性的难度上。几乎来自利物浦和雷德蒙两只团队中的每个人（还有许多不在PGR2团队的其他人），都花费了时间提供了有关特别赛事和五个难度级别等方面的游戏平衡性反馈。

    考虑到游戏的大小，玩家的众多，和我们所担心的在积分板和Xbox Live的排分榜上暴露得分中的“黄金路径”（通过走捷径得到高分的快捷方式）, 我们为我们在微调期间通过高强度协作所取得的结果而感到高兴。

5、有效的授权管理
    追求现实世界真实性是PGR系列的一个核心优势：真实的车、真实的城市、带有真实DJ的真实广播站、来自真实乐队的真实音乐。和电影制作者不一样，游戏制作者需要得到每个商标和物品的拥有者的合同批准，才能在游戏中使用它们的影像。

    11个城市（包括一个真实的赛道），超过100辆车，33个广播站每个都有自己唯一的DJ，超过300首歌，这个工作量是难以想象的。 我们雇佣了由5个授权经理组成的团队，在整个项目过程中全权负责这项任务，包括建立和维护与所有相关合作方的关系，帮助审核所有游戏中的资产，并且和律师一起合作来签署下每个合同。

    授权团队的贡献是至关重要的。他们不仅仅使得我们的美工可以真实的再现每个城市，而且还获得了相关的授权。没有他们的话，我们将不能在PGR2中表现诸如法拉利、保时捷和宝马等真实的车辆。
 

惨痛教训

1、在全球范围同步协调工作成果

    如前所述，管理协调我们在全世界各地的团队的工作成果是一个很大的挑战。我们觉得这个过程总体来说运行良好。但是，如果任何巨大的挑战一样，制作过程的核心部分总会有一些主要的问题突出出来。

    我们原来计划通过分配工作给各团队来利用我们的全球资源，对全球汽车名录上的各种车的基本数据进行收录、处理和实现。但最后这么做发现得不偿失。因为车的记录规格没有统一，而且很多的车的数据很晚才拿到，我们不得不牺牲了游戏中每辆车的实现和调整的时间。

另外，音效设计小组的一个重要的成员在搬到加利福尼亚后，还试图兼职工作，这更加搞乱了已经很薄弱的工作流程。相关问题也发生在DJ脚本方面。我们在各个城市录制DJ，但冗长的合同和录音计划影响了我们的工作。

    这个失败给我们上了两课。首先，我们将来需要更好的协调内容创建（content creation）和执行。第二，所有和微软合作的游戏开发团队都要面临的一个挑战是：协调开发团队和测试团队。

    虽然所有Bizarre的程序员、美工和设计师，和微软雷德蒙德的测试人员、授权经理和国际本地化团队，都是使用一个bug数据库实时工作，我们还是遇到了一些问题。在4GB的传输速度下，传输builds的时间是漫长的，我们不得不在发布之前三个月改变文件传输工具。在雷德蒙发现的一些明显的错误很难在利物浦重现，因为测试的build版本落后于开发之后至少一整天的时间。

两个团队之间5,000英里的距离更增加了在项目最终阶段任何文件更改所带来的风险。

    虽然我们在更好的协调开发和测试方面迈进了很大一步，但我们将：（1）在功能性和内容的最终期限前更有效地完成任务（2）增强build流程的稳定性（3）在build发送到雷德蒙测试组之前，在利物浦的测试做得更周密些。

2、设计花费的时间太长了

    在我们整个项目的执行过程中，不完整的设计对各项工作的按时完成产生极为消极影响。虽然我们都理解和同意对于PGR系列游戏的总体设想，我们很晚才开始编写PGR2设计文档，而且我们在功能冻结（feature freeze）和E3展之后，因为新的想法出现成形，仍然在更新这个文档。最后导致我们几次大规模调整设计要素，象用户界面、Kudos奖励评价、甚至整个游戏的结构。

    很多重要的原因导致我们的设计阶段被延长。我们的设计工作在早期摊得太开太浅，在具体计划实施之前我们妄图追求太多不同的路径和游戏模式。在2003年初，Martyn Chudley，PGR系列游戏之父和Bizarre Creations公司的领导，不得不进场干预，为精简游戏设计的规模起到非常重要的作用。

    反复调整修改每一个车辆的驾驶特性是一个超乎寻常的挑战，而且在项目计划时间表（schedule）中很晚才完成。对任何一款仿真赛车游戏来说，每一个车辆驾驶特性的任何改变都在可用性、AI的性能、每辆车的等级和竞争分类、和设定每次竞赛的难度级别等方面都有重大影响。   

    从PGR到PGR2车辆的数量翻了四倍，而我们调整的时间绝对比前作超过四倍。因为更多的车型和内容，需要我们更加努力，进行测试，和在个体车型和类型之间调整。我们低估了这项工作的难度。

    为了解决这些问题，我们扩充了测试团队的规模，从另外的项目调入了额外的设计师，而且雇佣了一支小团队来专门负责游戏配平的任务。在将来的项目中，我们将采用其它的解决方案，比如在早期就充实设计文档的关键部分，离线编译新的游戏性原型，提前安排游戏平衡工作。迭进修改是一个游戏开发的自然组成部分，而且我们对于结果是基本满意的，但是达到最好的效果却不是一件容易的事情。

3、依赖外部团队的新技术

    PGR2的设计是要求在游戏里的方方面面都具有完整的在线特性。这些特性需要的API函数仍然由Xbox Live小组开发中，这影响了我们项目的进展，使我们的开发遇到许多严重的障碍和时间上的约束。

    我们的计分牌是曾在2002年的Xbox Live初心会上展示的MotoGP演示版中所用系统的扩展。比之其它游戏，我们前所未有地应用和扩展了这套系统。加上新的Xbox Live功能，比如带附件的统计（如ghost），和我们预期的大量在线用户，我们知道我们做了一个很大的赌博，要把这些刚刚问世的技术变得稳定而且可用。如果任何一块有问题，系统就会崩溃。作为这个领域的先行者，为上传下载幽灵所编制的附件API（attachment API）带给了我们很多无法预知的问题。Xbox ATG团队给予了我们极大的支持，但是他们也很艰难，需要在期限内完成自己的任

务。

    举例来说，我们应该避免的一个问题就是优化我们和在线记分牌的互动。根据在项目后期对Xbox Live的研究，他们发现我们的代码对他们的记分牌服务器访问过于频繁，整个容量的问题在正式版发售后服务器将无法应付。虽然我们修复了这个问题，但还是对这个重大的制作问题感到后怕。

    依赖外部团队的关键技术，我们深刻体会到要在计划中给不可预料的问题分配足够的缓冲时间（buffer）的重要性，要让所有的部门之间保持交流的畅通，以及对技术要有深层次的理解。

4、ghost回放系统的稳定性

    为了支持全世界各地的Xbox Live用户能够上传ghost 回放文件，我们必须能够保证每个ghost是实际赛车结果的一份真实复制品。本功能的重要性使得我们从测试组那里得到了足够的重视。

    回放子系统作为记录ghost数据的底层框架使用。该遗留系统的长期调试是复杂和艰难的。距离验证发布（RTC, release to certification）前两天的一个深夜，我们的测试人员正沉浸于火热的竞赛中，在几个小时的arcade cone竞赛中挑战各自的高分ghost。

    当时某项记录变得很难被打破，某位测试人员注意到在ghost回放中出现的整个Kudos分数并不匹配积分榜上的值。尽管连续几个月的不间断测试，但该游戏在装货前仅仅几个小时，仍然在回放系统上出现了非常严重的一个bug。

    竞赛游戏模式在最后阶段是测试过程中非常有价值的部分，因为这也是玩家将会如何玩我们的游戏！虽然我们修正了这个bug，但是我们本应该更早一点发现这个bug。在将来, 我们将为重要的领域进行自动测试，包括编写特殊测试脚本的hooks、边界和压力条件。我们永远也不能很完美的模拟出上百万玩家的游戏体验，但通过区分我们关注的事物的优先次序，扩展我们的自动操作套件，并且在最后阶段扩大主要内部团队“清扫bug”努力的规模和范围，我们将能在发布前更好的寻找和修正所有的重量级bug。

5、构建流程和源码控制

    在Bizarre Creations的内容创建（content creation）阶段，我们有海量的资源需要管理，包括100多辆车的3D模型，物理动态和驾驶数据文件，11个不断演化的城市模型，8000多个音频内容文件。这导致了项目后期的极端混乱，因为我们最初计划的流程并没有考虑如何管理海量代码和内容。在项目的起始阶段，我们有多个团队上传到一个游戏镜像。这导致了在构建build阶段严重的内容不相容问题，例如汽车使用了不正确的引擎音频、城市马路没有路边障碍、以及把旧内容当成新的回写的后旧bug再次重现。我们计划解决这个问题的方法是：把原始的游戏镜像分割成独立的镜像，其中分为城市数据、音频和无线电内容、汽车内容和所有的源代码。在游戏发布给雷德蒙的测试组前, 我们同样计划创建唯一的测试镜像，这个镜像则包括了所有的内容。

    不过，按照这种方法来分割流程，弊大于利。在最后阶段，由于Bizarre团队每隔几天就要构建一次build，因此测试镜像得要经常手动更新。为了确保一致性和速度，团队创建了按部就班的流程和一组批处理文件，这些文件每次按照特定的顺序运行。由于游戏是如此大，服务器空间捉襟见肘，使得我们不能使用Alienbrain或者其他文件管理包。我们不得不专门指派一个人用手动拖放来创建测试镜像。

    当构建build过程开始花费更长时间时，厄运也开始袭来了。每个人工作很多小时，在build冒烟测试（smoke test）后才check-in自己的部件，添加额外的步骤用来管理多个游戏镜像的资源获取，所有这些导致构建build过程变得很复杂。测试镜像经常被收集在一起并放到安全的FTP站点，而雷德蒙的测试组第二天早晨往往发现build无法运行，这就损失了一整天的测试时间。

注解：

    关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说冒烟测试就是在每日build建立后对系统的基本功能进行简单的测试，这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。

    至于冒烟测试这个名称的来历，大概是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。
  
    在开发游戏上，Bizarre团队将会坚持使用两个游戏镜像：一个用来提交所有的代码和内容，另一个用来存贮所有测试完毕、可提交的内容。在减少改动部分的前提下，我们期望该流程能够在未来的项目上使用得更平稳。

最后总结：

    最后，我们都对我们在PGR 2中的取得的成绩感到骄傲，而且我们希望玩家也同样如此。作为一个团队，我们按照我们的预先设想和优先级别成功完成了这个游戏。我们在保持PGR游戏的传统核心和引入如线上多人游戏和记分系统中等创新内容之间找到一个平衡。另外，我们也做到了准时把游戏献给玩家。

    当然，没有哪个项目是完美的。并且我们也有很多障碍要去克服，很多是我们自己的问题。在PGR和PGR 2之间有Bizarre Creations和Microsoft Game Studios的队伍成长壮大。我们的挑战在于我们要在未来继续成长，要一同工作，并且要克服出现的困难。

    回顾昨天，我们成功的关键在于将游戏融入于生活中。PGR 2是由一群努力工作并且效率高的人所开发的——他们之间有相互的高度信任感、开放的沟通渠道、并且有一个清晰的远景和目标。空谈总是简单的，执行才是关键，而且在可预见的将来都是这样。

网载 2011-03-03 01:36:01