1. 项目概述从经典到策略网格地图的通用化思考做游戏开发这些年从最基础的俄罗斯方块到复杂的战棋策略游戏我发现一个有趣的现象它们的底层世界几乎都构建在一个看似简单的“网格”之上。俄罗斯方块的旋转与消除战棋角色的移动与攻击范围本质上都是对网格坐标的精确计算与状态管理。这个发现让我开始思考能否设计一套通用的网格地图系统它足够灵活既能承载简单的方块下落逻辑又能支撑起复杂的战棋规则并且是在Unity这个强大的引擎里优雅地实现这就是今天想和大家深入聊聊的主题。网格地图或者说Tile-based地图远不止是屏幕上一个个排列整齐的小方块。它是一个强大的抽象层将连续的游戏世界离散化为游戏逻辑提供了精确的坐标系统和可预测的寻路基础。对于俄罗斯方块网格是7x的“井”字棋盘对于战棋网格可能是六边形、正方形甚至是不规则形状组成的战场。通用设计的核心挑战就在于如何用一套代码架构去适配这些截然不同的游戏类型和网格形态。这不仅仅是技术实现更是一种对游戏空间本质的理解和设计。在Unity中实现这样的系统我们既要利用好引擎提供的便利如Transform、SpriteRenderer又要避免被其面向连续空间的特性所束缚。我们需要自己构建一套基于整数坐标x, y的逻辑层让它独立于Unity的世界坐标同时又能高效、准确地进行双向映射。无论你是刚入门Unity的新手想理解游戏世界的构建基础还是有一定经验的开发者正在为你的策略游戏寻找稳健的地图解决方案这套设计思路和实现细节或许都能给你带来一些直接的启发和可以“抄作业”的代码片段。2. 网格地图的通用设计哲学与核心架构2.1 离散化一切逻辑的基石通用网格地图设计的第一个也是最重要的原则就是逻辑层的彻底离散化。这意味着在代码逻辑中我们不应该直接使用Unity的Vector3世界坐标来处理角色的位置、单位的移动或技能的释放范围。取而代之的是一个由整数索引(gridX, gridY)构成的二维或三维数组。为什么必须这么做想象一下战棋游戏。当你说“角色移动到35格”时这是一个绝对精确、无歧义的指令。如果使用浮点坐标你可能会遇到“大概在3.1 4.9的位置”这会导致边界判断模糊、寻路算法复杂化以及状态同步的噩梦。离散的网格坐标让“占领格子”、“计算移动力消耗”、“判断攻击范围”这些核心玩法变得像做算术题一样清晰。逻辑坐标与渲染坐标的分离是随之而来的关键设计。逻辑层只关心(gridX, gridY)和该格子的状态是否可通行、地形类型、是否有单位等。渲染层则负责将这个逻辑坐标通过一个固定的换算公式如worldPos new Vector3(gridX * cellSize, gridY * cellSize, 0)转换为Unity世界中的实际位置并实例化对应的Tile预制体或模型。这种分离使得我们可以在不改变游戏逻辑的情况下随意调整网格的视觉表现比如把正方形贴图换成六边形甚至3D模型。2.2 数据驱动定义网格的“灵魂”一个格子不只是一个位置它承载了游戏所需的所有静态和动态信息。一个健壮的数据驱动设计是通用的保证。我们需要定义一个TileData基类或结构体包含以下核心字段[System.Serializable] public class TileData { public int x; // 逻辑坐标X public int y; // 逻辑坐标Y public bool isWalkable; // 是否可通行 public float movementCost; // 移动力消耗例如平原为1森林为2山地为3 public TerrainType terrainType; // 地形类型枚举 // ... 其他游戏特定属性如防御加成、资源类型等 }更进一步我们需要一个GridMap管理类来持有整个地图的数据。它通常是一个二维数组TileData[,] mapData。这个类的职责包括地图初始化与加载从配置文件如JSON、ScriptableObject、编辑器或程序化生成中创建mapData。坐标有效性验证提供IsCellValid(int x, int y)方法防止数组越界。邻居查找提供GetNeighbors(TileData cell)方法。这里是体现通用性的关键对于正方形网格邻居通常是四方向或八方向对于六边形网格邻居是六个方向。这个方法应该可配置或通过策略模式来切换。路径查找接口暴露一个方法给游戏逻辑单元如角色基于movementCost和isWalkable进行寻路常用A*算法。注意切忌在TileData里直接保存对场景中GameObject的引用如GameObject tileView。这会导致场景加载/卸载时的引用丢失问题。正确的做法是使用一个独立的GridRenderer或TileViewManager来管理逻辑坐标与视觉对象的映射关系。2.3 网格类型的抽象方形与六边形的统一接口俄罗斯方块使用正方形网格而许多经典战棋如《英雄无敌》、《文明》系列使用六边形网格因为它能提供更自然的移动和更均衡的邻接关系。我们的通用系统需要能兼容两者。我们可以定义一个IGridLayout接口public interface IGridLayout { Vector3 CellToWorld(int x, int y, float cellSize); // 逻辑坐标转世界坐标 (int x, int y) WorldToCell(Vector3 worldPos, float cellSize); // 世界坐标转逻辑坐标 List(int dx, int dy) GetNeighborOffsets(); // 获取邻居坐标偏移量 float GetDistance(int x1, int y1, int x2, int y2); // 计算两格间的“距离” }然后分别实现SquareGridLayout和HexGridLayout。在HexGridLayout中CellToWorld的转换会稍微复杂一些需要考虑六边形交错排列的偏移奇数行或偶数列向右平移半个单位宽度。GetNeighborOffsets对于六边形会返回六个方向的偏移量。GetDistance在六边形网格中通常使用立方体坐标下的曼哈顿距离的一半来计算。通过依赖注入或配置我们的GridMap在初始化时使用特定的IGridLayout实现。这样上层的游戏逻辑如寻路、范围计算就可以完全不用关心底层是方格子还是六边形格子它只需要调用gridMap.GetNeighbors(tile)剩下的由布局实现类搞定。这是实现“通用性”的核心技巧。3. 在Unity中的核心模块实现3.1 地图生成与管理器的构建有了设计哲学我们开始在Unity中搭建骨架。首先创建一个GridManager单例或通过依赖注入访问的全局管理器。它是整个网格系统的中枢。public class GridManager : MonoBehaviour { public static GridManager Instance { get; private set; } [Header(布局配置)] public GridLayoutType layoutType; // 枚举正方形、六边形 public float cellSize 1f; // 每个逻辑格子的世界单位大小 [Header(地图数据)] public int gridWidth 10; public int gridHeight 10; public TileData[,] GridData { get; private set; } // 核心逻辑数据 private IGridLayout _gridLayout; private void Awake() { if (Instance ! null Instance ! this) Destroy(this); else Instance this; InitializeGridLayout(); GenerateGridData(); // 可以在这里触发渲染系统生成视觉表现 } private void InitializeGridLayout() { switch (layoutType) { case GridLayoutType.Square: _gridLayout new SquareGridLayout(); break; case GridLayoutType.Hexagon: _gridLayout new HexGridLayout(); break; default: throw new ArgumentOutOfRangeException(); } } private void GenerateGridData() { GridData new TileData[gridWidth, gridHeight]; for (int x 0; x gridWidth; x) { for (int y 0; y gridHeight; y) { GridData[x, y] new TileData { x x, y y, isWalkable true, // 默认可行走可通过其他方式配置 movementCost 1.0f, terrainType TerrainType.Plain }; } } // 示例设置一些障碍物 GridData[3, 3].isWalkable false; GridData[3, 3].terrainType TerrainType.Mountain; } // 提供给其他系统的关键API public Vector3 GridToWorldPosition(int gridX, int gridY) { return _gridLayout.CellToWorld(gridX, gridY, cellSize); } public (int gridX, int gridY) WorldToGridPosition(Vector3 worldPos) { return _gridLayout.WorldToCell(worldPos, cellSize); } public TileData GetTileAt(int x, int y) { if (IsWithinBounds(x, y)) return GridData[x, y]; return null; } public bool IsWithinBounds(int x, int y) { return x 0 x gridWidth y 0 y gridHeight; } }3.2 寻路系统A*算法的通用化集成战棋游戏的核心玩法之一是移动这就需要寻路。A算法是网格寻路的黄金标准。我们需要实现一个与网格布局无关的A算法。关键在于将网格的抽象通过接口传递给A*。我们创建一个Pathfinding类它不关心具体是方形还是六边形只依赖IGridLayout和GridData来获取邻居和移动成本。public class Pathfinding { public ListTileData FindPath(TileData start, TileData goal, GridManager gridManager) { // 验证起点终点是否可行走 if (!start.isWalkable || !goal.isWalkable) return null; var openSet new HeapTileData(gridManager.GridWidth * gridManager.GridHeight); var closedSet new HashSetTileData(); openSet.Add(start); while (openSet.Count 0) { TileData currentTile openSet.RemoveFirst(); closedSet.Add(currentTile); if (currentTile goal) { return RetracePath(start, goal); } // 关键点通过GridManager获取邻居而GridManager内部使用当前配置的IGridLayout foreach (TileData neighbor in gridManager.GetNeighbors(currentTile)) { if (!neighbor.isWalkable || closedSet.Contains(neighbor)) continue; float newMovementCostToNeighbor currentTile.gCost GetDistance(currentTile, neighbor) * neighbor.movementCost; if (newMovementCostToNeighbor neighbor.gCost || !openSet.Contains(neighbor)) { neighbor.gCost newMovementCostToNeighbor; neighbor.hCost GetDistance(neighbor, goal); neighbor.parent currentTile; if (!openSet.Contains(neighbor)) openSet.Add(neighbor); else openSet.UpdateItem(neighbor); } } } return null; // 未找到路径 } private float GetDistance(TileData a, TileData b) { // 使用当前GridManager的布局来计算距离 return GridManager.Instance.GetLayout().GetDistance(a.x, a.y, b.x, b.y); } private ListTileData RetracePath(TileData start, TileData end) { // ... 回溯父节点构建路径列表 } }实操心得A*算法中的GetDistance启发函数hCost对性能影响很大。对于正方形网格使用对角线距离Chebyshev距离或欧几里得距离通常效果不错。对于六边形网格需要使用基于立方体坐标的曼哈顿距离。确保你的IGridLayout.GetDistance方法实现了正确的距离计算否则寻路结果会很奇怪。3.3 可视化编辑器拓展与运行时调试一套好的系统必须有便捷的可视化工具。我们可以在Unity编辑器中拓展GridManager使其在Scene视图绘制网格Gizmos。#if UNITY_EDITOR private void OnDrawGizmosSelected() { if (!Application.isPlaying GridData null) return; Gizmos.color Color.white; for (int x 0; x gridWidth; x) { for (int y 0; y gridHeight; y) { Vector3 center GridToWorldPosition(x, y); // 根据layoutType绘制不同的Gizmos形状 if (layoutType GridLayoutType.Square) { DrawSquareGizmo(center, cellSize); } else if (layoutType GridLayoutType.Hexagon) { DrawHexGizmo(center, cellSize); } // 用颜色表示格子状态 TileData tile GetTileAt(x, y); if (tile ! null !tile.isWalkable) { Gizmos.color Color.red; Gizmos.DrawCube(center, Vector3.one * cellSize * 0.2f); Gizmos.color Color.white; } } } } private void DrawSquareGizmo(Vector3 center, float size){ /* 绘制正方形 */ } private void DrawHexGizmo(Vector3 center, float size){ /* 绘制六边形 */ } #endif此外创建一个简单的TileView组件挂载在表示每个格子的GameObject上。它负责从GridManager获取对应的TileData并根据数据状态更新自身表现如材质颜色、Sprite。public class TileView : MonoBehaviour { public int gridX; public int gridY; private SpriteRenderer _spriteRenderer; void Start() { _spriteRenderer GetComponentSpriteRenderer(); UpdateVisual(); } public void UpdateVisual() { TileData data GridManager.Instance.GetTileAt(gridX, gridY); if (data ! null) { // 根据地形类型切换颜色或Sprite _spriteRenderer.color GetColorForTerrain(data.terrainType); // 高亮显示等逻辑 } } }4. 从俄罗斯方块到战棋两种游戏类型的适配实践4.1 俄罗斯方块的快速适配状态与消除对于俄罗斯方块我们不需要复杂的移动成本或寻路。我们需要的是一个状态网格。每个格子只有两种状态空或被占据。TileData可以简化为public class TetrisTileData : TileData { public bool isFilled; // 是否被方块占据 public Color blockColor; // 方块颜色如果需要 }游戏逻辑变得非常直接下落判断当前活动方块由4个格子组成试图向下移动一格。检查其目标位置对应的所有TetrisTileData如果isFilled为true或超出下边界则锁定。锁定与填充方块锁定后将其四个格子的位置在GridData中标记为isFilled true。行消除检查遍历每一行检查该行所有格子的isFilled。如果全部为true则将该行清除所有isFilled置为false并将上方所有行的数据下移一行。渲染同步每当GridData发生变化通知所有TileView更新自己的显示显示为彩色方块或空白。在这个案例中我们复用了通用的GridManager、坐标转换和邻居系统用于方块旋转时的碰撞检测但极大地简化了TileData和游戏规则逻辑。这证明了我们通用架构的灵活性。4.2 战棋游戏的深度应用移动、范围与技能战棋游戏是网格系统的终极试炼场。我们需要在上面构建复杂的游戏逻辑。1. 移动系统移动力Action Points每个单位有固定的移动力AP。TileData.movementCost表示通过该格子消耗的AP。可移动范围高亮使用广度优先搜索BFS或Dijkstra算法从单位所在格子出发遍历所有可达格子累计消耗AP ≤ 单位剩余AP并将这些格子的TileView高亮。路径预览与移动玩家点击一个高亮格子后使用A*算法计算出消耗AP最少的路径并让单位沿路径格子逐格移动。2. 攻击与技能范围这通常基于网格距离。例如“攻击范围3”意味着所有与施法者格子距离≤3的格子。这里就用到了IGridLayout.GetDistance方法。无论是方形还是六边形距离都能正确计算。范围形状可能多样菱形、十字形、圆形近似。我们可以预先定义好这些形状的坐标偏移模板Pattern然后在网格上应用。public ListTileData GetTilesInRange(TileData center, int range, RangeType rangeType) { ListTileData result new ListTileData(); for (int dx -range; dx range; dx) { for (int dy -range; dy range; dy) { int x center.x dx; int y center.y dy; TileData tile GridManager.Instance.GetTileAt(x, y); if (tile ! null) { int dist GridManager.Instance.GetLayout().GetDistance(center.x, center.y, x, y); // 根据rangeType圆形、菱形等判断dist是否符合条件 if (dist range) result.Add(tile); } } } return result; }3. 地形效果通过TileData.terrainType来驱动。在战斗计算时检查防御方所在格子的地形提供防御力加成如森林20%防御。某些地形可能禁止通行isWalkable false或仅允许特定单位通过如飞行单位无视山地。踩坑记录在实现战棋的“移动范围高亮”时最初我直接用了A遍历所有格子来计算消耗在大型地图上性能堪忧。后来改为使用带消耗的BFS并利用TileData的movementCost作为边的权重性能提升了一个数量级。记住A用于找两点间最优路径BFS/Dijkstra用于找单点到所有可达点的最短消耗。5. 性能优化与高级技巧5.1 数据存储与访问优化当网格变大如100x100频繁的GridData[x, y]访问和对象创建会成为瓶颈。使用扁平数组或内存连续结构TileData[,]在C#中访问效率尚可但可以考虑使用一维数组TileData[]通过index y * width x来访问有时对CPU缓存更友好。结构体struct替代类class如果TileData较小且主要是数值类型将其定义为struct可以避免堆内存分配和垃圾回收GC压力。但要注意struct是值类型传递和修改时需要小心使用ref。分块加载Chunking对于超大型地图如开放世界不要一次性加载所有网格数据。可以将地图划分为多个“块”Chunk只加载和激活玩家附近的块。这需要更复杂的坐标管理和块边界处理。5.2 高效的空间查询与索引“获取某单位周围3格内所有敌人”这类查询非常频繁。暴力遍历所有单位并计算距离是O(N)的效率低下。网格空间分区Grid-based Spatial Partitioning这是最自然契合我们系统的优化方法。我们维护一个字典Dictionary(int gridX, int gridY), ListUnit unitsInCell。每个单位根据其所在的网格坐标注册到对应的格子列表中。当需要查询某格子周围单位时只需获取周围几个格子的单位列表并合并即可复杂度降至O(1)或O(9)对于3x3范围。四叉树/八叉树对于非均匀分布或需要更精细范围查询的场景可以使用这些空间数据结构。但在均匀的网格地图中网格分区通常更简单高效。5.3 网络同步考虑针对多人战棋如果要做多人联机战棋网格系统带来了便利也带来了挑战。确定性基于离散网格和整数坐标的游戏逻辑天生具有确定性。所有客户端对同一输入如“单位A移动到(5,7)”应计算出完全相同的结果。这为锁步Lockstep同步模型提供了完美基础。状态同步只需要同步网格数据的变化哪个格子的状态改变了而不是每个单位的连续位置。数据量小同步效率高。例如同步一次攻击可以压缩为{attackerCell: (x1,y1), targetCell: (x2,y2), skillId: 3}这样的小数据包。预测与回滚客户端可以根据输入预测本地网格状态的变化如果服务器校验后不一致则进行状态回滚。由于网格状态是离散的回滚操作恢复某个格子的isWalkable或单位归属比连续物理引擎的回滚要简单得多。6. 常见问题与排查技巧实录在实际开发中你一定会遇到下面这些问题。这里是我总结的“避坑指南”。6.1 坐标转换的精度陷阱问题单位移动后用WorldToGridPosition转换回逻辑坐标偶尔会得到错误的相邻格子坐标。原因浮点数精度问题。Unity世界坐标是float转换计算如除法、取整可能产生极小的误差如4.999999f。当你使用Mathf.RoundToInt或Mathf.FloorToInt时这个误差可能导致取整到错误的整数。解决public (int x, int y) WorldToCell(Vector3 worldPos, float cellSize) { // 在取整前加上一个极小的偏移量消除负值取整的歧义 float epsilon 0.0001f; int x Mathf.FloorToInt((worldPos.x / cellSize) epsilon); int y Mathf.FloorToInt((worldPos.y / cellSize) epsilon); // 对于六边形网格计算更复杂但原理相同在取整前处理精度 return (x, y); }同时确保单位的Transform位置在移动后被显式地设置到由GridToWorldPosition计算出的精确位置而不是一个近似的向量。6.2 寻路算法卡死或路径怪异问题A*算法有时找不到明明存在的路径或者找出的路径非常奇怪绕远路。排查清单检查移动成本确认所有格子的movementCost都是正数0。如果存在0或负数会导致算法优先级计算错误。检查启发函数Heuristic确保GetDistance函数返回的值永远不会超过实际成本。对于六边形网格使用曼哈顿距离的变体确保其是可接受的Admissible。验证邻居获取在GetNeighbors函数中打印日志确认对于边界格子返回的邻居列表是正确的没有包含无效坐标。封闭集合Closed Set比对确保用于比较TileData是否在closedSet中的是**引用相等Reference Equality**或基于唯一ID的比较而不是值比较。否则内容相同的不同TileData对象会被错误地认为是同一个。6.3 编辑器下正常运行时地图错乱问题在Scene视图里Gizmos画得好好的运行游戏后Tile的视觉位置全部错位。原因这通常是渲染层与逻辑层初始化顺序问题。TileView在Start()中根据gridX, gridY去GridManager.Instance获取数据并定位自己。但如果GridManager的Awake()初始化数据晚于TileView的Start()执行那么TileView获取到的就是空数据或旧数据。解决将TileView的初始化逻辑放在Start()中并确保GridManager的初始化在Awake()中完成Unity默认的Awake顺序在所有Start之前但同一帧内顺序不确定。更稳健的方法是使用事件驱动。GridManager在完成初始化后发布一个OnGridInitialized事件。所有TileView订阅此事件在事件触发后才执行自己的初始化定位。或者在TileView的Start()中如果发现GridManager.Instance未就绪或数据为空则启动一个协程等待下一帧再尝试初始化。6.4 内存泄漏与性能热点问题随着游戏进行内存缓慢增长或在频繁寻路时帧率下降。排查与优化对象池管理TileView频繁创建和销毁成千上万的Tile GameObject是性能杀手。务必使用对象池来管理TileView的实例。避免在Update中做复杂网格查询例如每帧为所有单位计算移动范围。应将这类计算放在事件触发时如单位被选中时并使用缓存机制直到相关格子状态发生变化时才重新计算。使用性能分析器使用Unity Profiler重点关注CPU Usage查找GetNeighbors、FindPath、GetDistance等函数的耗时。GC Alloc检查每帧是否有意外的TileData、ListTileData等对象的分配。尽量复用集合对象使用List.Clear()而非new List()。Heap Memory监控TileData数组和TileView对象池的内存占用是否异常增长。这套从俄罗斯方块到战棋游戏的网格地图通用设计与实现其价值在于它提供了一种清晰、解耦的思维方式。它将游戏世界中最基础的空间表达抽象出来让你能专注于上层游戏玩法的创新而不是反复解决坐标转换、寻路碰撞这些底层问题。当你下次开始一个新项目不妨先问问自己我的游戏世界可以用网格来描述吗如果可以那么从这套架构开始或许能让你走得更稳、更快。
