游戏开发文章读后感

2017年7月16日:

http://blog.csdn.net/w174504744/article/details/50560892

大量在线的游戏服务架构的设计:

Gate:负责客户端连接以及将消息转发至GameServer

GameServer:主要的游戏进程,文中说做逻辑功能的话单线程就够了。

DBManager:实现数据库的读写,方便异步读写。

GameManager:负责管理所有的GameServer,GameServer之间的消息转发,提供广播到所有Game的功能。

客户端连接Gate,Gate连接GameServer,GameServer连接DBManager,GameManager管理所有的GameServer并通知所有的Gate。

https://www.zhihu.com/question/29779732

卡牌和跑酷类弱交互服务端,玩家和玩家之间的PK就是打一下对面的离线数据,所以直接使用HTTP服务器即可,客户端做简单的解析,每隔一段时间请求服务端的数据即可。

第一代游戏服务器:世界上第一个MUD程序,使用单线程无阻塞套接字来服务所有的玩家,每1s更新广播所有数据,可以使用LPC脚本定制。

第二代游戏服务器:发展流程就不介绍了,最终的形式如下:

第三代游戏服务器:无缝地图为标志,每个Node管理一块地图区域,在两个地图之间的地区由两个地图Node服务器AB同时提供服务。同时因为用户的位置飘忽不定,而Node服务器需要与用户通信,将玩家对象从Gate中提取出来便势在必行。整体服务器划分为三层,Node专注于场景,Obj专注于玩家对象,Gate专注于网络转发。

但随着发展,会发现Node的分布需要适应玩家的密度,手动调整很笨重,所以出现了动态负载均衡。由NodeMaster定时移动修改各个Node的边界。

http://blog.sina.com.cn/s/blog_ae4d86c801017yxs.html

简单讲述了一下计算复杂度随人数的规律,再说了一下几种划分方法,大同小异。

http://www.gameres.com/657543.html

RTS类游戏最主要的技术是同步机制。本文的重心也主要在此。

同步机制的分类:

Peer-to-Peer:就是冰封王座里的局域网,没有服务器,某一个玩家就是服务器。

Client-Server:所有的操作需要服务端确认后客户端才能模拟,延迟高卡顿会很明显。

早期的RTS大多采用LockStep方案来设计,标准的LockStep模式如下:

  • 每个玩家互相连接,整个游戏过程划分为一组turn指令帧,由玩家自我模拟
  • 游戏速度取决于网络最慢的那个玩家
  • 一个玩家掉线会影响到其他玩家

所谓Turn可以理解成一个回合,这个turn非常短,一般在100-200ms,玩家之间的操作指令都在一个turn间隔发出。

http://www.gameres.com/478430.html

这里提到了好几篇文章,都要认真看看,感觉作者十分的厉害!

帧间同步法:格斗游戏可以使用帧间同步法,乐观帧版本可以克服玩家掉线的问题,总的来说就是每秒使用许多个Turn指令帧,如每秒20次向服务端发送数据,服务端每秒40次向客户端返回数据。也有使用UDP的游戏,每秒上传50次键盘信息,丢了就丢了,后面过来的数据会覆盖前面的数据。

状态同步法:对于逻辑不需要精确到帧的游戏类型而言,允许每个玩家屏幕显示的内容不同,可以使用状态同步法。RPG的移动只需要“谁在哪里向哪里移动”,例如《魔兽世界》中差不多每s发送一次,别的客户端收到就会矫正一下位置。对于FPS和赛车类同步要求高一点,通常会用“导航推测算法(DR)”从客户端去预测修正其他玩家的位置。FPS类的射击通常是客户端本地判断是否击中,再发送给服务端判定。

状态同步分为“DR同步”和“非DR同步”前者针对FPS,赛车等激烈,对位置误差容忍小的游戏,后者对位置误差容忍大一些。

建议使用TCP,等游戏开始挣钱了再考虑改成UDP。

http://www.gameres.com/msg_454350.html

影子跟随算法

是由普通的DR(dead reckoning)算法发展而来。

屏幕上的“实体”不停地追逐它的“影子”,服务器向各个客户端发送各个影子的状态改变(坐标,方向,速度,时间),各个客户端收到以后用差值修正影子状态。

影子是跳变的,但实体是连续的,所以整个过程是平滑的。

帧同步:主要用于低延迟的网络情况,如局域网等。

状态同步:常见于FPS类游戏和竞速类游戏。

http://www.360doc.com/content/10/0927/11/3060981_56743919.shtml

说开服之后玩家最多,单服务器容纳的人数越多越好,比如开服第一天有1w,流失一半就还剩5k。

将服务器划分为如下,

gls:game login server,游戏登录服务器,要实现很多登陆排队功能,GM超级管理员登陆通道,限制用户登录,限制版本登录等…

db:缓冲+数据库。

center:所有组件都在此注册,在线玩家Session状态都集中存放。

角色入口:玩家登陆后的选择角色。

gs:game server最核心的组件,同一地图所有游戏逻辑相关的功能都在此。

gate:主要是建立和用户之间的长连接,做消息转发。

IM,关系,寄售:表示其他组件,负责对应的跨地图发生全局的游戏逻辑。

这个地方的划分倒让我认识到,gs主要负责地图间的交互,其他的跨地图的游戏内容需要额外的服务器来做。

发表评论

电子邮件地址不会被公开。 必填项已用*标注