BOOM开发回顾：首次尝试，我如何用一个月的下班时间独自开发完游戏作品

本文系用户投稿，不代表机核网观点
故事的开始：
大概在去年底的时候，因为各种各样原因，我决定尝试一遍开发游戏。促使我开始的原因有很多，其中包括在去年底，从网上各种消息来看AI编程似乎到了一个比较能成熟应用的阶段，对于那时不掌握代码能力的我来说，似乎起步门槛终于降到了一个对我比较舒服的状态，我可以踏出这一步了。
首个游戏的尝试大约于4月初结束，实际开发只是一小部分，中间经历了不少事情，包括学习专业的游戏策划工作知识，进行AI编程可行性测试，引擎选择与学习（最后选了Godot），以及发现代码还是得学之后对代码知识的补课等等。上个项目一结束，我就开始思考接下来的安排，在为完善前一个项目而补习各种进阶知识的过程中，我就逐渐积累了下一个项目的想法，刚好在那几天看到了机核新一届BOOM正在报名的消息，没做太多考虑，我就决定参加比赛，接着进行第二个游戏的开发。
我在B站的同名账号有关于这两个项目的视频，这里就不宣传了。本次文章就讲述最近一个月，我是如何利用下班时间独自完成一款完整的BOOM参赛游戏作品的。
其实我一开始没有打算独自开发，因为前一个项目的尝试真的搞得我有些头大，而且我觉得我之前有点孤僻，GameJam比赛还是应该找人组队，合作完成。于是我在机核发了招募信息：

但最后有两个原因导致我还是一个人开发，一个是我发布信息时报名只剩几天截止了，确实很难找到合适的伙伴。
第二个更重要的原因是，为了节省时间，发布那几天我同时开始完成游戏设计文档和界面框架搭建，几乎只用了两三天时间，整个游戏的模样就已经被完整确定了。这说明这个游戏在我心中已经非常明确，我只差把它做出来。这种情况下，我一个人开发，反而会减少中间可能的冗余讨论，让这个游戏百分百是自己想要的样子。所以最终，虽然知道又要继续熬一个月的夜，但为了成品的统一性，我还是决定自己完成开发。

起步，数倍压缩的时间规划：
接下了这个大活，马上就要面临最大的现实问题：工作量。
给大家说一下这游戏（当时）的内容量：游戏是一款类自走棋游戏，有4大阵营，6大职业，24个兵种，每个兵种有各自不同的能力，再加4个阵营能力和6个职业羁绊，然后还有11个宝物（装备），以及合成系统（三合一合成更高星级兵种），英雄系统（初始从3个英雄中选一个），商店系统（随等级越来越强大），远征队系统（管理你的队伍），以及与比赛主题有关的奉献系统等等，我只有一个月时间，既要完成游戏设计，又要完成美术资源，又要实际把它们开发出来。 
以上一个项目我的开发速度来比对，我差不多要提速六倍才能完成。
我当然不能用这个速度往后推去规划安排，我必须倒推时间节点，把每个阶段的进度卡死。大致的时间规划是，从4月7号开始，最后用三四天把开发前的所有工作完成（如DEMO版本的所有美术资源导出，包括正式命名等），进入开发后，用一周完成除能力系统外所有功能的开发，第二周开始实现能力系统和正式实现所有能力，务必保证在5月之前把能力开发完，这样最后4天我才能用来替换美术资源，修bug，调数值和增加音频资源。想要游戏能实现，这个进度绝不可往后推一天。
当然，我现在能发文章，肯定说明最后完成了，而且事实上最后差不多是7倍到8倍提速，我原本预估24个兵种能力以我过去的速度差不多要预留十天时间，实际最后只用了五天，因此我额外还增加了1个职业，4个兵种，开发了难度系统等等功能。

实战，AI编程高效提速三大法则：
4月12号，前置准备工作全部完成，我再次打开Godot进入开发阶段。为了真正吞下这大量的工作量，我几乎每天都在思考如何提效，最后化成了各种各样的小技巧，这里我总结了我认为最重要的三个改进。
1.事无巨细的文档记录跟进
这几乎相当于为AI外接大脑。
在开发上个项目时，对于当时完全没有开发经验的我，为了最后真能把游戏开发出来，而不是中途翻车无力回天，我进行了一些思考。我的应对方法是，在正式开发前，把我对于后续功能实现中没有把握的部分，一一先与AI进行对话，让它给出一个讨论后比较合理的方案，然后统一记录在一个“技术文档”里。在正式开发前，把我的游戏设计文档和技术方案文档都投喂给了AI，让它快速对接下来要实现的项目有一个基本了解。
这个习惯后来延续到了这个项目中。

但这还不够，随着功能的正式实现，实际脚本中每个功能的实现方法，函数和变量的名称，会逐渐和技术文档里预设的不一样，此后再给AI看原本的技术文档，不仅没有用，甚至很容易起到误导效果。
于是这一次，我的改进方式是，每次完成了一个重要新功能后，我就让AI自己新建一个文档，把刚刚实现的整个功能的运作流程和要点总结进去，于是这一次，我多了这么多文档。

这样做的好处是：
1.写文档本身就是AI的天然长项，这工作对它来说很高效也没有出错空间。
2.AI同时也习惯于阅读文档，更不用说以它自己熟悉的标准格式写下的文档。
3.趁AI刚刚开发完功能时让它做总结，是它对功能最熟悉最有记忆的时候，写出来的文档含金量也最高，几乎不用担心有幻觉在其中或有重要遗漏。
用过Cursor的朋友都知道，每次新建一个对话框，其实就是一个全新的AI，它不是你的老朋友，没有之前你和其它AI讨论过的任何记忆。你想仅靠对话让新朋友跟上你当前的思维进度，可能需要非常多次的对谈，中间还要保证它不走歪。有了文档记录之后，每次继续完善一个功能时，我就把相关的文档直接扔给AI，让AI瞬间装载前世记忆。就这一个改进，帮我省下了大量的时间。

28个兵种的职业能力文档最后记录了有5000多行，没有这个文档随时进行快速回顾，我必定会在这里栽上很多跟头。

2.重点严控框架的搭建
一句话，在AI搭建框架时多花一小时监督，可以在未来帮你节省十天收拾烂摊子的时间。
因为AI的无记忆，AI编程容易造成的另一个问题是，每次你给它一个要求，它给你的实现方案都有可能是不一样的。有时是完全不同的实现，有时看似相近但对后续工作量影响天差地别，这倒不一定是问题，问题是你必须要做那个决策的人，你的决策质量最终决定了项目的整体质量。
这也是我意识到代码知识还是得补的地方。
给了你那么多种方案，你有没有能力判断哪一种是对当前项目最合适的？亦或应该有更合适的方案，但因为缺少信息提供所以AI没有给到你？另一个重要问题是，当你真正确定方案后，你有没有办法监督AI，保证后续开发的持续统一？
我在前一个项目吃了这个问题的亏，当我还没意识到这个问题时，在和AI讨论一个功能时，每次都以为它默认给出的方案看起来像模像样的，应该是正确的，就让它执行。结果一个很简单的功能，最后越写越多，用了一千多行代码才实现，可想而知，这里面有多少不必要的冗余，缝合了多少种不必同时共存的方法，以及未来要再进行任何一点小修补时，AI有多大可能因为忽略掉某个小地方而出错。
所以这一次，每次要开始进入一个新系统的实现时，都是我精神最专注，看代码最认真的时候，绝不急于让AI马上开始实现脚本，务必讨论到觉得自己挑不出任何毛病来后才让AI去执行。且和第一点一样，在测试完功能确实实现之后，马上让AI撰写文档总结。同时很重要的，你自己必须真正理解功能的实现方式，将其内化于心。

还记得前面说的预估十天的功能只用了五天完成吗，这就是框架健壮的功劳。

3.巧妙地化解和避开难题与死结
这一点比较玄妙，因为很多时候，不到问题真的解决不了，你不会意识到这个问题竟然是个难题，你总会觉得AI下次给出的修改方案就能把问题解决了。所以这需要一些经验，当你体感当前这个问题已经花了AI一个小时，反复尝试也没有解决，甚至更直接点，AI已经开始反复说胡话时，你就可以收拾收拾，做好整理工作，回退版本去了。
回退完版本后，下一次重新出发时，因为知道了这个问题很难解决，你可以在一开始就要求AI给出一个最简单最小改动的补丁方案，或者不再撞南墙，完全转换思路用一种“面子工程”去实现一个效果。毕竟这是GameJam作品，有时确实不用那么在意代码的优雅度。
实际开发中我有好几次遇上这样的情况，一个功能给了AI一个多小时也没有实现，而且眼看着代码差不多已经被AI改废了。我冷漠地回退到修改前的版本，让AI用最简单的方式去实现，结果AI只执行一次就实现了我的要求。
这里举一个例子，比赛截止前最后一天，我打算导出一个可以在线试玩的Web版本，但导出后的版本死活没有任何声音。我一开始大意了，觉得这种导出问题应该能很快解决，就是改几处代码的问题。结果，后面花了几个小时，用尽各种办法去调试，AI依然找不出问题所在，我明显感觉到这是一个典型的超出当前AI解决能力的问题。
此时已经来到深夜，离截止时间只剩一个多小时，我知道只能进行一些妥协了。我心想，算了，别的不说了，你至少让我进入游戏后能循环播放BGM总可以吧？于是我就想到，既然是Web版本，能不能不用Godot自己的音频机制，就用Web端的方式去播放音频？我把这个思路告诉了AI，没想到只一次尝试，就真的成功了，我终于听到了第一声声音。
于是我接着想，既然这个思路是可行的，那我可不可以让所有音频的播放都绕过Godot，只监听Godot发出的信号，然后全部用web的方式去播放音频？我把这个思路告诉AI，AI也认为可行，于是我让它继续给出完整方案，最终前后只用了十几分钟，我就实现了一个完全绕开Godot音频机制的独立音频播放方案，解决了问题，顺利提交了作品。

我相信随着AI的进步，也许未来某天当我遇到类似问题时，AI能直接给我提供这种方案。但在当前，还有很多类似的情况，需要靠一些“人类的经验和直觉”，去让AI实现一些它永远不会自己产出的解决方案。

补充：美术的把控
这部分其实没有什么新鲜的，因为工作量庞大，这次的角色部分我先用了MJ产出最初的资源，但是无论怎么收束关键词，产出资源的美术风格始终会各有不同，需要后期进行一次专门修整把控，统一所有角色的风格，包括头身比，刻画风格，配色，重心等等。给大家看几个修改例子就明白了。

结尾：人生中充实的一个月
今年以来比较喜欢的一个词叫“着力即差”。开发上一个项目时，明明已经给自己定了一个很简单的游戏，还是在开发过程中遇上了大量预想以外的问题，导致不仅实际开发过程折磨自己，最后的结果也没看出有什么亮点。
也因为有了上个项目的实践，我才能在这个项目开始之前就调整好自己的心态，多多将脑力用在那些决定性的，真正重要的节点上，也因此才能实现如此大幅的效率提升。同时改变的不仅是效率，还有这个月的心态，整个月中我每天都是按部就班地进行开发，很少有真的觉得压力过大的情况。事后回想起来，只觉得是过了很充实的一个月，很踏实地完成了一件事情。
最后，当然还是欢迎大家来直接体验我的游戏，文章着重讲述了开发过程和项目管理，没怎么聊设计理念，当你实际体验过游戏后，还会感受到我在游戏设计层面的另外的思考。欢迎大家多多与我交流，或者在机组发布你的试玩感受，只要看到了我都会回复，谢谢大家~