1. 项目概述从“物理幻想”到“数据驱动”的轨迹移动在CocosCreator 3.x里做游戏尤其是带点解谜或策略性质的让物体沿着预设的轨迹移动是个挺常见的需求。比如推箱子、轨道小车、或者像《贪吃的方块》这种方块只能在特定的“轨道”格子上滑动。新手包括曾经的我很容易一头扎进物理引擎的怀抱觉得用碰撞体和刚体来限制移动范围既直观又“高级”。但现实往往很骨感物理引擎在处理这种精确的、格子化的、规则性极强的移动逻辑时可能会带来一堆意想不到的坑性能开销、穿透Bug、移动不精确还有那令人头疼的“卡顿”感。我最近就重构了一个类似的项目核心目标就是让物体严格按照我们画好的“轨迹”来移动不能越界不能穿模一个格子上只能有一个物体。最初我也迷信物理系统结果在真机特别是老设备如iPhone 8上跑起来各种不跟手调试到怀疑人生。最后痛定思痛抛弃了复杂的物理模拟回归到最朴素的二维数组网格Grid和数据驱动的逻辑上。这套方案不仅逻辑清晰、性能可控而且代码的可维护性和关卡设计的灵活性都大大提升。如果你也在为CocosCreator 3.x中如何实现精准的轨迹移动而头疼或者担心物理引擎带来的性能问题那么我踩过的这些坑和总结的这套“笨办法”或许能给你一条更踏实的前进路径。2. 核心思路为什么放弃物理引擎选择网格系统在深入代码之前我们必须先统一思想对于强规则性的棋盘/格子类移动数据状态的权威性应该高于视觉物理表现。2.1 物理引擎的“水土不服”物理引擎如Cocos内置的Builtin或Cannon.js是为模拟真实世界连续运动而设计的它处理的是连续的坐标、速度、力和碰撞。但我们的“轨迹移动”本质是离散的。物体只能从一个格子中心点瞬间“跳”到另一个相邻的格子中心点。这里存在几个根本矛盾连续与离散的冲突物理引擎计算出的位置是浮点数而我们的格子是整数索引。用物理约束如关节、碰撞体形状很难完美地将物体“锁”在格子中心总会有微小的偏移积累起来就是视觉上的不整齐和逻辑判断的误差。性能与精度持续运行的物理模拟哪怕物体是静止的本身就有开销。为了阻止物体滑出轨道你可能需要设置一堆静态碰撞体作为“墙”这增加了碰撞检测的复杂度。在老款移动设备上这些开销可能就是卡顿的元凶。状态同步难题游戏逻辑最需要知道的是“物体在哪个格子上”而不是“物体的世界坐标精确到小数点后几位”。用物理引擎你需要不断从刚体的worldPosition反算回格子索引这个转换过程容易因浮点误差而出错尤其是在物体被“卡”在两个格子之间时。规则实现的复杂性像“一个轨迹格子上只能有一个物体”、“不能穿越同类物体”这类规则用物理碰撞来实现非常别扭。你需要处理碰撞分组、过滤还要防止高速移动下的穿透代码会变得复杂且脆弱。2.2 网格系统的优势相比之下基于二维数组的网格系统就纯粹得多状态唯一一个grid[x][y]的值就明确表示了该格子的状态例如0空1墙2轨迹3物体A4物体B。物体的位置就是(x, y)这个整数对。逻辑简单判断能否移动就是检查目标格子(x1, y)的值是否为“轨迹”且不为“物体”。所有规则都可以通过直接读取和修改这个二维数组来实现没有歧义。性能极佳逻辑运算只有简单的数组读写和整数比较几乎没有性能压力。渲染部分只需要根据最新的网格状态更新对应节点的位置即可。与关卡设计器无缝衔接你可以直接用Tiled地图编辑器、Excel甚至文本来设计关卡每个格子是什么类型一目了然导入到游戏里就是一个二维数组数据驱动非常方便。我的踩坑心得不要试图用解决连续动力学问题的工具物理引擎去解决离散状态机问题棋盘逻辑。早期贪图物理引擎的“可视化”和“自动碰撞”而选型错误会导致中后期整个游戏逻辑层和表现层纠缠不清重构成本巨大。对于解谜、战棋、推箱子这类游戏第一时间确立网格系统的核心地位是项目健康度的关键。3. 系统架构与数据层设计明确了网格核心思想后我们来搭建系统的骨架。整个系统可以分为三层数据层、逻辑层和表现层。3.1 定义网格与格子类型首先我们需要定义整个游戏世界的坐标系和格子类型。这里我建议在项目初期就建立一个全局的配置或枚举文件。// GameConstants.ts export const enum TileType { EMPTY 0, // 空地不可通行 WALL 1, // 墙壁不可通行 TRACK 2, // 轨迹可通行 // 可以根据需要扩展更多类型如起点、终点、陷阱等 } export const enum ObjectType { NONE 0, BOX_RED 1, // 红色方块 BOX_BLUE 2, // 蓝色方块 PLAYER 3, // ... 其他物体类型 } // 全局配置格子像素大小 export const TILE_SIZE 64;接着定义核心的GridManager单例类来管理整个网格数据。// GridManager.ts import { _decorator, Component, Node } from cc; import { TileType, ObjectType, TILE_SIZE } from ./GameConstants; export class GridManager { private static _instance: GridManager; public static get instance(): GridManager { if (!this._instance) { this._instance new GridManager(); } return this._instance; } private _width: number 0; private _height: number 0; // 核心二维数组存储格子类型地面是什么 private _tileGrid: number[][] []; // 另一个二维数组存储格子上的物体谁站在上面 private _objectGrid: number[][] []; // 初始化网格例如从关卡数据加载 init(width: number, height: number, tileData: number[][]) { this._width width; this._height height; this._tileGrid tileData; // 假设tileData是已经加载好的二维数组 // 初始化物体网格为空 this._objectGrid []; for (let x 0; x width; x) { this._objectGrid[x] []; for (let y 0; y height; y) { this._objectGrid[x][y] ObjectType.NONE; } } } // 根据世界坐标获取格子索引 worldPosToTileIndex(worldPos: Vec3): {x: number, y: number} { // 假设世界坐标系原点在左下角格子与像素对齐 const x Math.floor(worldPos.x / TILE_SIZE); const y Math.floor(worldPos.y / TILE_SIZE); // 注意Cocos的y轴可能向上为正需要根据你的坐标系调整 // 例如如果原点在左上角则 y Math.floor((totalHeight - worldPos.y) / TILE_SIZE); return {x, y}; } // 根据格子索引获取世界坐标中心点 tileIndexToWorldPos(tileX: number, tileY: number): Vec3 { const x tileX * TILE_SIZE TILE_SIZE / 2; const y tileY * TILE_SIZE TILE_SIZE / 2; return new Vec3(x, y, 0); } // --- 核心查询API --- getTileTypeAt(x: number, y: number): TileType { if (this.isInGrid(x, y)) { return this._tileGrid[x][y]; } return TileType.WALL; // 超出边界视为墙 } getObjectAt(x: number, y: number): ObjectType { if (this.isInGrid(x, y)) { return this._objectGrid[x][y]; } return ObjectType.NONE; } setObjectAt(x: number, y: number, objType: ObjectType) { if (this.isInGrid(x, y)) { this._objectGrid[x][y] objType; } } isInGrid(x: number, y: number): boolean { return x 0 x this._width y 0 y this._height; } // 判断一个格子是否可通行是轨迹且没有物体 isTileWalkable(x: number, y: number): boolean { return this.getTileTypeAt(x, y) TileType.TRACK this.getObjectAt(x, y) ObjectType.NONE; } }3.2 关卡数据的设计与加载关卡数据最好外部化。我们可以用一个简单的JSON文件来定义一个关卡// level_01.json { width: 8, height: 8, tiles: [ [1,1,1,1,1,1,1,1], [1,2,2,2,2,2,2,1], [1,2,0,0,0,0,2,1], [1,2,0,1,1,0,2,1], [1,2,0,1,1,0,2,1], [1,2,0,0,0,0,2,1], [1,2,2,2,2,2,2,1], [1,1,1,1,1,1,1,1] ], objects: [ {type: BOX_RED, x: 2, y: 3}, {type: BOX_BLUE, x: 5, y: 3} ] }在游戏启动或切换关卡时加载这个JSON并初始化GridManager。// LevelManager.ts import { resources, JsonAsset } from cc; import { GridManager } from ./GridManager; import { ObjectType } from ./GameConstants; export class LevelManager { async loadLevel(levelId: number) { const path levels/level_${levelId}; const jsonAsset await new PromiseJsonAsset((resolve, reject) { resources.load(path, JsonAsset, (err, asset) { if (err) reject(err); else resolve(asset); }); }); const levelData jsonAsset.json; GridManager.instance.init(levelData.width, levelData.height, levelData.tiles); // 清理上一关的物体实例化新物体并放置到网格上 this.spawnObjects(levelData.objects); } private spawnObjects(objectsData: any[]) { for (const objData of objectsData) { const objType this.parseObjectType(objData.type); const {x, y} objData; // 1. 在逻辑网格上注册物体 GridManager.instance.setObjectAt(x, y, objType); // 2. 实例化对应的预制体并设置到正确世界位置 const worldPos GridManager.instance.tileIndexToWorldPos(x, y); // ... 实例化节点设置位置添加脚本等 } } }设计要点将tileGrid地形和objectGrid物体分离是非常关键的一步。地形是静态的定义了什么格子可以走轨迹。物体是动态的记录谁站在哪里。这样判断一个格子是否“可移动至此”就变成了两个简单的检查tileGrid[x][y] TileType.TRACK objectGrid[x][y] ObjectType.NONE。逻辑非常清晰。4. 移动逻辑的实现从输入到格子的状态变迁有了扎实的数据层移动逻辑的实现就变成了对网格状态的查询和更新。我们以一个可移动的方块MovableBox为例。4.1 移动范围的动态计算物体不是在任何地方都能移动的。它的移动范围被其所在的“轨迹簇”所限制。我们需要一个算法当物体放在某个起始格子时找出所有与之连通的、类型为“轨迹”的格子集合。这就是一个经典的Flood Fill洪水填充算法和你在很多画图软件里用的“油漆桶”工具原理一样。// MovableBox.ts import { _decorator, Component, Node, Vec3, input, Input, EventTouch, KeyCode } from cc; import { GridManager } from ./GridManager; import { ObjectType, TileType } from ./GameConstants; const { ccclass, property } _decorator; ccclass(MovableBox) export class MovableBox extends Component { // 该物体在网格上的逻辑位置 private _gridX: number 0; private _gridY: number 0; // 该物体所属的类型 property({ type: ObjectType }) public objectType: ObjectType ObjectType.BOX_RED; // 该物体当前可以移动到的所有格子坐标 private _movableTiles: {x: number, y: number}[] []; start() { // 初始化时根据节点世界位置反算格子坐标 const worldPos this.node.worldPosition; const gridPos GridManager.instance.worldPosToTileIndex(worldPos); this._gridX gridPos.x; this._gridY gridPos.y; // 向网格管理器注册自己 GridManager.instance.setObjectAt(this._gridX, this._gridY, this.objectType); // 计算初始可移动范围 this.calculateMovableRange(); // 监听输入例如点击或拖拽 this.setupInput(); } // 核心Flood Fill算法计算可移动范围 calculateMovableRange() { this._movableTiles []; const visited new Setstring(); // 用于记录已访问的格子避免重复和死循环 const stack: {x: number, y: number}[] []; // 用栈实现深度优先搜索(DFS) // 从自身所在格子开始 stack.push({x: this._gridX, y: this._gridY}); visited.add(${this._gridX},${this._gridY}); while (stack.length 0) { const current stack.pop()!; // 即使当前格子是自己站的位置也加入可移动范围代表可以“不动” this._movableTiles.push(current); // 检查四个方向上、下、左、右 const directions [ {dx: 1, dy: 0}, // 右 {dx: -1, dy: 0}, // 左 {dx: 0, dy: 1}, // 上 {dx: 0, dy: -1}, // 下 ]; for (const dir of directions) { const nextX current.x dir.dx; const nextY current.y dir.dy; const key ${nextX},${nextY}; // 如果下一个格子未访问过且在网格内且是轨迹且没有其他物体 if (!visited.has(key) GridManager.instance.isTileWalkable(nextX, nextY)) { visited.add(key); stack.push({x: nextX, y: nextY}); } } } // 此时_movableTiles 包含了所有从起点能到达的、空的轨迹格子。 // 可视化调试可以在这里生成一些高亮精灵来显示范围。 console.log(物体可移动至 ${this._movableTiles.length} 个格子); } }4.2 处理玩家输入与移动请求当玩家拖动或点击想让物体移动时我们需要将屏幕坐标转换为网格坐标并判断目标点是否在_movableTiles列表中。// 接上 MovableBox.ts setupInput() { // 以拖拽为例 this.node.on(Node.EventType.TOUCH_MOVE, this.onTouchMove, this); this.node.on(Node.EventType.TOUCH_END, this.onTouchEnd, this); } private _isDragging: boolean false; private _touchStartPos: Vec3 new Vec3(); onTouchMove(event: EventTouch) { if (!this._isDragging) { this._isDragging true; event.touch!.getUILocation(this._touchStartPos); } // 可以在这里实现拖拽跟随的临时视觉效果 } onTouchEnd(event: EventTouch) { if (!this._isDragging) return; this._isDragging false; const touchEndPos new Vec3(); event.touch!.getUILocation(touchEndPos); // 计算拖拽方向向量 const delta new Vec3(); Vec3.subtract(delta, touchEndPos, this._touchStartPos); // 判断主要移动方向简化处理取绝对值最大的分量 let targetGridX this._gridX; let targetGridY this._gridY; const threshold 20; // 移动阈值避免误触 if (Math.abs(delta.x) Math.abs(delta.y)) { // 水平移动 if (delta.x threshold) targetGridX 1; // 向右 else if (delta.x -threshold) targetGridX - 1; // 向左 } else { // 垂直移动 if (delta.y threshold) targetGridY 1; // 向上 else if (delta.y -threshold) targetGridY - 1; // 向下 } // 发起移动请求 this.requestMoveTo(targetGridX, targetGridY); } requestMoveTo(targetX: number, targetY: number) { // 1. 检查目标是否在可移动范围内 const canMove this._movableTiles.some(tile tile.x targetX tile.y targetY); if (!canMove) { console.log(无法移动到 (${targetX}, ${targetY})该位置不在可移动轨迹上或已有物体。); // 可以给一个抖动或音效反馈 return; } // 2. 执行移动 this.executeMove(targetX, targetY); }4.3 执行移动与状态更新移动的执行分为两步更新逻辑网格状态然后更新视觉表现。// 接上 MovableBox.ts executeMove(newX: number, newY: number) { // 1. 更新逻辑网格将旧位置清空新位置占位 GridManager.instance.setObjectAt(this._gridX, this._gridY, ObjectType.NONE); GridManager.instance.setObjectAt(newX, newY, this.objectType); // 2. 更新物体自身的逻辑坐标 this._gridX newX; this._gridY newY; // 3. 更新视觉位置可以加动画 const newWorldPos GridManager.instance.tileIndexToWorldPos(newX, newY); // 简单瞬移 // this.node.setPosition(newWorldPos); // 使用Tween动画移动 tween(this.node) .to(0.2, { position: newWorldPos }, { easing: sineOut }) .start(); // 4. 移动后重新计算可移动范围因为自身位置变了 this.calculateMovableRange(); // 5. 可选触发一个全局事件通知其他系统如检查关卡是否完成 // director.emit(object:moved, this.objectType, newX, newY); }关键细节executeMove函数中先更新数据层再更新表现层的顺序至关重要。这保证了在任何时刻逻辑状态都是唯一且正确的来源。动画只是让这个状态变化看起来更平滑。即使动画还没播完游戏逻辑也已经认为物体在新格子上了。5. 高级特性与性能优化基础移动实现后我们可以根据游戏需求添加更多规则和优化。5.1 实现“一格一物”与推箱子逻辑“一个轨迹格子上只能有一个物体”的规则在我们上面的isTileWalkable检查中已经通过objectGrid实现了。那“推箱子”呢假设我们的红色方块可以推动蓝色方块。我们需要修改移动判断逻辑。当物体试图移动到一个已被占用的格子时不是直接拒绝而是检查“能否连锁推动”。// MovableBox.ts - 增强版移动请求判断 canPushTo(targetX: number, targetY: number): {canMove: boolean, chain: {x: number, y: number}[]} { const targetObject GridManager.instance.getObjectAt(targetX, targetY); const targetTile GridManager.instance.getTileTypeAt(targetX, targetY); // 情况1目标格子是空的轨迹 - 可以直接移动 if (targetObject ObjectType.NONE targetTile TileType.TRACK) { return { canMove: true, chain: [{x: targetX, y: targetY}] }; } // 情况2目标格子有物体且该物体是可推动的 // 假设我们有一个函数来判断物体类型是否可被推动 if (this.isObjectPushable(targetObject) targetTile TileType.TRACK) { // 计算推动方向 const dx targetX - this._gridX; const dy targetY - this._gridY; const nextX targetX dx; const nextY targetY dy; // 递归检查被推的物体的下一个格子是否可行 // 注意这里需要获取目标格子上的物体实例来调用它的canPushTo方法。 // 这需要GridManager不仅能返回物体类型还能返回物体引用。我们可以建立一个映射。 const pushedObj this.getObjectNodeAt(targetX, targetY); // 假设这个方法能拿到物体脚本 if (pushedObj) { const pushResult pushedObj.canPushTo(nextX, nextY); if (pushResult.canMove) { // 连锁推动成立 return { canMove: true, chain: [{x: targetX, y: targetY}, ...pushResult.chain] // 合并推动链 }; } } } // 情况3其他所有情况 - 不能移动 return { canMove: false, chain: [] }; } // 修改 requestMoveTo requestMoveTo(targetX: number, targetY: number) { // 使用新的判断逻辑 const { canMove, chain } this.canPushTo(targetX, targetY); if (!canMove) { this.playInvalidMoveFeedback(); return; } // 执行连锁移动。注意要从链的末端开始移动避免覆盖。 // 链的顺序是[被推物体目标位置 被推物体的被推目标位置...] // 我们需要逆序执行 for (let i chain.length - 1; i 0; i--) { const step chain[i]; // 这里需要找到对应格子的物体并移动它。实现略复杂需要维护格子到物体实例的映射。 // 思路在GridManager中用一个Map记录坐标到MovableBox实例的引用。 } // 最后移动自己 this.executeMove(targetX, targetY); }5.2 性能优化缓存与脏标记如果你的地图很大或者可移动物体很多每一帧都对所有物体进行Flood Fill来计算移动范围是不现实的。我们需要优化。缓存移动范围物体的可移动范围只在两种情况下需要重新计算a) 自己移动了b) 周围的地形或其他物体发生了改变影响了连通性。在大多数情况下移动范围是静态的可以缓存起来。使用脏标记Dirty Flag在GridManager中设置一个脏标记。当任何改变地形或物体布局的操作发生时如移动物体、炸毁墙壁就将这个标记设为true。在下一帧或下一个逻辑回合开始时所有受影响的物体可以通过记录依赖关系或简单粗暴地全部检查这个标记如果为脏则重新计算自己的移动范围然后清除标记。// GridManager.ts 补充 private _gridDirty: boolean false; // 当改变网格状态时 setObjectAt(x: number, y: number, objType: ObjectType) { if (this.isInGrid(x, y)) { const oldObj this._objectGrid[x][y]; this._objectGrid[x][y] objType; // 如果放置或移除了物体标记网格为脏 if (oldObj ! objType) { this._gridDirty true; } } } // 提供一个方法供物体查询是否需要更新 shouldUpdateMovementRange(): boolean { const dirty this._gridDirty; if (dirty) { this._gridDirty false; // 查询后清除 } return dirty; } // 在MovableBox的update或一个统一的游戏循环中 update(deltaTime: number) { if (GridManager.instance.shouldUpdateMovementRange()) { this.calculateMovableRange(); } }限制Flood Fill范围对于大部分游戏物体的移动范围不会无限大。可以根据物体类型设置一个最大搜索步数maxSteps在Flood Fill时记录从起点出发的“距离”超过这个距离就停止搜索。5.3 可视化调试绘制可移动范围在开发阶段将可移动范围可视化出来对调试和设计至关重要。我们可以在物体被选中时在它所有可移动的格子上方生成半透明的“高亮块”。// MovableBox.ts - 调试绘制 property({type: Prefab}) highlightTilePrefab: Prefab | null null; private _highlightNodes: Node[] []; showMovementRange() { this.clearHighlights(); for (const tile of this._movableTiles) { const highlightNode instantiate(this.highlightTilePrefab!); const worldPos GridManager.instance.tileIndexToWorldPos(tile.x, tile.y); highlightNode.setPosition(worldPos); // 可以设置一个父节点来管理所有高亮 this.node.parent.addChild(highlightNode); this._highlightNodes.push(highlightNode); } } hideMovementRange() { this.clearHighlights(); } private clearHighlights() { for (const node of this._highlightNodes) { node.destroy(); } this._highlightNodes []; }6. 常见问题与避坑指南在实际开发中你肯定会遇到一些棘手的问题。以下是我总结的几个典型场景和解决方案。6.1 坐标系转换的坑Cocos Creator 3.x的坐标系通常是Y轴向上可能与你的关卡编辑器如TiledY轴向下或网格逻辑坐标系不一致。这是最大的混乱来源。问题物体渲染的位置和逻辑格子对不上。解决在GridManager的worldPosToTileIndex和tileIndexToWorldPos函数中明确进行一次Y轴翻转。例如如果关卡数据是左上角为(0,0)Y轴向下增长而Cocos世界是左下角为(0,0)Y轴向上增长那么转换时需要logicY totalGridHeight - 1 - cocosWorldY。务必在项目初期就确定一套统一的逻辑坐标系并在所有转换处坚持使用。6.2 物体“挤在一起”的判断当两个物体试图移动到同一个空轨迹格子时谁先谁后如果同时判断可能都会成功导致逻辑错误。问题并发移动导致状态冲突。解决引入行动顺序或回合概念。例如玩家操作是顺序执行的在一个操作完全结束包括动画之前不接受新的操作。对于AI或同时移动可以引入一个“移动请求队列”在一个统一的“逻辑帧”里处理所有请求按优先级或规则排序并解决冲突例如后请求的失败。6.3 移动动画与逻辑的同步你用了Tween做移动动画耗时0.2秒。在这0.2秒内逻辑上物体已经在新格子但视觉上还在旧格子。如果此时玩家快速点击另一个指令或者有AI立刻判断这个新格子的状态可能会出问题。问题动画期间逻辑与表现不同步。解决状态锁在物体_isMoving为true时屏蔽一切新的移动请求。回调通知在Tween动画的onComplete回调中再触发“移动真正结束”的事件然后才解锁状态或进行下一步逻辑如检查胜利条件。立即更新对于不需要视觉反馈的纯逻辑判断如AI寻路直接读取网格数据忽略动画状态。6.4 复杂地形与多层轨迹上面的例子是简单的四方向连通。如果你的轨迹有“传送门”、“单向通行”、“需要钥匙的锁”等复杂规则怎么办解决扩展TileType枚举和isTileWalkable逻辑。例如isTileWalkableForObject(x: number, y: number, object: MovableBox): boolean { const tileType this.getTileTypeAt(x, y); const objectOnTile this.getObjectAt(x, y); if (objectOnTile ! ObjectType.NONE) return false; // 有物体挡着 switch(tileType) { case TileType.TRACK: return true; case TileType.ONE_WAY_UP: // 检查物体是否从下方过来 return object.lastGridY y; case TileType.TELEPORTER: // 总是可进入进入后会触发传送逻辑 return true; case TileType.LOCKED_DOOR: // 检查物体是否有对应钥匙 return object.hasKey(red_key); default: return false; } }在calculateMovableRange的Flood Fill中将判断条件从通用的isTileWalkable替换为这个更具体的isTileWalkableForObject。6.5 内存与对象管理当地图很大、物体很多时每个物体都缓存一个_movableTiles数组可能占用不少内存。优化按需计算只在物体被选中或可能移动时才计算移动范围并在一段时间后或取消选中时释放缓存。共享结果如果多个同类型物体在完全相同的地形环境下它们的可移动范围可能是一样的。可以考虑缓存一个“地形指纹”如周围格子类型的哈希值到移动范围的映射进行共享。但这会增加复杂度需权衡。使用更紧凑的数据结构用Uint16Array或Bitmask来表示移动范围而不是对象数组{x, y}[]。从被物理引擎折磨到回归网格数据驱动的朴素美学这个过程让我深刻体会到在游戏开发中最适合的解决方案往往不是最“强大”或最“炫酷”的而是最“简单”和“可控”的。对于CocosCreator 3.x中的轨迹移动放弃“物理模拟”的执念拥抱“状态网格”用清晰的数据结构驱动游戏逻辑不仅能换来性能的显著提升和Bug的急剧减少更能让后续的功能扩展如推箱子、传送门、机关联动变得有章可循。当你再遇到移动逻辑的难题时不妨先问自己一句“用二维数组该怎么表示” 答案往往就在其中。