我参加了机核这次为期一周mini Jam，这是我第一次以单人的身份参加游戏Jam活动，以下是这次游戏开发经历的总结。
一、前提和初衷
前提1：我在学生时代学过用Flash做游戏，大学的时候用Unity和Cocos2D做过半成品的小游戏，毕业后学了一些前端JS，之后一直在从事动画方面的工作，算是有一些美术能力和编程能力，但都不多，也完全没有真正职业游戏开发的经验。
前提2：我以前曾经和朋友一起参加过几次LudumDare和别的GameJam活动，对于短期高强度游戏开发这件事算是有一些经验，尤其知道限制游戏规模和遵守时间流程的重要性。
前提3：在之前和朋友合作的Jam里，我都是负责美术和一部分的玩法策划的工作，几乎没有接触过程序的部分，而且之前几次用的都是我那个大神朋友自己写的引擎，在程序方面可以说完全帮不上忙（插不上手），也因为是他自研的引擎，我始终缺少究竟能把游戏设计到什么程度的认识（这一点其实挺重要的），直到最后一次我们才换成了Godot3.5，那一次也是我们完成度最高的一次，但我依旧只是负责美术的工作。
前提4：我上半年刚刚完成了一个长期的个人外包，长时间精神紧绷的状态在七月份彻底松弛，导致作息完全颠倒，画外包时虽然很累，但反而被迫过得很有规律，因此我觉得自己需要一个新的节点，比如这次的Jam。
初衷1：我想通过这次Jam更深入地了解游戏开发的程序部分的工作，同时把之前落下的引擎使用的学习也捡起来。
初衷2：我想看看自己是否能够独立制作一款游戏。
初衷3：我想通过开发游戏找回一些生活的动力，用老白的话说：重新体会劳动的价值，从被资本异化的生存状态里走出来。
那么，2023年8月19日周六上午，题目公开。游戏开始。
二、设计规划
题目公开之后，我大概花了半天时间构思，这里有一个单人开发游戏的经验：
单人开发游戏和多人开发游戏的一个明显不同就是沟通。多人开发的时候，沟通会对开发效率和思维广度有很大影响，这影响既有正面也有负面。而单人则完全不同，你在整理流程和延展思维上不会有任何帮助和干扰，这导致你需要有自己的信息收集和行为约束的实体，说人话就是有想法一定要写出来或者画下来，想安排流程也一定要做看得见的时间表和待办项，不然一旦你一个阶段的工作结束，你就会立刻陷入“我接下来要做什么”的无助中，毕竟自己和自己的对话是不会有聊天记录的。
我刚开始就吃了这个亏，导致我明明半天就想好了大概的游戏玩法，却在混乱的自我头脑风暴中又多浪费了一天的时间，直到第一个周末的最后一个下午才开始做可行性验证。
好在我有把自己的想法在纸上画下来的习惯，这让我不至于把一整周的时间都浪费在和自己的头脑风暴里。
虽然我当时觉得自己设计的玩法不是很有趣，但根据初衷2，我还决定立刻进入游戏开发，即使做出来的游戏不好玩，也一定要完整地做一个游戏出来。
最终我的规划如下：
做一个简单的小规模休闲游戏，有很轻度的解密元素，或许玩起来不是很有趣，但必须是一个好理解，好上手且有开始和结束画面的游戏，美术素材可以简单但必须完整统一。
此时是8月20日周日下午，开发正式开始。
三、开发
首先是可行性验证和玩法验证。这一步我花了大约半个周日和一个周一晚上（进入工作日后我只有下班后才能继续开发）
游戏的核心玩法相当于一个画图软件里常见的套索工具模拟器，所以我首先要设计出套索的各种核心交互，包括记录鼠标轨迹，自动封口，检测图案是否被完全包围等等，然后在引擎里验证它们的可行性，顺便再看这样是否好玩（虽然我一直让自己不去纠结好不好玩）。
对了，我用的引擎是Godot4.1，这是在我那个写引擎的朋友的建议下选择的，我之前完全没有用过Godot写程序。但现在的我可以很明确地说，Godot和它官方的GDScript语言，是非常适合新人和小团队开发的，无论是上手难度还是开发速度，目前4.1版本的Godot都很适合不要求具体游戏类型的独立开发者。
而且官方编辑器还自带非常详细的文档，这让我可以边学边做地进行开发，检查器里还自带英文属性的中文翻译，可以说对新手来说非常友好了。
当然作为体量比Unity小得多的引擎，它也有它的不足，比如我在开发中就遇到了一些感觉理应是引擎自带的函数和工具意外地缺失以至于要自己造轮子的尴尬处境，不过总的来说Godot依然是很好用的引擎。
完成了玩法验证后，我开始进入游戏关卡框架的搭建，这一步用时是从周二到周三的两个晚上。
从这里开始，我之前提到的独立开发游戏时写备忘和待办的重要性就体现出来了，由于我白天要上班，所以开发总是不连续的，我从周二开始就意识到我很可能会在下班后继续开发时陷入不知所措，所以我开始每天给自己写项目代办，规划接下来有哪些项目要做，哪些是需要优先处理的内容，哪些是可以延后甚至来不及时抛弃的想法。
我几乎是在任何时候都会写待办，上班摸鱼的时候，上厕所的时候，吃饭的时候，只要脑子里有想法了，就立刻打开待办程序，添上一条或者修改一下原来的条目，这样使得我虽然白天的时候没有实际进行开发，却一直在推进项目进度（很对不起我的本职工作）。
最终，在周三半夜入睡时，我完成了关卡框架的搭建，接下来就是具体的关卡设计了。
制作关卡设计到最后的完整游戏流程，我花费了周四的一个通宵。
其实当框架搭好后，关卡设计就不太花时间了，毕竟我一开始就没有规划特别复杂的关卡，所以这次没有打算在这一步花太多时间，倒是由于那天是我最后一个可以下班后开发的晚上了（那时还没有通知提交延期），所以我把大量的时间用在了设计游戏界面上。
由于这次时一个人制作，而且我的重心放在了程序和完成度上，所以我在美术上就只求能简单明了地传递游戏信息，于是我直接沿用了很久以前自己画过的一个美术风格，用扁平图案和粗线条作为主要元素，加一些单色立体效果，尽量让画面整洁大方。
最后，大约在周五早上的七点，我打包好了游戏，上传提交。
四、提交之后
写这篇总结时，是周五的晚上，虽然下午时通知将提交期限延期到了晚上22点，但对我而言倒也没有什么需要再补充的内容了，虽然有些想法在开发中因为时间而放弃了，但我至少还是说到做到地完成了一个流程完整的游戏。从这个角度而言，这次的Jam，我已经达成了我的预期，而且意料之外地收获了独立开发游戏的经验。
我可能暂时不会再参加这样限时或限定主题的游戏开发活动了，因为这次头脑风暴让我想起了很多自已以前想过但没有实现游戏灵感，我打算先去看看一下这些灵感是否好玩。
但无论如何，这样的活动对很多爱好游戏开发的人来说都很有意义，我久违地感受到了全情投入，心无旁骛地创作的快乐，这种快乐真的太珍贵太难得了。
感谢机核和所有主办方。
最后，关于为什么要写游戏开发总结（或者开发日志）
其实我之前很多年一直对开发日志这种形式不以为然，觉得这种东西不仅写的人浪费时间，看的人也未必能有什么收获，直到最近我参与了一些长周期、要求高完成度而且同样只有我一个人参与的工作后，我才终于意识到了事前规划和事后总结的重要性。
总的来说，写总结的意义其实不在于是否给后人提供了帮助（事实上由于每个人情况和视角不同，我始终觉得几乎没有人能从开发日志一类的东西里获得直接帮助），而在于在写总结的过程中，我自己为了写出这篇总结而被动地整理了我的思路，不至于一时激动地参加了一场活动，废寝忘食地赶完了进度，头昏脑胀地点击了提交按钮之后，就把一切抛诸脑后，再也不去思考自己哪里做得好哪里没做到，那样的游戏开发，除了给世界徒增一个可执行程序之外或许再也没有别的作用了。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。