日韩偷拍一区二区,国产香蕉久久精品综合网,亚洲激情五月婷婷,欧美日韩国产不卡

第3章游戲場景的轉換——狀態模式(State)

3.1 游戲場景本書使用Unity3D游戲引擎作為開發工具，而Unity3D是使用場景(Scene)作為游戲運行時的環境。開始制作游戲時，開發者會將游戲需要的素材(3D模型、游戲對象)放到一個場景中，然后編寫對應的程序代碼，之后只要單擊Play按鈕，就可以開始運行游戲。除了Unity3D之外，筆者過去開發游戲時使用的游戲引擎(Game Engine)或開發框架(SDK、Framework)，多數也都存在“場景”的概念，例如：? 早期Java Phone的J2ME開發SDK中使用的Canvas類；? Android的Java開發SDK中使用的Activity類；? iOS上2D游戲開發工具Cocos2D中使用的CCScene類。雖然各種工具不見得都使用場景(Scene)這個名詞，但在實現上，一樣可使用相同的方式來呈現。而上面所列的各個類，都可以被拿來作為游戲實現中“場景”轉換的目標。3.1.1 場景的轉換當游戲比較復雜時，通常會設計成多個場景，讓玩家在幾個場景之間轉換，某一個場景可能是角色在一個大地圖上行走，而另一個場景則是在地下洞穴探險。這樣的設計方式其實很像是舞臺劇的呈現方式，編劇們設計了一幕幕的場景讓演員們在其間穿梭演出，而每幕之間的差異，可能是在布景擺設或參與演出角色的不同，但對于觀眾來說，同時間只會看到演員們在某一個場景中的演出。要怎樣才能真正應用“場景”來開發游戲呢？讀者可以回想一下，當我們打開游戲App或開始運行游戲軟件時，會遇到什么樣的畫面：出現游戲Logo、播放游戲片頭、加載游戲數據、出現游戲主畫面、等待玩家登錄游戲、進入游戲主畫面，接下來玩家可能是在大地圖上打怪或進入副本刷關卡……。游戲畫面轉換如圖3-1所示。 圖3-1 游戲畫面轉換就以上面的說明為例，我們可規劃出下面數個場景，每個場景分別負責多項功能的執行，如圖3-2所示。 圖3-2 每個場景負責執行的游戲功能? 登錄場景：負責游戲片頭、加載游戲數據、出現游戲主畫面、等待玩家登錄游戲。? 主畫面場景：負責進入游戲畫面、玩家在主城/主畫面中的操作、在地圖上打怪打寶……? 戰斗場景：負責與玩家組隊之后進入副本關卡、挑戰王怪……在游戲場景規劃完成后，就可以利用“狀態圖”將各場景的關系連接起來，并且說明它們之間的轉換條件以及狀態轉換的流程，如圖3-3所示。 圖3-3 各場景轉換條件以及狀態轉換的“狀態圖”即便我們換了一個游戲類型來實現，一樣可以使用相同的場景分類方式，將游戲功能進行歸類，例如：卡牌游戲可按如下分類：? 登錄場景：負責游戲片頭、加載游戲數據、出現游戲主畫面、等待玩家登錄游戲。? 主畫面場景：玩家抽卡片、合成卡牌、查看卡牌……? 戰斗場景：挑戰關卡、卡片對戰……轉珠游戲可按如下分類：? 登錄場景：負責游戲片頭、加載游戲數據、出現游戲主畫面、等待玩家登錄游戲。? 主畫面場景：查看關卡進度、關卡信息、商城、抽轉珠……? 戰斗場景：挑戰關卡、轉珠對戰……當然，如果是更復雜的單機版游戲或大型多人在線游戲(MMORPG)，還可以再細分出多個場景來負責對應的游戲功能。切分場景的好處將游戲中不同的功能分類在不同的場景中來執行，除了可以將游戲功能執行時需要的環境明確分類之外，“重復使用”也是使用場景轉換的好處之一。從上面幾個例子中可以看出，“登錄場景”幾乎是每款游戲必備的場景之一。而一般在登錄場景中，會實現游戲初始化功能或玩家登錄游戲時需要執行的功能，例如：? 單機游戲：登錄場景可以有加載游戲數據、讓玩家選擇存盤、進入游戲等步驟。? 在線游戲：登錄場景包含了許多復雜的在線登錄流程，比如使用第三方認證系統、使用玩家自定義賬號、與服務器連接、數據驗證……對于大多數的游戲開發公司來說，登錄場景實現的功能，會希望通用于不同的游戲開發項目，使其保持流程的一致性。尤其對于在線游戲這種類型的項目而言，由于登錄流程較為復雜，若能將各項目共同的部分(場景)獨立出來，由專人負責開發維護并同步更新給各個項目，那么效率就能獲得提升，也是比較安全的方式。在項目開發時，若是能重復使用這些已經設計良好的場景，將會減少許多開發時間。更多的優點將在后續章節中說明。本書范例場景的規劃在本書范例中，《P級陣地》規劃了3個場景，如圖3-4所示。 圖3-4 《P級陣地》規劃的3個場景? 開始場景(StarScene)：GameLoop游戲對象(GameObject)的所在，游戲啟動及相關游戲設置的加載。? 主畫面場景(MainMenuScene)：顯示游戲名稱和“開始”按鈕。? 戰斗場景(BattleScene)：游戲主要執行的場景。3.1.2 游戲場景可能的實現方式實現Unity3D的場景轉換較為直接的方式如下：Listing 3-1 一般場景控制的寫法public class SceneManager{ private string m_state = "開始"; // 改換場景 public void ChangeScene(string StateName) { m_state = StateName;

switch(m_state) { case "菜單": Application.LoadLevel(“MainMenuScene”); break; case "主場景": Application.LoadLevel(“GameScene”); break; } } // 更新 public void Update() { switch(m_state) { case "開始": //... break; case "菜單": //... break; case "主場景": //... break; } }}

上述的實現方式會有以下缺點：只要增加一個狀態，則所有switch(m_state)的程序代碼都需要增加對應的程序代碼。與每一個狀態有關的對象，都必須在SceneManager類中被保留，當這些對象被多個狀態共享時，可能會產生混淆，不太容易識別是由哪個狀態設置的，造成游戲程序調試上的困難。每一個狀態可能使用不同的類對象，容易造成SceneManager類過度依賴其他類，讓SceneManager類不容易移植到其他項目中。為了避免出現上述缺點，修正的目標會希望使用一個“場景類”來負責維護一個場景，讓與此場景相關的程序代碼和對象能整合在一起。這個負責維護的“場景類”，其主要工作如下：? 場景初始化；? 場景結束后，負責清除資源；? 定時更新游戲邏輯單元；? 轉換到其他場景；? 其他與該場景有關的游戲實現。由于在范例程序中我們規劃了3個場景，所以會產生對應的3個“場景類”，但如何讓這3個“場景類”相互合作、彼此轉換呢？我們可以使用GoF的狀態模式(State)來解決這些問題。3.2 狀態模式(State)狀態模式(State)，在多數的設計模式書籍中都會提及，它也是游戲程序設計中應用最頻繁的一種模式。主要是因為“狀態”經常被應用在游戲設計的許多環節中，包含AI人工智能狀態、賬號登錄狀態、角色狀態……3.2.1 狀態模式(State)的定義狀態模式(State)，在GoF中的解釋是：“讓一個對象的行為隨著內部狀態的改變而變化，而該對象也像是換了類一樣”。如果將GoF對狀態模式(State)的定義改以游戲的方式來解釋，就會像下面這樣：“當德魯伊(對象)由人形變化為獸形狀態(內部狀態改變)時，他所施展的技能(對象的行為)也會有所變化，玩家此時就像是在操作另一個不同的角色(像是換了類)”。“德魯伊“是一種經常出現在角色扮演游戲(RPG)中的角色名稱。變化外形是他們常使用的能力，通過外形的變化，使德魯伊具備了轉換為其他形體的能力，而變化為“獸形”是比較常見的游戲設計。當玩家決定施展外形轉換能力時，德魯伊會進入“獸形狀態”，這時候的德魯伊會以“獸形”來表現其行為，包含移動和攻擊施展的方式；當玩家決定轉換回人形時，德魯伊會復原為一般形態，繼續與游戲世界互動。所以，變化外形的能力可以看成是德魯伊的一種“內部狀態的轉換”。通過變化外形的結果，角色表現出另外一種行為模式，而這一切的轉化過程都可以由德魯伊的內部控制功能來完成，玩家不必理解這個轉化過程。但無論怎么變化，玩家操作的角色都是德魯伊，并不會因為他內部狀態的轉變而有所差異。當某個對象狀態改變時，雖然它“表現的行為”會有所變化，但是對于客戶端來說，并不會因為這樣的變化，而改變對它的“操作方法”或“信息溝通”的方式。也就是說，這個對象與外界的對應方式不會有任何改變。但是，對象的內部確實是會通過“更換狀態類對象”的方式來進行狀態的轉換。當狀態對象更換到另一個類時，對象就會通過新的狀態類，表現出它在這個狀態下該有的行為。但這一切只會發生在對象內部，對客戶端來說，不需要了解這些狀態轉換的過程及對應的方式。3.2.2 狀態模式(State)的說明狀態模式(State)的結構如圖3-5所示。 圖3-5 狀態模式的結構圖參與者的說明如下：? Context(狀態擁有者)? 是一個具有“狀態”屬性的類，可以制定相關的接口，讓外界能夠得知狀態的改變或通過操作讓狀態改變。? 有狀態屬性的類，例如：游戲角色有潛行、攻擊、施法等狀態；好友上線、脫機、忙碌等狀態；GoF使用TCP聯網為例，有已連接、等待連接、斷線等狀態。這些類中會有一個ConcreteState[X]子類的對象為其成員，用來代表當前的狀態。? State(狀態接口類)：制定狀態的接口，負責規范Context(狀態擁有者)在特定狀態下要表現的行為。? ConcreteState(具體狀態類)? 繼承自State(狀態接口類)。? 實現Context(狀態擁有者)在特定狀態下該有的行為。例如，實現角色在潛行狀態時該有的行動變緩、3D模型變半透明、不能被敵方角色察覺等行為。3.2.3 狀態模式(State)的實現范例首先定義Context類：Listing 3-2 定義Context類(State.cs)public class Context{ State m_State = null;

public void Request(int Value) { m_State.Handle(Value); }

public void SetState(State theState ) { Debug.Log ("Context.SetState:" theState); m_State = theState; }}Context類中，擁有一個State屬性用來代表當前的狀態，外界可以通過Request方法，讓Context類呈現當前狀態下的行為。SetState方法可以指定Context類當前的狀態，而State狀態接口類則用來定義每一個狀態該有的行為：Listing 3-3 State類(State.cs)public abstract class State{ protected Context m_Context = null; public State(Context theContext) { m_Context = theContext; } public abstract void Handle(int Value);}在產生State類對象時，可以傳入Context類對象，并將其指定給State的類成員m_Context，讓State類在后續的操作中，可以獲取Context對象的信息或操作Context對象。然后定義Handle抽象方法，讓繼承的子類可以重新定義該方法，來呈現各自不同的狀態行為。定義3個繼承自State類的子類：Listing 3-4 定義3個狀態(State.cs)// 狀態Apublic class ConcreteStateA : State{ public ConcreteStateA(Context theContext):base(theContext) {}

public override void Handle (int Value) { Debug.Log ("ConcreteStateA.Handle"); if( Value > 10) m_Context.SetState( new ConcreteStateB(m_Context)); }}

// 狀態Bpublic class ConcreteStateB : State{ public ConcreteStateB(Context theContext):base(theContext) {}

public override void Handle (int Value) { Debug.Log ("ConcreteStateB.Handle"); if( Value > 20) m_Context.SetState( new ConcreteStateC(m_Context)); } }

// 狀態Cpublic class ConcreteStateC : State{ public ConcreteStateC(Context theContext):base(theContext) {} public override void Handle (int Value) { Debug.Log ("ConcreteStateC.Handle"); if( Value > 30) m_Context.SetState( new ConcreteStateA(m_Context)); } }上述3個子類，都要重新定義父類State的Handle抽象方法，用來表示在各自狀態下的行為。在范例中，我們先讓它們各自顯示不同的信息(代表當前的狀態行為)，再按照本身狀態的行為定義來判斷是否要通知Context對象轉換到另一個狀態。Context類中提供了一個SetState方法，讓外界能夠設置Context對象當前的狀態，而所謂的“外界”，也可以是由另一個State狀態來調用。所以實現上，狀態的轉換可以有下列兩種方式：? 交由Context類本身，按條件在各狀態之間轉換；? 產生Context類對象時，馬上指定初始狀態給Context對象，而在后續執行過程中的狀態轉換則交由State對象負責，Context對象不再介入。筆者在實現時，大部分情況下會選擇第2種方式，原因在于：狀態對象本身比較清楚“在什么條件下，可以讓Context對象轉移到另一個State狀態”。所以在每個ConcreteState類的程序代碼中，可以看到“狀態轉換條件”的判斷，以及設置哪一個ConcreteState對象成為新的狀態。每個ConcreteState狀態都可以保持自己的屬性值，作為狀態轉換或展現狀態行為的依據，不會與其他的ConcreteState狀態混用，在維護時比較容易理解。因為判斷條件及狀態屬性都被轉換到ConcreteState類中，故而可縮減Context類的大小。4個類定義好之后，我們可以通過測試范例來看看客戶端程序會怎樣利用這個設計：Listing 3-5 State的測試范例(StateTest.cs) void UnitTest() { Context theContext = new Context(); theContext.SetState( new ConcreteStatA(theContext ));

theContext.Request( 5 ); theContext.Request( 15 ); theContext.Request( 25 ); theContext.Request( 35 ); }首先產生Context對象theContext，并立即設置為ConcreteStateA狀態；然后調用Context類的Request方法，并傳入作為“狀態轉換判斷”用途的參數，讓當前狀態(ConcreteStateA)判斷是否要轉移到ConcreteStateB；調用幾次Request方法，并傳入不同的參數。從輸出的信息中可以看到，Context對象的狀態由ConcreteStateA按序轉換到ConcreteStateB、 ConcreteStateC狀態，回到ConcreteStateA狀態。 State測試范例產生的信息 Context.SetState:DesignPattern_State.ConcreteStateA ConcreteStateA.Handle ConcreteStateA.Handle Context.SetState:DesignPattern_State.ConcreteStateB Context.SetState:DesignPattern_State.ConcreteStateC Context.SetState:DesignPattern_State.ConcreteStateA3.3 使用狀態模式(State)實現游戲場景的轉換在Unity3D的環境中，游戲只會在一個場景中運行，所以我們可以讓每個場景都由一個“場景類”來負責維護。此時，如果將場景類當成“狀態”來比喻的話，那么就可以利用狀態模式(State)的轉換原理，來完成場景轉換的功能。由于每個場景所負責執行的功能不同，通過狀態模式(State)的狀態轉移，除了可以實現游戲內部功能的轉換外，對于客戶端來說，也不必根據不同的游戲狀態來編寫不同的程代碼，同時也減少了外界對于不同游戲狀態的依賴性。而原本的Unity3D場景轉換判斷功能，可以在各自的場景類中完成，并且狀態模式(State)同時間也只會讓一個狀態存在(同時間只會有一個狀態在運行)，因此可以滿足Unity3D執行時只能有一個場景(狀態)存在的要求。3.3.1 SceneState的實現《P級陣地》的場景分成3個：開始場景(StarScene)、主畫面場景(MainM