iPhone 游戲開發教程 游戲引擎 （6）
iPhone 游戲開發教程 游戲引擎 （6）是本我要介紹的內容，繼續上一章開始介紹，本節主要介紹了事件的相關內容，先來看本文詳解。
解決高層次事件
一旦判定了用戶執行的物理動作，你的代碼必須能將它們轉換為游戲邏輯組件可以使用的形式。具體怎么做需要依賴于你的游戲的上下文，但是這里有幾種典型的形式：
如果玩家準備控制虛擬人偶，在玩家和游戲之間通常會有連續的交互。經常需要存儲當前用戶輸入的表現形式。比如，如果輸入裝置為遙桿，你可能需要在主循環中記錄當前點的x軸坐標和y軸坐標，并修正虛擬人偶的動量。玩家和虛擬人偶之間的是緊密地耦合在一起的，所以控制器的物理狀態代表著虛擬人偶的高層次的狀態模型。當遙桿向前撥動時，虛擬人偶向前移動；當“跳躍”按鈕按下時，虛擬人偶跳起。
如果玩家正與游戲地圖進行交互，那么需要另外一種間接的方式。比如，玩家必須觸摸游戲地圖中的一個物體，代碼必須將玩家在屏幕上的觸摸坐標轉化為游戲地圖的坐標以判定用戶到底觸摸到了什么。這可能只是簡單的將y軸坐標減去2D攝像機坐標的偏移量，也可能是復雜到3D場景中的攝像機光線碰撞偵測。
最后，用戶可能進行一些間接影響到游戲的動作，如暫停游戲、與GUI交互等。這時，一個簡單的消息或者函數會被觸發，去通知游戲邏輯應該做什么。
游戲邏輯
游戲邏輯是游戲引擎中是你的游戲獨一無二的部分。游戲邏輯記錄著玩家狀態、AI狀態、判定什么時候達到目的地、并生成所有的游戲規則。給出兩個相似的游戲，他們的圖像引擎與物理引擎可能只有細微差別，但是它們的游戲邏輯可能會有很大差異。
游戲邏輯與物理引擎緊密配合，在一些沒有物理引擎的小游戲中，游戲邏輯負責處理所有物理相關內容。但是，當游戲引擎中有游戲引擎的時候，需要確保兩者的獨立。達到此目的的最好方式就是通過物理引擎向游戲邏輯發送高層次的游戲事件。
高層次事件
游戲邏輯代碼應該盡可能僅處理高層次問題。它不應該處理當用戶觸摸屏幕時需要以什么順序將什么描畫到屏幕上，或者兩個矩形是否相交等問題。它應該處理玩家希望向前移動，什么時候一個新的游戲物體應當被創建/移除以及當兩個物體相互碰撞后應該做什么。
為了維持概念上的距離，處理低層次概念（諸如用戶輸入與物理引擎等）的代碼應當創建高層次的消息并發送給游戲邏輯代碼去處理。這不僅能保持代碼的獨立性與模塊化，還會對調試有所幫助。通過查看高層次消息傳遞的日志，你可以判定是沒有正確處理消息（游戲邏輯代碼的問題），還是沒有在正確的時機傳送消息（低層次代碼問題）。
一個非?；镜膫鬟f高層次消息的技術是寫一個String并傳遞它。假如玩家按下了上箭頭鍵，它的虛擬人偶必須向上移動。
- void onPlayerInput( Input inputEvt ) {
- if(inputEvt.type == IE_KEY && inputEvt.value == KEY_UP ) {
- g_myApp->sendGameLogicMessage( "player move forward" );
- }
- }
雖然上面的代碼對程序員來說通俗易懂，但對于電腦來說卻并不高效。它需要更多的內存與處理，遠比實際需要的多。我們應該用提示來替代用戶輸入方法。比起一個字符串，它使用一個"type"和"value"。由于可能的事件都是結構化的和有限的，因此我們可以使用整數和枚舉類型來我們消息中的事件信息。
首先，我們定義一個枚舉類型來標識事件類型：
- enumeration eGameLogicMessage_Types {
- GLMT_PLAYER_INPUT,
- GLMT_PROJECTILE_WEAPON,
- GLMT_GOAL_REACHED,
- };
接著我們再創建一個枚舉類型來標識事件的值：
- enumeration eGameLogicMesage_Values {
- GLMV_PLAYER_FORWARD,
- GLMV_PLAYER_BACKWARD,
- GLMV_PLAYER_LEFT,
- GLMV_PLAYER_RIGHT,
- GLMV_ROCKET_FIRED,
- GLMV_ROCKET_HIT,
- };
現在我們定義一個結構體來存儲我們的消息數據：
- view plaincopy to clipboardprint?struct sGameLogicMessage {
- short type;
- short value;
- } Message;
現在，我們就可以像上一個例子代碼一樣，用一個對象來傳遞我們的消息：
- 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個字節來傳遞消息（20個字符各占一個字節，別忘了終止符）。第二個例子只用了4個字節來傳遞同樣的消息。但是更要的是，當sendGameLogicMessage()處理方法的時候，它只需要分析兩個switch語句就可以找到正確的響應，而前一個例子則組要從字符串進行解析，速度很慢。
人工智能
游戲邏輯的另外一個職責就是管理AI代理。兩類典型的游戲需要用到AI系統：一種是玩家與電腦競賽；另外一種是在游戲世界中有半自主系統的敵人。在這兩種情況下，AI代理為游戲世界中的物體的動作接受輸入并提供輸出。
在第一種類型游戲里，AI被稱作專家系統。它被期待用來模擬理解游戲規則的人的行為動作，并可以采取具有不同難度的策略來挑戰玩家。AI具有與玩家類似的輸入與輸出，可以近似的模擬玩家的行為。由于人類比現在的AI代理更擅長處理復雜信息，有時為專家系統提供的輸入信息要多于給玩家的，以使AI系統看起來更智能。
例如，在即時戰略游戲（RTS）中，戰爭迷霧用來限制玩家的視野，但AI敵人可以看見地圖上所有的單位。盡管這樣提高AI對抗更高智慧玩家的能力，但是如果優勢變的太大，會讓人覺得AI在作弊。記住，游戲的重要點是讓玩家獲得樂趣，而不是讓AI擊敗他們。
在第二種類型的游戲中，可能有許多AI代理。每一個都獨立，其不是非常智能。在某些情況下，AI代理會直接面對玩家，而有些可能是中立狀態，甚至還有一些是前面兩種狀態的結合。
有些代理可能是完全愚笨的，提供特定的、有限的行為而且并不關心游戲世界中發生的事情。在走廊里面來來回回走動的敵人就是一個例子。有些可能是稍微有些愚笨，只有一個輸入和一個輸出，比如玩家可以打開和關閉的門。還有一些可能非常復雜，甚至懂得將它們的行為組合在一起。為AI代理選擇恰當的輸入允許你模仿“意識”和增加現實性。
不論AI代理有多么簡單，一般都會它們使用狀態機。例如，第一個例子中的完全愚笨的物體必須記錄它在朝哪個方向走動；稍微愚笨的物體需要記錄它是開的狀態還是關的狀態。更復雜的物體需要記錄“中立”與“進攻性之間的”動作狀態，如巡邏、對抗與攻擊。
透明的暫停與繼續
將游戲視作具有主要游戲狀態的模擬是非常重要的。不要將現實世界時間與游戲時間混淆。如果玩家決定休息會兒，游戲必須可以暫停。之后，游戲必須可以平滑的繼續，就像任何事情都沒有發生一樣。由于IPHONE是移動設備，保存與繼續游戲狀態變得尤其重要。
IPHONE上，在一個時間點只允許一個應用程序運行，用戶也希望這些應用程序能夠很快載入。同時，他們希望能夠繼續他們在切換應用程序之前所做的事情。這意味著我們需要具有在設備上保存游戲狀態，并盡可能快的繼續游戲狀態的能力。對于開發游戲，一項任務是要求保持現在的關卡并可以重新載入它使玩家即使在重新啟動應用程序后也可以繼續游戲。你需要選擇保存哪些數據，并以一種小巧的、穩定的格式將其寫到磁盤上。這種結構化的數據存儲被稱為序列化。
根據游戲類型的不同，這可能比聽起來要困難的多。對于一個解謎游戲，你將僅需要記錄玩家在哪個關卡、以及現在記分板看起來是什么樣的。但是在動作類游戲中，除了記錄玩家虛擬人偶之外，你可能還需要記錄關卡中的每個物體的位置。在一個特定時間點，這可能變得難以管理，特別是當希望它能夠很快完成。對于這種情況，你可以在游戲設計階段采取一些措施以確保成功。
首先，你必須決定什么東西是在保存游戲狀態時必須保存的。火焰粒子系統中的每根小火苗的位置并不重要，但是在粒子系統的位置在大型游戲中可能很重要。如果它們能從關卡數據中獲得，那么游戲中每個敵人的狀態可能并不重要。用這種方式進一步考慮，如果你可以簡單的讓玩家的虛擬人偶從check point開始的話，那玩家虛擬人偶的確切狀態與位置也可能不需要保存。
基于幀的邏輯與基于時間的邏輯
基于幀的邏輯是指基于單獨的幀的改變來更新游戲物體。基于時間的邏輯雖然更復雜但卻與實際游戲狀態更緊密，是隨著時間的流逝而更新游戲物體。
不熟悉游戲開發的程序員總是犯了將基于幀的邏輯與基于時間的邏輯混合的錯誤。 它們在定義上的區別是微妙的，不過如果處理不得當，會造成非常明顯的BUG。
比如，讓我們以玩家移動為例。新手程序員可能寫出這樣的代碼：
- void onPlayerInput( Input inputEvent ) {
- if(inputEvt.type == IE_KEY && inputEvt.value == KEY_UP) {
- //apply movement based on the user input
- playerAvatar.y += movementSpeed;
- }
- }
每當玩家按下按鍵，虛擬人偶像前移動一點。這是基于幀的邏輯，因為每次移動的變化都會潛在的伴隨著新的幀。事實上，在這個的例子中，每次玩家輸入事件都會發生移動。這或多或少有點像主循環的迭代。移動的可視化影響只有在主循環的下次迭代中才會反映，所以任何迭代中間的虛擬人偶移動都會浪費計算。讓我們做一下改進：
- 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;
- }
- }
現在我們知道，在鍵被按下的過程中，每次游戲循環中都只會被賦予一次速度。但是，這仍然是基于幀的邏輯。
基于幀的邏輯的問題是，幀變化不會總是以相同的時間間隔發生。如果在游戲循環中，渲染或者游戲邏輯會比通常耗費更多的時間，它可能會被推遲到下一次循環中。所以，有時你需要有60幀每秒（fps），有時，你只需要30fps。由于移動是適用于幀的，有時你只會以通常的一半速度來移動。
你可以用基于時間的邏輯來準確的表達移動。通過記錄自從上次幀更新的時間，你可以適用部分移動速度。用這種方式，你可以以每秒為單位來標識移動速度，而不必關心當前幀速率是多少，玩家虛擬人偶的速度是一致的：
- 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。基于時間的邏輯需要一點額外的代碼，但是它可以使程序更精確而不必在乎暫時的延遲。
當然可以用基于幀的邏輯來開發游戲。重要的是，不要混合它們。比如，如果你的圖形代碼使用基于時間的邏輯來渲染玩家虛擬人偶的移動動畫，但是游戲邏輯代碼卻使用基于幀的邏輯在游戲世界中來移動它，這樣移動的動畫將不能玩玩家移動的距離完全同步。
如果可能的話，請盡量移除基于幀的邏輯。基于時間的邏輯將會對你有更大的幫助。
游戲邏輯組織結構
游戲邏輯代碼的核心功能就是管理游戲狀態的規則與進度。根據你的游戲設計，這可能意味著任何事情。但是，還是有一些基本模式基于制作的游戲的類型。
游戲邏輯不與任何一個特定的類相關聯，它游戲狀態對象中表現出來。當主游戲狀態被初始化后，它將會為關卡載入與初始化必要的資源。例如猜謎游戲中的一組提示與單詞、玩家虛擬人偶的圖片數據以及玩家當前所在區域的圖片數據。在游戲循環中，游戲邏輯將會接受用戶輸入，運行物理模擬，并負責處理所有的碰撞結局消息，模擬AI動作，執行游戲規則。最后，當應用程序需要終止主游戲狀態，它會釋放釋放所有的游戲資源，并可能將游戲狀態保存到硬盤驅動器上。
根據游戲的復雜度，你可能會發現很方便進一步分解游戲邏輯。比如，如果你在開發一款冒險游戲，你可能有一個充滿環境數據（地面、建筑、河流、樹等）、可以移動、與玩家交互的實體（玩家虛擬人偶、敵人、非玩家角色、開關、障礙物等），各種GUI使玩家作出特殊動作和顯示重要信息的游戲世界。每種游戲特征都必須有大量的代碼。雖然它們合在一起才能組成完整的游戲，但是你還是可以保持它們的工作模塊化。
你可以創建一個Level Manager類來處理游戲關鍵，包括載入和卸載顯示在游戲世界中的物理與圖像數據與調用游戲引擎來偵測實體與游戲世界的碰撞。你還可以創建另外一個類或者一些類來處理游戲世界中存在的實體。每個類都載入和卸載渲染那些物體的必要的物理和圖片數據，以及包括控制它們的AI。
最后，你可能創建另外一個單獨的類來處理游戲中用戶交互，以保持代碼與三大概念獨立。
這個體系結構適用于任何類型的游戲。首先評估游戲設計的主要特性，接著以某種方式組合，將相近的功能與數據組合在一起。
小結：
小結：iPhone 游戲開發教程 游戲引擎 （6）的內容介紹完了，希望本文對你有所幫助！你應該對創造一個游戲引擎時必須完成的任務有了一個基本的理解。這將會幫助我們在下一節創建這些元素，為我們的游戲做準備。 想要深入了解iPhone 游戲引擎的更多內容，請參考以下幾篇文章：
