嘴遁大师

问题：关卡几何由对话内容决定。 平台尺寸、落脚点、机关和文字显现必须跟节点走； 传送、受击和复活会产生位移，不能把这类位移当成玩家「走完了这一句」。

做法：一条对话节点对应一块平台物体，文字、碰撞、锚点和可选机关组挂在同一处。 文字按角色在平台上的水平行程逐步显现；超过阈值的位移视为传送，不计入行程。 推进器维护平台对象池，按屏幕比例槽位排版，节点完成后锁定输入、延迟再切到下一节点。 角色控制按不规则平台单独调：地面与空中加速度分开、单击跳与长按高跳、边缘保护只对平台层采样，低矮障碍可走上。

结果：正式关用手摆固定尺寸，手感可逐关调； 自定义关卡因文本长度未知，另做按实际高度累加的布局。两套排版分开，避免互相改坏。

问题：每关都需要角色、输入、HUD 和结算。 如果每个关卡场景复制一份壳，改一处流程就要改所有场景； 叠加加载时，壳上的流程脚本也拿不到关卡里尚未就绪的对象。

做法：进关只做门控：校验解锁、消耗体力、记录当前关，再交给常驻过渡遮罩。 遮罩盖住之后加载玩法壳，关卡场景再叠加进来。 结算与复活挂在壳上，等关卡场景加载完成再绑定引用。 自定义关卡不走正式进关，避免误写进度。

结果：改 HUD、复活和输入只动玩法壳； 关卡场景只带数据和摆放内容。新增一关不必复制壳。

问题：关卡挂在不同联系人下，解锁要能跨联系人、卡评级、卡时间。 主界面还要按「当前能接触到什么」过滤，而不是把整张图摊开。

做法：联系人与关卡都是 ScriptableObject。 解锁条件按 AND 组合，支持立即、次日和延迟小时。 「已出现」和「可进入」分开：付费关可以先出现在列表里，购买后才能进。 通关后扫描全部关卡数据，把新满足条件的条目标为已出现。 复活花费和首通奖励由全局经济配置按难度换算，不在关卡上手填价格。

结果：加关主要是填数据和摆场景； 主界面未读数量等于已出现但未通关的关卡数，进度用 JSON 本地持久化，并带字段迁移。

问题：目标平台是微信小游戏。 SDK 在编辑器里不可用，业务逻辑又不能到处写条件编译； 用户生成内容一旦发出去就难以撤回，检查必须发生在对外分发之前。

做法：自定义关卡复用正式关的对话节点，运行时不转换格式。 分享业务只依赖一组接口：存储、内容检查、拉起卡片。 编辑器使用本地实现，微信实现只编进 WebGL，启动时替换。 流程固定为检查、落库、再拉卡片；启动参数只带分享标识，不带正文。 从后台回到前台时按平台生命周期领取，不假定会重新跑一遍启动逻辑。

结果：同一套业务在编辑器里就能验证领取、过期和失败回显； 真机只换实现。内容检查的最终判定放在云函数，不依赖客户端拦截。