????? 軟件復用程度的級別可以按以下準則來衡量（級別從低到高）：
（1）函數：將那些重復或者類似的程序集中起來放在函數里，對外提供參數以利復用，是功能型的重用；
（2）實在類：將若干經常使用的函數集中起來，將函數的參數轉化為類的成員變量，自定義構造和銷毀函數，是資源型的重用；
（3）抽象類：使用純虛函數對外提供接口，這些接口僅僅聲明了基類的功能，而將實現拖延到子類中去，是強調可變性的資源型重用；
（4）包：將若干耦合度較大的類集中起來，統一地對外提供接口，是一種有機的資源型重用；
（5）模板：將變量的類型通用化，它是一種強調通用性的資源型重用，可以應用在上面四個層次上；
（6）組件：封裝了數據和方法的可執行代碼，上面五種都屬于代碼級的復用，而組件屬于軟件級的重用。
??????? 游戲一般規模都很大，保持結構清晰是首要的問題。我們知道大型系統一般都可以分為MVC三部分，實踐證明這種結構行之有效。本人將之應用在游戲設計中總結出若干經驗：
（1）將建模和交互兩部分分開，建模階段采用工廠模式，利用資源管理器統一創建、銷毀和調度資源；
（2）交互包括顯示和操縱兩部分，其實可以統一由圖形界面實現；
（3）邏輯使用腳本加解釋器的方式實現，這樣可以在游戲之外修改游戲；
（4）將場景作為游戲的基本單位，將物理系統和效果系統獨立出來，場景可以透明使用和替換它們；
（5）針對應用自定義消息，開辟若干線程，使用線程消息機制來進行消息響應；
（6）注意類的粒度的問題，類之間的交互只好保持在同一級，這樣有利于擴展和移植。
???????? 游戲設計最理想的情況就是美工做資源，設計師寫腳本，然后運行一下可復用的引擎就把游戲搞出來了。雖然難度不小，但是可以沖著這個目標努力，最最關鍵的還是要有合理的體系結構。
????????
??? 從電子游戲的開發難度來看，它不亞于開發一個小型的操作系統，為什么這么說呢？首先在計算量方面，由于電子游戲是三維的，CPU計算量非常大；其次在資源管理方面，顯卡和內存的使用要精打細算；第三，游戲中的對象之間的通信十分頻繁，大部分消息的檢測和響應都要自定義。實際上，開發電? 子游戲的時候是要借鑒很多操作系統的思想的，比如基于多線程的消息系統，基于組件的窗口系統等。
??? 從電子游戲的內容來看，它比操作系統更高級。傳統的操作系統都是桌面式的，而電子游戲擁有自己的一個虛擬空間，甚至連它的GUI也是三維的。我們知道從無圖形的DOS到有圖形的Windows是一個很大的進步，而從平面到立體則是一個更大的進步。我個人認為在計算機方面，天才來自以下幾個領域：網絡黑客，操作系統開發者，再有就是游戲設計師。
??? 其實電子游戲更應該叫虛擬環境，它的很多技術和思想都可以移植到專業的圖形系統中去，實際上很多的虛擬戰場系統就是基于類似的游戲開發的，所以我認為電子游戲絕對不是只有娛樂價值。可以這么說，如今的電子游戲既是應用系統，又是操作系統，它是一種技術含量很高的軟件，應該得到程序員足夠的尊重。
??????? 此次會議發生了如下一些趣事：參加了唐澤圣教授的頒獎儀式，跟石教英教授一起排隊打飯，跟彭群生教授同桌吃飯，跟Ahmad Nasri樓外樓同桌聚餐，參觀CAD&CG國家重點實驗室，欣賞了西湖夜景。對幾個老師印象比較深刻：齊東旭，鮑虎軍，胡事民。收獲了兩本論文集：唐澤圣論文集和石教英論文集。總的感覺是長了見識，見到了許多圖形系統的演示，并且認識了不少圖形學方面的朋友。可以肯定的是：在圖形學方面，浙江大學是國內最好的。總而言之一句話：雖然圖形學是騙眼睛的，但是我熱愛它。
?????? 完成Transformer 2.0之后，我已經靜心思考了一段時間。我剛拜讀了“四人幫”所著的《設計模式》一書，發現2.0中已經使用了其中的六種了，分別是Factory、Singleton、Chain、Command、Interpreter、Observer。其它的模式也基本上看得懂。接下來打算將State、Strategy應用到3.0中。三種類型的設計模式：創建型、結構型和行為型，我認為行為型最有用，因為游戲中一則對象多，二則通信頻繁。為更好地解決該問題我將在3.0中借鑒經典的設計模式。State是狀態機，可以用在游戲狀態的切換上；Strategy是算法，可以用在物理系統的實現上。我的經驗是：設計模式能夠讓你既優雅又高效地解決問題。