1. 网格系统策略游戏的基石在策略游戏的开发世界里地图网格系统是那个“看不见的骨架”。它不像华丽的特效或精致的模型那样引人注目但却是所有战术决策、单位移动、资源管理和战斗计算得以发生的绝对基础。无论是《文明》系列中六边形铺满的广袤大陆还是《星际争霸》里矩形划分的微观战场网格都在背后默默定义着游戏的规则与边界。对于Unity开发者而言理解并亲手实现一套高效、灵活的网格系统是从“会做游戏”到“懂做游戏”的关键一步。这不仅仅是画格子那么简单它涉及到数据结构设计、空间转换、寻路算法以及性能优化等一系列核心问题。接下来我将结合多年的项目经验为你彻底拆解在Unity中实现策略游戏地图网格的完整思路、技术细节与避坑指南。2. 网格系统的核心设计与架构思路2.1 网格类型选型方形、六边形与点阵选择哪种网格形状是设计初期最重要的决策它直接决定了游戏的玩法风格和后续所有系统的复杂度。方形网格矩形/正方形是最直观、最容易实现的选择。它的坐标转换极其简单一个二维数组grid[x, y]就能完美映射。在Unity中一个Transform的position可以轻松通过(x * cellSize, 0, y * cellSize)计算得出。它的寻路算法如A*实现起来也最标准。许多经典的RTS游戏如《帝国时代》、《红色警戒》都采用此方案。它的缺点是移动方向被限制在4向或8向看起来不够自然对角移动距离按格子数算与欧几里得距离存在差异。六边形网格是策略游戏的“黄金标准”因其无中心点距离相等的特性而备受青睐。在六边形网格中从一个格子移动到任何相邻格子的“代价”是均等的这使得移动和范围计算如攻击范围、视野更加公平和真实。像《文明》系列、《英雄无敌》系列都采用了六边形网格。但其实现复杂度陡增坐标系统有立方体坐标、轴向坐标等多种表示法寻路算法中的邻居查找逻辑也更复杂地图的渲染尤其是贴图拼接也需要特殊处理。点阵网格或自由网格则更加自由它不强调规则的几何形状划分而是将地图离散化为一系列连接的点节点。单位可以在这些点之间沿连接线移动。这常用于一些需要复杂地形连接的策略游戏或模拟经营游戏。它的实现更接近于图论灵活性最高但设计和平衡的难度也最大。实操心得对于中小型团队或首个策略游戏项目我强烈建议从方形网格开始。它的低复杂度能让你快速搭建起游戏原型验证核心玩法。六边形网格的魅力巨大但请做好投入至少双倍开发时间进行基础设施搭建的心理准备。2.2 数据层与表现层的分离MVC思想的应用一个健壮的网格系统必须遵循“数据与表现分离”的原则。这是避免后期代码混乱、提升可维护性的关键。数据层Model是网格系统的核心大脑。它不关心Unity的GameObject只负责存储和管理网格的状态。这通常是一个纯粹的C#类可能包含一个二维数组或字典每个网格单元Cell是一个数据结构体存储如下信息坐标在网格系统中的位置如(x, y)。通行状态是否可被单位行走布尔值。地形类型草地、森林、山地、水域等每种类型可能影响移动消耗、防御加成。占据单位当前位于该格子的单位引用可为空。其他游戏逻辑数据如视野覆盖、归属势力、资源储量等。表现层View负责将数据层的状态可视化。它监听数据层的变化并在Unity场景中生成或更新对应的视觉元素。例如根据地形类型实例化不同的地形预制体Prefab。当单位移动时更新单位GameObject的Transform.position。高亮显示可移动范围或攻击范围。控制层Controller处理输入和逻辑流转。例如当玩家点击一个格子时控制器会判断这个点击意图移动、攻击、使用技能然后调用数据层的方法更新状态最后通知表现层更新视图。这种分离使得你可以独立修改美术资源如更换地形贴图而无需触碰核心逻辑也方便未来进行网络同步只需同步数据层状态。2.3 坐标系转换连接逻辑与世界的桥梁这是新手最容易卡壳的地方。我们的游戏逻辑运行在网格坐标系离散的整数坐标如(2,5)中而Unity的世界空间使用的是世界坐标系连续的浮点向量如(2.5, 0, 12.3)。两者之间的无缝转换是系统流畅运行的基础。核心转换函数通常会被封装在一个GridManager或GridUtility静态类中public class GridSystem : MonoBehaviour { public float cellSize 1f; // 每个格子的边长 public Vector3 gridOrigin Vector3.zero; // 网格原点在世界中的位置 // 世界坐标 - 网格坐标 public Vector2Int WorldToGrid(Vector3 worldPos) { // 计算相对于原点的偏移并除以格子大小最后取整 int x Mathf.FloorToInt((worldPos.x - gridOrigin.x) / cellSize); int z Mathf.FloorToInt((worldPos.z - gridOrigin.z) / cellSize); // 注意Unity是Y轴向上 return new Vector2Int(x, z); } // 网格坐标 - 世界坐标获取格子中心点 public Vector3 GridToWorld(Vector2Int gridPos) { float x gridPos.x * cellSize cellSize * 0.5f gridOrigin.x; float z gridPos.y * cellSize cellSize * 0.5f gridOrigin.z; // 注意y和z的对应关系 return new Vector3(x, 0, z); // Y轴高度可根据地形数据另行计算 } }注意事项务必注意Unity的坐标系是左手系Y轴向上。因此在2D平面网格中我们通常用(x, z)来对应逻辑上的(x, y)。Mathf.FloorToInt确保了世界坐标点总是映射到它所在的唯一格子内这对于点击检测至关重要。3. 网格系统的核心实现细节与难点攻克3.1 网格数据的存储与高效访问如何存储一个可能很大的网格例如100x100简单的二维数组Cell[,] grid是最直接的方式访问速度是O(1)。但当地图非常大且稀疏很多格子为空或无效时数组会浪费内存。此时可以考虑使用DictionaryVector2Int, Cell它只存储有效的格子但访问速度是近似O(1)比数组稍慢。混合存储策略是一个折中方案对于规则矩形区域使用数组对于地图边缘的不规则部分或动态生成的区域使用字典。在《文明》类的大型地图中常采用分块Chunk加载将大地图划分为多个小块如16x16每个块用一个数组存储只有玩家视野内的块才会被加载到内存和渲染。Cell类的设计也大有讲究。避免使用MonoBehaviour因为它有额外的开销。使用纯C#的struct如果较小且不可变或class。一个典型的Cell类可能如下public class GridCell { public Vector2Int Coordinate { get; private set; } public TerrainType Terrain { get; set; } public bool IsWalkable Terrain.baseMoveCost int.MaxValue; // 根据地形移动成本判断是否可通行 public int BaseMoveCost Terrain.baseMoveCost; // 地形基础移动力消耗 public Unit OccupyingUnit { get; set; } // 当前占据的单位 // ... 其他属性如防御修正、视野阻挡等 }3.2 寻路算法的集成与优化寻路是策略游戏的灵魂。A*A-Star算法是网格寻路的事实标准。Unity内置的NavMesh系统对于RPG或FPS很友好但对于需要高度定制化移动规则如不同单位对不同地形的消耗不同、动态阻挡的策略游戏往往需要自己实现基于网格的A*。实现要点开放列表与关闭列表使用PriorityQueue可通过SortedList或第三方库实现来维护开放列表确保每次都能取出F成本最低的节点这是A*性能的关键。启发函数Heuristic对于方形网格常用曼哈顿距离仅4方向移动或切比雪夫距离/对角线距离允许8方向移动。对于六边形网格需要使用适配的六边形距离公式。移动成本G Cost不要只设为1。应该从当前格子的Cell对象中读取BaseMoveCost。这样穿越森林成本2就比走草地成本1更“贵”。动态阻挡除了地形的静态不可通行属性还需要在寻路前检查目标格子的OccupyingUnit属性判断是否被友方或敌方单位阻挡。性能优化技巧路径缓存对于AI单位如果目标点短时间内未变化可以复用上一次的计算结果。分层寻路HPA*对于超大地图先将地图抽象成由大区域Cluster构成的粗粒度网格先在大网格间寻路再在单个区域内精细寻路。Jump Point SearchJPS针对均匀网格的优化算法可以跳过大量不必要的节点评估在开放地形上能极大提升速度。Unity Asset Store上有成熟的JPS插件。3.3 范围计算与网格交互策略游戏中经常需要计算“移动范围”、“攻击范围”或“技能影响范围”。这本质上是基于网格的图搜索问题。移动范围行动力扩散通常使用广度优先搜索BFS或Dijkstra算法。从单位所在格子出发向相邻格子扩散每次扩散消耗该格子的移动成本直到累计消耗超过单位的行动力MP为止。最终所有访问过的、且可通行的格子就是可移动范围。public HashSetVector2Int CalculateMoveRange(Vector2Int startPos, int movePoints) { var reachableCells new HashSetVector2Int(); var frontier new PriorityQueueCellNode, int(); // 使用优先队列按剩余移动力排序 var costSoFar new DictionaryVector2Int, int { { startPos, 0 } }; frontier.Enqueue(new CellNode(startPos, movePoints), movePoints); while (frontier.Count 0) { var current frontier.Dequeue(); reachableCells.Add(current.Position); foreach (var neighbor in GetNeighbors(current.Position)) { var cell GetCell(neighbor); if (!cell.IsWalkable) continue; int newCost costSoFar[current.Position] cell.BaseMoveCost; if (newCost movePoints (!costSoFar.ContainsKey(neighbor) || newCost costSoFar[neighbor])) { costSoFar[neighbor] newCost; int remainingMP movePoints - newCost; frontier.Enqueue(new CellNode(neighbor, remainingMP), remainingMP); } } } return reachableCells; }攻击/技能范围这可能是一个固定形状如十字形、菱形、圆形的格子集合。可以预计算好不同半径、不同形状的“模板”在需要时直接套用到中心点上并过滤掉地图边界外的非法格子。对于圆形范围可以使用中点圆算法的网格版本来高效计算覆盖的格子。4. 网格的视觉表现与性能调优实战4.1 网格的绘制与高亮反馈在编辑器和运行时可视化网格对于调试和玩家体验都至关重要。编辑器下绘制在自定义的Editor脚本中使用Handles或Gizmos在OnDrawGizmos或OnSceneGUI方法中绘制网格线。这能让你在场景视图中清晰地看到网格划分。// 在GridSystem组件的OnDrawGizmosSelected中 private void OnDrawGizmosSelected() { Gizmos.color Color.white; for (int x 0; x gridWidth; x) { for (int y 0; y gridHeight; y) { Vector3 center GridToWorld(new Vector2Int(x, y)); Vector3 size Vector3.one * cellSize; size.y 0.01f; // 画一个扁平的线框 Gizmos.DrawWireCube(center, size); } } }运行时高亮当玩家选中单位或悬停格子时需要高亮显示可移动范围、攻击范围或路径。有两种主流做法Shader高亮为地形材质编写一个自定义Shader接收一个高亮颜色和强度参数。通过脚本将需要高亮的格子坐标数组传递给ShaderShader在片元着色器中判断当前像素属于哪个格子若在数组中则混合高亮色。这种方法性能最优但Shader编写有一定门槛。透明面片覆盖为每个需要高亮的格子动态生成一个半透明的Quad面片GameObject。这种方法实现简单但格子数量多时如大范围高亮实例化大量GameObject会造成严重的性能开销和Draw Call激增。推荐方案采用对象池Object Pooling管理高亮面片。预先创建一定数量的高亮面片预制体放入池中需要高亮时从池中取出并放置到对应格子位置取消高亮时放回池中。这避免了频繁的Instantiate和Destroy操作。对于固定地图甚至可以预先为每个格子生成一个高亮子节点并默认禁用需要时直接启用这是最直接的方法。4.2 地形表现与网格的关联地形不仅仅是贴图它的视觉表现必须与网格数据严格同步。一个常见的架构是GridSystem管理核心数据和逻辑。TerrainManager负责根据GridSystem中每个Cell的TerrainType在场景中生成或管理对应的地形视觉元素。实现方式预制体拼接为每种地形类型草地、沙漠、雪地等制作一个或多个Prefab其中包含模型、贴图和可能的地形装饰如小石头、草簇。在初始化地图时根据网格数据在对应世界坐标实例化对应的Prefab。这种方式灵活可以做出非常丰富的视觉效果。地形纹理Terrain使用Unity的Terrain系统将网格数据转换为Terrain的高度图和纹理混合图。这种方式适合连续起伏的自然地形但对于策略游戏精确的格子划分和格子级别的属性控制反而不如预制体方便。Shader Graph/材质属性块使用一张大的平面通过Shader根据世界坐标或UV坐标来查询网格数据动态改变局部区域的材质属性如颜色、纹理、法线。这需要较强的图形学功底但性能极佳适合风格化或移动端游戏。踩坑实录曾经在一个项目中我们使用了预制体拼接。当地图尺寸扩大到256x256时场景中的GameObject数量超过了6万个导致编辑器卡顿运行时帧率下降。解决方案是采用了静态合批Static Batching。我们将所有相同材质的地形预制体的模型标记为StaticUnity在构建时会自动将它们合并成更少的Draw Call。但注意静态合批后这些物体将无法移动。对于策略游戏的地形这通常是可接受的。4.3 性能瓶颈分析与优化策略网格系统在运行时的主要开销来自寻路计算、范围计算和视觉渲染。1. 寻路优化异步计算将A*寻路放到单独的线程或使用UnityWebRequest那样的协程异步操作避免阻塞主线程导致卡顿。可以使用C#的Task或Job System配合Burst编译进行多线程寻路。简化网格对于AI的长期路径规划可以使用更粗糙的网格比如把4x4的小格子合并成一个大格子进行高层规划再在局部进行精细寻路。预设路径对于固定巡逻路线或常用路径可以预先计算并存储。2. 范围计算优化缓存结果单位的移动范围在行动力未消耗、周围地形未改变时结果是相同的。可以缓存计算结果直到相关状态失效。增量更新如果只是地图上少数格子状态改变如一个可通行的桥梁被摧毁可以只重新计算受影响的单位范围而非全部重算。3. 渲染优化LOD多层次细节对于远离相机的地形块使用面数更少、贴图分辨率更低的模型。遮挡剔除Occlusion Culling在Unity中正确设置遮挡区域确保相机看不到的地形块不被渲染。GPU Instancing如果大量地形使用相同的材质和模型启用GPU Instancing可以极大减少Draw Call。确保你的地形材质球勾选了“Enable GPU Instancing”选项。5. 高级应用与常见问题排查5.1 多层地图与高度处理许多策略游戏如《英雄无敌》中的地下城与地上世界或需要地形高低差的游戏如《战争艺术》需要支持多层地图。这可以通过扩展网格的Z坐标或Y坐标取决于你的定义来实现将数据结构从Grid[x, y]变为Grid[x, y, level]。高度影响移动成本上坡和下坡可以设置不同的移动消耗。视野与攻击高地单位可能拥有更远的视野和攻击范围并能攻击低地单位而低地单位可能无法反击模拟现实中的高度优势。通行性过高的悬崖可能无法直接通行需要绕路或使用技能。在寻路和范围计算时邻居查找的逻辑需要将高度差作为一个因素考虑进去。例如从一个格子到另一个高度差为2的相邻格子可能被视为“不可直接通行”。5.2 动态改变网格属性地图不是一成不变的。技能可能烧毁森林将地形从“森林”变为“焦土”移动成本改变工程师可能建造桥梁将“水域”变为“可通行”。实现关键事件驱动当网格属性改变时触发一个事件如OnCellChanged。通知相关系统所有依赖网格状态的系统都需要监听这个事件。寻路系统需要清除或更新受影响的缓存路径。单位系统如果单位正站在发生改变的格子上可能需要重新计算其状态例如站在被烧毁的森林里受到持续伤害。表现系统需要更新该格子的视觉表现更换预制体或修改材质。批量更新如果一整个区域发生变化如陨石术砸出一个大坑应设计批量更新接口避免频繁触发单个事件导致性能问题。5.3 常见问题排查速查表问题现象可能原因排查与解决方案单位移动“卡顿”或“抖动”1. 世界坐标与网格坐标转换存在浮点数精度误差。2. 移动动画的插值Lerp时间设置不当或与逻辑更新帧不同步。1. 确保GridToWorld和WorldToGrid函数互为逆运算且使用相同的gridOrigin和cellSize。移动目标点使用GridToWorld计算出的精确中心点。2. 将单位的移动逻辑放在FixedUpdate中而将视觉插值放在Update中确保逻辑帧稳定。点击选择格子不准确1. 用于射线检测的碰撞体Collider大小或位置与视觉网格未对齐。2. 射线检测的层Layer设置错误。1. 为每个格子创建一个与cellSize匹配的碰撞体如Box Collider并将其中心点通过GridToWorld对齐。或者使用一个大的平面碰撞体通过WorldToGrid转换点击点。2. 确保射线检测只针对地形层Terrain Layer避免选中单位等其他物体。寻路速度慢大型地图卡顿1. A*算法的开放列表数据结构效率低。2. 地图过大搜索节点过多。3. 每帧进行了多次寻路。1. 将开放列表从List更换为PriorityQueue如使用SortedSet或Heap实现。2. 实现分层寻路HPA*或转向JPS算法。3. 限制每帧寻路的次数或将寻路请求加入队列异步处理。高亮范围时帧率骤降1. 为每个高亮格子都 Instantiate 了新的 GameObject。2. 高亮面片使用了复杂的材质或Shader。1. 改用对象池管理高亮面片。2. 使用最简单的无光照、顶点颜色Shader来绘制高亮面片。考虑使用Shader一次性绘制所有高亮区域通过传递位置数组。单位可以“穿墙”或走到不可通行区域1. 寻路算法中未正确判断格子的IsWalkable属性。2. 动态阻挡如其他单位未在寻路时实时更新。3. 客户端与服务端网格状态不同步网络游戏。1. 在寻路邻居查找和移动成本计算中严格检查目标格子的通行性。2. 单位移动前再次验证路径上每个格子的实时状态通行性、占据单位。3. 确保所有改变地图状态的逻辑都在服务端权威执行并同步给所有客户端。实现一套完善的策略游戏网格系统是一个从抽象逻辑到具体表现、从数据结构到算法优化、从功能实现到性能打磨的完整闭环。它没有太多炫技的成分更多的是对细节的严谨把控和对架构的清晰思考。当你看到单位在格子上流畅移动、攻击范围被精准高亮、AI凭借你写的寻路算法做出精妙绕后时那种成就感是实实在在的。这套系统将成为你策略游戏项目最稳固的基石在此之上复杂的规则、丰富的技能和深度的策略才能得以构建。
Unity策略游戏开发：网格系统核心设计与A*寻路算法实战
发布时间：2026/7/21 2:16:49
1. 网格系统策略游戏的基石在策略游戏的开发世界里地图网格系统是那个“看不见的骨架”。它不像华丽的特效或精致的模型那样引人注目但却是所有战术决策、单位移动、资源管理和战斗计算得以发生的绝对基础。无论是《文明》系列中六边形铺满的广袤大陆还是《星际争霸》里矩形划分的微观战场网格都在背后默默定义着游戏的规则与边界。对于Unity开发者而言理解并亲手实现一套高效、灵活的网格系统是从“会做游戏”到“懂做游戏”的关键一步。这不仅仅是画格子那么简单它涉及到数据结构设计、空间转换、寻路算法以及性能优化等一系列核心问题。接下来我将结合多年的项目经验为你彻底拆解在Unity中实现策略游戏地图网格的完整思路、技术细节与避坑指南。2. 网格系统的核心设计与架构思路2.1 网格类型选型方形、六边形与点阵选择哪种网格形状是设计初期最重要的决策它直接决定了游戏的玩法风格和后续所有系统的复杂度。方形网格矩形/正方形是最直观、最容易实现的选择。它的坐标转换极其简单一个二维数组grid[x, y]就能完美映射。在Unity中一个Transform的position可以轻松通过(x * cellSize, 0, y * cellSize)计算得出。它的寻路算法如A*实现起来也最标准。许多经典的RTS游戏如《帝国时代》、《红色警戒》都采用此方案。它的缺点是移动方向被限制在4向或8向看起来不够自然对角移动距离按格子数算与欧几里得距离存在差异。六边形网格是策略游戏的“黄金标准”因其无中心点距离相等的特性而备受青睐。在六边形网格中从一个格子移动到任何相邻格子的“代价”是均等的这使得移动和范围计算如攻击范围、视野更加公平和真实。像《文明》系列、《英雄无敌》系列都采用了六边形网格。但其实现复杂度陡增坐标系统有立方体坐标、轴向坐标等多种表示法寻路算法中的邻居查找逻辑也更复杂地图的渲染尤其是贴图拼接也需要特殊处理。点阵网格或自由网格则更加自由它不强调规则的几何形状划分而是将地图离散化为一系列连接的点节点。单位可以在这些点之间沿连接线移动。这常用于一些需要复杂地形连接的策略游戏或模拟经营游戏。它的实现更接近于图论灵活性最高但设计和平衡的难度也最大。实操心得对于中小型团队或首个策略游戏项目我强烈建议从方形网格开始。它的低复杂度能让你快速搭建起游戏原型验证核心玩法。六边形网格的魅力巨大但请做好投入至少双倍开发时间进行基础设施搭建的心理准备。2.2 数据层与表现层的分离MVC思想的应用一个健壮的网格系统必须遵循“数据与表现分离”的原则。这是避免后期代码混乱、提升可维护性的关键。数据层Model是网格系统的核心大脑。它不关心Unity的GameObject只负责存储和管理网格的状态。这通常是一个纯粹的C#类可能包含一个二维数组或字典每个网格单元Cell是一个数据结构体存储如下信息坐标在网格系统中的位置如(x, y)。通行状态是否可被单位行走布尔值。地形类型草地、森林、山地、水域等每种类型可能影响移动消耗、防御加成。占据单位当前位于该格子的单位引用可为空。其他游戏逻辑数据如视野覆盖、归属势力、资源储量等。表现层View负责将数据层的状态可视化。它监听数据层的变化并在Unity场景中生成或更新对应的视觉元素。例如根据地形类型实例化不同的地形预制体Prefab。当单位移动时更新单位GameObject的Transform.position。高亮显示可移动范围或攻击范围。控制层Controller处理输入和逻辑流转。例如当玩家点击一个格子时控制器会判断这个点击意图移动、攻击、使用技能然后调用数据层的方法更新状态最后通知表现层更新视图。这种分离使得你可以独立修改美术资源如更换地形贴图而无需触碰核心逻辑也方便未来进行网络同步只需同步数据层状态。2.3 坐标系转换连接逻辑与世界的桥梁这是新手最容易卡壳的地方。我们的游戏逻辑运行在网格坐标系离散的整数坐标如(2,5)中而Unity的世界空间使用的是世界坐标系连续的浮点向量如(2.5, 0, 12.3)。两者之间的无缝转换是系统流畅运行的基础。核心转换函数通常会被封装在一个GridManager或GridUtility静态类中public class GridSystem : MonoBehaviour { public float cellSize 1f; // 每个格子的边长 public Vector3 gridOrigin Vector3.zero; // 网格原点在世界中的位置 // 世界坐标 - 网格坐标 public Vector2Int WorldToGrid(Vector3 worldPos) { // 计算相对于原点的偏移并除以格子大小最后取整 int x Mathf.FloorToInt((worldPos.x - gridOrigin.x) / cellSize); int z Mathf.FloorToInt((worldPos.z - gridOrigin.z) / cellSize); // 注意Unity是Y轴向上 return new Vector2Int(x, z); } // 网格坐标 - 世界坐标获取格子中心点 public Vector3 GridToWorld(Vector2Int gridPos) { float x gridPos.x * cellSize cellSize * 0.5f gridOrigin.x; float z gridPos.y * cellSize cellSize * 0.5f gridOrigin.z; // 注意y和z的对应关系 return new Vector3(x, 0, z); // Y轴高度可根据地形数据另行计算 } }注意事项务必注意Unity的坐标系是左手系Y轴向上。因此在2D平面网格中我们通常用(x, z)来对应逻辑上的(x, y)。Mathf.FloorToInt确保了世界坐标点总是映射到它所在的唯一格子内这对于点击检测至关重要。3. 网格系统的核心实现细节与难点攻克3.1 网格数据的存储与高效访问如何存储一个可能很大的网格例如100x100简单的二维数组Cell[,] grid是最直接的方式访问速度是O(1)。但当地图非常大且稀疏很多格子为空或无效时数组会浪费内存。此时可以考虑使用DictionaryVector2Int, Cell它只存储有效的格子但访问速度是近似O(1)比数组稍慢。混合存储策略是一个折中方案对于规则矩形区域使用数组对于地图边缘的不规则部分或动态生成的区域使用字典。在《文明》类的大型地图中常采用分块Chunk加载将大地图划分为多个小块如16x16每个块用一个数组存储只有玩家视野内的块才会被加载到内存和渲染。Cell类的设计也大有讲究。避免使用MonoBehaviour因为它有额外的开销。使用纯C#的struct如果较小且不可变或class。一个典型的Cell类可能如下public class GridCell { public Vector2Int Coordinate { get; private set; } public TerrainType Terrain { get; set; } public bool IsWalkable Terrain.baseMoveCost int.MaxValue; // 根据地形移动成本判断是否可通行 public int BaseMoveCost Terrain.baseMoveCost; // 地形基础移动力消耗 public Unit OccupyingUnit { get; set; } // 当前占据的单位 // ... 其他属性如防御修正、视野阻挡等 }3.2 寻路算法的集成与优化寻路是策略游戏的灵魂。A*A-Star算法是网格寻路的事实标准。Unity内置的NavMesh系统对于RPG或FPS很友好但对于需要高度定制化移动规则如不同单位对不同地形的消耗不同、动态阻挡的策略游戏往往需要自己实现基于网格的A*。实现要点开放列表与关闭列表使用PriorityQueue可通过SortedList或第三方库实现来维护开放列表确保每次都能取出F成本最低的节点这是A*性能的关键。启发函数Heuristic对于方形网格常用曼哈顿距离仅4方向移动或切比雪夫距离/对角线距离允许8方向移动。对于六边形网格需要使用适配的六边形距离公式。移动成本G Cost不要只设为1。应该从当前格子的Cell对象中读取BaseMoveCost。这样穿越森林成本2就比走草地成本1更“贵”。动态阻挡除了地形的静态不可通行属性还需要在寻路前检查目标格子的OccupyingUnit属性判断是否被友方或敌方单位阻挡。性能优化技巧路径缓存对于AI单位如果目标点短时间内未变化可以复用上一次的计算结果。分层寻路HPA*对于超大地图先将地图抽象成由大区域Cluster构成的粗粒度网格先在大网格间寻路再在单个区域内精细寻路。Jump Point SearchJPS针对均匀网格的优化算法可以跳过大量不必要的节点评估在开放地形上能极大提升速度。Unity Asset Store上有成熟的JPS插件。3.3 范围计算与网格交互策略游戏中经常需要计算“移动范围”、“攻击范围”或“技能影响范围”。这本质上是基于网格的图搜索问题。移动范围行动力扩散通常使用广度优先搜索BFS或Dijkstra算法。从单位所在格子出发向相邻格子扩散每次扩散消耗该格子的移动成本直到累计消耗超过单位的行动力MP为止。最终所有访问过的、且可通行的格子就是可移动范围。public HashSetVector2Int CalculateMoveRange(Vector2Int startPos, int movePoints) { var reachableCells new HashSetVector2Int(); var frontier new PriorityQueueCellNode, int(); // 使用优先队列按剩余移动力排序 var costSoFar new DictionaryVector2Int, int { { startPos, 0 } }; frontier.Enqueue(new CellNode(startPos, movePoints), movePoints); while (frontier.Count 0) { var current frontier.Dequeue(); reachableCells.Add(current.Position); foreach (var neighbor in GetNeighbors(current.Position)) { var cell GetCell(neighbor); if (!cell.IsWalkable) continue; int newCost costSoFar[current.Position] cell.BaseMoveCost; if (newCost movePoints (!costSoFar.ContainsKey(neighbor) || newCost costSoFar[neighbor])) { costSoFar[neighbor] newCost; int remainingMP movePoints - newCost; frontier.Enqueue(new CellNode(neighbor, remainingMP), remainingMP); } } } return reachableCells; }攻击/技能范围这可能是一个固定形状如十字形、菱形、圆形的格子集合。可以预计算好不同半径、不同形状的“模板”在需要时直接套用到中心点上并过滤掉地图边界外的非法格子。对于圆形范围可以使用中点圆算法的网格版本来高效计算覆盖的格子。4. 网格的视觉表现与性能调优实战4.1 网格的绘制与高亮反馈在编辑器和运行时可视化网格对于调试和玩家体验都至关重要。编辑器下绘制在自定义的Editor脚本中使用Handles或Gizmos在OnDrawGizmos或OnSceneGUI方法中绘制网格线。这能让你在场景视图中清晰地看到网格划分。// 在GridSystem组件的OnDrawGizmosSelected中 private void OnDrawGizmosSelected() { Gizmos.color Color.white; for (int x 0; x gridWidth; x) { for (int y 0; y gridHeight; y) { Vector3 center GridToWorld(new Vector2Int(x, y)); Vector3 size Vector3.one * cellSize; size.y 0.01f; // 画一个扁平的线框 Gizmos.DrawWireCube(center, size); } } }运行时高亮当玩家选中单位或悬停格子时需要高亮显示可移动范围、攻击范围或路径。有两种主流做法Shader高亮为地形材质编写一个自定义Shader接收一个高亮颜色和强度参数。通过脚本将需要高亮的格子坐标数组传递给ShaderShader在片元着色器中判断当前像素属于哪个格子若在数组中则混合高亮色。这种方法性能最优但Shader编写有一定门槛。透明面片覆盖为每个需要高亮的格子动态生成一个半透明的Quad面片GameObject。这种方法实现简单但格子数量多时如大范围高亮实例化大量GameObject会造成严重的性能开销和Draw Call激增。推荐方案采用对象池Object Pooling管理高亮面片。预先创建一定数量的高亮面片预制体放入池中需要高亮时从池中取出并放置到对应格子位置取消高亮时放回池中。这避免了频繁的Instantiate和Destroy操作。对于固定地图甚至可以预先为每个格子生成一个高亮子节点并默认禁用需要时直接启用这是最直接的方法。4.2 地形表现与网格的关联地形不仅仅是贴图它的视觉表现必须与网格数据严格同步。一个常见的架构是GridSystem管理核心数据和逻辑。TerrainManager负责根据GridSystem中每个Cell的TerrainType在场景中生成或管理对应的地形视觉元素。实现方式预制体拼接为每种地形类型草地、沙漠、雪地等制作一个或多个Prefab其中包含模型、贴图和可能的地形装饰如小石头、草簇。在初始化地图时根据网格数据在对应世界坐标实例化对应的Prefab。这种方式灵活可以做出非常丰富的视觉效果。地形纹理Terrain使用Unity的Terrain系统将网格数据转换为Terrain的高度图和纹理混合图。这种方式适合连续起伏的自然地形但对于策略游戏精确的格子划分和格子级别的属性控制反而不如预制体方便。Shader Graph/材质属性块使用一张大的平面通过Shader根据世界坐标或UV坐标来查询网格数据动态改变局部区域的材质属性如颜色、纹理、法线。这需要较强的图形学功底但性能极佳适合风格化或移动端游戏。踩坑实录曾经在一个项目中我们使用了预制体拼接。当地图尺寸扩大到256x256时场景中的GameObject数量超过了6万个导致编辑器卡顿运行时帧率下降。解决方案是采用了静态合批Static Batching。我们将所有相同材质的地形预制体的模型标记为StaticUnity在构建时会自动将它们合并成更少的Draw Call。但注意静态合批后这些物体将无法移动。对于策略游戏的地形这通常是可接受的。4.3 性能瓶颈分析与优化策略网格系统在运行时的主要开销来自寻路计算、范围计算和视觉渲染。1. 寻路优化异步计算将A*寻路放到单独的线程或使用UnityWebRequest那样的协程异步操作避免阻塞主线程导致卡顿。可以使用C#的Task或Job System配合Burst编译进行多线程寻路。简化网格对于AI的长期路径规划可以使用更粗糙的网格比如把4x4的小格子合并成一个大格子进行高层规划再在局部进行精细寻路。预设路径对于固定巡逻路线或常用路径可以预先计算并存储。2. 范围计算优化缓存结果单位的移动范围在行动力未消耗、周围地形未改变时结果是相同的。可以缓存计算结果直到相关状态失效。增量更新如果只是地图上少数格子状态改变如一个可通行的桥梁被摧毁可以只重新计算受影响的单位范围而非全部重算。3. 渲染优化LOD多层次细节对于远离相机的地形块使用面数更少、贴图分辨率更低的模型。遮挡剔除Occlusion Culling在Unity中正确设置遮挡区域确保相机看不到的地形块不被渲染。GPU Instancing如果大量地形使用相同的材质和模型启用GPU Instancing可以极大减少Draw Call。确保你的地形材质球勾选了“Enable GPU Instancing”选项。5. 高级应用与常见问题排查5.1 多层地图与高度处理许多策略游戏如《英雄无敌》中的地下城与地上世界或需要地形高低差的游戏如《战争艺术》需要支持多层地图。这可以通过扩展网格的Z坐标或Y坐标取决于你的定义来实现将数据结构从Grid[x, y]变为Grid[x, y, level]。高度影响移动成本上坡和下坡可以设置不同的移动消耗。视野与攻击高地单位可能拥有更远的视野和攻击范围并能攻击低地单位而低地单位可能无法反击模拟现实中的高度优势。通行性过高的悬崖可能无法直接通行需要绕路或使用技能。在寻路和范围计算时邻居查找的逻辑需要将高度差作为一个因素考虑进去。例如从一个格子到另一个高度差为2的相邻格子可能被视为“不可直接通行”。5.2 动态改变网格属性地图不是一成不变的。技能可能烧毁森林将地形从“森林”变为“焦土”移动成本改变工程师可能建造桥梁将“水域”变为“可通行”。实现关键事件驱动当网格属性改变时触发一个事件如OnCellChanged。通知相关系统所有依赖网格状态的系统都需要监听这个事件。寻路系统需要清除或更新受影响的缓存路径。单位系统如果单位正站在发生改变的格子上可能需要重新计算其状态例如站在被烧毁的森林里受到持续伤害。表现系统需要更新该格子的视觉表现更换预制体或修改材质。批量更新如果一整个区域发生变化如陨石术砸出一个大坑应设计批量更新接口避免频繁触发单个事件导致性能问题。5.3 常见问题排查速查表问题现象可能原因排查与解决方案单位移动“卡顿”或“抖动”1. 世界坐标与网格坐标转换存在浮点数精度误差。2. 移动动画的插值Lerp时间设置不当或与逻辑更新帧不同步。1. 确保GridToWorld和WorldToGrid函数互为逆运算且使用相同的gridOrigin和cellSize。移动目标点使用GridToWorld计算出的精确中心点。2. 将单位的移动逻辑放在FixedUpdate中而将视觉插值放在Update中确保逻辑帧稳定。点击选择格子不准确1. 用于射线检测的碰撞体Collider大小或位置与视觉网格未对齐。2. 射线检测的层Layer设置错误。1. 为每个格子创建一个与cellSize匹配的碰撞体如Box Collider并将其中心点通过GridToWorld对齐。或者使用一个大的平面碰撞体通过WorldToGrid转换点击点。2. 确保射线检测只针对地形层Terrain Layer避免选中单位等其他物体。寻路速度慢大型地图卡顿1. A*算法的开放列表数据结构效率低。2. 地图过大搜索节点过多。3. 每帧进行了多次寻路。1. 将开放列表从List更换为PriorityQueue如使用SortedSet或Heap实现。2. 实现分层寻路HPA*或转向JPS算法。3. 限制每帧寻路的次数或将寻路请求加入队列异步处理。高亮范围时帧率骤降1. 为每个高亮格子都 Instantiate 了新的 GameObject。2. 高亮面片使用了复杂的材质或Shader。1. 改用对象池管理高亮面片。2. 使用最简单的无光照、顶点颜色Shader来绘制高亮面片。考虑使用Shader一次性绘制所有高亮区域通过传递位置数组。单位可以“穿墙”或走到不可通行区域1. 寻路算法中未正确判断格子的IsWalkable属性。2. 动态阻挡如其他单位未在寻路时实时更新。3. 客户端与服务端网格状态不同步网络游戏。1. 在寻路邻居查找和移动成本计算中严格检查目标格子的通行性。2. 单位移动前再次验证路径上每个格子的实时状态通行性、占据单位。3. 确保所有改变地图状态的逻辑都在服务端权威执行并同步给所有客户端。实现一套完善的策略游戏网格系统是一个从抽象逻辑到具体表现、从数据结构到算法优化、从功能实现到性能打磨的完整闭环。它没有太多炫技的成分更多的是对细节的严谨把控和对架构的清晰思考。当你看到单位在格子上流畅移动、攻击范围被精准高亮、AI凭借你写的寻路算法做出精妙绕后时那种成就感是实实在在的。这套系统将成为你策略游戏项目最稳固的基石在此之上复杂的规则、丰富的技能和深度的策略才能得以构建。
