4.5 支撑游戏的机制与系统在线视频

在接下来就是游戏的几个机制和系统

一个就是时间

时间我们这里说是有一个TimeUtility类

我们下面再大概看一下几个系统之间

这个我就简单说一下一会我们再看看吧

这个就是场景的子系统

场景子系统一般来说

场景主要做的事情就是

它得负责把这个场景加载进来

然后能负责实例化这个场景上的各种对象

然后再显示出来

另外一方面就是涉及到场景切换

场景切换一般就是把旧的场景做一个清理

然后再加载新的场景

然后在负责初始化

就是主要就是做这几件事情

然后我们这个里头就直接用了

就直接用了unity的场景格式

然后另外一个是资源

资源子系统

一般来说是比较复杂的

就是因为我们可能需要把3D资源

都组织到就是得分类

在不同的地方

可能会用不同的资源

我们就会对它做一些组织

我们这里头会涉及到几类

就是引擎能识别的资源

还有那就是刚才我们说的原始资源

这个就是我们自己要用的

就放在这个StreamingAssets下

然后另外一个是资源打包

这个我们这个Demo里头是没有包括的

但实际做游戏的话

基本都会涉及到这个

就是正常美术做的

比如说散的每个贴图

它的粒子系统

比如说特效模型

这些还都是一个一个的那个资源文件

我们一般到发布的时候

我们会把所有的这些资源都要达成

比如一个压缩包这种

然后Unity的话

它本身已经提供了一个叫

AssetBundle这样的机制

我们就会把那些资源都打到这里头来

然后再下一个就是

资源会涉及到资源的加载

因为资源的加载对前端来说

可能是一个比较关键的

就是加载资源就有几种方式

就是有同步的

同步的

这种加载呢

它就是就相当于是怎么回事

就是我在调这个的时候

我这个游戏当前就是类似于就是卡着了

所以加起来多长时间

它是直接影响我这个游戏的帧率了

这样就是如果假设你的资源

加载需要很长的时间

同步加载就会感觉到明显的卡顿

这个时候我们就需要考虑两个策略

两个是可以就是

就是是不一样的

就是可以分别去选择

一个呢就是我们可以做资源的预加载

其实就相当于我在切这个场景的时候

我在进场景之前

我把我所有需要的资源

我就提前加载好

这样我要用的时候我就不用再加载了

这样这个时间

就不会在游戏过程中体现出来

另外一个就是做这个异步的加载

相当于我假设我现在

看到一个NPC进入我这个视野

我需要创建它

那么我先去加载资源

但这个时候我不会等

我只是发起一个请求

然后等这个资源创建好了

它还会有一个回调过来

然后我们才实际去创建这个NPC

在这个形象

这就是异步

然后这个加载根据打包和不打包的话

unity是有一个差别的

前面说到那个预加载的话

就会对应就会有一个资源尺

因为我提前加载的资源

我肯定需要有一个地方就是保存着

到后面用的时候就不需要重新加载了

还有一个跟游戏相关的就是像NPC这种

然后我们可能会把它跟它的资源

对应的这个对象也一起做一个缓存

所以有时候会设计得有个对象尺

然后还涉及到这就是游戏对象

这个就是玩家和这个

NPC这个在传统的游戏里头的

我们其实比较多的会使用继承

但是现在呢

就是越来越多了

大家又是推荐

就是不要去用这个继承这种方式

而是多用组合

那unity呢

实际它用的是ECS的模式

然后ECS模式

现在应该还在发展中

这个ECS最早应该是07年的时候

也有一些人就是在网上开始提出

就是重新思考这个游戏对象的设计

到底应该采用什么方式去设计

那就是涉及到一个问题就是早期吗

因为那个时候就是面向对象

是比较主流了

大家很自然的

而且有

因为这个东西

它又叫游戏对象

所以很自然的大家就

按照面向对象的思维去考虑

就是上来就进行分类

然后再按照父子关系好

我才这样去做

然后但是做久了之后呢

大家发现一个问题就是我大概举个例子吧

就是

比如说我们游戏里头

有像一般游戏里说都会有NPC

然后也有可能会有陷阱

实际它们都是属于游戏对象

然后如果按照传统的这种方式呢

我们往往会一开始

就会把游戏对象可能分成一个

静态游戏对象这是一类

然后另外一类叫动态的游戏对象

这个从概念上来说是很自然的

就是因为陷阱是不会动的吗

NPC都是可以动了

所以我们就会这样去猜

然后静态的下面呢

可能又会分成各种各样不一样的

然后动态的呢

有可能会分什么NPC、分Boss、分Monster

不停的反正就有各种各样的分法

然后这样看起来都没什么问题

但是到了后面

有一天我们可能有个功能早期的功能

比如说AI这个

AI它肯定是需要跟游戏对象去关联的

那我们往往可能就会在

在NPC这一个继承分支上会考虑关联

一个AI系统

这个时候也没什么问题

然后我们游戏继续往后设计

到了有一天

然后我们策划同学可能会提出

说我这个陷阱最好也能有一个AI

一般来说

其实它这个需求都是很自然的

也是合理但是呢

由于我们采用的分类这种方式

我们发觉我们这个UI

只能够在动态游戏对象上才具备

那现在因为我已经分类了

我的代码都已经拆开了

我要比说静态的像陷阱

这个也需要AI怎么办

这个时候就会很麻烦

其实我们就不得不仿照那边

在这边相当于重新拷贝再写一份

这就是

这就是在游戏里头

会比较普遍的遇到的一个问题

然后后来呢

就是有一些这个同学

开始思考这个问题就是

就是我们的游戏对象

到底他是不是一个面向对象这样一个概念

慢慢的

大家开始发现可能不是的

就是你的对象可能不太适合

按照分类的方式去管理

它更像一个什么呢

就是有些对象的数据库

所以它们提出了这个概念之后

后面就开始出现了Ecs这种模式

以及这个就是面向数据的设计

然后我觉得这个顺序应该大概是这样

就是先有不用继承方式的这个ECS

但是那个时候

主要的考虑还是在考虑游戏的

就是游戏对象的归属

概念上到底他应该算是一个OO（面向对象）

就是这种OO风格的这种分类方式

管理的东西呢

还是是一种数据

就是首先开始倾向于这个

然后随后呢

就

大家逐渐认可

这种数据的这种组织方式之后

就出现了这个面向数据的设计

然后再往后应该就是游戏引擎层面

大家发觉这种模式带来另外一个好处

就是面向数据的设计

可以很方便的做到cache友好

因为其实这个是比较好理解的

因为OO的这种方式的话

我们都是按照Class把数据拆开了嘛

所以Cache

实际上它是一个关联存储

它永远都是加载它附近的这些数据

而我们

采用这种对象的方式把这个数据拆开之后

它实际上在内存上

可以认为它就是散落在各个不同的区域

这样的话就是如果我们

连续的去访问这些对象的时候

其实Cache基本是没法命中的

就是会不停的出现这个

Cache数据的这个替换

所以现在逐渐的就开始倾向于这个

这个大家后面

如果做unity相关的东西的话

可以去看一下unity的ECS模式

不过现在好像它这个还不是很成型

可能还是零点几的这么一个版本号

就是应该也还在不断的调整中吧

还一块下面一块是这个剧情

这个时间有点紧

我就

我就先不多说了吧

这个主要就是一个消息和消息处理

这个和我们传统的脚本稍微有点不一样

我们传统的脚本一般来说就是基于栈的

然后我们这里头

用的这个称之为剧情的脚本

它是基于队列了

所以这里头它主要带来了一个特性

就是因为它是基于队列了

我们可以比较方便地实现一个

类似协程的效果

这个一会再说

还一个就是AI

AI的话我们这里说用的是一个

比较简单的这个状态机的这么一个

这么一种方式

这个在游戏里应该也是比较常见的

从概念上来说也比较好理解就是

就这里

我大概列了有五个状态

就是休闲状态

移动状态追击状态

战斗状态和脱战

大家可以想一下游戏里的一个怪物

正常的一个情况就是比如说它正常

它就在那个场景里头

如果没有玩家过来

它是处在一个休闲状态

可能就是可以会做个什么动作

到处走走之类的

然后如果呢

它的视野里出现了一个玩家

这个时候呢

它就会进入到这个追击的状态

追击的状态里头

它主要要做的事情

就是它不断的接近这个玩家

直到进入它的技能可以打到这个玩家

就是所谓的攻击范围内

当它见到攻击范围内

它就会切到这个战斗的状态

然后战斗的状态里头

它主要要做的事情就是选择不一样的技能

然后去进行这个战斗

然后如果玩家比如说离开了

那这个时候

它可能还会再回到追击状态

还有一种就是这个可能在网络游戏里头

会比较常见的就是每一个怪

它其实它是从属于一个区域的

所以会有一个叫脱战的这么一个概念

就是如果这个怪它在追玩家追了很远了

它一看

发觉它离它的那个所属的区域太远

这个时候它就会进到这个脱战状态

防脱战状态做着一件唯一的一件事情

就是回到他之前的那个区域

这个大家玩

如果玩MMO游戏的话

应该是可以看到类似这样的