一直以来都有个疑问
虽然物件导向教学都说继承与多型是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大大说的!! 豁然开朗