前面两篇我们把数据抽成了配置把结构设计成了框架 效果列表。现在配置文件里躺着{ type: damage, value: 100 }这样的东西问题来了谁来真正把这 100 点伤害打出去配置只是一张纸纸上写着造成 100 伤害但纸自己不会动手。真正干活的是这一篇的主角——行为组件。这是整个技能系统的心脏标题里标了核心两个字不夸张。先想清楚行为组件到底是个啥打个比方。配置是一张点菜单上面写着宫保鸡丁、麻婆豆腐、番茄炒蛋。行为组件就是后厨里的厨师——每个厨师专精一道菜菜单点到谁谁就上灶台炒。放到技能系统里配置里的type: damage→ 交给伤害厨师处理配置里的type: heal→ 交给治疗厨师处理配置里的type: slow→ 交给减速厨师处理每一种效果类型对应一个行为组件。组件负责把配置里的数字变成游戏里真实发生的事。最关键的一步定义统一的接口既然要把每种效果做成独立组件就得先定个规矩所有组件长什么样、怎么被调用。这个规矩就是接口。规矩只有一条给你一个配置、一个施法者、一个目标你负责执行。interfaceSkillEffect{voidapply(EffectContextcontext);}参数打包成一个context上下文里面装着执行一次效果需要的所有东西classEffectContext{Entitycaster;// 谁放的技能Entitytarget;// 打给谁EffectConfigconfig;// 这个效果的配置伤害值、持续时间等// 可能还有技能等级、暴击信息、随机数种子等}为什么要费劲搞个统一接口因为只要所有组件都长一个样引擎调用它们的时候就不用管具体是谁了——反正都是effect.apply(context)。这是后面所有灵活性的根基。动手写几个组件伤害组件最基础的把配置里的 value 扣到目标血量上classDamageEffectimplementsSkillEffect{Overridepublicvoidapply(EffectContextctx){floatdamagectx.config.value;// 可以在这里叠加各种计算攻击力加成、防御减免、暴击等damagedamagectx.caster.attack*0.5f;// 加成施法者攻击力damagedamage*(1-ctx.target.defense);// 扣掉目标防御ctx.target.hp-damage;// 触发一些附带的事情showDamageNumber(ctx.target,damage);// 飘伤害数字ctx.target.onDamaged(ctx.caster,damage);// 通知目标我挨打了}}注意伤害组件不只是简单减血。攻击加成、防御减免、暴击判定这些怎么算伤害的通用逻辑全都收拢在这一个组件里。好处是全游戏所有技能的伤害计算都走这一份代码。哪天公式改了改这一处全体生效。治疗组件跟伤害几乎对称把血加回去classHealEffectimplementsSkillEffect{Overridepublicvoidapply(EffectContextctx){floathealctx.config.value;healhealctx.caster.magicPower*0.3f;// 加成法术强度ctx.target.hpMath.min(ctx.target.hpheal,ctx.target.maxHp// 别超过血量上限);showHealNumber(ctx.target,heal);}}减速组件减速不是一锤子买卖它要持续一段时间所以逻辑稍微不一样——它给目标挂一个 buff然后靠 buff 系统去管理持续和消失classSlowEffectimplementsSkillEffect{Overridepublicvoidapply(EffectContextctx){BuffslownewBuff();slow.typeslow;slow.valuectx.config.value;// 减速多少比如 0.3slow.durationctx.config.duration;// 持续几秒ctx.target.addBuff(slow);// 挂上去剩下的交给buff系统}}这里透露出一个重要信号有些组件自己就把事情干完了伤害、治疗有些组件是起个头把后续交给别的系统减速交给 buff 系统持续伤害交给 dot 系统。组件不需要自己扛下所有事情。把组件注册起来写好了一堆组件怎么让引擎知道damage 这个字符串对应 DamageEffect 这个组件用一张表把它们对上号classEffectRegistry{privateMapString,SkillEffecteffectsnewHashMap();voidregister(Stringtype,SkillEffecteffect){effects.put(type,effect);}SkillEffectget(Stringtype){returneffects.get(type);}}游戏启动时把所有组件登记进去registry.register(damage,newDamageEffect());registry.register(heal,newHealEffect());registry.register(slow,newSlowEffect());registry.register(dot,newDotEffect());// 以后加新效果就在这里加一行这张表就是菜单类型到厨师的对照表。核心引擎把一切串起来现在万事俱备。引擎要做的事特别简单——读配置对着表找组件挨个执行classSkillEngine{privateEffectRegistryregistry;voidcast(SkillConfigskill,Entitycaster,Entitytarget){// 前置检查冷却好了吗法力够吗距离够吗if(!canCast(skill,caster,target))return;// 扣冷却、扣法力caster.startCooldown(skill.id,skill.cooldown);caster.mana-skill.manaCost;// 核心遍历所有效果逐个交给对应组件执行for(EffectConfigeffectConfig:skill.effects){SkillEffecteffectregistry.get(effectConfig.type);if(effectnull){log.warn(未知效果类型: effectConfig.type);continue;}EffectContextctxnewEffectContext();ctx.castercaster;ctx.targetresolveTarget(effectConfig,caster,target);// 按配置选目标ctx.configeffectConfig;effect.apply(ctx);// ← 一切魔法发生在这一行}}}盯着effect.apply(ctx)这一行看。引擎完全不知道自己在执行伤害、治疗还是减速它只管找到组件调 apply。具体干什么是组件自己的事。引擎和组件彻底解耦了。这就是为什么加 200 个技能不用改引擎——引擎的逻辑永远是这几行变的只是配置和组件。威力展示加一个全新效果有多简单假设策划要加个前所未有的效果“击退”——把目标弹飞一段距离。第一步写个组件程序员的活就这么点classKnockbackEffectimplementsSkillEffect{Overridepublicvoidapply(EffectContextctx){Vectordirctx.target.pos.minus(ctx.caster.pos).normalize();floatdistancectx.config.value;ctx.target.posctx.target.pos.plus(dir.times(distance));}}第二步注册一行registry.register(knockback,newKnockbackEffect());第三步策划在配置里随便用程序员不用管了{id:shield_bash,name:盾击,effects:[{type:damage,value:60,target:enemy},{type:knockback,value:5,target:enemy},{type:slow,value:0.5,duration:2,target:enemy}]}一个造成伤害 击退 减速的盾击技能就诞生了。程序员只写了击退这一个新组件伤害和减速直接复用现成的。这就是组件化的复利组件写得越多能拼出的技能越多而且是指数级增长。几个容易踩的坑组件之间别互相依赖。伤害组件就老老实实算伤害别在里面写如果目标中毒了就额外爆炸这种跟别的效果耦合的逻辑。这种联动应该交给配置的condition去表达或者用事件机制。组件一旦互相勾连就又变回那团焊死的代码了。组件要保持无状态。组件本身别存数据。注意上面所有组件都是new DamageEffect()一个就够全游戏用因为它不记任何东西每次执行需要的数据全从context传进来。如果组件里存了状态多个技能同时用就会互相干扰排查到你怀疑人生。执行顺序有讲究。效果数组是有序的先伤害后击退和先击退后伤害结果可能不一样击退了可能就打不中了。设计时想清楚顺序配置里也要按正确顺序排。处理好目标已经死了这种情况。第一个效果把目标打死了后面的治疗、减速还要不要执行组件里要做好空判断和存活判断别对着一具尸体施法然后崩溃。一句话收尾行为组件这一篇的核心思想把每一种效果做成一个独立的、统一接口的、无状态的小组件用一张表登记起来。引擎不关心具体效果是什么只负责读配置、查表、挨个调用apply。程序员的工作变成造组件策划的工作变成拼组件。到这里前三篇就闭环了数据逻辑分离是思想数据结构设计是把数据组织好行为组件是把逻辑组织好。三者一合你就有了一套能扛住策划反复折腾、加几百个技能也不慌的技能系统。下一步可以聊聊组件之间怎么协作——比如 buff 系统、事件机制、还有那些连招触发链是怎么实现的。