[請益] 遊戲製作時的多型?

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