Replacement Bots
概述
在以下兩種情形，讓AI控制玩家的角色通常很有用：
- 為了替換在對戰進行中從遊戲中斷連線的玩家。這有助於建立更公平的對戰，因為機器人可以在玩家試著重新連線到遊戲時協助，或甚至替補一名憤怒退出的玩家。
- 在未達到啟動遊戲階段的最低必要玩家數量時，以假的玩家填入房間。這在遊戲版本週期的早期階段尤其重要，此時的玩家基數仍然很小。
設定
在Quantum中，此類功能的AI邏輯由每個客戶端的機器在本機執行；意味著沒有「模擬機器人輸入的主客戶端」的概念。
雖然運行AI以控制一些遊戲實體通常很簡單，但需要針對遊戲而進行。當然，AI執行方式本身的複雜性可以從非常簡單到非常複雜。
最簡單的開始方法是標明一個實體是否在任何時點由AI所控制。可以透過不同的方法來完成：
- 新增一個「旗標元件」，比如
component AI {}，其在需要的時候新增到實體／從實體移除。系統之後可迭代每個有著一個AI元件的實體，以執行控制邏輯； - 在元件中使用一個布林值，以開啟／關閉AI控制，比如
component MyCharacter { bool ControlledByAI; }； - 新增更多AI特定的元件，並附上很多額外的資料，比如機器人SDK的代理元件（HFSM、BT等等），或一個自訂的元件；
現在的問題是，應該何時完成它？這取決於前面提到的選定的使用案例；這些將在下一個章節中進行說明。
在遊戲對戰中替換一個真實玩家
透過啟用PlayerConnectedSystem，並且之後回應ISignalOnPlayerConnected及ISignalOnPlayerDisconnected信號，可以完成這件事情。系統及其附隨的信號在玩家文檔中有所說明。
當玩家中斷連線：尋找該玩家所控制的實體，並且以上述說明的方法來針對它們設定AI。
當玩家再次連線，檢查是否有實體曾由該玩家所控制，並且移除AI設定，這樣玩家從AI拿回控制。
值得一提的是，上述系統使用PlayerInputFlags以工作，如果需要的話，其也可以獨立於PlayerConnectedSystem使用。如需取得更多相關資訊，在此取得玩家輸入旗標的資訊。
以機器人填入房間
在這種案例下，沒有涉及實際的玩家。換句話說，建立實體的時候，並不希望它被實際的人所控制。
因為不涉及實際的玩家，因此也不需要連線性邏輯。針對自訂遊戲邏輯，可以以實體填入房間，比如在這個範例演算法／程式碼片段中：
- 在一個Quantum系統中，在遊戲啟動後等待一段時間間隔，以便玩家有時間連線並發送他們的玩家資料；
- 當玩家到達時，使用
OnPlayerDataSet回調，在遊戲狀態中（例如，在frame.Global的變數中）儲存已成功連線和加入遊戲的玩家數量； - 在時間間隔之後，從幀API的期望玩家計數中減去這個數量，如下操作：
int fillAmount = frame.PlayerCount - frame.Global->ConnectedPlayersCount; - 使用該結果來執行一個
for迴圈，在此將建立機器人實體：
C#
for(int i = 0; i < fillAmount; i++)
{
// Create a new Entity here
// Setup it as a Bot as explained earlier on this document
}
上述程式碼片段非常簡單，並且應按照遊戲及遊戲設計的要求來調整；舉例而言，指派特殊資訊到機器人實體可能非常有用，比如假的玩家資訊、團隊資料等等。
選擇一個機器人以建立
取決於遊戲類型，基於一些已知的資料來建立一個新的機器人可能非常有用。舉例而言，為尚未被選擇或具有不同難度的角色來選擇機器人。
訣竅： RuntimeConfig資產可保有一些參照到實體原型（也就是AssetRefEntityPrototype），這樣您可以參照各式各樣的角色以選擇。或者，可以有一種角色的單一類型，並且參照不同的AI資產來控制它（例如，基於難度等級的不同的狀態機器）。
玩家及機器人結構
Quantum系統控制角色。這些系統通常知道如何讀取玩家輸入，來改變他們的角色的遊戲狀態，比如移動他們、旋轉他們及觸發攻擊。
現在，可透過多種方式以AI邏輯控制這些同樣的角色。這是一個例子程式碼結構，其通常運作良好：
- 玩家自然地有一個輸入，其可以由
frame.GetPlayerInput(playerIndex)輪詢，然後傳回給您一個到類型Input的架構的指標； - 機器人也可以在一個自訂元件-
component Bot { Input Input }-中有相同的架構，並且AI邏輯本身可能只是用於填入其中的資料； - 在任何角色系統運行之前填入輸入資料。這樣的話如果系統知道如何取得輸入，而不論是誰填入，那麼不需要在系統之中進行任何額外的特殊檢查，來了解該實體是一個玩家或機器人；
- 這意味著AI系統可能（幾乎）永不直接地影響實體狀態，而是它基於其決策邏輯來生成假的輸入。
使用該結構的優勢是將三者進行明確分離：輸入 | 玩家及機器人 | 角色，這是透過提供低耦合系統來完成。
請記住：這只是一個建議。這個結構完全不是強制性的，而且同樣的結果可以透過其他許多方法來達成。
這裡是這個策略的視覺化效果，這個策略使用於Twin Stick Shooter範例:
注意： Twin Stick Shooter範例是一個 進階 範例，所以理解Quantum的基礎，對於分析它而言是必要的。
具有機器人SDK的AI
如果您剛開始針對您的專案思考AI，您可能希望研究一下Quantum的機器人SDK。機器人SDK是編輯器工具及Quantum程式碼的集合，其支援AI代理的建立，比如狀態機器、行為樹及其他常見的解決方案。
如需取得更多關於機器人SDK的資訊，請按此處。
Back to top