网络程序场景101 VOL2

模式三 全同步模式（即时战略常用）

以经典的星际争霸为例，玩过的都知道，战斗中如果一个玩家掉线，其他所有玩家都要等待一定时长，直到60秒结束，时间到了掉线的就连不上来了。

RTS游戏的需求是，由于玩家此时控制的是大量单位，对于大兵团的框选，键盘发出的技能快捷键，按快捷键攻击选取地图上的点或者具体的兵等一系列操作都需要在每个玩家的游戏客户端上同步。

这里需要考虑的一个问题是，相对于FPS游戏，RTS游戏的操作量可能会大很多。FPS常用的键基本上就是ASDF+鼠标左键，次常用的可能就是1234+空格。而RTS游戏对于鼠标框选，1-9，Ctrl，鼠标右键，+各个兵种的快捷键一般常规都会有4-5个按键。这样的操作频率如果都需要发送到服务器端处理，并处理后返回给客户端，由客户端呈现计算的结果，会对服务器计算能力和网络延迟有较高的要求，好在一般RTS最多也就8个人一起玩，而且不是纯3D游戏，计算资源不会大量耗在GPU上。

星际1由于是局域网游戏，采用的是P2P方式广播，每个游戏客户端都广播玩家的操作给其他（最多7个）IP地址，当然这个封包肯定也是UDP的。游戏客户端收到其他地址传来的玩家操作动作后，由客户端计算这些动作对本机产生的影响（看到对方移动，被攻击）等，这种分布式模式能将计算量分担到每个玩家客户端上。而且客户端可以保存整盘游戏上所有玩家的操作行为到replay文件，在重播时在明确知道地图数据时，完全重播所有玩家的动作，这就是为什么replay文件很小的原因，一个replay文件基本可以等同于玩一盘游戏时网络交换的数量，一般只有几百K。包越小，包越少，都对提高程序延时有很大的好处。

此种封包方式的另外一个好处就是由于星际对战时屏幕上角色数量很多，极端情况会有全屏幕的角色，如果跟FPS一样去同步每个角色的动作是低效的；而像框选，右键移动这种动作作为封包作为同步的单位，可以较少需要同步的数据量，其他客户端拿到这样的数据后就能还原这个操作，让每个玩家屏幕上的动作是一致的。

我没有专门去抓过星际的网络封包，相关一些文章可以看看
The Revolution of StarCraft Network Traffic

http://choongsoo.info/docs/starcraft2.netgames12.pdf

未完待续

---

文章来自微信平台「麦芽面包」
微信公众号「darkjune_think」转载请注明。
如果觉得有趣，微信扫一扫关注公众号。