Godot开发框架探索#2

前言

        距离上次发文又又又隔了很长一段时间。主要原因还是因为思绪在徘徊，最近纠结的点有以下几个：1.渴求一个稳定的Godot开发框架；2.要不要使用更轻量的开发框架，或者直接写引擎；

3.对自己想做的游戏品类拿不定主意。

        先说第一个，出于个人强迫症要挟，开发时希望能有一个规范的蓝本可以按部就班，这样做起来才会安心。但是现在觉得游戏开发没有什么定式，更不应该按部就班；第二点，尝试了很多遍其他轻量级开发框架后，比如FNA，甚至直接SDL写起，发现非常折磨，更别说写引擎；加上第三点，我认为每个游戏开发者能找到最适合自己的游戏品类最好不过，而个人自研引擎最好按照特定的游戏品类设计，否则很难找出与市面上现存的通用引擎相比的优势，这样一来反而浪费精力。在几番周转后又又又回到了Godot。

        上面说的跟这篇文章谈论的内容其实一点关系没有。这里我将分享最近尝试实现的一些关于Godot开发的想法，它们一部分已经被我整理成了Godot插件：

MOWEIII/GoDogKit: Classes Library used for Godot C#.https://github.com/MOWEIII/GoDogKit        感兴趣的可以看看，虽然目前不太完善，我稍后会解释为什么。

又是全局？

        我设计全局类的初衷其实只是为了简化开发速度，比如有一个AudioStream，它作为一种资源类型，需要相关节点才能作用，也就是AudioStreamPlayer，所以我就有了这种想法：既然这种资源很大概率只会用于对应的某种节点，那么可不可以简化创建节点到赋值资源这个过程。虽然这个过程确实是非常简单，但是在多次实践中，发掘零散的节点管理同样也会引发一些问题，除了这里的音频之外，还有一个重灾区就是输入，如果只是简单地在每个节点的输入处理函数中编写输入逻辑，那么很容易造成难以发现的混乱，比如需要同时处理UI输入逻辑和玩家移动逻辑的情况，如果游戏暂停，玩家移动也暂停，但因为节点的层次结构问题，UI没有被暂停，所以需要对处理输入的节点更加关注。这样一来，全局输入节点似乎是好的选择，不过我也还在思考怎么样实现。

场景管理

        Godot有些东西藏得确实隐晦，文档中也说不了那么详细，又或许是我理解有误，场景切换就是一个小坑。那几个Godot的场景切换API其实都是针对场景树的“当前场景CurrentScene”而言的，换句话说所谓的切换场景其实只是把当前场景释放掉，然后添加新的那个场景，乍一看没什么问题，但是一旦把节点置于那个“当前场景”之外，切换时就不会释放了。

        因为使用Unity的习惯，总觉得切换场景是非常干净利落的，可以很好释放资源。但是在Godot中仅仅只是释放某个特殊一点的节点，而非整个场景树。这就造成了一些可能的小问题，比如什么不小心把一些节点添加到场景树根目录，然后切换场景后发现它们还在。

        所以也许是我误会了Godot的场景管理，因为节点这一设计，导致不能简单粗暴地直接给游戏“翻个面”，不过我还是把翻个面的功能加上了，其实就是切换场景时把所有场景树的子节点都释放掉，然后再加载新的场景，除了一些设计上作为“全局”的节点之外。

结语

        其实好像也没有多少好说的，本来以为能多编一些，但是想说的都在源码里了。那个开源项目后面大概率会被归档，因为它的定位不太清楚，我打算等有想法了做一个更框架一点的框架，把功能细化优化。这里更多地应该是收拾收拾心路历程。

        其实优柔寡断真的什么都做不了，每个引擎或框架都有自己的优缺点，而且游戏开发重点在人而非工具，与其纠结用哪个工具不如纠结游戏的玩法。