Photon Server SDK (Part 1) — Applications

已經把 Photon Server 安裝好了嗎? 想瞭解在 Server-Side 可以怎麼樣開發程式嗎? 如何將 SDK 中提供的 Base Class 擴展, 來架構符合我們自己需求的應用呢?

這一篇, 我們就來看看 Photon Server 簡單又強大的軟體架構吧 !! 😃🤖

Photon Server 的開發架構, 應用範例: MMO, Load Balancing (+Plugins), Hive (Lite)

基本概念

在 Photon Server 世界裡, 什麼是 Application 呢? 它可以用來做什麼? 而遊戲邏輯是寫在哪裡? 有哪些事件跟操作可以跟 Client 界接與通訊, 還有連線/斷線時的該如何管理等, 我們先來看看這些簡單的入門概念~ 😁👾

Applications 應用程式

對於連線遊戲架構來說, Application 是一種在 Server-Side 執行的程式邏輯 (Game Logic), 遊戲中的特制化功能, 像 RPC, Data Storing, Database 的功能等, 會是(並且也只會是)在 Photon Application 裡面實作的.

開發時, 用的是 C# , 原始碼在編譯後, 產出的 DLL 會被 Photon 的原生核心載入執行. Photon Core 會讀取設定檔 Configuration files, 在設定檔裡面用了一些定義好的標記與數值, 來編寫載入時的初始化與一些應用程式的相關參數.

通常, 在一個 Application 裡就會提供某一個遊戲裡的所有運作邏輯. 進階應用的話, Photon Server 的設計是可以在同時間跑多個 Applications, 所以我們可以為了不同目的, 而設計一些特殊化的工作項目(Task), 把它們分別作成不同的應用, 比如, 編寫一個只是針對 Web-Based 的連線請求(Client Request)而單純的送出 Policy Files 的功能而已, 若我們把它單獨分離出來成為一個應用, 還可以簡化連線設計的架構複雜度.

Game Logic 遊戲邏輯

遊戲邏輯, 也就是對於 Client 跟 Server 之間是如何的互相傳達資訊與功能, 實作出一些操作/事件/以及在 Server 上自己本身或是跟外部之間須要做的相關的事.

在 Photon Server 中, 所有的遊戲邏輯都是用 C# framework 來開發的, 程式的進入點也就是應用程式的類別, 有定義在 Photon.Socketserver.dll, 所以我們寫程式時會參考到它.

而 Photon server SDK 中提供的三個 Applications 即是用 C# 寫成的很好的範例框架, 有 Room-Based 以及 MMO 的應用, 稍後會再聊聊這些應用的各種面向.

Operations 操作

在 Photon 中, Operation 等同於 RPC (遠端程序呼叫), 所以 client 可以使用 operation call 來達成任何它們之間想要溝通傳達的事.

而其中的參數傳送, 可以定義在 server-side 的應用程式之中, 所以我們可以用 HashTable ( keys & values ) 來定義資料, Client 與 Server 的 framework 會自動的做好序列化, 傳送, 以及解序列的工作 (Serialization , Transfer and Deserialization).

每個 Operation Call 也能提供返回值(return result), 但這是一種單向的提供要求的資料給 Client, 但也可以不用提供返回值以節省網路頻寬. 每次的 Client 與 Server 間的操作呼叫, 是只有他們自己互相傳送訊息而已, 其它的 Client 並不會被通知或是參與傳送.

Events 事件

Photon Events 是對 Client 的一種訊息通知. 在 LoadBalancing Application 中已有定義了好幾種事件, 但相對的, 在 Client-Side 也可以自己設計定義一些事件來運用.

通常, 一個接收端收到的事件是由其它的發送端的操作呼叫(Operation Call), 也就是 Event 可能會在任何時侯產生(或是到達), 像 LoadBalancing 就會在某人加入、離開 Room 時, 傳送事件通知給那些在同個 Room 裡的人.

Connections & Timeouts 連結與逾時

Photon Engine 在傳送資料的網路底層用了改良過的 UDP, 稱之為 Reliable-UDP (R-UDP)

在發送端(Sender)傳出去的 R-UDP 的封包之中的命令(commands) 會有個序列號以及記號(flag), 而接收端(Receiver)必須回應這個訊號; 發送端的 R-UDP 會在很短的時間內重複的發送, 直到有一個相對的回應傳回到發送端才會停止. 若沒有收到回應, 那就會產生連線逾時.

若偵測到連線逾時, 那麼發送端就會斷掉這個連線. 若某一方判定另一方不再產生回應, 就不會再傳訊息過去, 也就會發生資訊無法同步了.


基本類型的應用程式 (Base Applications)

Photon Server SDK 裡面供了至少三種基本類型的應用程式, 有: 在一個單一並且巨大世界的多人遊戲架構 MMO App, 小型多量且獨立的空間(Room-Based)的遊戲架構 Lite App, 以及負責多層次遊戲伺服平台的工作負載分配等的 LoadBalancing App. 有了這些, 讓我們在初入門開發時就有好用又簡單的架構可以參考. 我們現在來看看吧~

LoadBalancing Application

這個應用範例與 Photon Cloud 本身內部運作的負載平衡, 在功能大致上是一樣的. 而它的組成包含了二個伺服器: Master Server, Game Server. 而這二個 Server 是互相協調運作的, 大致的功能如下:

  • Master Server 功能
    1.
    記錄著在 Game Servers 中, 哪些遊戲是當時有開放的.
    2. 記錄著在 Game Servers 中的所有工作負載情形, 並且分配新加入的 Peers (玩家) 到合適的遊戲伺服器上.
    3. 有一個 Lobby(遊戲大廳), 用來保持與更新可用的 rooms 的列表, 方便 Clients 連上時先行取得合適的資訊, 可以提示給 User 觀看.
    4. 幫連上的 Clients 配對找到合適的 Room, 例如用亂數的方式或是由某個名稱字串值來尋找, 並且把 Game Server 的位置傳回給它們( Clients).
  • Game Server 功能
    1.
    由 Lite(Hive) 的變種擴展而來, 主要是用來管理遊戲的 Rooms. 
    2. 定時的向上層 Master Server 回報它們現在的工作負載情形及目前能玩的遊戲的資訊列表.
Load Balancing 的基本設定

如上圖所示, 1 個 LoadBalancing App 在設定上是 Master Server 只會有 1個實體存在, 而 Game Server 可以分別執行很多次成為很多個實體( 1..n 個)的存在. 而且 Master Server 還可以跟跑在其它雲端平台上的 Game Server 串接, 或是分別在不同的電腦跑 LoadBalancing App , 就可以架構功能更強的多層次服務平台了! 超強大~👏🏻👻

LoadBalancing 可以跟其它 VM 上的 GameServer 串接
在 Photon 3 的 SDK 中, LoadBalancing App 是由 Lite 擴展而來;
在 Photon 4 的 SDK 中, LoadBalancing App 是由 Hive 擴展而來.

MMO Application

對於所有的玩家都在單一個巨大的世界中互動的遊戲, 這個範例應用是個很好的示範. 它提供了一些如 Actors / Items / Properties / Events 的基本類別與管理.

如果想要在伺服器端(Server Side) 寫些針對單一個遊戲世界中的某些項目有著共同的規則與邏輯, 像是怪物生成, 寶物掉落, 魔法泉, 重點區域, 以及互相間的特殊事件(Event)觸發某件事情之類的, 那麼參考這個範例是最好的開始, 這個範例提供如下圖的基本構成:

MMO Server Side : 單一世界, 多個區域, 物品管理, 資源管理, 重點區域

Lite (Hive) Application

Lite 的應用範例是從 Photon 3 SDK 就有提供, 對於瞭解 Photon 的基本概念是個很好的教材; 而 HivePhoton 4 SDK 開使提供的; 基本上二者是相同的, 但有些小地方有改良, 以目前的開發建議, 當然是直接用 Load Balancing 來開始擴展我們自己所須的架構會比較好.

那麼為何這個範例會叫做 Lite 呢?

  1. 因為從設計上來說, 它主要就是希望 Server-Side 的部份非常地輕量化;
  2. 在遊戲連線架構上, 像是計分(Scoring) 扣血(Damaging) 這種功能, 可能已經直接把 Server 做在某個特殊的 Client ( Photon 中稱之為 Master-Client) 裡面了. 所以可以不須要用 Server-Side Logic 來做;
  3. 並且, 這樣使得 Room Class 在 Lite 裡會顯得更容易瞭解, 就會更方便日後做擴展延伸了~

有了這些概念, 我們心裡對於 Photon Server 的軟體開發框架就有底了, 對於接下來看是要從 MMO App 之中, 學習或是擴展多人連線 RPG 設計; 亦或是想做些屬於自己專案的特規的 Room-Based Game Server, 就可以從 Hive App 學習到基本框架後, 再從 Load Balancing App 著手開始擴展囉!

😂👻👍