下载 App
《血涌：无慈之印》开发日志 总集篇之程序：暗夜行路 终见太阳
修改于10/2283 次播放综合
底下是沉静碧蓝的大海，头顶是黄金灿烂的太阳 ——《帆》
注：本篇并非单纯的开发日志，内容较杂，包括但不限于：
- 一些项目的开发过程回顾
- 一些开发经验的总结分享（程序为主）
- 一些对于游戏的思考
- 一些个人化的。故事，情绪，心路历程，碎碎念……
很乱，内容也乱，顺序也乱。
为了方便相关开发者交流经验，我会在某些特定主题的标题上做标注，方便直接快速阅读相关内容，也方便不感兴趣的朋友快速跳过某些内容。
以上
海
三年零五个月前，在做完手上最后一个项目后，我从商业手游公司离职，自信踏上了在家手搓独立游戏的道路。
三年零五个月后，我没做出任何称得上是成品的游戏作品。自己做过，也跟人合作过，也参加过比赛，也尝试过找独立游戏行业的工作。彼时虽然也在和他人合作，但是项目经过几次大概方向之后又进入了一个新的等待期。
我慢慢开始接受“我好像就是做不出来”的这一事实。
我开始学着慢慢放下对做游戏的执念，不再天天打开Godot或Unity，不再写代码，不再一次又一次地新建项目搓一些我认为有可能是金子的东西，也不再把自己关在房间。
我开始健身，开始更多和家人相处，开始学着享受生活。就像一个潜水员，发觉自己怎么也探不神秘的海底，而氧气却耗光了。
游出水面换气，然后上岸做一切和大海无关的事。
我考虑转行。
因为更多和家人待在一起，闲暇之余我会带小学的小外甥写作业，我开始考虑学着也许可以做小学生教辅辅导，我寻思我上学成绩不错，性格也很适合做老师，还能赚钱！为什么不呢？
只要不再探入海底。
比赛
慢慢地我没那么厌恶做游戏这件事了，我能够重新坦然面对了。
我重新开始打开游戏引擎。我甚至买了一套UE的课程来学着做3D地编相关的内容，学习的过程甚至还很快乐。
然后我发现，只要没有进度上的压力，仅仅作为业余兴趣，我还是很喜欢做游戏的。
所以看到#TapTap聚光灯游戏创作挑战 的时候，我还是报了名，但是没有找任何人组队，我想试着放平心态，solo做完一次。做游戏不再必须是我的意义，也不再需要是我的谋生工具，它仅仅是我的一项业余兴趣。
不用和别人组队，不用一边期待着，一边承担着责任，我想着，轻轻松松地，做完一个小小的游戏。我不需要自我表达和自我实现，这只是我的业余兴趣，我不用盯着那些已经跑得远远看不见的朋友和对手，我只需要让自己开心。
一个多月前，我确确实实是这么想的。
舟夜书所见
我决心进军小学生教辅行业
开始新的尝试。先从带外甥写作业开始练手。
背诗，背《舟夜书所见》
舟夜书所见
月黑见渔灯，孤光一点萤。
微微风簇浪，散作满河星。
为了方便他记忆，我教他我的背诵方法：
想象月黑风高的夜，很黑！
那么有一盏渔灯在水面上，就会看得清清楚楚！
所以灯很孤独！现在是半夜一点！河边都是水草所以也会有小虫！有萤火虫！
所以是：
孤光一点萤！
......
效果很好，他一下就背下来了。
看他很快地顺着背下来，我神气活现地得意起来，也许我真有天赋吧，也许我真的有点子做教培的天分在身上。
而不在我之前一直追求的东西。
老师要求背诵并且默写，背诵了几遍之后就开始默写了。
我盯着铅笔出神。
我又想到了海。
……
孤光一点萤
海的下面到底是什么，到底有多深，黑夜的海，微微风簇浪，风正一帆悬？
不对，风正一帆悬是他妈另一首诗
我没见过海，我说的是真实的海
也不对，我见过，但是我没有见过真正的海
也许海的另一边还是海？也许海的另一边是真正的海？
另一边，我说另一边，我说的不是横着的另一边，我说
我说的是竖着的，垂直的，Vertical，另一边
Unity默认的InputAsix是Horizontal和Vertical，这两个单词我闭着眼睛也能拼对，不对，闭不闭眼睛好像无所谓......
……我收起了思绪。
小学生已经快默写完成。
我却感觉到海水的味道，从草稿纸上，从铅笔摩梭的笔尖，喷涌而出。
我好像站在海底，无形的海浪充斥了整个房间，房间在变黑，声音开始隔着一层膜，我像是短暂获得了腮的鱼，一瞬间又忘记了自己为什么在这里，为什么来这里。
我一瞬间又回到了房间，我才意识到我还在岸上。
这是我才意识到，我没法不想那片海。
我只是视而不见。
幻觉
关于中间的事情，暂且容我卖个小关子，来一个无趣的小谜题。
忘掉海，忘掉牢骚。
忘掉被海淹没的，决心进军小学生教培行业的无业游戏程序员好了。
让我们转到现实当中，来聊点实际的内容吧。
「程序开发经验」：立项方案
在立项上，我们的计划中我们是做类证件出示的玩法
考虑到这次的比赛形式，新增了一个奖项，那么一定是双端：PC和安卓。
我放弃了Godot。Godot很好，但我认为有两个缺点对我们这次的项目是会有较大影响的：
- UI工作流较为简单，尤其针对有大量PSD导出UI需求的项目
- 移动端工程实践并不稳定，移动端目前尚缺乏足够复杂度的项目实践
再加上本次项目一定是2D为主，所以也自然没必要上UE。
于是最后确定就是Unity了。
选择Unity还有一个理由，就是这次应该会接wwise中间件。考虑到没接过Godot的wwise中间件项目，我更加笃定了选Unity。
Unity虽然在2D的很多功能上原生引擎做得像一坨狗屎，但是我打算这次直接拿UI来做整套的游戏Gameplay，对于存在大量点击拖拽操作的要同时适配移动端和PC端的情况，这是最佳选择。
「程序开发经验」：功能实现设计
这里必须推荐和感谢一位B站博主，我在实现的过程参考了大量他的思路，他较为详细地讲解了类证件出示玩法中如何通过配置和数据来串联游戏逻辑
详细的思路可以看他的视频，这里就不再展开赘述，我这里只说一些我自己认为在游戏开发中比较重要的思路和实践经验。
数据优先
我刚刚入职的时候，我的老大经常对我说这句话：数据优先。
可能是我们的游戏品类的特性，他在前端表现的玩法复杂度并不算特别高，但是必须要保障数据准确。
所以多年以来养成的习惯是：做玩法一定是先通过设计数据流和数据结构来串联整个流程。先把纯数据的玩法跑通并且测试稳定。
当然，这些并不适用于所有的游戏。比如某些对动画和表现要求高的项目，例如偏动作类的类银。但是对于出示证件类型的项目，这样是很适合的，本身有大量配置相关的内容，并且也有比较丰富的随机生成。
所以我在开始并没有着急去制作主界面，而是花了一天多的时间理顺视频中提到的数据逻辑，先设计数据表
配表一览
设计完成，大概在脑中理清完整的数据逻辑后，就进入下一个阶段。
沟通
是的，你没看错，这是我认为优秀程序必备的技能。在这个AI大时代下，我认为是比写代码更重要的能力之一。
沟通并不意味着和谐好说话情商高，沟通的目的是为了对齐（虽然这个词已经被用烂了）。我认为针对于程序岗位的沟通能力主要体现在以下几点：
- 是否能够准确理解策划意图并及时质疑可能不清晰的部分，坦诚且实际。能做的确保做到位，做不到的果断否定拒绝。
- 是否能保证策划准确理解程序所理解的意图，避免“啊我以为我跟你说清楚了！”的情况。避免信息差。
- 是否能够发现项目潜在的逻辑问题
- 是否对项目冗余犯错的空间有一定预留量，但是又不至于过分冗余设计导致代码结构过分膨胀
我认为这几项难度是梯度上升的。绝大部分能做到1和2已经是合格的程序员了，3的话基本需要吃团队磨合以及对这个品类理解的个人经验，4的话就是需要非常深度的对某个游戏品类的理解和认识了。
关于程序和策划的大战，这么多年来网上也是各种梗源源不断，但是我想说的是，大家的目的都是把游戏做好，所以沟通真的是最重要也最硬性的关键技能。沟通的方式，沟通的时机和频繁程度，沟通的效率与准确度，往往决定了项目的成败。不是每个人都能搞定所有东西（也是有这种六边形展示的）
在设计完数据表后，我甚至也没有着急写一行代码，我先找了策划和制作人对清楚了所有可能的需求和情况，以及这个表格后续的大概配置方式及功能。
事实上后面这个表格的结构和逻辑后续也是发生了很多变化，游戏实际的玩法里的细则也是与我们最初开会的内容是有一些差异，但是整体的思路和表的结构基本上都是那时候定下来的，这对后面的工作顺利展开起到了至关重要的作用。
数据流程
接下来的工作相对就简单很多。只需要照着思路把数据流程实现完善。这个阶段仍然是不接入任何表现相关的内容的，着重关注以下几点：
- 数据表的设计是否合理？
- 数据流程是否清晰？哪些是过度设计的？哪些是考虑不够的？
- 测试过程中的各种边界情况是否清晰？
说实话因为是Gamejam项目，所以在这点上并没有做完整的测试流程。早年在我刚入行的时候，我非常想尝试TDD（测试驱动开发）的工程实践。但是在较为繁重的开发压力下，更多的还是以做完了再交给测试的方式来制作的。
TDD在当今有一个新的动机，那就是AI的发展。不过这里我不想展开讲，因为会有一章专门用来讲现在AI开发的一些内容。这里给出我的结论：我认为AI是非常好的推动TDD开发模式的一个好用工具。
也许在下次的项目中，我会尝试比较严格的TDD开发流程，但是这次确实也没时间做，比较可惜。
数据玩法里，保证数据能够正常流转，逻辑正确，包括生成逻辑与判断逻辑即可。这里就不再赘述了。
数据与表现分离
我还在商业公司做主程序的时候，有时候要培训新人，对于新手程序员，我唯一的关注点就是数据和表现分离。
我认为区分新手程序员和非新手程序员的分水岭，就是能否时刻意识到这一点并且在资源允许的范围内做到。能够充分理解这一点并且成功按照需求灵活实现，基本上就算是从新手村出来了。
当然对于这次的项目，因为有数据先行的设计逻辑，数据和表现分离变成了一个非常自然的事情。
提到这个话题，很多朋友会认为就是某些数据结构或者设计模式。我认为不仅是这些，抽象的理论能够用到实际工作融会贯通才算真正掌握。
说回项目。在数据能够成功流通的情况下，表现层要做的其实是两件事
- 将数据转换为表现，如动画，演出，界面等
- 控制逻辑：表现之间如何安排？输入如何转化为控制行为？某些phase下允许哪些输入？
事实上，这里的表现层并非只是MVC理论中的V，而是VC的综合。
表现层这里不仅要思考怎么将数据转化成演出，更重要的是考虑另外两件事
- 导演流程控制
- 输入操作控制
我在这里的设计方案是：首先实现一套通用的，支持await的Flow系统。Flow系统主要是控制游戏的流程逻辑，支持各种演出/行为的同步/异步队列，用这套系统来控制游戏流程。
定义各个阶段的phase，用来控制允许的输入逻辑。当然后来做完发现这套系统没什么用，仅仅是一些关键阶段的屏蔽点击之类的。
View只负责某些行为的演出。当然不是所有的演出都是可以独立出来不依赖于某些状态和数据的。但是View单独拆分的优势是：动画可以单独测试。
几乎所有的程序动画都作为一个单独的View接口实现，由Flow系统控制嵌入到主流程中，并且由主流程决定是同步等待还是异步执行。
另一个带来的好处是，得益于Unity强大的编辑器特性，每个演出都可以单独调试，这样大大节省了调动画的时间。调动画最害怕的其实是构造某些逻辑在正常流程中，前面需要漫长的等待+Mock适配的假数据。且不论假数据可能带来遗漏的问题，单纯就是等待前面流程这一项就会浪费很多时间了。
这样还有另一个好处，理论上演出逻辑的调教是可以交给其他成员的。只要抽离做得好，可以在不干预主工作流的情况下，由动画制作者调试专门的流程动画。当然这次gamejam并没有那么多的时间，只是从工程实践上是更有优势的。
比较有趣的一点是，在整个比赛做完的情况下，原来的数据原型场景仍然可以正常运行。稍做改动便可以在数据原型场景的状态下完成绝大多数的游戏流程。
Bug
从结果来说，我认为比较满意的一点是，在我们测试时间非常短的时间下，游戏的第一个完整流程的试玩版到最后提交的比赛版本，游戏没有出现任何影响游戏流程的Bug。（当然表现层的Bug还是层出不穷，但是都不会影响游玩流程）
临交卷发现了本次最大的Bug
倘若当时没有用这套思路来进行制作，按照我们的工作时间，我想必最后是要和bug搏斗几天的，那么这种情况下，整个项目的进度就会被拖累，很多需要程序化实现的效果也没有时间实现了。
虽然最后因为时间问题，还有很多表现演出上的细节没有时间制作和实践，但是能在后期比较高压的情况下实现能力范围能的所有效果和演出，以及项目没有拖慢整体流程的重大bug，我已经非常满意了。
不足
当然这次项目的经历也不是完美的，还有一些可以提高的部分，我认为主要是以下几项
低估了整体项目的复杂度
说实话，知道要做这个类型要开始调研的时候，我是有些轻敌的。一方面，我认为这个类型与偏剧情的纯文字类游戏区别不大，程序的工作应该不会很重。另一面得益于前面提到的Up主，我又有现成的思路可以参考，省去了很多需要设计和思考的时间。
但是实际制作到后期，项目的复杂度是远超我的想象的，这里就不展开了。
总之就是，不要提前开香槟，不要轻敌。
数据测试流程不完善
其实后期这方面是出了一些问题的。比如到最后一天的时候发现原来的角色生成逻辑有某些问题，但是是经过仔细查才发现。
发现问题的途径往往是策划测试中的人力测试，这部分其实是效率非常低的，如果能我提前做好测试数据集，对表格配置也有完整的测试流程，策划在这方面的精力可以省很多。对于需求变更的逻辑也有更加稳定健壮的保障
第三方库以及音频的测试逻辑经验不足
这次我们接入了wwise用来实现音频效果，但是在最后一天才发现了一些凭我自己无法解决的问题，最后在大家都绝望的情况下，在音频老师六点哥的帮助下找到了问题。
因为我没有太多的复杂音频的接入测试经验，本次的音频实现上涉及到有一些状态的问题，我认为在这方面做得是不足的。项目初期只是实践了一下SDK接入以及打包测试。在音频需求上我也没有参与讨论。导致最后不仅接入的时候手忙脚乱，遇到问题测试的时候也是一头包。
我对于现在任何“需要人力来测试”的项目都持一个否定态度。人力测试确实是必要的，但是如果想着“有人力测试就可以不在流程设计上改进” ，这种想法是不行的。尤其在GameJam这种情况下，每个人的时间其实都是很宝贵的，如果能在程序的流程上通过某些设计来提升测试的效率，等于团队就多了一份实打实的制作时间来完善整个项目，是很宝贵的。
【项目开发过程回顾】立项真的很重要
虽说项目的开发是从10月1日才开始，但是立项并非如此。
早在加入这个项目组的时候，制作人就早早确定了项目的玩法，风格，方向。给足了大家时间来做风格探索和预研。
Gamejam发展到如今这个年代，尤其对于#TapTap聚光灯游戏创作挑战 这样的长周期比赛来说，我认为提前做项目预研是很有必要的。
这也许是一个暴论。因为一旦这样做了，就有“预制菜抢跑”的嫌疑。
当然事实上我们正式开始制作也是在真正开题了以后做了方向调整然后才开始的。
可是我们抛开这次的比赛来说，单纯只说游戏制作。过去三年我信奉的游戏设计理论是：原型代替立项，玩法会自己长出来。
但是从结果来看，这样是不可取的。姑且不论个人的能力问题，我自己遇到的最大问题是，游戏做到某个阶段，就会开始心里打鼓“现在这样好玩吗？”
游戏的好玩并非只是单纯的Idea的优劣。诚然优秀的Idea结合优秀的制作，是每个游戏人梦寐以求的高峰。但是更多时候，我们想出来的Idea并不是那么优秀的。游戏最后呈现出来的优秀与否，更多看的是制作上的完成度和水平。
对于立项上，主要还是制作人和美术大大们参与，我事实上没有太多参与立项的具体工作，我更多精力放在了预研玩法的实现逻辑上。但是这次比赛我也深刻感受到了，一个有着完整立项逻辑流程的项目，做起来后续是什么感觉。
那么在没有完整探索立项过程的时候，贸然开始制作会有什么问题呢？
结局就是越制作越偏离，越做越怀疑自己。
立项不可能一开始就把整个游戏所有的内容全部都板上钉钉的完全敲定，但是，抱着“俺寻思”的心态去做的话，早晚面临一个困局：当游戏在某个阶段感觉“不够好玩”的时候，你没法确定到底是Idea出了问题，还是说你的制作内容/打磨程度不够。
立项正是对这种阶段的一种预研，有了充分的立项上的思考，你到中间这个阶段，就会知道路还有多长，以及路的终点是如何。
诚然这种制作形式也会有问题，比如不好掉头或者调转方向，不太适合某些特性类型的项目。但是对于21天的Gamejam来说，我认为是最好的选择了。
一旦不够顺利，deadline又步步紧逼，怀疑就会容易滋生并且蔓延。
怀疑自己，怀疑想法，怀疑内容，甚至怀疑队友。
积累到一定程度，制作组内就会矛盾爆发，分道扬镳。
我没有经历过这种爆组的经验，但是带着怀疑前行的感觉同样非常难受。
毕竟对于怀疑自己这件事，
我已经体验得太多了。
【游戏人的思考】AI时代，何去何从
我并不排斥AI，这次比赛当然也会涌现很多优秀的AI作品。
对于AI素材生成我这里不想做讨论，因为我这里是作为一个程序的身份来分享这次开发过程中对AI的一些思考的，我不置可否。
看着AI以令人咋舌的速度变强，作为一个游戏人，作为一个程序员，说不恐惧，那是假的。
我会被替代吗？独立游戏行业会因为AI而爆炸吗?
在这次的项目开发中，策划/美术/音频老师依然坚持手搓的情况下，我作为程序确是另一种情况。这次项目大部分代码都是AI生成的。
我没法承认我代码比AI写得更好，更快。
最早从2023年开始尝试用Chatgpt写寻路代码开始，到后来24年底开始接触AI Vibecoding，我认为AI编程一定就是未来游戏工程实践中非常重要的一环。
但是还是太快了。
曾经可以一个月手搓近2w行代码的我，现在手写代码的时间约等于0。大量非程序出身的选手也可以借助VibeCoding搓出非常不错的项目和效果。我能感受到我的手写代码的能力在逐渐退化，思维也不如以前敏捷。
我在想，作为程序，我应该怎么和AI共存。
于是这次的工程实践也算是我的一次实验：一方面，我把具体的代码交给AI。另一方面，我希望自己在系统设计上的思考能够更进一步，更多的借助AI的力量来帮助我实现更好的工程实践。
前面已经提到过我先设计了游戏的数据结构，这部分是我完全手搓的，通过设计表结构，理清思路，来对游戏整体的系统有一个把握。
然后进入制作阶段，一步步实现各个系统。并且尽量让AI做充足的测试。事实上这一点做得还是不太够，以AI现在的能力，是能够轻松生成大量的TDD案例来测试数据逻辑的。在这个阶段我还是主要用人肉测试的方式来试验。
我目前不太能接受那种，给定AI文档让AI自己开发的形式。一方面是开发内容的质量不可预知不可控制，另一方面我认为自己对于系统的思考需要一点时间。
所以我采取折中的方式：我不会告诉AI代码怎么写，但我会把边界情况和可能的问题讲清楚，以及AI的文件结构如何组织，代码大概有哪些文件，每个文件大概的功能说清楚。这样即使是真的遇到问题需要手动修改，我对代码也有一定的了解。另外是针对后续的可能扩展，有了扎实的框架，AI的实践效果也会更加稳定。
AI其实可以做得更多，在游戏制作的工程实践上。
比如，AI很适合固定规则的检测。在策划的表格配置上，如果要硬编码检查规则，往往对程序员来说是噩梦。但是AI适合检查规则的编写：因为表格注释一般来说清晰易懂，都是自然语言。另外AI能够通过自然语言分析文本配置来指出潜在风险，比如某个对话的id配置错误等等。
AI也适合某些QA中的Debug。我听闻有的组会直接让AI读项目的BugList，然后给出可能的解决方案。这也是我接下来会研究的一个实践方向。虽然思路听起来很简单，但是我认为这个东西的实践是需要一定的工程思维的：如何保证AI的改动逻辑不会影响到其他模块？如何保证AI的改动能够正确合并到主分支或者测试分支并且产出打包版本？如何在接近全自动化的流程中留下人工紧急介入的接口和冗余？AI不需要解决100%的问题，如果AI能在这个领域解决80%的问题，那么就已经能够帮助项目更好更快地做更多有实际意义的内容。
AI也适合测试驱动开发的逻辑。这个前面已经在程序经验总结里提到了。这里就不展开说了。
跟制作人老欧聊这个问题，他常常提到的一个观点是“作品要有人味”。
诚然现在这个时代AI的能力没有边界，效率和能力范围远远超过任何碳基生物，但是我认为优秀的作品一定还是要有人主导的，AI只是作为一个工具。别的领域我不了解，我也不置可否。但是对于程序领域来说，积极了解，思考，实事求是地接受，是好过固步自封和恐惧的。
【项目开发过程回顾】意外
当然，意外还是来了。
一方面我个人因为一些个人原因紧急回了两天老家，原本满打满算拉满的工作时间少了两天。
遇到的更大的问题是：之前的游戏方向存在一些的问题，就如上面的开发日志所示。
当时我们已经做好了最差的心理准备，也就是无法完赛。
制作人第一时间同步了这个问题，然后开诚布公地和大家谈论了这个问题，并且说清了最坏的可能性。
那天之后紧急修改了多少文案，任务设计，剧情线，原本定好的故事设计的内容，我不得而知。
我只知道后来我忙完家里的事情回来后，紧急开的第一个会，我看到的了一份完全重新出发的，不同于原来故事设计的，玩法方案设计上也完全不同于原来版本的游戏策划案。
除了游戏玩法的大底子形式没变以外，其他所有的东西基本上都从头来过。
无法想象大家在背后付出了多少看不见的努力。
但我知道，这是一份迫不得已的最大诚意。
意外就是这样，不可预测。
前面我花了很长的篇幅来阐述立项的重要性：立项能够规避最大程度的意外。但是即使是我们在如此充分的立项的基础上，我们还是遇到了意外。
包括后来看到各个制作组分享的开发日志，也鲜有真正意义上完完全全一帆风顺做下来的，有些克服了重重阻碍最后完赛，有些竭尽全力但是也无奈分崩离析，有些看起来一帆风顺快快乐乐顺顺利利，但是背后也砍掉了很多自己心心念念的特性和功能，与时间选择和解。
意外出现的时候，对整个制作组的考验并不只是事情本身，更重要的是相互间的信任和面对的态度。
遇到问题第一时间跟大家坦诚的信任是合作的基础，在这样的信任基础下合作才更容易共渡难关。
做游戏从来不是一件一帆风顺的事，没有人能预知一切，没有人能保证没有意外。
因此最后在完赛的时候，在21号上午11点钟上传了最后的版本后，熬了一个大夜的几人终于稍稍放下心来的时候。
我躺在沙发上，回想这几天的旅程，我感觉到的并不只是如释重负，不只是开心，更多的复杂，感慨，苦涩，遗憾的感觉都萦绕在心头，无法入睡。
当然，我还是没熬过整夜未眠的劳累，本想着看见版本过审后再睡，最后还是在沙发上昏迷了。
梦
……
我好像又回到听写小学生的那个桌前。
但是又像是大海，而且是深处的大海。
课桌，光，铅笔，草稿纸在向上飘，很快消失不见。
我想向上游，但是却发现自己在下潜。
我不再带着氧气。
我在下潜，在很努力地下潜。
……
我想起来了，加入的事。
在我生日的那天，我出门，去吃美味的寿司郎（此处并非广告，是真的挺好吃的还）。
我开始健身了，我不再天天吃碳水，我吃很多鸡蛋，鸡胸肉。
我告别了过去天天吃油腻吃碳水的生活，就像我告别做游戏一样。
我意识到了我要多吃蛋白质，很多很多的蛋白质，很久没吃寿司这样的碳水似乎让我觉得有点不适应。
我一边开玩笑说自己变成了蛋白人，一边顺手开始查寿司到底是有多少蛋白质，我要吃多少个金枪鱼寿司才能补够蛋白质。
然后我看到了小红书的招募，有一个游戏制作组，24年制作《孟婆》项目，那年刚好我也参赛了，并且对他们印象很深很深，我记得24年就拿到了最佳美术的提名。
他们说他们打算参赛这次#TapTap聚光灯独立游戏 挑战，缺程序。
我迟疑了一秒钟，问向坐在对面的女朋友。对方是很有名气的组，我应不应该去试试。
“你愣着干嘛，赶紧联系啊！”
再后来似乎就很自然了，进组，定需求，开会，写代码，对需求，聊天，测试，打包，沟通，仿佛就顺其自然地这样合作下来了。
后来再聊起来这件事，听说那天看到帖子后，来联络的程序络绎不绝，那天我也拼命拿出我的项目经历和一些东西来证明自己，想办法展示自己的优势区间。
去他妈的小学生教辅吧，我想。
我想做游戏。
但是最后真正敲定了我的入场券的，却是我无心中透露的事情，我说今天是我的生日。
“那决定就是你了！”
现在想到这件事还会觉得非常搞笑，我应该是为数不多的，凭借过生日进组的人了哈哈哈哈
最搞笑的事情是，在最后几天进度紧张，吭哧吭哧熬大夜的时候，我们一边干活，一边漫无目的地在凌晨聊天来保持清醒，老欧透露过两天是他的生日，我说哇那太好了比赛刚好也结束了，不得好好庆祝一下，他幽幽地丢来一句话。
“我打算去吃寿司郎”
……
梦中似乎还在下潜
越往下越深，岸上的光亮也离我越来越远
直到过了一个界限
重力似乎反转，没有下降
在上升？
海不再变得黑暗位置沉重，似乎能看到渐渐透出的亮光
仿佛从海最深的一端穿过，穿到了另一个重力方向的，另一片海
原来海的对面还是海啊
直到我完全上升到穿过了又一片海
浮在不知道是哪里的海面上
底下是沉静碧蓝的大海，
头顶是黄金灿烂的太阳
最后的碎碎念…
创作是痛苦的，但是也是快乐的。
在做游戏这件事上，我没有过成功的经验，我的人生好像都是失败，但是我的人生好像也不都是失败，但是我的人生也称不上成功。
我曾经以为创作这件事，人的痛苦快乐与否，取决于最后的结果。
如果拿到了所谓的大结果，那么再苦再累也会转化成快乐。
如果没有拿到任何结果，那么再享受快乐也很难得到真正的快乐。
这次比赛真的做完提交的那一刻，我的心理涌现的，是一种奇妙的感受。
是一种平静的感动。
并非只是倾尽全力就好，曾经倾尽全力，但是在结束之前我就预想到，这可能不是一个让我自己满意的作品
创作者中，倾尽全力的创作者是最痛苦的，因为已经倾尽全力
创作者中，倾尽全力的创作者也是最幸福的，因为已经倾尽全力。
最后，让我用大学时候看的一本书来收尾吧
当初，游戏开发更像是废寝忘食也乐此不疲的爱好，而绝非枯燥乏味的工作。
惟愿时光倒流，让游戏研发的乐趣回归。
鸣谢
感谢这次制作组的大家，感谢无敌的美术组，感谢克劳老师，彩灯老师，考拉老师和Dua老师，产出了海量且质量非常过硬的美术资源！每次群力发图大家都会化身夸夸战士，感慨我们美术组的给力和强大！
感谢程序组的我自己和音频组的六点老师，我一直认为#TapTap聚光灯游戏创作挑战 应该出一个最佳音频奖项，私以为六点老师完全配得上这一奖项！制作了超多很给力的音频，游戏表现力也因此大增。
特别感谢，制作人兼策划的欧老师和木木老师。谢谢给我机会加入这么氛围好的制作组大家庭，也一起熬了不知道多少个大夜，一直战到上线的最后一刻！背后做了超级多给力的工作为我们兜底！
当然最感谢的是愿意游玩体验这个游戏的每一个玩家，谢谢你们。我们接下来也会不断完善和优化这个游戏，争取让它变得更完美！谢谢大家！
