一般化Generalization是很重要的一個步驟卻也是常常被人忽略的一個細節簡單來說,就是把特殊用途的程式碼轉變成為一般用途的程式碼舉個例子來說,我現在有20種怪物的AI要寫直覺上我們會建立20個Class來分別實現但是事實上,真的需要那麼多嗎?仔細分析一下怪物的種類與特性地上爬的,天上飛的,水
進入這一個章節的最後一部份一口氣就介紹三小節State,Composite和Command不過不用太擔心,我想這篇文章會很短因為...我懶得打那麼多的字前兩篇文章不斷提到觀念,也是這個章節的中心思想當你遇到複雜的巢狀判斷式,或是冗長的判斷式時請毫不猶豫的簡化它!所以延續前面的主題,另外有三個Patt
這次來比較兩個有趣的東西:Strategy和Decorator同樣是巢狀邏輯判斷式的寫法改法不止限於上次提到的ComposedStrategy和Decorator也是不錯的選擇艾倫史密斯在互動元件那邊做了一個示範詳細內容我不贅述了,有興趣可以去找找看總之是在處理主角吸上互動元件後怎麼對主角施予重力和
結束了創建Creation的部分,接下來則是簡化Simplification 我想又臭又長的程式碼是沒有人可以接受的 因此如何簡化程式碼的內容,也成為一大課題 第一個上場的就是Composed Method 簡單來說,就是把太大的function拆解成為小function 除了簡化原本的程式碼外,也
最後一個是為了確保Factory唯一性所做的機制也就是DesignPatterns裡面的Singleton相信很多人都有使用過的經驗但是書中提到的卻是使用過度的Singletonitis指沈迷於Singleton裡面講了很多不需要使用Singleton的情形它最大的問題就是製造了全域的變數而且還是一
延續上一次的主題,再來看看Factory內部的建立流程一個AI需要載入Model,需要建立FSM,需要建立Physics...所以流程大概會有:// Load model and create callback functionm_pAM = NiActorManager::Create sFile
首先要道歉一下,我看書的速度真的太慢了...總之目前進入了第一大單元 - 創建Creation顧名思義的它就是要教你怎麼用好的方式去建立一個Class由於裡面內容牽扯到大量豬屎排程Design Patterns不熟的人還請搭配書本服用在我們建立一系列有繼承關係的Class,例如State Node會
最近在書上看到的,關於設計過頭與設計不足的一些現象,給大家做參考 設計過頭: 學完了DesignPattern就一昧的想要使用 結果原本短短幾行或一個Function就可以解決的問題 卻使用了複雜的架構當然是從DesignPattern學來的來完成,白白多寫了幾十行,甚至幾百行的Code 設計不足:
遊戲研究 (3)