1. 项目概述为什么战棋游戏的“行动力范围”是个技术活做战棋游戏尤其是那种走格子的经典类型玩家最核心的体验之一就是“我能走到哪儿”。一个清晰、准确、响应迅速的行动力范围高亮不仅仅是UI的一部分它直接决定了游戏的策略深度和操作手感。想象一下在《火焰纹章》或者《XCOM》里你选中一个单位屏幕上立刻亮起一片格子告诉你这个单位在当前行动力下所有可能的落脚点。这个功能看似简单背后却涉及路径计算、规则判断和高效渲染。在Godot 4.2里我们有了一个非常趁手的工具AstarGrid2D。它不再是那个需要你手动添加点、连线的复杂图论工具而是直接为你管理一个二维网格世界。用它来计算行动力范围简直是“专业对口”。但事情没这么简单光是“怎么走”这个问题就衍生出四种经典的对角线移动模式总是允许、从不允许、仅当无障碍时允许、仅当相邻两边都无障碍时允许。选错模式你的游戏平衡性和体验感会大打折扣。这篇文章我就来拆解如何用Godot 4.2的AstarGrid2D从零开始实现一个功能完整、性能可靠、规则可配置的战棋行动力范围高亮系统。我会把四种对角线模式的实现细节、选择逻辑以及实际编码中那些容易踩的坑都掰开揉碎了讲清楚。无论你是刚接触Godot的战棋爱好者还是正在为项目寻找一个稳健解决方案的开发者这篇实战指南都能让你直接“抄作业”。2. 核心思路与AstarGrid2D设计解析2.1 为什么是AstarGrid2D而不是手动循环计算行动力范围最朴素的想法是以单位为中心向外一层层BFS广度优先搜索扩散检查每个格子是否可达并累计算移动消耗直到消耗超过行动力上限。这个思路本身没问题但自己实现BFS你需要处理队列管理。已访问格子的记录防止重复计算。地形移动力消耗的查询。移动规则的判断如对角线规则。边界检查。AstarGrid2D把这些脏活累活全包了。它本质上是一个为网格化地图优化的A*寻路算法实现。我们虽然不关心具体路径但可以利用它的核心功能计算从起点到网格内任意一点的最小移动成本。这正是我们需要的我们告诉它起点、每个格子的“通行成本”即移动力消耗以及一些规则如对角线模式它就能返回一个“成本地图”。我们只需要从这个地图中筛选出成本小于等于单位行动力的格子就是可移动范围。优势对比代码更简洁Godot引擎原生支持API清晰。性能更优底层是C实现比GDScript的循环BFS快尤其在大型地图上。功能强大直接支持四种对角线模式、自定义成本计算、区域划分等高级功能方便后续扩展如不同地形、技能影响范围。易于调试AstarGrid2D提供可视化调试方法可以直观看到成本分布。2.2 系统架构与数据流设计在动手写代码前先理清数据和逻辑的流动。我们的系统大概需要这几个部分地图数据层负责存储整个游戏地图的静态信息。每个格子至少需要知道terrain_type地形类型如草地、森林、山地、水域。is_occupied是否被其他单位或障碍物占据。可选defense_bonus等其它战斗属性。 我们可以用一个二维数组Array[Array]或一个TileMap图层来存储这些数据。为了和AstarGrid2D配合使用TileMap会更方便因为可以直接获取网格尺寸和世界坐标转换。移动规则配置这是一个核心配置表。它定义了不同地形对移动力的消耗。例如var movement_cost_table { “grass”: 1, “forest”: 2, “mountain”: 3, “water”: 999 # 表示不可通行 }同时这里也配置我们选择的对角线移动模式。AstarGrid2D处理器这是核心计算模块。它的工作流程是初始化根据地图尺寸创建AstarGrid2D实例。更新当需要计算某个单位的范围时根据单位当前位置、行动力上限、当前地图的占据情况动态设置每个格子的“权重”即通行成本。计算调用get_point_path或利用id计算成本但我们有更优的方法。范围高亮渲染器负责将计算得到的可达格子列表以视觉形式如半透明色块、边框高亮显示在屏幕上。可以用另一个TileMap专门用于效果层或者用Polygon2D/Sprite2D批量绘制。单位控制器作为触发器当玩家选中一个单位时调用处理器计算并将结果传递给渲染器进行显示。数据流单位被选中-获取单位属性位置、行动力-查询地图数据层-配置AstarGrid2D设置成本、对角线模式-执行范围计算-生成可达格子列表-渲染器高亮显示。注意AstarGrid2D的update()函数在设置完点权重后必须调用否则新的成本设置不会生效。这是一个常见的疏忽点。3. 四种对角线模式详解与实现选择这是战棋游戏移动规则的精髓所在不同的规则会极大影响游戏的策略性和“感觉”。AstarGrid2D.DiagonalMode枚举提供了四种选项我们来逐一剖析。3.1 DiagonalMode枚举解析在Godot 4.2中AstarGrid2D的对角线模式通过diagonal_mode属性设置它是一个AstarGrid2D.DiagonalMode枚举值DIAGONAL_MODE_ALWAYS(0):总是允许对角线移动。计算方式从中心格子到斜对角格子的移动成本是sqrt(2) ≈ 1.414倍的基础成本。AstarGrid2D内部会处理这个近似值通常用整数近似如14代替10的1.414倍。游戏影响单位的机动性最强移动范围更接近圆形。适合追求快节奏、高机动性的游戏。但可能导致单位可以“挤”过一些视觉上看起来过不去的角落如果两个相邻的直角边都是障碍物但对角点可达。实现场景奇幻或科幻题材单位行动不受传统物理限制。DIAGONAL_MODE_NEVER(1):从不允许对角线移动。计算方式单位只能向上、下、左、右四个正交方向移动。斜对角格子被视为“不可直接到达”必须绕路。游戏影响移动范围呈现明显的菱形曼哈顿距离。移动路径更可预测但长距离移动会显得笨拙、不自然。策略上更容易构筑“人墙”进行阻挡。实现场景追求严谨格子战术、或者单位设定为只能前后左右移动的游戏如某些机器人主题战棋。DIAGONAL_MODE_IF_AT_LEAST_ONE_WALKABLE(2):至少有一个相邻的直角边格子可通行时允许对角线移动。计算方式假设你想从(0,0)移动到(1,1)。系统会检查(1,0)和(0,1)这两个格子。只要其中至少有一个不是障碍成本非无限大就允许这次对角线移动。游戏影响这是很多经典战棋游戏如《高级战争》的默认选择是平衡性和直观性的折中。它防止了单位“穿墙角”因为如果两面墙形成直角两个相邻格都不可通行对角移动就被禁止同时保持了较高的机动性。实现场景绝大多数传统日式或美式战棋游戏的首选。DIAGONAL_MODE_IF_ALL_WALKABLE(3):仅当两个相邻的直角边格子都可通行时才允许对角线移动。计算方式继续上面的例子必须(1,0)和(0,1)都可通行才允许从(0,0)到(1,1)。游戏影响这是最严格的对角线规则。单位几乎无法贴着障碍物进行对角线移动移动范围在障碍物边角处会有明显的“切角”现象。它提供了最高的战术确定性和“真实感”但机动性最受限制。实现场景强调真实地形战术、或者希望移动规则极其严谨的硬核策略游戏。3.2 模式选择与性能考量如何为你的游戏选择快节奏/高幻想选ALWAYS。严谨/机器人主题选NEVER。经典战棋/平衡之选选IF_AT_LEAST_ONE_WALKABLE。硬核战术/模拟真实选IF_ALL_WALKABLE。性能上这四种模式对AstarGrid2D的计算复杂度影响微乎其微因为判断逻辑是内置的、高效的。你的选择应完全基于游戏设计需求。实操心得不要小看这个选择。在项目早期就用一个可配置的变量来控制diagonal_mode并在你的关卡中实际测试不同模式带来的手感差异。我曾在原型阶段从ALWAYS切换到IF_AT_LEAST_ONE_WALKABLE发现单位再也不会鬼畜地贴墙滑行了关卡设计也变得更有意义。3.3 在AstarGrid2D中配置模式配置非常简单在初始化你的AstarGrid2D实例后直接设置属性即可var astar_grid AStarGrid2D.new() func _ready(): astar_grid.size Vector2i(地图宽度, 地图高度) astar_grid.cell_size Vector2(格子大小, 格子大小) astar_grid.offset Vector2(格子大小/2, 格子大小/2) # 通常将点置于格子中心 # 关键设置选择对角线模式 astar_grid.diagonal_mode AStarGrid2D.DIAGONAL_MODE_IF_AT_LEAST_ONE_WALKABLE astar_grid.update() # 初始化更新这个设置是全局的意味着整个网格都遵循同一套对角线规则。如果你需要不同单位有不同的移动规则比如飞行单位用ALWAYS步兵用IF_AT_LEAST_ONE_WALKABLE那么你需要为不同类型的单位准备不同的AstarGrid2D实例或者在同一实例上动态切换模式并重新计算。4. 实战构建从地图到高亮的完整流程现在我们进入实战环节一步步搭建这个系统。假设我们使用Godot 4.2并且已经有一个用TileMap绘制好的基础地图。4.1 步骤一创建并初始化AstarGrid2D首先我们创建一个单独的脚本如MovementRangeCalculator.gd来封装所有计算逻辑。extends Node2D class_name MovementRangeCalculator export var map_tilemap: TileMap # 引用你的基础地图TileMap export var default_movement_cost: int 1 export var diagonal_mode: AStarGrid2D.DiagonalMode AStarGrid2D.DIAGONAL_MODE_IF_AT_LEAST_ONE_WALKABLE var _astar_grid: AStarGrid2D var _grid_size: Vector2i var _cell_size: Vector2 func _ready(): _initialize_astar_grid() func _initialize_astar_grid(): if not map_tilemap: push_error(“MovementRangeCalculator: 未指定 map_tilemap!”) return # 获取TileMap的网格大小假设地图铺满 var used_rect: Rect2i map_tilemap.get_used_rect() _grid_size used_rect.size _cell_size map_tilemap.tile_set.tile_size # 假设TileSet中所有Tile尺寸一致 _astar_grid AStarGrid2D.new() _astar_grid.size _grid_size _astar_grid.cell_size _cell_size _astar_grid.offset _cell_size / 2 # 将A*点置于格子中心 _astar_grid.diagonal_mode diagonal_mode _astar_grid.default_compute_heuristic AStarGrid2D.HEURISTIC_MANHATTAN _astar_grid.default_estimate_heuristic AStarGrid2D.HEURISTIC_MANHATTAN # 初始时将所有格子设为默认成本 _astar_grid.default_terrain 0 # 使用默认地形类型 # 我们需要一个自定义函数来为每个格子设置具体成本 _update_cell_weights_for_entire_map() _astar_grid.update() func _update_cell_weights_for_entire_map(): # 遍历所有格子根据TileMap的图层信息设置移动成本 for x in range(_grid_size.x): for y in range(_grid_size.y): var cell_coords Vector2i(x, y) map_tilemap.get_used_rect().position var terrain_id _get_terrain_at_cell(cell_coords) var cost _get_movement_cost(terrain_id) _astar_grid.set_point_weight_scale(cell_coords, cost)这里的关键是_update_cell_weights_for_entire_map函数。它遍历每个格子根据格子对应的地形通过_get_terrain_at_cell获取查询移动成本表_get_movement_cost然后使用set_point_weight_scale设置该格子的基础通行权重。权重值越高移动通过它就越“贵”。设置为0或负数通常会被视为不可通行。4.2 步骤二动态处理单位占据与障碍地图上的障碍和友军单位会阻挡移动。我们需要在计算某个单位的移动范围前动态更新AstarGrid2D中这些格子的权重。func calculate_movement_range(unit_cell_pos: Vector2i, movement_points: int, blocking_cells: Array[Vector2i] []) - Array[Vector2i]: 计算单位在指定行动力下的可移动范围。 参数: unit_cell_pos: 单位所在的格子坐标TileMap坐标。 movement_points: 单位的行动力上限。 blocking_cells: 其他单位或障碍物占据的格子坐标数组。 返回: 可达的格子坐标数组。 # 1. 备份当前权重状态可选如果计算频繁且需要重置 # 2. 应用动态阻挡将阻挡格子的权重设为极大值不可通行 for block_cell in blocking_cells: # 确保坐标在网格内 if _is_in_grid(block_cell): _astar_grid.set_point_weight_scale(block_cell, 99999.0) # 一个很大的数 # 3. 确保起点是可通行的单位自己站的位置 _astar_grid.set_point_weight_scale(unit_cell_pos, 0.0) # 起点成本为0 # 4. 核心计算获取所有可达点 var reachable_cells: Array[Vector2i] [] # AstarGrid2D没有直接获取“所有成本低于X的点”的函数。 # 我们需要使用get_point_path计算到每个点的成本但这很低效。 # 更优方案使用A*算法原理但我们利用其内部数据结构不Godot未暴露。 # 实际做法实现一个基于优先队列的Dijkstra算法变种但这里我们用一个简化方法 # 遍历所有格子检查从起点到该点的“估算成本”是否可行。但AstarGrid2D不直接提供此接口。 # 因此我们需要自己实现一个基于AstarGrid2D的“可移动范围洪水填充”。 # 让我们实现一个定制的洪水填充函数 reachable_cells _flood_fill_movement_range(unit_cell_pos, movement_points) # 5. 恢复被修改的格子权重如果之前备份了 for block_cell in blocking_cells: if _is_in_grid(block_cell): _astar_grid.set_point_weight_scale(block_cell, _get_movement_cost(_get_terrain_at_cell(block_cell))) _astar_grid.set_point_weight_scale(unit_cell_pos, _get_movement_cost(_get_terrain_at_cell(unit_cell_pos))) return reachable_cells func _is_in_grid(cell: Vector2i) - bool: var origin map_tilemap.get_used_rect().position return cell.x origin.x and cell.x origin.x _grid_size.x and cell.y origin.y and cell.y origin.y _grid_size.y这里遇到了一个关键问题AstarGrid2D没有直接提供“获取所有移动成本在N以内的点”的API。get_point_path只能获取两点间的路径和总成本如果对每个格子都调用在100x100的地图上就是一万次寻路性能不可接受。解决方案我们需要基于AstarGrid2D提供的“格子权重”和“对角线规则”自己实现一个移动力消耗感知的洪水填充算法Dijkstra算法。这正是AstarGrid2D内部寻路算法的前半部分探索阶段。好消息是我们可以利用AstarGrid2D已经设置好的权重和规则让我们的填充算法逻辑保持一致。4.3 步骤三实现移动力感知的洪水填充算法这是本项目的核心算法。我们将使用一个优先队列最小堆来高效地处理待探索的格子确保总是先探索移动成本最低的格子。func _flood_fill_movement_range(start_cell: Vector2i, max_cost: int) - Array[Vector2i]: var reachable: Array[Vector2i] [] # 使用字典记录到达每个格子的最小已知成本 var cost_so_far: Dictionary {} # 使用数组模拟优先队列Godot没有内置优先队列这里用简单数组排序替代对于小范围计算够用。 # 对于大地图建议实现一个真正的二叉堆。 var frontier: Array [] # 元素格式: [累计成本, 格子坐标] frontier.append([0, start_cell]) cost_so_far[start_cell] 0 # 定义四个正交方向和四个对角线方向 var orthogonal_dirs [Vector2i.RIGHT, Vector2i.LEFT, Vector2i.DOWN, Vector2i.UP] var diagonal_dirs [ Vector2i(1, 1), Vector2i(1, -1), Vector2i(-1, 1), Vector2i(-1, -1) ] var all_dirs orthogonal_dirs diagonal_dirs while frontier.size() 0: # 按成本排序取出成本最小的格子 frontier.sort_custom(func(a, b): return a[0] b[0]) var current frontier.pop_front() var current_cost: int current[0] var current_cell: Vector2i current[1] # 检查所有可能的方向 for dir in all_dirs: var next_cell current_cell dir if not _is_in_grid(next_cell): continue # --- 关键根据对角线模式判断该方向是否允许 --- var is_diagonal (abs(dir.x) 1 and abs(dir.y) 1) if is_diagonal: if not _is_diagonal_move_allowed(current_cell, dir): continue # 根据当前模式跳过不允许的对角线移动 # 获取下一个格子的地形移动成本 var terrain_cost _get_movement_cost(_get_terrain_at_cell(next_cell)) if terrain_cost 999: # 不可通行地形 continue # 计算移动到下一个格子的总成本 # 对角线成本更高这里简化处理如果AstarGrid2D的diagonal_mode不是NEVER且是斜向成本*1.4近似sqrt2) var move_cost_multiplier 1.0 if is_diagonal and _astar_grid.diagonal_mode ! AStarGrid2D.DIAGONAL_MODE_NEVER: move_cost_multiplier 1.4 # 近似值也可用14代替10 var new_cost current_cost ceil(terrain_cost * move_cost_multiplier) # 向上取整 # 如果新成本超过行动力或不是更优路径则跳过 if new_cost max_cost: continue if next_cell in cost_so_far and cost_so_far[next_cell] new_cost: continue # 找到一条更优或新路径记录并加入探索队列 cost_so_far[next_cell] new_cost frontier.append([new_cost, next_cell]) # 遍历cost_so_far所有记录在内的格子都是可达的成本未超过max_cost reachable cost_so_far.keys() # 别忘了包含起点本身 if start_cell not in reachable: reachable.append(start_cell) return reachable func _is_diagonal_move_allowed(from_cell: Vector2i, dir: Vector2i) - bool: 根据当前AstarGrid2D设置的diagonal_mode判断是否允许这次对角线移动。 dir 是类似 (1, 1) 的对角线方向向量。 var mode _astar_grid.diagonal_mode if mode AStarGrid2D.DIAGONAL_MODE_ALWAYS: return true if mode AStarGrid2D.DIAGONAL_MODE_NEVER: return false # 检查两个相邻直角边格子 var neighbor1 from_cell Vector2i(dir.x, 0) var neighbor2 from_cell Vector2i(0, dir.y) var cost1 _get_movement_cost(_get_terrain_at_cell(neighbor1)) if _is_in_grid(neighbor1) else 999 var cost2 _get_movement_cost(_get_terrain_at_cell(neighbor2)) if _is_in_grid(neighbor2) else 999 if mode AStarGrid2D.DIAGONAL_MODE_IF_AT_LEAST_ONE_WALKABLE: return cost1 999 or cost2 999 # 至少一个可通行 elif mode AStarGrid2D.DIAGONAL_MODE_IF_ALL_WALKABLE: return cost1 999 and cost2 999 # 两个都必须可通行 return false # 默认不允许这个_flood_fill_movement_range函数是范围计算的核心。它模拟了单位移动力的“消耗”并严格遵守了我们设置的对角线规则。算法会从起点开始像水波纹一样扩散探索所有移动成本不超过max_cost的格子。实操心得这里的frontier数组用排序来模拟优先队列在行动力范围较小比如20格以内时完全够用且代码简单。但如果你的游戏有行动力非常高的单位如飞行单位或者地图巨大建议实现一个真正的最小堆Min-Heap来管理frontier这样pop和push操作的时间复杂度是O(log n)而不是O(n log n)。Godot 4.2的GDScript 2.0支持自定义类实现一个简单的堆结构并不难。4.4 步骤四高亮渲染与性能优化计算出可达格子列表Array[Vector2i]后我们需要将其可视化。简单方法使用第二个TileMap作为高亮层# 在你的主场景或一个专门的Highlighter节点中 onready var highlight_tilemap: TileMap $HighlightTileMap onready var calculator: MovementRangeCalculator $MovementRangeCalculator func highlight_movement_range(unit_cell: Vector2i, movement_points: int): # 1. 清除之前的高亮 highlight_tilemap.clear() # 2. 计算范围 var blocking_cells get_blocking_cells() # 从游戏管理器获取所有障碍物坐标 var reachable_cells calculator.calculate_movement_range(unit_cell, movement_points, blocking_cells) # 3. 在高亮TileMap上放置高亮图块 var highlight_tile_id highlight_tilemap.get_tileset().find_tile_by_name(“movement_highlight”) for cell in reachable_cells: highlight_tilemap.set_cell(0, cell, highlight_tile_id, Vector2i.ZERO)这种方法简单直接利用Godot的TileMap批量渲染性能很好。你只需要在TileSet中准备一个半透明的蓝色或绿色图块。性能优化点避免每帧计算只在单位被选中或地图状态改变时计算。缓存结果如果单位位置和行动力未变且地图阻挡未变可以直接使用上一次的计算结果。减少高亮图块更新只更新发生变化的部分格子而不是全部清除重设。可以比较新旧reachable_cells数组的差异。使用MultiMeshInstance2D高级对于需要复杂着色效果如渐变、脉冲的高亮TileMap可能受限。可以使用MultiMeshInstance2D配合自定义着色器绘制数百个高亮四边形性能极高且效果炫酷。但这需要更多的图形编程知识。5. 常见问题、调试技巧与扩展思路5.1 问题排查清单在实际集成中你可能会遇到以下问题问题现象可能原因解决方案高亮范围形状奇怪不对称1. 对角线模式设置错误。2. 洪水填充算法中成本计算有误如对角线成本没乘系数。3. 地图某些格子的地形成本设置异常。1. 打印diagonal_mode值确认。2. 在_flood_fill_movement_range中打印new_cost的计算过程。3. 遍历地图打印每个格子的_get_movement_cost返回值。单位可以“穿过”障碍物1. 障碍物格子权重未正确设置为高值如999。2.blocking_cells数组未正确传递给计算函数。3. 对角线模式为ALWAYS且单位从“缝隙”中挤过。1. 检查set_point_weight_scale调用。2. 调试calculate_movement_range函数入口查看blocking_cells内容。3. 考虑切换到更严格的对角线模式。计算速度慢游戏卡顿1. 行动力过高导致洪水填充探索格子过多。2. 每帧都在计算。3.frontier排序效率低使用数组排序。1. 从设计上限制最大行动力。2. 确保计算是事件触发而非每帧执行。3. 实现最小堆优先队列。高亮不显示或显示错位1.highlight_tilemap的图层、坐标原点和map_tilemap不一致。2. 格子坐标转换错误TileMap坐标 vs 世界坐标。3. 高亮图块源尺寸不匹配。1. 确保两个TileMap的tile_set、cell_size一致且处于同一坐标系。2. 使用map_to_local和local_to_map进行转换调试。3. 检查TileSet中图块的纹理区域设置。5.2 调试可视化技巧Godot的AstarGrid2D自带调试绘制但对我们这个场景帮助有限。更实用的方法是控制台打印关键数据在计算函数中打印起点、行动力、最终得到的reachable_cells数量和前几个坐标确保逻辑正确。绘制调试图形在_process中使用CanvasItem的draw_rect或draw_circle函数将计算出的可达格子用不同颜色临时画出来。这比修改TileMap更灵活且不影响正式渲染。func _draw(): if not reachable_cells_for_debug.is_empty(): for cell in reachable_cells_for_debug: var rect Rect2(map_tilemap.map_to_local(cell), map_tilemap.cell_size) draw_rect(rect, Color.GREEN.with_alpha(0.3), true)单步调试在计算函数中设置断点观察frontier队列和cost_so_far字典的变化过程。5.3 功能扩展思路一个基础的行动力范围系统完成后你可以考虑以下扩展让游戏更具深度差异化地形消耗已经实现。可以更复杂如“骑兵在平原消耗1在森林消耗3”。单位特性某些单位可以无视特定地形如飞行单位过水域或拥有特殊移动方式如传送。可以在_get_movement_cost函数中加入单位参数来判断。技能与效果影响如“加速术”使单位本回合行动力2“流沙”地形使经过的单位移动消耗加倍。这需要在计算前动态修改movement_points或特定格子的地形成本。攻击范围联动计算完移动范围后可以进一步计算“从每个可达格子出发单位的攻击范围”并用不同颜色如红色叠加显示形成“移动攻击”预览这是战棋游戏的标配。移动路径预览当玩家鼠标悬停在一个可达格子上时实时显示从当前位置到该格子的具体移动路径。这需要调用AstarGrid2D的get_point_path方法并将路径坐标用一条线或一系列箭头绘制出来。实现路径预览时要注意性能。不要每帧对每个悬停格子都寻路只在鼠标进入新的可达格子时计算一次并缓存。同时确保寻路使用的AstarGrid2D实例其权重设置障碍与计算移动范围时一致。最后别忘了将你的MovementRangeCalculator做成一个可重用的场景或单例方便在游戏的不同关卡和模式中调用。通过良好的参数化设计导出变量diagonal_mode、movement_cost_table等你可以轻松调整游戏的整体移动手感直到找到最适合你游戏设计的那一种。