无缝大地图世界构建！！！为什么选择无缝大世界地图构造？？？？

        MMO 魔兽世界。。等诸多的开放世界游戏都用到了无缝大世界构建。不一一列举了。下面开始我们的大地图世界构建，和会遇到什么样的问题难点。

      通常，都是先把游戏世界分成小块，然后在相邻的小块间加入一些服务器间的通讯，每个服务器都可以自主地作出反应。服务器互相通知那些与边界接近的对象，这样来，每个服务器都可以通过它们的本地代理来对远程对象(在某种程度上)进行控制。

问题1：分割游戏世界

怎样才能最好地划分游戏世界？这个问题往往依赖于特定的游戏。在一个由玩家控制游戏人物的基于地形(terrain-based) 的游戏(也就是典型的在线RPG)中，应该假设游戏世界处于一个二维平面上，并按照二维网格对其进行划分，这是最可行(也是最简单)的方法，并且也适用于三维游戏世界。对于那些真正的“6度空间(six degrees offreedom)”仿真游戏来说，这个方法也许并不好，使用八叉树或其他方式来进行空间细分可能会更合适。

问题2:  平均分配

下一个需要考虑的问题是相邻区域的共享边界应该有多大。最小情况下，它们应该与客户端的游戏世界和/或玩家的可感知范围一样大。如果再小一点的话，当玩家在服务器边界附近时，他视野的对象可能和边界另一边的其他玩家不同，这可能会引起很多对这一游戏特性的滥用。

图描述了这种情况。服务器A和B共享同一个边界，边界区域中的对象会被映射到另一端。玩家P2在共享边界中，而玩家P1在共享边界外。P1的可见对象集合由PI周围的虚线表示，它包含了P2。但是由于P1并没有映射到服务器B中，他对于P2来说是不可见的，即使P2和P1具有相同的可视范围。由于服务器B完全不知道P1的存在，因此无法把关于P1的信息告知P2。所以PI也许可以攻击P2，但P2却不能攻击P1。

 下面，看一个更复杂一点的（图2）。

 

问题3：详细的代理对象还是精确的代理对象( 两者不可兼得)

边界区域中的对象可以跨越服务器边界进行交互。当一个对象进入边界区域时，它所在
的服务器会通知相邻的服务器，后者会创建一个代理对象来表示远程对象。同样地，当这个
对象从边界区域移动到服务器“内部”时，这个代理对象会被销毁。
另一个必须解答的问题是代理对象应该为游戏提供多少信息。如果信息太少，就很难在
没有异步消息传递的情况下编写任何游戏代码:如果信息太多，就需要对更多的数据保持同
步，这必然也会导致更多的数据得不到同步。一个实用的代理对象至少必须包含位置、方向、
碰撞信息及对象类型等基本属性。此外，它还可以包含任何其他依赖于游戏且不会发生变化
的属性(譬如说:比例、颜色等)。
为了减少服务器间为了更新代理对象而进行的通讯，可以为对象属性赋予优先级。也就
是说，确定每一个需要映射的属性，然后确定应该以多快的速度对它进行更新。当一个低优
先级的属性发生改变时，代理对象可以延迟更新(视环境而定,甚至可以永不更新)。这么做
通常会使同步问题更加严重，但却可以在效率和精确度之间进行平衡。

问题4：定义边界

另一个需要考虑的技术细节是服务器的边界是柔性的还是刚性的。当一个对象越过刚性服务器边界时，它的所有权会立即转移给另一个服务器，没有任何延迟。而一个柔性边界在转移前只允许对象“略微跨越”边界。转移对象的代价可能很大，而柔性边界.可以减少对象转移的数量，但是代码的编写会变得更为复杂。譬如说，如果有些代码(无论游戏开发人员尽多大努力去避免，总会有一些)需要对代理对象使用不同的方式进行处理，那就不能简单地用“是否在本服务器边界内?”这样的判断来区分本地对象和代理对象。

问题5：静态边界还是动态边界

最后需要考虑的是在游戏运行过程中是否可以改变服务器的边界一一也就是说，它们是
静态的(不变的)还是动态的(可移动的)。要正确地设计和实现可以动态调整的服务器边界
是非常复杂的。譬如说，游戏系统必须通过-一个原子事务(原子事务的各个步骤不可分割，
要么全部成功，要么全部取消)处理把一-组对象整体转移到另-一个服务器上，并且不能产生
任何玩家可以察觉的延迟。如果边界和两个以上的服务器相关联(在实践中这必然会发生),
那么边界的调整将涉及到3个或更多的服务器。
即使实现了这个机制，要正确判断应该在什么时候对服务器边界进行怎样的调整也是非
常困难的。过于频繁的调整会带来很大的资源消耗。而过少移动边界则会导致服务器负担过
重，尤其是出于某些原因大量的玩家同时在一-个地点聚集时(譬如说开设了一个新的地下城)。
在确定新的边界时，必须确保修改后的服务器负载是均衡的，从而降低在今后对此进行重复
修改的可能性。服务器负载依赖于很多参数:玩家数量、AI 数量、游戏世界中有多少可碰撞
对象等等。这些都需要进行大量的调整，才能得到正确的结果。

6：总结

一张图片胜过千言万语（上面那张图2）， 结合上面的问题。这张图片中有3个相交的服务器，在边界周围有很多对象，它们处于不同的位置。阴影区域代表共享边界，其中的对象会映射到其他服务器中。交叉线阴影标出的区域必须被映射到两个相邻服务器中。对象1.7、9对于它们各自的服务器来说是严格本地的。对象2、4、8在相应的相邻服务器中有一个代理。对象3、5、6有两个远程代理。

 

美工上的难点：

令人难以置信的是，在无缝世界中就连美工制作也会变得更为复杂。创建像建筑物那样
的大型对象会受到服务器边界区域大小的影响;任何对象的最大尺寸必须小于共享边界的大
小:否则，这样的对象可能会由于跨越边界区域而导致问题。
图，一个大型对象位于服务器A中，并且在共享边界中。服务器B.上的玩家P可
能看不到这个对象(因为P在共享边界之外，而这里共享边界的宽度恰巧和玩家的感知半径
相同),然而很明显它应该是可见的。更糟糕的是，P可能和它发生碰撞，这不仅会给用户带
来不必要的麻烦，还会给运营团队带来很多莫名其妙的错误报告。

优点：1，更大的游戏世界空间  2，可伸缩性可扩展性 3，不确定边界 4，不需要载入地图

缺点：1，制作难度大， 不确定性因素多 2，物品交易实现复杂 3，模型构建复杂 4，美工 5，运营维护成本高。

 后记：为什么选择无缝大地图世界构建？？？

小公司千万谨慎选择（有钱老板可以忽略），无缝大世界一种新的游戏模式，玩法和体验上，让玩家可以在里面构建自己的世界，组队吃鸡，互动性强。类似的游戏 绝地求生，无限法则,手游就不说了。鹅厂的几款和猪厂的几款，大家都耳熟能详。不在赘述。

拜拜！！！