对于gameplay来说,本身就是个大循环,一定频率进行tick,接收来客户端或者其他服务器的rpc,处理逻辑,然后数据落地以及发送数据给客户端或者其他服务器,一般gameplay来说在同一个进程里都是同步的方式去编写,同步的实现大多数是单线程的,或者使用coroutine来实现actor这种模式。大部分游戏交互都是比较多,所以不论service和service之间的交互还是玩家和玩家之间的交互,如果考虑多线程的同步的问题,会非常复杂以及很容易做错,所以一个service内同一个时刻都是在一个线程中执行的。
针对mmo或者一些竞技类游戏往往有场景管理的概念,就是游戏AOI,比如一个玩家移动,需要告诉周围所有的玩家,复杂度在nn,如果减少这个n,就有了AOI算法,比如九宫格,十字链表等,如果刚开服的时候很多人挤到一个主城中,就算采用九宫格和十字链表等AOI等算法,往往同屏内玩家数量还是很大,客户端渲染的单位数量比服务器少一个数量级的,所以场景管理这里还可以有个分线的做法,玩家多的时候,不同线不可见,玩家少的时候进行合并。
如果做帧同步一些关键点为表现要和逻辑分离,随机算法和随机种子的一致性,数学库浮点换定点,三角函数采用泰勒展开或者查表法,需要保序的容器,timer不能基于钟表时间而需要帧timer,以及防作弊(一般都是投票法,或者服务器跑个验证端)
现在很多游戏在线更新bug甚至不停服更新慢慢变成一种强需求了,实现这种方式主要使用脚本热更新,热重启+逻辑内存以及ab服切换来实现。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)