服务器端的游戏场景管理

最近在想怎么在服务器端组织游戏场景。

服务器客户端地图位置同步的2种方式:

1。服务器只存对象的当前位置。

Client发来的消息分为两种:开始移动和定期同步。

开始移动:目的点。

定期同步:当前点和刚经过的关键点。服务器验证后把这个信息再广播给视野内的Client。

role的位置改变是由客户端来触发的。视野内其它玩家的路径信息,可能是服务器转发的,也可能是客户端自己寻的。

2。服务器保存对象的当前位置和行走路径。Client向服务器发它要走的路径。服务器把这部分信息merge到现在的行走路径中。然后定期根据路径刷新,并广播。我觉得2比1好,没有必要让客户端多发那个包。

今天看到一个很不错文档,http://theory.stanford.edu/~amitp/GameProgramming/,让我大开眼界。一个很基本的问题,地图的阻挡信息如何表示?最简单的做法是地图画格子,每个格子要么是0,要么是1,代表可走与不可走,然后在格子上做A* 。另一种方式是,在上述的基础上,把阻挡以多边形的方式存储,那么寻出的路径的折点恰好就是多边形的顶点,但是貌似没见谁这么用,而且游戏里如果玩家真这么走,太别扭了。还有就是导航网格。UE3的文档中对这个有很详细的介绍:http://udn.epicgames.com/Three/NavigationMeshReference.html

算AOE以及做视野内广播的时候也是,如果不是把对象划到格子里,按格子做广播,那么采用某个查找树比如红黑树就很不错。查找树因为是有序的方式组织数据,所以天然的支持范围查找,分别对x,y做两次范围查找就可以得到想要的结果,例如TreeMap\>>。最后一个Set是这个格子里的roleid列表。

此博客中的热门博文

少写代码,多读别人写的代码

在windows下使用llvm+clang

tensorflow distributed runtime初窥