※ 引述《cowbaying (是在靠北喔)》之銘言：
: 其實這概念是很簡單的
: 就是有沒有想通而已
: 遊戲開發時你要以開發者容易除錯跟測試的角度去看
: 基本上就像是你有幾種技能
: 例如有技能ab01, ab02, ab03
: 他們有些基本的屬性
: 1.傷害
: 2.範圍
: 3.特效
: 4.持續時間
: 5.冷卻時間
: 6.消耗物
: 7.屬性
: 8.技能名稱
: 我列一些基本的東西
: 然後我們在物件的設定檔案裡
: 通常是加密過的property檔或是自己開發的檔案格式來設定這些屬性
: 然後將傷害、範圍、特效...等等這7項分別寫成物件
: 本身技能總項一個物件
: 在啟動或初始化這些技能的時候就會組合這些物件然後依照你的設定一一觸發
: 完成一系列的工作
: 這個好處就是可以減少總記憶體的使用量
: ※ 引述《gyd (阿龍哥)》之銘言：
: : 是個野生wix三千
: : 目前負責過的案子, 我設計的架構上通常都會像這樣(以技能系統為例)
: : 命名這邊只用概念
: : base -- ability -- abilityA
: : |- abilityB
: : |- abilityC
: : |- buff -- buffA
: : |- buffB
: : 其中 base 管理 data, 處理radius/add/remove等等共用的事
: : ability 處理 施法/各技能階段等等ability專用的事
: : buff 處理 多久跳一次/持續時間/等等buff專用的事
: : abilityA...N 處理該技能在各階段該做的事
: : buffA...B 處理該buff在生效時及stackin/out時做的事
: : 其他如特效/model也是類似架構
: 你的架構離組件式似乎較遠
: 比較缺乏彈性
: 但敘述過少也很難斷定
: 歡迎討論
因為的確就不是組件式
我的想法是
你所列出的8個項目都比較偏向data的範疇, 實際上就算是拆成8個組件
也會互相綁的很死, 至少會跟主組件綁死
當然若是子類別應用範圍非常的廣, 拆成組件可以擺脫一些切分上的問題
例如
純model元件, 如地圖裝飾物
有生命的model元件, 如樹木
有技能有生命的model元件, 如角色
就至少會有三個類別
而實際的應用上, 拆成元件式的結果就是主組件內要寫很多讓組件彼此溝通用的api
否則拆成組件的意義就並不是這麼大了
個人認為
以系統來說, 拆成組件為佳
以gameplay來說, 繼承為佳
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.117.152.17
※ 文章網址: https://www.ptt.cc/bbs/GameDesign/M.1445936443.A.37F.html