※ 引述《cowbaying (是在靠北喔)》之铭言： : 其实这概念是很简单的 : 就是有没有想通而已 : 游戏开发时你要以开发者容易除错跟测试的角度去看 : 基本上就像是你有几种技能 : 例如有技能ab01, ab02, ab03 : 他们有些基本的属性 : 1.伤害 : 2.范围 : 3.特效 : 4.持续时间 : 5.冷却时间 : 6.消耗物 : 7.属性 : 8.技能名称 : 我列一些基本的东西 : 然後我们在物件的设定档案里 : 通常是加密过的property档或是自己开发的档案格式来设定这些属性 : 然後将伤害、范围、特效...等等这7项分别写成物件 : 本身技能总项一个物件 : 在启动或初始化这些技能的时候就会组合这些物件然後依照你的设定一一触发 : 完成一系列的工作 : 这个好处就是可以减少总记忆体的使用量 : ※ 引述《gyd (阿龙哥)》之铭言： : : 是个野生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也是类似架构 : 你的架构离组件式似乎较远 : 比较缺乏弹性 : 但叙述过少也很难断定 : 欢迎讨论 因为的确就不是组件式 我的想法是 你所列出的8个项目都比较偏向data的范畴, 实际上就算是拆成8个组件 也会互相绑的很死, 至少会跟主组件绑死 当然若是子类别应用范围非常的广, 拆成组件可以摆脱一些切分上的问题 例如 纯model元件, 如地图装饰物 有生命的model元件, 如树木 有技能有生命的model元件, 如角色 就至少会有三个类别 而实际的应用上, 拆成元件式的结果就是主组件内要写很多让组件彼此沟通用的api 否则拆成组件的意义就并不是这麽大了 个人认为 以系统来说, 拆成组件为佳 以gameplay来说, 继承为佳 --

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