時空資料庫與 MMO RPG 設計
背景介紹
-
我們是 Clockwork Labs 公司，一個 40 人的遊戲工作室，正在開發一款名為 BitCraft Online 的大型多人線上角色扮演遊戲（MMORPG）。
-
BitCraft Online 是一個完全持久的單一世界 MMO，玩家可以編輯地形、建造建築物、砍伐樹木並建立整個社會。
遊戲特色
-
玩家建造的定居點：玩家可以在世界任何地方建造，例如建造海濱區域，還能看到深入背景的道路。
-
地形編輯：玩家可以建造坑洞等地形。
-
多人互動：有大量玩家在同一個地方一起工作，遊戲有各種裝備和升級方式，是一款長期進階的遊戲，類似 Runescape 和 Minecraft 的結合。
-
生存工藝：玩家可能會死亡，遊戲中有多種生物群落，地圖非常大。
-
Discord 社區：有很棒的 Discord 社區，玩家可以分享創作，例如將遊戲地圖製作成美麗的藝術作品。
為何選擇在資料庫中構建遊戲
-
起初，在資料庫中構建遊戲似乎很不理智，擔心速度太慢、不理解在資料庫中運行的真正含義以及是否可行。
-
但實際上，對於構建像 BitCraft 這樣完全持久和可編輯的世界，這可能是唯一合理的方式。
技術要求
-
單一物理世界：所有玩家都在同一個物理世界，因為可以編輯地形和建造建築物，所以所有人都需要看到這些變化。
-
大量同時在線玩家：可能有 10 萬同時在線玩家，同一區域需要有大約 1000 名玩家，以營造 MMO RPG 的感覺。
-
伺服器權威邏輯：需要處理複雜的權限，例如只有特定好友在特定健康狀態下才能打開箱子。
-
可編輯的角色和世界狀態：角色和世界狀態必須可編輯且持久，即使伺服器關閉也不會丟失。
-
交易的事務性：交易必須是事務性的，以避免物品重複。
-
實時互動：角色和世界的互動必須是實時的，例如戰鬥時健康和耐力的更新，以及攻擊樹木時的損害計算。
-
大量怪物：遊戲中需要有數千個怪物。
-
接近聊天：需要有接近聊天功能。
-
可管理的開發團隊：需要適合約 10 名開發人員的團隊進行開發。
傳統架構
-
組成部分：需要遊戲伺服器、遊戲客戶端、Web 伺服器、資料庫、部署方式以及可能的數據分析或聊天伺服器。
-
簡化架構：客戶端連接到遊戲伺服器，遊戲伺服器連接到資料庫，Web 伺服器也連接到資料庫。
-
遊戲伺服器狀態：有需要實時更新的臨時狀態和需要持久化並存儲在磁盤上的持久狀態，持久狀態需要與客戶端狀態同步。
-
問題：如果有其他進程（如 Web 伺服器）或同一遊戲伺服器中的其他線程同時寫入資料庫，會導致狀態不同步，這是計算機科學中最難的問題之一——分布式一致性，也涉及緩存失效問題。
-
解決方案：將遊戲伺服器狀態視為寫通緩存，確保所有人都從遊戲伺服器狀態讀取，所有寫入都通過遊戲伺服器轉發到資料庫。
遊戲伺服器循環
-
流程：處理玩家輸入、模擬 AI 和世界、向客戶端發布更改。
-
準備工作：優化數據布局以提高緩存效率，決定如何定期或有選擇地將數據存儲到資料庫，實現序列化和反序列化，實現消息協議和傳輸層，實現興趣區域廣播器，考慮多線程，實現身份驗證、多線程、數據分析、管理 API 和管理客戶端等。
遊戲客戶端
- 任務：在客戶端實現序列化和反序列化，連接傳輸層，實現消息協議，可能需要實現客戶端預測，不能存儲整個世界狀態，需要部署遊戲。
部署和擴展
-
部署：在開發中使用 Docker 運行，需要設置 AWS 帳戶和權限，部署到雲端時使用 Kubernetes，設置代理和網絡。
-
擴展：需要設置區域伺服器，每個區域伺服器擁有世界的一部分狀態，當玩家移動時，將其臨時和持久狀態發送到另一個區域，更新全局伺服器和代理伺服器。
傳統架構的問題
-
Kubernetes 複雜性：部署複雜，處理資料庫是一場噩夢。
-
數據庫同步問題：需要通過對象關係映射（ORM）處理，使用事務時需要小心，可能會出現一致性問題，多線程複雜，臨時狀態不是事務性的。
-
客戶端限制：只支持一種客戶端，難以調試伺服器狀態，沒有容錯能力。
新的方法
-
合併伺服器和資料庫：將資料庫轉換為實時資料庫，使其能夠運行程序代碼，或者將遊戲伺服器賦予 ACID 屬性（原子性、一致性、隔離性、持久性）和查詢引擎。
-
使用查詢同步客戶端：讓客戶端直接連接到資料庫並進行查詢，資料庫會實時發送更新，處理傳輸層、序列化格式、類型安全和代碼生成、興趣管理等。
-
簡化部署：資料庫是單個二進制文件，只需部署單個二進制文件並上傳邏輯到資料庫，資料庫會處理複製、容錯和代理。
擴展架構
- 節點和資料庫：有一組節點，每個節點上都有資料庫，資料庫會在節點之間路由，代理由資料庫處理，具有容錯能力，服務器更少，只有一個二進制文件，所有機器上都是對稱的。
演示
-
編寫和部署代碼：在 Spacetime DB 中，使用任何編譯為 WebAssembly 的語言編寫代碼，例如 Rust，編譯後上傳到資料庫作為存儲過程運行。
-
添加圓形：使用 add circles 函數向圓形表中添加圓形，圓形會在資料庫中移動。
-
實時更新：在不斷開客戶端的情況下，更新伺服器代碼以實現圓形碰撞，展示了在資料庫中實時更新遊戲邏輯的能力。
-
調試和日志：可以使用 SQL 查詢查看圓形的位置，查看日志了解物理模擬的性能。
內部工作原理
-
客戶端連接：客戶端連接到 HTTP 伺服器，HTTP 伺服器路由到適當的 WebAssembly 實例。
-
WebAssembly 實例：運行物理邏輯，與內存數據存儲交互，內存數據存儲存儲所有表的數據，單個索引查找速度快。
-
查詢引擎：運行 SQL，讀寫內存數據存儲，客戶端通過訂閱查詢與查詢引擎交互，查詢引擎實時評估訂閱查詢並發送數據變化的增量。
-
提交日志：存儲資料庫中所有事件的完整歷史，壓縮和存档日志，可截斷日志。
-
快照樹：將自上次快照以來更改的髒頁寫入文件，以便快速啟動。
-
同步提交：目前實現了同步提交關閉，未來計劃實現同步提交開啟，以增加延遲但不影響吞吐量。
-
代碼生成：可以從編譯為 WebAssembly 的模塊中提取模式信息，並為模塊生成不同的客戶端。
改進的工作流程
-
ECS 默認實現：內部頁面布局類似 ECS，ECS 可以視為關係模型的子集。
-
類型安全的 RPC：客戶端可以自動調用伺服器上的函數。
-
網絡、序列化和反序列化：由資料庫處理，目前使用 TCP 作為傳輸層，未來可能添加可靠 UDP。
-
消除 ORM：所有數據都持久化在資料庫中，遊戲開發人員無需考慮數據存儲。
-
多個客戶端：可以有代理在世界中重生樹木、更新玩家健康等。
-
簡單調試：可以使用 SQL 查詢遊戲狀態。
-
實時廣播：免費提供，並且可以進行多線程處理。
-
複製和容錯：資料庫會自動故障轉移到另一個副本。
-
簡單部署：只需一個命令即可部署。
-
原子性：所有還原器默認都是原子性的。
未來工作
-
更積極的多版本並發控制：允許並行處理多個事務，提高並發性。
-
放寬隔離屬性：根據需求放寬隔離約束，提高可擴展性。
-
倒帶和重放支持：存儲所有事務的完整歷史，實現倒帶和重放功能。
-
自動客戶端預測：在客戶端本地運行 Spacetime DB，實現自動客戶端預測。
結語
-
獨立 MMO RPG 的可能性：希望一兩個開發人員就能製作獨立的 MMO RPG，降低此類系統的複雜性。
-
重新認識資料庫：資料庫是一種思考方式，而不是特定的軟件，與數據導向設計密切相關，有大量研究成果可供借鑒。
-
程序內存作為資料庫：將程序內存視為資料庫，分離邏輯和物理表示，實現更靈活的設計。
-
數據導向設計的下一步：數據導向設計的下一步可能是資料庫導向設計，鼓勵在設計中更多地考慮資料庫。
問答環節
-
數據分析：計劃提供對提交日志的訪問，實現自動分析和儀表板構建器。
-
規模和成本：考慮伺服器端的物理計算和網絡更新，優化數據布局以提高緩存效率。
-
物理模擬和客戶端預測：在幀開始時讀取可能變化的狀態，幀結束時發布和寫入，未來可能在客戶端本地運行 Spacetime DB 實現自動客戶端預測。
-
支持和運營：需要認真對待資料庫管理，通過測試和擴展團隊來解決問題。
-
安全性：通過強制客戶端通過伺服器代碼進行變更、實現行級安全規則和速率限制來解決安全性問題。
-
多區域延遲：目前尚未處理多區域延遲，未來會解決。
最後呼籲
- 歡迎在會後交流，提供 200 美元的雲端積分供試用 Spacetime DB。