一直以來都有個疑問
雖然物件導向教學都說繼承與多型是OOP的特色
不過在遊戲設計時常常需要製作很多同一個架構但不同功能的類別
比如說技能，部隊這一類
我是應該遵照OOP的特色，為每一種技能實作一個類別呢？
還是應該寫在同一個類別裡，透過控制屬性去產生不同效果呢？
又或是有其他更好的方法呢？
我目前是採用多類型的作法，但是類型一多又總覺得看起來很亂
因為我程式都是自學為主，所以想請問一下通用的作法是哪一種
麻煩各位先進提供一下意見

如果用不同的property就能達到效果，那一個類別就夠了但如果程式碼中充滿switch case判斷式，就應該用多型如果你不知道規則，就思考一下增加新技能時需要做什麼好的設計是你只需要添加程式碼，不用修改既有程式碼亦即所謂 open-close 的原則

open-close嗎... 嗯嗯，我會多留意 謝謝

同樓上 用文檔設定的方式來設計技能是比較經濟的方式但切記資料要加密阿...

也可以參考版上Component-Based的那篇

當下流行的架構是組件式，之後會不會有新的流行不一定也有人繼承式和組件式混和用，像我們公司就是這樣最基本的幾種物件架構是以繼承方式組成，專精的細功能則是用組件的方式組合起來

Interface和Component混搭還蠻常見的概念上是：先定義好你這堆需要多型的物件會有怎樣的操作介面，但實作上用delegation的方式轉交給Component這樣你的物件就能輕巧靈活組合(component-based的優點)但又能有共通的操作介面和型別(多型的優勢)

通用的作法: 支援LUA script,方便做MOD.

介面我還不太會用呢XD 不是很理解介面該用在什麼情況

地方板上需要更多的組件式OOP資源←在unity寫子彈常常會覺得我到底是要組件還是多型...

組件導向似乎很適合遊戲 但是組件要寫得夠抽象好像很難..

其實就是一個 obj.AddComponent(component) 介面剩下自由發揮還有，不要陷入"要寫一個超完美引擎"的圈套裡把遊戲做出來比較重要，反覆產出遊戲之後，自然就會對遊戲引擎架構有比較好的概念人家Unreal也是副產品，他們不是一開始就以開發商業引擎為目的，而是不斷產出遊戲之後，一個可以拿來賣的引擎才慢慢成形老話一句 "Make games, not game engines."

引擎是以前寫遊戲的副產物，除非是要賣引擎才要寫到完美

靠要 這篇推文都是神

之前也有遇過同樣的困擾，後來發現會困擾的原因是，不論是類別還是參數控制都是對的，對底層運作而言不需要類別只需要參數，對設計者自己控制而言把參數類別化控制就不用煩惱細節，結論:混用就好..

我的作法跟火星大一樣 這麼做比較好用而且清楚傷害計算跟演出最好分開一點 不要寫在一起

大推cjcat2266大大說的!! 豁然開朗