文章摘要
这篇文章分享了作者在Develop Brighton 2026的演讲内容，讲述了使用Godot引擎开发商业VR游戏并移植到PSVR2的经验，包括支付约8万英镑的早期采用成本、重写Godot核心渲染服务器，以及呼吁平台持有者和渲染程序员关注开源引擎。
文章总结
好的，这是根据您提供的英文文章内容，使用中文重新陈述的主要信息，已保留关键细节并删减了与主题无关的个人感慨和部分冗余内容。
标题：Godot VR 游戏发布与移植至 PSVR2 的阶段性复盘
核心摘要： 本文是作者在 Develop Brighton 2026 会议上演讲的文字版。核心结论是：Godot 引擎确实可以用于发布商业 VR 游戏，但团队为此支付了约 8 万英镑的“早期采用者税”。文章分享了重建 Godot 核心、与社区合作进行 PS5/PSVR2 移植的经历，以及作者为何最终为 Godot 4.7 版本重写了一个全新的渲染服务器。文章最后向平台持有者和渲染程序员发出了呼吁。
第一部分：背景与现状
- 作者简介： Claire，自 PS2 时代起从事游戏开发，Godot 贡献者（主要涉及 OpenXR 和渲染），有丰富的 VR 开发经验，曾参与《Dreams》等项目，目前正在开发《Augmental Puzzles》。
- Godot 引擎的适用性： Godot 对于 2D 游戏和大多数简单 3D 游戏是绝佳选择。但对于开放世界、流式加载、大量角色动画或追求极致写实风格的游戏，Unreal 可能更合适。对于初入 VR 的开发者，Unity 的渲染器可能更强大。Godot 的资产库目前仅限免费内容，且社区控制台移植方案尚不成熟。
- 商业 VR 的可行性： 可以，但需要付出代价。团队在引擎工作上花费了约 8 万英镑，这笔开销在 Unity 上是不需要的。这个数字不包括 PS5/PSVR2 的移植工作。
- 项目历程： 团队此前尝试过多个 Godot VR 项目，如《Digging VR》（因渲染功能缺失搁置）、《Rune Magic》（因玩法问题取消）、《Magic Shop》（因资金问题取消）。最终，团队转向了《Augmental Puzzles》，一个基于数独的 VR 解谜游戏。
- Godot 的开发速度： 游戏核心在两天内即可玩，一周内完成完整菜单流程。Godot 的快速原型能力是其巨大优势。
第二部分：为商业 VR 重建 Godot 核心
- Godot 引擎的架构问题： 其核心是 90 年代风格的面向对象引擎，存在诸多问题，例如：使用 Variant 联合类型、对象 ID 数据库锁竞争严重、场景图不支持非均匀缩放、渲染器非绑定式且非线程化、内存模型基于 POSIX 且效率低下。这些设计主要源于其早期开发者并非面向控制台开发。
- 优点： 高度模块化，开发者可以像改装赛车一样，只修改游戏需要的部分。
- 实战故事 1：Label3D 导致帧率崩溃
- 问题： 在 VR 中，Label3D 组件为每个字符生成独立材质，导致材质创建风暴和帧率尖峰，这在 VR 中意味着帧提交失败。
- 解决方案： 开发了 FastText 替代方案。通过共享字体资源、预烘焙所有字形、每个节点单次绘制调用，并使用自定义着色器驱动字符颜色，解决了性能问题。
- 后续： 利用进入公有领域的 Slug 字体专利，FastText 现已支持基于 GPU 曲线的无限分辨率字体渲染。
- 实战故事 2：合规性与商店平台
- 问题： Godot 核心缺乏对用户权限、排行榜、事务性存档、会话管理等基础 API 的支持。社区插件多为单平台且可能不符合 GDPR 等合规要求，给控制台提交带来巨大麻烦。
- 解决方案： 团队自行构建了统一的中间件层，为所有平台提供单一接口，处理离线模式、多存档槽、云存档合并和合规的身份验证状态机。
- 扩展、模块与插件的混乱： 三者并非完全等同，Android 扩展的 JNI 桥接、外部库链接等问题耗费了大量时间。此外，Godot 使用的 SCons 构建系统非行业标准，导致无法有效利用分布式构建，拖慢了开发效率。
第三部分：PS5 / PSVR2 移植挑战
- 社区移植的缘起： 由于对 W4 公司“官方”控制台移植的沟通方式不满，作者决定发起一个社区驱动的 PS5/PSVR2 移植项目。
- 移植现状：
- 4.5 社区版： 2D 游戏已可开始移植，3D 光照工作正在进行中。代码为 MIT 许可，需注册为 PlayStation 开发者才能获取。
- 4.7 私有版： 完全专注于 VR 需求，包含对渲染服务器的完全重写，将在未来发布。
- 移植团队： George Marques（负责构建系统等基础工作）、André Ewald（负责 4.5 版移植和 Discord 社区）、作者本人（负责内存模型、IO、渲染管线等）。
- 主要战斗 1：POSIX IO 与统一内存架构
- 问题： Godot 基于 POSIX 的文件模型已过时。现代设备（手机、VR 头显、游戏机）均采用统一内存架构和高速 NVMe 存储，但 Godot 的 pck 虚拟文件系统效率低下，充斥着本地缓存和内存拷贝。
- 解决方案： 团队尽力优化了资源系统，但仍有很大改进空间。
- 主要战斗 2：着色器管线瓶颈
- 问题： Godot 的着色器编译管线冗长（GDShader -> GLSL -> SPIR-V -> SPIRV-Cross -> PSSL）。宏定义导致生成的 GLSL 文件巨大，编译器难以优化。在 AMD 控制台硬件上，会因寄存器限制导致编译失败，且调试迭代周期极长。
- 解决方案： 为 4.5 版构建了自定义的 SPIRV-Cross 后端，直接输出原生 PSSL，并处理了 200-300 个着色器变体的反射表，目标是让开发者的 GDShader 能在 PS5 上“开箱即用”。
- 转折点： 作者意识到，将 Godot 4.5 移植到 PS5，本质上是将 90 年代的决策移植到 2020 年代的硬件上。因此，她决定为 Godot 4.7 重写一个全新的渲染服务器。
- 新渲染器架构：
- 纯绑定式渲染： 使用无锁的 SPSC 环形缓冲区传递命令流，消除对象数据库的互斥锁开销。
- 显式核心亲和性： 将物理、游戏逻辑、渲染等任务明确映射到特定 CPU 核心，优化缓存行为。
- 材质驱动管线： 材质决定执行流程，而非场景树。
- 平台原生着色器： 直接编写 PSSL（PS5）、Metal（Apple）或 GLSL（Vulkan），以获得最佳性能和可调试性。
- 默认统一缩放： 非均匀缩放作为特殊情况处理，以加速 GPU 管线。
- 进展： 已实现画布渲染、纹理、光照等基础功能，VR 立体渲染也已跑通。
第四部分：呼吁与展望
- 对平台持有者的呼吁： 借鉴 PhyreEngine 和 NVIDIA/Apple 的做法，将工程资源投入到 Godot 这样的开源引擎中。这比编写孤立的示例程序更有价值，能展示平台优势，并打破引擎双头垄断。
- 对游戏工作室的建议： 采用 Godot 并非因为它是一个开箱即用的 AAA 引擎，而是将其作为技术栈的“种子”。你本就需要花费成本去定制 Unity 或 Unreal，而在 Godot 中，这笔投入换来的是你完全拥有的代码。即使深度修改，仍可保持 Godot 的编辑器和脚本语言，降低招聘和外包成本。
- 参与方式：
- VR 开发者： 可参加 Godot XR 游戏开发大赛。
- PlayStation 开发者： 可通过 DevNet 论坛申请加入 4.5 社区移植项目。
- 渲染程序员： 请积极参与着色器模板、绑定式渲染等未来 Godot 渲染架构的讨论和代码审查。
- 结论： Godot 让团队快速启动项目，早期采用者税是真实存在的，社区移植已让 2D 游戏在 PS5 上运行。作者最终停止了移植旧决策，转而构建了 VR 优先的新渲染器。4.5 版移植在继续，4.7 版渲染器已能渲染立体光照场景，而《Augmental Puzzles》即将登陆 PSVR2。
评论总结
根据评论内容，总结如下：
主要观点与论据：
对Godot性能的批评（评分：无，作者Yokolos）：用户反映在Godot上开发游戏时性能问题严重，不得不将大部分代码迁移到纯C#，甚至放弃Jolt物理引擎。渲染器成为限制大量飞船同屏战斗的瓶颈。关键引用："performance has been a nightmare" / "I'm constantly hitting the limits of what Godot can do"。
对Godot易用性的肯定（评分：无，作者Yokolos）：尽管性能不佳，但用户认可Godot的快速上手体验，不后悔选择它。关键引用："Getting up and running in Godot was surprisingly, blindingly fast" / "I don't regret picking it at all"。
对技术细节的质疑（评分：无，作者a1o）：用户对资源管理系统、POSIX的缺陷以及统一内存感知等具体技术细节缺乏解释表示不满。关键引用："I could use a lot more information on why POSIX is bad" / "exactly what it means on resource management being 'aware' of unified memory"。
平衡性总结： 评论呈现两极分化：一方面肯定Godot的快速上手优势，另一方面强烈批评其性能瓶颈和技术文档不足。用户对具体技术细节的追问表明，Godot在高级功能（如资源管理、物理引擎）的透明度和优化上存在明显短板。