《代号-奥罗拉岛》 开发日志 01 技术选型和基于组件开发的游戏框架搭建

项目简介

《奥罗拉岛》是我今年开始尝试制作的独立游戏。因为我意识到自己很难独立完成游戏的制作，所以我尝试寻求组队。幸运的是我在B站找到了网友可可，并且在和她简单讨论之后，确定了项目的大方向“女性向的模拟经营养成游戏”。

开始界面效果图.png

我们首先谈到的游戏就是《星露谷物语》，但我们希望在其基础上弱化种田相关的gameplay，因此我们将主角设定为一个经营着一家甜品店的小姑娘，而其他的一切设定都是围绕着甜品的制作和销售（当然，也少不了可攻略的NPC，这是后话）
由于游戏定位是女性向，因此我尽可能的让可可同学来负责游戏的美术风格以及很多细节的策划（真不是因为我懒）。

世界地图规划.jpg

当然，在开始合作的首周，我们遭遇了很多困难，这其中包括对于一些工具的使用，如果大家感兴趣，我会在后续的开发日志中和大家更详细的聊到。

技术方案选型

最近我对godot很有好感，因此这款游戏我们尝试使用godot开发。并且一边开发一边等待godot4的发布
因为涉及到线上协作，因此我们选择了git作为版本控制工具，代码托管在国内的gitee上（是私有仓库）。
godot对于tilemap的支持十分有限，因此我选择使用tiled作为tilemap的制作工具，因此造成了一些麻烦。这里按下不表。
当然，对于godot，可以聊的很多，包括一些插件的选择：
首先强推的便是 dialogic这款对话插件，尽管目前还没有投入使用，但我早已经对其跃跃欲试。
其次便是状态机、行为树相关的插件，因为状态机较为简单，因此我选择自己实现。

我在itch上购买的素材

在代码框架方面，我选择尝试用基于组件系统的方式开发。这也是这篇开发日志的重点。

当前项目进度

在过去的一个月里，我在逐步熟悉godot引擎，是的我在春节期间就在思考利用godot做点什么。
在确定了最初的游戏大方向的设定后我和可可就开始分头行动了。她开始设计整个岛屿的布局以及角色，而我则开始制定开发框架，并开始制作道具系统。
我已经接触过很多优秀的游戏引擎和开发框架，比如UE4官方提供的gameplay框架或者unity3D很多优秀的第三方框架插件
也许是因为我本身是游戏策划的缘故，因此我再一开始便思考怎么在做游戏的过程中分离出自己的框架。
当然，脱离业务逻辑的框架听起来就像空中楼阁，因此这个框架我会在之后随着业务逻辑的编写而持续优化迭代。
几年前我曾经写过《核心机制设计》，这次算是利用godot实践一遍，真正做到：理论结合实际。

近期项目规划

在制定好开发框架后，道具系统的实现比我预想的顺利很多，这里不介绍具体的开发细节，后续等整个系统开发完成我会单独出一期开发日志回顾整个过程。
我去年在用ue4制作《老李教你穿装备》系列教程时候就说，背包系统本质上就是维护一个道具的列表或字典，实现对道具的增删改查方法。

目前使用临时素材实现的道具背包

待到道具系统制作完成后，便会开始制作游戏的核心系统——甜品制作，这部分我目前还不知道是什么样的形式，要找机会跟可可问清楚。
开发日志应该不会更新十分频繁，也会穿插分享一些我认为不错的教程和经验。
后续还有一些更大胆的想法，目前还比较模糊，在之后有了更具体的设计方案再和大家分享。

简单的游戏框架

这是最让我兴奋地部分，作为一个独立游戏开发者，在制作游戏前，我首先想到的是对于游戏框架的搭建。
这样做的核心诉求在于我对于独立游戏的理解，我认为不同于重度的商业游戏，独立游戏应该更短平快，因此我不想再制作下一款游戏时完全重新开始。那么搞清楚哪些东西是可以复用的就显得十分关键，而这部分便成为了“框架”。

得益于godot对于单例模式的支持，我抽象出一个Qinstance作为整个游戏的全局框架类，这个类中维护着很多有用的manager，这是典型的manager of managers 模型。

一个典型的manager of managers 单例

尽管 MOMS 模式远远谈不上优雅高级，但好在简单高效。
那么，我选择了哪些manager？
这部分我参考了UE4的Gameplay框架（不可否认的是我们都没办法摆脱路径依赖），我在Qintance中注册了当前的player_character、player_controller和current_ui_form、current_scene等对象的引用，方便在任何地方可以调用
当然，一些经典的管理类包括entity_manager、UI_manager 和 datatable_manager等，也许后续还会拓展出net_manager以及其他的。
当我以为自己要设计很多manager时候，我惊奇的发现事实上godot提供了很多现成的管理类以及设计模式，这个我们之后再聊。

当这一切完成开始编辑业务逻辑时候，便会发现很多工作简单多了。

基于实体组件系统的实现原型

也许你注意到了entity_manager，这用来管理游戏中所有的entity。
entity是我对于游戏内所有对象的交互，可以理解为UE4中的actor
我创建了entity_base脚本，继承自node节点，因此与ue4中的actor有些不同，entity不包含坐标transform信息。
在最开始我打算将逻辑和表现完全分开。
这部分我参考了《饥荒》的lua脚本。
我开始的构想是entity_base和component_base 脚本（两者都继承自node）实现最简单的组件模式。
在继承component_base的脚本中实现各种逻辑，并使用godot的signal 信号机制实现逻辑的回调。
在各种继承entity_base的entity实体中，组合这些组件，并根据自身特性处理组件的回调函数。
而逻辑与表现的结合便是在entity中持有对 逻辑 prefab的引用。
当然，作为逻辑层的entity和component全部是运行时动态增删的。
这在逻辑上可行，但我最终没有采取这样的办法。主要原因是我不清楚这样做的性能如何。

一个典型的entity包含多个component

我最终采取的是更折中的方式：
我将逻辑和表现层作为一整个scene，其中表现层作为逻辑层的子节点树，取名为inst，但同时也可以手动指定表现层。
这样更符合godot引擎整体的设计。
可能有同学会疑问为什么不用godot现有的node的设计，通过自定义node实现类似component的方式。
这首先基于解耦的原则，我希望逻辑层的代码尽可能不依赖于引擎，这部分设计我参考了unity3D中一个著名的框架entitias（同时，这是一个ECS实现）
另一个原因就是基于面向对象、godot的节点有一些限制，比如可移动的对象的根节点要求是kinematicbody2d的，而一些其他的对象则可以使Node2D，这让我在指定类型时遇到了一些麻烦。
但现在我将node作为所有entity的基类和根节点，并且抽象出entity_base这个类用来管理维护所有的component和运行时的增删改查。
简单来说，一切都可以由我自己掌握了，这能减少很多由于对游戏引擎不了解导致的焦虑。

实用的游戏管理状态机

最后，我想分享的是一个用来管理全局游戏状态的状态机，我称其为procedure_manager
状态机常被用来处理很多基于状态的逻辑，特别是处理一些简单的AI问题。
但我这里要讲的是另一种对于游戏全局状态的管理办法，这个办法来自于Unity3D引擎一个著名的游戏框架Gameframework（是的，就叫这个名字）感兴趣的同学可以了解一下，同样是采用了manager of managers 的方式，并且其中让我印象最深刻的就是这个流程管理器。

procedure_manager的实现非常清晰

和其他manager不同的是，我将 procedure_manager 做成了一个 scene 并放在游戏 main场景下。在procedure_manager 的 ready 方法中，它会将自己注册在 qinstance 单例中。
这样做的好处是，不破坏godot单独场景可运行的原则。假设一种场景：
我们游戏会从main场景运行，然后根据procedure 加载资源、读取配置、然后进入开始界面、加载游戏或者新建游戏。调试期可以很方便地改变状态机来跳过某个流程。
但有时候我们要测试某个单独的系统，比如某个item_tile的显示是否正常，player_character 能否正常移动，这些可以在 单独的场景中完成的测试，不应该受到流程管理器的影响。

如果你还没有接触过procedure_manager ,我强烈建议在你的下一款游戏中采用这样的设计。你会更清楚这样做的优缺点。

写在最后

以上便是《代号-奥罗拉岛》这款游戏的第一期开发日志，希望你能喜欢这种形式。
我是老李，一个想在今年制作出第一款独立游戏的游戏人。
我们下期开发日志，再见！