實時對戰遊戲PVP開發之PUN使用中常見問題總結
PUN在使用過程中常遇到的問題和疑問，本篇文章可以幫你解決PUN使用和選擇的疑問，順利完成PVP實時對戰遊戲開發。
哪款Photon產品適合我？
這是一個難以回答的問題，因為它取決於你正在製作的遊戲和你的專案的具體情況。 不過，可以推薦以下內容幫你進行選擇：
如果您仍然有疑問，請隨時與我聯絡，直接進行留言，幫你解決問題。
Photon Realtime和PUN有什麼區別？
Photon Realtime和PUN都基於相同的API：LoadBalancing API。 兩種產品共享相同的後端，相同的伺服器應用程式，相同的核心概念。 起初，PUN是一個更好的UNet（舊的Unity網路）產品替代者。保留一個類似的API，具有更堅實的後端和豐富的功能。 然後它逐漸分化，成為Unity上多人遊戲的頭號解決方案。
我們擁有Photon Realtime Unity SDK，但PUN具有更高水平的高度封裝元件式即用功能，如：
Unity中callbacks
Unity元件，可以序列化和同步。 PhotonView元件
PunRPC
離線模式
然而，儘管PUN支援webhooks和持久的房間狀態，但在載入已儲存的遊戲時，仍然無法100％地在場景中恢復網路物件的狀態。
Photon Cloud
什麼是預設Photon區域？
只要至少有一個區域可用，客戶端應該能夠連線到Photon Cloud。 因此，為保證這一點，開發人員沒有明確設定或選擇“最佳區域”選項時會配置或使用預設值。 預設值可能因客戶端SDK而異。 在本地SDK中，它是OpGetRegions中伺服器返回的區域列表的索引0處的值。 在Unity和DotNet SDK上，預設區域應該是“EU”。
是否可以禁用某些區域？
是。 它通過定義允許區域的列表，來實現禁用某些區域。 可以在“Dashboard Regions Filtering”中進行設定。
Load Balancing 負載均衡
Photon房間支援的最大玩家數量是多少？
玩家人數是增加房間內流量的主要因素。 交換的訊息越多，訊息越多。
理論上沒有限制。 對於超過8名玩家你需要進行管理。 對於大量的玩家，你可以將他們分開 - 你的伺服器中 - 跨越多個房間。
Photon字串是否有限制？
Photon使用字串有很多用途：房間名稱，大廳名稱，使用者名稱，暱稱，自定義屬性鍵等。
Photon二進位制協議可以序列化最多32767個字元的字串。 對於名稱和UserID，32個字元應該足夠了（例如GUID是32個字元）。 但是，對於自定義屬性鍵，您應該使用較短的字串以儘量減少開銷。 這對於在大廳中可見的屬性尤為重要，因為這些屬於房間列表的一部分，並且會發送給大廳中的所有人，而不僅僅是房間中的幾個客戶。
自定義屬性的數量是否有限制？
沒有限制。但請注意，設定的自定義屬性越多，客戶端載入時間就越長，因為加入房間時，客戶端也會收到所有屬性。 如果您的人數太多，而且客戶的載入時間超過一定的時間，可能導致客戶端他們斷開連線。
我可以使用Photon傳送大量資訊嗎？
我們不建議使用Photon傳輸大資料（即檔案），除非您知道您在做什麼。我們建議您優化您交換的資料，如果您確實需要傳送非常重要的資訊可以和官方進行聯絡。
Photon Cloud對客戶端緩衝區有500KB的伺服器端限制。因此，根據上下文，可以考慮訊息：
我們的客戶端緩衝區大小在Photon Cloud> 500KB上“太大”。如果客戶在短時間內遇到此限制，則伺服器將斷開連線。
“太大”不能與UDP一起傳送，而不會導致大量可能導致> 100KB問題的片段。
“太大”不能將它分成多個大於1.2KB的UDP包（包括協議開銷）。
對於定期傳送的郵件（每秒10次或甚至更多），我們建議將它們的大小保持在1KB以下。
如果訊息只發送很少（例如在比賽開始時傳送一次），那麼多KB的大小仍然很好，但我們仍然建議將其保持在10KB以下。
在特殊情況下，20KB甚至50KB可能是有意義的。但通常那些大的訊息表明存在錯誤，您應該檢視自己正在做的事情並重新考慮自己的選擇。
哪些資料應該可靠地傳送，哪些資料應該不可靠地傳送？
首先，你應該知道只有當使用的協議是UDP時，可靠性才是一個選項。 TCP有其自己的“可靠性”機制，這裡沒有涉及。
傳送可靠的資訊意味著我們應該確保它到達目標。 因此，如果我們在等待足夠的時間後沒有收到確認，我們會重複傳送，直到我們收到確認或我們超過了重新審理的次數。 此外，重複可靠的事件可能會導致額外的延遲並使後續事件延遲。
不使用可靠性的例子：
玩家在實時遊戲中的位置更新
語音或視訊聊天
使用可靠性的示例：
在回合制遊戲中轉變事件
為什麼我的遊戲中有太多斷線？
這些斷開可能是由於各種原因。 我們已經有兩個文件頁面可以幫助您調查相關問題：
“分析斷開”
“客戶端連線處理”
每個房間每秒訊息的計算方式？
Photon伺服器每秒對入站和出站郵件的總數進行計數，並將其除以房間總數（在同一主伺服器上）。
任何操作請求或操作響應或事件都被視為訊息。 Photon操作返回一個可選的操作響應並觸發零個或多個事件。 快取的事件也被計為訊息。
每個房間室內操作的訊息成本：
如何計算使用者消耗的流量？
這是一個複雜的問題。 首先，您需要知道所做的任何計算只是一個理論估算，並不一定反映實際情況。 我們建議構建概念驗證並使用它來收集真實資料。
這裡說的是如何估算房間內單個使用者產生的流量：
我們假設如下：
一個房間有N個玩家。
玩家每秒傳送F訊息（以Hz為單位的訊息傳送速率）
平均訊息大小為X（以位元組為單位，有效負載（P）+協議開銷（O））
一個普通玩家每個月在你的遊戲上花費H小時
如果我們不考慮ACK，連線處理（建立，保持活躍等）命令並重新發送。 然後我們說平均來說，CCU消耗遊戲中的C（以位元組/月為單位）如下：
C = X * F * N * H * 60（分鐘每小時）* 60（每分鐘秒數）
PUN Plus和PUN Free有什麼不同？
你可以在這裡找到比較表。 但基本上，它們在功能和原始碼上幾乎完全相同。 差異因Unity版本而異，具體如下：
Unity 4 Pro，Unity 5，Unity 2017：
PUN Plus（PUN +）= PUN免費（PUN）+ 100CCU 60個月（憑證可兌換1個支援的Photon應用程式）
Unity 4免費
PUN Plus（PUN +）= PUN免費（PUN）+ 100CCU 60個月（憑證可兌換1個支援的Photon應用程式）+支援Android / iOS版本的套接字
Billing開票
如果我是學生或者愛好者是否提供特別優惠？
我們所有的產品都有免費的一級和一次性的入門計劃。 我們通常也會參與Unity的資產商店銷售，並偶爾向優惠券發放優惠券。
我可以為單個Photon應用程式組合多個100 CCU計劃嗎？
不可以.100個CCU計劃不可堆疊，每個AppId只能應用一次。 如果您購買多個PUN +資產座位，那麼您必須為每個100個免費CCU兌換單獨的AppId。 如果您需要更多的CCU用於單個應用，則下一個更高的計劃是500 CCU。 如果您訂閱每月或每年的計劃，那麼您仍然可以在每月/每年計劃的基礎上將CCU保留60個月。