大家好 👋
这将是一篇开发日志，篇幅比平时稍长。我想分享GMNav是怎么开始的，它做什么，以及我一路走来的收获。
起源——愚蠢的士兵
大约三个月前，我无聊时浏览免费的Itch资源，发现了一个不错的小型塔防包，想着也许能拿它做点什么，不是发布完整游戏，而是打发点空闲时间。我想换个角度，让玩家反过来进攻，控制士兵并升级它们。
我很快开始了，但没过多久就发现问题：士兵们太蠢了。真的，蠢得不行。我不喜欢它们无视来自塔的反击。于是我开始研究士兵AI，但很快意识到这比我想象的要深奥得多，不是随便就能打发时间做的。
兔子洞——无尽的循环
作为一个喜欢做框架的人，我的第一个想法是：“为什么不做一个高度可定制、基于节点的生成式AI框架，让人们能为任何类型游戏做任何类型的AI呢？”
嗯……没过多久我就发现这不太实际。最终结果比用自己的AI还复杂，而不是用我的。
然后我想：不如专注AI的一个核心组件？在我的场景里，最重要的是什么？寻路！
火魔法场景——决策很重要
我开始研究寻路，发现了不少有用的东西。我一直想一个具体场景：一个怪物和一个英雄，英雄血量很低，距离近但不在攻击范围内，英雄在他们之间施放火魔法。怪物会怎么做？它会直接穿过火去补最后一击，即使要承受伤害吗？它会绕远路，避开火，即使直接穿过去就能杀死自己不会死的英雄吗？还是会根据它的认知选路：它不怕火，血量够扛，英雄只剩一击就死。
这让我开始思考一个我后来学到的东西，叫成本层。
构建GMNav——多次尝试
在尝试和放弃十多次后，我终于掌握了诀窍，成功做出了一些有意义的东西。一个基于模块化、成本层、不同布局（等距、六边形、正交等）、净空、流场，最重要的是可恢复性构建的寻路框架。可恢复性很重要。当战场上有200个士兵时，你不会想让FPS随着每个新士兵的加入而大幅下降。这就是调度器的用武之地。你给它每帧的预算，它在不超预算的情况下生成路径，从而稳定FPS，即使有50个或500个士兵。
海拔问题——层层叠叠
事情稳定下来，一切快成形时，我碰到了堵墙；海拔。
我想了很多怎么处理。要不要给网格加额外深度，变成3D并指数级增大？要不要彻底改变方向，重做整个Dijkstra网格，改成支持海拔的东西？还是做一个体素风格的网格，只在高海拔的新单元格上添加新格？
我选了最后一个选项，不是因为便宜，而是因为它最合理。你只在现有单元格上添加新单元格，从而形成依赖地面层的新层。任何路径生成要跨层时，它先找到连接点，然后从那个连接点走到终点，实现层间移动。
目前的状态——立足点
它走过不少路，我终于觉得值得发篇文章了。还有一些小缺陷在修，但即使现在，它也已经相当适合在游戏中使用。我试图让使用方法尽量简单，不像我其他一些库。
这篇比平时长，让我知道你的想法，或者想让我加什么特定功能。我想让它有点开发日志风格，分享我的经验和想法。我尽力别写太长，否则可能好几页😅
感谢阅读！
GMNav——免费、开源、MIT许可的GameMaker寻路和导航框架
GitHub: https://github.com/erkan612/GMNav
如果你想看看我其他库：
GMUI: https://github.com/erkan612/GMUI
GMLiteSearch: https://github.com/erkan612/GMLiteSearch
评论 (0)