server | v4 switch to v5  

Turn-based & Async. Games

異步遊戲可以像其他遊戲一樣用Photon Realtime建立。主要的區別是,伺服器端的設置被改變為存儲房間。它們可以被加載並在以後繼續進行。

Photon有一套特殊的功能,用於玩幾天或幾周的遊戲,而不是幾分鐘。需要一個外部網絡服務來保存房間的狀態。玩家可以在任何時候繼續遊戲,甚至以異步方式加入。

系統概述

在Photon Realtime中,一個應用程序可以與外部網絡服務相連接。 這個服務會被包裹起來,並由Photon伺服器用於特殊任務。 客戶端不需要直接與該服務進行通信。

Back To Top

網絡服務

保存、加載和列出數據是網絡服務的一項常見任務,所以讓Photon使用網絡服務來保存數據是有意義。

一旦在Dashboard的 "Webhooks "標簽中配置了網絡服務,它將以兩種方式被使用。 事件驅動的 "Webhooks "和客戶端行動驅動的 "WebRPC "和 "Event Forwarding"。

Back To Top

Webhooks

Photon Webhooks建立了保存和加載遊戲的網絡服務接口。 Photon會在需要時自動調用各個任務,因此客戶不需要處理這些任務。

Example: 當房間裡的所有玩家斷開連接時,就會保存房間狀態。

Photon將調用 "/GameClose" 並將狀態作為POST數據傳遞。

為了在你的主機上接收事件,根據你的需要配置你的掛鉤的路徑。 在你的dashboard 上的應用程序列表中,按照details鏈接,然後選擇Webhooks來設置您的配置。

{% endif %}

閱讀更多關於"Photon Webhooks"。

Back To Top

WebRPC

WebRPCs採用了Webhooks的理念,並將其開放給大家使用。 您可以編造您自己的操作(基本上是RPC)並在Web服務上調用它們。 來回傳遞參數和執行Web服務手稿由您決定。

Example: 在MemoryDemo中,我們使用WebRPC來獲取一個用戶先前玩過(並保存)的房間列表。 一個合適的手稿獲取用戶的ID並從數據庫中獲取列表。

要建立您自己的WebRPC,您需要在網絡服務上執行一個手稿。 手稿的路徑(減去Dashboard中配置的base-URL)定義了將在客戶端使用的WebRPC的名稱。 兩個方向的參數都必須以JSON格式傳遞。

閱讀更多關於"Photon WebRPCs"。

Back To Top

創建 "異步 "房間

一旦應用程序在Dashboard中被設置為 "IsPersistent",實際房間的創建方式與其他房間相同:通過操作 "創建房間"。 只是有一些更多的選項需要設置。

"異步 "房間會在所有玩家斷開連接的超時後自動持久化。 這個超時被稱為 "房間生存時間"(房間TTL)。 它可以由客戶端在創建房間時設置(見OpCreateRoom)。 一個最佳的實踐值是12秒。

要了解更多關於如何保存和加載房間的信息,請參考"房間持久性指南"

Back To Top

離開和結束房間

在 "異步 "遊戲中,斷開客戶端的連接或離開遊戲會將玩家標記為不活躍。 被標記為不活躍的玩家可以在以後返回。 如果需要,玩家可以明確地 "結束 "一個遊戲。 要做到這一點,請使用帶有合適參數值的離開操作。

Photon會列出一個房間裡所有活躍和不活躍的玩家,但是一旦有玩家結束遊戲,這個玩家在遊戲中就不再為人所知。 另外,在默認情況下,該玩家的所有事件和屬性都會被清理掉。

Back To Top

加載一個房間

要在任何房間繼續遊戲,您必須知道它的名字。 在客戶端,使用OpReJoinRoom(name)

從客戶端的角度來看,房間是否還在Photon的內存中或被加載並沒有什麼區別。 如果房間找不到了,或者房間裡的actor過期了,操作就會失敗。

要了解更多關於如何保存和加載房間的信息,請參考"Room Persistence Guide"

Back To Top

Getting A List Of Saved Rooms

演示手稿和伺服器手稿樣本為每個用戶ID維護一個在線房間列表。

我們的想法是使用"自定義認証 "來登錄一個用戶,然後獲取該用戶的房間列表。

閱讀更多關於"GetGameList WebRPC"。

Back To Top

保持遊戲狀態

當玩家重新加入一個房間時,它將獲得玩家的屬性(活躍和不活躍)和所有緩沖的事件。 有了這些數據,你應該能夠重現狀態並繼續遊戲。

Back To Top

屬性

您可以設置房間和玩家的屬性。 當您需要保留一個狀態而不是變化的歷史時,最好使用屬性。 您可以輕鬆地將局數的狀態和回合數保存為屬性。 任何玩家都可以設置房間屬性,所以異步輪流也不是問題。

當玩家結束遊戲(或超時)時,玩家屬性將被清理掉。

Back To Top

事件緩存

每個房間都有一個緩存,按需存儲事件。 緩存事件可以保持事件發生的順序,當您存儲的東西依賴於以前的行動或數據時,這是需要的。

默認情況下,事件不被緩存,但是OpRaiseEvent有一個參數可以控制事件的緩存。 像往常一樣發送事件,但使用EventCaching.AddToRoomCache來存儲它。

您也可以用EventCaching.RemoveFromRoomCache選項從緩存中刪除事件。 在這種情況下,eventCode、"sender actorNumber "和 "content "Hashtable被用來作為過濾器。 您可以刪除特定actor的事件、具有相同eventCode的所有事件或具有特定內容的事件。

如果您在發送事件的同時故意發送某種 "標簽",那麼按內容刪除事件就特別強大。 "MemoryDemo "在每個事件中發送一個 "回合",這被用來刪除舊回合的事件,這樣可以保持事件的歷史簡短(這又有利於加載一個長時間的遊戲)。

閱讀更多關於"緩存事件"。

Back To Top

事件轉發

除了緩存事件外,您還可以將其轉發到網絡服務。

同樣,客戶端的OpRaiseEvent使用WebFlags定義了一個事件是否應該作為GameEvent webhook轉發給網絡伺服器。

轉發的事件沒有回到遊戲中的方法,但對於追蹤一些遊戲中的動作和結果是很有用的。 這可以用來計算比賽的結果和調整用戶的ELO。

"MemoryDemo "並沒有利用這一點。

To Document Top