Criando um armazenamento de perfil de usuário para um jogo com Node.js e MongoDB
Karen Huaulme, Nic Raboy10 min read • Published Jan 12, 2022 • Updated Apr 02, 2024
Avalie esse Tutorial
Quando se trata de desenvolvimento de jogos, ou pelo menos desenvolvimento de jogos que tenham um componente on-line, você vai tropeçar no território das lojas de perfis de usuários. Estes são essencialmente registros de cada um de seus jogadores e contêm tudo, desde informações da conta até o que eles realizaram no jogo.
Veja o jogo Plummeting People que alguns de nós do MongoDB (KarenHuaulme, Adrienne Tacke e Nic Raboy) estamos criando, transmitindo e escrevendo sobre ele. A ideia por trás desse jogo, conforme descrito em um artigo anterior, é criar um jogo tributo aoFall Guys: Ultimate Knockout com nossa própria versão.
Como este jogo será um jogo multiplayer online, cada jogador precisa reter informações de jogo, como quantas vezes ganhou, quais trajes desbloqueou, etc. Essas informações existiriam dentro de um documento de perfil do usuário.
Neste tutorial, vamos ver como projetar um armazenamento de perfil de usuário e, em seguida, construir um componente de backend usando o Node.js e o MongoDB Realm para interagir com ele.
Para que você se familiarize, Fall Guys: Ultimate Knockout é um jogo no estilo battle royale em que você compete pelo primeiro lugar em várias pistas de obstáculos. Ao jogar, você ganha pontos de carma, coroas e trajes para tornar o jogo mais interessante.
Como estamos trabalhando em um jogo de tributo e não em um clone direto, determinamos que nosso jogo Plummeting People deve ter os seguintes dados armazenados para cada jogador:
- Pontos de experiência (XP)
- Cataratas
- Passos dados
- Colisões com jogadores ou objetos
- Perdas
- Gatas
- Abacaxis (moeda)
- Realizações
- Inventário (Roupas)
- Plummie Tag (nome de usuário)
Claro, pode haver muito mais informações ou muito menos informações armazenadas por jogador em qualquer jogo. Com toda honestidade, as coisas que achamos que devemos armazenar podem evoluir à medida que avançamos no desenvolvimento do jogo. No entanto, este é um bom ponto de partida.
Agora que temos uma ideia geral do que queremos armazenar, faz sentido converter esses itens em um modelo de dados apropriado para um documento no MongoDB.
Veja o exemplo a seguir:
Observe que temos as informações identificadas anteriormente. No entanto, a estrutura é um pouco diferente. Além disso, você notará campos extras, como
created_at e outros dados relacionados a registros de data e hora, que podem ser úteis nos segundo plano.Para conquistas, uma matriz de objetos pode ser uma boa ideia porque as conquistas podem mudar com o tempo, e cada jogador provavelmente receberá mais de um durante a vida útil de sua experiência de jogo. Da mesma forma, o campo
inventoryé um objeto com matrizes de objetos porque, embora o plano atual seja ter um inventário de roupas de jogadores, isso pode evoluir posteriormente para itens consumíveis para serem usados no jogo, ou qualquer outra coisa que possa se expandir além das roupas.Uma coisa a observar sobre o document model de perfil de usuário acima é que estamos tentando armazenar tudo sobre o player em um único documento. Não estamos tentando manter relacionamentos com outros documentos, a menos que seja absolutamente necessário. O documento para qualquer jogador é como um registro de sua experiência de vida com o jogo. Ele pode desenvolver muito facilmente ao longo do tempo devido à natureza flexível de ter um document model JSON em um banco de dados NoSQL como o MongoDB.
Para obter mais informações sobre o processo de design de nossos documentos de armazenamento de perfil de usuário, confira a gravação on-demand do Twitch que criamos.
Com uma ideia geral de como escolhemos modelar nosso documento de player, poderíamos começar a desenvolver o back-end responsável por fazer o espectro de operações de criação, leitura, atualização e exclusão (CRUD) em nosso banco de dados.
Como o Express.js é uma maneira comum, se não a mais comum, de trabalhar com o desenvolvimento da API do Node.js, fazia sentido começar por lá. O que vem a seguir reproduzirá o que fizemos durante a transmissão do Twitch.
Na linha de comando, execute os seguintes comandos em um novo diretório:
Os comandos acima inicializarão um novo arquivopackage.json dentro do diretório de trabalho atual e, em seguida, instalarão oExpress.js, o driver do MongoDB Node.jse o middlewarebody analyzer para aceitar cargas úteis JSON.
No mesmo diretório do arquivopackage.json, crie um arquivomain.js com o seguinte código Node.js:
Tem muita coisa acontecer no código acima. Vamos detalhá-lo!
Você notará primeiro as seguintes linhas:
Anteriormente, fizemos o download das dependências do projeto, mas agora estamos importando-as para uso no projeto. Depois de importado, estamos inicializando o Express e pedindo que ele use o analisador de corpo para cargas codificadas em JSON e URL que chegam com POST, PUT e solicitações similares. Essas solicitações são comuns quando se trata de criar ou modificar dados.
Em seguida, você notará as seguintes linhas:
O
client neste exemplo pressupõe que sua connection string do MongoDB Atlas existe em suas variáveis de ambiente. Para ser claro, a connection string teria a seguinte aparência:Sim, você pode codificar esse valor, mas como a connection string conterá seu nome de usuário e senha, faz sentido usar uma variável de ambiente ou arquivo de configuração por motivos de segurança.
A variável
collection está sendo definida porque terá nosso identificador de coleção para uso em cada uma de nossas funções de endpoint.Por falar em funções de endpoint, vamos ignorá-las por um momento. Em vez disso, vejamos como servir a nossa API:
No código acima, estamos servindo nossa API na porta 3000. Quando o servidor inicia, estabelecemos uma conexão com nosso cluster MongoDB Atlas. Uma vez conectados, usamos o banco de dados
plummeting-people e a coleçãoplummies. Nessa circunstância, estamos chamando cada jogador de plummie, daí o nome da nossa coleção de armazenamento de perfil de usuário. Nem o banco de dados nem a coleção precisam existir antes de iniciar o aplicativo.É hora de focar nessas funções de endpoint.
Para criar um player — ou plummie, neste caso — precisamos dar uma olhada no endpoint POST:
O endpoint acima espera um payload JSON. Idealmente, ele deve corresponder ao modelo de dados que definimos anteriormente no tutorial, mas não estamos fazendo nenhuma validação de dados, portanto, qualquer coisa neste momento funcionaria. Com o payload JSON, é feitauma operação
insertOnee esse payload é transformado em um perfil de usuário. O resultado da criação é enviado de volta ao usuário.Se você quiser lidar com a validação de dados, confira a validação de esquema no nível do banco de dados ou usando uma biblioteca de validação voltada para o cliente, como Joi.
Com o documento de perfil do usuário criado, talvez seja necessário procurá-lo em algum momento. Para fazer isso, dê uma olhada no endpoint GET:
No exemplo acima, todos os documentos na collection são retornados porque não há nenhum filtro especificado. O endpoint acima é útil se você quiser encontrar todos os perfis de usuário, talvez para fins de relatório. Se você quiser encontrar um documento específico, você pode fazer algo assim:
O endpoint acima usa um
plummie_tag, que estamos esperando para ser um valor único. Desde que o valor exista no campo plummie_tag de um documento, o perfil será retornado.Embora ainda não haja um jogo para jogar, sabemos que precisaremos atualizar esses perfis de jogador. Talvez o
xptenha aumentado ou novos achievements tenham sido ganhos. Qualquer que seja o motivo, uma solicitação PUT é necessária e pode ter a seguinte aparência:Na solicitação acima, estamos esperando que um
plummie_tag seja passado para representar o documento que queremos atualizar. Também estamos esperando que uma carga seja enviada com os dados que queremos atualizar. Como com insertOne,updateOne não está passando por validação anterior. Usando plummie_tag, podemos filtrar as alterações para um documento e, em seguida, usar o operador$set com uma seleção de alterações a serem feitas.O endpoint acima atualizará qualquer campo que tenha sido passado na carga. Se o campo não existir, ele será criado.
Pode-se argumentar que os perfis de usuário só podem ser criados ou alterados, mas nunca removidos. Cabe a você decidir se o perfil deve ou não ter um campo
activeou apenas removê-lo quando solicitado. No nosso jogo, os documentos nunca serão excluídos, mas, se você quiser, poderá fazer o seguinte:O código acima pegará um
plummie_tag do jogo e excluirá todos os documentos que correspondam a ele no filtro.Deve-se reiterar que espera-se que esses endpoints sejam chamados de dentro do jogo. Então, quando você estiver joga e criar seu player, ele deve ser armazenado por meio da API.
Embora Node.js com Express.js possa ser popular, não é a única maneira de criar uma API de armazenamento de perfil de usuário. Na verdade, pode até não ser a maneira mais fácil de fazer o trabalho.
Durante o stream do Twitch, demonstramos como transferir o gerenciamento do Express e do Node.js para o Realm.
Como parte da plataforma de dados MongoDB, o Realm oferece muitas coisas que a Plummeting People pode aproveitar ao criar este jogo, incluindo gatilhos, funções, autenticação, sincronização de dados e hospedagem estática. Mostramos rapidamente como recriar essas API por meio do HTTP Service do Realm diretamente da interface do usuário do Atlas.
Para criar nossos endpoints GET, POST e DELETE, primeiro criamos um aplicativo Realm. Retorne à interface do usuário do Atlas e clique emRealm na parte superior. Em seguida, clique no botão verde Iniciar um novo aplicativo Realm.
Nomeamos nosso aplicativo Realm como PlummetingPeople e o vinculamos ao cluster do Atlas que contém os dados do jogador. Todas as outras configurações padrão estão corretas:
Parabéns! Realm Application Criação de Realm Desbloqueado! 👏
Agora clique no menu 3Serviços de terceiros à esquerda e, em seguida, em Adicionar um serviço. Selecione o HTTP Service.Nomeamos o nossoRealmOfPlummies:
Clique no botão verde Adicionar um serviço e você será direcionado para Adicionar webhookde entrada.
Vamos recriar nosso endpoint GET primeiro. Na guia Configurações , nomeie seu primeiro webhook de getPlummies. Ative Responder com resultado e defina o Método HTTP como GET. Para simplificar as coisas, vamos apenas executar o webhook como o sistema e pular a validação sem autorização adicional. Certifique-se de clicar no botão Revisar e distribuir na parte superior do caminho.
Nesse editor de funções de serviço, substitua o código de exemplo pelo seguinte:
No código acima, observe que o MongoDB Realm interage com nossa coleção
plummiespor meio da variável global context . Na função de serviço, usamos essa variável de contexto para acessar todos os nossos plummies. Também podemos adicionar um filtro para localizar um documento ou documentos específicos, assim como fizemos no endpoint Express + Node.js acima.Alterne para a guia Configurações do
getPlummies e você notará que uma URL do webhook foi gerada.
Podemos testar esse endpoint executando-o em nosso navegador. No entanto, se você tiver ferramentas como o Postman instaladas, sinta-se à vontade para tentar fazer isso também. Clique no botãoCOPY e cole o URL em seu navegador.
Se você receber uma saída mostrando seus pipms, criou com sucesso um endpoint de API no Realm! Muito legal. 💪😎
Agora, vamos passar por esse processo novamente para criar um endpoint para adicionar novas plummies ao nosso jogo. No mesmo serviçoRealmOfPlummies, adicione outro webhook de entrada. Nomeie-o
addPlummie e defina-o como um POST. Alterne para o editor de funções e substitua o código de exemplo pelo seguinte:Se você Go às Atlas e obtiver o URL, poderá usá-lo para fazer o POST de novos plummies em nosso banco de dados depessoas que estão despencandono Atlas.
E, finalmente, os dois últimos endpoints para
DELETE e UPDATE nossos jogadores.Dê um nome a um novo webhook de entrada
removePlummie e defina como POST. O código a seguir removerá o plummie do nosso armazenamento de perfil de usuário:O novo webhook de entrada final
updatePlummie e definido como PUT:Com isso, temos outra opção para lidar com os quatro endpoints, permitindo operações CRUD completas para nossos dados
plummie, sem precisar ativar e gerenciar um backend do Node.js e do Express.Você acabou de ver alguns exemplos de como projetar e criar uma loja de perfil de usuário para seu próximo jogo. O armazenamento de perfil de usuário usado neste tutorial é uma parte ativa de um jogo que alguns de nós do MongoDB (Karen Huaulme, Adri essenTackee Nic Raball) estamos construindo. Depende de você se deseja ou não desenvolver seu próprio backend usando o driver MongoDB Node.js ou aproveitar o MongoDB Realm com funções de webhook.
Esse tutorial específico faz parte de uma série sobre o desenvolvimento de um jogo tributo aoFall Guys: Ultimate Knockout usando o Unity e o MongoDB.
Avalie esse Tutorial