《STRIDE》的开发商Joy Way分享其如何实现VR跨平台多人游玩

处理运行同一操作系统的多个平台

开发《STRIDE》时，我们遇到的一个问题是，有些目标VR平台（Pico和Meta Quest）运行的都是Android系统。这导致了一些问题，出于这个原因，我们无法使用虚幻平台提供的配置将Pico和Quest重叠的配置值区分开来。默认情况下，在代码中，你无法确定当前处于哪个平台。我们采用了下面的解决方案。

通过在虚幻构建工具中注入-ini参数，即可解决配置值的问题。你可以在你的CI/CD构建脚本中实现这一点，并将-ini配置传递到虚幻自动化工具中，从而覆盖配置。请以这种格式传递：

你可以在这里阅读关于配置注入的更多信息。此外还有一种方法，可以通过修改虚幻自动化工具，在打包的游戏中应用被注入的配置值。请在这里阅读更多信息。

接下来，你可以向UAT传递一个配置值，以确定当前所处的平台。

下一步是为Pico和Quest设备添加平台定义。请注意目标规则中GlobalDefinitions和模块规则中PublicDefinitions之间的区别。默认情况下，UAT会生成两套构建：一套供编辑器使用（用于在构建期间运行命令行），另一套供目标平台使用。GlobalDefinitions是整个目标的定义。这意味着，如果你将Pico/Quest平台的定义放到GlobalDefinitions中，那么（运行命令行所必需的）编辑器构建也会拥有非必要的平台定义。考虑到上述情况，你应该将平台定义放到模块规则的PublicDefinitions中。以下是具体做法：

现在，你可以使用熟悉的预处理器指令，在C++代码中确定当前平台，并使用BlueprintFunctionLibrary将平台检查公开给蓝图。

最初，我们使用lambda函数对响应的回调实现API调用。然而，我们很快就得到了一大堆嵌套的调用，代码变得难以维护。所以，我们决定让每个请求成为单独的ULBlueprintAsyncActionBase。

在蓝图中使用UBlueprintAsyncActionBase自动生成的节点非常简单。这里是编程指南。
 

现在，我将揭开UObject扩展的神秘面纱，分享一些不易发现的技巧。

首先，你只需要扩展一个东西：通过WorldContext调用全局函数的GetWorld。以下代码示例重写了Worker GetWorld。

请注意对CDO的第一次检查。这将进一步说明问题。

下面是创建Worker的代码示例。

总结一下上面的内容。你应该继承UObject，重写GetWorld，然后继承你的C++ Worker，最后，在Worker生命周期的核心位置实例化正确的对象。下面的代码展示了如何从蓝图中获取一个类，以实例化正确的对象。

现在说说CDO。如你所见，我们在GameInstanceSubsystem的构造中指定了TSubclassOf变量。在这里，如果你不检查CDO，可能会遇到问题。在没有检查CDO的情况下，我们遇到了编辑器崩溃以及与资产系统相关的严重问题，所以你那里也可能会出现同样的情况。

将每个请求分开，并将请求链公开到蓝图图表中，有助于我们摆脱“面条式代码”的困境，使得与后端相关的代码更易于维护，从而加快迭代速度，减少错误。