摘要：最近跟行业朋友们聊，发现一个有趣的点，很多团队，甚至是很大的团队，都忽略了一个很基本的能力，就是工程能力。也许是很多团队没有工程的意识，也许很多大公司团队并不在意（钱多人多），游戏就是一个复杂软件工程，如何高效地把这个工程实现出来，是一门不简单的学问，是团队能
作者：余田 首发“鱼塘游戏制作工坊”公众号
最近跟行业朋友们聊，发现一个有趣的点，很多团队，甚至是很大的团队，都忽略了一个很基本的能力，就是工程能力。也许是很多团队没有工程的意识，也许很多大公司团队并不在意（钱多人多），游戏就是一个复杂软件工程，如何高效地把这个工程实现出来，是一门不简单的学问，是团队能力的基础标杆，是一个游戏水下的冰山。包括我们团队，也是自己摸爬滚打，也踩了很多工程上的坑，才逐渐具备还算高效的落地能力。本篇文章，不敢说分享，只是基于自己的浅薄理解，总结一些经验教训，记录下来提醒自己，也抛砖引玉，希望大家看时多多评论指教，斧正我的错误认知，让我可以迭代自己，感激不尽。一、一切的起点大方向的变动，摇摆，导致的返工，重做，比任何东西都拖延进度，且打击士气。做好这一点没有捷径，就是得项目负责人/制作人想清楚。最重要的是立项，大多数项目的立项过于草率，之前项目用了接近三个月立项，各种原型进行验证，砍掉了无数选型，不断推敲，最后才定下核心玩法。现在看来，还是不够，当时隐隐也有感觉，有些细节没有完全推敲到满意，然后结果就是，这些细节都在未来让我们花了至少10倍以上的代价去解决，具体可以参考之前的设计复盘。立项如果能多花一天时间，多想清楚一分，多验证一点，后面省下的时间可能是10天，100天，也可能是成与败之分。有朋友问如何避免另一个极端，在立项时长期过度打磨，怎么样才算思考清楚？首先我定义的立项，是核心玩法的立项，这个阶段最少只需要一个设计师，如果没有程序经验，最多再加一位程序员。这个核心机制的立项阶段，我还没见过哪个团队有耐心做的足够久的，远谈不上过度打磨。绝大多数情况，反而是跳过了这个阶段，直接拍脑袋一个想法就拉起团队开始搞了，或者做了大半年，美术资产一堆，核心玩法还没想清楚。怎样算思考清楚，核心意图明确，推出不变的定点，定点作为评分依据，进行理性客观的评分，设定一个阈值，超过阈值后，一定时间内没有更好的方案，就停手。其实在长时间的思考推演下，会有明显的感知，就是已经是短期内最优解，不太可能有质变的提升空间，这时候，就可以往下一步推进了。关于立项，不再赘述，是另外一个大话题。立项的审慎，换来一个值得笃定坚持的方向，这是一切的起点。二、什么时候做什么事情（仅代表我们类型的项目）知道什么时候应该做什么，是做过0-1后的宝贵经验。有了全局的视角，能帮助新的项目更好推进，快了慢了，什么时候该做什么不该做什么，做到心中有数。前期验证期不要纠结UI，但要验证交互方案。不要在美术上纠结细节，但要定好美术标准。不要纠结世界观文案氛围之类的，核心机制和实现可行性的验证才是验证期的基石。中期切片期验证美术风格，世界观，做成品品质切片版本，用作以美术相关管线为核心的流程定标。这个阶段，可以适当进行一些打磨工作，利用免费测来试探短期留存上限。后期推进期验证通过后，全力推进铺量，经过合理的验证期，大方向不能也不会去大改，这时候就是士气，效率为王，可以不断改的是，管线流程润色微调，周边系统的验证迭代。最后打磨期首先控制自己加功能的小手，大部分功能，上线后加也没有任何区别。至少预留两个月作为打磨期，一切以稳定性和提升细节为主。应做好内容量预留，上线后三个月-半年的内容量最佳。三、小步快跑，敏捷开发以迭代为核心，每周一个冲刺，1-2个月见一次玩家，作为一个里程碑，不停做目的清晰的验证，并提升士气，凝聚团队。并且，利用里程碑控制进度，防止微小的延迟被累积，里程碑的本质是一段足够长的时间缓冲器，用于将微小任务分配的不确定性中和。尊重里程碑节点，合理的规划时间，估时留好预留时间应急，修bug等，延期比加班更损害团队，因为这会让团队逐渐变得不尊重节点。另外，很值得反思的是：是在小步快跑还是布朗运动？或者说是在迭代还是乱改？想清楚的是迭代，没想清楚的是乱改。举例，测试前，目的是看玩家在游玩A功能时的某某行为参数，设计上认为参数最有可能的表现是X，结果符合预期，应该怎么继续前进。但结果也有可能是Y，如果是Y，应该怎么优化。这就是迭代。测试前，摇摆不定，没想清楚，感觉这个方案A更好，测测试试。测了结果也不知道是为什么，那改成方案B测测试试，“测试测试，不就是测测试试嘛”，这就是乱改。四、快就是慢，债都要还警惕技术债，设计债。这是来自软件工程的经典描述，指的是为了短期方便快速做的临时操作，在未来爆发出问题，结果付出更多代价去解决问题，就像还之前欠下的债。经典技术债：“先写死吧”，“时间不够先临时实现一下”，“打个补丁处理一下，先保证不出错”。经典设计债，“先这样设计，玩家小概率才会体验到，问题不大”，“这个游戏成绩好，也有这个系统，照着来吧，又快风险又低”，“还没想清楚，但先这样试试吧”。那应该如何做？1.可配置一切都可配置，警惕代码写死。2.基建优先基建功能，自动打包，热更等功能，一定越早做越好，整体上省时间。3.重视QA重视QA，用例规范，开需求会。排期时，至少四分之一的时间应该排给测试QA。重视回归测试。4.避免临时需求尽量避免为了当前测试节点，老板要求等等，做一些临时需求，应以长远更高效为先。5.多问工程问题三问这个功能目的是什么，是否有实现性价比更高的替代方案？怎么拓展，如果要改动这个功能，是否好改，是否需要程序，能否策划改配置就能改？该功能是一个稳定的功能吗，万一未来要删掉，是否好删，是否会影响其他功能？等等。。五、沟通人月神话大家都知道，本质上是随着人数提升，协作成本上升速度远超人力产出上升速度。在没有合理的管理方法时，理想状态下，前者指数上升，后者线性上升，因此实际产出是一个对数曲线，边际效用快速递减。实际状态下，前者不是单纯的指数，而是有多个质变点的，后者也不完全是线性增长。以程序来说，成本最高的是沟通成本，其次是设计成本，最后才是编码实现成本。因此，程序进度，是最符合《人月神话》中提到的Brooks 法则：向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）总结来说就是：因为协作成本的存在，加人不能解决问题，反而应该找准质变点，一般质变点就是从一层管理变成两层，两层变三层这些节点。在这些质变点加人就该收手了，先提升团队管理水平更优。那怎么解决呢？沟通成本最高的就是程序，还是以程序为例：1.任务分解最好的分任务的方式，是将功能点逻辑划分合理，然后将其分配到一个前端一个后端能做的颗粒度，减少沟通成本。或者将两个系统间的输入输出端口规划好，互为黑盒，无需关注对方具体实现。另外，尽量了解程序，最好有一定编程经验，维护统一规则文档，作为沟通的桥梁之一。最好了解架构师做的事情，对于设计整个工程结构有所了解后，自然能更合理的分配任务。2.拓展性考虑到未来可能的变化，越通用，越底层的实现方式，拓展性越强。实现的时候要注意拓展性，更重要的是提出方案时要注意拓展性。3.文档化沟通问题，文档化，不要口头需求。不要私聊要群聊保障信息同步。文档留痕，减少battle成本，但不要用文档来做追责，找问题分析问题，而不是追责。多用checklist，摒除项目中一切需要人记忆的部分。4.传递设计意图程序彻底了解设计意图很关键，实现起来更明确有动力，也会主动补完一些细节。很偶尔的，程序还会在实现过程中，会发现违反设计意图的点，这往往很有价值，因为有些东西实现和设计相差很大，可以发现一些隐藏的问题。5.明确灵活处理的空间只有一个标准，设计目的，以此为前提，明确什么是能妥协变通的，什么是不能妥协必须实现的？6.分支管理做好分支管理也是沟通的重要一环，要保证协作的顺畅，必须把分支管理做好。每个功能新拉分支，分支命名清晰，不能偷懒。等等。。六、士气团队的士气很大程度上决定了团队效率，理想的士气就是每个人都对项目充满热情，愿意主动做更多，去思考更多，对项目有主人翁意识。怎么维护士气，点燃士气？1.里程碑尊重节点，按期完成里程碑，本身就会增长士气，就如前文所说：延期比加班更损害士气。2.利用迭代成果迭代开发的成果是一种增强士气的利器，数据好就不说了，即使数据暂时不是很好，只要明确方向是对的，只要做的东西可以打动自己，那一定会有玩家喜欢。某些玩家彻夜畅玩，某些玩家发了长帖，做了啥UGC的内容，这些都可以去告诉团队，让团队伙伴感受到做的东西是有人喜欢的，值得为自己的游戏骄傲，大家在翘首以盼等着我们更新。这样大家自然士气更高。3.主观能动性分布任务时，强调模块的重要性，每个模块都有其意义，就是其设计目的，放大这个意义即可。小技巧，这个意义往往是说为什么要这个系统，可以反过来说，如果没有这个模块，我们将损失什么，往往更能传递其重要性。4.权责明确控制自身越权管理的欲望，权责明确，充分授权，疑人不用用人不疑。除了设计案，减少细节微操。5.高效氛围管理所有人工作时完全专注，不能允许做任何其他事情，来影响高效专注的氛围，工作时长上尽量想办法缩短。这点不能有任何妥协，避免滑坡效应。6.强力团队建立外科手术式的团队，只招优秀的人，和优秀的人共事本身就在提升士气。7.最最重要的！做自己喜欢，擅长，认可的事。负责人的状态会很大程度的影响团队，自己有没有想清楚，喜不喜欢，认不认同自己的游戏，大家其实很容易能感受出来，做对的事情的状态，那种辛苦却充满激情的状态，大家都能感受到，并且被带动起来。总结：工程能力是一个大话题，篇幅有限，这里只是简单记录总结一下，抛砖引玉，希望大家多多斧正。道阻且长，不断进步！来源：吉吉游戏玩
免责声明：本站系转载，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与本站联系，我们将在第一时间删除内容!