民工气息满载的后端大地图管理策略

大地图类型，在俺的理解中，就是先把y无视，仅处理x z的平面坐标改变的移动类型；

做大地图类型游戏的基础构建过程中，一般来说，免不了要以一副理所当然又无奈至极的表情去面对一个实际的问题——地图管理；

俺的表情是 无奈#。

从实现细节来看，大地图中，坐标的变更怎么搞都只是个属性设置和地图内指向变更的小case；

真正蛋疼的地方是视野（view）。

简单来说，从最常见的应用出发，那就是，俺要知道哪些家伙在俺附近；

基于大地图以上的一些特性和常见需求（当然，不一定全面，太较真了这就是书不是博文了），前辈们发挥着刺瞎俺的狗眼的聪明才智，创造了高效又与计算机亲和力高的管理办法：

Nx树，

曾几何时，俺在一次次笔试中，一次次地在卷面写不好x树遍历，一次次地奇怪自己明明回宿舍开个vs琢磨琢磨着居然又出来了，一次次徘徊在面临毕业即失业的危机中挂一脸铁青去找这周的新动画安抚心情打消一跳了之的念头...扯远了；

通过树的层遍历获得高效的视野效果，然后通过对象指向变更（节点移动）实现对象移动功能，只是，个人隐约觉得，这可能不是唯一的办法，于是开始想；

最后，俺的结论是，一位数组。

先粗略地图解一下Nx树地图：

。            。node

        。 root

。             。

简单来说，就是从中央点开始，横竖各一刀半分切割平面，形成小片的管理区域，再在各个细分区域内重复这个过程；

然后，管理的最优先点就是最开始的那个中央点（root），也就是树的根节点，也是在未经优化的支持下，视野搜索的入口；

后来，通过一些搜索优化工作，可以使得我们不必每次都‘从头开始’地获取视野范围，例如搜索请求归并、视野区域缓存、制造不平衡区域、偏心搜索等等。

之后，也粗略地图解一下俺的一位数组地图管理策略：

。。。。。

。。。。。

。。。。。

以上。

每一个   。  俺定义为一个管理区域，类似Nx树中被最小分割后的小片管理区域，它们在内存中的样子就是：

。。。。。。。。。。。。。。。

有多少个小片，数组就有多长，例如，一个10000单位长/宽的地图，每100单位长/宽为一个小片，那么数组长度就是100；

坐标移动很简单，就是从数组中小片A所管理的对象池中，移动到小片B的对象池，和Nx树一样；

至于视野，则是这么一回事：

           x1              xn

y1        。。。。。         

            。。。。。

yn        。。。。。

那么，一个片的所标（x， y）换算成数组index就是  index  =  xn * y + x

从这出发，最便利地得到视野的方法就是，把 y1 < y < yn，x1 < x <xn 范围内，视野所需范围（view distance）所覆盖到的方形区域，切片返回：

for y in xrange(y - distance, y + distance):

    _x = xn * y + x

    yield map[_x - distance, _x + distance]

懒人py一下完事（未加边缘修正，未继续优化

缺点就是，比较吃内存，方法太民工，视野是方形的...

然后准备进入悲壮的死命项目赶工期，偷懒