作者wix3000 (癢，好吃)
看板GameDesign
標題[請益] 遊戲製作時的多型?
時間Sat Oct 24 09:58:12 2015
一直以來都有個疑問
雖然物件導向教學都說繼承與多型是OOP的特色
不過在遊戲設計時常常需要製作很多同一個架構但不同功能的類別
比如說技能，部隊這一類
我是應該遵照OOP的特色，為每一種技能實作一個類別呢？
還是應該寫在同一個類別裡，透過控制屬性去產生不同效果呢？
又或是有其他更好的方法呢？
我目前是採用多類型的作法，但是類型一多又總覺得看起來很亂
因為我程式都是自學為主，所以想請問一下通用的作法是哪一種
麻煩各位先進提供一下意見
--
███ ︵︵︵︵ █◤ ◢█◤ ちから
██ ／＼｜｜｜█ ◢█◤ 「ひとりでは耐え切れぬ 雷 でもきっと、
▄█│‵╯︶︶| ██◤ # ふたりなら大丈夫私は信じる！」
▔█ ╲ ） ∕█████◣ +
+ █ ╮ - │██◣ ◥◥█◣ ◢ 第四巻 27ページ…
▂▄▆█│ │██◤* ◢████◣ 雷神の系譜 ψWix
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 219.85.240.42
※ 文章網址: https://webptt.com/m.aspx?n=bbs/GameDesign/M.1445651896.A.A0C.html
※ 編輯: wix3000 (219.85.240.42), 10/24/2015 09:59:37
1F：推 littleshan: 如果用不同的property就能達到效果，那一個類別就夠了 10/24 10:02
2F：→ littleshan: 但如果程式碼中充滿switch case判斷式，就應該用多型 10/24 10:05
3F：→ littleshan: 如果你不知道規則，就思考一下增加新技能時需要做什麼 10/24 10:07
4F：→ littleshan: 好的設計是你只需要添加程式碼，不用修改既有程式碼 10/24 10:08
5F：→ littleshan: 亦即所謂 open-close 的原則 10/24 10:08
6F：→ wix3000: open-close嗎... 嗯嗯，我會多留意 謝謝 10/24 10:25
7F：推 cowbaying: 同樓上 用文檔設定的方式來設計技能是比較經濟的方式 10/24 10:53
8F：→ cowbaying: 但切記資料要加密阿... 10/24 10:54
9F：推 ddavid: 也可以參考版上Component-Based的那篇 10/24 10:55
11F：推 cjcat2266: 當下流行的架構是組件式，之後會不會有新的流行不一定 10/24 13:26
12F：→ cjcat2266: 也有人繼承式和組件式混和用，像我們公司就是這樣 10/24 13:27
13F：→ cjcat2266: 最基本的幾種物件架構是以繼承方式組成，專精的細功能 10/24 13:28
14F：→ cjcat2266: 則是用組件的方式組合起來 10/24 13:28
15F：推 holymars: Interface和Component混搭還蠻常見的 10/24 15:02
16F：推 holymars: 概念上是：先定義好你這堆需要多型的物件會有怎樣的操作 10/24 15:04
17F：→ holymars: 介面，但實作上用delegation的方式轉交給Component 10/24 15:07
18F：→ holymars: 這樣你的物件就能輕巧靈活組合(component-based的優點) 10/24 15:09
19F：→ holymars: 但又能有共通的操作介面和型別(多型的優勢) 10/24 15:09
20F：→ enthos: 通用的作法: 支援LUA script,方便做MOD. 10/24 15:56
21F：→ wix3000: 介面我還不太會用呢XD 不是很理解介面該用在什麼情況 10/24 17:58
22F：→ KanoLoa: 地方板上需要更多的組件式OOP資源 10/24 19:47
23F：→ KanoLoa: ←在unity寫子彈常常會覺得我到底是要組件還是多型... 10/24 19:49
24F：→ wix3000: 組件導向似乎很適合遊戲 但是組件要寫得夠抽象好像很難.. 10/24 20:01
25F：推 cjcat2266: 其實就是一個 obj.AddComponent(component) 介面 10/25 03:50
26F：→ cjcat2266: 剩下自由發揮 10/25 03:50
27F：推 cjcat2266: 還有，不要陷入"要寫一個超完美引擎"的圈套裡 10/25 03:52
28F：→ cjcat2266: 把遊戲做出來比較重要，反覆產出遊戲之後，自然就會對 10/25 03:53
29F：→ cjcat2266: 遊戲引擎架構有比較好的概念 10/25 03:54
30F：→ cjcat2266: 人家Unreal也是副產品，他們不是一開始就以開發商業 10/25 03:54
31F：→ cjcat2266: 引擎為目的，而是不斷產出遊戲之後，一個可以拿來賣的 10/25 03:55
32F：→ cjcat2266: 引擎才慢慢成形 10/25 03:55
33F：→ cjcat2266: 老話一句 "Make games, not game engines." 10/25 03:55
34F：推 LayerZ: 引擎是以前寫遊戲的副產物，除非是要賣引擎才要寫到完美 10/26 18:23
35F：推 FukadaKyoko: 靠要 這篇推文都是神 10/26 19:04
36F：推 LayerZ: 之前也有遇過同樣的困擾，後來發現會困擾的原因是，不論是 10/26 19:06
37F：→ LayerZ: 類別還是參數控制都是對的，對底層運作而言不需要類別只 10/26 19:06
38F：→ LayerZ: 需要參數，對設計者自己控制而言把參數類別化控制就不用 10/26 19:07
39F：→ LayerZ: 煩惱細節，結論:混用就好.. 10/26 19:07
40F：推 chrisjeremy: 我的作法跟火星大一樣 這麼做比較好用而且清楚 10/27 23:59
41F：→ chrisjeremy: 傷害計算跟演出最好分開一點 不要寫在一起 10/28 00:01
42F：推 eulbos: 大推cjcat2266大大說的!! 豁然開朗 10/28 15:36