Projetar uma estratégia para desenvolver um jogo com Unity e MongoDB
Avalie esse Tutorial
Quando se trata de desenvolvimento de jogos, você provavelmente deve ter algumas ideias anotadas antes de começar a escrever código ou gerar recursos. O mesmo provavelmente poderia ser dito sobre qualquer tipo de desenvolvimento, a menos, é claro, que você esteja apenas brincando e aprendendo algo novo.
Então, o que deve ser planejado antes de desenvolver seu próximo jogo?
Dependendo do tipo de jogo, você provavelmente vai querer um frontend executável, também conhecido como o próprio jogo, algum tipo de backend se quiser um componente online como multijogador, tabelas de classificação ou similar, e possivelmente um web- painel baseado para obter informações rapidamente se você estiver no lado operacional do jogo e não for um jogador.
Adrienne Tacke, Karen Huaulmee eu (Nic Raboy) estamos no processo de construção de um jogo. Achamos que Fall Guys: Ultimate Knockout é um jogo muito bem feito e achamos que seria interessante criar um jogo de tributo que fosse um pouco mais retrô, mas com muitos dos mesmos recursos. O jogo será intitulado Plummeting People. Este artigo explora o processo de planejamento, design e desenvolvimento!
O Jamboard acima foi criado durante um fluxo de planejamento no Twitch do qual a comunidade participou. O conteúdo a seguir é um resumo de cada um dos tópicos discutidos e informações úteis para planejar o desenvolvimento de um jogo.
O jogo é o que a maioria verá e com o que mais se importará. Ele deve atuar como o driver para todos os outros componentes que operam nos bastidores.
Em vez de tentar invadir o espaço de um jogo já excelente que gostamos (Fall Guys), queríamos dar nossa própria opinião, tornando-o 2D em vez de 3D. Com Fall Guys sendo a ideia básica por trás do que queríamos realizar, precisávamos detalhar ainda mais o que o jogo precisaria. Tínhamos algumas conclus}es.
Níveis / Arenas
Precisamos de algumas arenas para poder chamá-lo de um jogo que valha a pena jogar, mas não queríamos que fosse tão pensado quanto o jogo que inspirou nossa ideia. No final das contas, queríamos nos concentrar mais na jornada de desenvolvimento do que em fazer um sucesso de bilheteria.
Pipes do fall, embora considerados uma reale ação, ainda são um jogo de corrida em sua essência. Então, que tipo de áreas fariam sentido em um ambiente 2D?
Nosso plano é começar com os conceitos de nível mais simples para nos salvar da complicada física e engenharia do jogo. Existem dois níveis em particular que têm colisões básicas como ênfase em Fall Guys. Esses níveis incluem "Door Dash" e "Tip Toe", que se concentram em portas falsas e ladrilhos que desaparecem. Ambos não têm física rotacional e nada além de colisões básicas e randomização.
Embora pudéssemos nos limitar a dois níveis básicos como nossa prova de conceito, temos um objetivo para uma arena de equipe, como marcar gols no futebol.
Ativos
Os conceitos de arena são importantes, mas para executar, serão necessários recursos do jogo.
Estamos considerando os seguintes recursos de jogo como parte necessária do nosso jogo:
- Planos de fundo da arena
- Imagens de obstáculos
- Imagens de jogadores
- Efeitos sonoros
- músicas do jogo
Para manter o espírito do jogo Battle Royale moderno, achamos que as personalizações dos jogadores eram um componente necessário. Isso significa que precisaremos de sprites personalizados com roupas diferentes que possam ser desbloqueadas durante toda a experiência de jogo.
Física e controles de jogo
O design de níveis e os recursos do jogo são apenas parte de um jogo. Eles são totalmente insignificantes, a menos que sejam combinados com o componente de interação do usuário. O usuário precisa ser capaz de controlar o jogador, interagir com outros jogadores e interagir com obstáculos na arena. Para isso, precisaremos criar nossa própria lógica de jogo usando os ativos que criamos.
Prevemos que a maior parte do nosso trabalho em torno deste jogo de imposto estará no backend. Mover-se na tela e interagir com obstáculos não é uma tarefa muito difícil, como demonstrado em um tutorial anterior que escrevi.
Em vez disso, a experiência online exigirá a maior parte da nossa atenção. Nossa primeira rodada de planejamento chegou às seguintes Conclusões:
Interação em tempo real com soquetes
Quando o jogador faz qualquer coisa no jogo, ela precisa ser processada pelo servidor e transmitida para outros jogadores no jogo. Isso precisa ser em tempo real e os soquetes são provavelmente a única solução lógica para isso. Se o servidor estiver gerenciando os soquetes, os dados poderão ser armazenados no banco de dados sobre os jogadores, e o servidor também poderá validar as interações para evitar trapaças.
Combinando jogadores com jogos
Quando o jogo estiver ao vivo, haverá jogos simultâneos em operação, cada um com seu próprio conjunto de jogadores. Precisaremos criar uma solução de matchmaking para que os jogadores só possam ser adicionados a um jogo que aceite jogadores e esses jogadores atendam a determinados critérios.
O processo de matchmaking pode servir como uma oportunidade perfeita para usar pipelines de agregação no MongoDB. Por exemplo, digamos que você tenha 5 vitórias e 1000 derrotas. Você não é um jogador muito bom, então provavelmente não deveria terminar em uma partida com um jogador que tenha 1000 vitórias e 5 derrotas. Essas são coisas que podemos planejar a partir do nível do banco de dados.
Lojas de perfil de usuário
As lojas de perfis de usuário são um dos componentes mais comuns de qualquer jogo online. Eles armazenam informações sobre o jogador, como nome e informações de cobrança do jogador, bem como estatísticas de jogos. Imagine que tudo o que você faz em um jogo acabará em um registro para o seu jogador.
Então, o que podemos armazenar em uma loja de perfis de usuário? ```P32 E sobre o seguinte?:```
- Trajes de jogadores desbloqueados
- Gatilhos, perdas, pontos de experiência
- Nome de usuário
- Tempo de jogo
A lista poderia Go indefinidamente.
A loja de perfis de usuário terá que ser cuidadosamente planejada porque é a linha de base para qualquer coisa relacionada a dados no jogo. Isso afetará o processo de matchmaking, tabelas de classificação, dados históricos e muito mais.
Para ter uma ideia do que estamos colocando na loja de perfis de usuário, confira uma transmissão gravada no Twitch que fizemos sobre o assunto.
Tabelas de classificação
Por se tratar de um jogo competitivo, faz sentido ter uma tabela de classificação. No entanto, esta tabela de classificação pode ser um pouco mais complicada do que apenas o seu nome e os seus pontos de experiência. E se quiséssemos monitorar quem tem mais vitórias, derrotas, passos, tempo de jogo, etc.? E se quiséssemos detalhá-lo ainda mais para ver quem era o líder na América do Norte, na Europa ou na Ásia? Poderíamos usar consultas geoespaciais do MongoDB sobre a localização dos jogadores.
Enquanto estivermos coletando dados do jogo para cada jogador, podemos ter algumas ideias interessantes de tabelas de classificação.
Estatísticas do jogador
Sabemos que vamos querer monitorar as vitórias e derrotas de cada jogador, mas talvez queiramos rastrear mais. Por exemplo, talvez queiramos rastrear quantos passos um jogador deu em uma determinada arena ou quantas vezes ele caiu. Essas informações poderiam ser passadas posteriormente por um pipeline de agregação no MongoDB para determinar uma classificação ou um nível que poderia ser útil para a criação de partidas e tabelas de classificação.
Chat do jogador
Seria um jogo multijogador online sem algum tipo de bate-papo? Estamos achando que, enquanto um jogador estiver fazendo a correspondência, eles poderiam conversar entre si até o jogo começar.Os dados desses chats seriam armazenados no MongoDB e poderíamos implementar a funcionalidadeAtlas Search para procurar sinais de excesso, linguagem obsceno, etc., que possam aparecer ao longo do chat.
Como administradores do jogo, vamos querer coletar informações para melhorar o jogo. É provável que não queiramos analisar essas informações de dentro do próprio jogo ou com consultas brutas no banco de dados.
Para isso, provavelmente vamos querer criar dashboards, relatórios e outras ferramentas úteis para trabalhar com nossos dados regularmente. Aqui estão algumas coisas que estamos considerando fazer:
MongoDB Atlas Charts
Se tudo estiver funcionando bem com o jogo e a collection de dados do backend, temos os dados, então só precisamos visualizá-los. MongoDB Atlas Charts podem pegar esses dados e nos ajudar a dar sentido a eles. Talvez queiramos mostrar um mapa de calor em diferentes horas do dia para diferentes regiões do mundo, ou talvez queiramos mostrar um gráfico de barras em torno dos pontos de experiência do jogador. Qualquer que seja o motivo, MongoDB Atlas Charts fariam sentido em uma configuração de painel de administração.
Descarregamento de dados históricos
Dependendo da popularidade do jogo, os dados entrarão no MongoDB como uma mangueira de incêndio. Para ajudar na escalabilidade e nos preços, fará sentido transferir dados históricos do nosso cluster para um armazenamento de objetos na nuvem, a fim de economizar custos e melhorar o desempenho do cluster removendo dados históricos.
No MongoDB Atlas, a melhor maneira de fazer isso é habilitar o Online Archive, que permite definir regras para arquivar automaticamente seus dados em um armazenamento na nuvem totalmente gerenciado, mantendo o acesso para consultar esses dados.
Você também pode aproveitar oMongoDB Atlas Data Lake para conectar seu próprio armazenamento em cloud - Amazon S3 dos buckets do Microsoft Blob Storage e executar queries federadas para acessar todo o seu conjunto de dados usando o MQL e o Aggregation Framework.
Como mencionado anteriormente, este artigo é um ponto de partida para uma série de artigos que escrevemos AdrieneTacke, Keren Huaulmee eu (Nic Raboy), sobre um jogo de imposto sobre os Garotas que estamos chamando de Plummeting Persons. Estamos tentando competir com os fall times? absolutamente não! Estamos tentando mostrar o processo de ideias em torno do design e desenvolvimento de um jogo que aproveite o MongoDB e, comoFallGuys é um jogo demais, queremos fazer uma Homenagem a ele.
O próximo artigo da série será sobre o projeto e o desenvolvimento da loja de perfis de usuário para o jogo. Ele abordará o modelo de dados, queries e algum código de servidor de backend para gerenciar as futuras interações entre o jogo e o servidor.
Quer discutir este artigo de planejamento ou o stream do Twitch que foi com ele? Junte-se a nós no tópico da comunidade que criamos.