FPS Sample服务端技术点

FPS Sample服务端技术点

---

FPS Sample是一个由Unity官方出品的FPS类型的教程游戏，整个教程游戏的制作水准无论是从画质还是网络同步效果都是比较高的，并且完全开源。游戏中有3个大的技术框架及其使用值得学习

1. High-Definition Render Pipeline(HDRP).这是unity新推出的两个渲染管线中的能够取得较高画质的一个，从游戏的实际运行效果也可见一斑。
2. Data-Oriented Technology Stack (DOTS).这也是unity力推的一套提升游戏运行效率的技术，基本包括：①Entity Component System (ECS)机制 ②C# Job System ③burst compiler。youtube上面有一些测试视频能看到有时DOTS能够为场景提供几十倍的性能提升。
3. 状态同步机制。FPS Sample并没有特别复杂的服务端架构，仅仅是客户端连接上服务端，两端同步指令和状态数据。这个同步的过程正式这篇文章想要描述的主要内容，下文以每一个技术点为小节展开。

基本信息

考虑到实时性，FPS Sample也使用了UDP作为战场内数据同步的传输层协议，为了防止丢包，做了ACK机制和数据重传机制。这个数据重传并不和TCP一样丢了某一帧的数据就再把那一帧的数据重发一份完全一样的，毕竟在实时性很强的射击游戏里面，重传之前的老数据的意义也不大。FPS做的重传方式是将重要信息重传，譬如服务端想要下发生成entityA的一个命令，服务端会一直向发往客户端数据包中写入创建一个entityA的命令，直至收到客户端回复了创建entityA的ACK。在服务端做的另一个方面就是尽量使用一些持续的状态，而不是一个瞬发事件。客户端对于防丢包做法就是传输冗余数据，每一帧向服务端发送用户输入的时候把之前两帧的用户输入再次传输。由于用户输入数据量很小，重复传输用户输入可以很有效的防止丢包，如果一次丢包的概率是$10^{-5}$，那三次都丢包的概率就只有$10^{-15}$了。

#客户端预测回滚
在FPS Sample中，服务端有着绝对的权威，也就是说客户端并不会上传任何本地信息譬如英雄的血量、位置等，而是由服务端下发到客户端。但是这样就会造成一个问题：客户端接收到用户的输入并上传到服务端，服务端处理之后将整个数据快照发放到客户端这样一个流程至少需要一个rtt (Round-Trip Time)，这还是在忽略服务端处理时间的情况下。这样的话很多时候都会给用户一种很卡的感觉。为了解决上述问题，FPS Sampe使用了比较常见的“预测回滚机制”。预测回滚机制包含两个部分，①一个是预测：客户端接受到用户的输入之后一方面将用户输入上传到服务端另一方面会按照和服务端一致的逻辑执行用户输入，这样的话无需等到服务端回复消息玩家控制的角色就可以响应用户输入，能够有效的提升用户体验。②另一个是回滚：单单有预测的话可想而知会造成客户端和服务端数据不一致，所以当服务端快照到达的时候，客户端会先将玩家控制角色的状态设置和服务端完全一致，然后将服务端还未处理的（因为rtt的存在）消息再走一遍预测逻辑。预测回滚机制只对本地玩家控制的角色生效，并不会对其他玩家控制的角色（也就是敌人）起作用，并且在预测的时候并不会创建新的entity，譬如在用户按下鼠标开枪的时候，客户端仅会播放开枪的动画而子弹entity的生成还是需要等到服务端通知才会发生。
为了定位哪些消息是服务端处理了的哪些消息服务端还未处理，客户端会维护几个变量，名称和含义如下表所示，这几个变量的主要逻辑都存在与ClientGameLoop.HandleTime(f