使用 Reality Composer Pro 3 设计无代码游戏

一句话判断

这场 Session 最值得关注的一件事是：Reality Composer Pro 3 的 ScriptGraph 配合即将推出的 Vision Pro 实机 Live Preview，彻底把 visionOS 空间交互的“调参权”从程序员手里抢走，交给了设计师。

这场 Session 讲了什么

以前做 visionOS 原型，设计师画个草图，程序员写一堆 RealityKit 代码，戴上头显发现手势灵敏度不对，再回去改代码重新编译，循环极其痛苦。现在 Apple 在 Reality Composer Pro 3 (RCP3) 里塞进了 ScriptGraph（基于节点的可视化脚本系统）。

你不需要写 Swift 代码，直接在 RCP3 里连线就能监听 On Drag 事件、修改 Transform 甚至接入物理引擎。更狠的是，你可以把变量设为 public，在 Vision Pro 上实机预览时直接拨动滑块调参。这套工作流对技术美术 (TA) 和独立开发者来说是史诗级增强，但对习惯纯代码的工程师来说，可能需要适应这种“所见即所得”的节点逻辑。

值得深挖的点

ScriptGraph 与 Vision Pro 实机调参的化学反应

Apple 推 ScriptGraph 绝不是为了做个玩具级别的蓝图。visionOS 开发最大的痛点是“空间感无法在 2D 屏幕上预测”。你在 Mac 上用鼠标拖拽觉得刚好的物理阻尼，戴上 Vision Pro 用手捏住一甩，可能直接飞出窗外。

ScriptGraph 巧妙解决了这个问题。演示中 Saschka 把拖拽速度 dragSpeed 设为 public 变量。在 RCP3 里，这个变量会暴露在实体的 Scripting Component 上。配合今年晚些时候上线的 Vision Pro 实机 Live Preview，设计师可以直接戴着头显，看着 Mac 虚拟显示器上的 Inspector 面板，实时修改 dragSpeed 的值（比如从 1.3 调到 1.15）。这种 Override（覆盖）机制意味着同一个 ScriptGraph 可以复用在多个实体上，每个实体有独立的参数。这直接把 Unity/Unreal 里成熟的 TA 工作流搬到了 visionOS，大幅降低了空间交互原型的试错成本。不过坑也很明显：节点一多，连线会变成“意大利面条”，RCP3 目前缺乏强大的节点搜索和调试断点功能，复杂逻辑还是得老老实实写 Swift。

3D 场景与 SwiftUI 的跨界事件驱动

Session 后半段展示了如何用 ScriptGraph 触发 SwiftUI UI，这是 visionOS 混合现实开发的典型场景。当 3D 场景里的松鼠需要说话时，ScriptGraph 触发一个名为 squirrelTalk 的 Custom Event（自定义事件），并带上文本参数。SwiftUI 侧通过 scene.subscribe 监听这个事件，更新状态并渲染 Attachment（附件）。

这种设计选择背后的 trade-off 很明显：Apple 希望 3D 逻辑和 2D UI 逻辑解耦。设计师在 RCP3 里把控“什么时候说话”，程序员在 Xcode 里写“气泡长什么样”。相比以前在 RealityKit 代码里硬编码事件分发，这种方式让非代码人员也能参与 UI 触发时机的编排。但要注意，跨边界的事件传递只有简单的数据类型（如 String、Float），如果你想在 3D 和 2D 之间传递复杂的结构体或闭包，ScriptGraph 就无能为力了，必须回到纯代码的 Entity Component System (ECS) 架构。

代码片段

1. 监听 3D 场景的自定义事件

场景：在 SwiftUI 中接收 ScriptGraph 抛出的 squirrelTalk 事件，并更新 UI 状态。

// 监听 RealityKit 场景中的自定义事件
if let scene = entity.scene {
    scene.subscribe(forEventName: "squirrelTalk", on: { event in
        // 尝试从事件中提取字符串参数
        if let sayThis: String = try? event.value("sayThis") {
            self.sayThis = sayThis
        }
    }).store(in: &cancellables)
}

坑：event.value 是泛型方法，如果 ScriptGraph 里传的类型和 Swift 里接收的类型不匹配（比如传了 Int 接收 String），这里会静默失败返回 nil，不会报错，调试时极易抓狂。

2. 将 SwiftUI 视图作为 3D 实体的附件

场景：将上面接收到的文本渲染为对话气泡，并绑定到 3D 松鼠实体上。

// 在 RealityView 的 attachments 闭包中定义 UI
RealityView { content, attachments in
    // 加载 3D 实体逻辑...
} attachments: {
    // 定义一个 ID 为 "squirrelTalk" 的附件
    Attachment(id: "squirrelTalk") {
        SquirrelTalkAttachmentView(text: sayThis)
    }
}

坑：Attachment 的 ID 必须与你在代码中通过 entity.components.set(AttachmentComponent) 绑定的 ID 严格一致，拼写错误会导致 UI 悬浮在虚空或者干脆不显示。

最佳实践

新项目采用建议：把 ScriptGraph 当作“胶水”和“原型工具”。用它来处理手势反馈、简单的物理碰撞、动画状态机和 UI 触发时机。一旦涉及网络请求、复杂数据解析或 ECS 系统级查询，立刻切回 Swift 代码。
已有项目迁移：不需要把现有的 RealityKit 逻辑推翻重写。你可以把 ScriptGraph 生成的逻辑封装成独立的 Scripting Component，与现有的自定义 Component 和 System 共存。
实战避坑：在 ScriptGraph 里大量使用 Prototyped Subgraph（原型子图）来封装常用逻辑（比如“检测变量是否改变”）。如果不做封装，你的节点图在两周内就会变成无法维护的蜘蛛网。

还有什么值得关注

物理引擎节点化：现在可以直接在 ScriptGraph 里用 Add Force 和修改 PhysicsBodyComponent 来动态开关重力，做抛物线交互不用再写物理系统代码了。
Live Preview 支持 Mac 虚拟显示器：在 Vision Pro 里预览时，可以调出 Mac 屏幕来实时改参数，不用频繁摘下头显看电脑。
Custom Node Library：允许创建自定义事件库，跨多个 ScriptGraph 复用事件定义，解决了大型项目里事件名称冲突和拼写错误的问题。