A lista a seguir fornece uma visão geral dos principais requisitos de design técnico que pensamos enquanto trabalhávamos em O Mistério da Avenida Duvall.Para mais informações sobre o design visual desses elementos, veja o Mystery of Duvall Drive Showcase, que destaca as várias características e ferramentas do Studio que usamos para criar o ambiente imersivo.
Missões
Existem vários tipos de missões que os jogadores devem resolver para progredir através da experiência, incluindo navegar por uma série de plataformas giratórias até que os jogadores sejam capazes de recuperar um item especial ou encontrar diferentes ingredientes em uma panela expandida e colocá-los em uma panela fervente.Para organizar o processo de scripting de criação e depuração de missões, criamos um framework de missão e uma versão de depuração.
Estrutura da missão
Para garantir que unificamos cada passo da missão ao longo da experiência, projetamos um quadro de missão simples de quebra-cabeça para cada missão que consistia em ganchos para o início e o fim do quebra-cabeça, um espaço para ler dados de configuração e um botão para completar o quebra-cabeça para propósitos de depuração.Para mais informações detalhadas sobre esse processo e seus parâmetros, veja Lógica de Missões.
Selos e estados de jogo
Quando os jogadores entraram em salas específicas, queríamos que eles interagissem com objetos pequenos especiais conhecidos como focas para ativar missões.Depois de resolver a missão, queríamos que eles pegassem a assinatura e a colocassem em um local predefinido dentro do salão para prosseguir através do jogabilidadegeral.Depois de colocar o selo no local correto, eles poderiam então continuar para outra sala dentro da casa e iniciar a próxima missão clicando no Objetoespecial daquela sala.
Para implementar isso, criamos estados de jogo , que especificariam o período de tempo em que os jogadores poderiam iniciar o processo como:
- Procurando por um selo "corrompido" em uma sala para ativar a missão.
- Pegue o selo "restaurado" quando ele resolver a missão.
- Coloque o selo no círculo do foyer.
Estados de jogo controlam em grande parte o fluxo da experiência e como os jogadores interagem com a narrativa da experiência .Para mais informações, veja Gerenciador de Estado de Jogo.
Salas normais e corruptas
Queríamos ter dois estados de seis quartos na casa: um estado normal e um estado corrompido.Quando um jogador tocaria em um selo corrompido em uma sala para ativar o estado corrompido da sala, o ambiente mudaria para uma atmosfera mais escura com iluminação modificada, objetos ambientais e efeitos especiais especiais.Os jogadores então teriam que resolver a missão para retornar ao estado normal da sala.
Para implementar isso, preparamos um espaço especial na experiência que estava muito longe da casa, cerca de 6.500 metros de distância na direção X , que poderia abrigar o estado corrompido de uma sala.Quando um jogador ativa qualquer estado corrompido, o estado corrompido desse quarto específico se clona nesta área de ServerStorage até o diretório TempStorage/Cloned , então os jogadores teletransportam-se para esse quarto.Pequenas Parts existem dentro de cada sala normal e corrupta que servem como pontos de spawn para jogadores ao entrar ou sair de salas.Depois que eles resolverem a missão, nós teletransportamos os jogadores de volta ao estado normal da sala e destruímos todos os objetos no estado corrompido da sala.Para mais informações sobre os estados do jogo que controlam esse processo de teletransporte, veja Gerenciador de Estado do Jogo.
Versão de depuração
Para nos ajudar a debugar missões periodicamente, criamos uma versão da experiência em que não teríamos que esperar no lobby ou para cutscenes.Esta versão tinha atalhos e botões baseados em teclado que nos permitiriam completar automaticamente missões para que pudéssemos testar rapidamente aspectos da experiência.Periodicamente copiaríamos e publicaríamos essa versão na versão que planejávamos liberar que tinha o fluxo de jogo adequado.Para distinguir essas duas versões, fizemos um DemoGlobalSettings script para verificar o placeID, ver se está rodando no Studio e habilitar/desabilitar vários truques e botões de jogabilidade.Para mais informações, veja Lógica de Missões e Scripts de Configuração.
Teletransporte
Existem três tipos de teletransporte que ocorrem dentro da experiência:
- Teletransportando jogadores do simples lobby para a área principal de jogabilidade em um servidor reservado.
- Teletransportar jogadores do estado normal de uma sala para o estado corrompido, e depois de volta novamente enquanto mostra uma cutscene.
- Teletransportar jogadores dentro de alguns quebra-cabeças, ou quando eles respawn após cair da área de jogabilidade.
Servidores reservados
Decidimos agrupar os jogadores em grupos de cinco em um lobby simples antes de teletransportá-los para um servidor reservado para a área principal de jogabilidade da casa.O lobby forneceu tempo para que jogadores adicionais se juntassem e jogassem juntos, e servidores reservados impediram que jogadores adicionais perdessem aspectos do jogo e da narrativa da experiência de se juntar tarde.Essa teleportação só acontece uma vez.
Cenas de corte
Queríamos ser capazes de transportar os jogadores durante todo o jogo sempre que realizassem certas tarefas, como tocar um selo ou completar uma missão.Para implementar isso, desenvolvemos uma versão simples de uma ferramenta baseada em scripts chamada Gerenciador de Eventos que controlava várias propriedades e atributos, executava scripts e áudio e realizava agitações de câmera por um período de tempo.Isso nos permitiu mover tanto os jogadores quanto transmitir para dentro e para fora de diferentes salas enquanto ocultávamos esse processo do jogador usando efeitos especiais.Para mais informações, veja Gerenciador de Eventos.
Respawnar jogadores
O terceiro tipo de teletransporte que queríamos implementar foi um teletransporte curto com apenas uma mudança de coordenada de um jogador CFrame dentro de alguns quebra-cabeças e quando os jogadores caem e respawnam.Ao contrário dos dois tipos anteriores de teletransporte, este tipo não solicita explicitamente streaming assíncrono.
scriptingde jogos
Programação nos permitiu executar em elementos específicos de jogabilidade, como desaparecer elementos de UI, criar volumes de gatilho para eventos-chave e destacar objetos quando estavam em foco com o cursor do jogador.Muitos desses sistemas dependiam de rotular objetos para executar comportamento personalizado, então usando uma variedade de scripts de cliente ou servidor para conter fluxos de trabalho específicos dependendo de qual ação precisava ocorrer em pontos definidos na experiência.Para mais informações sobre como implementamos esses sistemas, veja Sistemas de jogabilidade fundamentais e Sistemas de suporte.
Comportamento personalizado com tags
Queríamos uma maneira de adicionar comportamento personalizado para objetos, como trancar portas para que os jogadores tivessem que permanecer na sala até concluírem a missão ativa.Para implementar isso, decidimos usar tags para objetos específicos, então usamos CollectionService para encontrar esses objetos e conectamos qualquer comportamento correspondente Scripts para adicionar comportamento personalizado.Tínhamos um Script para cada categoria de tag que agia como gerente para lidar com todos os objetos rotulados sob essa categoria para que pudéssemos manter o Script em um único local, ao invés de serem copiados muitas vezes em DataModel.Para mais informações, veja Gerenciador de Portas , Animador Master , Gerenciador de Gavetas , Volume de Morte , Reaparecimento de Missão do Jogador e Gerente de Piano.
O "gerente" Script usa uma função Init para encontrar quaisquer objetos marcados quando a experiência começa e conectar um comportamento personalizado a eles.Por exemplo, o Gerenciador de Portas encontra qualquer objeto rotulado com Porta , então ele atribui o comportamento correto aos objetos da porta (movimenta a porta quando clicada, toca um efeito de som de balanço de porta, etc.).No entanto, quaisquer objetos que sejam adicionados ou removidos durante o tempo de execução, como qualquer objeto que seja adicionado a uma sala corrompida após um jogador interagir com um selo corrompido, perderá essa chamada inicial e nunca obterá o comportamento esperado.Para resolver isso, usamos CollectionService.GetInstanceAddedSignal e CollectionService.GetInstanceRemovedSignal para conceder o mesmo comportamento a novos objetos que são marcados e desmarcados, respectivamente.
Scripts de cliente e servidor
Queríamos reduzir a largura de banda para diferentes aspectos do jogo que seriam caros em performance.Decidimos que quando a funcionalidade do objeto pode afetar a simulação para outros jogadores, como mover o objeto através da colisão, nós executaríamos isso no servidor , mas se algo for mais relacionado ao design do ambiente, como luzes, animações ambientais que não afetam o jogabilidade, efeitos especiais e áudio, nós os executaríamos em clientes.Isso reduziria a largura de banda e manteria as mudanças de movimento e ambiente mais suaves nos dispositivos do usuário.