前言

因为只注重于实现攻击效果，因此代码结构上没有考虑玩家的动画播放和后台的数值设计。

在实际开始做游戏的时候，第一次站在较高层次上去思考如何构建一套可复用的扩展性强的代码框架，这时候我体会到，工程项目和科研项目是不一样的，根据我的经验，科研项目可能一整个项目就几百行代码（仅限于我负责的那部分），但工程代码太多了，如果对整体框架没有一个清晰的把握，屎山就会飞速堆积，哪怕在构思好框架的基础上，也很难避免屎山的出现，最多放缓屎山堆积的速度吧。

第一次用UML图来辅助写代码，感觉的确是有效果的，能帮忙理清思路。

在尝试实现技能卡片列表的时候，问了一下ai，发现ai直接给出了一个正确的大方向，只是在具体的实习方式上缺少一点细节，这给了我很大的惊喜，我根据这个思路画出了不标准的流程图，然后参考这个流程图，完成了具体的是实现。

机制介绍

玩家会拥有一个技能卡片列表，每个技能卡片都对应着一个主动/被动效果，当玩家攻击的时候，依次触发每个技能卡片的效果，遍历所有卡片后，输出最终的攻击弹幕。

技能卡片

每一张技能卡片都有一个冷却属性，所有的卡牌冷却叠加，得到最终的攻击冷却。

有些被动卡片的效果会减少冷却。

主动卡片

主动卡片会提供主动攻击的效果，一般是发射弹幕。

一些主动卡片会停止当前的效果传播，另一些主动卡片会保留当前的效果，并传递给下一张卡片。

被动卡片

被动卡片会给玩家本身或者下一张主动卡片提供效果，例如减少冷却，提高体积，增加速度，修改弹道等等。

某些被动卡片给玩家同时提供正面和负面的效果。

流程图

其中Player类挂载在玩家GameObject上，SkillManager既可以挂载在玩家身上，也可以单独创建一个单例用来挂载。Player内部初始化状态机和对应的所有状态，在Player内部调用StateMachine进行状态的更新，控制玩家的动作和对应的动画播放。状态机的实现已经发非常成熟，这里不再赘述。

其中最核心的部分是技能的触发方式。
SkillManager内部维护一个技能列表SkillList，同时维护一个SkillContext类。

SkillList很简单，就是存储当前可生效的技能，而SkillContext的作用在于，他会保留当前卡片提供的各种被动/主动效果，然后传递给下一张卡牌，直到遇到一张主动卡牌，主动卡牌会访问当前上下文提供的弹幕属性和释放策略，然后基于此来释放弹幕。

如果每次进行攻击的时候，都要初始化上下文，然后遍历卡牌进行属性和策略的累计，可能会影响性能，所以只在卡牌列表更新的时候同时进行上下文的构建。

最后，参考着这个图片，完成了实际的代码开发后，把代码交给ai，形成完整的类图，有助于进行架构评估和进行其他功能的开发。