项目复盘：TapTap聚光灯Gamejam
前言
三周的开发终于落下帷幕，其实我个人还是对结果很满意的，虽然作品不及他人的万分之一，不过主要目的还是以熟悉Godot引擎本身为主。这次我做的事情其实主要还是把在Unity那边学到的东西Copy到Godot来，仅此而已，几乎没有进化。
不过还是找不同找到了很多两个引擎之间的异同。很快我会罗列出来。
项目概览
项目名： 第九天 （DAYNINE）
类型：休闲，肉鸽
开发周期：3周（实际2周不能再多了）
游戏引擎：Godot4.3 Mono
美术风格：像素美术？
核心玩法：跑图，提升，生存，割草？
游戏链接：第九天PC/主机 - TapTap
https://www.taptap.cn/app/726174
项目框架
主流程管理
我简单粗暴地以单个单例类作为主流程的管理类了，但是这个类完全不符合单一职责的原则，事实上，它不仅负责控制主流程，还涉及了一部分的资源加载和输入控制。所以整个游戏的主流程循环起来会有不少BUG。
还有一部分的游戏数据写在该类中，其实我也不清楚到底一些全局数据应该写在哪里，于是就......。
生物类
所谓的生物类，不过是带有生命值的东西，因为玩家和怪物都具有这些七七八八的东西，就作为基类了。
我觉得这次GJ在设计继承关系的一个重大失误就是Override太多了，比如一个怪物1会一直跟着玩家，怪物2会徘徊追击，但是怪物1写好了很多重要的机制，怪物2也可以用到，理所当然地想到怪物2继承怪物1，但是只有一两种还好，怪物种类一旦多起来或者怪物机制一旦复杂就会出现很多BUG，比如经常性地把某个父类的重要函数Override掉了。
于是我便想到一个曾经用于Unity的解决方案，基于“组合优于继承”的设想。简单来说就是将复杂的AI机制包裹成一个个类，每个怪物，或者说生物基类包含可以实现机制类的处理方法。
或者应该叫他们状态类，怪物们本质上还是一个状态机。
这样或许能规避很多东西，就比如，我从Unity时期就养成的习惯就是一直把所有帧处理相关的函数直接塞到帧处理函数里（比如Unity的Update和Godot里的Process），这样确实是挺方便的，但是就像我方才说的那样，在继承等关系的影响下，执行过程是否还能保证准确无误，一段移动函数属于某个父类，而这段函数恰恰是最基础最简单的移动函数，我们理所应当不会想为每个其他类都写一边，于是就开始继承，继承完了后发现某个子类需要实现某个特殊的机制，需要对移动函数进行重载，然后长此以往便堆积出了很多冗杂代码，甚至逻辑错误。
所以不妨按照自己的想法，把所有可能需要的机制（状态）先写出来，而不是为某个“怪物”写。换句话说，这个机制类是所有怪物共享的，可以有也可以没有，如果有就在帧处理函数中进行处理，比如一段普通的水平移动，我们封装成类，向怪物类注入该类的依赖（我觉得甚至可以不需要），以便怪物执，怪物类就是一个状态机，状态处理器，拿到什么状态就处理什么状态即可，至于状态之间的切换就还是得因地制宜了。
虽然感觉复杂了一点，不过倒是实现了状态与怪物之间的解耦。
UI框架？
我打问号是因为我完全没用到什么框架。老实说Godot的UI真的又好又坏，它没有像Unity那样多样的设计方案，甚至对有些UI需求的支持很弱。不过它的信号系统切实为UI设计加分。
我们都知道做UI是很烦很累的，这倒也不是什么技术上的问题，而是UI逻辑十分的繁琐。如果有一个现成的框架会不会更好呢。以我的经验来看，做游戏的UI和网页差不多，都是响应式为核心，当然特殊需求除外。而Godot在这方面意外地提供了一种连连看方案，就是信号。
我们可以为每个按钮或面板之间的通信以信号连接的形式处理，比如把一个按钮的pressed信号与某个面板的hide函数连接起来，甚至就算彼此的参数不一样，Godot还是可以通过信号设置实现通信，这样就大大降低了写UI时的繁琐代码量，其实这个过程也挺繁琐的，但我还是认为写一堆雷同代码更反人类。
我目前对于UI的最大需求莫过于，能响应多种输入模式，至少是手柄加键鼠。还要能管理好FOCUS，就是不能在子面板FOCUS到父面板上的按钮吧。
所以目前我对写一个Godot的UI框架持观望态度，倒不是因为它不重要，而是还没那么重要。
输入管理
这次敲代码我似乎遗忘了一个很重要的点，那就是输入控制应带由单个类承担，以至于我很多在类中写了一些处理输入的函数，比如我最喜欢把用于控制玩家的输入写在玩家类里边，这确实挺方便的，但是如果把处理UI输入的函数写在UI中就不可避免的会有一些冲突。
最大的问题应该是Godot没有所谓的Disable或Enable，只有隐藏和显示，虽然加上设置处理模式可以实现类似效果，但是不免有一些烦琐。有的时候虽然UI被隐藏了，但是背地里还在处理，所以经常会有一些BUG。
我能想到的最优解就只能是把所有的输入单独用一个管理类处理，它同时还负责记录输入模式，切换输入状态等职责。
音频
作为可怜的独狼开发，这个游戏完全没有任何声音，因为实在来不及了，随着开发经验的积累我越发觉得音效的重要性如此之大，哪怕只是魔性洗脑的点击音效都能让人感觉游戏质量完全不一样了。
结语
多说无益，因为我一时半会也想不到什么重要议题，于是就草草结束吧，具体的实践成果肯定是要等到真正的代码搓出来了才会展示。
下一次开发多半是月末的吉比特GJ了。