有關遊戲物件實現的描述，前面兩篇文章中說的不甚清楚，主要是一直都要引用網上能夠找到的資料來進行描述，以避免與公司引起不必要的麻煩。所以語言有些拼湊的感覺，舉的例子也很不恰當，今天正好看到了遊戲程式設計精粹五和六上的兩篇文章，內容都差不多，《基於元件的物件管理》和《基於元件的遊戲物件系統》，說的也是我上兩篇文章想要描述的內容，所以再補一篇，引用其中的部分文字進行明確的說明。
傳統的遊戲物件管理系統採用繼承的方式來實現，例如，所有的子類都從cobject派生。大多數情況下，直接派生的也是抽象類，其中帶一些功能而另一些子類則不帶這些功能，比如可控制/不可控制，可動畫/不可動畫等。mangos的實現中基本就是這種情況，從object直接派生的unit和worldobject都是不可直接例項化的類。
傳統方法的問題在於無法應對需求的變化，如要求**也有動畫效果時就無法處理了。如果硬要是這樣做，那隨著需求的嗇，很多的方法會被放到基類中，最終的結果是繼承樹變得越來越頭重腳輕，這樣的類會喪失它的內聚性，因為它們試圖為所有物件完成所有的事。
就是說到最後，基類會有乙個很長的介面列表，而很多的遊戲物件型別根本不需要實現其中的一些甚至大部分介面，但是按照這種結構卻又必須去實現。以至於於實現乙個非常龐大的物件，而且想要修改一點功能會導致系統的大調整。
我們希望的系統是可以將現有的功能組合到新的物件中，並且在將新的功能新增到現有的物件中時不需要重構大量的**和調整繼承樹的結構。
實現的方法就是從元件來建立乙個物件。元件是乙個包含所有相關資料成員和方法的類，它完成某個特定的任務。把幾個元件組合在一起就可以建立乙個新的物件。如把entity元件、render元件和collectable元件組合在一起生成了乙個spoon物件。entity元件讓我們可以把物件放到遊戲世界中，render元件讓我們可以為物件指定乙個模型進行渲染，而collectable元件讓我們可以拾取這個物件。
關於元件的實現，所有的元件都從乙個基礎元件介面派生，可稱其為icomponent。每個元件也有自己的介面定義，並且這個介面也需要從icomponent派生，類似於這樣：icomponent -- icmprender -- ccmprender
元件之間的通訊有兩種方法，一是用元件id查詢到元件介面指標，然後呼叫介面方法；二是使用訊息的方式，向物件中所有元件發訊息。在初始化的時候，每乙個元件型別都會告訴物件管理器應該接收什麼樣的訊息。
查詢介面的方法也就是直接的方法呼叫，只不過介面不是全部在基類中，所以必須先查找到指定的元件然後才能呼叫其介面。訊息的使用前面已經說過多次，其實現方案也有過說明。
最後是關於遊戲物件功能的擴充套件和遊戲物件的定義。需要擴充套件功能也就是需要實現乙個新的元件，或者修改現在元件。在大多數情況下，擴充套件都不會引起結構的很大調整，受影響的最多只是使用到該元件的部分**。
遊戲物件定義可採用完全資料驅動的方式，使用xml或者指令碼語言來定義物件型別，以及每個型別需要載入的元件。物件型別註冊到物件管理器後，由管理器提供建立指定型別的物件的方法。資料驅動的方式能夠讓策劃自由定義遊戲物件型別，並且隨時可自由建立新的物件型別。
遊戲物件的實現 補
有關遊戲物件實現的描述，前面兩篇文章中說的不甚清楚，主要是一直都要引用網上能夠找到的資料來進行描述，以避免與公司引起不必要的麻煩。所以語言有些拼湊的感覺，舉的例子也很不恰當，今天正好看到了遊戲程式設計精粹五和六上的兩篇文章，內容都差不多，基於元件的物件管理 和 基於元件的遊戲物件系統 說的也是我上兩...
九 物件導向 補
this關鍵字表示當前物件本身,一般用於類的內部,其內部存在乙個位址,指向當前初始化的物件本身.new 乙個物件時,其實產生了兩個引用,兩個引用執行同一記憶體空間 物件 所以類中用this來表示當前物件,因為不用this,我們是不知道在建立物件時具體的物件名的 1.呼叫成員變數 用於解決成員變數與區...
補間動畫的實現
public class mainactivity extends activity 1.利用xml實現漸變的補間動畫 private void initalpha 1.用 實現漸變的補間動畫 private void codealpha 2.用xml實現縮放 private void scalea...