Nesta parte da série, configuraremos um sistema de armazenamento de dados do jogo para permitir que você armazene o estado do jogo do jogador ao longo de sua experiência com o jogo. Para isso, criaremos alguns pontos de extremidade /state e /states que representarão blocos individuais de dados de estado. Permitiremos vários blocos de estado nomeados para permitir que o jogo divida os dados de estado em blocos atualizáveis separadamente para evitar a necessidade de gravar muitos blocos de estado quando apenas uma parte tiver sido alterada.

Se você ainda não leu Parte 1 e Parte 2 desta série, sugiro que você o faça, pois esta parte e as futuras se baseiam nelas!

Ajuda rápida - Renovação da sessão

Algo que deveria estar na minha postagem anterior do blog, mas que é importante, é a renovação da sessão dos usuários sempre que eles a acessam. Sem isso, é garantido que a sessão expire após 60 minutos, independentemente de o jogador ainda estar jogando. Obviamente, essa não é a nossa intenção, portanto, vamos corrigir isso!

Primeiro, precisamos adicionar uma nova função ao nosso SessionModel, portanto, abra o arquivo sessionmodel.js e vamos adicionar o seguinte bloco. É uma função bastante simples; ela recebe um ID de sessão e executa uma operação de toque para redefinir o tempo de expiração para 3600 novamente (a partir do momento da execução do toque, não quando a chave foi originalmente inserida).

Agora que temos nossa função de modelo para atualizar a sessão, vamos encontrar um bom lugar para chamá-la. Nosso método authUser parece ser uma boa opção, pois é executado em qualquer endpoint que exija que o usuário seja autenticado. Vamos fazer isso agora. Aqui está nossa nova função authUser com nossa chamada de toque adicionada.

Como parte dessa correção de expiração de sessão, talvez seja necessário extrair a versão do couchnode diretamente do GitHub devido a um erro em nossa implementação de toque que foi corrigido antes da publicação deste blog, mas após o lançamento do ciclo mais recente.

Estados do jogo - O modelo

Agora que já resolvemos o pequeno problema da parte anterior, vamos implementar o salvamento do estado do jogo! Como eu disse acima, vamos permitir que os jogos armazenem dados em vários blocos de estado para reduzir o tráfego de rede. Do ponto de vista do armazenamento, armazenaremos todos esses blocos de estado em um único documento do Couchbase, e esse documento será criado de forma preguiçosa na primeira solicitação para salvar informações para o usuário. Até o momento em que houver algo salvo, emularemos uma lista de estados vazia para o usuário, como você verá em breve.

Para começar, vamos configurar nosso layout de arquivo de modelo padrão em model/statemodel.js. Importamos nossos módulos necessários e configuramos um modelo sem métodos chamado StateModel.

Agora que temos os fundamentos do nosso modelo, vamos começar a implementar alguns dos métodos que serão necessários. Vamos começar com um modelo que nos permita salvar um novo bloco de estado. Essa função tratará tanto da criação quanto da atualização de um bloco de estado. Isso torna a lógica do lado do cliente muito mais simples, pois não precisamos nos preocupar se o bloco de estado já existe em um nível de API. Usaremos uma forma de bloqueio otimista em que um número de versão será armazenado com cada bloco de estado. Sempre que um bloco de estado for atualizado, você precisará passar o número da versão existente no servidor antes que o servidor aceite os novos dados. Isso serve para evitar que várias cópias do jogo em execução simultânea atropelem os dados umas das outras. Esse também é o primeiro lugar em que usaremos a função bloqueio otimista para garantir que não estejamos fazendo alterações simultâneas em nosso objeto de estados a partir de duas chamadas de endpoint.

Vamos começar com nosso protótipo de função de salvamento.

Nossa primeira etapa real é criar um nome para o nosso documento de armazenamento de estado e, em seguida, solicitar esse documento ao Couchbase para verificar se ele já existe.

Agora, verificamos se houve algum erro ao solicitar um documento de estado existente. Se encontrarmos um erro, verificaremos se não foi um erro "não encontrado". Se o documento não foi encontrado, ignoramos esse erro e continuamos, pois isso se deve à natureza de criação preguiçosa do nosso documento de estados.

Em seguida, movemos nosso documento de estado existente (ou um novo documento, caso não tenha sido encontrado) para uma variável separada para facilitar o acesso e para que possamos lidar com os documentos existentes e com o novo documento da mesma maneira.

Agora, faremos a mesma coisa com nosso bloco de estado. Você notará que garantimos que nossa variável stateBlock faça referência à matriz de estados dos documentos de estado reais. Outro ponto que vale a pena mencionar é que nossa versão padrão do bloco de estado é 0. Isso significa que, ao executar um salvamento pela primeira vez, espera-se que o cliente especifique a versão 0 para esclarecer que está ciente de que esse será um novo bloco de estado.

Em seguida, precisamos verificar se a versão especificada pelo chamador ainda corresponde à que está armazenada em nosso cluster. Se esse não for o caso, outro usuário deve ter feito alterações desde a última vez em que o cliente recuperou os dados salvos. Espera-se que, se houver uma incompatibilidade de versão, o cliente recupere os novos dados, faça as mesclagens necessárias e tente atualizar novamente.

Como mencionei no início desta seção, também usaremos o bloqueio otimista incorporado ao Couchbase para garantir que nossas gravações de documentos de estado sejam executadas em ordem. Devido ao fato de que realizamos nosso get anteriormente, depois fazemos nossa comparação de versões e, finalmente, fazemos a gravação novamente aqui, há uma chance de que outra chamada ao nosso endpoint de salvamento de estado tenha alterado o objeto desde o nosso get original, mas antes do nosso set. Para saber mais sobre os valores cas, consulte a seção Manual do Couchbase sobre valores cas.

Por último, para esse método específico, pré-formamos nosso conjunto, todos os erros que ocorrem são propagados para o chamador (isso provavelmente deve ser envolvido no nível do modelo, conforme mencionado anteriormente) e o retorno de chamada é invocado com o bloco de estado que armazenamos.

Por fim, aqui está todo o nosso método de salvamento. Ele é bastante longo, mas espero que seja relativamente compreensível!

O próximo método que incluiremos é o findByUserId. Esse método nos permitirá criar um ponto de extremidade que retorne todos os blocos de estado para qualquer usuário específico. Trata-se principalmente de uma otimização no lado do cliente para permitir a busca de todos os blocos de estado de uma só vez, em vez de executar várias solicitações. A função é extremamente simples. Usando o mesmo nome de documento da nossa função de salvamento, tentamos carregar o documento de estado do nosso cluster; se ele existir, retornamos a lista de estados dentro desse bloco; se o documento estiver ausente, retornamos uma lista vazia para o usuário. Quaisquer outros erros são encaminhados para o chamador.

A última função de modelo que precisamos criar é o nosso método para acessar um único bloco de estado para um usuário. Essa função é quase idêntica à nossa função findByUserId, exceto pelo fato de que, além disso, detalhamos um bloco de estado específico por nome em vez de retornar a lista inteira.

Estados do jogo - Tratamento de solicitações

Agora que temos nosso modelo pronto para ser usado, vamos começar a criar os manipuladores de solicitação para nossos três pontos de extremidade! Vamos criar um ponto de extremidade para solicitar todos os estados de um usuário, um ponto de extremidade para solicitar um bloco de estado específico e, finalmente, um ponto de extremidade para atualizar um bloco de estado específico.

Antes de criarmos nossos manipuladores de solicitações, precisamos primeiro adicionar uma referência ao arquivo statemodel.js que criamos anteriormente!

Agora, vamos começar com nosso endpoint de salvamento. Como nas partes anteriores, nossos manipuladores de solicitação são extremamente simples e simplesmente encaminham as partes pertinentes da nossa solicitação para o modelo. Esperamos o nome do bloco de estado como parte do URI, o número da versão como parte da nossa consulta e, finalmente, os dados reais do bloco de estado no corpo da solicitação.

Em seguida, precisamos da capacidade de recuperar um bloco de estado que armazenamos anteriormente.

Por último, mas não menos importante, o ponto de extremidade para solicitar todos os blocos de estado armazenados para um determinado usuário. Como eu disse antes, isso serve principalmente para otimizar a sequência de carregamento do jogo, em que geralmente precisamos recuperar todos os blocos de estado.

Terminou!

Agora que criamos nosso modelo e implementamos os manipuladores de solicitação necessários, você poderá iniciar o aplicativo como nas partes anteriores e executar algumas solicitações no servidor do jogo para ver o resultado do nosso trabalho árduo!

Sucesso!

A fonte completa desse aplicativo está disponível aqui: https://github.com/brett19/node-gameapi

Aproveite! Brett