第 10 章未来的 Portal：BF 系列创造力的去向

第 10 章未来的 Portal：BF 系列创造力的去向

 0 未来的 Portal：BF 系列创造力的去向以变化为前提来制作，思考方式就更不容易坏掉
做法会变化：工具规格、AI 行为、UI 标准一变，最佳实践也会跟着变。如果把现在的“正确答案”当成固定答案来记，每次变化都要重新来过。
变化也是机会：规则编辑器和地图编辑器的功能越多，就越有可能用更少的代码做得更安全。
学会“该看哪里”，不安就会减少：什么容易变，变了之后该检查哪里。只要有关注点和重新解读的步骤，更新就不会那么可怕。
本章不是要预测未来，而是整理一套思考方式，让未来真的到来时你不会迷路。
 1 容易变化的东西与不容易变化的东西先整理一下。容易变化的东西要每次重新检查，不容易变化的东西则可以长期复用。
 容易变化UI 的做法，例如消息显示方式、HUD 标准
SFX/FX 的播放方式，例如冷却时间和拥挤时的推荐处理
XP 和发布相关的处理，需要始终意识到可能会因情况受到限制
 不容易变化“文字 → 标记 → 效果” 的顺序，这是传达信息的基础
用名称管理 ID，也就是 ids.ts
明确状态，并用 Phase 和 onceIn 做出只能通过一次的路径
边界 / 状态 / 呈现这三个箱子，也就是第 7 章的分割设计
面向未来要调整的是“做法”。一直要守住的是“思考方式”。

能分清这两者后，变化就会从“麻烦事”变成“有趣的调整”。
 2 配合工具进化的“重新解读” 2.1 规则编辑器增加或变化时重新解读方式：新增事件或新动作出现时，不要到处直接调用。先在 api.ts 或 ui.ts 中做一个自己的调用函数。不要增加从 main 或 Script.ts 直接调用 API 的位置。
检查：确认它和现有的 onceIn（单向通过）相性不差。替换后仍然要保持不会多重触发的结构。
在编程里，这种薄薄一层的调用函数有时叫做“包装器”。

这里重要的不是术语，而是即使 Portal API 的调用方式变了，也能把需要修改的地方集中到一处。
 2.2 地图编辑器的对象增加时重新解读方式：按照第 4 章的规则，只要不重复 ID，并按需要增加系列即可。
检查：Shared 系列要注意基础地图兼容性。像第 4 章养成的习惯一样，照常确认是否出现警告标记。
 2.3 UI 标准变化时（通知、图钉、图标）重新解读方式：让 ui.say 可以在一处替换，和第 7 章、第 8 章的做法一致。
检查：不要破坏“一次只传达一件事”的原则。即使来了新的 UI，也不要同时显示多个东西。
效果：演出“吵不吵”的标准会随时代变化，但只要设计上避免过度展示，就不容易偏离。
 3 AI 与脚本的关系（为今后的扩展做准备）AI 相关功能是很容易受益于进化的领域。
现在的做法：使用 AI_Spawner 和 AI_WaypointPath，并确保生成点前方有余地、拐角不要太急（第 4 章）。
扩展余地：如果 AI 行为 API 增加，就把 “行为是数据，开始信号是事件” 分开。
例）把 行为配方 定义成固定值，规则侧只调用 “开始配方 A”。

理由：AI 的细节命令容易变化。信号的骨架（按下 → 引导 → 到达 → 演出） 不容易变化。
实现备忘：从现在开始，就把 AI 相关代码集中到专用位置，未来会更容易替换。
 4 性能与规模（提前养成习惯）将来，如果更大的地图和更高密度的战斗成为标准，那么不容易变重的做法会一直发挥作用。
避免每帧处理（第 8 章 9）：距离更新和引导每 0.5-1 秒一次通常就够了。
自己决定同时播放上限，例如 SFX/FX 最多同时 3 个。
做成“可以切掉”的设计：远距离不播放演出。在 ui 中加入距离过滤。
测试习惯：运营时插入一次满员测试（第 9 章）。
这样未来遇到“容易变重的场面”时，也能用同样步骤验证。

 5 发布后用少人数慢慢养成的做法模式只有被玩到之后才会成长。

不过，在 Portal 里，一个无名的个人模式只靠自然流量聚集玩家并不容易。

如果没有大型主播或现有社区带来的导线，就不要过度假设会持续聚集大量玩家，这样更安全。
本书并不把集客本身作为目的。

发布后应该观察的是：来到这里的少数玩家能不能不迷路地开始，会不会无法推进，以及你能不能看出下一步该修哪里。
养成第 9 章的 256 字符以内短句模板：目的 / 人数 / 所需时间 / 最初行动。
不要以标签补充为前提：先当作创作者没有可自由添加的标签，用标题、说明、缩略图和外部公告传达。
小幅改善 → 立刻发布：根据少数人的反馈，修正迷路的地方和过长的场面。
外部公告不要硬铺太多：X、Discord、Blog、Note 等，选择一个自己能持续更新的地方。
 6 “未来适应性”检查清单（每半年一次）每半年只检查下面这些就够了。
ids.ts：用 Vitest 检查 -1、重复和用途不明的 ID。Godot 侧的配置 ID 用 ObjIdManager 或第 4 章的台账确认。
ui.ts：检查 say / guide / celebrate 的顺序和频率，确认没有变得太吵。
config.ts：防守秒数、冷却时间、推荐人数等数值是否符合当前环境。
flow（转换表）：分支是否增加过多。不需要的分支要折叠。
性能：满员时只做一次负载测试。
说明文：是否和实际内容有偏差。256 字符以内要看得懂目的、人数、所需时间和最初行动。
 7 把“今天的正确答案”变成“明天的素材”做完、发布、然后结束，这样太可惜了。
复用：把 ui、api、game、ids 这四件套作为模板复制到下一个模式。
轻量开始：新功能出现时，先小范围试用，再轻轻合进模板里。
有舍弃的勇气：已经变重的小技巧，不要在下一个模式一开始就塞进去。过去是图书馆，现在是现场。
 8 创造力的去向（创作者视角）“正确地害怕”会保护创造力：以变化为前提，只固定不该坏掉的核心，也就是 ID、状态和顺序。
“最小循环”会成为文化：只要能共享按下 → 引导 → 到达 → 演出的流程，多人也能快速制作。
“可视化”会带来发明：在调试 HUD 中看得到数值和状态时，实验 → 学习 → 改善的速度会变快。
未来不只是“新武器增加”。

“传达方式的规则”也会更新。你每次只需要 稍微 改写一点。
 结论第 10 章不是预测未来的章节，而是让你扎实建立一种不会被未来折断的制作方式。
要守住的是 ID 命名 / 状态与单向通过 / 文字 → 标记 → 效果 / 三箱分割。
会变化的是 API 调用方式 / UI 做法 / AI 的细节动作。那里只要在 api 或 ui 的一处修改即可。
每半年做一次未来适应性检查，你的模式就能活得更久。
 附录 / 后续指引附录 A：主要事件与动作列表
附录 B：官方示例程序解说
附录 C：modlib 解说
本章不是 最后的哲学，而是 明天也能继续制作的工具箱。把本章的观察方法叠加到第 3-8 章建立的步骤上，无论 Portal 如何进化，你的创作都能继续。