4.2 游戏循环概述(下)在线视频

前面游戏循环大概的介绍就是@

然后接下来能说一下游戏里的时间

然后游戏的时间的一般会有两类

就是绝对时间和相对时间

这个

这个分法是什么样的呢

我们如果大家之前用过Unity的话

应该知道Unity的这个Time类

它是有一个scale的这个属性的

这个属性默认是1

我们可以把它比作的调成二或者二三四

我们就会看到这个游戏的这个进程

它就会变快

所以这种时间呢

就是一个相对时间

说白了就是我们因为游戏

都是通过心跳来驱动的吗

然后心跳本质上

是一个对这个世界的一个模拟

那它的模拟实际上就是基于时间的

它是代表了一个

按照某种速度来流逝这个时间

然后就会产生对应的这个影响

所以如果我们把这个时间的速度加快

那整个这个演算的速度就会变快

就相当于比如说

我们可能一小时可能一分钟就可以过去了

这里头涉及到两个概念

一个就是比如加速播放

这个现在能来玩王者的话

应该就可能会知道就说

如果中间有掉线的话

但你在连上的时候你可能会看到

它有一个很快的这个各种动作都会加快

有一个快进的这么一个过程

这个就是涉及到相当于是一个重演

就是我们游戏逻辑上

按正常肯定都是在算当前的事情

但是有时候呢

可能会涉及到重演

然后和重演相对应的另外一个是反演

就是说这时间倒流

其实我们实际实现的时候确实会比较难

然后像反演

这种的话

最终可以无缝做到的其次就是像录像一样

就是每一帧你把所有的状态都记下来

这样的话就无所谓了

你可以随意跳到任何一帧

那和你刚才说的那个

比如说记住一千人的一帧可能也是没事的

但是你可能不是每一帧都记

你是结合一下

然后我们这里说到的这个

真正反演的难度恰恰也是来源这个

我可以简单举个例子就是比如说

假设我在刚刚那一帧里头有一个NPC

它比如说被杀死

那就是它就消失了

那实际上

当我们直接

如果我们没有做任何记录

然后我我根据我的操作往回反演的话

到这一帧的时候

我只知道有一个Npc消失了

但是我恢复回来之后

我发觉这个NPC它有很多的信息

其实都没有

原因就是因为

我们实际上是我们前面从演的时候

每一帧都是一个对它

之前的整个历史信息的一个积累

除非我们能真的把这个记下来

否则的话

这个难度是很大的

所以如果大家玩游戏的时候

发现哪个游戏要是做了这个

时间倒流的功能的话

一般来说

他们是技术上应该算是比较先进

反正我们很少做这个

另外一个是这个帧时间和实时时间

帧时间的话就是每帧

因为我们说了

就是由于循环里头都是各种各样的Tick嘛

那么Tick就是每一帧里头

一般来说

一般来说我们取一帧的这个时间

然后跟上一帧然后计算

这样我就大概知道我流逝了多久

然后我们的逻辑实际上很多时候

是一种是以这个每一帧这个时间

作为步长然后去演算

所以在游戏里头

很多时候我们实际上

使用这个帧时间就够了

那么另外一个是实时时间

就是任何时候你去取时间

就是任何时候你去取时间

都是取到的真实的流逝到这个点的时间

用这种实时时间呢

我这里就举一个例子

一般我们假设我们在

因为游戏逻辑的Tick里头

会做很多运算吗

如果假设这个运算量很大的话呢

因为我们比方假设我需要

每秒钟一减三十人

那么每一帧的话

只能够最多就是有三四毫秒的时间

但如果我这里运算这一帧

可能需要五十毫秒的话

我在这一帧里真的把这个预算全部做完

那我的帧率实际上就等于下降了一半

所以有时候

我们会把这个就是逻辑上的有些处理

会需要进行分帧的处理

其实它本来是一个操作

可能会需要分到若干帧里头去完成

它们这个时候怎么做呢

我们就是需要这种实时的时间

那我就会在这个运算的过程中

会经常去看已经算了多久了

按照我们预想的这个时间片

如果这个时间到了的话

那我们可能就要把这个运算先暂停一下

然后到后面帧再继续处理

这就是实时时间

那还一块是这个高精度的时间

这个可能大家学计算机的话应该都比较清楚

就是这样就是硬件相关的

这个时间都是可以做到微秒一级

我们实力能用的话

往往主要是用在性能分析里头

就是游戏在运行的时候

比如说有可能会觉得很卡

这个时候

我们就会要分析它到底是怎么回事

这个时候就需要去度量，比如说

每一个函数它到底开销是多少

这个时候就需要使用到这个微妙级事件

还有一块是这个垂直同步

垂直同步的话

现在其实

现在的硬件其实是不需要的

这个应该是早期就是以前那个

原来那个CRT的这种显示器

因为它是那个就像我们右边这个图上一样

它实际上是靠那个电子枪在这个屏幕上

就是一行一行的这个快速的这个扫过

然后实际屏幕相当于是依次这些点在显示

所以如果

在这个屏幕的这个电子枪扫的过程中

如果我们更新了它的帧缓存的话

那就是刚才我们看到这两个颜色

就是有一个深色一点的

下面三号是蓝色的

如果假设在这我们更新了这个缓存的话

那我们可能看到的就会是这样

就是上面的这个看到的是上一帧的

然后下面三行将看到的是下一帧的内容

就会出现这个帧的这种撕裂的现象

所以以前为了解决这个问题的话

我们一般是需要等这个每一屏电子枪扫描完之后

它电子枪它会有一个

回到屏幕左上角的这么一个时间

这个分支为垂直同步

所以以前就会，通常游戏的帧率

在以前会需要跟显示器的这个帧率

保持一个倍数关系

就是为了做到我们每次更新

都是在这个垂直同步的时候

去更新这个缓存画面就不会有问题

现在其实一般是没有这个概念了

但是就是实际是没有这个需求

但一般在引擎里头依然接受保留了这种方式

包括Unity

它也还会提供三十帧和六十帧这样的

这种标准帧率

一般移动游戏的话

我们现在是三十帧每秒

然后下面提了一个就是

我们前面其实一直默认游戏循环

都是有渲染循环来驱动的

实际上肯定从驱动的角度来说

应该说它总会有它的驱动

但是因为我们实际上除了单线程之外

现在还有一种是多线程的运行方式

所以我们只要是可以在渲染循环里头

只是做一次驱动

就是说比如说启动

让我这个游戏逻辑

然后游戏逻辑能自己的是可以

在自己的循环做的

这个它有一些好处

好处的最典型的好处就是

比如我们前面提到分帧处理这种事情

用游戏循环

如果跟渲染循环分开的话

就意味着游戏循环

它不会影响我们看到的帧率

这个时候一般人来说

可以做一个帧率更稳定的游戏的话

这个时候会比较容易

然后游戏循环

就可以允许它一个

和这个引擎不一样的帧率去工作

比如说我们想要一个

很高战力的这个视觉效果

比如说六十帧每秒

但是我们游戏逻辑

其实往往可能十帧每秒就够了

这样的话

我们就是通过这种方式可以去做这个分离

然后

缺点是啥

其实主要就是复杂性

这个可能大家如果学这个计算机的话

会比较明白

因为对于并行的这种方式的话

因为游戏的逻辑实际上

是给引擎提供数据了

所以如果你在两个线程里头的话

就必然会涉及到数据的这个

数据在这两个线程之间如何同步的问题

如何同步的问题

这个就会引入很多很多

比较麻烦一点

还有就是刚才我们提到

在说那个游戏循环的时候

我会说为什么我们会选择更简单的方式

这就是一个多人协作的一个问题

可能就是不是一个技术性的问题

但是是一个叫软件工程上需要考虑了

当你是多人协作的时候

简单有时候对整个产品的质量

比采用更好的技术

可能就是这个影响会更大一些

然后这里我简单说一下异步编程的复杂性

我记得咱这里面应该是有一半的同学

都是都是科班

所以这里头我就简单说一下吧

还有最主要的一种就是说

这个锁的话

一个就是如果假设我整个Tick加一个锁

这个时候很显然就是性能会比较低

那就相当于是

如果我两个线程的每一个Tick

都是直接是一个锁的话

实际上

这个时候就等于是它们没有多线程

它已经被串行化了

所以一般锁的话

肯定要求力度会比较

就是你只锁真正需要同步的那个

但这个时候就是逻辑上就会非常复杂

所以很容易就会写死锁和活锁

这样的东西来

然后

这个可能是跟不同软件是有一些差别

在游戏软件里头

我们很少使用这种锁的这个方式

原因就是因为游戏的逻辑它会比较复杂

它和传统软件可能不太一样

这个我就算多说一点

就是按传统软件

一般比如说它会跟一个行业相关

它会有一个对应的就是我们所说的

它会有个业务模型

而传统行业的话一般业务模型

它会是基于稳定的

所以就是长远来看

它的很多东西就是就做了后面

它的变化就会比较少

除了你说最上层直接面向用户的层面之外

所以在那个层面呢

所以大家是可以使用比较复杂的这种技术

因为这个技术不会被蔓延到所有的地方

但是游戏呢

还是一个比较怎么说呢

因为游戏所有的设计都是策划来做

然后策划

他们做游戏实际是有一个追求

就是我就是要做的和别人不一样

所以这个东西它实际和软件工程上面

求稳是一个完全冲突的

所以游戏里头

如果大家将来去做这个游戏的话

应该会体会到这一点就是游戏逻辑

真的是就是非常非常复杂

是一个方面

另外一个就是随时都有可能变化

所以这个时候

我们会采用另外一种方式来处理

一般就不会使用这个加锁的话

这个回调链

这个大家就大概看一下就可以了

我就不细说了

我就好像不是很会说清楚

我们说一下

刚才说的另外一种就是在游戏里头

如果世界有多现实

我们可能会比较多地采用了一种方式

是消息队列就是比如说

假设这里有四个线程

不然我这边有一个主线程

然后让大家尽量会保证每个线程

运行过程中没有其它的依赖

如果有依赖的时候呢

我们会在线程之间做一些消息对列

那么消息队列本身是有加锁的

但是这个时候这时锁就会比较简单

因为它只是锁整个队列就可以了

它就不会在逻辑上需要加速

然后逻辑上比如说我这个线程A

需要和另外一个线程B通信的话

那我们就会发一个消息

然后转到这个消息队列里了

这个时候它会加锁

然后另外一个线程

它会按照自己的这个步调

然后从消息队列里头解锁

就把这个东西读出来

然后这样就可以起到

和全面加锁类似的这种通信方式

其实这种方式比较标准的

其实就是在

Windows的GUI里头就是这样

windows的消息队列

它实际就是这种方式来工作

那么我们在游戏里

当前端的话可能涉及不会太多

后端可能会更多一点

就会这种模式会比较常见

但是即便是这样的话

那我们一样还会遇到一个异步操作

比较难处理的问题

大家可以看一下这个图

就是我们假设有现成ABCD

然后现在我是主线程

然后现在ABCD呢

各有一个操作就是比如说

假设它们都在并行的执行

然后我的主线程上

现在假设我有一个另外一个操作

我这个操作必须要拿到了A的结果

B的结果

C的结果D的结果才可以做

那可以想象这个逻辑要怎么写

发到消息队列的话

A的操作肯定是在

这个消息对面里头取出来了

然后B的呢

也是在这个里头取出来

C呢也是在这个里头取出来

D的呢也是在这个里头取出来

我们可以知道就是取出来的时间点

肯定是不一样的

结果有可能是在第一帧取到了A的结果

帧B的结果

第三帧起到了C的结果

第四帧取起到D的结果

让我拿到A的结果的时候

我其实做不了我要做的操作

我拿着B的时候也做不到

拿着B的时候也做不到

只有到D的时候我才可以做

这样就意味着我前面三个操作的结果

我都不得不做缓存

这就是异步编程

在逻辑上会导致了一个比较大的问题

就是如果我们有操作的依赖

你就不得不在前面的这些操作结果做缓存

然后在最后再去处理

反正这个是我们所常用的

这种命令式程序的一个特点

如果是函数式程序

也许有别的解决方案

但是现在像我们好像基本上都是命令式了

所以会比较

多着会遇到这样的问题

另外一个就是调试和排错了这个困难

这个困难主要是因为如果调试的话

大家写程序应该都会用过单步调试

就是你可以一步一步的往下走

这样你就大概知道整个数据流

和控制流是怎么样的

但如果是一个多线程的程序

你就很难办

因为你在线程A里头单步的话

你是永远不可能走到线程B里头去的

所以这个时候你就会需要设很多的断点

然后自己放下来的时候还需要去分析

就是整个流程大概是什么样

这个大家在后面实际接触到的时候

应该会比较多

在体会到这个问题

我有些循环的大概介绍就是这些