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