原文請參照以下部落格
Dev Story: Das Tal’s Backend & Exit Games’ Photon
這篇嘉賓帖子由獨立工作室Fairytale Distillery的“ Das Tal”技術總監兼開發人員Sebastian Dorda撰寫。
“ Das Tal”是一種快節奏的沙盒MMORPG，專注於玩家互動。 Full Loot和Open PvP創建了一個“風險與回報”的遊戲，您需要權衡選擇權，然後再與其他人進行互動。
PvP從未受到限制，但合作總是需要回報。 每個世界的功能集和地理位置都是獨一無二的-您可以選擇這些功能！ 帶時間限制的服務器可創造贏家和輸家，並讓您定期重新開始。 無類角色系統可讓您塑造角色以適應您的遊戲風格。 您在爭奪資源以製造設備並建立解決方案。 PvP戰鬥是100％基於技能的，常見且快速發現的。 小規模的衝突和大規模的圍攻都可以在任何時候提供給所有玩家。
有興趣的夥伴請註冊成為Das Tal的Alpha測試人員哦。
這次主題是後端。 我將概述我們的基礎結構，並更詳細地介紹基於Photon Server的遊戲服務器。
請注意，這只是我們的操作方式。 如果您對此有任何意見或評論，我們將很高興收到您的來信。
遊戲設計的一些背景
遊戲經過精心設計，有許多小型的孤立遊戲世界。 註冊人數為1000到2000，並且100到200個CCU（同時連綫玩家）連接到一個世界。 這種規模的原因是為了給世界定時間，並建立一個親密的用戶社區（在一個世界之內），以最大程度地減少技術複雜性。
遊戲的核心是極高的速度和簡單的遊戲。
換句話說，處於一堆Counterstrike服務器和“經典” WoW式MMORPG結構之間的中間位置，該結構具有由連接實例組成的龐大世界。 這是一個玩法示例：
基礎架構配置
這是與遊戲的實時操作或其開發相關的服務的概述。 大多數服務已經啟動並運行，儘管其中只有一部分是虛擬的。
Live環境
- 帳戶管理（REST）
- 在遊戲世界中生存的信息（名稱，成就等）（REST）
- 遊戲世界清單（REST）
- 地圖文件存儲（HTTP，FTP）
- 修補程序/客戶端文件（HTTP，FTP）
- 遊戲服務器（Photon Server）
- 客戶端（Unity）
- 數據收集（Graphite）
- 跟踪（Honeytracks，Piwik，Google Analytics（分析））
- 監控（icinga2）
- 網站（Tumblr，web）
- 論壇（web）
- 備用（Bacula）
- 通訊（Mailchimp）
開發者環境
- 構建/連續集成/部署服務器（Jenkins）
- 問題追踪器（Hansoft）
- 版本控制（Git / Gitlab）
- 內部文件共享（Seafile）
這些服務大多數都非常易於使用，並且已在大多數基於MMO的遊戲中使用。
遊戲服務器
所有服務都很重要，但核心是遊戲服務器。 經過各種審查，我決定使用Photon Server。 主要原因是代碼快速且製作精良，因此我可以簡單地在服務器和客戶端之間共享代碼(C＃)。 我簡短地寫了關於在操作之前進行評估的遊戲中間件。
概觀
我們的遊戲服務器是一個完整的權威服務器(authorative server)。遊戲循環（模擬）的核心部分以大約15 ticks / s的速度運行。由於多線程非常困難，因此我們決定將游戲循環的核心部分限制為1個線程。
設計和維護單線程遊戲循環要容易得多。例如，由於高負載，未知計時錯誤（重複項等）較少。
不利的一面是，由於遊戲循環的核心部分沒有水平擴展，因此無法擴展一個遊戲世界。但這並不重要，因為遊戲世界本應該很小。
其他事情，例如網絡IO，外部服務的調用，長期運行的計算（路線搜索），世界數據的存儲等，是由不同的線程執行的。實際上，所有這些都是使用光子內部的Fiber結構作為Fiber完成的。
我正在使用2D網格索引進行客戶興趣管理(client interest management)。 這對於將流量和CPU負載減少到可管理的水平是必要的。
遊戲玩法基於Artemis的實體系統框架，並使用Farseer進行碰撞和移動。
對於客戶端和服務器之間的小消息，僅使用Photon自己的序列化（基本數據格式的鍵值列表），更大，更複雜的數據由protobuf序列化並編碼為Photon協議的字節數組。
遊戲狀態存儲在內存中。 因此，您要做的就是使用protobuf完全序列化並將其保存到文件中。 這是可行的，因為每個世界都很小且有時間限制，因此它不會呈指數增長。
建議：在用protobuf編碼的文件旁邊，將游戲的完整狀態轉儲到單個大型YAML文件中。 這樣，您可以簡單地使用文本編輯器檢查遊戲的狀態。 不需要其他工具。
所有日誌記錄都是通過Photon Server中包含的log4net完成的。 我們使用的IoC容器是Windsor。
單元測試的設置基於使用Visual Studio Unit Testing Framework的Photon MMO演示案例的設置。
Peer & service interaction
Peer代表連接的客戶端，並充當與播放器進行通信的網關。 每個Peer都有一個處理傳入和傳出消息的光纖，每個Peer分別存在。
不同的Peer之間的通信是通過服務完成的。 例如，驗證完成後，Peer向聊天服務註冊以發送和接收聊天消息。
peesr具有一個協議狀態對象，該對象表示協議的當前狀態。 因此，當客戶端連接到遊戲並參與遊戲時，將按以下順序（客戶端角度）執行遊戲。
1.驗證客戶端版本和服務器版本匹配
2.登錄並授權客戶端（使用帳戶服務）
3.選擇一個字符（使用帳戶服務）
4.從服務器獲取技能定義和其他全局平衡值（使用平衡文件，技能定義服務）
5.獲取從外部服務器下載靜態地圖數據所需的地圖信息（下載URL，hash）（使用地圖存儲服務）
6.下載靜態地圖（如果它們尚未出現在客戶端上並且hash匹配）（不使用遊戲服務器）
7.實例化地圖（不使用遊戲服務器）
8.進入遊戲（使用遊戲服務）
遊戲服務
遊戲服務運行遊戲循環核心部分的纖維。 它是遊戲內（作為遊戲光纖）和遊戲外之間的門戶。 當對等方加入遊戲時，由gameService.Enter輸入。
“ gameService.OperationBodyMovement（對等運動）”。 所有這些命令在遊戲循環光纖中整列，並在Ticks間執行（計算遊戲模擬的一個步驟）。
遊戲服務的另一項工作是快照當前遊戲狀態（同步），並將其移交給地圖存儲服務，該地圖存儲服務對狀態進行序列化和存儲（異步）
遊戲循環的核心部分
此代碼段顯示瞭如何在遊戲服務中調用tick方法。
遊戲循環的核心是Artemis實體系統。與實體系統交互的所有代碼都在客戶端和服務器之間共享（處理遊戲網絡同步的系統除外）。
這是為了允許客戶端根據需要使用相同的數據結構和方法。當前，客戶端僅使用共享遊戲代碼的數據結構和部分檢查方法。 Artemis包括用於各種遊戲部件的系統（例如，用於HP和能量再生的ASCharacterRegs，用於投射技能的ASCharacterCast等）。
ASFarseer是一個非常重要的系統。使用Farseer庫計算碰撞和運動。
ASSpatialIndex系統包含基於網格的各種空間索引，這對於有效的客戶興趣管理是必需的。還有一個特殊的網格索引來處理腳步聲（以防止腳步聲變滿）。
ASNetwork（在圖中稱為“遊戲網絡傳出”）將所有遊戲狀態與客戶端同步。該組件可以訪問遊戲服務中所有當前活動的對等實例。
以下序列顯示了組件與以下示例的交互。
示例：玩家移動角色，結果顯示在屏幕上。
- 客戶端發送操作消息。
- 對等方收到操作消息。
- 對等方的遊戲內狀態會處理該消息，並將其發送到遊戲服務。
- 在完成當前tick之後，遊戲服務將處理動作命令並與受影響的實體計劃動作。
- 在下一個遊戲“tick”中，ASFarseer系統將模擬所有實體的行為。
- tick結束時，ASNetwork系統將ACK消息發送到已處理的輸入消息。
- 另外，ASNetwork系統（使用網格）將關聯位置的更新發送到活動對等方。
- 客戶端將本地預測位置調整為目標位置。
本章到此爲止。 如果您對執行方法有任何疑問或意見，請聯繫sebi@fairydist.com
評論
0 條評論
請登入寫評論。