PlayFab 用量：最佳做法
使用 PlayFab 以用量為基礎的定價模型，您只需為遊戲的實際服務用量付費。但這引發了一個顯而易見的問題：如何以最佳方式最佳化這些遊戲以節省成本，同時仍實作您需要的所有功能？在本文件中，我們將深入探討這些細節，並說明有助於您提前規劃的最佳做法。 在將遊戲從開發模式移至上線之前，您可以在 Game Manager 的 Billing Summary 索引標籤中檢閱計量資訊。 有六種用量計量：事件、設定檔、內容和設定、CloudScript、Insights 以及多人遊戲服務。開始最佳化遊戲的最佳方式，是查看它使用的每個計量，並了解它如何隨時間累積。這可讓您快速找出一些明顯的改善之處。如需計量的詳細資訊，請參閱定價計量。事件
PlayFab 中有兩種類型的事件：PlayStream 和遙測。 PlayFab 會處理 PlayStream 事件，以檢查它們是否觸發您所定義的 PlayStream 動作，並更新使用者區段。某些 PlayStream 事件會因呼叫驗證和統計資料更新等服務功能而自動產生。遊戲可以產生自己的自訂事件來擴充此功能。 遙測事件不會由 PlayStream 處理。這些事件用於分析，並直接進入資料倉儲。遙測事件不會在 PlayFab 中自動產生；它們是由遊戲產生的自訂事件。 對於這兩種事件類型，較大的資料承載都會增加計量用量的總量。您可以確保只傳送所需的資料，以降低整體用量。粗略的準則是，任何指定事件在事件本文中每 1 KB 資料都會讓相關計量遞增 1。 若要選擇最適合您用法的事件路徑，您應該對如何使用所產生的每個自訂事件有明確的計畫。只有遊戲離線評估才需要的事件應走遙測路徑。這有助於大幅降低成本，因為遙測事件的超額費用不到 PlayStream 的一半。 如果您使用的是預先建置的 SDK，請務必記住，某些關於使用者行為的分析資料會自動產生，如 PlayStream 事件模型參考中所述。若要關閉選用事件，請在 PlayFab Game Manager 中變更遊戲的 Settings/Data Collection 索引標籤中的分析設定。同樣地，雖然在偵錯期間為 CloudScript 執行開啟「產生 PlayStream 事件」選項是個好主意，但您應確保在上線之前將其停用。對於 PlayStream 動作觸發的 CloudScript，如果您需要在實際環境中偵錯某些行為，隨時可以稍後再開啟它們。設定檔
設定檔實際上是「關於玩家的一切」，包括物品欄、儲存的資料和統計資料等常見元素。它也包含您用來透過 PlayStream 中的 LiveOps 功能驅動獨特體驗的中繼資訊，例如上述的使用者區段。此外，某些遊戲層級的舊版功能 (例如遊戲資料、目錄和商店) 也包含在此計量中，因為它們的資料實作實際上與使用者資料相同。由於這組計量是由所有玩家動作以及對玩家採取的動作所驅動，因此它是最需要最佳化規劃的計量。 定價計量所擷取之用量的主要影響因素，是讀取、儲存和寫入的資料量，以及您呼叫產生計量資料之 API 的頻率。 如需導致這些計量「轉動」之特定 API 呼叫的詳細資訊，請參閱定價計量。 我們將從使用者資料和統計資料開始，因為它們的使用模式相似，然後我們將討論玩家物品欄管理。資料和統計資料
評估使用者資料的用量時，適用與事件相同的近似邏輯——每 1 KB 讓計量計數增加 1——不過請記住，基於此計算的目的，呼叫的每個「元素」都應視為不同的。更新使用者資料之呼叫中的每個索引鍵值組都會分別計算。對於讀取，此 1 KB 計算適用於傳回的總資料，無論索引鍵值組的數目為何。這表示寫入 10 個各 100 位元組的索引鍵是設定檔寫入計量的 10 個「刻度」，因為每個索引鍵值組寫入最少為 1 KB，而讀取這 10 個索引鍵則是 1 個「刻度」，因為總共是 1 KB。如需用量的更具體詳細資料，請參閱定價計量。 統計資料稍微複雜一些，因為它們會更新設定檔，也可能對排行榜產生影響。一般而言，您可以將每個更新的統計資料視為完整的設定檔更新，而讀取則以每次呼叫中讀取之資料的總大小為基礎。由於儲存體是以每 GB 計價，而統計資料通常每個只會耗用幾個位元組，因此我們將專注於讀取和寫入。 由於總資料大小很重要，因此最佳化它是第一步。幸運的是，有各種廣為人知的技術可以達成這一點——使用列舉或識別碼取代物品的完整文字、將大型資料封裝為二進位，甚至使用位元欄位將資料封裝到較小的空間中。完成後，下一步是仔細評估何時需要進行這些讀取和寫入呼叫。 如果您來自 PC 或主機開發——特別是單人遊戲——這可能是一種新模式。但在這些環境中，您必須小心用戶端裝置上的資源衝擊和記憶體回收，因為它們可能會在關鍵時刻造成效能降低。當您的遊戲使用雲端中的資源時，除了效能成本之外，還必須將此邏輯延伸，將每次資源衝擊都視為具有實際成本。 您如何判斷讀取和寫入的最佳頻率？想要更頻繁地更新資料和統計資料的開發人員，最常見的兩個顧慮是防止作弊，以及在伺服器端儲存即時資訊，以供玩家之間的互動，或在遊戲意外結束時防止資料遺失。作弊防護
雖然看起來您可能需要不斷更新後端資料以確保基本安全性，但如果您的遊戲不需要對工作階段進行完全以伺服器為權威的控制，頻繁更新幾乎是不必要的。首先，根本的問題是您實際需要多少安全性。 對於某些遊戲，特別是主要透過遊戲內廣告營利且沒有排行榜的遊戲，作弊並不是什麼大問題。在此情況下，信任用戶端傳送的資料通常是可行的做法，因為這些資料的安全性並不是真正的顧慮。為了識別作弊行為並決定如何處理，我們建議您實作程序來檢閱玩家的事件、資料和統計資料。 對於需要支援競爭公正性或保護整體玩家體驗的其他遊戲，更強的安全性就更加重要。根據您的特定需求，某些做法可以在這些情況下降低資料讀取和寫入的頻率。 如果您的遊戲不是即時的，我們建議的一種做法是在一段時間內彙總有關玩家遊戲的資訊——通常是遊戲的一個「回合」，持續數分鐘——然後將這些資料傳送至判斷其是否有效的指令碼。要評估的關鍵元素可能因遊戲而異，但需要考量的常見概念範例包括：- 距離上次工作階段報告已經過了多久，以及用戶端聲稱它在最近一次工作階段中遊玩了多久？
- 玩家登錄了哪些分數，以及根據玩家的等級、裝備等，這些分數是否合理？
資料即時性
我們從設定檔寫入率高的開發人員那裡聽到的一個常見主題，是他們擔心玩家遺失進度。如果玩家在遊戲能夠儲存之前結束遊戲，且下次遊玩時無法使用本機狀態，或者該狀態需要在裝置之間移動，您會希望 PlayFab 儲存的玩家狀態資訊盡可能保持最新。 對於許多遊戲，您可以透過定期、低頻率地向服務傳送更新活動訊號 (例如每 15 分鐘) 來解決此問題。但加入額外的邏輯來延長或縮短該頻率也有幫助。例如：- 加入「重要更新」覆寫，如果玩家主動做了重要的事情，就會立即寫入並重設計時器，讓它不會遺失。
- 如果您的遊戲在沒有玩家輸入的情況下持續進行，請考慮在長時間沒有輸入時延長活動訊號週期。這對於放置型遊戲特別重要，因為玩家經常讓它們整夜執行。
- 為玩家提供直接強制更新的方式，例如使用者功能表中的按鈕。不過在此情況下，請務必節流從用戶端裝置實際對 PlayFab 發出呼叫的速率，讓重複按下該按鈕的玩家不會每次都產生一個呼叫。