陷阵之志的敌人AI | 机核 GCORES

本文系用户投稿，不代表机核网观点
对于这个话题我很难一言而尽，不过AI/平衡/难度是创作这个游戏时最大的挑战。关于陷阵之志的设计哲学很重要的一点是比起策略游戏，这个游戏更多是个解密游戏。如果系统没有设计对的话，关卡不仅会变“难”，更会变得“无解”。无解的谜题会让游戏玩家感到沮丧。所以即便没有明说，接下来每个决定都会反应这个原则。
同时，对于几乎所有的问题，只要可能的话我都会倾向于极端简单（几近粗暴）的解决方法。简单意味着易于实现，维护，编辑，扩展等等。陷阵之志的AI肯定可以有更复杂的解决方案，甚至有些其他方案会让游戏变得更好。但是作为开发团队里唯一的程序，我的目标一般就是"够用就行"。

   
    
  
   
    
  
   
    
  

基本的AI逻辑如下，在多年以来的游戏早期版本中也只有这些规则：
1. 汇总下一个单位所有的可执行动作
程序会先遍历一个单位可以移动到的所有格子，以及从那个格子它可以用武器攻击到的“目标格子”。在上面这个截图里面，这个单位可以移动到的格子总数大概有30个，同时每个位置会有上下左右4个目标格子。
2. 计算“动作”的分数
在截图里面你可以看到黄蜂在不同位置的“目标分数”。每个敌对单位，每个建筑，以及每个将要攻击的友好单位都会被计入这个分数。虽然对每个敌人单位而言，每一项的分数应该是不同的，这样不同的敌人会有不同的行为，但是95%的敌人单位的这三项分别都是5分，5分和-2分。
得分低的目标会被弃置，截图里面可以看到在每个地点的最高分数。所以能打到两个建筑的格子有10分(5*2)
3. 选择一个行动
简单的按照分数给所有行动排个序，然后随机选择最好的行动。
========我是分割线======== (原文真的有个分割线）
接下来，我们把AI的得分系统略微扩展了一下，下面是我们增加的限制：
次优行动：
AI也可以选择次优的动作了。这样对难度设定更有帮助。（在更高的难度下，最优行动会更频繁的被选择）
不要重复行动：
毒蝎网住你的单位之后准备攻击，你捶破网后，它继续网你，这就没意思了。所以我给重复位置/目标设置了负权重。
地点分数：
每个地点的分数和“目标分数”分开计算了，也称为“地点分数”。
“地点分数”并不是和“目标分数”加在一起的。它遵循一下这些条件：
如果一个地点因为某些原因得分是负数，游戏会直接弃置这个选项。这一条反应了一些“危险”的格子/行动
如果目标分数都是0的话，就回退到按照地点分数排序
地点分数是这样计算的：

   
    
  
   
    
  
   
    
  

近战单位：他们会更喜欢”靠近“敌对单位，所以即便有一些危险，更近的格子也会有更高的权重。这一点在他们打不到任何东西的时候额外重要。
危险：火，落穴，敌对单位的攻击等等，这些都是”危险“，所以敌人单位会避开他们，也因此这些格子会有负权重。
边缘：敌人跑到地图边缘的话游戏就很不友好了。玩家没法推拉他们，或者有效的操控他们。所以我们狠狠的给了边缘格子负权重，不过为了避开火和其他危险敌人也可以到那儿去。
========我是分割线======== (原文真的有个分割线）
玩家总会把AI想的比实际上更复杂。考虑到这种想法经常会有，我想明确说下以下这些事情我们从来没做过：
 敌人单位从来不会考虑其他敌人在干嘛。他们不会提前计划攻击来让攻击更分散又或是怎样。不过，如果一个敌人计划在某个格子进行攻击，那个格子在后续敌人的计算中会被认为是”危险的。
敌人单位不管他们攻击的是建筑还是玩家单位，并且不会去在这两者中分散攻击。
敌人单位不会在意玩家的武器，修改器等等，也不管他们最后造成的局面是不是可解的。
敌人单位从来不会计划未来的行动，不会像国际象棋AI或者其他类似的游戏AI一样。
========我是分割线======== (原文真的有个分割线）
在这里我想提一下，敌人AI只是平衡游戏难度和敌人行为的开始。我们同时也依赖下述的这些工具来控制玩家的体验：
地图设计: 所有地图都是手工设计的，有一小部分是随机元素（比如森林的位置）。地图布局对于创造”可解“问题来说非常重要。地图上存在封闭小角落和其他的一些难以被利用来操控敌人的元素是一个风险。比起让AI去避开它们，设计地图的时候就不带它们更简单。
敌人生成管理: 生成多少单位，什么类型的单位，是陷阵之志游戏平衡的重要部分。这个游戏真的就在无解噩梦和”可解谜题“的边界上面。这两者的区别，往往就是一个单位的差别。多一个单位，多增加一个问题，结果限制了玩家3个可能的行动。这里我不会详细聊这背后的细节，不过我们花了相当长的时间测试游戏和迭代，才最终达到了平衡。并且游戏也会根据任务走向（击杀很多单位的话会生成更多的敌人来取代它们）来适应玩家——我们的目标始终是让玩家的每个回合变得有趣，既不会太简单也不会太难。
（全文完）
译者最大的感想是这个原则: 如果简单的方案有效，那就用简单的方案。游戏开发总归是一个不短迭代的过程，不能在一开始就想着把所有问题一次性解决掉。而作为独立开发，最大问题就是能不能做成这个游戏。而其实只要能做成，解决方案再怎么Dump（粗暴）都不是问题。在后续的迭代打磨中逐步完善才是正解。
原文链接：https://docs.google.com/document/d/1OPRNzAVQNgPtP35HzhV2ZzEqE1eCdXbWA7lEZXDdMHQ/edit?pli=1&tab=t.0