（接下來的內容，大部分都是純邏輯問題，與語言沒有多大關係。Go語言的作用就是利用它的語言特性，提供介面來應對變化）

世界場景搭建

• Cell伺服器

  拆出Cell服務，是業內公認的。MMO RPG最核心的玩法就在Cell上，是最吃CPU和最佔網絡頻寬的地方。只有把它拆出來，才有橫向擴充套件的可能。

• 何為世界

  為什麼突然來個這麼哲學的問題 = =|
  因為你看世界的角度不同，你的活法也不一樣 + +| (居然還是這麼的哲理)

  因為不同的世界，會有不同的後面章節的實現。如果能提前考慮這個問題，那麼有可能，讓你做的遊戲伺服器可以適配更多的具體應用。

• 房間集合即為世界

  你可能玩過《球球大作戰》、《貪吃蛇大作戰》、《射箭大作戰》。遊戲以房間為單位，背景是一片空地。通常人們是不會把這些遊戲歸類到MMO RPG遊戲中的。

  如果你能換個角度考慮問題的話，那麼一個個房間是不是等價於MMO RPG中的一個個副本，房間內的空地是不是等價於沒有障礙物的地圖呢。

  同時如果你仔細分析的話，還有更多相同的東西。比如 進入房間的流程和進入副本的流程；2者遊戲物件屬性同步的機制也可以是一樣的 等等。

  不同的地方在於，他們的 移動演算法、尋路演算法、AOI演算法可能是不一樣的，不同的玩法，會做不一樣的演算法實現

  這裡列舉這個例子，目的不是要 我們做世界場景構建時要相容這種遊戲型別。而是在開發這些功能時，應該要足夠的模組化，並提供開關設定。在我不需要它的時候，可以直接關閉它，不會汙染其他功能、程式碼。

  只有這樣才會讓引擎框架有更多的可用性、可插拔性。

• tile-based 的世界

  在 3D遊戲出現之前 都是這種 基於格子的世界。即使是現在，3D遊戲盛行，還是有非常多的遊戲服務端，採用這種方式來構建世界。原因就是對一些遊戲來說，它已經滿足了玩法的需求。且相關概念演算法比較成熟，資料容易獲得。

  應當合理的設計介面，如提供：

  onSceneCreate
  onSceneDestroy
  onEnterScene
  onLeaveScene

  這樣具體應用可以針對這些介面做些特殊的處理

• NavMesh 構成的世界

  目前貌似 go 相關的 NavMesh的資料不是很多。比如在github上搜索下，只有1個 4stars 的go 專案：

  另外一種可能，Go語言呼叫NavMesh DLL。暫不考慮。

  因此使用 Go語言開發遊戲服務端，先不考慮使用這種方式構建世界。

移動、尋路及同步

這裡假設，世界是 tile-based的世界。由於使用Go語言開發，正常來說需要復刻一次這些功能

• 移動及同步
  可以參考成熟專案的移動演算法，這裡羅列一些要點

  1. 保持2端在某個方向上的位移計算演算法一致
  2. 伺服器端每100毫秒更新移動物件。但不需要與客戶端做位置同步
  3. 伺服器端在移動物件 方向發生改變、或者速度發生改變時，則必須與客戶端同步
  4. 伺服器端每5秒可以主動同步一次客戶端
  5. astar演算法產生的點，都是方向不再一個方位上的，因此與上面的要點是完全統一的

  想要平滑的移動同步效果，客戶端也要針對可能出現的渲染、網路不穩定，做相應的優化措施。比如目前比較流行的，會把一個物件分成 資料部分 和 渲染部分， 讓渲染部分做插值追趕 數值部分。

• 提供介面
  如，

  onMoveStart
  onMoveStop
  onMoveDirChange
  onEnterColloction
  onLeaveColloction

AOI演算法實現

暫略，比較複雜

輔助功能介紹

• 自動構建（略）

• 單元測試

  首先需要養成 一個功能，需要寫好充足的測試用例 的習慣。它不僅能用於測試你程式碼的正確性；同時可以作為這個功能的例子教程

  Go語言 提供了一個 go test 機制，來定義用例丟擲錯誤。
  因此可以在自動構建上，最後去自動執行 單元測試。若單元測試不通過，必然 本次自動構建會失敗告終。自動構建可以通過郵件告知程式設計師

• 部署及監視

• 除錯演示
  應該提供非常編譯的除錯控制檯，方便服務端程式，在與客戶端聯調前，做好充足的除錯。
  同時，應該提供視覺化的伺服器端視窗工具。這樣即使脫離客戶端也可以把某個流程除錯完整。