其实这概念是很简单的 就是有没有想通而已 游戏开发时你要以开发者容易除错跟测试的角度去看 基本上就像是你有几种技能 例如有技能ab01, ab02, ab03 他们有些基本的属性 1.伤害 2.范围 3.特效 4.持续时间 5.冷却时间 6.消耗物 7.属性 8.技能名称 我列一些基本的东西 然後我们在物件的设定档案里 通常是加密过的property档或是自己开发的档案格式来设定这些属性 然後将伤害、范围、特效...等等这7项分别写成物件 本身技能总项一个物件 在启动或初始化这些技能的时候就会组合这些物件然後依照你的设定一一触发 完成一系列的工作 这个好处就是可以减少总记忆体的使用量 ※ 引述《gyd (阿龙哥)》之铭言： : ※ 引述《wix3000 (痒，好吃)》之铭言： : : 一直以来都有个疑问 : : 虽然物件导向教学都说继承与多型是OOP的特色 : : 不过在游戏设计时常常需要制作很多同一个架构但不同功能的类别 : : 比如说技能，部队这一类 : : 我是应该遵照OOP的特色，为每一种技能实作一个类别呢？ : : 还是应该写在同一个类别里，透过控制属性去产生不同效果呢？ : : 又或是有其他更好的方法呢？ : : 我目前是采用多类型的作法，但是类型一多又总觉得看起来很乱 : : 因为我程式都是自学为主，所以想请问一下通用的作法是哪一种 : : 麻烦各位先进提供一下意见 : 是个野生wix三千 : 目前负责过的案子, 我设计的架构上通常都会像这样(以技能系统为例) : 命名这边只用概念 : base -- ability -- abilityA : |- abilityB : |- abilityC : |- buff -- buffA : |- buffB : 其中 base 管理 data, 处理radius/add/remove等等共用的事 : ability 处理 施法/各技能阶段等等ability专用的事 : buff 处理 多久跳一次/持续时间/等等buff专用的事 : abilityA...N 处理该技能在各阶段该做的事 : buffA...B 处理该buff在生效时及stackin/out时做的事 : 其他如特效/model也是类似架构 你的架构离组件式似乎较远 比较缺乏弹性 但叙述过少也很难断定 欢迎讨论 -- --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 59.127.231.87 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/GameDesign/M.1445934454.A.7E7.html