如何设计一个易扩展的游戏技能系统？
PC端如Dota、LOL、梦幻西游等等。手游端如刀塔传奇。可以很好的应对后续不断添加的需求。或者有哪些开源的可以学习的。
按时间排序
每个技能都不一样如果设计几十个技能那字段得加多少 程序和策划都会疯了 建议看看火炬之光的技能编辑器 会很受启发
这两天一直在做技能系统，占坑。下周末写
好像以前有款Sid Meier出的星际slg游戏，大概03年就有了，就是有星际会议，根据民主投票结果改变规则。太阳神三国杀的设计技能主要是通过lua来实现。易扩展指开发扩展还是玩家扩展？我觉得lua的那种数组结构比C容易扩展多了。用了LUA都不想用C。
其实一款可以不断增加角色的游戏就具有极高扩展性，但主要问题在于如何维护游戏内的平衡，这个可以参考口袋妖怪系列。
不是内行的人都认为改下设计和实现跟用纸巾擦一下嘴角一样简单 实际上比更改建筑结构还难
作为一个玩家，也确实想过不少次一款怎样的游戏才是真正的游戏，想了很多，世界背景，技能，社会框架等等。想到最后，顿时觉悟。只做接口，然后把坑留给其他千千万万的玩家来填。
楼上有人的答案说了。我所在的游戏做法也类似。技能类一共划分为技能表，与角色相关，配置了角色的技能对应的攻击，防御减伤等效果描述。以及各种装备符文加成表。这些表是给策划用的，用Excel组织。表格的字段一般定好了就不会变，以后添加表项就行。这张表可以借助自动化工具转化为后台对应的数据结构，然后游戏服务器进行游戏加载的时候会把字段内容解析到内存里处理。有些字段如果是角色独有的最好进行抽象，从公共逻辑里剥离出来。如果策划需要修改某个角色的攻击加成之类的改下数值然后转表，直接提交一个公有运行目录重启下服务就行了。基本上，Excel表的形式适用于各种运营活动，技能系统，装备系统，掉落系统。当然这种转表的姿势还是比较繁琐，整个编辑器把转表提交过程一键无脑完成就好了
我个人对这个问题非常感兴趣，因为我花了至少5年在设计和实践（我自己经历了大小7个项目，虽然大多最后因为其他原因都没上）这样一套机制并且可以说基本解决了这个问题！我并不想藏着他，我也和很多朋友分享了，同时也感谢他们提出了很多意见，包括细节和优化等方面，正因为互相之间的借鉴和交流，我到今天已经把这套机制归纳的非常好了，还是想把它分享给更多想做好游戏的人，希望大家能进一步交流，把它更完善化，以形成一种规范，这套机制适用于任何类型的游戏开发，因为他是一个很棒的思路。首先分析一下可扩展性：我从一个设计师的角度来看，所谓的可扩展性是——你并不知道策划下一个设计的是什么，但是你需要在尽可能不改动核心代码的基础上去把它实现了，并且在调试的时候（甚至是上线之后要做调整的时候），你可以并不伤筋动骨的去修改它。这里除了你要有好的代码规范外，还需要抽象一套机制来实现它。最早开始想这套机制的动力是因为我在起凡工作，看了代码之后我感觉是完全无扩展性的，当我想要设计一个新的英雄的时候，要去修改代码已经几乎是不可能的了，于是我便思考，如果我要做一套WoW的技能、buff系统，应该是怎样的呢？于是我总结、归纳、抽象了这样一套东西，并且最早在三国争霸2项目中投入实际使用。2年前我在GameRes发过相关的帖子：实际上，好的策划的脑洞是非常大的，你真不知道他会设计出什么样的技能，但你并不能说一些设计因为无法实现就理所应当被埋没了，（我对策划设计Dota类游戏的思路要求是开放的，发挥想象力的：）因此我想了这样一个机制，他们的核心在于：1，明确区别了AOE\Buff和技能3块，策划应该从这个角度出发思考问题。2，这既然是一套机制，你可以把它用在任何游戏的框架当中。比如我要做一个Dota传奇的卡牌游戏，一样可以用这套机制，但是核心在于——你的策划要有能力归纳出游戏中的回调点。当然我们在使用这套机制的时候，逻辑上实现并没有任何问题，但是我们一样会遇到一些从逻辑变成动画的困难，尤其是当我们的战斗在服务器上一瞬间完成了，但是要把结果告诉客户端吗，并且有客户端重新验算一遍的时候，因此我在之后有总结了一套作法，来完成这个事情：这个解决的是，当你有各种有趣的buff，但是又想不大改客户端的时候，你应该这样去建立这个框架。你可以想象如果你做一个MT类型的游戏，战斗是服务器一瞬间的，但你又要客户端重演，我们举个例子：比如我门设计了在MT类型游戏中加入地形因素：可以有火海，火海每回合开始的时候对所有场上敌我英雄造成火焰伤害。然后有个英雄是一只凤凰，凤凰有2个被动效果：1，受到火焰伤害的时候变成治疗自己相当于伤害值的血量。2，战斗中第一次死亡可以复活，回复最大生命值50%，如果在火海中则回复100%。这样一个英雄和地形，我们如何实现呢？如果你看了我上面的几套机制，并且理解了，那基本没有难度，你根本不需要硬编码。但这里有个问题，我如何让客户端重现？这就是上面这篇说的关键了。希望以上这些我多年的经验总结能够对游戏人有所帮助！—————————— 更新一条 ——————————————看来感兴趣的人还是不少的，于是我发了一些关于这套机制的实际运用方式在GameRes上，主要是想说——这套东西核心还是离不开策划的设计的，同时放开脑洞去思考，才是最重要的：
由于是从事设计工作，所以在此只谈设计需求方面的思路。关于具体实施方案，如果无法将当前游戏机制可能产生的运算关系全集完全罗列并全部编写为底层API，那么，表格化配置方案并不是最灵活的解决方案~在从技能描述设计到技能逻辑设计再到最终填写配置的过程中，将会不断的发生当前表格配置无法满足设计需求的问题，直至完成阶段规划的全部技能设计，以内容生产商的角度考虑，这将涉及到关于项目生产时间的dead line问题~每个技能逻辑完全通过程序代码实现是扩展性最差的解决方案，原因很多，在这里只讲一个决定性因素就够了，一旦版本更新出现技能逻辑方面的改动，在游戏版本更新时很难支持热更新。比较有弹性的解决方案是底层API配合脚本编写，也就是说将技能实现中基于面向对象的部分与基于面向过程的部分分拆，底层运算API部分交给前端游戏机制实现的程序人员做，另行指派程序人员专门负责脚本编写或将这个工作交给设计人员，不过据我个人了解，多数公司都是指派程序人员来完成这个工作，毕竟多数的中小型公司通常设计人员都比较少，有脚本编写能力的更少，无法满足项目在生产时间上的需求。另外，以项目流程迭代角度来考虑这个生产时间问题，这种解决方案可步进式推进项目进度~关于技能抽象问题，需要针对当前游戏机制主体所支持的时间序规则设计，如果机制属于非回合制类型，确实有单次时间序技能（常规定义技能），常量时间序技能（BUFF与DEBUFF）,与条件技能（英雄光环技能，终止条件多为英雄阵亡）等概念~这是由于技能概念是建立在时间序的面向过程逻辑基础上所导致的~如楼上一位兄台所说，技能是设计、程序及美术三方共同协作所诞生的产物，所以单谈技能设计很难获得有效设计经验~入行时间还不长在这方面可以总结出的阶段性结论暂时只有这些，期待大神指点~……本来写了不少内容，结果这个差评APP把我辛苦打的文字扔了，心情不美，不说了~
容易扩展？等于容易失衡……
好像都是讨论游戏结果影响方面的技能表现，有没有讨论美术表现的技能表现啊？简而言之就是程序和美术合作方面的，而不是程序和策划合作方面比如说，像格斗游戏一样的必杀技/大招等等，但面向多人vs多人的情况
编辑器对策划要求比较高，如果策划素质堪忧，尽量写死，给一些简单的参数配置就好。此为前言。说了前面，那么一个技能，基本上就和AI差的不多了。有很多成熟的行为树编辑可以作为参考，但是还是那句话，这个东西对你们策划要求和程序要求都要高一些，如果能力不足会容易长期填坑。切记不要，“我什么都想试试”。行为树和编辑器，可以看这个实现，
（。。。答完看了下其他答案感觉这个问的是程序问题，表示非程序无能为力。以下答案仅仅从策划或玩家的角度考虑。）1、感觉从现实来说没啥好说的。技能无非是一堆数值、各种状态（BUFF或DEBUFF）、施放条件、持续时间、CD等等的排列组合。没做过具体的技能设计，但我想应该是一张表里面有N多列表示不同的状态、或者BUFF。新技能应该是在这个表里面加多一横，并在你想要技能有什么效果的对应列上设定。（纯个人想象，如果错误请大神们指出免得误导了别人。）2、在拓展性上我发表一下个人看法，扩展容易但必须考虑清楚。A、首先要考虑替代性的问题，比如动作游戏按键有限的情况下一个新技能意味着必须淘汰一个旧的技能。如果是淘汰就要考虑用户之前技能以及现在技能的升级成本以及作用相关性，如果新技能效果有限或者说用户需要付出很大的代价才能让新技能达到替换旧技能的水平，那将会影响新技能的普及替换。如果说技能是跟RMB挂钩比较直接的话要考虑替代的时间间隔，好不容花了很多时间、精力、金钱把技能弄好，雄霸一方才2天出个新技能回到解放前人人平等那就不对了。B、扩展的技能主动性技能要慎重，尽量是被动或BUFF类。不用替换主动技能又达到增强效果。C、平衡性问题
战斗系统大概就动作和特效的控制。动作分开始，触发，触发，结束几个阶段。触发特效有特效触发被击或者直接触发被击表现。所以技能特效也分开始，触发，结束几个阶段。然后就是被击的表现处理了。注意控制好行为的生命周期以及设计好数据的结构。就没什么了。有时间可以开发技能编辑器取代配置表。
技能这部分我倒是没有见过有开源的框架，但题主必须要纠正一个观念，技能这部分的架构，是没办法做到策划提出需求而你不用修改的，你所能做到的就是降低各个功能块的耦合，给策划足够的自由度，后续添加很少的代码即可。比如说弓箭手的技能，你在做的时候提供子弹数量与子弹夹角，是否穿透，是否返回，再提供一个可以配置曲线的地方，这样的话策划基本上可以根据你提供的参数配置直线曲线散射单攻返回穿透这几个因素组合的各种技能。楼下有人提到buff与技能的关系，说起来各种形态的都有，主要看做这块的程序怎么想，有些技能结构中buff的比重很高，基本上技能就是挂各种buff，效果全由buff实现，有些技能结构中buff比重很低，仅仅用来实现一些光环类，状态类效果，这两者之间的界限，其实还是看个人实现，并没有一个硬性的规则。个人觉得不受制于技能释放状态的效果，都应该归类到buff里面，也就是说技能的动作释放完了还存在于自身或者敌方的效果，具体如回复，持续伤害，减速，眩晕，封技，打坐等等，归到buff里面也可以更自由，技能只需要提供挂buff的相应配置即可。另外，关于技能结构，最好能提供组合技能的功能，以我尚浅的资历，到目前为止这个功能要么是早期要么是后期，基本上遇到的项目都要用，在实现一些比较复杂的技能时尤其有用，所谓组合技能就是可以连续释放多个技能中途不退出技能状态，注意这个和连续释放无CD技能是有区别的，组合技能是用来处理类似于冲过去打几下然后打到天上再打到地上一通踩的这种技能的，你做的时候就会发现这些技能每一段都是技能表可配置的，但组合起来就得重新写一个新的技能，而且策划一般会提过来好几个这样的炫酷技能，那么提供技能组合无疑是比较好的方案。其实说白了就一句话，提供各种可配置参数，把权限交给策划，具体要提供哪些，你自己多想想，细节很多，写下去就没完没了了，就这样吧。
补充一下，以防有误导的嫌疑，这篇文章想表达的是我作为一个玩家，不是作为商业公司的员工，所谓的程序、美术或策划，对感兴趣的一些游戏技能体系的一些分析，如果看起来太复杂、不实用、脱离游戏需求等等，这就对了，因为我根本就不关心这些嘛。just for fun。=====这个要看追求了，没追求一张 excel 表配置上几百个参数，碰到一个需求加一个总能写出来；有追求甚至能和 war3 一样十几年前的游戏就可以在没有源码情况下做出 dota（然而总有嘴强王者认为这没有什么大不了）；又或者像我一样幻想有没有可能设计出一套集成 GTA（模拟现实）+神之浩劫（moba）+虐杀原型（超现实动作）又可供玩家扩展的技能系统？技能是如此有意思的事情，精巧的、可扩展的技能框架简直可以说是游戏最大的乐趣，远不是一些泡菜网游里面一句一切皆 buff 就能把我打发了的，所以很久以来我对探索技能在各种游戏里面的实现乐此不疲，分享一点研究的线索。比较少谈具体的编码细节，因为就像我本篇最后说的那样，研究多了甚至开始反思技能这样一个概念到底存不存在，或者说不同游戏类型讨论的技能真的是同一种东西吗？如果游戏真的是现实生活的映射，那我们人类作为角色拥有技能吗？最简单的就是虚幻竞技场那种 fps，感觉这种没什么好说的，虽然虚幻竞技场的改装枪是一个玩点，但是代码层面并不复杂。复杂点的泡菜网游 rpg 或者 moba 可以参考星际争霸的银河编辑器，风暴英雄就是用这个做出来的，ga 论坛欢迎你，找了一篇相关文章：，可以粗感受一下是不是题主需要的东西。再安利一个外国玩家利用该框架做的一个 mod：熟悉 war3 不熟悉 sc 就下载 ga 的 war3 mod（），这是论坛头目在 sc 体系下完整的复刻了 war3，可以观察 war3 里面的技能一个一个是怎么实现的，常见的比如暴风雪、空中锁链、变羊、风暴之锤等等，其实简单的的网游技能无非就是这些技能的变种。里面大体来说把技能相关的东西解耦成了如下模块，unit、action、order、ability、behavior、effect、actor，然后通过反射和连线配置来扩展游戏。简单描述这个体系，很复杂，也不求没研究过的人能看懂：ability 就是通俗意义上的技能，包装成 order 被 unit 调用，ability 本身不负责技能逻辑，只有使用 ability 消耗的资源（比如消耗多少魔法）前摇后摇之类的处理，他指向一个 effect，在 ability 调用时候转发到 effect 身上；effect
晚点说，先说 behavior，常见的 behavior 类型就是添加一个 buff，也就是对一个属性的阶段性修改，behavior 是有状态的；回头说 effect，effect 最终组成了一颗 effect 树，effect 常见的有发射投射物、应用 behavior、周期性的调用下一个 effect、对区域进行搜索然后对搜索到的每个对象进行调用 effect、造成伤害、创建单位等，除了周期性效果之外的 effect 都是无状态的，只是简单的对逻辑进行一次函数调用。以上所有的一切描述都是纯逻辑层面的，而 actor 是表现体，所有的特效、动画都是通过 actor 监听以上所有对象的信号 来做出相应的反应，而不是常见的动画驱动逻辑，换句话说，如果 actor 不监听逻辑层的信号，表现会有问题，但是游戏的核心逻辑还是照样跑，包括 unit 类其实都不包括任何的表现信息，只是在 unit 类创建时候通知 actor 创建并做表现 。actor 很类似一个完全被动驱使的客户端，其他模块是服务器。最后，在整个一套异步流程中，需要一些全局的类似 ai 中的黑板数据，记录比如施法者、施法位置、目标攻击位置、目标攻击对象等，由于 effect behavior 的树状向下扩散，所以这个黑板数据其实也要不停地更换上下文，这个就有点复杂了。更详细的说明看 ga 的 wiki 吧。 粗略的框架类图可以在这里找到：。另外，表现层的 actor 的技能动作处理，也比较有意思，采用动作名称模糊匹配的思路：。大概就是这样的：对角色当前各种状态进行采样（比如心情、天气、角色上一个状态名称等），根据状态类型优先级自动选择最合适的且存在的动作，比如如果资源同时存在Attack 00 Attack 01动作，那就随机播放一个 Attack，再比如风暴英雄里面普通死亡、爆炸死亡、天空击飞死亡播放不同动作也是在这个层次处理的。当然，动作模块的设计是个大问题，各大引擎中间件也经常是一个版本一个方案的大改，他这套方案也有局限性。好处就是用起来方便，ruby 曰：约定大于配置。想象一下，当玩家新做一个路人角色，这个角色在看到美女时候就自动做特定的好玩动作，而这一切需要做的也许仅仅是，配置一个 npc，给他一个特定名称的动作，比如 love stand。星际目前有296个关键字可以相互组合。再谈一个小细节，一般自研引擎都解决的比较好，但是也可能还有人还没注意这件事：星际美术的动作资产中，除了骨骼动画，声音、特效等实时演算的功能也集成在里面，而且编辑器可以做到直接预览，上层技能框架里面把很多单位的表现状态（比如替换模型）都抽象成“动作”（而不是单纯的骨骼动画），这种直观的设计很舒服。反观一些方案（比如 unity 很常见的做法）直接把 fbx 作为美术流水线的终点，局限性很大，加个简单特效都要放到上层技能框架里，还不能预览，最好在裸骨骼动画和“技能”之间加个支持编辑器预览的、引擎实时演算功能（主要是特效、声音）相关的中间层，这个中间层的结果作为“动作”最终暴露给业务层，这方面 unreal 做的就比较好，编辑器对 fbx 的二次加工支持预览，用起来方便多了。研究完了会发现顺便把插件接口、游戏录像（甚至可以做到从录像中某个点加入扮演某个阵营）、网络同步、表现信息自动适配机器配置等内容还一块解决了。只不过我个人山寨的时候最后还是把这套方案的一些繁琐细节给折中了，最后的结果很类似 dota2 的技能系统，这就不多说了。一个玩家都能随意扩展的 moba 技能体系，难道专业策划还做不好？这恐怕是做游戏思路的差异吧。再补充个好玩的，之前 war3 平台的地图《军团 td》作者做了个网游梦塔防，在测试中。具体到编码细节我从 war3 时代就开始研究，也山寨过，非三言两语可以说清楚，但核心思路其实也就上面说的那些。只要把常见技能都亲手制作一遍，心中自有定论。虽然说起来简单，但是如果非要把自己定位到程序、美术或策划的立场上，而不是玩家或者 mod 作者，这玩意可能都太复杂了。有人说看起来和某些 ai 的设计有点像？那是当然的，无论是 ai 还是所谓的“技能”，从基础的 if else 到上层做了一层又一层的抽象，说到底都是无非就是为了控制异步逻辑的复杂度，手段都差不多。至于游戏 ai 里面的乱七八糟理论，和本主题无关，就忍住不吐槽了，反正也是一个乱象丛生的领域。实在觉得搞不懂也懒得折腾这么复杂的东西，就去研究 war3 的 we 编辑器吧。大体思路就是把持续性效果、瞬间伤害、生成单位等一些基础设施准备好，再设计出常见技能的技能模板，最后在合理的时间点发出信号，配合触发器或脚本来扩展技能内容。技能模板如果懒得设计，甚至初始技能每个技能一个状态机硬写好像也没什么不可以，反正魔兽争霸那么复杂的游戏其实基础技能也没多少。未来扩展出来的技能都是这些技能模板的实例，区别是发出的信号或触发器在脚本层处理不一样。魔兽那么多自定义地图的技能都是这么出来的，复制一个已有的技能的配置，然后稍作修改，虽然说起来好像有点傻。还记得当年第一次见 dota 屠夫的钩子，惊为天人。要研究 we，ga 也是大本营，只不过现在讨论的少了， 毕竟老了，都转到 sc 上面去了。比 moba 的技能还要复杂？mugen 之类的格斗够不够？b 站的 mugen 专区，大家玩的不亦乐乎：
这个粗读过，山寨 mugen 的。unity 上读过一些逆向的格斗游戏，做的不错的比如韩国的网游灵魂之心（视频：），用的是状态机。国内的比如王者之剑、影之刃啥的，其实都很好逆，unity 写的。哦，我去拿下顺丰快辶我回来了o(∩_∩)o 。unity 平台还有一个格斗插件写的也不错 ，读的是早期版本，没有用状态机有点难读，但很多格斗业务逻辑相关的细节处理的蛮好，比如技能取消、帧优势（Frame Advantage这么翻译没错吧，街霸的概念）、物理，现在的新版本应该更优秀吧（我会告诉你悄悄下载做纯洁的技术探索天不知地不知吗？）。格斗相关的代码虽然读了很多，但是没有实际做过格斗游戏，不好给更多的参考意见了。个人的一些反思，可能有点口齿不清乱七八糟 ，对真正做游戏未必有用，放在这里暂记下吧：再复杂的游戏，所谓的技能，本质上是在一段时间线上有撤销需求、需要强扩展设计的、分支极为复杂的、支持配置的异步逻辑，这些异步逻辑之间还可能会有并行交互。更远一点来看，游戏单位在游戏世界中的存在本身就是状态（比如云风的 skynet 游戏服务器中对每个单位生成一个 luastate 的 agent，配合 coroutine 来实现异步拉成同步不阻塞），很多技能就是单位这个状态体生成的子状态，这样理解单位的行为（比如 walk、idle，而不单单是通俗意义上的技能）会变得更有意思，仿佛和人类社会一样，一切都是并行顺着时间向前走的，没有回调没有中断，一切逻辑的上下文变得自然而然（异步的复杂性很多时候是来源于上下文的丢失）。如果这套设想是成立的，简化异步编程，各行各业有很多探索，游戏行业未必就是做得最好的，比如我曾业余实践过基于 actor 模型（coroutine模拟的） 的技能框架，虽然很多细节至今没能解决，但确实是很有意思的探索。（写到这里突然想到 skynet 早期分享里好像也做过远程对象的设计，配合协程希望逻辑自包含上下文，思路上可能有共通的地方。他那个方案后来怎么样？貌似没有后来了）为这些游戏和技术带来的快乐，乾杯。
谢邀，不过这块好像也没啥可说的，这几年主要的改变就是 “表格化” 了。以前一个新技能或者一个新buf都需要编写相应的代码，规模上去以后，修改频繁，这样的方法经常造成开发效率底下以及bug多的问题。虽然有些游戏引入了局部表格化的方式，但是还是不够彻底，更多的游戏使用了完全 “表格化” 配置。一共三张表：技能表，buf表和道具表。程序只实现字段，修改和扩充都由策划完成。程序做一个配置检查工具，检查策划的 excel写的对不对。每个字段不但可以写一些具体数值，还可以写一些小的公式和脚本，比如：DF += 3。程序读取表格的时候，将表格转换为 python 或者 lua 脚本，运行时 import 即可，或者每次运行载入时再翻译也没啥。限于知识产权，具体表格的字段，不方便直接提供。但其实也没啥，自己归纳总结一下，不断扩充即可。一般情况，一个表格有100个字段很正常，一个技能表格上千行也很正常。不当技能表格化，道具表格化，包括任务系统，新手教学，同样可以表格化。程序要做的就是一个强大的表格解析系统，需要扩充时扩充字段即可，剩下的事情，让策划来做吧，策划写错了，QC自然会给策划提 BUG，你时不时还可以问一下策划，你的bug到底改好没有？
现有的答案太简陋了 等大神。至少框架应该考虑各种可能性，其中一个问题，技能和状态（buff）的关系应该是怎么样？目前我还是无法分辨这个两个类的边界
技能没什么框架，只是有很多字段罢了比如 cd 施法距离 释放动画 飞行动画 等等其实游戏技能不是一直不是什么难点，毕竟根据每个属性实现逻辑就好了技能真正麻烦一点是其实是 所谓的“效果”因为从很久以前，游戏设计的时候就把效果这个概念添加进来了对于 游戏战斗对象主体，我们暂时叫做BattleAgent简称BA。影响BA的数据有很多，比如移动速度 攻击力 基础属性 等等，影响的入口也有很多技能buff/被动技能装备强化宝石魂等等，而这些实际上从影响结果没什么区别首先我们先谈区别，对于这些数值影响，其实区别只有入口或者说是作用的方式技能是BA(castor)对BA(target)释放造成的瞬间数值影响buff是castor对BA(target)安装后造成的持续数值影响，分为按时触发瞬发和持续修改数值装备是特定容器对BA持续修改数值所以这里游戏开发者们抽象出了 效果这个概念对与效果而言，只存在2个行为1 对BA产生数值影响2 对BA撤销数值影响所以效果最终定义为interface Effect {
void cast(BattleAgent target);
default void reverse(){
而对于其他功能实体来说，就可以简化为效果的容器interface EffectContainer extends Effect{
List&Effect& getEffects();
这样我们就只要定义不同效果容器就可以了比如技能class abstract
Skill implements EffectContainer{
public void spellTo(BattleAgent target){
foreach(Effect effect in getEffects()){
effect.cast(target);
对于buffclass abstract Buff implements EffectContainer{
public void update(){
foreach(Effect effect in getEffects()){
effect.cast(target);
对于被动技能（其实也是buff）class abstract
BuffSkill extends Buff {
public void install(){
foreach(Effect effect in getEffects()){
effect.cast(target);
public void unstall(){
foreach(Effect effect in getEffects()){
effect.reverse(target);
装备同理被动技能是不是很清晰？而对于复杂的技能效果，因为我们已经抽象出了Effect所以怎么实现也就很容易了class DamageEffect implements Effect{
private int damage = 100;
public void cast(BattleAgent target){
target.hp -= damage;
看起来是不是很简单，我们来写个变羊这个技能包括 2 个效果 外形修改和属性1 外形变羊class ChangSheepEffect implements Effect{
public void cast(BattleAgent target){
target.gameObject = GameManager.getAnimeObject("sheep");
2 攻击力和防御力变0 速度变慢class PropChangeEffect implements Effect{
public void cast(BattleAgent target){
target.atk = 0;
target.def = 0;
target.speed = 50;
就是这么简单，同学你明白了吗如果要深入一点的话，就是变羊是持续型的，到了时间会变回来所以我们要一个可以触发buff的效果class TriggerBuffEffect implements Effect{
BuffSkill buff = new BuffSkill (){
public List&&getEffects(){
return new List().add(new ChangSheepEffect()).add(new PropChangeEffect());
public void cast(BattleAgent target){
int time = 3000;//3秒
target.addBuff(buff,time);
然后把这个TriggerBuffEffect加到技能能上就ok了，就完成了一个可以变羊3秒的技能恩 累了 就这样