A Joy Way, desenvolvedora do jogo STRIDE, compartilha suas práticas de desenvolvimento multijogador e multiplataforma de RV

Como lidar com múltiplas plataformas rodando em apenas um SO

Ao desenvolver STRIDE, enfrentamos o problema de algumas das plataformas de RV (Pico e Meta Quest) rodarem em Android. Por causa disso, surgiram vários problemas: não poderíamos mais usar as configurações de plataforma da Unreal para diferenciar valores de configuração que o Pico e o Quest tinham em comum. Por padrão, no código, não é possível determinar em qual plataforma se está. Confira as soluções que adotamos.

O problema dos valores de configuração pode ser resolvido com uma injeção de argumentos -ini na Unreal Build Tool. Você pode implementar isso em seus scripts de compilação de CI/CD e inserir as configurações -ini na Unreal Automation Tool para sobrepor as configurações. Use o formato seguinte:

Você pode ler mais sobre as injeções de configuração aqui. Além disso, há uma maneira de modificar a Unreal Automation Tool para aplicar valores de configuração injetados em um jogo compactado. Leia mais aqui.

Com isso feito, você pode inserir um valor de configuração para o UAT e especificar em qual plataforma você está.

A próxima etapa é adicionar as definições de plataforma referentes aos dispositivos Pico e Quest. Observe a diferença entre GlobalDefinitions do Target Rules e PublicDefinitions do Module Rules. Por padrão, o UAT produz duas versões: uma para o editor (para executar Commandlets durante a compilação) e outra para a plataforma de destino. GlobalDefinitions são definições para todo o alvo. Isso significa que, se você definir as plataformas como Pico/Quest em GlobalDefinitions, a compilação do editor (necessária para executar Commandlets) também terá a definição da plataforma indesejada. Considerando isso, você tem que colocar uma definição de plataforma em PublicDefinitions do Module Rules. Confira como você pode fazer isso:

Agora você pode usar diretivas conhecidas de pré-processador para determinar em qual plataforma você está no código C++ e usar o UBlueprintFunctionLibrary para expor verificações de plataforma aos Blueprints.

Primeiro, começamos a implementar chamadas de API usando callbacks de função lambda para respostas. No entanto, logo ficamos com muitas chamadas aninhadas, e ficou bem difícil de lidar com o código. Portanto, decidimos tornar cada solicitação uma UBlueprintAsyncActionBase separada.

É bastante simples usar nós de UBlueprintAsyncActionBase gerados automaticamente em Blueprints. Confira o guia de programação.
 

Agora, vou desmistificar a extensão do UObject e compartilhar algumas dicas não tão óbvias.

Primeiro, há apenas uma coisa que você deve estender. GetWorld para chamar funções globais com o WorldContext. Confira um exemplo de código de sobreposição de Worker GetWorld .

Preste atenção na primeira verificação do CDO. Isso fará sentido mais adiante.

Aqui está o exemplo de código com a criação de um Worker.

Resumindo o que foi dito acima, é preciso herdar do UObject, sobrepor o GetWorld, herdar do Worker em C++ e, por fim, instanciar o objeto correto no núcleo do ciclo de vida do Worker. Confira como obter uma classe de Blueprints para instanciar um objeto correto.

Agora, vamos abordar o CDO. Como você pode ver, atribuímos a variável TSubclassOf na construção do GameInstanceSubsystem. A essa altura, você pode ter problemas se não fizer uma verificação de CDO. Sem essa etapa, nós enfrentávamos falhas no editor e muitos problemas no sistema de recursos. Você pode acabar tendo os mesmos problemas.

Separar cada solicitação e expor as cadeias de solicitações aos gráficos do Blueprint ajudou a resolver o "código espaguete" e facilitou a manutenção do código do back-end. Dessa forma, pudemos fazer iterações mais rápidas e tivemos menos bugs.