单人游戏中连续无限地图的实现方案

yxxiaobin

其实在星际2编辑器中，原生支持256*256大小的地图，对于绝大多数情况，已经够用了。但是人总有一种欲望，就是突破极限。只要有极限的存在，总有人回去试图突破它。在多人游戏中，已经有比较成熟的无限地图实现方案了，但是有一定局限性，比如一定得做成不同关卡，同一批玩家需要在同一个或者有限几个关卡中活动，即执行任务的同步性，无法做出真正自由的无限地图。但是在单人游戏中，同步性这个问题将不复存在，所以我们可以实现真正无缝衔接的无限地图。下边大致介绍一下实现方法。首先了解一下无限地图的基本技术。
1.伪地面贴图技术。编辑器无路论多强大，你还是无法真正的实现动态地面贴图。但是你可以用创建泼溅图的方法在原来的地面上再创建一层贴图，而这个贴图虽不支持原生贴图的很多功能，比如自由的叠加，比如自由的形状等，但这不是问题，因为我们可以预先画出非常细致的地形贴图来，而不需要依赖地形编辑器，你可以想象一下早期2D网游的地图，比如网易的发家制作“大话西游2”，那都是预先手绘了一整张画。在游戏时，我们只要按一定算法像铺地砖一样把它铺上去，就能制作出很漂亮的地面贴图。要做到这一点，需要一定的图形编辑水平和模型制作知识。如果你或你的小组有人精通绘图和模型编辑，那么就简单多了。
2.伪悬崖技术。同样，编辑器无法动态修改悬崖，但这个是最容易实现的，只要创建具有“表面行走”性质的模型（比如桥梁类模型就能让单位在其表面行走），并应用足印就ok了。不过编辑器没有内置合适的模型，你的需要自己来制作，这需要用到模型制作知识，可能是最难的一个环节了。暴雪防卫局这张图做的这么好，很大程度上是因为他们有青蛙君这样优秀的模型制作者。
3.即时地形变形技术。还好，这一技术是被编辑器原生支持的。演算体中有一类叫做地形变形器，用它可以简单的做出地形凹陷和凸起的效果，配合足印可以制作出非常丰富的地形起伏。
4.伪小地图技术。编辑器支持镜头范围应用至小地图，但前提是小地图图片是存在的。对于预先设计出完整地形的情况（只需要突破256*256限制，而不需要真正无限），可以使用这种方法，当然你得提前导入一个小地图图片进去。但是如果是随机无限地形，就没法用这种方法了，那么可以自己自定义一个小地图出来。相信有一定UI编辑知识的人都能做到。

然后说一下无限地图的实现方案。其实我觉得方案有很多种，有的复杂，有的简单，有的效果逼真，而有的则比较简陋。我这里只介绍一种原理和实现都很简单的一种，最终效果也可以接受。在这种方案里，单位的移动采用单位真实在地图上移动，而不是动态移动地形的方式来实现，这样需要系统支持是最少的，实现起来也最逼真。那么如何保证单位不会走到地图边界呢，我推荐使用大小九宫格来实现。
第一步，将地图分割成3*3=9个大格，为了后边描述方便，我将行号记为ABC，将列号记为一二三，比如“A二”代表第一行，中间那个格子。将每个大格再次分为3*3=9个小格，同样分别用abc和123来标记行列。这样，每个小格就具有唯一坐标，比如“A二b2”就代表第一行中间那个大格里边的最中间小格。如果将每个小格定义为27*27单元格，则整张地图为243*243，正好在地图256*256的范围内，还留有余量。
第二步，制作出地形，方法上边已经说了。这里最好按小九宫格为单元，比如每个小格铺一张地形贴图，这样全图就需要铺81张贴图。当然也可以按大格铺，这样只需要9张贴图，但是你就得做出很巨大的贴图，制作时编辑不方便，而且我也不确定在移动这么大的贴图时，电脑是否会lag一下。当然除了地形贴图，还有悬崖、地形起伏等。
第三步，在指定位置创建单位。游戏不可能没有单位，比如玩家角色、各种npc，以及野怪等。具体和你对地图的设计有关。
第四步，动态更改地形，当玩家移动到边缘大格的中间一列或者一行时（图中蓝色区域及四个角的红色区域），就将全图所有内容（包括单位、地形，某些演算体等）整体移动一个大格，具体移动方向，视玩家进入的区域有关，比如进入A行b行，就将地图向右下方移动，而进入B行2列，则将地图向右移动一个大格。之所以不让单位抵达地图尽头再移动，是因为某些技能可能具有射程，当单位向地图边缘发射时就无法正确运算了。这种移动方法，单位里地图边界总是保持在54格以上的距离，在多数情况下够用了。

在移动时，涉及到一个问题就是，移来的东西可以通过某种方法的到（比如随机或读取），但移走的部分如何处理呢。如果是预先设计完整地形的，移走的直接删除就行了，当再次需要时，直接读取地形设计，重新创建。某些特殊的单位可能需要缓存，或者是通过其他方法保存起来，比如隐藏后移动到一个不为人知的小角落。但是如果是真正无限的地形，直接删除就不行，因为一旦玩家返回，你就无法还原地形，导致玩家就像走进了异次元空间永远无法返回原处。这种情况下，可以通过缓存地形和单位的方法来保存走过的地方。可能有人会想到，那这样一来占用内存越来越多，不是就像魔兽那样越玩越卡了吗？其实这一点在多数情况下不用担心，原因有一下几点：1，虽说无限，但玩家不可能真的无限玩，游戏进程是有时间限制的，多数情况下也就几十分钟，不会真的无限制造数据。2.你可以通过一定限制来避免数据几何性增长，比如让玩家走过的地方尽量保持走廊样，而不是整体的大平原。还可以通过游戏设计诱导玩家多多利用走过的区域。3.合理的算法只需要保存关键值，而且大多是实数，少数是字符串，真心占用不了多少内存。4.现在电脑的内存和10年以前不同了，不会因为几兆的数据就卡起来了。就我这破电脑还8G内存呢，我相信多数人不能连这个数都到不了吧。
另外一个问题：对点施放的持续性效果和以点为目标的飞弹无法完美移动，只能就地摧毁。目前还没有任何方法能很好地解决这一问题，这意味着，如果采用本方案或者与之类似的方案，就尽量避免使用上述两种设计，或者尽量将它的重要性降低，即使直接摧毁它们也不会对游戏进程产生重大影响。

yxxiaobin

忘记了，顺便附上地形变形器的几个主要字段和值的意义。
足印：中心区域的形状和大小。这一区域不会变形。
影响范围：边缘区域的宽度，虽然能设置为实数，但最终会被近似成整数后起作用，最小值为1，如果设置小于1，则实际应用时重置为1。这个是变形区。
高度：即隆起来的高度，如果设置为负值，则表现为凹陷。
混合时间：从演算体创建到地形变形完成所需要的时间，时间越长，变形越缓慢，如果设置为零，则表现为瞬间完成。
地形变形标旗：
    摧毁植被：变形器发生范围内的地形植被会被摧毁。如果是用于制作弹坑，会表现的更真实。如果是用于动态地形，通常需要关闭它。
    使用单位足印：如果勾选此项，足印字段的设置将被忽略。如果演算体附着于单位，且单位有足印，则以单位足印为中心区域，否则中心区域将设为0面积。
    恢复隐藏：应该翻译为隐藏时恢复，即：当演算体被隐藏时，地形变形将恢复原状。
    移动时恢复：当演算体被移动时，原先区域的变形会回复，而移动到的地方将出现新的变形。当勾选此项时，可以做出地形变形随演算体移动而移动的效果，比如用于表现一个球在海绵上滚动时。将此项禁用，可以用一个演算体连续移动来做出沟壑变形。
    摧毁时回复：当演算体呗摧毁时，地形变形将恢复原状。将此项禁用可以在不保留任意演算体的情况下创建永久性地形变形。

几项重要提示：
    1.与单位和装饰物的足印不同，变形器的足印不会强制对齐到网格。
    2.变形并不是连续平滑的，而是存在区段，区段地形网格有关。
    3.基于以上两点，将同一个变形器创建到小数位不同的坐标时（比如3.5和4.0），它的表现也不相同。
    4.如果混合时间不为0，当演算体移动后，会重新混合一遍。这就导致，如果你连续的移动演算体，则形变会在移动时不能充分表现出来。
    5.地形变形器之间是可以叠加的，但是仅仅在周边区域的高度有叠加，中心区域的高度并不叠加。也就是说，你在一个高度2的变形器区域再创建1个高度1的变形器，并不会让高度变成3。
    6.如果影响范围设为1，则隆起表现为折现变化，无渐变区。如果足印、和影响范围都设置的足够大，则在足印周边表现为折线变化，但是在最外围则表现为弧线。影响范围越大，外围弧线越平滑。如果足印设为0面积，且在影响范围足够大时，表现为一个完全弧线变化的圆丘（或圆坑）

wyg5105478

要是有多人连续的就好了像打战役那样

wyg5105478

而且我倒是希望加入一个可以半途加入玩家的功能这样的话游戏里人跑了就不怕玩不下去了

zjm1001010

写的很仔细喔，但是这个工程量太大了，如果业余制图爱好者很难达成

七键守护神

很好的帖子~

几个意见：
1：关于玩家会不会无限玩，77的意见是，如果这样的地图真做出来了，玩家一定会无限玩。
因为77自己的地图，就算不是无缝无限扩展，而仅仅是利用动态地形进行场景切换，都出现了玩家赖在里面不走的情况。据我观察，只要玩家的队伍没散（比如有人不会玩，有人秒退），那么玩家一般会在游戏中逗留两个小时到四个小时左右的时间。
如果在地图机制上阻止玩家继续玩（比如在机制上设定一局最多20分钟），则失去了这种地图的存在意义，所以这个地图的制作中内存管理是重中之重，一个漏都不能有。

2：不必保留玩家所经过的地形本体，可以用地形固定、只保留每个地形上的“可交互物体”的方式来搭建地图，可交互物体的使用要谨慎一些，用在关键的门、可破坏的岩石、NPC之类上面，大部分环境不可破坏和交互。怪物也不用记录，就像早期的FC游戏那样，距离怪物太远怪物则自动消灭，过版后再往回走怪物又会刷新，这样应该可以极大的降低刷新频率和内存占用。

3：多人游戏也可以使用这套方案。具体手法就是使用相位技术，将地形重叠放置，支持多少个玩家就做多少个行为和对应的筛选器对应的验证器，武器、技能在使用前都需要通过这个判断目标当前是否和源处于同一位面的验证器，单位碰撞问题则通过设置不同的碰撞层来解决（但这里有个问题，就是足印如何实现异步，如果使用单位圆形碰撞效率可能会不可接受）。现在演算体相位有官方的演算体消息支持，使用起来效率已经可以接受。
在两个玩家靠近时（区块重叠时），则将两个玩家传送到同一个位面。两个玩家相互分开时，则将分开的玩家传送到相位位面。
77在自己的地图中也实验了一下这个设计（还没有开放给玩家），虽然没有你的设计这么完整，但基本功能应该是没有太大问题的。但因为足印异步问题，77的这个设计只支持每个玩家最大128x128的地图空间，最多4个玩家。

具体实现起来又是一个耗时漫长的大工程，但只要实现这个，在SC2中做WOW这个梦想就算是基本实现了。
为什么说只是基本实现，暴雪看来是不打算提供服务器存档给我们用了呢……

yxxiaobin

七键守护神 发表于 2017-7-4 14:19
很好的帖子~

几个意见：

感谢7j大神的回复。7j在地图编辑，尤其是动态地形上有丰富的经验，非常有发言权。

关于7j大神几个意见的反馈：
1.玩家是否会长时间使用地图，这个我没有经验，只是凭感觉猜测的。根据你说的情况，或许应该把预估游戏时间的上限调整为3个小时，而不是七八十分钟，这可能会带来超过1倍的数据增量。
3.相位技术是个好东西，在某些类型的地图中可以做出很神奇的效果。但是在rpg中，制约太严重，可以说，根本无法做出很完美的相位来。我觉得这个只是备选方案，应尽量避免使用。

结合第二点详细说一下我对各种数据的设想，因为没有实际的去测试，可能有想的不周到的地方。
贴图采用固定的组合，在较大范围内重复，比如以1*1至9*9个大格作为一个周期，这样玩家也不会注意到纹理是重复的（视纹理和其附属装饰物而定，越是花哨而没有特征，则需要的面积越小），这种排列规律可以事先定义，不需要额外记录，数据量将变得微乎其微。几个格子作为周期对数据量都不是问题，只是减少面积能减少编辑时的工作量。
其他装饰物可以采用组合设计：在每张贴图设计固定几种装饰物的组合，实际应用时随机抽取一种出来。比如一张贴图有2-6个装饰物区域，我们针对每个区域设计4种方案，实际应用时每个区域独立随机，就能组合出非常丰富的效果。之所以不做成全固定是为了避免地形高度重复。这么设计的好处有两点：第一，能更好的和地形纹理匹配（比如绿地出现树林比较自然，但是如果石板路上也有树木就比较古怪）；第二，我们在记录时，只需要记录一张贴图的几个随机数就行，而不必记录数百上千个装饰物分别是怎样的。而且配合上边提到的贴图固定组合的方式，这种记录将变得更简单。虽然这么做能增加制图工作量，但是为了优秀的效果绝对是值得这么做的。
悬崖不应当固定，我觉得悬崖是作为地形特征的主要标记，比装饰物还要引人注目。而且，如果考虑到和地形和其他装饰物配合，推荐悬崖也像装饰物那样。
怪物不必保留，这些东西没有个体特征，位置也不恒定，玩家根本不会注意到多了或少了几只，或者他们现在的位置和以前移动的趋势不符这种事。需要缓存的都是特殊单位，比如某个旅行商人，但数量不会太多，在数据量的比例上可以不考虑。如果是城镇区，各种交互会很多，建议采用预先设计的方案，每次重建时读取设计就好。这么做的好处还有一点：城镇的地形如果随机会更像野外，没有城镇感觉，而设计则可以做的更合理。
地形起伏不宜做的过于剧烈，且不必记录，每次随机创建即可。
某些地标性地形装饰物要有计划的使用：如果都不使用，当然能减少数据量，但是如果有计划的使用某些地标性装饰物，能更有利的诱导玩家产生“我以前确实是从这里过来的”这种想法，即使其他细节其实是不同的。

另外有一个细节就是，每次改变地形，都可能导致卡一下，可以使用技术手段来降低其可能性或严重性。
目前想到可以这么做：首先复制玩家当前所在大格的地形到中央大格，然后移动玩家角色和所有单位，这个必须瞬间完成。但剩余的格子里的内容则可以通过一个计时器在1-5秒内顺序完成，这样就在很大程度上避免了瞬间运算量过大了。但是需要注意的是如果单位有瞬间大范围移动的技能要做对应处理，以免传送到未完成区域。远距传送，比如回城类技能，可以做出引导时间，甚至允许淡入淡出来造成切画面的效果，这样就有足够时间构建区域了。像追猎者这种战术性传送避免传太远（小于一个2个小格即27*2=54个单元格就没问题），事实上战术性传送一般也就几个单元格而已，超过10个的都不是很多。


对于真正的单人游戏，做的人不多，做出来也很难推广。我写着文章，也是一时心血来潮，估计在很长一段时间内都不能得到真正的应用。不过在某些特殊情况下，这种技术在多人游戏下依然可以被应用，比如如果你的地图只允许2向扩展。想想早期双人玩的横版过关游戏吧，不是相当于地图扩展的吗？（尽管那其实是固定地图在移动）。我们可以这么设计，让地图在高度（或宽度）上保持243不变，但在另一个方向上可无限扩展。如果玩家要探索前边的区域，就必须都处于地图同一侧。你可以通过剧情引导玩家在一个事件段向固定方向探索，以便获取更多奖励。但是无论怎样设计都挡不住奇葩，如果大家都想右探索，但有一个玩家就是要在地图最左侧活动，则可以投票传送他。如果真的采用这种设计，就能做出一张图无限关卡，一个关卡无限面积。

七键守护神

yxxiaobin 发表于 2017-7-4 18:11
感谢7j大神的回复。7j在地图编辑，尤其是动态地形上有丰富的经验，非常有发言权。

关于7j大神几个意见 ...

这个做法做起来其实很类似FC游戏机的图像渲染方式。

FC游戏机的显存是不足的，它的显存容量甚至无法存储一张相当于其本身分辨率大小的黑白图片。所以这时候FC使用了活动块这个概念，即：
1：画面上每8x8的区块为一个活动块。
2：每个活动块可使用最多4种颜色。
3：场上的活动块种类有一定的数量限制。
用在无限地形上，就类似下面这样：
1：地图上每8x8的地区为一个活动块。
2：每个活动块最多可使用N种装饰物。
3：场上的活动块种类有一定的数量限制，并且不会同时出现3个或3个以上不同地形风格的活动块。
这样一来，需要保存在内存里的资料数量应该会得到几何级的下降，在进入一个新区域时，需要加载的模型量也会得到控制，并且脚本里的地形数据也会变得很简洁。但坏处是要制作一个好看场景的成本会大大提高，你必须为此写一个足够优秀的编辑器。

地形起伏建议每帧用触发器修所有改进行了移动的单位的高度，很笨的办法，但是很必要的。曾经我也想用物理体模型来实现这一点，但实际效果很欠佳，特别是在斜坡上，SC2的物理体对斜坡上的处理非常不精确。当然抬高地面的物理体也得有，否则尸体和粒子会沉入地面以下。
区块里也可以记录，当前区块内是否会进行地形高度改变，如果没有进行改变（也就是说当前区块都是平地），就可以不对区块上的单位进行遍历，省下这点运算量。

至于刷新效率问题，就按你说的，优先保证玩家所在的地图的刷新，周边地区的刷新可以放入一个周期性线程中执行，设置每一帧能刷新的区块数量上限，超出的就留到下一帧处理。也不一定需要保证玩家能看到的地形完整无缺，在移动速度很快的情况下，玩家是允许看到装饰物在视野内刷新过程的，这没问题，玩家可以理解的，只要保证足印的刷新不要落下就行了，这里要做好视觉和逻辑层面的分离。
还有个比较重要的，就是没刷新的区域设定为不可进入。用大块足印阻塞没有刷新好的地形应该就可以了，这样应该可以防止出现一些因为地形来不及刷新而出现的穿墙Bug。

玩家离开后的区块需要被移除，可以不着急移除，而是将其存到回收站，等一定时间过去后再彻底移除，而在时间内如果玩家返回则可以直接把回收站里的区块拉回来，设置演算体的位置比新建一个演算体要节省得多。

相位在现在而言其实并不是特别难以实现，问题在于实现后编写任何资料都会相当繁琐。如果要使用相位技术搭建多人游戏，那么最好所有的技能都通过触发释放，这样就可以为其写好通用的接口，提高制作效率。而运行效率上其实SE的触发是没什么问题的，相对于地形系统来说，技能系统所占用的资源非常少。

疯人￠衰人

其实小彬说这个，孔明在国内比赛的那张GA星际时代（类似大富翁那个图）已经到达真无限+真位面消隐的（256-8*2）*（256-8*2）大小地图了
仅有的缺陷是音效的异步比较麻烦，是个耗时间的功夫活（直接使用或继承官方的演算体会带上声音设置，异步处理起来比较多）
另外就是比较吃内存。每个玩家需要维持若干个256*256*n的数组，然后每个经过并离开的地图都会保存到DataTable中。

因为当时是自由之翼时代，很多技术都还没有，所以当时只能做出星空背景的，三个天空盒以演算体方式异步放置制作出玩家在不同星区的效果。
因为是大富翁类的，在固定轨道行驶，避开了寻路和碰撞的问题（这是目前动态生成地图最大的问题，足印没法动态生成，虽然如防卫局那种用单位拼合可以解决问题，但是执行效率很受影响。）
游戏中所有单位都没有点击交互，除了自己和自己的浮游炮以及敌人之外都是虚假的演算体，所以效率还可以接受。

切换场景参照老式rpg那种loading，播放一个UI层的过场动画来遮盖。（这里特意把玩家的世界视角移动，背箱生成的演算体方向，降低渲染消耗）
去除边界后，玩家在一个网状的路径上移动，每个星区（240*240的地图）的是个边界方式上都有离开此星区的传送点，到达目标星区后会出现相反方向的对应位置。
（中间的网格生成算法会根据已知的传送点来生成，未知的位置会随机生成。）

详细可以看这里
http://bbs.islga.org/read-htm-tid-2151310-page-1-fpage-1.html

其实这就基本是SC2在全动态随机地形上能够达到的极限，在复杂的效率会成为主要问题，基本就没有实用性了。今天还和青蛙聊到了泼溅图的资源消耗。如果完全用泼溅图实现，会吃一大部分资源。
虽然可以用单位足印来模拟真实足印，但是足印没法异步，这导致需要自己写套寻路算法（寻路好实现，但是寻路又牵扯到主动攻击、逃避等，就很难实现了，而且即使实现效率也堪忧）

星际时代利用科技和验证器做出来了位面消隐的目标判断，这个方法效率还是可以接受的。
攻击、投射物和技能最好是按照防卫局那种自制系统模拟的方式，否则异步判断会闹心死。每个涉及的演算体效果都需要有对应的演算体消息控制或继承父级的可见性

地图区域的动态生成方面，可以去看一些Minecraft的资料，那个就是动态生成的，而且java的效率也不见得比较galaxy高多少。

这种级别的系统大约需要半年的时间搭建骨架，半年测试。全随机的系统没法遍历测试，所以可靠性很难100%保证

这玩意是相当痛苦的大活，不过真写出来，galaxy的水平也就达到顶尖水平了（不是自吹无论war3还是sc2都没有几个这样级别的复杂系统的）。
这东西要求对效率有超级的敏锐感，比较一个地方浪费1，就240*240浪费了，孔明当时写的时候为了避免超过执行上限，废了好大心思来拆分循环（递归更难控制）

yxxiaobin

七键守护神 发表于 2017-7-4 19:57
这个做法做起来其实很类似FC游戏机的图像渲染方式。

FC游戏机的显存是不足的，它的显存容量甚至无法存 ...

其实我对游戏设计不是很理解，你关于活动块的说法我似乎明白，但细节还是不是很清楚。
比如在无限地形上，为何要限制活动块中装饰物的种类和活动块的种类呢？如果装饰物并不是全随机，而是实现定义的话，装饰物种类并不会明显增加数据量吧，同样活动块种类也是一样，因为某种活动块，只需要访问一下预先定义的文件（或数组）就能直接读取内容了，需要记录的也就是一个标识。当然我不敢肯定我对活动块在星际中应用的理解是正确的。

关于地形起伏，我一直以为物理体这种表面判定是可以用的，毕竟系统自带的桥梁倒是也没出什么大毛病。不过如果真的存在问题的话，我觉得有个替代方案：使用地形变形器演算体，合理的定义足印并加以组合，就能很好地模拟悬崖和斜坡的表面（亲测悬崖能完美模拟，而斜坡可近似模拟），而路径控制依旧采用足印。

用大块足印封闭未刷新区域是个好主意，能减少bug的发生几率。

回收站的想法很棒啊，只是算法一时想不到很合适的，但是这不是关键问题，只要有方向，设计是迟早的事，毕竟有很多人对算法都比较精通。

相位技术其实主要是兼容性问题，和星际2原生的数据系统结合的不是很好，比如你提到用触发器来施放技能等方面，显然需要额外的系统支持。不过在没有其他方法替代的情况下，相位技术也算唯一能解决此问题的了。

yxxiaobin

疯人￠衰人 发表于 2017-7-4 22:40
其实小彬说这个，孔明在国内比赛的那张GA星际时代（类似大富翁那个图）已经到达真无限+真位面消隐的（256-8 ...

想不到孔明早就做出来了，我倒是孤陋寡闻了。而且通过你的介绍可以看出来，细节做得很足。
其实这系统我也就是随意想一想，可以说是最初的最朴素的想法，后边的补充也是临时想到就写上去的，在发文时还没有去想....
另外，我也并不会真正将它做出来：一个是我不想使用相位技术，原因你和q7j都说了。而不使用相位技术就注定只能单人，或者在少数多人游戏中能应用，基本上就是花数个月做一个废物（由于水平有限，还不一定能做成）。
不过看你的图，应该成熟度是很高的说明花了很大的精力去设计、制作和调试，我在此深表佩服。

疯人￠衰人

yxxiaobin 发表于 2017-7-5 01:47
想不到孔明早就做出来了，我倒是孤陋寡闻了。而且通过你的介绍可以看出来，细节做得很足。
其实这系统我 ...

也不算，我的方式是取巧，随机的深度要比防卫局高，但是宽度不足，相当于是无法完全做随机的前提下的两个方面的取舍。
整个地形方面做了8个月（前半年上班只是带着做，然后出了事故丢了一回代码，后两个月重构丢一回注释和原始代码，因为是notepad++做的，只找回了生成代码），路径指引做了1个月。
然后随机玩家单位数据做了1个月+半个月的异步化
UI做了半个月多，然后玩法只有1个礼拜（写使用说明……）

这是1.5.0版本做的，把当时黑科技都用了。

其实我们说的问题不在相位技术，而在于显示层和逻辑层的分离。
无论地形变形器还是模型达到的地面起伏都是虚假的，无法在逻辑层获取
所以只能用模拟的方法同步记录（防卫局的做法）
这种方法是没法完美的，孔明尝试很久也没法解决对应的AI问题（低处单位看不到高处单位不会主动攻击，以及隔墙看不见这类）
当然这里其实是SC2没有开放风暴中的目标动态排序的功能
这是其中的一个方面，异步做到最后你只能放弃某些东西

孔明的地图是直接在机制上躲过去了，防卫局是迎难而上。

当然另外一种方式也能做位面，那就是分片构造
也就是将整个地图分区为玩家个数的个区，每个玩家如果在不同位面就放到不同的分区，然后对每个分区创建相同的地形和背景……防卫局偏向这种，这种方法就避免了真位面消隐代理的问题，不过动态生成地形还是没法解决细节问题，比较我们没法生成真实悬崖。

这种方式其实更适合注册地形数据，可以自己做编辑然后仿SE那种绘制地形然后根据需要生成。比真实随机生成能实现更好的美术效果，不过工作量增加很多。

yxxiaobin

疯人￠衰人 发表于 2017-7-5 10:08
也不算，我的方式是取巧，随机的深度要比防卫局高，但是宽度不足，相当于是无法完全做随机的前提下的两个 ...

低处看不到高处和隔墙问题可以考虑试用遮蔽高度来解决（我自己做了一张可变迷宫，墙就是用单位做的）。但是逻辑上“高处”的单位依然是平地，这个貌似无解。
在不考虑地图大小的情况下，分区的方法显然是最佳的，实现最简单，也不容易出现许多绕不过去的坎。但问题是某些时候分区导致区域过小，所以目前好多玩家都希望能开发出安全有效的无限地图做法。只是某些先天的限制，此类做法终究不完美，且不说足印和碰撞问题，就说玩家丢一个地板技能，当移动地形时，就没有任何办法完美的移动或重建这个技能效果到新的区域。要想实现完美的无限地形，可能还有很长的路要走，甚至得期待编辑器更新出某些功能才行。

ScHsPeDFlaSh

啥时候暴雪能做地图打包发布啊（躺）

疯人￠衰人

yxxiaobin 发表于 2017-7-5 13:44
低处看不到高处和隔墙问题可以考虑试用遮蔽高度来解决（我自己做了一张可变迷宫，墙就是用单位做的）。但 ...

目前的方案就是全模拟了……接管所有的数据，然后自己以可控的方式模拟
这个工作量比较大，也不通用