Unity中目前提供的基於Navmesh的網格尋路，如果僅僅是單機遊戲，其實功能還是能滿足的，當然，如果你做的是大規模兵海流的 rts遊戲，Unity的網格尋路還是會碰到多人尋路相互擠壓的問題。     由於我們目前的工作主要集中在手遊，而又以聯網RPG遊戲為主。由於Unity並未開源Navmesh尋路元件，而Navmesh其實上是開源尋路專案RecastNavigation的作者做的升級版本，自然而然，我們會嘗試在伺服器端整合RecastNavigation。進行此類工作的團隊很多，大概思路都是根據RecastNavigation要求，定製客戶端外掛，匯出客戶端網格資料。     不過很可惜的是，雖然大部分情況，客戶端和伺服器能做到尋路路徑統一，但是在一些特殊情況下，比如網格是一些特別細長的三角形，尋路路徑卻存在偏差，這幾乎是不能接受的。但是如果拋棄客戶端的尋路，把RecastNavigation匯出到客戶端，雖然能保障路徑統一，但是實際中行路及碰撞等圖形表現不是很好，畢竟Unity為尋路做了大量的工作。     之前的專案為了上線，大多采用了折中的方案： 方案１：在客戶端尋路併發送到伺服器，執行廣播。伺服器僅僅是驗證路徑是否合理。     方案２：客戶端自己根據Navmesh生成標準尋路格子，將客戶端尋路替換成基於格子的Ａ*尋路，去除單位碰撞。自己單獨處理跳躍點等情況，我曾經為此寫過一個Unity尋路外掛Navgrid。     上述2個方案其實上都不算完美，僅僅是可用而已。對大多數研發團隊來說就一勞永逸的方案，其實還是等待Unity能開放尋路演算法原始碼，畢竟Unity已經慢慢開放了不少底層元件的原始碼。不過由於專案需要（需要客戶端伺服器完全同步且要求碰撞處理），我一直在思考一種相對完善的方案，把格子尋路和網格尋路結合起來：     首先，基於Tile我們生成一份帶行走權重的二維導航資料。把起始點和終點轉換成Tile序號，我們讓尋路單元在Tile之間尋路。由於Tile足夠大，我們甚至不用做查詢後路徑的二次優化，而且這步尋路會足夠快。     其次，在到達終點所在Tile後，尋路轉換為精細尋路，伺服器切換為RecastNavigation，客戶端切換為Unity自帶尋路。由於在Tile內尋路，網格尋路路徑將極大簡化，基本上能保障路徑的一致性，就算是真的有偏差，由於整個尋路是在Tile內進行的，也不會偏差太多。下圖為大概的尋路路徑：