做塔防游戏这么久我一直有一个观点地图才是整个项目的骨架。Cocos2dx 塔防游戏开发里敌人AI、炮塔攻击、技能特效、音效演出全都是围绕地图上的那条路来展开的。最近我用 C 配合 Cocos2dx-3.X 重写了一个《王国保卫战》风格的塔防Demo正好把地图这部分踩过坑、走过的弯路、最后沉淀下来的实现方案整理成文。这篇是系列第一篇主要讲 地图数据建模、瓦片渲染、路径点与寻路的关系后续再单独写敌人系统、炮塔攻击和技能表现。不管你是刚接触 Cocos2dx 不久、想拿塔防练手的新手还是想参考一套完整地图数据结构的在职开发这篇文章给出的方案都尽量做到“能直接抄作业”。我不会只贴一段代码就完事而是会把每一步为什么要这么做、不这么做会踩什么坑一起讲清楚这样你改造成自己的塔防玩法时至少不会在最底层的数据结构上返工。1. 塔防地图的整体设计思路1.1 从《王国保卫战》看塔防地图的组成《王国保卫战》这类塔防地图玩起来很直观怪物沿着固定路线从出口走到终点玩家在路边指定的格子建塔阻挡和消灭怪物。但落到代码层面地图至少包含三套信息地形表现、战斗逻辑数据、路径引导数据。地形表现决定玩家眼睛里看到的路面、草地、石头、河流是什么样。这部分属于渲染层我们可以用图片拼、用瓦片地图甚至直接用纯色块先跑通逻辑。战斗逻辑数据决定哪些格子能建塔、哪些格子怪物不能走、哪些格子是装饰。这部分是纯数据用二维数组或者更结构化的方式存起来。路径引导数据决定怪物从出生点到终点按什么顺序走。塔防地图如果固定路线路径就是一批有序的坐标点如果允许改路线那块地图还需要接寻路算法。我在项目里一开始犯过的错误是把这三样东西混在一起处理直接用 Sprite 摆位置怪物往 Sprite 的位置走塔位写在另外一张表里。结果就是地图稍微调一格怪物路径和塔位全乱套。后来我彻底重构把“地图表现”和“地图数据”拆开数据归数据渲染归渲染调起来才顺手。1.2 我为什么先选栅格地图结构栅格地图听起来高端其实就是一个棋盘格。把一整张地图按照固定格子大小切分比如 64x64 像素一格整张地图就变成了 N 行 M 列的逻辑网格。每个格子用一个枚举值表示它的类型可走、不可走、塔位、障碍物。选择栅格结构有几个实际好处。塔防天然适合格子化因为怪物按格子走、塔按格子建冲突检测友好后续不管是做范围攻击还是做减速区域都能直接以格子为最小单位计算。第二个好处是数据组织简单一个std::vectorstd::vectorint就能表达完整的地图逻辑想改关卡、调路径改数组里的值就行不用动渲染代码。第三个好处是方便做寻路A* 算子在栅格上实现起来最直观每个格子就是节点上下左右还有对角线移动成本都能建模。注意格子大小直接决定游戏手感。我用过 32、48、64、96 四种规格最终在移动端选择了 64。格子太小地图信息密度高但点击塔位容易点错格子太大又显得地图空旷路径可玩性下降。建议先用 64 做原型再结合你的美术资源和屏幕适配去调。2. 地图数据建模与编辑2.1 用一个二维数组表达整张地图先看最基础的部分。我心里一张完整的塔防地图数据大概长这样import random import time # 游戏地图 5行9列 row 5 col 9 map_data [ [0, 0, 0, 2, 0, 0, 0, 0, 0], [0, 1, 0, 2, 1, 0, 1, 1, 0], [0, 1, 0, 2, 0, 0, 0, 1, 0], [0, 1, 0, 2, 1, 1, 0, 1, 0], [0, 1, 0, 2, 2, 2, 2, 1, 0], ]这段代码只是我用 Python 快速验证地图数据用的方便在控制台print出来看。真正在 C 工程里我一般不直接手写数组因为地图行列多的时候眼睛会看瞎。我的做法是用一个文本文件或者 JSON 文件存地图数据游戏启动时加载进来解析成一个二维容器。每个数字的含义可以自己定义我的建议是一开始就留出扩展空间数值含义说明0可通行草地区域玩家不能建塔怪物不走1障碍物/水域完全不可通2路径怪物默认行走的格子3塔位玩家可以在这格建塔怪物不走这里有个容易忽略的点路径“2”和塔位“3”的格子逻辑上要分开判断。怪物寻路时只能走“2”建塔时只能选“3”但如果让塔位放到了路径旁边塔的攻击覆盖范围计算又要参考路径格子。所以做塔位数据时我通常单独再存一份std::vectorVec2塔位坐标数组而不是每次遍历二维数组去查性能更好代码也更清晰。2.2 坐标转换格子坐标、像素坐标、屏幕坐标地图数据建好了接下来是坐标转换。你在数组里写map[2][3] 2这只是逻辑上的“第 2 行第 3 列”。要把这段数据画到屏幕上需要换算成像素坐标。假设每格TILE_SIZE 64那么// 格子坐标 - 像素坐标 Vec2 gridToPixel(int col, int row) { return Vec2(col * TILE_SIZE, row * TILE_SIZE); } // 像素坐标 - 格子坐标 Vec2 pixelToGrid(const Vec2 pos) { int col (int)(pos.x / TILE_SIZE); int row (int)(pos.y / TILE_SIZE); return Vec2(col, row); }在 Cocos2dx-3.X 里地图容器节点一般加在原点左下角Tile 最小一格从(0, 0)开始。这里需要注意实际问题Cocos2dx 的坐标系是左下角为原点y 轴向上所以数组的“第 0 行”如果画在地图底部数组索引与像素row的正方向是反的。我的习惯是让数组的第 0 行对应屏幕最上面一行这样写地图逻辑时更像从上往下看但渲染循环里要用map_height - 1 - row去算像素坐标避免上下颠倒反过来。屏幕坐标又涉及 UI 适配。在手机上visibleSize不等于设计分辨率我建议地图节点统一放在一个Node容器下通过设置容器位置来做屏幕居中或适配不要在每块瓦片位置上硬写屏幕偏移量。2.3 路径点数据决定怪物怎么走地图数据只是静态地形怪物要沿路径移动还需要“路线点”。最简单也最可控的方案在地图设计阶段就定好从出生点到终点依次经过的格子中心点存成一个数组std::vectorVec2 waypoints { Vec2(3, 0), // 出生点 Vec2(3, 1), Vec2(3, 2), Vec2(3, 3), Vec2(3, 4), Vec2(4, 4), Vec2(5, 4), Vec2(6, 4), Vec2(7, 4), Vec2(8, 4), // 终点 };怪物移动时就按顺序朝下一个路径点的像素坐标位置移动到了之后切换到下一个点。判断“是否到达”不要用因为每次帧移动的步长不一定能被 64 整除大概率会越过目标点。正确做法是判断距离bool arrived (currentPos - targetPos).length() moveSpeed * dt 0.5f;如果已经到达直接把坐标吸附到路径点上避免累积误差越走越偏。有些开发者会问既然已经有二维数组里的“2”标记路径为什么还要额外存路径点数组因为数组里只有“哪些格子是路径”没有“怪物先走哪个、再走哪个”的顺序。路径可能分岔、可能绕圈只有路径点数组能表达方向信息。这也有利于后续做怪物旋转朝向用当前路径点和下一个路径点的方向设置怪物角度即可。3. 地图渲染用代码和资源把数据变成画面3.1 瓦片拼接渲染和 TMX 地图怎么选地图数据准备好后渲染层有两个主流路线。路线一直接 Sprite 拼接在地图初始化时遍历二维数组每一种格子类型对应一张图片创建 Sprite 并放到格子的像素坐标上。优点是不依赖外部工具代码一目了然缺点是地图大、瓦片种类多的时候Sprite 数量会很多Draw Call 飙升。路线二TMX 瓦片地图Tiled Map Editor先在 Tiled Map Editor 软件里画好地图导出.tmx文件然后用TMXTiledMap::create(map.tmx)加载。优点是可以直接在编辑器里刷地形、放物体、加碰撞区域美术资源管理方便适合正式项目缺点是多一层工具链而且 TMX 数据跟二维数组的逻辑数据还需要同步维护不同步就会出现“画面看起来是路代码里却不是路径”的bug。我的结论是如果只是学习 Demo 或者地图规模小直接用 Sprite 拼接做原型跑通逻辑后再决定要不要换 TMX。我在《王国保卫战》这个项目的初版里就是用 5x9 的格子手动拼接来验证玩法等整个塔防框架稳定了才把地图美术切到 Tiled 导出。这个顺序能让你更快聚焦游戏逻辑而不是一开始被工具搞晕。3.2 手动拼接地图的代码骨架手动拼接的核心思路很简单一张地图一个容器 Node往里面 AddChild 若干个 Sprite。// MapRenderer.cpp 核心逻辑 void MapRenderer::buildMap() { auto mapNode Node::create(); this-addChild(mapNode); for (int row 0; row ROW_COUNT; row) { for (int col 0; col COL_COUNT; col) { int tileType mapData[row][col]; std::string frameName getFrameNameByTileType(tileType); auto sprite Sprite::createWithSpriteFrameName(frameName); // 注意锚点设成左下角方便用格子坐标定位 sprite-setAnchorPoint(Vec2(0, 0)); int pixelRow ROW_COUNT - 1 - row; // 处理坐标系翻转 sprite-setPosition(Vec2(col * TILE_SIZE, pixelRow * TILE_SIZE)); mapNode-addChild(sprite); } } }这里有两个容易出问题的点。锚点设置Sprite 默认锚点是(0.5, 0.5)也就是说setPosition设置的是精灵中心点的位置。如果直接用格子像素坐标去定位会导致每块瓦片向右下偏移半格。我把锚点改成(0, 0)setPosition传格子的左下角坐标逻辑更顺。坐标系翻转前面提到的 row 方向问题渲染时要根据你的数组语义来定。如果你数组第 0 行想表示地图下方那就直接row * TILE_SIZE如果第 0 行表示地图上方就需要(ROW_COUNT - 1 - row) * TILE_SIZE。做地图编辑器时我自己习惯第 0 行在下方这样和数学上的 y 轴方向一致减少混淆。3.3 渲染性能优化和纹理优化塔防地图通常帧率压力不大但地图大或者后期加特效时还是要做一些基本优化。第一是Sprite 数量控制。5x9 的格子小地图无所谓但如果是 20x30 甚至更大的地图600 个 Sprite 同时渲染移动端低端机会吃力。优化思路是把静态地图烘焙成一张 RenderTexture地图初始化完成后一次性把它画到一张纹理上之后整个地图只需渲染一次。这样 Draw Call 从 600 降到 1。缺点是无法单独控制某块瓦片的显隐但塔防地图的静态地形本来就不需要动。第二是图集打包。瓦片图片不要一张一张单独加载用 TexturePacker 之类工具把瓦片合成一张图集再用 SpriteFrame 来创建精灵能显著降低纹理切换开销和内存占用。第三是分块加载。如果地图特别大把地图切成多个区块屏幕外的区块可以裁剪掉只渲染visibleSize范围内的瓦片。Cocos2dx 的Culling机制也能帮一部分忙但手动算可见范围更可控。实测下来小地图原型阶段手动拼接完全够用。我见过不少新手一上来就折腾 TMX、图集、分块加载结果逻辑还没跑通光渲染就调了两周。正确节奏是先用最简单的方式把玩法验证了再逐层加性能优化。4. 路径寻路与地图数据联动4.1 固定路径 vs 动态寻路塔防游戏的寻路有两种典型形态。第一种是路径完全固定。出生点、路径点、终点在设计地图时就写死了怪物只需要跟路径点数组走。这类实现简单、性能高、逻辑可控也是《王国保卫战》的原版做法。你用前面说的 waypoints 数组就能搞定。第二种是玩家可以改变地图状态比如造墙、堵路、建塔改变地形这时候地形变化会影响路径怪物需要实时重新寻路。这时候就要引入 A* 寻路算法而且需要在每次地图数据变化后对怪物重新计算路径。做原型版本时我建议先走固定路径。理由很现实塔防的玩法重心在塔的布置和怪物的波次节奏如果一开始就搞动态寻路排查 bug 的复杂度会翻倍。等基础架构稳了再扩展动态寻路也不迟。4.2 A* 寻路在栅格地图上的应用思路如果你决定做动态寻路A* 是塔防里最常见的选择。算法的核心思路是维护一个开放列表和一个关闭列表每次从开放列表里取f g h最小的节点扩展直到找到终点。g表示从起点到当前节点的实际代价h表示当前节点到终点的预估代价也就是启发式函数。在栅格地图上节点就是格子。相邻格子间默认代价为 1斜向移动为 1.414或者禁掉斜向只允许上下左右。struct GridNode { int row, col; int g, h; int parentRow, parentCol; int f() const { return g h; } }; // 启发式曼哈顿距离 int heuristic(int curRow, int curCol, int endRow, int endCol) { return abs(curRow - endRow) abs(curCol - endCol); }A* 的重要细节有两个。一是启发式函数的选择。如果只允许上下左右移动用曼哈顿距离如果允许斜向移动用欧氏距离或八方向对角线距离。选错会导致路径不够平滑或者搜索效率变低。二是路径平滑。A* 在栅格上找出来的路径经常是折线出现很多拐角。塔防里怪物走到拐角突然转向视觉上比较僵硬。处理方法是对路径做简化如果两个路径点之间没有阻挡直接删掉中间的点让怪物走直线更高级的可以用一些路径平滑算法进一步优化但对塔防来说去掉冗余拐点就足够了。4.3 塔位与路径的碰撞检测细节地图逻辑里塔位和路径是互斥的但实际渲染时塔的“占地面积”可能超过一格。比如一个箭塔的攻击塔身美术图是 96x96而塔位格子是 64x64。这时候就会出现塔的图片把旁边的路径覆盖掉视觉上出现“怪物踩着塔走”的尴尬。我的处理方案是把塔分成“逻辑底座”和“视觉模型”两层。逻辑底座严格等于塔位格子大小用于碰撞检测、范围计算视觉模型是美术展示可以比格子大但放在底座之上渲染层级也更高。怪物走在路径上时碰撞检测只认逻辑底座所以就算美术图片看起来重叠了逻辑上依然各走各的。这个细节想在前面后面接塔的攻击范围指示器、拖拽放置、怪物围堵边界时都会省事很多。5. 地图调试与常见问题速查5.1 坐标对不上锚点、原点方向、除法取整新手遇到最多的问题就是“我明明把塔放到了格子 34但显示出来偏了一块”。这类问题几乎都出在坐标换算的三处锚点、原点方向、除法取整。锚点问题前面已经提过Sprite默认锚点是中心改成(0, 0)才能和格子左下角对齐。原点方向问题Cocos2dx 的 y 轴向上如果你数组里“第 0 行”表示地图最上方别忘了渲染时做一次(ROW_COUNT - 1 - row)翻转。除法取整问题像素坐标转格子坐标时用int强转会丢掉小数部分这本身没问题但如果你像素坐标是负数或者地图原点不是从(0, 0)开始那么pos.x / TILE_SIZE会得到不对的结果。稳妥做法是先减去地图节点原点偏移再做除法。5.2 瓦片重叠导致的闪烁和最上面一层的问题多个瓦片渲染在同一 Z 序上在部分设备上会出现边缘闪烁Z-fighting。塔防地图虽然是平面的但我还是建议给不同地形类型设置不同的setLocalZOrder比如路径格子的 Z 序比草地高障碍物再比路径高。这样能保证视觉层级稳定后续放塔、放敌人也更可控。有时候地图绘制出来总有一层叠在别的上面排查顺序是先检查 ZOrder 设置再检查 Sprite 的锚点和位置最后确认加载的图片是否本身带有透明边框。5.3 TMX 地图加载失败的常见原因如果你选择了 TMX 方案加载失败通常集中在四个方面TMX 文件路径不对TMX 引用的图集路径是相对路径Cocos2dx 在某些平台上对相对路径解析有区别图集图片格式不是引擎支持的类型TMX 的像素尺寸和代码里预设的格子尺寸不一致。我的建议是TMX 地图的瓦片尺寸和代码逻辑的地图格子尺寸必须解耦。TMX 管表现你可以用 128x128 的瓦片做出精致画面但逻辑地图里的格子尺寸依然用 64x64。转换时专门写一个适配函数千万不要在逻辑层直接依赖 TMX 的瓦片数据。5.4 大地图的帧率和内存问题地图大了之后最直接的影响是内存和帧率。内存压力主要来自纹理资源尤其是大尺寸背景图或大量瓦片图集。帧率问题则多来自渲染批次过多以及每帧都在遍历地图数组做逻辑判断。我解决内存问题的方法是全部走图集禁止单张瓦片独立纹理。解决帧率问题的方法是前面说的烘焙 RenderTexture或者至少做可视区域裁剪。另一个细节是不要每帧去遍历整张地图做碰撞检测路径点的判断只在怪物移动时用局部数据计算地图静态数据只在需要时读取。6. 一点个人经验和后续计划地图这个模块做完之后后面的敌人系统、塔攻击系统、技能范围系统我才真正感觉到顺畅。因为地图数据结构稳定了怪物的坐标、塔的位置、攻击范围的计算全都有据可依。甚至后续加英雄单位、加飞行怪、加传送门都只需要在栅格数据上增加新的字段和标记不需要推倒重来。我个人体会最深的一点是先定数据结构再写渲染再考虑寻路。这个顺序不能乱。很多人拿到一个塔防地图的需求第一反应是先找好看的瓦片素材然后开始摆。但一旦数据模型没有提前规划好后面所有系统都会受到影响。我做这个《王国保卫战》系列的时候地图数据文件改过三版但渲染逻辑没有大改就是因为数据结构从第一版开始就比较接近最终形态给后续迭代留了余地。最后再分享一个小技巧写地图系统时一定做一个“地图调试可视化开关”。打开之后可以在游戏画面上直接把每个格子的类型用不同颜色半透明块显示出来路径、塔位、障碍物一眼就能看清。调试寻路时尤其好用不用对着数组猜。这个开关我只花了半小时写但后面排查问题省了至少一天时间。系列下一期我会接着讲敌人的移动状态机和波次生成到时候地图的路径点和遮罩动画就会派上大用场。