游戏功能开发前期沟通与交流的重要性

     近期，我所在的游戏部门有重大变革，要对游戏内部进行很大调整，并且不在原有服务器上做调整，只是会新开服务器并为以前的服务器开放转服功能。对于策划各种诡异的需求先不置可否，单从功能来看，这是一个很大的工程。但是实际上策划给出的需求文档对于转服的处理流程没有任何实质性的提示，整整三页文档给程序以及测试人员的印象就是“转服”两个字。

     这种情况下，开发工作是很难开展起来的。接到任务初期，我就是找程序一起核对需求，但是发现功能展得越开，很多不确定的需求就越来越多。例如：文档设定上是将转服申请存储在角色数据库里，每个区服都是独立的，各个区服之间都不知道其他区服转出的数量，这样在转服的时候很容易导致很多老区角色转入同一个新区里，而每个区服肯定是有人数限制的，这样就会出线转服失败的情况。为此想了一个很复杂的解决方案，就是在申请转服的时候对角色进行判断并给予优先级，在转入执行过程中就将优先级高的角色先转入，最后转入失败的角色都是优先级较低的。但是这样处理会比较麻烦，而且后续处理方案以及玩家体验度都会很差。除此之外还有很多问题，开始都是单方面核对，例如测试找程序，测试找策划，或者程序找策划，很难达成共识，而且浪费了工作时间，一共核对了两天的需求，结果还是没有最终定稿。

     根据之前的经验，以及在MSUP的“测试驱动项目开发”的培训中总结出了，对于功能确定一定要召开三方会议。即：需求制定人员（策划）、程序人员和测试人员一起坐下来，确认具体的需求，并将三方会议的结果邮件发送给相关人员作为凭证，这样就能防止需求不明确导致开发人员走弯路和需求人员不断更改需求的问题。例如上述问题，在三方会议中就很快解决，解决方案为将申请总数记录在全区服的网关服务器上，而不是记录在各自的数据库里，这样各个区服就知道转入区服的一个总数了，就没有因为人数上限而导致的转服失败以及后续处理的问题。

     由此可见，在游戏制作过程中，需求的核对也非常重要。而就我现在工作的公司来看，需求基本是策划写文档，然后给开发人员测试人员看，最后口头去描述一下就进行开发与测试。对于很多细节的处理，三方都不是很明确，这样导致最终开发出来的功能可能不是策划想要的，或者是策划要的，但是由于细节不清楚导致容易出bug等弊病。

     所以，像开发网络游戏这种短期内很多小需求构成的软件工程体系里，沟通是更加必要的！