求前辈指教。linux的套接字编程，这个程序运行，我照着源码敲，出现一堆错误。用的是vim和gcc

网游实现客户端同步，是通过让他们进入同一个地方而达到同步的，因为虽然每个客户端都是不一样的，但是他们进入的是同样一个服务器，我们要进入的是同样的一个地方，，所以这样就实现了各个客户端同步，玩游戏这种状态。

首先
帧同步
简单来说，就是相同的状态+相同的指令+ 按帧顺序执行=相同的结果。
状态：所有客户端确保逻辑一致，接收一样的随机种子（randomseed），一样的房间信息；
指令：服务器只负责收集接收每个客户端 *** 作指令（cmd），转发指令，服务器以恒定帧率（30帧1秒）派发指令，没有指令或指令没有变化也需要派发；
执行：真正游戏逻辑由各个客户端单独计算 ，客户端需要收到服务器派发的指令才能推进逻辑，没有收到指令时不能推进逻辑（LockStep）
顺序执行
帧同步会必定按到从第一帧开始一帧一帧的执行，才能保证运行结果一样，跳帧会导致逻辑不一样，如果玩家网络不好，则会在当前帧等待至下一帧的接受，如果丢包超时，则会再次发出需要帧的请求。
追帧
什么是追帧：当前玩家播放到帧比服务器的帧落后时，服务器下发多个帧，玩家便要开始快进到服务器当前帧
为什么要追帧：如果网络波动，服务器会有最晚的接受帧时间，
做法：超过则下次发送多个帧，然后快进播放（多次DoAction），快进期间，不播放特效音效等不影响运行结果的逻辑
重连
做法：接受从0开始所有帧重新快速播放到当前帧，如果帧列表count大于规定速度则按照最大速度播放，否则按照剩余的count播放相应次数的帧。
优点
第一，它的开发效率比较高。如果你开发思路的整体框架是验证可行的，如果你把它的缺点解决了，那么你的开发思路完全就跟写单机一样，你只需要遵从这样的思路，尽量保证性能，程序该怎么写就怎么写，服务端逻辑简单，只需要负责转发指令，压力也小。
资料来源于网络若侵权联系删除

首先要知道游戏类型是什么，然后知道承载人数是多少，以及开发周期多少。需要根据这些来决定游戏架构和技术选型。

对于gameplay来说，本身就是个大循环，一定频率进行tick，接收来客户端或者其他服务器的rpc，处理逻辑，然后数据落地以及发送数据给客户端或者其他服务器，一般gameplay来说在同一个进程里都是同步的方式去编写，同步的实现大多数是单线程的，或者使用coroutine来实现actor这种模式。大部分游戏交互都是比较多，所以不论service和service之间的交互还是玩家和玩家之间的交互，如果考虑多线程的同步的问题，会非常复杂以及很容易做错，所以一个service内同一个时刻都是在一个线程中执行的。

针对mmo或者一些竞技类游戏往往有场景管理的概念，就是游戏AOI，比如一个玩家移动，需要告诉周围所有的玩家，复杂度在nn,如果减少这个n，就有了AOI算法，比如九宫格，十字链表等，如果刚开服的时候很多人挤到一个主城中，就算采用九宫格和十字链表等AOI等算法，往往同屏内玩家数量还是很大，客户端渲染的单位数量比服务器少一个数量级的，所以场景管理这里还可以有个分线的做法，玩家多的时候，不同线不可见，玩家少的时候进行合并。

如果做帧同步一些关键点为表现要和逻辑分离，随机算法和随机种子的一致性，数学库浮点换定点，三角函数采用泰勒展开或者查表法，需要保序的容器，timer不能基于钟表时间而需要帧timer，以及防作弊（一般都是投票法，或者服务器跑个验证端）

现在很多游戏在线更新bug甚至不停服更新慢慢变成一种强需求了，实现这种方式主要使用脚本热更新，热重启+逻辑内存以及ab服切换来实现。

不了解ET的，点击  >