比如子弹，直接为它掛载『移动脚本和『击中脚本，就可以仅靠修改这两个脚本的参数的情况下让子弹千变万化。
最可怕的是，这个所谓的『脚本，同样是一个可以隨意继承实现的类。
不过想要自定义新的脚本就很难在不编程的情况下做到了。
这套体系便是整个模组api的核心逻辑。
基於此，可以开发出无数匪夷所思的充满想像力的另类玩法。
不过对於脚本的灵活应用，林琅打算留给他已经想好了的第二款模组。
当下这款自然还是集中在让大家了解如何新增自定义的植物和殭尸等。
继承自豌豆，將发射函数延迟片刻额外执行一次，並將子弹的引用替换成仙人掌刺。
仅仅如此操作，一个双发仙人掌便做出来了，当然他还需要为其准备一套美术素材。
同样的逻辑，阳光炸弹只需要继承自樱桃炸弹，为爆炸击杀后添加一个生成一坨阳光的效果即可。
有射手类，当然也会有投手类，儘管它们都出自一个叫『攻击型植物的父类。
这样的设计虽然非常便於理解和使用，但並非像看上去那样完美。
复杂的重重嵌套带来的是代码的高度耦合，这其实並不符合编程追求的解耦思想。
一环套一环的层层依赖，带来的结果是灾难性的可维护性。
假设某一天林琅突然想要动一动实体类这个万物源根，就有可能一脚踢翻整座『屎山。
不过所见即所得，这对於模组开发者而言却是一件好事。
不消多会儿，林琅便为几种常见的植物类型都做好了变种版本。
但这还没完，儘管可以直接为它们设置好阳光消耗，直接载入到卡池中，但他还是选择了另一种方式。
回到主菜单的那个墓碑之上，这玩意儿其实並不像肉眼看上去那样排列了几个按钮来实现。
事实上这整个ui都是完全程序化生成的，邪门到家。
为什么要捨近求远的搞成这样的设计呢，这自然也是为了模组作者。
只需要在mod类的主入口中声明一个『菜单类，执行註册，它便可以就这么直接显示在墓碑之上。
藉由此，模组作者只要想，甚至可以完全在不靠注入的情况下对整个ui体系都做出客制化修改。
也就是所谓的『资源包、“数据包”功能。
林琅在主菜单加入了一个『合成按钮，只要点击，就可以跳转到一个特殊的场景。
將植物卡组合在一起，只要符合他设置的配方，便可以解锁杂交版的植物。
当然这整个合成卡牌的场景也是完全程序化的，只不过是调用了內置的『卡槽类，又调用ui工具生成了一个显示所有持有卡牌的仓库。
对於0基础用户，林琅则是在开发工具中设置了一个可视化的ui设计工具，拖拽组件到对应位置即可。
一整套下来，一个全新的玩法便诞生了。
接下来便是运行工具包中的『编译打包工具，调用他准备好的程序集將一切都编译成模组文件。
“来来来，又整新活了，来玩玩看。”