作者wix3000 (痒，好吃)
看板GameDesign
标题[请益] 游戏制作时的多型?
时间Sat Oct 24 09:58:12 2015
一直以来都有个疑问
虽然物件导向教学都说继承与多型是OOP的特色
不过在游戏设计时常常需要制作很多同一个架构但不同功能的类别
比如说技能，部队这一类
我是应该遵照OOP的特色，为每一种技能实作一个类别呢？
还是应该写在同一个类别里，透过控制属性去产生不同效果呢？
又或是有其他更好的方法呢？
我目前是采用多类型的作法，但是类型一多又总觉得看起来很乱
因为我程式都是自学为主，所以想请问一下通用的作法是哪一种
麻烦各位先进提供一下意见
--
███ ︵︵︵︵ █◤ ◢█◤ ちから
██ ／＼｜｜｜█ ◢█◤ 「ひとりでは耐え切れぬ 雷 でもきっと、
▄█│‵╯︶︶| ██◤ # ふたりなら大丈夫私は信じる！」
▔█ ╲ ） ∕█████◣ +
+ █ ╮ - │██◣ ◥◥█◣ ◢ 第四巻 27ページ…
▂▄▆█│ │██◤* ◢████◣ 雷神の系谱 ψWix
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 219.85.240.42
※ 文章网址: https://webptt.com/cn.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