6月1号-3号参加了完美世界举办的上海站GameJam。本场的规则是在48小时内，做出一款主题为“萌”的游戏，最后所有队伍分别演示。我们团队一共6人，我名义上是队长，实则后勤部长（笑）。队伍成员都没有实际游戏项目经验，也基本上是第一次参加GameJam。而我更是一个接触游戏引擎才一个月的新新手。我们大都抱着见见世面、膜拜大佬的心态参赛的。最后作品居然很幸运地获得了上海站前三的成绩，难以置信。
才华横溢的策划大佬，对这次游戏的设计感悟作了很好的总结：2018完美世界中国年轻一代游戏创意大赛(Game Jam组)的作品展示，愿意的来？ - 和浪的回答 - 知乎 https://www.zhihu.com/question/279712395/answer/411142801。游戏通关视频和下载链接那里都有，大家可以先移步过去看一下我们的游戏“找回春天”。
从结果上说，GameJam更注重创意和玩法，美术和程序都是表现形式。只要你能将创意表现出来，玩法实现出来。我认为有一些小bug、小瑕疵是完全可以接受的。但从过程上说，我们团队有许多做得不够好的地方。这篇文章的目的，就是谈谈整个团队48小时开发过程中的不足。只有将失误提炼成经验，我们才能成长。
第一点，开发进度控制做的不好。时间回到在6月3日早晨8点，离比赛结束还有6个小时，队员们都意识到进度控制出了问题。我们之前在关卡打磨和人物技能的优化上花费了太多时间。其中我大概花了整整12个小时，想把角色攀爬做到完好。除此之外，我们还做了一些可有可无、不必要的功能，而很多必需的组件都没来得及做，比如：角色死亡重置、关卡间摄像机变换、开头和结尾的动画等等。这意味着赛程已过去7/8，一个可玩的版本都还没有出来，每个人的压力很大。我们立马进行调整，所有的工作都按优先级排序，先做重要的。临近比赛结束，终于赶出来了第一个可玩版本。但时间有限，直到最后我们现场演示时还有一点小bug。
现在看来，我们应该采用敏捷开发模式。先做最重要最基本的组件，得到一个１.０版本。在此之上进行快速迭代，每次迭代增加一些新的功能。这样的好处是，任何时刻我们手上都有一个可玩的版本。可以随时体验、测试、提交。由此收集到的反馈信息，还可以帮助新版本进行调整。
第二点，分工不当。队伍里一共有三个程序员。比赛开始时预想的分工是：我做人物控制、另一个程序做动画部分、主程负责场景搭建和剩下的工作。这里存在不少问题，首先任务没有完全分解到个人。动画部分的编程和美术是耦合的，场景搭建与美术和策划都是耦合的。其次是任务量分配不均。我一开始以为自己只要专心人物操作，所以花了很多时间做攀爬，时间浪费了。另一个程序要等美术的动画，所以一开始只能和主程一起做旋转操作，相当于两个人做一件事，时间浪费了。主程由于要负责场景搭建，所以有很大一部分时间都在和策划一起打磨关卡的摆放和参数。到最后有很多重要的组件已经来不及做，由我们赶工顶上。分工的问题主要是由于我们经验不足，对每个人的能力，整个项目的工作量都没有很好的预估。
第三点，沟通有时候不到位。多人合作的项目中，沟通一定是极其重要的。在游戏开发中还存在跨界的沟通：美术与策划、策划与程序、美术与程序。凡是沟通，都需要特别注意。举一个比赛中的例子。队里美术大佬最初画的“夏天”关卡的背景图，与关卡初衷的感觉上有偏差，整图需要重画。原因在于美术并没有参与我们对游戏设计的讨论，所以他只能按照自己对夏天的感觉来创作。这里就是任务交付时沟通上存在问题。之后策划找到了美术以前画的沙漠风景图，让美术尽量按照这个感觉来画。最后成品的效果大家都很满意。
GameJam是大家坐在一起，有什么事情可以直接面对面交流，沟通成本已经很低了。哪怕这样沟通还是会不到位。我常常感觉到，沟通的损耗无法避免，我们所做的只能是尽量将损耗降到最低。两个人的大脑，就像机制不完全匹配的译码机和解码机。发送者用他的大脑把想法编译成文字，通过嘴发声，再经由空气传播，到另一个人的耳朵，接受者再用大脑来翻译接收到的文字。且不说环境嘈杂对声音接收的影响，光是不同人千差万别的语言习惯、各自大脑的主观思想，都能让想法在传递过程中“变味”。人与人靠说话来沟通想法，是如此的不可靠。所以在沟通重要任务时，一定要尽可能把话说完整，包括这个任务的前因后果，可能出现的场景，潜在问题等等。不要嫌麻烦，因为冗余信息能帮助对方理解你的意思。说完后，要确认对方是否真的理解。
第四点，测试不足。这几乎是必然的，因为我们基本开发到比赛最后一刻，没有时间留给测试阶段。但是哪怕我们有足够的时间，也不一定能把所有的bug找出来。我们脑子里没有一套完善的测试流程，所以很难测试覆盖到项目的整个逻辑。比赛过程中，我们想加入一个功能：当玩家超过一定时间没有进行操作，游戏角色就会发出叫声。这个功能最后只写成一个半成品：不管是否操作，角色每隔5s都会叫一下。然后因为优先级太低，就被我们舍弃，但是代码忘记删了。队伍里的所有人在试玩最后版本的时候，都没有打开电脑音量，没有发现这个半成品组件还在持续发挥着它的功能。所以最后演示时，游戏角色每5s都会刺耳地叫一下，“滴滴滴”、“滴滴滴”、“滴滴滴”…直到结束。所以一定要注重测试。
最后总结一下。“每个编程人员都是乐观主义者”——《人月神话》。我们这48小时的程序开发，基本就是反复上演这句话：“预估一个重要的功能很容易，打算最后再做，结果发现实现起来很复杂”，“第一天做好了功能，好像进度还不错，结果第二天出bug”等等。这次GameJam的经历，让我深刻意识到软件工程管理里学问很多，比我曾经设想的还要多，所以要学习的知识还有很多。
在文章末尾，我要感谢团队里的每位小伙伴。虽然开发过程中存在一些不足之处，但第一次合作能达到这样互相交流和配合，已经很不容易了。大家都热爱游戏开发、想把游戏做好，和你们一起合作是非常快乐的一件事。能认识你们，是这次比赛最大的收获。