动作角色扮演游戏“构建工艺”编译难题：小型编译器如何解决技能组合困境？

创作数据应保持简洁

2026年5月20日，在动作角色扮演游戏（ARPG）里，构建工艺（Buildcraft）乍看是内容问题，随着组合增加情况不同。例子节选自用Zig编写的ARPG游戏引擎，技能、辅助、物品和运行时规则需相互组合。起初各规则看似没问题，如辅助增加伤害、让投射物穿透目标等，但组合出现后问题就来了，像不同效果的顺劈斩、投射物技能等。一种做法是增加特殊情况处理，但游戏元素多了会棘手。更有效的思路是把构建工艺视为小型编译管道，创作内容是源输入，辅助等产生事实并整合到派生缓存，战斗环节使用缓存。在这种设计下，技能解析时问题转化为底层运行时数据。

创作数据应保持简洁

辅助定义是词汇范围较窄的数据，并非可执行游戏玩法代码。一个辅助可产生属性修改和行为改变，不直接访问投射物存储等。给出辅助定义示例，可看作内容而非行为代码，适用于标记为近战和区域的技能。未来技能可与现有辅助规则配合，面向玩家的标签和运行时适用性标签不必相同。

辅助编译成行

技能插槽变化时，需清除旧编译输出才能生成新输出。这一步将装备技能和激活辅助转化为属性修改行和行为产生行。`active_support_mask`很重要，宝石等级决定辅助插槽解锁。删除步骤和生成步骤同样重要，否则陈旧编译输出会影响结果。

行需要来源信息

编译管道保留源标识，属性修改行显示数值来源更有用，后续系统可利用此信息移除行、重建缓存并解释结果。没有来源信息，系统无法回答更有价值的问题。

实体范围和技能范围是不同的通道

有些辅助影响整个实体，有些只影响被支持技能，这种区别编译到属性修改行中。编译管道明确保留范围信息，体现了作用域、命名空间和重写。

行为产生携带形状，而非行为代码

属性行相对简单，行为改变更复杂。它们通过单独产生类型整合到技能缓存中，缓存条目是技能插槽的运行时摘要，分离很重要，战斗环节使用摘要，检查和清理用源行。

脏域限制重建范围

模拟过程不应每帧都重建所有派生事实，变更标记脏域，重建步骤处理受影响实体，这是微型增量编译。部分为了性能和明确职责，使用属性的系统无需询问数据更新情况。

标签是适用性过滤器，而非技能矩阵

行为重建步骤将行整合到技能缓存，缓存从行中重建，适用性基于标签。内容可按标签描述，避免庞大技能/辅助标识矩阵，便于找到辅助应用错误的问题。标签粒度是棘手部分，但问题范围相对较小。

规则重写与属性计算分离

有些构建效果改变其他事实解释方式，如“法术伤害适用于近战”。行为重建有部分处理此问题，源事实产生规则，缓存重建解释规则，这种规则来自创作物品效果等，特殊情况限制在一层。

解析过程使用编译后的事实

技能解析时，投射物路径从缓存开始，投射物传递过程使用关心的字段，此层面基本无辅助ID，关键路径使用编译后的事实，源归属信息用于清理等。

限制特殊情况

内容契约有限制，行为缓存有固定设置。具体限制取决于游戏，重要的是限制可见，若内容超出限制，内容模型和引擎契约需一起改变。

设计现状

目前编译管道各阶段有职责，创作数据声明式，存储保留源标识等。设计有前景，添加辅助只需添加源事实。存在标签粒度等问题，但比一次性战斗分支好处理。设计提供测试切入点和处理特殊情况位置，目标是避免不良情况，是带着剑的小型编译器。