這篇文章想主要說明一下在Unity3D遊戲開發中是如何寫遊戲腳本的，對於Unity3D這套遊戲引擎來說入門極快，可是要想做好卻非常的難。這篇文章的目的是讓哪些已經上手Unity3D遊戲引擎的朋友學會如何更好的寫遊戲腳本。首先我們看看遊戲主要是由哪幾部分組成的，如下圖所示，任何平臺下的任何遊戲核心都是由：數據、邏輯、渲染三大部分組成。
當你寫過>=2個平臺下的遊戲時你會發現其實遊戲開發很“容易”，爲什麼“容易”呢？因爲此時你會發現所有平臺下開發遊戲的模式，如下圖中的“數據”與“邏輯”兩部分真的是完全一樣的，這兩部分是與遊戲開發平臺無關的。然而真正與遊戲平臺有關的緊緊是“渲染”這部分，因爲各個遊戲平臺下的渲染接口是不同的。這也就印證了一點，能把J2ME遊戲寫好的程序員就必然能把IOS或Android遊戲同樣的寫好。讀到這裏請結合一下你的公司情況，你可能會發現在你的技術總監兩三天就能上手Unity3D遊戲開發 Cocos2d遊戲開發，這並不是他對遊戲平臺研究的透徹，而是他對遊戲數據的掌控能力非常強，所以能很快玩轉各個平臺下的開發。
如下圖所示，Unity3D這套遊戲引擎在遊戲開發中的權重如圖中所示。其中包含100%的渲染部分 +50％左右的邏輯部分。（因爲Unity3D封裝了很多與邏輯相關的API供開發者使用）
下面我們回到Unity3D腳本架構的編寫上，我們知道Unity3D在是可以創建遊戲場景的，在每個遊戲場景中又可以創建遊戲對象，把每個場景的遊戲對象融合在一起就是一款3D遊戲。遊戲場景之間屬於同等級的關係，爲了讓遊戲場景之前交互我們需要有一個凌駕所有場景之上的腳本，我稱之爲“全局腳本”。如下圖所示，所有場景都能與這個唯一的全局腳本進行交互。舉個例子，當場景切換時可將臨時邏輯數據寫入全局腳本中，切換完畢後再去全局腳本中取之前保存的數據，從而實現交互。（當然還有別的辦法也能實現這個效果，但是我覺得這樣做會更好一些，數據會更安全一些）
接着我們就進入場景中，遊戲場景是由若干遊戲對象組成，下面我好好說一說遊戲對象。遊戲對象是需要綁定遊戲腳本才能完成它的生命週期。那麼腳本的使命就會尤其的重要。因爲遊戲對象比較多那麼腳本必然會出現交互的情況，如下圖所示，很多初期Unity3D的項目中的腳本會編寫成這個樣子。錯綜複雜相互交互，這樣編寫的腳本有可能你的遊戲能做出來，可是你在維護的時候團隊開發的時候你會發現你的腳本非常的混亂，別的同事想改都不知道怎麼改。（顯然這樣的作法時完全錯誤的）
我們想想爲什麼腳本之間要交互，原因很簡單。是因爲腳本中需要使用/調用另一條腳本或者另一條腳本對應的遊戲對象某一項數據/方法，爲了解決這個問題而導致最終的腳本非常混亂。爲了避免這個問題，我在開發中會這麼做，如下圖所示，腳本之間切記不要做直接的相互交互，腳本之間只做間接的交互。每一個遊戲場景都有一個凌駕所有遊戲對象之上的單例腳本，在這條腳本中保存場景中所有腳本的公共數據。包括該場景的整體邏輯更新都是在這條單例腳本中完成。每條腳本都只與這個單例腳本做交互，和別的腳本一概不交互。（間接交互）
編寫腳本時請注意，腳本只幹屬於自己最重要的事情，就跟代碼中的函數一樣，只幹最重要的事情。切記和該條腳本無關的事情不要去管，不要在腳本中做過多的相互連帶工作，讓所有連帶工作的話都放在全局單例腳本中來做。
這裏我們舉一個例子，主角砍怪或技能攻擊怪，怪物受傷只到怪死亡以後屏幕播放一段勝利動畫。
1.主角對象發動攻擊，全局單例腳本接受按鍵事件後通知主角腳本播放攻擊動畫。
2.敵人對象接受到主角發送攻擊消息時開始播放受傷動畫，敵人腳本接收到主角的碰撞時詢問單例腳本 主角是“普通攻擊、還是技能攻擊”，接着敵人播放對應的受傷動畫，根據攻擊類型敵人對象開始減血。
3.重複上面的操作，當敵人的血量《=0的時。敵人銷燬自身對象，並且敵人腳本告訴單例腳本自己已經死亡。此時，單例腳本在調用“勝利動畫”對象播放勝利動畫效果。
上述邏輯我是完全按照剛剛圖片中所說明的方式來寫，這樣做就可以很好的避免交互交互混亂的情況，其實開發中的所有類似這種交互的情況都能很好的用這個全局單例腳本來解決。希望廣大Unity3D開發愛好者可以和我討論，因爲我知道架構設計沒有最好只有更好。嚯嚯！！
雨鬆MOMO 2012年11月06日 於 雨鬆MOMO程序研究院 發表
