Unity《ATD》塔防RPG类3D游戏架构设计(一)

《ATD》 游戏简介


游戏类型:塔防+RPG的3D游戏

游戏要素:3D 塔防 英雄 建筑树 搭配

主体玩法:游戏里将会有一波波怪物进攻基地。玩家可以建造塔来防御敌人,同时也可以控制单独的个体英雄角色来攻击敌人。

游戏模式

  • 第三人称视角的RPG模式

Unity《ATD》塔防RPG类3D游戏架构设计(一)

  • 上帝视角的建造模式

Unity《ATD》塔防RPG类3D游戏架构设计(一)

控制方式:在游戏中使用Tab按键,切换这两种操作模式:

  • RPG模式下:WASD控制移动,Space跳跃,鼠标左键普通攻击。
  • 建造模式下:鼠标左键建造,E销毁已建造的建筑。
  • 数字键1,2,3,4,5,6控制物品栏,对应英雄技能或者建筑安放。

胜利条件:消灭所有敌人 或者 坚持到时间结束

失败条件:基地生命值为0 或者 英雄死亡

《ATD》 整体结构


一般来说,整个Unity游戏项目整体结构,我比较偏向分为如下5部分:

  • 场景对象 :不会产生互动的可视物体对象,例如地型/建筑/灯光。

  • 游戏对象 :参与互动的游戏对象,例如英雄/怪物/塔。

  • 游戏逻辑 :负责控制游戏的逻辑,其逻辑对象一般是单例的。

  • 非游戏性对象 :负责增强游戏效果,但不是直接的游戏逻辑,例如UI/HUD/特效/声音。

  • 工具 :负责辅助编码,例如日志工具,调试工具。

在《ATD》游戏项目里,我是这样设置游戏对象目录的:

Unity《ATD》塔防RPG类3D游戏架构设计(一)

注:“个体”在《ATD》里的术语表示游戏对象单位。

《ATD》 游戏机制


通过分析《ATD》策划案,确立了两种需要实现的基本游戏机制:

Buff机制

和策划商量后,策划制作了下面一张含所有Buff属性的Excel表:

由于策划还没想好Buff名字,直接套用装备或者技能名字来命名Buff。

Unity《ATD》塔防RPG类3D游戏架构设计(一)

首先,使用了一个数据类型BuffData,用于完全映射Buff在表格的所有属性:

public class BuffData
{
public int ID;
public string Name;
public int HpChange; //血量变化
public double HpChange_p; //血量百分比变化
public int AttackChange; //攻击力变化
public double AttackChange_p; //攻击力百分比变化
public double AttSpeedChange_p; //攻击速度百分比变化
public double SpeedChange_p; //速度百分比变化
public int HpReturnChange; //血量恢复数值
public double HpReturnChange_p; //血量百分比恢复数值
public int AddReviveCount; //增加复活次数
public bool isDecelerate; //减速
public bool isVertigo; //眩晕
public bool isParalysis; //麻痹
//...等属性
}

然后我们就可以用一个 List<BuffData>来存储表示所有Buff种类。

为了读取Excel表,并根据读入的所有Buff种类属性来初始化 List<BuffData>,于是就引入了一个BuffDataBase的全局单例类来负责此事:

//全局单例类
public class BuffDataBase : MonoBehaviour
{
//读取excel插件生成的json文件
public TextAsset buffDataJson;
//存储BuffData的列表
private List<BuffData> buffDatas; //全局单例实现
//... //根据ID获取相应的BuffData对象
public BuffData GetBuffData(int ID){
//...
}
}

为了表示游戏对象得到/失去一个Buff而从BuffDataBase找到并拷贝一份BuffData对象/释放掉一份BuffData对象显然是不明智的。(BuffData所占空间大,开销大)

正确的做法应该是使用索引/引用的方式,例如某个游戏对象持有3号索引,则表示它当前受一个ID为3的Buff影响。

为了引入Buff的时间有效性,则进一步封装索引,于是编写了下面一个Buff类:

public class Buff
{
public int ID; //BuffData的ID(索引) public double time; //持续时间
public int repeatCount; //重复次数
public bool isTrigger; //是否触发类型
}

因为每个Buff的时间有效性都有所不同:有些Buff是一次性触发Buff;也有一些是持续性Buff,持续N秒;还有一些是被动buff,永久生效。

所以我这里就总结了个规则,Buff主要分为两种类型:

  • 持续型(Non-Trigger):开始对属性造成生效影响一次,有效时间结束时造成失效影响一次。例如一段时间内增加攻速Buff
  • 触发性型(Trigger):有效时间内,每一帧对属性造成生效影响一次。例如一次性伤害Buff,光环Buff。

然后Buff的有效时间取决于2个属性:

  • 持续时间(time):每帧持续时间减少DeltaTime
  • 触发次数(repeatCount):每帧触发次数减一

当一个Buff对象,持续时间 <= 0 并且 触发次数为0,则应视为失效。特殊地,触发次数为-1时,表示无限时间。

这样Buff/BuffData/BuffDataBase基本构造就出现了:

整个游戏同种类Buff只用存储一份BuffData;但是可以有很多个对象持有索引/引用,指向这个BuffData。

游戏对象持有Buff对象,通过BuffDataBase访问BuffData的数据,然后利用这些数据对游戏对象属性造成影响。

Unity《ATD》塔防RPG类3D游戏架构设计(一)

看到这里,可能会有人想到前面有个问题:对于任意一种Buff,它往往有很多属性是false或者0,使用这种完全映射会不会很影响空间占用或者效率。

  1. 首先,空间占用绝对不用担心,因为前面BuffDataBase机制保证同种Buff只有唯一BuffData副本,其所有BuffData总共占用量不过几kb而已。
  2. 其次,至于效率,例如说某个Buff对某个游戏对象造成影响,因为是完全映射,所以需要对该游戏对象每个属性都要进行更新,其实这也并不是太糟糕。

    而且只要游戏对象有比较好的Buff计算方式,可以让一个Buff对象的整个有效周期只对对象造成两次影响计算(生效影响,失效影响),避免每帧出现影响多余的计算,这样就很不错了。

Skill机制(技能机制)

可以说技能是我比较头疼的部分。

看到那千奇百怪的Skill需求时,然后才总结出大概这几个分类:

  • 主动Buff技能 = 主动释放,生成一个Buff
  • 被动Buff技能 = 初始化时,生成一个Buff
  • 召唤技能 = 生成一个游戏对象
  • 指向性技能 = 主动释放,对锁定的目标生成一个Buff

最后我决定使用继承接口的方式来实现Skill:

Unity《ATD》塔防RPG类3D游戏架构设计(一)

技能接口:

public interface ISkill
{
// 技能初始化接口
void InitSkill(Individual user);
// 使用技能接口
void ReleaseSkill(Individual user);
/// 技能每帧更新
void UpdateSkill(Individual user); /// 技能是否冷却
bool IsColdTimeEnd();
// 技能冷却百分比
float GetColdTimePercent();
}

需要注意的一点是,技能并不是主动释放时调用一个自定义的技能函数即可完事:

例如持续性的范围技能,需要每帧调用散发Buff的函数。

所以一个ISkill对象 该有这3种重要的接口方法:初始化/主动释放/每帧更新

下面是其中一个派生类的具体实现:

由于一开始设计考虑不足,Buff技能类暂时包含了ActiveBuff技能类和PassiveBuff技能类的功能。

// 示例:Buff技能类
public class BuffSkill : ISkill
{
public int buffID; //目的Buff
public bool isAura = true; //光环
public bool releasable = true; //是否主动释放
public float range = 0.01f; //范围 private float coldTime = 5.0f; //冷却时间
private float timer = 5.0f; //冷却计时 //构造方法
public BuffSkill(int buffID,bool releasable = true,bool isAura = true, float range = 0.01f)
{
this.buffID = buffID;
this.isAura = isAura;
this.range = range;
this.releasable = releasable;
} //初始化技能
public void InitSkill(Individual master)
{
//非光环的被动buff
if (!releasable && !isAura)
{
var individual = master.GetComponent<Individual>();
master.GetComponent<MessageSystem>().SendMessage(2, individual.ID,buffID);
}
} //释放技能
public void ReleaseSkill(Individual master)
{
//主动buff
if (releasable && IsColdTimeEnd())
{
timer = 0.0f; Factory.TraversalIndividualsInCircle(
(individual) => { master.GetComponent<MessageSystem>().SendMessage(2, individual.ID, buffID); }
, master.transform.position, range);
}
} //技能每帧更新
public void UpdateSkill(Individual master)
{
//增加计时
timer =Mathf.Min(timer+Time.deltaTime, coldTime); //光环被动buff:每帧向周围range范围内的对象散发buff
if (!releasable && isAura)
{
Factory.TraversalIndividualsInCircle(
(individual) => { master.GetComponent<MessageSystem>().SendMessage(2, individual.ID, buffID); }
, master.transform.position, range);
}
} //得到冷却时间百分比
public float GetColdTimePercent()
{
if (!releasable) return 1.0f; return timer / coldTime;
} //冷却时间是否结束
public bool IsColdTimeEnd()
{
return timer > coldTime;
}
}

派生类的构造函数很重要,这样即使硬编码了4个技能派生类,通过不同的数据参数传入,也能产生更多不同的技能对象。

最后还应该再写一个SkillDataBase全局单例类,它负责读取策划写的技能配置文件,来初始化出来一些ISkill对象,以供游戏对象使用。

不过项目代码还没写完,因此项目目前是直接在SkillDataBase的初始化函数直接硬编码3个技能。


public class SkillDataBase : MonoBehaviour
{
//技能json文件
public TextAsset skillDataJson; //全局单例实现
//... //读取文件,初始化ISkill对象给英雄使用
public void InitSkillsData(){
//...TODO:读取文件来初始化英雄的技能 //目前硬编码给英雄赋予3个技能
HeroSkills.Add(new BuffSkill(6, true, true, 5.0f)); //主动技能:嘲讽Buff
HeroSkills.Add(new BuffSkill(0, false, false)); //被动技能:回血buff
HeroSkills.Add(new BuffSkill(14, true, false)); //主动技能:攻速戒指buff
}
}

以后的话,SkillDataBase的初始化函数应该是读取某种配置文件,然后生成若干个对应的技能对象分配给游戏对象使用:

Unity《ATD》塔防RPG类3D游戏架构设计(一)

仇恨机制

待更新

《ATD》 游戏模型


策划案部分摘取

Unity《ATD》塔防RPG类3D游戏架构设计(一)

Unity《ATD》塔防RPG类3D游戏架构设计(一)

Unity《ATD》塔防RPG类3D游戏架构设计(一)

分析了策划案后,显而易见里面划分了这4种游戏模型:

英雄怪物陷阱

继承实现游戏模型

最初想到的是使用继承的方式来实现这些游戏模型(如图):

Unity《ATD》塔防RPG类3D游戏架构设计(一)

然而考虑到现在的英雄/怪物/陷阱/塔类型已经足够太多了,而且以后还可能会扩展更多。

若用继承的方式,其派生类数量将到达一个小团队难以维护的地步。

至于之前设计Skill机制的时候,为什么反而采用继承的方式,原因如下:

  1. 策划案里,Skill的种类只有8种,所以需要编写的派生类比较少,而英雄/怪物/陷阱/塔所有种类总共加起来有二十多种。
  2. Skill不是GameObject,没有Unity提供的GameObject-Component机制,不太方便接纳组件(除非自己再实现一套组件模式)。
  3. 实际上,还有个设计Skill的思路就是把Skill设计成一个行为树,通过组合节点来生成一个Skill。然而因为当时急于实现,于是抛弃了这个想法。

首先为了统一术语,避免游戏模型和Unity的GameObject弄混淆,我们定义了一个称之为 个体(Individual) 的名词,来表示一个游戏模型单位。

组合实现游戏模型

再想到Unity的GameObject-Component机制,于是最后我采用组合组件的方式来设计这几个游戏模型。

那么如何表示一个个体游戏对象呢?

首先我们需要编写一些个体游戏对象必要的组件脚本类。

对于一个个体游戏对象,它可能由如下图构成:

Unity《ATD》塔防RPG类3D游戏架构设计(一)

一般来说行为和输入都应该放在一起统称为控制器,然而实际上在游戏里,输入来源可能是玩家,也可能是AI,因此把个体对象行为和输入分离是个好的选择。

也就是说它得有属性,行为,操控行为的输入,还得可以容纳Buff机制,Skill机制和装备机制。

根据这些需求分化出来不少组件类:

Unity《ATD》塔防RPG类3D游戏架构设计(一)

然后为了解耦各组件的依赖关系,特别是跨游戏对象的组件依赖,于是还额外引入了一个 消息系统组件 ,实际上就是用于实现观察者模式。

每个个体对象都必须带一个消息系统组件,且其他编写的组件类基本上都依赖这个消息系统组件。

例如,A个体用指向性技能对B个体进行释放实际上的行为是:

由A个体的 技能系统组件 发送消息给A个体的 消息系统组件

然后A个体的 消息系统组件 把消息再转发给B个体的 消息系统组件

B个体的 消息系统组件 再把消息通知给 Buff系统组件 ,从而让B个体受到该Buff影响。

组合实现设计结构

最终个体游戏对象的组件依赖关系图:

Unity《ATD》塔防RPG类3D游戏架构设计(一)

然后通过一个GameObject然后添加好模型,然后放置一些组件从而组合出来一个个体游戏对象。

一个怪物个体游戏对象示例:

Unity《ATD》塔防RPG类3D游戏架构设计(一)

结语


《ATD》本来只是社团部门内提出的一个Unity游戏项目,而我负责这个项目的程序架构设计。

然而中途开发因为不少事,我们不得不放弃了这个项目。

感觉到有些可惜,因此才想得写点东西总结一下开发这个项目时的经验。

GitHub - ima-games/ATD: Unity RPG+塔防3D游戏

第二篇:Unity《ATD》塔防RPG类3D游戏架构设计(二) - KillerAery - 博客园

上一篇:CURLE_OPERATION_TIMEDOUT libcurl 错误码28– 操作超时


下一篇:基于 jQuery 实现垂直滑动的手风琴效果