系统设计决定：可视化脚本为被动系统
嗨！ 👋 我们想与大家分享我们最近做出的一个系统设计决定。
我们决定使用 嵌套的可视化脚本 来给游戏设计更多的自由，而且直到现在，真可爱的使用起来！
背景
我们是一个四位开发者的小团队，所有人都有编程经验，所以我们以前的项目中并没有使用过可视化脚本。
最近我们需要实现一个 被动系统。
核心思想
在一个事件发生时，读取游戏状态并执行一个动作。
在最初看起来似乎很简单，但是有额外的限制：
- 一个被动可以监听 多个事件 并针对每个事件执行 不同的动作
- 一个被动可以 存储数据 以及 触发器 之间
- 一个被动可以执行一个动作来激活另一个被动
- 我们预计 最终游戏 中将有 100+ 的被动
考虑的选项
选项 1：完全编写被动
优点
- 为每个被动定制化
- 几乎没有限制
缺点
- 每个被动的实现成本很高
- 每次变化或新想法都会要求额外编程
选项 2：可脚本化对象 + 自定义检查器 + 模块
优点
- 设计师可以混合并匹配行为而不用编程
缺点
- 设计实现复杂且昂贵
- 需要一个非常灵活的系统来支持所有用例
*频繁地需要创建或修改模块
选项 3：可视化脚本图表
优点
- 设计师有完全的控制权
- 更容易理解和修改
缺点
- 实现强大的模式很昂贵
- 难以维护
- 低性能
我们的决定
我们认为 工具的成本 在长期内是有价值的，所以我们选择了 选项 3：可视化脚本。
实施
- 触发器：自定义EventUnit来激活被动
- 效果：自定义Unit可以影响游戏世界
- 数据来源：自定义Unit可以从当前场景中获取数据
- 函数：自定义Unit可以帮助数据处理（如随机和列表过滤...)
使用
- 每个被动都有一个独立的图表
- 每个图表使用自定义Unit，Unity的Unit以及Auto-生成的Unit
- 被动使用协程以避免冲突
- 当激活被动时，图表会被创建
- 我们有一个类，发送事件并等待被动执行结束
后记
这项决策花了我们 1 周来找到模式，1 周来实现并且 2 周来调试。
目前，我们有 40 个图表；其中 25 个完全由游戏设计师创建，而不写一行代码。
在任何时候，我们最多有 6 个被动被激活，同时，它们中的最大图表有 50 个Unit。到目前为止，我们还没有遇见什么性能问题。
主要的重视点是维护性：重命名一个类或自定义Unit需要手动更新所有图表。幸运的是，这并不是很频繁地进行的。
TL;DR 我们使用小的、嵌套的可视化脚本图表来有效地管理数百个独特的被动系统。
评论 (0)