iPhone 游戲開發(fā)教程 游戲引擎 （6）是本我要介紹的內(nèi)容，繼續(xù)上一章開始介紹，本節(jié)主要介紹了事件的相關(guān)內(nèi)容，先來看本文詳解。

解決高層次事件

一旦判定了用戶執(zhí)行的物理動作，你的代碼必須能將它們轉(zhuǎn)換為游戲邏輯組件可以使用的形式。具體怎么做需要依賴于你的游戲的上下文，但是這里有幾種典型的形式：

如果玩家準(zhǔn)備控制虛擬人偶，在玩家和游戲之間通常會有連續(xù)的交互。經(jīng)常需要存儲當(dāng)前用戶輸入的表現(xiàn)形式。比如，如果輸入裝置為遙桿，你可能需要在主循環(huán)中記錄當(dāng)前點的x軸坐標(biāo)和y軸坐標(biāo)，并修正虛擬人偶的動量。玩家和虛擬人偶之間的是緊密地耦合在一起的，所以控制器的物理狀態(tài)代表著虛擬人偶的高層次的狀態(tài)模型。當(dāng)遙桿向前撥動時，虛擬人偶向前移動；當(dāng)“跳躍”按鈕按下時，虛擬人偶跳起。

如果玩家正與游戲地圖進行交互，那么需要另外一種間接的方式。比如，玩家必須觸摸游戲地圖中的一個物體，代碼必須將玩家在屏幕上的觸摸坐標(biāo)轉(zhuǎn)化為游戲地圖的坐標(biāo)以判定用戶到底觸摸到了什么。這可能只是簡單的將y軸坐標(biāo)減去2D攝像機坐標(biāo)的偏移量，也可能是復(fù)雜到3D場景中的攝像機光線碰撞偵測。

最后，用戶可能進行一些間接影響到游戲的動作，如暫停游戲、與GUI交互等。這時，一個簡單的消息或者函數(shù)會被觸發(fā)，去通知游戲邏輯應(yīng)該做什么。

游戲邏輯

游戲邏輯是游戲引擎中是你的游戲獨一無二的部分。游戲邏輯記錄著玩家狀態(tài)、AI狀態(tài)、判定什么時候達到目的地、并生成所有的游戲規(guī)則。給出兩個相似的游戲，他們的圖像引擎與物理引擎可能只有細(xì)微差別，但是它們的游戲邏輯可能會有很大差異。

游戲邏輯與物理引擎緊密配合，在一些沒有物理引擎的小游戲中，游戲邏輯負(fù)責(zé)處理所有物理相關(guān)內(nèi)容。但是，當(dāng)游戲引擎中有游戲引擎的時候，需要確保兩者的獨立。達到此目的的最好方式就是通過物理引擎向游戲邏輯發(fā)送高層次的游戲事件。

高層次事件

游戲邏輯代碼應(yīng)該盡可能僅處理高層次問題。它不應(yīng)該處理當(dāng)用戶觸摸屏幕時需要以什么順序?qū)⑹裁疵璁嫷狡聊簧?，或者兩個矩形是否相交等問題。它應(yīng)該處理玩家希望向前移動，什么時候一個新的游戲物體應(yīng)當(dāng)被創(chuàng)建/移除以及當(dāng)兩個物體相互碰撞后應(yīng)該做什么。

為了維持概念上的距離，處理低層次概念（諸如用戶輸入與物理引擎等）的代碼應(yīng)當(dāng)創(chuàng)建高層次的消息并發(fā)送給游戲邏輯代碼去處理。這不僅能保持代碼的獨立性與模塊化，還會對調(diào)試有所幫助。通過查看高層次消息傳遞的日志，你可以判定是沒有正確處理消息（游戲邏輯代碼的問題），還是沒有在正確的時機傳送消息（低層次代碼問題）。

 一個非?；镜膫鬟f高層次消息的技術(shù)是寫一個String并傳遞它。假如玩家按下了上箭頭鍵，它的虛擬人偶必須向上移動。

void onPlayerInput( Input inputEvt ) {     
    if(inputEvt.type == IE_KEY && inputEvt.value == KEY_UP ) {     
        g_myApp->sendGameLogicMessage( "player move forward" );     
    }     
}    

雖然上面的代碼對程序員來說通俗易懂，但對于電腦來說卻并不高效。它需要更多的內(nèi)存與處理，遠(yuǎn)比實際需要的多。我們應(yīng)該用提示來替代用戶輸入方法。比起一個字符串，它使用一個"type"和"value"。由于可能的事件都是結(jié)構(gòu)化的和有限的，因此我們可以使用整數(shù)和枚舉類型來我們消息中的事件信息。

首先，我們定義一個枚舉類型來標(biāo)識事件類型：

enumeration eGameLogicMessage_Types {     
    GLMT_PLAYER_INPUT,     
    GLMT_PROJECTILE_WEAPON,     
    GLMT_GOAL_REACHED,     
};  

接著我們再創(chuàng)建一個枚舉類型來標(biāo)識事件的值：

enumeration eGameLogicMesage_Values {     
    GLMV_PLAYER_FORWARD,     
    GLMV_PLAYER_BACKWARD,     
    GLMV_PLAYER_LEFT,     
    GLMV_PLAYER_RIGHT,     
    GLMV_ROCKET_FIRED,     
    GLMV_ROCKET_HIT,     
};    

現(xiàn)在我們定義一個結(jié)構(gòu)體來存儲我們的消息數(shù)據(jù)：

view plaincopy to clipboardprint?struct sGameLogicMessage {     
    short type;     
    short value;     
} Message;    

現(xiàn)在，我們就可以像上一個例子代碼一樣，用一個對象來傳遞我們的消息：

void onPlayerInput( Input inputEvt ) {     
   if(inputEvt.type == IE_KEY && inputEvt.value == KEY_UP ) {     
       Message msg;     
       msg.type = GLMT_PLAYER_INPUT;     
       msg.value = GLMV_PLAYER_FORWARD;     
       g_myApp->sendGameLogicMessage( msg );     
   }     
    

這看起來作了更多的工作，但它運行起來會更有效率。前一個（壞的）例子用了20個字節(jié)來傳遞消息（20個字符各占一個字節(jié)，別忘了終止符）。第二個例子只用了4個字節(jié)來傳遞同樣的消息。但是更要的是，當(dāng)sendGameLogicMessage()處理方法的時候，它只需要分析兩個switch語句就可以找到正確的響應(yīng)，而前一個例子則組要從字符串進行解析，速度很慢。

人工智能

游戲邏輯的另外一個職責(zé)就是管理AI代理。兩類典型的游戲需要用到AI系統(tǒng)：一種是玩家與電腦競賽；另外一種是在游戲世界中有半自主系統(tǒng)的敵人。在這兩種情況下，AI代理為游戲世界中的物體的動作接受輸入并提供輸出。

在第一種類型游戲里，AI被稱作專家系統(tǒng)。它被期待用來模擬理解游戲規(guī)則的人的行為動作，并可以采取具有不同難度的策略來挑戰(zhàn)玩家。AI具有與玩家類似的輸入與輸出，可以近似的模擬玩家的行為。由于人類比現(xiàn)在的AI代理更擅長處理復(fù)雜信息，有時為專家系統(tǒng)提供的輸入信息要多于給玩家的，以使AI系統(tǒng)看起來更智能。

例如，在即時戰(zhàn)略游戲（RTS）中，戰(zhàn)爭迷霧用來限制玩家的視野，但AI敵人可以看見地圖上所有的單位。盡管這樣提高AI對抗更高智慧玩家的能力，但是如果優(yōu)勢變的太大，會讓人覺得AI在作弊。記住，游戲的重要點是讓玩家獲得樂趣，而不是讓AI擊敗他們。

在第二種類型的游戲中，可能有許多AI代理。每一個都獨立，其不是非常智能。在某些情況下，AI代理會直接面對玩家，而有些可能是中立狀態(tài)，甚至還有一些是前面兩種狀態(tài)的結(jié)合。

有些代理可能是完全愚笨的，提供特定的、有限的行為而且并不關(guān)心游戲世界中發(fā)生的事情。在走廊里面來來回回走動的敵人就是一個例子。有些可能是稍微有些愚笨，只有一個輸入和一個輸出，比如玩家可以打開和關(guān)閉的門。還有一些可能非常復(fù)雜，甚至懂得將它們的行為組合在一起。為AI代理選擇恰當(dāng)?shù)妮斎朐试S你模仿“意識”和增加現(xiàn)實性。

不論AI代理有多么簡單，一般都會它們使用狀態(tài)機。例如，第一個例子中的完全愚笨的物體必須記錄它在朝哪個方向走動；稍微愚笨的物體需要記錄它是開的狀態(tài)還是關(guān)的狀態(tài)。更復(fù)雜的物體需要記錄“中立”與“進攻性之間的”動作狀態(tài)，如巡邏、對抗與攻擊。

透明的暫停與繼續(xù)

將游戲視作具有主要游戲狀態(tài)的模擬是非常重要的。不要將現(xiàn)實世界時間與游戲時間混淆。如果玩家決定休息會兒，游戲必須可以暫停。之后，游戲必須可以平滑的繼續(xù)，就像任何事情都沒有發(fā)生一樣。由于IPHONE是移動設(shè)備，保存與繼續(xù)游戲狀態(tài)變得尤其重要。

IPHONE上，在一個時間點只允許一個應(yīng)用程序運行，用戶也希望這些應(yīng)用程序能夠很快載入。同時，他們希望能夠繼續(xù)他們在切換應(yīng)用程序之前所做的事情。這意味著我們需要具有在設(shè)備上保存游戲狀態(tài)，并盡可能快的繼續(xù)游戲狀態(tài)的能力。對于開發(fā)游戲，一項任務(wù)是要求保持現(xiàn)在的關(guān)卡并可以重新載入它使玩家即使在重新啟動應(yīng)用程序后也可以繼續(xù)游戲。你需要選擇保存哪些數(shù)據(jù)，并以一種小巧的、穩(wěn)定的格式將其寫到磁盤上。這種結(jié)構(gòu)化的數(shù)據(jù)存儲被稱為序列化。

根據(jù)游戲類型的不同，這可能比聽起來要困難的多。對于一個解謎游戲，你將僅需要記錄玩家在哪個關(guān)卡、以及現(xiàn)在記分板看起來是什么樣的。但是在動作類游戲中，除了記錄玩家虛擬人偶之外，你可能還需要記錄關(guān)卡中的每個物體的位置。在一個特定時間點，這可能變得難以管理，特別是當(dāng)希望它能夠很快完成。對于這種情況，你可以在游戲設(shè)計階段采取一些措施以確保成功。

首先，你必須決定什么東西是在保存游戲狀態(tài)時必須保存的。火焰粒子系統(tǒng)中的每根小火苗的位置并不重要，但是在粒子系統(tǒng)的位置在大型游戲中可能很重要。如果它們能從關(guān)卡數(shù)據(jù)中獲得，那么游戲中每個敵人的狀態(tài)可能并不重要。用這種方式進一步考慮，如果你可以簡單的讓玩家的虛擬人偶從check point開始的話，那玩家虛擬人偶的確切狀態(tài)與位置也可能不需要保存。

基于幀的邏輯與基于時間的邏輯

基于幀的邏輯是指基于單獨的幀的改變來更新游戲物體。基于時間的邏輯雖然更復(fù)雜但卻與實際游戲狀態(tài)更緊密，是隨著時間的流逝而更新游戲物體。

不熟悉游戲開發(fā)的程序員總是犯了將基于幀的邏輯與基于時間的邏輯混合的錯誤。 它們在定義上的區(qū)別是微妙的，不過如果處理不得當(dāng)，會造成非常明顯的BUG。

比如，讓我們以玩家移動為例。新手程序員可能寫出這樣的代碼：

void onPlayerInput( Input inputEvent ) {     
    if(inputEvt.type == IE_KEY && inputEvt.value == KEY_UP) {     
        //apply movement based on the user input     
        playerAvatar.y += movementSpeed;     
    }     
}   

每當(dāng)玩家按下按鍵，虛擬人偶像前移動一點。這是基于幀的邏輯，因為每次移動的變化都會潛在的伴隨著新的幀。事實上，在這個的例子中，每次玩家輸入事件都會發(fā)生移動。這或多或少有點像主循環(huán)的迭代。移動的可視化影響只有在主循環(huán)的下次迭代中才會反映，所以任何迭代中間的虛擬人偶移動都會浪費計算。讓我們做一下改進：

void onPlayerInput( Input inputEvent ) {     
    if(inputEvt.type == IE_KEY && inputEvt.value == KEY_UP) {     
        //save the input state, but don't apply it     
        playerAvatar.joystick = KEY_UP;     
    }     
    if(inputEvt.type == IE_KEY_RELEASE) {     
        playerAvatar.joystick = 0;     
    }     
}     
void Update() {     
    //update the player avatar     
    if( playerAvatar.joystick == KEY_UP ) {     
        playerAvatar.y += movementSpeed;     
    }     
}    

現(xiàn)在我們知道，在鍵被按下的過程中，每次游戲循環(huán)中都只會被賦予一次速度。但是，這仍然是基于幀的邏輯。

基于幀的邏輯的問題是，幀變化不會總是以相同的時間間隔發(fā)生。如果在游戲循環(huán)中，渲染或者游戲邏輯會比通常耗費更多的時間，它可能會被推遲到下一次循環(huán)中。所以，有時你需要有60幀每秒（fps），有時，你只需要30fps。由于移動是適用于幀的，有時你只會以通常的一半速度來移動。

你可以用基于時間的邏輯來準(zhǔn)確的表達移動。通過記錄自從上次幀更新的時間，你可以適用部分移動速度。用這種方式，你可以以每秒為單位來標(biāo)識移動速度，而不必關(guān)心當(dāng)前幀速率是多少，玩家虛擬人偶的速度是一致的：

void Update( long currTime ) {     
    long updateDT = currTime - lastUpdateTime;     
    //update the player avatar     
    if( playerAvatar.joystick == KEY_UP ) {     
        //since currTime is in milliseconds, we have to divide by 1000     
        // to get the correct speed in seconds.     
        playerAvatar.y += (movementSpeed * updateDT)/1000;     
    }     
    lastUpdateTime = currTime;     
}    

在這個例子中，移動速度的總量將會是相同的，不管是2fps還是60fps?；跁r間的邏輯需要一點額外的代碼，但是它可以使程序更精確而不必在乎暫時的延遲。

當(dāng)然可以用基于幀的邏輯來開發(fā)游戲。重要的是，不要混合它們。比如，如果你的圖形代碼使用基于時間的邏輯來渲染玩家虛擬人偶的移動動畫，但是游戲邏輯代碼卻使用基于幀的邏輯在游戲世界中來移動它，這樣移動的動畫將不能玩玩家移動的距離完全同步。

如果可能的話，請盡量移除基于幀的邏輯。基于時間的邏輯將會對你有更大的幫助。

游戲邏輯組織結(jié)構(gòu)

游戲邏輯代碼的核心功能就是管理游戲狀態(tài)的規(guī)則與進度。根據(jù)你的游戲設(shè)計，這可能意味著任何事情。但是，還是有一些基本模式基于制作的游戲的類型。

游戲邏輯不與任何一個特定的類相關(guān)聯(lián)，它游戲狀態(tài)對象中表現(xiàn)出來。當(dāng)主游戲狀態(tài)被初始化后，它將會為關(guān)卡載入與初始化必要的資源。例如猜謎游戲中的一組提示與單詞、玩家虛擬人偶的圖片數(shù)據(jù)以及玩家當(dāng)前所在區(qū)域的圖片數(shù)據(jù)。在游戲循環(huán)中，游戲邏輯將會接受用戶輸入，運行物理模擬，并負(fù)責(zé)處理所有的碰撞結(jié)局消息，模擬AI動作，執(zhí)行游戲規(guī)則。最后，當(dāng)應(yīng)用程序需要終止主游戲狀態(tài)，它會釋放釋放所有的游戲資源，并可能將游戲狀態(tài)保存到硬盤驅(qū)動器上。

根據(jù)游戲的復(fù)雜度，你可能會發(fā)現(xiàn)很方便進一步分解游戲邏輯。比如，如果你在開發(fā)一款冒險游戲，你可能有一個充滿環(huán)境數(shù)據(jù)（地面、建筑、河流、樹等）、可以移動、與玩家交互的實體（玩家虛擬人偶、敵人、非玩家角色、開關(guān)、障礙物等），各種GUI使玩家作出特殊動作和顯示重要信息的游戲世界。每種游戲特征都必須有大量的代碼。雖然它們合在一起才能組成完整的游戲，但是你還是可以保持它們的工作模塊化。

你可以創(chuàng)建一個Level Manager類來處理游戲關(guān)鍵，包括載入和卸載顯示在游戲世界中的物理與圖像數(shù)據(jù)與調(diào)用游戲引擎來偵測實體與游戲世界的碰撞。你還可以創(chuàng)建另外一個類或者一些類來處理游戲世界中存在的實體。每個類都載入和卸載渲染那些物體的必要的物理和圖片數(shù)據(jù)，以及包括控制它們的AI。

最后，你可能創(chuàng)建另外一個單獨的類來處理游戲中用戶交互，以保持代碼與三大概念獨立。

這個體系結(jié)構(gòu)適用于任何類型的游戲。首先評估游戲設(shè)計的主要特性，接著以某種方式組合，將相近的功能與數(shù)據(jù)組合在一起。

小結(jié)：

小結(jié)：iPhone 游戲開發(fā)教程 游戲引擎 （6）的內(nèi)容介紹完了，希望本文對你有所幫助！你應(yīng)該對創(chuàng)造一個游戲引擎時必須完成的任務(wù)有了一個基本的理解。這將會幫助我們在下一節(jié)創(chuàng)建這些元素，為我們的游戲做準(zhǔn)備。 想要深入了解iPhone  游戲引擎的更多內(nèi)容，請參考以下幾篇文章：

iPhone 游戲開發(fā)教程 游戲引擎 （1）

iPhone 游戲開發(fā)教程 游戲引擎 （2）

iPhone 游戲開發(fā)教程 游戲引擎 （3）

iPhone 游戲開發(fā)教程 游戲引擎 （4）

iPhone 游戲開發(fā)教程 游戲引擎 （5）