Photon服務器新手問題

Question

我已經在官方Photon服務器論壇上提出這個問題，但它不如本網站活躍，所以可能有人理解我在說什麼，所以請，如果你有時間和知識， 分享它。謝謝！

這裏來......

所以，我已經有了一個光子服務器和會談到服務器的基本Unity3D客戶的一個很好的工作原型。 它是從cjrgaming的例子構建的。

客戶端可以：連接，發送請求，建立和發送加密的請求 服務器可以：創建同行，收到操作請求，發送操作響應或事件給客戶端，還有，我的小加： 如果遊戲有很多操作，你不必使用巨大的switch case語句，而是將操作劃分爲類（Classes），並使用委託和字典調用它們。

我會發佈一個工作示例，當我覺得它已準備好發佈，但現在，我的實際問題..（對不起，長的職位，我不得不解釋我知道什麼，我有什麼遠）：

究竟是從客戶端發送到服務器的操作是什麼？ 或服務器向客戶端（所有客戶端？）提出的事件？

起初，我在想每個操作都是遊戲中的特定用戶流程。例如，操作代碼「1」意味着玩家X想要拍攝玩家Y，做一些事情。 但是後來我意識到，你不能把所有的遊戲邏輯都放在255個操作中，按字節限制，而不能將它擴展到short int或其他東西。

然後我發現有一個channelID，它可以在相同的操作代碼請求上有所不同...這對我來說意味着操作代碼不是用戶流，而是具有相同/客戶端和服務器之間的類似操作，以及channelID可用於區分要在服務器上計算的請求操作。

然後...！我意識到（哦虛設箱），即有在字典中，這增加了可能的用戶流的另一層從客戶端發送到服務器，反之亦然參數。

所以..現在我想理解事情，但他們只是更困惑我。

任何人都可以簡要解釋操作/事件/ channelID的目的嗎？例如，如果你做一個小型的多人遊戲，你將用什麼來製作用戶（遊戲）流，例如 - >玩家擊中目標，玩家拿起世界中的物品，玩家發送消息。你會爲每一個流使用唯一的操作代碼，還是按意義對操作進行分組，並使用通道來區分請求，或者甚至在這裏，您爲許多用戶流使用相同的channelID，並通過某些ID內部參數來區分它們？

希望我有任何意義。

非常感謝各位傢伙，至少，時間，如果有任何幫助！

Answer 1

1） 通道是一個完全不同的主題，並沒有任何做不同類型的遊戲邏輯的區分，要觸發。相反，如果一個操作取決於另一個操作，則確定優先級和狀態。

a） 如果您發送拍攝操作和2個聊天操作，並且由於客戶端的網絡連接不是最好的，第一個聊天消息在路上會丟失，但作爲你已經聲明要可靠地發送它，Photon客戶端將自動重新發送，當服務器沒有確認時，它已經收到它。現在，另一個聊天消息應該由Photon阻止，直到第一個聊天消息可以成功發送，否則來自同一作者的所顯示的聊天消息的順序將不再是它們已被寫入的消息順序。現在的問題是，不僅應該阻止相同類型的操作，而且可能還有其他操作，只有在重複丟失的操作後才能發送其他操作（例如，「用戶可見結果」離開聊天「操作不應顯示在屏幕上，直到他上次聊天消息之後，他在離開前發送）。另一方面，並​​非所有相同類型的操作都必須被阻止。例如，玩家可以私密地與2個不同的其他用戶交談，並且當其中一個人的一條消息不能立即通過時，則沒有理由將所有消息保留給另一個。對這個問題的光子解決方案是通道：在相同的通道中發送所有相互依賴的操作，但在另一個通道中發送獨立於它們的操作。如果現在需要重複其中一個操作，則在其他頻道中的操作不會被阻止，而是在同一頻道中的操作將會被阻止。

b） 通道的另一種方式是確定優先級：通道ID越低，優先級越高。因此，如果您擁有少量優先級較低的數據和其他數據，但優先級較低，但可能會出現大量數據，那麼在低通道上發送高優先級數據將是一個好主意信道ID。這樣它仍然會立即離開，儘管在具有較高ID的信道中可能有很多數據已經排隊等待發送，但還沒有被髮送出去。

2） 操作和事件都是消息。實際上有三種類型的消息：operationRequest，operationResponse和event。

a） 客戶端可以通過PhotonPeer.opCustom（）向服務器發送帶有特定操作代碼的operationRequest。一些典型的操作，例如加入和離開房間，已經由Photon應用層的應用程序（如Lite或LoadBalancing應用程序）實現。如果爲Photon應用程序提供了客戶端API，則此API可以提供像opJoin（）這樣的功能，將opCustom（）的正確參數包含在調用中，就像上述應用程序的客戶端API一樣做。

b） 根據在應用程序級別上如何實現具有特定代碼的操作，服務器可能會向客戶端發送一個operationResponse，從該客戶端收到operationReqeust。例如，LitePeer.opJoin（）將觸發來自服務器的加入響應，但LitePeer.opRaiseEvent不會觸發響應。

c） 根據在應用程序級別上執行操作的方式，服務器可能會或可能不會將事件發送到某些客戶端。例如，LitePeer.opJoin（）將觸發一個加入事件，該事件將被髮送給該房間中的所有玩家。 LitePeer.opRaiseEvent（）默認情況下讓服務器發送一個事件，該事件持有有效負載，並且已傳遞給它，用於同一個房間中除發送消息之外的所有客戶端。然而，opRaiseEvent（）爲其呼叫客戶端提供指定接收客戶端的可能性。

3） 「一個球員擊中目標，玩家在世界上拿起一個項目，玩家發送消息」 如果你需要爲這些任何特殊的服務器端邏輯，那麼你會實現它們與不同的自己的操作碼。如果情況並非如此，那麼您將使用opRaiseEvent（）發送這些信息，但您仍然會爲這三個事件中的每一個指定不同的eventCode。但是，operation-和eventCodes旨在用於區分不同類型的信息，比如聊天消息，皮卡點擊，位置更新等。因此，玩家a告訴玩家b他擊中了玩家c，玩家b告訴玩家d，他擊中玩家d，都會使用相同的代碼。關於哪個玩家被擊中的信息 - 就像它被擊中的難度或用哪種武器 - 屬於該操作的有效載荷一樣。例如，你可以將玩家的ID，被擊中的彈藥類型和他失去的生命能量傳遞給opRaiseEvent（）或opCustom（）。