Unity 組件

組件(Component)這個概念最先是在2005年《Game Programming Gems 5》的《Component Based Object Management》中接觸到的，當時感受在設計上很實用。後來，發現Unreal Engine 3的一個重要的改進就是拋棄了之前的基於純派生關係的對象 模型 ，而轉爲使用 基於組件 的對象 模型 。對於這種設計思想，Unity比Unreal貫徹的更完全——一切皆Component。 那麼到底什麼是「基於組件」的對象 模型 ？它可以解決什麼問題？ 在傳統的設計中，咱們通常會使用「派生」來描述對象之間的關係。子類經過派生父類，來得到父類的功能。在設計遊戲對象時，會根據遊戲自己的須要而爲遊戲對象添加各類功能支持，好比渲染，碰撞，剛體，粒子系統等等。這些通用功能爲了可以爲各類派生類提供服務，都必須實現到基類中。這樣就致使了遊戲對象基類變得很是龐大臃腫，即難使用，又難維護。 」基於組件「的對象 模型 就是把全部須要提供給遊戲對象的基礎功能都獨立成單獨的」組件模塊「(Component)，一個具體的遊戲對象能夠將它須要的功能模塊組合到一塊兒使用。全部」功能「再也不是父類中的接口，而變成子對象實例，爲遊戲對象提供服務。這樣既保證了功能代碼的可重用性，又增長了整個對象體系的模塊化和靈活度。 在Unity中，GameObject除了做爲Component的容器以外，基本上沒有其餘功能。全部須要的功能都要經過組合Component來實現。腳本自己也是Component，用來在GameObject上經過控制其餘Component來實現自定義的功能。雖然這些Component在物理上是徹底並列的關係，可是他們之間仍是會有必定的層次關係的。在設計一個遊戲對象的具體功能時，組件通常會被分爲三個層次。 引擎的基礎組件 Unity自己提供的各類內部功能組件。好比渲染組件，物理組件，聲音組件等等。這些組件實現了全部引擎提供的基礎功能，會被腳本使用來組合高級功能。 模塊功能腳本組件 經過腳本實現的一些相對獨立的通用模塊功能的組件。這類 組件的設計 是腳本可重用的關鍵，須要仔細分析遊戲對象中哪些功能能夠被獨立出來成爲一個可重用的功能模塊組件，而且在實現上應該儘可能下降與其餘組件的耦合性。好比在設計一個角色遊戲對象時，須要爲他設計換裝功能。換裝功能其實就是對顯示子對象進行分組管理，切換顯示狀態。這個功能相對獨立，與其將他實現到角色中，不如獨立成一個功能模塊組件。角色遊戲對象和其餘全部須要換裝功能的遊戲對象均可以經過包含這個模塊組件來實現換裝功能。 模塊功能組件之間還可能有依賴關係，也就是一個功能模塊組件可能依賴與另外一個功能模塊組件，從而在這個組件層次上造成更多的子層次。 高層的膠水代碼腳本 這些腳本用來真正將引擎基礎組件和模塊功能組件組合到一塊兒實現最終遊戲對象邏輯。用「膠水代碼」來形容這些腳本很是的貼切，就是把全部這些子功能「粘」在一塊兒。好比設計一個Player腳本，將全部須要的組件功能組合起來，實現一個玩家的具體遊戲邏輯。由於這一層次表明的都是最高層的遊戲行爲控制對象，是具體的遊戲邏輯的「膠水」代碼，不會再爲更上層提服務，因此自己的可重用性並不高。可是這些對象之間按照類型區分，每每會有一些功能上的重合，因此反而能夠繼續使用派生關係來實現功能的重用。好比在Character中實現全部的基礎功能(這些功能又是經過組合基礎組件來實現的），而Player和NPC都從Character派生，來繼承全部Character的功能，並繼續實現本身特殊的功能。一個功能到底應該用組件實現仍是用派生實現並無很是明確的界限，應該根據須要靈活運用。 在使用Unity的過程當中，若是要實現的是demo級別的小工程，並不須要考慮不少，直接用腳本實現功能就能夠了。可是若是要有效地組織複雜的工程，提升代碼的重用性，充分理解和合理的利用「基於組件」的對象 模型 設計思想仍是很重要的。