Wishfully如何在多个平台上同时发布《拉娜星球II》
《拉娜星球 II 是由瑞典独立工作室 Wishfully 开发的一款电影式解谜冒险游戏，该工作室成立于 2018 年，位于哥德堡。在 PC、Xbox、PlayStation® 和 Nintendo Switchᵀᴹ 上提供这种体验，包括下一代硬件，是一项重大的技术挑战。
我们与工作室的联合负责人兼创意总监 Adam Stjärnljus、高级程序员 Edvard Rutström 和首席程序员 Mattias Wargren 坐下来，讨论他们如何统一代码库、扩展构建管线，并优化游戏以在大多数平台上达到 60 fps，同时在 PC 和主机上同时发布。
*Nintendo Switch 是 Nintendo 的商标。
您能分享一下 《拉娜星球 II 的概述及其作为多平台项目的范围吗？
Adam Stjärnljus:《拉娜星球 II 在原作的基础上增加了大约两倍的内容和扩展的范围。与第一款游戏不同，第一款游戏在 Xbox 和 PC 上发布后，我们将其移植到其他平台，而续集则是为 PC、Xbox One 和 Xbox Series X|S、PlayStation 4 和 PlayStation 5 以及 Nintendo Switch 系统的同时多平台发布而开发的。我们于 2026 年 3 月 5 日发布了它。
它仍然是一款解谜冒险游戏，讲述了拉娜和她的伙伴 Mui 在一个以故事为驱动的旅程中，融合了解谜、平台跳跃和潜行元素。核心游戏玩法专注于拉娜和 Mui 之间的合作互动，而叙事则扩展了第一款游戏的世界和冲突。
团队采取了什么方法来定义同时多平台发布的愿景，以及哪些因素影响了平台阵容？
AS:我们以多平台优先的思维方式来处理续集，并在第一款游戏的基础上构建平台抽象和工具。我们的目标是在生产早期在所有目标平台上进行连续构建，以便我们可以在开发过程中测试和优化性能，而不是将这项工作留到最后。
我们根据原始发布的成功和在所有平台上实现同时发布的目标选择了平台阵容——PC、Xbox、PlayStation 和 Nintendo Switch 系统。为了支持这一点，我们对现有工具和工作流程进行了迭代，以便整个团队能够在早期贡献性能改进，尽管在所有目标平台之间保持一致性仍然具有挑战性。
你的技术架构如何支持高效的多平台构建和部署，而不产生平台特定的代码孤岛？
马蒂亚斯·瓦尔格伦：我们通过使用一个没有平台分支的单一Unity项目，并在第一个游戏的共享平台抽象层上构建，避免了平台碎片化。我们通过编译时定义、条件系统和工具来处理平台差异，而不是维护单独的代码库。
我们还实施了内容过滤工具，以根据平台包含或排除素材资源，并设置了可以根据设备调整的分级质量和细节级别。在Unity内置设置的基础上，我们添加了一个自定义质量系统，以获得更大的控制权。
AS:这个设置允许设计师和开发者根据目标设备调整内容和性能，同时保持在单一管道中的统一性。这使得在整个制作过程中保持构建高效和可管理。
你是如何构建管线以支持跨所有平台的部署，同时避免构建瓶颈的？
埃德瓦德·鲁特斯特伦：我们早期优先考虑构建管线，从使用TeamCity和专用构建代理的本地设置开始，以保持构建不在开发者机器上进行，避免争用。在项目的后期阶段，我们转向了一个由发行商托管的基础设施，增加了更多的构建代理，这使得跨所有平台的自动夜间构建成为可能，并减少了瓶颈。
我们还必须支持跨所有平台的公共演示，这增加了构建的复杂性，并有效地使构建数量翻倍。我们在同一个代码仓库和项目中处理这个问题，使用构建标志来定义演示与完整游戏，在构建时剥离非演示内容。虽然这在技术上运作良好，但管理构建的数量，特别是QA需要调试和发布变体，成为了一个主要的负担。
MW：我们设计了这个管线以便于移植。我们在迁移基础设施时不需要更改代码库或构建脚本，因此过渡是无缝的，没有干扰开发。
什么集成策略确保了在多个特定平台的优化并行开发时的稳定性？
MW：我们通过结合共享的质量层和强大的验证工具实现了稳定性。我们实施了平台感知的质量模式，可以直接在Unity编辑器中模拟，这使设计师和艺术家能够预览内容在不同硬件上的表现，而无需分支项目。
我们还构建了自动化工具，以逐步检查点、捕获屏幕截图并覆盖性能指标。这使团队能够持续洞察更改如何影响不同目标平台，并使得在保持代码库稳定的同时并行迭代成为可能。
你是如何构建你的资产管线以简化多平台构建并减少资产重复的？
ER:我们不再采用内容捆绑的重型方法。避免资产重复被证明是困难的，特别是因为我们在游戏中重用了生物群落内容，这使得清晰分离变得不切实际。
相反，我们依赖于更受控的资产管线。我们通过FMOD中的隔离音频库和通过精灵图集处理视觉效果。为了优化不同硬件层，我们专注于资产剥离和图集大小限制，这减少了内存使用而不引入额外的重复。
这种方法使构建更简单，同时确保了跨设备的可预测加载行为和稳定的内存使用。
你的游戏玩法系统如何使用C# Job System和Burst编译器支持多平台构建部署？
ER:我们在一些目标系统中使用了Unity C# Job System和Burst编译器，主要是处理火、热和水的元素模拟以及雪变形系统。
由于这些系统的范围明确且以数据为导向，它们在不同硬件上能够顺利转换，而无需特殊处理。我们没有遇到崩溃或竞争条件，因此标准的作业系统最佳实践就足够了。
您如何使用分析数据来指导构建配置和平台特定的优化？
MW：我们依赖于所有平台的开发构建中的分析，并使用自动快照来识别每个关卡的问题区域。我们没有从一开始就独立调整每个平台，而是专注于对所有目标平台都有利的改进，然后在需要时细化特定热点。
ER:我们从低规格的基线通道开始，针对CPU瓶颈，有时也针对GPU瓶颈，进行优化以保持视觉质量。这项工作向上推进，帮助我们在大多数目标平台上达到60帧每秒。我们还广泛使用内存分析来管理资产加载和内存占用。
AS:这是一个连续的循环。我们进行了分析，识别出绘制调用和帧率下降等问题，进行了优化，然后重复。随着时间的推移，这演变成一种工作流程，使设计师能够更早理解性能限制，从而减少后期的返工。
您如何配置和构建导航系统，以确保它们高效部署并在多个平台上表现一致？
MW：我们使用了静态和动态NavMesh体积的组合，平衡了预计算数据与运行时灵活性。我们通过质量配置调整每个平台的导航设置，这使我们能够控制每个设备的精度和性能成本，同时保持一致的行为。
事后看来，您会做出哪些不同的决定，您会给尝试同时进行多平台发布的团队什么建议？
ER:我们会改变的一件事是自动化构建管道中的补丁创建。手动进行这项工作耗时且无法扩展。
我们最大的收获是从第一天起就进行多平台开发。尽早在所有目标平台上构建和测试，不要将优化推迟到最后。我们还开发了一个平台抽象层，封装了保存数据、成就和用户处理等常见功能，通过一个单一的API提供。这使得实现相互隔离，并且更容易支持新平台，而不影响其余的代码库。
要了解更多关于使用Unity制作的项目，请访问资源页面。