管線類型
管線類型與管線所發出的事件類型直接相關。開發人員可以具現化兩種不同類型的管線:- 遙測事件管線:只能發出遙測事件,並使用 Write Telemetry Events REST API。
- PlayStream 事件管線:只能發出 PlayStream 事件,並使用 Write Events REST API。
驗證類型
建立管線的另一個重要部分是驗證類型。PlayFab 事件支援兩種驗證機制:實體驗證和遙測金鑰驗證。 當遊戲開發人員想要將事件連結至特定實體以進行進一步彙總或分析時,會使用實體驗證。例如,遊戲開發人員可以記錄與玩家動作相關的事件,以對遊戲玩家進行可供分群的進一步行為分析。 當遊戲開發人員想要記錄不一定需要連結至實體的事件時,會使用遙測金鑰驗證。例如,在有已登入的玩家之前,遊戲就可以開始傳送與效能相關的事件,或想要收集以供進一步分析的特定計量。這不需要經過一般的實體驗證程序即可完成。 支援的驗證類型 / 事件類型組合實體驗證
此驗證類型是一般且最常見的 PlayFab 驗證方法。它與特定實體緊密相關,並要求您呼叫對應的 PlayFab 登入 API 來取得實體權杖,以用於任何後續呼叫。下列清單列出可搭配實體驗證使用的不同實體類型。- namespace:命名空間實體代表跨遊戲的玩家身分識別和共用資料範圍。發行者識別碼會識別命名空間。
- title:遊戲實體代表範圍限於該遊戲的全域資訊。
- master_player_account:
master_player_account是命名空間中所有遊戲共用的玩家實體。 - title_player_account:對大多數開發人員而言,title_player_account 以最傳統的方式代表玩家。
- character:角色實體是 title_player_account 的子實體。
- group:群組實體是其他實體的容器。目前僅限於玩家和角色。
遙測金鑰驗證
遙測金鑰驗證不需要實體權杖,因此不會與任何特定實體綁定。 如果使用遙測金鑰驗證,在建立管線期間需要 PFEventPipelineTelemetryKeyConfig 結構。此結構有兩個主要部分:- 遙測金鑰,這是一個透過 PlayFab Game Manager 建立和管理的字串。
- PFServiceConfigHandle,可讓 SDK 知道應使用哪個正確的服務設定來上傳事件。服務設定控制代碼是在 SDK 初始化期間呼叫 PFServiceConfigCreateHandle 建立的。
事件管線設定
如前所述,事件管線有一些可設定的屬性,可在建立管線之後透過 PFEventPipelineConfig 結構參數提供。 可設定的屬性如下:- maxEventsPerBatch:在將事件寫入 PlayFab 之前批次處理的最大事件數目。
- maxWaitTimeInSeconds:管線在送出不完整批次之前等候的最長時間。
- pollDelayInMs:管線在清空事件緩衝區之後,再次從中讀取之前等候的時間。
- compressionLevel:定義壓縮演算法所使用的壓縮層級。如需壓縮的詳細資訊,請參閱 GZIP 壓縮。
- retryOnDisconnect:事件管線會重試傳送因連線中斷而失敗的事件。僅適用於遙測事件管線。
- bufferSize:管線緩衝區中事件數量的限制。
預設值
如果 PFEventPipelineConfig 只指定了部分屬性,空白的屬性會被覆寫並使用預設值。
如需如何為事件管線更新這些屬性的範例,請參閱 更新管線設定。
GZIP 壓縮
事件管線提供使用 GZIP 壓縮標準來壓縮本文承載的選項。 您可以在 PFEventPipelineConfig 結構中指定所需的壓縮層級,此結構是 PFEventPipelineUpdateConfiguration API 參數的一部分。 較低的壓縮層級壓縮程度較低,但速度最快;較高的壓縮層級可達到較佳的壓縮率,但壓縮速度最慢。壓縮率的差異完全取決於所傳送的資料類型。依資料的大小和隨機性而定,即使在不同層級,壓縮率也可能相同。 取捨: 由於執行壓縮演算法增加了複雜度,使用壓縮會增加 CPU 時間,但另一方面,網路本文承載會大幅減少。因此,是否應使用壓縮取決於遊戲開發人員依據遊戲需求和資源所做的決定。 根據內部驗證,CPU 時間平均增加 20%,而承載本文大小平均減少 91%。這些百分比可能會因承載大小和所壓縮資料的複雜度而有很大差異。事件處理常式
在建立管線時,遊戲開發人員可以提供兩個選擇性的事件處理常式,這些處理常式會在上傳事件時叫用。 不過,如果遊戲開發人員想要「射後不理」的體驗,可以省略提供事件處理常式。 可提供的事件處理常式如下:- PFEventPipelineBatchUploadSucceededEventHandler:顧名思義,它會接收所有成功上傳至 PlayFab 的事件。
- PFEventPipelineBatchUploadFailedEventHandler:它會在經過管線重試邏輯之後,接收所有失敗的事件。
管線建立範例
以下根據先前討論的主題,提供如何具現化事件管線的不同範例。-
使用實體驗證建立遙測事件管線
如果開發人員想要傳送遙測事件,而且不需要使用遙測金鑰驗證,可以使用 PFEventPipelineCreateTelemetryPipelineHandleWithEntity API,如下一個範例所示:
此範例示範如何建立使用實體驗證且沒有處理常式的遙測事件管線。這表示管線會發出事件,而不理會結果。
-
使用遙測金鑰驗證建立遙測事件管線
如果開發人員想要傳送遙測事件,而且需要使用遙測金鑰驗證,可以使用 PFEventPipelineCreateTelemetryPipelineHandleWithKey API,如下一個範例所示:
此範例示範如何建立不使用實體驗證的遙測事件管線。 事件管線會開始使用遙測金鑰上傳事件,之後也可以新增實體。請參閱切換至實體驗證或更新實體
-
建立 PlayStream 事件管線
如果開發人員想要傳送 PlayStream 事件,可以使用 PFEventPipelineCreatePlayStreamPipelineHandle API,如下一個範例所示:
此範例示範如何建立使用實體驗證且沒有處理常式的 PlayStream 事件管線。這表示管線會發出事件,而不理會結果。
-
使用事件處理常式的事件管線
此範例示範如何將事件處理常式提供給管線建立 API。
發出事件
一旦建立了事件管線,發出事件就是很直接的作業。遊戲開發人員應呼叫 PFEventPipelineEmitEvent API,此 API 會接收現有的事件管線控制代碼和要傳送的事件。E_PF_API_CLIENT_REQUEST_RATE_LIMIT_EXCEEDED (0x892354dd)
切換至實體驗證或更新實體
如果管線僅使用遙測金鑰設定建立,有一種方式可以切換至實體驗證,或者如果您想要更新管線以使用不同的實體,也可以這麼做。 透過使用 PFEventPipelineAddUploadingEntity,您可以將實體附加至執行中的管線,而不需要重新初始化管線。如果已有實體,它也會取代現有的實體。 範例: 在遊戲開始執行時,使用遙測金鑰設定建立遙測事件管線。可能的原因是尚未有玩家身分識別,或您還不想記錄任何與玩家相關的內容。切換至遙測金鑰驗證
延伸先前的案例,如果開發人員想要回到遙測驗證,並將事件記錄與實體分離,可以呼叫 PFEventPipelineRemoveUploadingEntity 並傳遞事件管線控制代碼,如下所示:更新管線設定
您可以使用 PFEventPipelineUpdateConfiguration API 更新管線,此 API 會接收現有的事件管線控制代碼和新的設定結構,如下所示:無效 / 已停用的遙測金鑰
如果遙測金鑰已停用,或在建立管線時提供了無效的金鑰,任何使用該遙測金鑰執行的事件管線一旦發現金鑰無效或已停用,就會開始失敗。 即使客戶最終重新啟用了金鑰,管線也不會察覺,並會繼續透過失敗事件處理常式傳回失敗。值得一提的是,此行為是以工作階段為基礎的,這表示如果重新啟動遊戲,就會建立新的管線,並能再次上傳事件。管線控制代碼生命週期
與其他 PlayFab 控制代碼一樣,事件管線控制代碼也使用複製/關閉模式:- PFEventPipelineCloseHandle:關閉管線控制代碼。當管線的最後一個控制代碼關閉時,管線會被終結,並排清任何剩餘的已緩衝事件。
- PFEventPipelineDuplicateHandle:複製管線控制代碼。原始控制代碼和複製的控制代碼都必須使用 PFEventPipelineCloseHandle 分別關閉。
