1. 項(xiàng)目概述六邊形大地圖的本質(zhì)與價(jià)值做SLG游戲研發(fā)的人多少都研究過《三國志戰(zhàn)略版》那種一眼望不到邊的六邊形大地圖。城池、關(guān)隘、山脈、河流、平原全部鋪在六邊形網(wǎng)格上玩家拖動(dòng)屏幕、縮放視角、點(diǎn)選地塊、行軍出征手感順滑且信息密度極高。這套地圖系統(tǒng)不僅是美術(shù)層面的展示更是整個(gè)游戲玩法邏輯的承重墻——地塊歸屬、行軍路徑、建筑選址、資源產(chǎn)出、戰(zhàn)斗判定全部依賴底層的地圖數(shù)據(jù)結(jié)構(gòu)。用Cocos Creator來實(shí)現(xiàn)這樣一套六邊形大地圖我做過幾次迭代從最初純美術(shù)擺件到后面接玩法邏輯踩了不少坑。這篇文章就把整個(gè)實(shí)現(xiàn)過程拆開講清楚適合已經(jīng)熟悉Cocos Creator基礎(chǔ)操作、想挑戰(zhàn)SLG大地圖的開發(fā)者閱讀也適合那些把“六邊形網(wǎng)格”當(dāng)成一個(gè)神秘黑盒、想弄明白底層原理的人——其實(shí)拆穿之后核心就是一套坐標(biāo)系轉(zhuǎn)換加網(wǎng)格布局算法并不玄乎。先說清楚這套系統(tǒng)到底做什么它能生成指定大小的六邊形棋盤支持地塊類型定義平地、山地、水域、城池等支持地塊狀態(tài)查詢與修改支持玩家點(diǎn)擊選中地塊、顯示地塊詳情支持行軍路徑的網(wǎng)格尋路與動(dòng)畫表現(xiàn)。也就是說從“顯示一張靜態(tài)地圖”到“地圖成為可交互玩法載體”的關(guān)鍵環(huán)節(jié)全部覆蓋到。1.1 為什么選擇六邊形網(wǎng)格而非四邊形網(wǎng)格做SLG大地圖第一道選擇題就是網(wǎng)格形狀。四邊形網(wǎng)格開發(fā)簡單、直覺清晰市面上不少休閑策略游戲用的就是四邊形但SLG品類普遍偏愛六邊形原因有三個(gè)。第一是移動(dòng)距離的均勻性。六邊形的中心到六個(gè)鄰居中心的距離全部相等而四邊形的斜向鄰居距離是橫向鄰居的根號2倍這意味著走斜線比走直線“更遠(yuǎn)”。在行軍、偵察、攻擊范圍這類需要精確計(jì)算格數(shù)的玩法里六邊形不會(huì)出現(xiàn)“同樣步數(shù)卻走出不同距離”的違和感。第二是視覺自然度。六邊形拼合之后接近蜂窩結(jié)構(gòu)邊界曲折度適中比正方形的硬線條更貼合自然地形。山川河流的走向在六邊形地圖上表現(xiàn)得更流暢城池地塊也更有“疆域感”。第三是策略豐富度。每個(gè)格子有六個(gè)鄰居比四邊形的四方向或者帶斜角的八方向更容易設(shè)計(jì)出有層次的戰(zhàn)場縱深。三國志戰(zhàn)略版里那種“一夫當(dāng)關(guān)”的地形卡位、陣型側(cè)翼、夾擊判定六邊形的六個(gè)方向提供了更細(xì)膩的表達(dá)空間。如果項(xiàng)目對網(wǎng)格精度要求不高、開發(fā)周期極緊四邊形當(dāng)然是性價(jià)比之選。但只要想做有深度的SLG玩法六邊形網(wǎng)格的投入就值得。2. 坐標(biāo)系選擇與網(wǎng)格生成原理六邊形地圖第一道坎就是坐標(biāo)系。很多新手一上來就想著畫六個(gè)三角形拼成六邊形然后靠屏幕坐標(biāo)硬擺位置結(jié)果一拖動(dòng)地圖就亂套。正確做法是先建立干凈的邏輯坐標(biāo)系再做屏幕映射。2.1 三種常見坐標(biāo)系對比六邊形網(wǎng)格常用的坐標(biāo)系有三種偏移坐標(biāo)Offset、立方體坐標(biāo)Cube、軸向坐標(biāo)Axial。偏移坐標(biāo)是最接近屏幕直覺的分奇行偏移和偶行偏移兩類行號變化時(shí)列號需要加個(gè)偏移量。存儲(chǔ)上就是行列兩個(gè)整數(shù)但做鄰居查找、距離計(jì)算時(shí)數(shù)學(xué)表達(dá)式詭異很容易寫出要枚舉六種情況的代碼。立方體坐標(biāo)是把六邊形網(wǎng)格想象成三維空間里一個(gè)平面的投影每個(gè)格子用(x, y, z)三個(gè)值表示且滿足x y z 0的約束。它的最大好處是鄰居計(jì)算和距離計(jì)算極其對稱六個(gè)方向就是六個(gè)固定的三維向量加減法搞定一切。軸向坐標(biāo)是立方體坐標(biāo)去掉一維后的簡化版保留x和y兩個(gè)值邏輯上繼承對稱性存儲(chǔ)上只有兩個(gè)整數(shù)是實(shí)際開發(fā)中使用頻率最高的方案。我最終選擇的組合是邏輯層用軸向坐標(biāo)表現(xiàn)層用偏移坐標(biāo)兩者之間做一層轉(zhuǎn)換。這樣既保證了玩法算法的干凈又不會(huì)讓美術(shù)同學(xué)配置地塊時(shí)對著負(fù)數(shù)坐標(biāo)發(fā)懵。2.2 軸向坐標(biāo)到屏幕坐標(biāo)的數(shù)學(xué)推導(dǎo)軸向坐標(biāo)下約定r方向?yàn)橛蚁滦毕騫方向?yàn)樗较蛴也煌Y料有不同定義自己體系統(tǒng)一就行。一個(gè)格子的中心位置可以用兩條基向量疊加計(jì)算。設(shè)定六邊形的外接圓半徑為size則水平方向的基向量為(size * 1.5, size * 0.866)斜向的基向量為(0, size * 1.732)。其中0.866是cos(30度)的值1.732是根號3的近似值。所以從軸向坐標(biāo)(q, r)轉(zhuǎn)到屏幕坐標(biāo)的公式為posX size * 1.5 * q posY size * 1.732 * (r q / 2)注意圖示和代碼實(shí)現(xiàn)中Y軸可能出現(xiàn)方向相反的問題。Cocos Creator的2D坐標(biāo)系Y軸向上這正好和多數(shù)六邊形算法教程里的世界坐標(biāo)系一致。如果你用的是某些默認(rèn)Y軸向下的引擎或自繪圖需要做一次鏡像。反過來從屏幕坐標(biāo)反推軸向坐標(biāo)是尋路、點(diǎn)擊檢測等交互操作的基石。公式如下q (sqrt(3)/3 * posX - 1/3 * posY) / size r (2/3 * posY) / size算出來的q和r是浮點(diǎn)數(shù)需要四舍五入到最近的整數(shù)格。但直接四舍五入在某些邊緣點(diǎn)上會(huì)選錯(cuò)鄰居穩(wěn)妥做法是把浮點(diǎn)坐標(biāo)轉(zhuǎn)成立方體坐標(biāo)再做四舍五入然后修正約束條件。這個(gè)細(xì)節(jié)我在第一版代碼里沒注意導(dǎo)致點(diǎn)擊邊界地帶時(shí)偶發(fā)選中錯(cuò)誤地塊玩家反饋“點(diǎn)不準(zhǔn)”后來換成這個(gè)方案才穩(wěn)定。注意無論采用哪種坐標(biāo)系最重要的是全局統(tǒng)一?；煊米鴺?biāo)系而不做轉(zhuǎn)換層最終一定會(huì)在尋路算法或地塊查詢階段爆發(fā)詭異bug。2.3 網(wǎng)格生成的Cocos實(shí)現(xiàn)生成一個(gè)完整地圖本質(zhì)上就是遍歷所有合法坐標(biāo)為每個(gè)格子創(chuàng)建節(jié)點(diǎn)并擺放到位。以三國志戰(zhàn)略版的經(jīng)典尺寸為參照一張主地圖通常上百列上百行直接生成上萬個(gè)節(jié)點(diǎn)會(huì)讓場景樹爆炸。我在第一版就吃了這個(gè)虧場景樹幾萬個(gè)節(jié)點(diǎn)編輯器都卡。所以正確做法是先按區(qū)塊加載或者只生成可見區(qū)。但為了讓讀者能先在本地跑通先講全量生成的實(shí)現(xiàn)邏輯后面只有在性能優(yōu)化部分才展開分區(qū)塊方案。下面是用TypeScript實(shí)現(xiàn)的網(wǎng)格生成代碼。這個(gè)版本先采用偏移坐標(biāo)存儲(chǔ)因?yàn)閷γ佬g(shù)配置最友好import { _decorator, Component, Node, instantiate, Prefab, Vec3 } from cc; const { ccclass, property } _decorator; ccclass(HexGridGenerator) export class HexGridGenerator extends Component { property(Prefab) hexPrefab: Prefab null; property mapWidth: number 60; property mapHeight: number 40; property hexRadius: number 32; private gridMap: Mapstring, Node new Map(); start() { this.generateGrid(); } generateGrid() { for (let row 0; row this.mapHeight; row) { let offsetX 0; if (row % 2 1) { offsetX this.hexRadius * 0.866; } for (let col 0; col this.mapWidth; col) { const posX col * this.hexRadius * 1.5 offsetX; const posY -row * this.hexRadius * 1.732; const cellNode instantiate(this.hexPrefab); cellNode.setParent(this.node); cellNode.setPosition(new Vec3(posX, posY, 0)); const key ${row}_${col}; this.gridMap.set(key, cellNode); cellNode.name hex_${row}_${col}; } } } }這段代碼有個(gè)關(guān)鍵點(diǎn)offsetX只在奇數(shù)行生效這正是六邊形交錯(cuò)排列的核心。如果省略這行六邊形會(huì)全部對齊成矩形陣列鄰居關(guān)系直接錯(cuò)亂。第二點(diǎn)是posY用了負(fù)號因?yàn)镃ocos的Y軸向上而我習(xí)慣讓地圖向下延伸。另外有一個(gè)容易被忽略的事情——六邊形Prefab的錨點(diǎn)必須設(shè)置在正中心。Cocos默認(rèn)精靈錨點(diǎn)是(0.5, 0.5)但如果美術(shù)給的六邊形資源帶邊框偏移錨點(diǎn)不居中整張地圖的網(wǎng)格定位就會(huì)跟著漂移而且越靠邊緣越明顯。最穩(wěn)的做法是在資源導(dǎo)入時(shí)直接檢查錨點(diǎn)位置或是在代碼里統(tǒng)一修正子節(jié)點(diǎn)的本地偏移。2.4 地塊類型的渲染方案大地圖的地塊不是千篇一律的純色六邊形。有草地、森林、沙漠、山地、水域還有城池、關(guān)隘這類特殊建筑地塊。直接為每種類型準(zhǔn)備一套獨(dú)立的Prefab是最直觀的思路但資源浪費(fèi)極大——如果地圖有十種地塊類型每個(gè)地塊節(jié)點(diǎn)都掛一個(gè)包含十種素材的腳本內(nèi)存開銷看著就心疼。更合理的方案是地塊節(jié)點(diǎn)只保留一份基礎(chǔ)框架通過更換子節(jié)點(diǎn)紋理或SpriteFrame來表現(xiàn)不同地塊類型。基礎(chǔ)框架包含一個(gè)底圖Sprite一個(gè)可選的地形裝飾層一個(gè)地塊遮罩用于高亮或暗化一個(gè)文本Label顯示坐標(biāo)或資源數(shù)值。類型切換時(shí)只替換SpriteFrame這樣地圖生成時(shí)就可以流暢地批量設(shè)置地塊屬性。地塊數(shù)據(jù)用枚舉定義export enum HexTerrainType { Plain 0, Forest 1, Mountain 2, Water 3, City 4, Road 5 }每個(gè)地塊的邏輯數(shù)據(jù)掛在ScriptAsset里不掛在運(yùn)行節(jié)點(diǎn)上。這一點(diǎn)非常重要——游戲運(yùn)行中地塊狀態(tài)會(huì)頻繁變化比如被攻打后從繁榮變破敗如果把狀態(tài)存在節(jié)點(diǎn)組件里遍歷查找會(huì)很慢而且節(jié)點(diǎn)一銷毀數(shù)據(jù)就丟。正確結(jié)構(gòu)是單獨(dú)維護(hù)一個(gè)二維網(wǎng)格數(shù)據(jù)數(shù)組節(jié)點(diǎn)只是數(shù)據(jù)的可視化映射。3. 地塊數(shù)據(jù)組織與算法核心地圖的網(wǎng)格生成只是第一步真正支撐玩法的是地塊數(shù)據(jù)的組織和相關(guān)系列的算法。比如玩家點(diǎn)擊一塊地要能立刻知道圍繞它的六塊鄰居分別是什么、距離目標(biāo)地塊要經(jīng)過多少格子、路徑怎么走才最優(yōu)。3.1 基于立方體坐標(biāo)的鄰居與距離算法我之前提到邏輯層推薦軸向坐標(biāo)但軸向坐標(biāo)的鄰居計(jì)算依然有六個(gè)方向需要記憶。如果直接使用立方體坐標(biāo)六個(gè)方向就是固定的三維向量const cubeDirections [ { x: 1, y: -1, z: 0 }, { x: 1, y: 0, z: -1 }, { x: 0, y: 1, z: -1 }, { x: -1, y: 1, z: 0 }, { x: -1, y: 0, z: 1 }, { x: 0, y: -1, z: 1 } ];只要把坐標(biāo)轉(zhuǎn)成立方體形式加一個(gè)方向向量再轉(zhuǎn)回來就拿到了某個(gè)格子的指定鄰居。不需要任何if分支判斷奇偶行這是立方體坐標(biāo)最舒服的地方。距離計(jì)算也極簡單。兩個(gè)立方體坐標(biāo)之差取絕對值的最大值就是網(wǎng)格距離function cubeDistance(a: {x: number, y: number, z: number}, b: {x: number, y: number, z: number}) { return Math.max(Math.abs(a.x - b.x), Math.abs(a.y - b.y), Math.abs(a.z - b.z)); }比如兩個(gè)格子的立方體坐標(biāo)差是(3, 1, 4)那距離就是4格。這比偏移坐標(biāo)的曼哈頓距離A*變體要清晰得多。3.2 A*尋路在六邊形地圖上的應(yīng)用SLG大地圖行軍必須走可通行地塊不能直接直線穿山過河。所以要用A*尋路算法在網(wǎng)格圖上搜索路徑。A*的估價(jià)函數(shù)在六邊形網(wǎng)格上沒有本質(zhì)區(qū)別啟發(fā)函數(shù)直接使用立方體距離也就是之前寫的cubeDistance。通行性判斷則依賴于地塊阻擋表——哪些地形可以走哪些不能走function isWalkable(terrain: HexTerrainType): boolean { return terrain ! HexTerrainType.Water terrain ! HexTerrainType.Mountain; }尋路算法本身用二叉堆做Open List優(yōu)化。小型地圖用線性掃也行但大圖上Open List可能堆到幾千個(gè)節(jié)點(diǎn)線性查找的復(fù)雜度不可接受。我這里直接用Cocos自帶或第三方庫的優(yōu)先隊(duì)列避免重復(fù)造輪子。實(shí)現(xiàn)一個(gè)簡化版A*作為參考function findPath(start: CubeCoord, goal: CubeCoord, walkableSet: Setstring): CubeCoord[] { interface Node { coord: CubeCoord; g: number; h: number; parent: Node | null; } const key (c: CubeCoord) ${c.x}_${c.y}_${c.z}; const openList: Node[] []; const closedSet new Setstring(); const startNode: Node { coord: start, g: 0, h: cubeDistance(start, goal), parent: null }; openList.push(startNode); while (openList.length 0) { openList.sort((a, b) (a.g a.h) - (b.g b.h)); const current openList.shift()!; const currentKey key(current.coord); if (currentKey key(goal)) { const path: CubeCoord[] []; let node: Node | null current; while (node) { path.push(node.coord); node node.parent; } return path.reverse(); } closedSet.add(currentKey); for (const dir of cubeDirections) { const neighborCoord { x: current.coord.x dir.x, y: current.coord.y dir.y, z: current.coord.z dir.z }; const neighborKey key(neighborCoord); if (!walkableSet.has(neighborKey) || closedSet.has(neighborKey)) { continue; } const gScore current.g 1; const existingIndex openList.findIndex(n key(n.coord) neighborKey); if (existingIndex 0) { const existingNode openList[existingIndex]; if (gScore existingNode.g) { existingNode.g gScore; existingNode.parent current; } } else { openList.push({ coord: neighborCoord, g: gScore, h: cubeDistance(neighborCoord, goal), parent: current }); } } } return []; }上面代碼為了可讀性使用sort作為優(yōu)先隊(duì)列真實(shí)代碼里換二叉堆會(huì)快很多。在幾百列的地圖上一次尋路用二叉堆大概幾毫秒用sort大概幾十毫秒——單次看都能忍但SLG客戶端經(jīng)常同時(shí)觸發(fā)多個(gè)單位的自動(dòng)尋路差距就體現(xiàn)出來了。3.3 地圖坐標(biāo)轉(zhuǎn)換統(tǒng)一接口我前面說過邏輯層和表現(xiàn)層用不同坐標(biāo)系這就需要一個(gè)轉(zhuǎn)換層統(tǒng)一對外接口。地塊數(shù)據(jù)存取只用偏移坐標(biāo)(row, col)所有算法函數(shù)內(nèi)部先把偏移轉(zhuǎn)成軸向或立方體算完再轉(zhuǎn)回來。對外統(tǒng)一封裝成hexUtils工具模塊export function offsetToCube(row: number, col: number): CubeCoord; export function cubeToOffset(cube: CubeCoord): { row: number, col: number }; export function hexDistanceByOffset(row1: number, col1: number, row2: number, col2: number): number; export function getNeighborByOffset(row: number, col: number, direction: number): { row: number, col: number };這樣上層業(yè)務(wù)代碼不需要知道內(nèi)部坐標(biāo)體系只需要處理row和col兩個(gè)整數(shù)。后續(xù)如果要把地圖改成四邊形的只需要改這個(gè)工具模塊的內(nèi)部實(shí)現(xiàn)所有業(yè)務(wù)調(diào)用幾乎無需變動(dòng)。我早期沒做這一層抽象直接在業(yè)務(wù)代碼里到處用軸向坐標(biāo)結(jié)果美術(shù)配置表全用(row, col)兩端對接時(shí)經(jīng)常弄混行列順序修bug修到頭大。后來統(tǒng)一規(guī)范一切跨層訪問必須通過這些接口函數(shù)整個(gè)項(xiàng)目的地圖代碼立刻清爽了。4. 交互點(diǎn)擊、框選與地圖拖動(dòng)地圖生成完畢、算法到位之后就要面對玩家實(shí)際手上的操作了。SLG大地圖的交互體感直接決定游戲品質(zhì)如果點(diǎn)擊沒反應(yīng)、拖動(dòng)不跟手、框選誤觸再好看的地圖也很難留住玩家。4.1 點(diǎn)擊地塊的事件捕獲與坐標(biāo)反算Cocos Creator的節(jié)點(diǎn)事件系統(tǒng)里給每個(gè)地塊節(jié)點(diǎn)掛一個(gè)點(diǎn)擊事件是可以的代價(jià)是上萬個(gè)節(jié)點(diǎn)各自監(jiān)聽touch事件性能損耗和事件管理復(fù)雜度都會(huì)上升。更合理的做法是在地圖容器節(jié)點(diǎn)上統(tǒng)一監(jiān)聽觸摸事件通過觸摸位置的屏幕坐標(biāo)反算地塊坐標(biāo)。核心流程包括觸摸事件拿到UI坐標(biāo)轉(zhuǎn)成世界坐標(biāo)世界坐標(biāo)減去地圖原點(diǎn)坐標(biāo)得到相對地圖的坐標(biāo)傳入軸向坐標(biāo)反算函數(shù)四舍五入得到地塊坐標(biāo)查找對應(yīng)地塊數(shù)據(jù)觸發(fā)選中事件。如果地圖節(jié)點(diǎn)自身有縮放或平移過這四個(gè)步驟里的坐標(biāo)轉(zhuǎn)換一定要用Cocos的UITransform轉(zhuǎn)換API不能自己拿節(jié)點(diǎn)位置做加減否則地圖一拖動(dòng)就點(diǎn)不準(zhǔn)。我給地圖容器掛一個(gè)HexInputHandler組件統(tǒng)一管理點(diǎn)擊和拖動(dòng)ccclass(HexInputHandler) export class HexInputHandler extends Component { property(HexGridGenerator) gridGenerator: HexGridGenerator null; private isDragging false; private dragThreshold 5; private startTouchPos: Vec2 null; onTouchStart(event: EventTouch) { this.startTouchPos event.getUILocation(); this.isDragging false; } onTouchMove(event: EventTouch) { if (!this.startTouchPos) return; const currentPos event.getUILocation(); const delta currentPos.clone().subtract(this.startTouchPos); if (!this.isDragging delta.length() this.dragThreshold) { this.isDragging true; } if (this.isDragging) { this.node.setPosition(this.node.position.clone().add( new Vec3(delta.x, delta.y, 0) )); this.startTouchPos.set(currentPos); } } onTouchEnd(event: EventTouch) { if (!this.isDragging) { const uiPos event.getUILocation(); const localPos this.node.getComponent(UITransform) .convertToNodeSpaceAR(new Vec3(uiPos.x, uiPos.y, 0)); const gridData this.gridGenerator.pixelToHex(localPos.x, localPos.y); if (gridData) { // 觸發(fā)地塊選中事件 this.node.emit(hex-selected, gridData); } } this.isDragging false; this.startTouchPos null; } }關(guān)鍵在于拖動(dòng)和點(diǎn)擊的判斷閾值。拖動(dòng)閾值太小玩家的手指輕微晃動(dòng)就被當(dāng)成拖動(dòng)點(diǎn)選永遠(yuǎn)點(diǎn)不中閾值太大快速拖動(dòng)時(shí)響應(yīng)遲滯。經(jīng)過反復(fù)測試5像素是一個(gè)比較平衡的值。4.2 六邊形地塊高亮與選中表現(xiàn)選中地塊之后要給玩家明確反饋。三國志戰(zhàn)略版的風(fēng)格是選中地塊后邊緣亮起金色或白色描邊周圍地塊輕微壓暗。我實(shí)現(xiàn)的方式是給每個(gè)地塊節(jié)點(diǎn)額外掛一個(gè)高亮子節(jié)點(diǎn)默認(rèn)隱藏。選中地塊時(shí)顯示高亮并隱藏上一個(gè)選中的高亮。為了避免遍歷全地圖查找高亮狀態(tài)我用一個(gè)currentSelected字段記錄當(dāng)前選中的地塊節(jié)點(diǎn)切換時(shí)只操作兩個(gè)節(jié)點(diǎn)。另一種常見反饋是路徑預(yù)覽——玩家選中部隊(duì)再點(diǎn)擊目標(biāo)地塊地圖上畫出可通行的行軍路徑。表現(xiàn)上就是在地塊中心點(diǎn)放置小的圓點(diǎn)或箭頭貼圖按路徑順序依次擺放。這里有個(gè)細(xì)節(jié)如果路徑很長路徑節(jié)點(diǎn)數(shù)量可能上百個(gè)每個(gè)都是一個(gè)Sprite節(jié)點(diǎn)數(shù)量可觀。我的處理是對象池預(yù)先創(chuàng)建100個(gè)路徑節(jié)點(diǎn)超過100的路徑就用分段箭頭表示方向不顯示每格路徑。4.3 相機(jī)縮放與邊緣回彈大地圖必然要支持縮放。Cocos中縮放相機(jī)或縮放地圖容器都可以我選擇縮放地圖容器節(jié)點(diǎn)因?yàn)橄鄼C(jī)的正交大小調(diào)整會(huì)影響所有UI層除非所有UI都掛在獨(dú)立Canvas上否則容易出現(xiàn)字體模糊和UI錯(cuò)位?？s放的實(shí)現(xiàn)邏輯是監(jiān)聽鼠標(biāo)滾輪或雙指縮放手勢以當(dāng)前鼠標(biāo)位置為縮放中心點(diǎn)使縮放的視覺中心保持在光標(biāo)下onScroll(event: EventMouse) { const delta event.getScrollY(); const factor delta 0 ? 1.1 : 0.9; const worldPos event.getUILocation(); const localPos this.node.getComponent(UITransform) .convertToNodeSpaceAR(new Vec3(worldPos.x, worldPos.y, 0)); const curScale this.node.scale.x; const newScale Math.min(maxScale, Math.max(minScale, curScale * factor)); const scaleRatio newScale / curScale; const offsetX localPos.x * (1 - scaleRatio); const offsetY localPos.y * (1 - scaleRatio); this.node.setScale(newScale); this.node.setPosition( this.node.position.x offsetX, this.node.position.y offsetY ); }這里有個(gè)容易踩的坑localPos必須用縮放前的屏幕坐標(biāo)轉(zhuǎn)換不能在縮放后重新取節(jié)點(diǎn)位置算偏移否則會(huì)積累誤差導(dǎo)致縮放中心點(diǎn)逐漸漂移。邊緣回彈就不贅述了本質(zhì)是限制地圖容器的position范圍。注意邊界值要根據(jù)地圖尺寸、容器尺寸和縮放倍數(shù)綜合計(jì)算不能寫死。5. 尋路與行軍表現(xiàn)的完整串聯(lián)到這一步核心玩法就可以跑通了。我給一個(gè)實(shí)際場景玩家點(diǎn)擊一個(gè)部隊(duì)駐守的城池地塊再點(diǎn)擊一個(gè)遠(yuǎn)處目標(biāo)地塊系統(tǒng)判斷部隊(duì)能否到達(dá)、計(jì)算路徑、并讓一個(gè)行軍單位的節(jié)點(diǎn)沿路徑移動(dòng)過去。5.1 行軍路徑計(jì)算與坐標(biāo)系還原部隊(duì)所在城池記錄在地塊數(shù)據(jù)中。當(dāng)玩家點(diǎn)擊目標(biāo)地塊時(shí)先用之前封裝的距離函數(shù)計(jì)算兩地塊之間的網(wǎng)格距離超過部隊(duì)最大行動(dòng)力就直接提示“距離過遠(yuǎn)”。通過A*找到路徑后路徑上是一串立方體坐標(biāo)。渲染節(jié)點(diǎn)之前要把每個(gè)立方體坐標(biāo)轉(zhuǎn)成偏移坐標(biāo)再轉(zhuǎn)成屏幕坐標(biāo)。屏幕坐標(biāo)轉(zhuǎn)完后用一個(gè)Tween按順序做節(jié)點(diǎn)移動(dòng)。這里有個(gè)額外的尋路優(yōu)化三國志戰(zhàn)略版的路徑不一定完全按照格心連線走直線而是會(huì)盡量貼合“道路”地塊因?yàn)榈缆芬苿?dòng)消耗更低。這個(gè)效果通過給每種地塊設(shè)置不同移動(dòng)消耗值、尋路時(shí)把gScore累加消耗值來實(shí)現(xiàn)。路口、橋梁等地塊的消耗為0或0.5平地為1森林為2山地禁止通行。玩家肉眼看到的結(jié)果就是部隊(duì)會(huì)自動(dòng)走大路、繞山林非常符合SLG的直覺。5.2 行軍節(jié)點(diǎn)移動(dòng)的實(shí)現(xiàn)使用Cocos的tween系統(tǒng)逐個(gè)移動(dòng)節(jié)點(diǎn)到路徑點(diǎn)。這里不建議用setPosition硬跳加插值因?yàn)楣?jié)點(diǎn)多時(shí)tween鏈?zhǔn)角短缀茈y管理取消移動(dòng)時(shí)容易留下半截tween狀態(tài)。我采用的方案是每個(gè)部隊(duì)節(jié)點(diǎn)維護(hù)一個(gè)待走隊(duì)列每幀按固定速度移動(dòng)update(deltaTime: number) { if (this.pathQueue.length 0) return; const target this.pathQueue[0]; const currentPos this.node.position; const targetPos target.position; const dir targetPos.clone().subtract(currentPos); const distance dir.length(); const moveStep this.moveSpeed * deltaTime; if (distance moveStep) { this.node.setPosition(targetPos); this.pathQueue.shift(); if (this.pathQueue.length 0) { this.onArrive(); } return; } dir.normalize(); this.node.setPosition(currentPos.clone().add(dir.multiplyScalar(moveStep))); }移動(dòng)速度的單位是像素每秒需要根據(jù)地格外接圓半徑來標(biāo)定。例如外接圓半徑32像素一格的實(shí)際寬度約48像素那么部隊(duì)速度如果定在120像素每秒大約相當(dāng)于每2.5秒過一格。三國志戰(zhàn)略版中部隊(duì)行軍有急行和普通之分按下加速按鈕時(shí)速度可以翻幾倍直接用這個(gè)變量控制就行。5.3 軍隊(duì)單位與地塊歸屬邏輯行軍節(jié)點(diǎn)到達(dá)目標(biāo)地塊后需要更新地塊歸屬。地塊數(shù)據(jù)里維護(hù)ownerId字段初始為空部隊(duì)到達(dá)后寫入部隊(duì)所屬玩家ID。地塊歸屬對城池類型尤為重要因?yàn)榈貓D上的資源收益、視野范圍、出兵點(diǎn)全部圍繞歸屬判斷展開。在我的實(shí)現(xiàn)里領(lǐng)土擴(kuò)張的邏輯簡單粗暴部隊(duì)到達(dá)目標(biāo)地塊如果地塊屬于無主狀態(tài)且不越過國界限制這塊地就歸部隊(duì)所屬方如果是敵對方的地則觸發(fā)戰(zhàn)斗流程。要做成三戰(zhàn)那種完整的內(nèi)政玩法還有很遠(yuǎn)的距離但從地塊數(shù)據(jù)結(jié)構(gòu)來說ownerId字段具備擴(kuò)展所有玩法的基礎(chǔ)能力。5.4 箭頭指引與連續(xù)行軍玩家在三國志戰(zhàn)略版中常看到行軍路線是帶有箭頭的虛線路徑。實(shí)現(xiàn)這個(gè)效果的常見方式是沿路徑每間隔一段距離放置一個(gè)箭頭Sprite箭頭方向與當(dāng)前段路徑方向一致。方向計(jì)算就是當(dāng)前點(diǎn)到下一個(gè)點(diǎn)的向量把Sprite的rotation設(shè)置成該向量的夾角即可。多段連續(xù)行軍——比如玩家設(shè)定了途經(jīng)多個(gè)標(biāo)記點(diǎn)的路線——本質(zhì)就是把多段路徑拼接成一個(gè)大隊(duì)列部隊(duì)走完一段自動(dòng)加載下一段。注意每段路徑的連接點(diǎn)要消除重復(fù)節(jié)點(diǎn)避免部隊(duì)在某格停留一幀造成視覺停頓。6. 性能優(yōu)化與大地圖分塊加載策略地圖從40x30的小演示圖擴(kuò)到160x120的大世界圖節(jié)點(diǎn)數(shù)量會(huì)從1200暴增到19200。全量生成在PC編輯器上還能跑手機(jī)上大概率直接閃退。所以性能優(yōu)化這一步躲不掉得從生成和渲染兩個(gè)維度入手。6.1 對象池復(fù)用地圖滾動(dòng)、地塊狀態(tài)變化時(shí)會(huì)頻繁創(chuàng)建和銷毀地塊節(jié)點(diǎn)或特效節(jié)點(diǎn)。Cocos Creator內(nèi)置的NodePool用起來很簡單在初始化時(shí)預(yù)創(chuàng)建一批節(jié)點(diǎn)需要時(shí)從池中取出用完歸還。它解決的問題是避免每個(gè)地塊都走一遍instantiate流程。instantiate確實(shí)會(huì)比直接從池里拿慢一個(gè)數(shù)量級。在移動(dòng)端上慢就是卡卡就是玩家流失。6.2 可視區(qū)域裁剪大地圖實(shí)際出現(xiàn)在屏幕上的地塊數(shù)量很少。以1080p手機(jī)屏幕為例六邊形半徑32像素時(shí)屏幕大約只容納40-50個(gè)地塊。如果地圖有一萬多個(gè)地塊節(jié)點(diǎn)而屏幕只顯示50個(gè)剩下九千多個(gè)節(jié)點(diǎn)純屬浪費(fèi)。裁剪邏輯是根據(jù)屏幕可視范圍的四角坐標(biāo)反算出覆蓋的地塊行列范圍只實(shí)例化這個(gè)范圍內(nèi)的地塊節(jié)點(diǎn)滾動(dòng)時(shí)動(dòng)態(tài)增刪邊緣節(jié)點(diǎn)。這個(gè)實(shí)現(xiàn)的關(guān)鍵是縮小時(shí)能處理跨頁加載的連貫性避免地圖滾動(dòng)時(shí)出現(xiàn)邊緣空白。我實(shí)現(xiàn)了一個(gè)簡化版的分塊加載updateVisibleCells() { const visibleRect this.getVisibleHexRange(); const newVisibleKeys new Setstring(); for (let row visibleRect.minRow; row visibleRect.maxRow; row) { for (let col visibleRect.minCol; col visibleRect.maxCol; col) { const key ${row}_${col}; newVisibleKeys.add(key); if (!this.gridMap.has(key)) { this.loadCell(row, col); } } } for (const [key, node] of this.gridMap) { if (!newVisibleKeys.has(key)) { this.gridMap.delete(key); this.recycleCell(key, node); } } }這段代碼放在地圖容器的update里每幀調(diào)用或每若干幀調(diào)用。需要注意移動(dòng)速度極快、或玩家快速縮放時(shí)visibleRect的擴(kuò)張速度要留有余量比如在計(jì)算結(jié)果上擴(kuò)展兩格以免玩家看到彈現(xiàn)的邊緣。6.3 合并渲染批次六邊形底圖大量使用同一張紋理時(shí)可以開啟Cocos的自動(dòng)合圖。具體做法是把所有地塊底圖紋理打包進(jìn)同一個(gè)圖集節(jié)點(diǎn)渲染使用同一個(gè)材質(zhì)這樣Cocos的2D渲染器能自動(dòng)合并渲染批次。實(shí)際效果上40個(gè)可見地塊如果全部同一紋理同一材質(zhì)渲染批次可以合并到極低數(shù)量。但如果地塊類型多樣紋理至少五六種批次就會(huì)成倍增加。優(yōu)化方向是按地塊類型分組渲染同一類型的相鄰單元格天然可以合并批次。另外陰影、高亮、路徑箭頭這些疊加特效節(jié)點(diǎn)盡量使用不加光照的簡單Sprite材質(zhì)避免引入透明排序問題。透明物體的渲染排序會(huì)打斷合批兩三個(gè)重疊的透明特效可能就讓批次從幾十飆升到幾百。6.4 懶加載與預(yù)加載的配合玩家打開大地圖的第一眼需要看到完整地圖框架全部地塊可以只顯示底圖色彩不加載詳細(xì)裝飾。當(dāng)玩家拉近縮放時(shí)再動(dòng)態(tài)加載裝飾細(xì)節(jié)層。這種兩級加載策略適合地圖元素多、文件體量大的情況。我實(shí)際用的思路是地塊節(jié)點(diǎn)只掛一個(gè)底圖Sprite和地塊類型數(shù)據(jù)裝飾元素樹、石頭、房屋模型由裝飾管理器統(tǒng)一管理裝飾節(jié)點(diǎn)放在一個(gè)單獨(dú)的DecorationLayer容器下只有當(dāng)?shù)貕K處于近距離范圍內(nèi)才創(chuàng)建。這樣遠(yuǎn)景時(shí)地圖干凈流暢拉近時(shí)才豐富起來視覺體感并不突兀。7. 常見問題與排查技巧實(shí)錄最終這節(jié)說幾個(gè)真實(shí)開發(fā)過程中踩過的坑。問題不難但排查過程周折寫出來可以幫后來者省幾天時(shí)間。7.1 坐標(biāo)錯(cuò)位、格子偏移的排查現(xiàn)象是地圖上一列列六邊形歪歪扭扭或者部分行列重疊。排查思路先確認(rèn)Prefab錨點(diǎn)是否居中。錨點(diǎn)偏移時(shí)代碼里計(jì)算的是中心坐標(biāo)實(shí)際渲染的卻是偏移后的位置奇數(shù)行尤其明顯?？梢杂肅ocos編輯器打開六邊形Prefab選中根節(jié)點(diǎn)看錨點(diǎn)數(shù)值。如果錨點(diǎn)正確再查offsetX的計(jì)算。奇偶行交替偏移時(shí)偏移值必須等于六邊形內(nèi)切圓半徑的一半?yún)^(qū)域也就是size * cos(30度)約0.866倍。我見過有人拿外接圓半徑代替內(nèi)切圓半徑做偏移結(jié)果偏移量過大格子之間出現(xiàn)明顯縫隙或重疊。最后再確認(rèn)行方向是Y正還是Y負(fù)。不同教材里六邊形網(wǎng)格Y軸方向定義容易混如果代碼里用了別人的坐標(biāo)轉(zhuǎn)換公式但自己的Y軸是反的整個(gè)地圖看起來像被壓縮或拉伸了。用一對坐標(biāo)手動(dòng)計(jì)算比如(q2, r3)的中心位置再對比實(shí)際節(jié)點(diǎn)位置就能快速定位。7.2 尋路卡死或路徑不合理的排查A*尋路最怕兩種表現(xiàn)。一種是指向目標(biāo)永遠(yuǎn)找不到路徑表現(xiàn)為隊(duì)伍一直原地轉(zhuǎn)圈另一種是走出來的路徑明顯繞路。第一種情況優(yōu)先檢查阻擋表。如果目標(biāo)地塊本身被標(biāo)成不可通行A*一開始就走不到。三國志戰(zhàn)略版里軍隊(duì)不能進(jìn)入敵方城池所在格這類規(guī)則要放在walkableSet判斷時(shí)統(tǒng)一處理。另外檢查起點(diǎn)地塊如果起點(diǎn)就是不可通行的同樣會(huì)導(dǎo)致死循環(huán)或空路徑。第二種情況大概率是啟發(fā)函數(shù)設(shè)置問題。如果h值大于真實(shí)距離A*會(huì)變成貪心算法容易繞進(jìn)死胡同。正確做法是h 立方體距離真實(shí)距離嚴(yán)格等于立方體距離啟發(fā)值不會(huì)高估。如果用了曼哈頓距離那在六邊形上就會(huì)高估路徑就會(huì)變差。我最初犯的就是拿四邊形的曼哈頓距離套六邊形路徑真的歪七扭八。7.3 點(diǎn)擊地塊不準(zhǔn)的排查點(diǎn)擊不準(zhǔn)通常不是事件問題而是坐標(biāo)反算的精度問題。先檢查反算時(shí)用的是不是縮放后的節(jié)點(diǎn)坐標(biāo)。如果地圖容器縮放為1.2倍反算公式仍然按照1.0倍計(jì)算點(diǎn)擊點(diǎn)會(huì)集體偏移約20%。oK的指標(biāo)是第一下點(diǎn)擊選中正確地塊如果在邊緣地塊反復(fù)測試仍偏移基本就是這個(gè)原因。其次是浮點(diǎn)數(shù)四舍五入的問題。之前明確說過軸向坐標(biāo)反算出的浮點(diǎn)數(shù)不能直接四舍五入到行列而應(yīng)該先轉(zhuǎn)立方體坐標(biāo)再圓整。邊緣地帶的浮點(diǎn)坐標(biāo)在幾個(gè)格子的邊界線上直接四舍五入很容易選到錯(cuò)誤格子。7.4 大地圖滾動(dòng)掉幀的排查滾動(dòng)掉幀大概率是節(jié)點(diǎn)過多。先看看場景樹里總節(jié)點(diǎn)數(shù)如果超過幾千檢查可視區(qū)域裁剪是否生效。注意一個(gè)問題裁剪邏輯不能只在地圖停止?jié)L動(dòng)時(shí)執(zhí)行每幀滾動(dòng)過程中都要執(zhí)行否則快速拖動(dòng)時(shí)邊緣空白會(huì)非常明顯。如果裁剪沒生效再查渲染批次。打開Cocos的Stats面板看DrawCall數(shù)量。如果DrawCall在幾百級別多半是透明特效節(jié)點(diǎn)或獨(dú)立紋理造成的。把紋理合進(jìn)圖集、統(tǒng)一材質(zhì)后DrawCall應(yīng)該能壓到幾十。還有一類情況是主線程CPU占用過高這通常來自路徑計(jì)算或坐標(biāo)轉(zhuǎn)換里的巨大循環(huán)。找到熱點(diǎn)函數(shù)把sort替換成二叉堆或者對計(jì)算結(jié)果做緩存重復(fù)點(diǎn)擊同一目標(biāo)時(shí)不用重新計(jì)算。8. 擴(kuò)展從靜態(tài)地圖到完整SLG玩法框架完成基礎(chǔ)六邊形地圖之后可以往上疊加更多玩法。這個(gè)部分給出一些后續(xù)擴(kuò)展的方向不寫完整代碼但把關(guān)鍵思路擺出來。8.1 視野迷霧系統(tǒng)SLG大地圖最大的體驗(yàn)點(diǎn)之一是戰(zhàn)爭迷霧。玩家只能看到己方城池和部隊(duì)周圍一定半徑內(nèi)的地塊詳情遠(yuǎn)方地形模糊或不可見。實(shí)現(xiàn)思路是每塊地維護(hù)一個(gè)visibility狀態(tài)可見、探索過、未探索。地塊渲染時(shí)根據(jù)狀態(tài)選擇不同紋理的遮罩層——未探索的格子只顯示深色底圖探索過但當(dāng)前不可見的格子顯示灰度地形。視野更新的觸發(fā)源是城池和部隊(duì)的視野半徑。部隊(duì)移動(dòng)時(shí)沿路徑每一格執(zhí)行一次“點(diǎn)亮半徑范圍內(nèi)地塊”的遍歷。注意這個(gè)遍歷要在路徑計(jì)算之后執(zhí)行不能在移動(dòng)過程中逐幀遍歷否則每幀都要處理上百個(gè)地塊的可見性更新幀率會(huì)掉。迷霧數(shù)據(jù)同樣放在地塊數(shù)據(jù)數(shù)組里不依賴節(jié)點(diǎn)。這樣當(dāng)區(qū)域裁剪重新加載地塊節(jié)點(diǎn)時(shí)迷霧狀態(tài)依然正確。8.2 城池建筑與地塊綁定城池不是一個(gè)簡單的地塊而是一個(gè)包含多個(gè)建筑槽的復(fù)雜地塊。落地做法是地塊數(shù)據(jù)里增加一個(gè)cityData字段記錄建筑列表、等級、當(dāng)前升級進(jìn)度等。地塊節(jié)點(diǎn)在渲染時(shí)根據(jù)cityData生成對應(yīng)的建筑子節(jié)點(diǎn)。城池的升級、拆除、重建都通過修改cityData并刷新節(jié)點(diǎn)表現(xiàn)來完成渲染層和生產(chǎn)數(shù)據(jù)層完全解耦。這樣城池建筑類型再多地圖底層邏輯也不會(huì)失控。8.3 多軍團(tuán)協(xié)同與戰(zhàn)斗表現(xiàn)有多個(gè)部隊(duì)單位后需要一套部隊(duì)調(diào)度系統(tǒng)。每只部隊(duì)是一個(gè)Unit節(jié)點(diǎn)記錄所屬地塊位置、目標(biāo)地塊、行軍路徑、當(dāng)前狀態(tài)。多個(gè)軍團(tuán)并行行動(dòng)時(shí)更新邏輯循環(huán)遍歷所有部隊(duì)節(jié)點(diǎn)每個(gè)部隊(duì)獨(dú)立走自己的路徑隊(duì)列。戰(zhàn)斗表現(xiàn)方面兩支部隊(duì)在同一地塊相遇時(shí)可以播放一個(gè)戰(zhàn)斗動(dòng)畫。前期最穩(wěn)的表現(xiàn)方式是生成一個(gè)戰(zhàn)斗特效Prefab播放完成后銷毀本質(zhì)上不改變地塊歸屬邏輯。等戰(zhàn)斗系統(tǒng)成熟了再把戰(zhàn)斗結(jié)算結(jié)果寫回地塊ownerId。8.4 移動(dòng)端的多點(diǎn)觸控適配SLG大地圖在手機(jī)上常需要雙指縮放和單指拖動(dòng)的組合手勢。Cocos的EventTouch支持多點(diǎn)觸控但代碼里必須區(qū)分主手指和輔助手勢。我的做法是觸摸開始時(shí)記錄第一根手指為位移操作檢測到第二根手指時(shí)停止位移進(jìn)入雙指縮放模式。雙指縮放的核心是計(jì)算兩根手指當(dāng)前距離與上一幀距離的比值作為縮放因子。當(dāng)手指抬起一根后另一根手指自動(dòng)接管位移操作。這個(gè)過程如果狀態(tài)機(jī)不清晰很容易出現(xiàn)“手指一拿開地圖猛跳一下”的bug用戶體驗(yàn)非常糟糕。9. 最終實(shí)踐建議六邊形大地圖這套系統(tǒng)所有模塊的單點(diǎn)難度都不高真正的復(fù)雜度來自模塊之間的數(shù)據(jù)流與狀態(tài)同步。坐標(biāo)轉(zhuǎn)換、尋路邏輯、渲染表現(xiàn)、交互判定任何一個(gè)環(huán)節(jié)的數(shù)據(jù)口徑不一致整套系統(tǒng)都會(huì)表現(xiàn)出詭異的問題。我個(gè)人的經(jīng)驗(yàn)是項(xiàng)目啟動(dòng)時(shí)必須立規(guī)矩所有地塊數(shù)據(jù)統(tǒng)一走工具模塊接口所有跨層訪問統(tǒng)一用偏移坐標(biāo)算法函數(shù)內(nèi)部才能自由使用立方體坐標(biāo)。團(tuán)隊(duì)協(xié)作時(shí)代碼評審重點(diǎn)盯坐標(biāo)轉(zhuǎn)換的調(diào)用凡是出現(xiàn)手寫數(shù)學(xué)公式替代接口函數(shù)的地方一律打回。這套紀(jì)律比任何炫酷的算法優(yōu)化都管用。另外一點(diǎn)不要一開始就追求完全體的大世界地圖。先用小尺寸地圖把玩法跑通地塊類型配齊交互手感調(diào)順再逐步增加地圖尺寸和視野迷霧。小地圖上暴露的邏輯問題比大地圖上隱藏的性能問題更容易定位和修復(fù)。如果你正在著手做SLG大地圖從這篇文章里的坐標(biāo)系統(tǒng)開始先跑通網(wǎng)格生成和地塊點(diǎn)擊高亮然后加尋路和行軍最后再做迷霧和分塊加載。每一步都有清晰的驗(yàn)證點(diǎn)按這個(gè)順序推進(jìn)大概率能繞開我當(dāng)年踩過的那些坑。