目录
上一篇：Unity《ATD》塔防RPG 3D游戏架构设计（一） - KillerAery - 博客园
“ATD”游戏模型
《ATD》规划项目摘录：
分析方案后，很明显分为这4种游戏模式：
英雄、怪物、陷阱、塔
最初的想法是使用继承来实现这些游戏模型（如图）：
不过考虑到现在英雄/怪物/陷阱/塔类型已经太多了，未来可能会扩展更多。
如果使用继承，派生类的数量将达到一个小团队难以维护的地步。
然后我想到了Unity的GameObject-Component机制，所以我最终通过组合组件的方式设计了这些游戏模型。
至于之前设计Skill机制时为何采用继承的方式，原因如下：
计划中技能只有8种，所以要写的派生类相对较少游戏动态，而英雄/怪物/陷阱/塔总共有20多种。 技能不是游戏对象。 它没有Unity提供的GameObject-Component机制，接受组件也不方便（除非你自己实现一套组件模式）。 事实上，设计Skill的另一个思路就是将Skill设计为行为树，通过组合节点生成Skill。 然而，当我选择两者之一时，这个想法就被放弃了。
首先，为了统一术语，避免游戏模型和Unity的GameObject混淆，我们定义了一个名词叫做个体来表示一个游戏模型单元。
那么如何表示单个游戏对象呢？
首先，我们需要为各个游戏对象编写一些必要的组件脚本类。
对于单个游戏对象，它可能由下图组成：
一般来说，行为和输入应该放在一起，统称为控制器。 然而塔防游戏设计与实现，现实中，在游戏中，输入源可能是玩家，也可能是AI，因此将个体对象的行为和输入分开是一个不错的选择。
也就是说，它必须有属性、行为、控制行为的输入，还必须能够容纳Buff机制、技能机制、装备机制（实际上是被砍掉的）。
许多组件类别已根据这些需求进行了区分：
然后，为了解耦各个组件的依赖关系，特别是跨游戏对象的组件依赖关系，额外引入了一个消息系统组件UI界面，它实际上是用来实现观察者模式的。
每个单独的对象都必须携带一个消息系统组件，而编写的其他组件类基本上都依赖于这个消息系统组件。
例如，如果个体A使用定向技能释放了个体B，则个体A的技能系统组件向个体B的消息系统组件发送消息，然后该消息被转发到个体B的Buff系统组件，使得个体B受到该消息的影响。 增益影响。
各个游戏对象的最终组件依赖关系图：
然后通过一个GameObject添加一个好的模型，然后放置一些组件来组合一个单独的游戏对象。
怪物个体游戏对象的示例：
《ATD》游戏逻辑
首先说明一下，全局游戏逻辑的全局性并不是指变量的全局暴露，而是负责游戏世界的整体逻辑。
全局游戏逻辑设计比较简单：
首先，为了更好的管理各个游戏对象，引入了对象工厂来控制各个对象的生命周期。 资金管理员负责玩家的资金数据管理，例如击杀奖励、等级结算奖励等。 塔管理员负责用规则来限制塔的逻辑，比如建塔的位置限制、建塔的金钱消耗等。 关卡管理员负责生成每一波怪物。
为了辅助这些逻辑塔防游戏设计与实现，引入了三个额外的脚本：消息系统组件、路径管理器和怪物生成器。
结构如下：
《ATD》游戏对象目录设置：
引入消息系统是为了让游戏逻辑能够监听各个对象之间的交互消息，从而使一些行为与游戏逻辑保持一致。
例如，如果听到基地内单个物体死亡的声音，则应判定游戏失败。
很多游戏逻辑脚本都需要读取配置文件数据的功能，以方便游戏的动态更新。
另外，脚本应该在Inspector面板中提供一些可调整的逻辑参数，以方便全局逻辑的调试（例如将钱数调整为99999999）。
“ATD”UI/HUD/特效/音乐
应该为每个UI/HUD/特效/BGM编写一个UI管理器/HUD管理器/特效管理器/音乐管理器：
一是为了方便管理展示，二是为了更好的和游戏逻辑/游戏模型交互。
然后还引入消息系统组件来为这些管理人员提供协助，以便接受一些重要的消息来改变显示效果。
例如，Buff特效管理器通过监听游戏模型的Buff消息，生成对应游戏模型的Buff特效对象。
此时项目整体架构关系如下：
是不是感觉有点像MVC视图？ （笑
结论
至此，《ATD》的整体程序结构就非常清晰了。 下一篇应该是最后一篇了，懒得再写了。
总体内容会更详细地介绍具体实现过程中出现的一些问题和解决方案（包括一些trick），以及一些工具。
目前为止就这样了。
