效果图制作网站,用jsp做的二手交易网站,北京常规网络营销电话,用qt做网站可以吗写的非常好的一篇博文#xff0c;转载自https://www.cnblogs.com/murongxiaopifu/p/6376234.html
0x00 前言
16年年底的时候我从当时的公司离职#xff0c;来到了目前任职的一家更专注于游戏开发的公司。接手的是一个platform游戏项目#xff0c;基本情况是之前的团队完成…写的非常好的一篇博文转载自https://www.cnblogs.com/murongxiaopifu/p/6376234.html
0x00 前言
16年年底的时候我从当时的公司离职来到了目前任职的一家更专注于游戏开发的公司。接手的是一个platform游戏项目基本情况是之前的团队完成了第一个版本即单人模式的基础玩法但是之后对该项目的定位又变成了一个本地局域网的联机手游2-4个玩家。因此重写项目底层外加确定网络同步方案就成了第一件需要去认真考虑的事情了。那么本文就来聊聊网络同步这件事吧。
0x01 游戏同步中的主次
开发网络多人游戏是一件十分有趣的事情但是和单机游戏相比无疑增加了更多的挑战。
例如我们之前开发的单机版本并不需要多么担心作弊的问题。这是因为购买我们游戏的玩家假如我们的单机游戏不免费发布的话即便作弊影响的也仅仅是他自己的游戏体验不会影响到别人。 但是开发多人游戏就不是这样了为了保证让每个人都有好的游戏体验防止作弊总是需要去考虑的。
除此之外在开发多人游戏时我们还需要考虑如何“欺骗”玩家的眼睛让他们认为他们在同一个世界中。
当2个或4个玩家一起在手机上玩游戏时看上去他们确实像是在共享同一个虚拟世界在同一个世界中游玩。但事实却是玩家自己的手机只是对“同一个”虚拟世界的近似模拟。换言之他们的游戏世界每一个都是独一无二的只不过从外观上看起来像。
因此为了达到这种看上去近似的效果我们需要确认哪些状态是需要同步的只要同步了这些状态这个游戏世界就看上去一样了。而哪些状态是无需同步的即这些对象的状态是否同步对整个游戏是否看上去一样并没有特别大的影响。
在我们的游戏中玩家的各种属性、在世界中的坐标、游戏世界中的敌人各种属性、道具获取以及各种触发器的触发等等都有可能会对游戏的表现产生影响因此需要考虑同步但是像例如海底的水泡粒子效果、道具获取后的碎裂效果甚至是背景音乐则不会对游戏的表现产生特别的影响因此并没有必要去同步这些内容。
0x02 同步输入or同步状态
既然明确了不存在两个完全一样的游戏世界每个游戏世界无非都是近似的模拟。那么接下来我们就要来选择一个适合的网络同步方案以满足这种需求了。最基本的游戏网络同步模型大概可以分为以下4种画图水平一般见谅 client-server专用服务器 client-server玩家之一作为服务器 peer-to-peer peer-to-peer帧同步
client-server
上面的两种client-server模型的相同点都在于有一台机器负责整个游戏世界的模拟而这台负责整个游戏世界模拟的机器是谁则是这两者最大的区别。在我们的项目中我们借助其中一个玩家的手机作为服务器我们叫它Master主机而一般的玩家设备则被称为Client。当然更常见的一种情景是游戏开发商或发行商管理的计算机作为服务器这也往往需要更多的计算机和运维人员。
通常基于这种同步模型的游戏中客户端不能做出真正的决定。一个情景就是当客户端的玩家按下一个按键客户端并不会真正的执行影响游戏状态的操作相反操作会被发往服务器并在服务器执行它之后服务器将执行完这个操作之后的结果通常是游戏世界的状态变化返回给客户端。
由于大家都知道的网络延迟因此服务器和客户端并非时刻保持一致的为了使游戏玩家的状态变化自然主要是指玩家的位置、角度等状态我们使用的是一种基于插值的同步算法当然这种方式也常常被称为影子跟随算法
服务器间隔固定的时间向客户端同步状态数据客户端收到数据之后进行同步一般的属性数据例如血量等等直接根据服务器的值来同步。而诸如位置等信息在客户端则保存为ServerPosition或者称为影子而客户端的位置则不断向ServerPosition靠拢。位置同步的过程为了更加平滑要使用插值步进距为玩家的移动速度。因此虽然ServerPosition是跳变的但是在客户端的表现上却是连续平滑的。如下图所示左侧的画面为Server的状态右侧的画面为客户端的状态玩家和场景内的怪物位置通过Server告诉客户端客户端于是开始追赶Server发来的状态。当然将所有的逻辑放到服务器并经过服务器的模拟之后再将结果返回给客户端的过程会带来一些滞后感当玩家对操作的敏感度要求较高时这显然不是一个很好的解决方案。因此客户端的输入预测和服务端的延迟补偿开始得到应用。通过在客户端侧的输入预测可以让玩家的输入得到立刻的反馈。而延时补偿则保证了结果的正确性。这个过程可以基本概括为以下几个阶段
当玩家按下按钮时客户端立刻执行相应的操作例如开始播放某个动作或是开始移动。与此同时客户端还会向服务器发送一条包含了时间戳的消息。服务器经过一段延迟后收到了客户端发来的按钮被按下的消息于是服务器会回滚到按钮被按下的时刻在这个时刻执行按钮对应操作之后再重新模拟到当前时刻。之后服务器将当前的状态同步给客户端。客户端收到服务器同步过来的数据此时由于网络延迟的缘故客户端收到服务器的消息时也已经过去一段时间。所以客户端同样需要回滚到服务器发出消息的时刻并根据服务器发送的状态来修正自己的状态。
虽然这样做能够更好的保证玩家的手感但是我们发现无论是客户端还是服务器一旦收到消息包之后都需要回滚。而这种回滚机制相对来说较为复杂并且也不容易在已有的游戏中加入这种机制。
综上我们可以看到在这两种同步模型中服务器获取客户端的操作指令并在服务器内模拟整个游戏世界之后服务器是将服务器所维护的游戏世界内的状态同步给各个客户端因此这里主要是做状态同步。
Peer to Peer
Peer to Peer点对点同步模型是一种很经典的网络游戏网络同步模型。带有帧同步模型的Peer to Peer在很多RTS游戏中得到了大量应用不过在讨论帧同步模型之前我们先来聊聊一般的Peer to Peer。
相对于C/S模型拥有一个计算机负责整个游戏世界的模拟Peer to Peer模式并没有单一的计算机来负责模拟游戏世界。相反它将对游戏世界的模拟分配给了所有玩家因而每个玩家的客户端都在模拟着自己的游戏世界。这样做的一大好处在于玩家的输入总是立刻响应的我按下一个按钮按钮造成的结果便发生了同时我需要做的是将我的操作发送给和我相连的客户端让他们也去根据我发送的操作模拟游戏世界。但是这样做的一大弊端在于不能保证客户端看到的游戏画面是一样的。 例如上图上方的怪物射出的子弹可以通过画线来阻挡但是由于client1和client2都是在模拟自己的游戏世界因此延迟或是不同移动设备本身的性能问题就有可能会造成client1的画线操作同步到client2上时产生不同的结果。所以我们发现只是简单的让每个客户端模拟自己游戏世界就像单机那样同时简单的将操作同步给别的客户端至少在同步这个问题上是不靠谱的。
因此游戏行业大多会采用帧同步模型来保证同步的可靠性。很多早期的RTS游戏都采用了帧同步来作为网络同步的方案。至于为什么很多人在介绍帧同步的时候都喜欢把早期的RTS游戏搬出来作为一个例子呢我想各位看一眼RTS游戏的游戏截图就能猜到个大概了。 RTS游戏中常常伴随着数十上百甚至上千个逻辑实体单位如果采用状态同步的话数据量相对要大很多。但是如果只同步玩家的操作呢如果每个客户端在相同的情况下开始游戏并且运行完全相同的步骤那么客户端就可以不通过接收状态同步信息就能保证游戏的同步了。
这也是这种模型的一大优势我们除了发送玩家的操作之外几乎不需要再发送任何数据。这种同步输入的方式可以说非常适合RTS游戏因为它们有那么多的单位同步所有单位的状态是不容易的。 因此采用这种模型就可以把游戏的过程分为一个一个的回合。游戏的每一步都需要通过网络来收集所有玩家的操作输入然后再往下执行。当然一提到“回合”这个词大家想到往往是所谓的回合制游戏但事实上只要回合的频率足够快仍然是可以做出即时游戏的感觉。
当然由于没有同步游戏的状态而是同步玩家在游戏内的输入操作因此实现完全同步还是有一些事情需要注意的。因为一旦一个小小的不同步发生就会产生蝴蝶效应从而引起很明显的不同步。一个典型的例子便是我以前在开发一个战斗回放系统时发现由于一个士兵在寻路的时候稍微走到有点不一样的地方就导致了一场战斗的结果大不相同。
虽然我们目前的项目并没有采用帧同步的方案但是还是想和大家分享一点教训。例如不要使用浮点型数据这是由于舍入会造成误差所以建议各位使用整形数据。同样另一个又被重视又被忽略的是随机数的问题。大家都知道帧同步要保证随机数也完全一致。因此大家都会去同步随机数生成器的种子和它们的使用方式。但是一个潜在的可能性是某一方的非游戏逻辑对象使用了随机数生成器从而造成不同步。例如某一方的移动设备性能更好也因此屏幕上有一些额外粒子特效这些粒子特效是有可能会使用随机数发生器的如果这些游戏逻辑之外的对象使用了随机数发生器就会造成不同步的发生。 哦对了最后需要说明的一点是帧同步还可以和C/S模型组合使用我们可以通过服务器来转发客户端的操作数据而不必让各个客户端直接通讯。公司内有项目组采用的就是这种方案。
0x03 后记
当然以上只是一些基本的同步模型。在这里只是结合我们的项目经验和大家做一个简单的分享我想基于这些基本的模型还会衍生出一些别的方案。也欢迎大家来一起交流。
