事隔兩年，又双叒叕重投樂園的開發

當年項目暫停之前正在研究KCP tunnel，目的是希望直接從底層開始建構－找出一個類TCP/UDP的protocol，可以結合兩者的優點然後再於其之上利用protobuf，在Golang及C#兩邊共享資源

然後就是沒有然後 😅

不過兩年後的今日再一次回看當年的決定，也覺得有點草率。原因在於開發的需求只是一個小眾向的遊戲，頂多都是兩三百人，然後對latency沒有多大的需求。今天再一次重新研究需求，希望能記錄選擇MMO服務器過程中的一點心得。

需求

最普通的MMO服務器通常都需要：

• 登入服務器/授權服務器
  • 用戶登記/注冊
  • 管理session
  • 加密協定(TLS)
• 世界服務器
  • chat
• 遊戲服務器
  • 遊戲邏輯
  • cache
• 數據庫
  • 保存用戶資訊

然後是一些進階要求：

• ❌ horizontal scaling
  • 預測最多只有一兩百人同時在線
  • 太複雜
• ❌ database sharding
  • 原因同上
• ❌ high throughput
  • 原因同上
• ✅ vertical scaling
  • 錢可以解決的問題…
• ✅ real time data streaming
  • 雖然樂園並不需要太即時，但polling中間的等侯時間並不能接受
• ✅ Golang寫的
  • 沒錯除了Golang以外的都不考慮😀
    • 並不相信nodejs的底層支援
    • c#不熟悉
    • java太舊
    • c++太容易出錯

選擇

綜合以上的幾點，然後就花時間Google了一些framework:

Nakama

• monolith
• 支援postgres/psql write compatible database
• 提介web管理介面
• docker ready
• gRPC/TCP/UDP support
• unity/c# client side support

Agones

• 比較像管理game server的軟體?
• kubernetes ready

Leaf

• 貌似暫停更新了

Photon

• 很多人用
• 貴

Leaf兩年前我應該有看過，但由於沒有再更新就不予考慮了。Agones比較像是遊戲服務器的管理－ 讓你可以自由scale/deploy 服務器，重點是這需要一個kubernetes cluster :D Photon要錢的就算了🤷‍♂️

Nakama需然是monolith，但benchmark看起來不錯－ 1vCPU／3GB Ram可以跑近兩萬玩家，然後各種配套也很齊存。

如無意思接下來就是花時間試跑一下Nakama了

---