开发日志06：再谈数据库与时间轴
幸运观众
登录后查看开奖结果
by单曲循环“The Moment”的寒刃
1030 9：45-13：44
游戏包体前几天就已经打包上传了，但最后一篇开发日志迟迟没有写出来，主要是因为昨天才刚刚结束了最后两门考试，而且是在发烧＋月经的情况下，身体几乎是透支的状态，今天才觉得有点缓过来，虽然鼻子还是塞塞的，但是为了揭秘游戏中对于“你确定这不是一个BUG吗？”的主题的解题方式，现在就是动笔写日志的时刻。
看过日志2的朋友们应该知道，我在前期写程序的时候，对数据进行了一次重构，当时的问题是我武断地把程序的分区做成了分区域的，也就是卡牌区，地图区，交易区，卡槽区，企图通过物理区域的隔离使得程序之间不相互耦结。然而结果是比较失败的，因为某些地方需要两次调用同一个数据，把程序物理分开以后，就需要有两个不同的数据库存同样的数据，并且还需要同步，这显然不经济。
随后我的优化方案是重新绘制一个简单的uml图，把应该合并到一起的数据都合并在一起，把程序严格分成了数据库层和操作层，并添加胶水代码。但是这样也有问题，在短期比赛中，这样意味着每次数据库添加数据都需要反复测试，同时，大量的预制体也会让整个项目变得很笨重，对于需要追求评审期下载量的游戏来说，过大的安装包非常容易劝退玩家。
（图片摘自和队友们非即时通讯的文档）
因此我意识到对于短期的项目来说，跑通更加重要，梳理游戏的时序性，写出闭环的反馈循环更加重要，低代码意味着不需要在编译器里面反复调整直到没有报错才能附加到unity上，于是我使用了“时间轴”的方法，在大型的项目中，一般来说需要同时依赖数据库为游戏提供可扩展性，又要用时间轴来确定不同内容结算的时序性，但是至于小型项目，能线性地展示核心玩法就可以，甚至也存在着文游（指传统依靠选项而没有内部小游戏的）这种完全依赖时间轴但体量依旧很大的游戏。
（图源我自己的笔记本）
也是在这个过程中，我决定彻底放弃一开始的“杀虫剂”肉鸽玩法，因为这样的时间轴会拉得非常长，不利于梳理和开发，更别提后期的测试。
时间轴意味着不需要使用专门的回合管理器就能把卡牌抽取的部分和商店结算的部分做好，但是地图部分如果想要长期维护，每次都需要新的时间轴（因为后续的关卡里不只有两个boss，更不只有一个能放路块的地方）
这时候距离开大会已经就剩三四个小时了，开完大会就是长达三天的考试，我真的没有时间做这么繁重的任务了，尤其是此时相当于已经进行了两轮重构，而计算的逻辑反而越改越多了。
数据库还是时间轴？这其实也可以不是一个选择题。
游戏的bug最开始的出现，来自于《太空侵略者》，彼时游戏首次使用cpu来提高存取时间，此前游戏通常使用TTL回路，cpu的应用让游戏的可能性大大地增加，同时也出现了由于cpu传送数据时出现的异常与游戏程序bug共同作用下的“bug”。如今的cpu性能大大增强，许多bug出现在显卡的层面，比如我和朋友玩双影奇境时，她看到的佐伊米欧并不是大美女，而是红着眼的低面数模型，还有一些bug发生在程序互相占用资源造成的死锁，有时这会导致游戏卡死，还有一些bug来自于判定条件出现矛盾，这种恶性bug会导致玩家刷道具，影响游戏内部经济体系的平衡。
这些都是游戏运行起来以后产生的bug，然而程序员是有办法让bug产生于运行之前的，比如为了短暂实现某些功能对程序做出的妥协式开发。（请帮我找一下那个鸽子依靠脖子飞的gif），像这样的bug，如果对于游戏没有太严重的影响，就可以被称之为“特性”，但在很多情况里，游戏的bug经常意味着游戏流程跑不通，比如无法重玩，无法刷新摆放道具，这些问题在我过去的开发里也都或多或少地出现过。
另一种表达是，数据库与时间轴在实践中常常组合使用，但也经常起冲突，就实际而言，代偿性使用另一者也并非不能构建游戏，但长期来看用错工具容易造成额外的开发成本。正因为对数据库的结构性神话与时间轴的实时性神话的错误理解，游戏中的bug才产生。
这个表达很好的概括了bug根本性的产生原因，但对于代偿性使用某一工具的说法令我产生了质疑，在本次开发中，数据库的重构和时间轴的不断修改都增加了开发成本，而将两种方案结合更加会几何倍数地增加开发成本，对于小型轻量的游戏本身是更加灾难化的。
那么是否有可能同时摈弃数据库与时间轴开发一款游戏？当然有可能，但这并不是说让我们倒退回TTL时代，而是在如今这个人人都可以用自己电脑上的cpu和成熟的游戏引擎开发游戏的时代里，使用我们自己的方式。
在我的研究“二手玩家”中有这样一个现象描述，玩家放弃对于游戏本身的探索和思考，转而转向参照有明确点击顺序的攻略，在游戏中进行机械式的互动，这种现象使得游戏设计中的反馈循环并非他们所追求的，而是在追求通过社交媒体推荐的内容进行操作所得到的确定性体验。比如二游中的“跟打表格”，游戏本身设定的游戏平衡机制，比如数值和克制关系，并非玩家与游戏产生互动的结构，只有屏幕内的ui与分屏（或是另外一个设备）的表格之间的相互对照与点击构成了最基本的反馈循环，玩家也会从中获得成就并学到东西，只是这种东西是“二手”的。
从另外一个角度来说，我们可以给出玩家攻略，让其点击就完成对游戏的操作，而非真正提供运算结构。如果没有实际的运算结构，仍能够提供游戏的体验，就意味着我们事实上并不需要数据库，也不需要时间轴，仍能够构建一个游戏。当然这个游戏一定会是有bug的，因为它甚至没有真正的逻辑运算，但因为本次作品的题目就是bug，这种构建bug的方式，我认为是极其精巧和锐利的，于是说干就干。
我最终只依赖四个脚本就写完了整个游戏，这四个脚本分别控制了物体的旋转，游戏的重玩，物体的显隐以及场景的切换。
我一开始就要求美术使用更低分辨率的素材，一是太高的分辨率放进屏幕也未必能展现出细节，二是对性能进行优化，最终使得游戏的整体包体大小只有29.4m，这是我历史以来开发游戏的包体大小之最（当然是最小的）。
然而就算如此，按照攻略的操作也可以完成四种不同的结局，并且如果你们发现了游戏实现的实际逻辑，也可以打出更多不同的隐藏情况，当然这些隐藏情况也都是通过bug实现的。
到此为止，游戏开发的部分结束，这些代码几乎都是我开大会的时候在座椅上写完的，我要求我的朋友帮我给会议内容拍照，而我则把手机完全关掉，进行沉浸式的创作，这段回忆无比的美好。我还记得在座位上手舞足蹈地说着“写完了写完了”的时候，心里的那一份悸动，比任何恋爱或是某一场比赛的胜利，都要好，那种感觉太好了。
后面这一部分我想夸夸我们的美术小伙伴们，他们都是大一的学生，刚刚结束军训就愿意跟我一起做游戏，我是读过大一的，我知道在如今这个“大学高中化”的时代里，大一的学生拥有最多的公共课，最多的会，最多的水课，以及最少的时间，而同时他们又要面对高中生活到大学生活的巨变，就算不参加任何额外的课外活动，就已经令人应接不暇。更何况需要从0开始制作一款游戏，学习怎么验证纸面原型，怎么进行规范命名，和新认识的朋友合作，想办法适应彼此的画风，还有工作节奏。但是二位真的完成得非常棒，明明看作品集的时候还能一眼就分出来谁的作品是谁的，但是提交美术资源的时候真的浑然一体，除非特意去查交付表格，否则真的看不出来是谁画的！
下午和朋友们在地下美食城围成一个圆桌，首次试玩和讲解我们的游戏的时候，朋友们在展示结束后都发出了“嗯~”的赞许，然后一直点头，说一些“独立风格很强”“硬核玩家应该会很喜欢里游戏的设计，就像那个需要描述游戏是什么的硬核桌面游戏一样”，我觉得自己就像是世界上最好的厨师，看到了顾客品尝食物的笑容，有假面骑士加布里那种“零食给人带来了幸福”的感觉。然后他们开始讨论为什么瓢虫代表了bug的意象，复古的画风和沉默的音效是否是一种“冷凝视”等等。
总之游戏开发到现在我没有那种“不舍”的情感，因为相比比赛刚开始那个忐忑不安的我，我更喜欢现在这个解决了问题，带领了团队，而且还通过跟朋友们分享自己的产出获得欣赏认同与幸福的自己。希望未来我能够继续前进，不断地兑现自己的天赋，然后遇到更多更多的朋友，走出一条自己的路。
就先说到这里吧！本期依旧抽取一位幸运观众，加上之前我抽的两位幸运观众，将获得专属“bug”卡牌一张（电子版）。
同时也欢迎大家多多下载游戏，多多评价，我将在评论区选出“最佳评价”，年末送上我的亲签杂志一份！