首先關於遊戲實體，最早有這個概念是看了這篇文章---遊戲Entity設計不完全整理

最早接觸遊戲程式設計的時候，看的是老師的程式碼，類似於早期的遊戲，使用的是最傳統的繼承模式的實體系統。當時就覺得繼承就是面向物件的一切，認為只要不斷的繼承就能解決所有問題。到後來才發現，繼承的一個嚴重的缺陷是你必須知道所有父類的具體實現，到了最後一個實體也變得非常臃腫且難以修改。後來接觸了設計模式，知道了策略模式這東西，大概的意思就是使用組合代替繼承，個人認為元件模式更多的就是使用了策略。

總之，第一次接觸元件模式的時候感覺很興奮，認為一旦有了這種系統，無論策劃怎麼變，修改起來都是輕而易舉的。於是立刻找了相關資料開始嘗試實現，但是真正去實現之後才發現這玩意真不容易，越寫越沒思路，後來只能放棄。

後來跟一個朋友提起這個系統，然後他也嘗試去弄了一下，相互交流之後感覺思路更開闊，不過苦於工作繁忙一直沒時間再去弄，而且實際上對這個模式依舊是隻有一個模糊的概念。其實期間一直在想辦法找到可以參考的框架，那樣就可以站在巨人的肩膀上去看元件模式。後來又接觸了U3D，發現這玩意不正是元件模式的設計嗎，於是迫不及待去看她的API，還去看了相關教程，然後就非常手癢的想實現一個看看。這時候公司說要做頁遊，於是就讓我去搭框架，我第一個就想到了元件模式，而且第一個想法是直接複製U3D的那套。

雖然複製的話結果不需要想太多，但到了細節就不知道怎麼實現了，比如實體具體該怎麼建立，原型和克隆該怎麼管理，最關鍵的是元件的動態新增和刪除問題。雖然遊戲中去給一個實體新增元件或者刪除元件的情況不多見，但是有的時候還是想那麼做，而其中最麻煩的就是元件之間的依賴問題，相互依賴的元件要如何找到對方是個問題。後來為了簡單就放棄這個功能，所有元件實現新增好，之後一起初始化。最好不得不佩服U3D漂亮的解決了很多細節問題，那些細節我都直接放棄掉了，而且U3D有編輯器幫助，我們是不可能實現那樣一個編輯器。同時也發現，遊戲除了實體，還有很多重要的東西，比如場景管理，資源管理，GUI，與伺服器的同步，以及遊戲的核心邏輯等。由於剛接觸網遊，對怎麼與伺服器同步並沒有很好的解決方案。場景管理東拼西湊基本上還能湊合，而最棘手的估計是遊戲的核心邏輯，這也是任何框架都躲不開的一個東西。總之去寫一個ARPG的喲徐，就會發現自己對狀態機的把控能力實在有限，需要找時間補一補。另外棘手的還有物件間的互動，本身很多互動都在伺服器完成，但是實際上加了這一步才不知道從何下手為好，因為伺服器只負責結果的計算，時間過程需要客戶端根據結果來模擬，於是以前棘手的“怎麼去互動”變成了更棘手的“什麼時候去怎麼去互動”。還有資源的動態裝載，雖然已經想到了自認為不錯的解決辦法，不過還沒有去實現專案就已經擱淺了。。。

於是有時候會想，可能夠用就好，可能不需要實體系統，不需要設計得太複雜，但是實際上很多時候是不知道怎麼樣才算夠用，如何巨集觀的去把控一個遊戲框架？感覺程式設計就是不斷在和程式的複雜度做鬥爭，於是引用一句話：既想馬兒跑又想馬兒不吃草是不現實的，複雜度不會平白無故地被抹消，所以必須有所取捨。於是又補上自己的話：策劃不會讓你舍，你自己也會告訴自己捨棄得太多就沒了競爭力。於是這大概就是寫程式的為什麼個個都變成苦逼的原因。。。