Como devo arquitetar meu servidor de DB e API para um jogo de tabuleiro para iPhone de Multiplayer baseado em turnos? (Pensando em Nodejs, Mongo, Couch, etc)

Question

Estou trabalhando em um jogo de tabuleiro baseado em turnos para iPhone e, eventualmente, Android. Estou usando o Appcelerator Titanium para desenvolvê -lo. Meu design multiplayer é semelhante às palavras com os amigos. Os usuários se revezam quando estão prontos e, em seguida, o quadro de jogos do oponente é atualizado de acordo.

Uma das minhas necessidades é ter uma API de mensagens que permite que os dois dispositivos dos 2 jogadores se atualizem sobre o status do quadro de jogos após uma mudança. Pensando em fazer isso com o JSON e manter um objeto JSON no dispositivo que contém a localização de todas as peças do quadro de jogos a qualquer momento. Este é o objeto que precisará atualizar no dispositivo local e enviar uma alteração para o dispositivo do oponente após a ação.

Eu fiz APIs no passado por plataformas móveis e, para fazer, usei o PHP com o MySQL e enviei o JSON entre o servidor API e o dispositivo móvel. Funciona apenas para usuários simultâneos baixos e aplicativos geralmente não massivos. Esperamos que este seja enorme;)

Então agora, em vez de um servidor HTTPD geral e similares, estou começando a pensar em soquetes persistentes e, se forem necessários ou não para o meu novo jogo. Também estou pensando que pode ser inteligente renunciar à pilha de lâmpadas grandes e à escalabilidade e talvez à facilidade de desenvolvimento, se inclinar mais para um fluxo de dados de algo como Mongo/Couch -> Node.js -> iPhone. Serei honesto, seria minha primeira incursão em um db não sql e node.js também.

Interessado em ouvir as tomadas e as experiências dos outros, mais opções/pensamentos e se estou pensando nisso da maneira certa ou apenas criando dores de cabeça para mim.

Answer 1

Primeiro de tudo, o NodeJS é incrível para escrever proxies TCP reversos para os bancos de dados NoSQL. Você pode permitir que todos os comandos padrão passassem, mas alterarem/estender suas APIs com sua própria magia, por exemplo, fazendo o MongoDB falar http ou couchdb falar um protocolo binário sobre soquetes.

Quando se trata de escolher uma solução NoSQL para armazenar peças de jogos de tabuleiro e monitorar os movimentos dos jogadores, acho que Redis e CouchDB são os melhores candidatos.

1. Couchdb. É rápido, confiável e pode lidar com muitas conexões HTTP simultâneas. Provavelmente é a melhor opção, porque, diferentemente do Redis, ele pode transmitir uma mensagem quando um documento mudar. o API de mudanças contínuas torna super simples que você tenha o monitor de aplicativos de cada jogador para alterações em sua placa. O pedido pode parecer:
   
   

   curl "$HOST/dbname/_changes?filter=app/gameboard&feed=continuous&gameid=38934&heartbeat=1000

   
   Cada cliente receberá um objeto JSON por linha na resposta sempre que um documento pertinente for alterado. (E uma nova linha em branco a cada 1000ms como uma espécie de Keepalive.)
   
   
2. Redis. Ele usa um protocolo simples baseado em linha (como o Memcached ++) para falar sobre um soquete e permite armazenar listas, conjuntos, hashes com valores arbitrários-mesmo binários. É muito rápido porque tudo acontece na memória, mas é persistido no disco assíncrono. Mas acima de tudo, você deve avaliá -lo porque já tem Pubsub notificações assadas. Observe que você terá que publicar explicitamente as notificações de movimentação sobre um canal que os jogadores compartilham porque o Redis não publicará automaticamente quando uma chave/valor mudar.

Como o MongoDB não possui um mecanismo para observar mudanças como eles-happen ou fazer pubsub, não considero isso uma boa opção, embora com um esforço extra você possa fazê-lo funcionar.

Portanto, para concluir, você poderá substituir "The Big Lamp Stack" por CouchDB sozinho, Redis sozinho, ou qualquer um colocado atrás de um aplicativo de nós para filtrar/estender as APIs que eles já fornecem em algo que se encaixa no seu jogo.

Boa sorte!

Answer 2

Eu comecei a aprender Mongo, e não é difícil aprender. Coisas como índices e explicações estão lá e funcionam iguais. Quando se trata de arquitetura, você quer pensar o oposto do SQL; Em vez de precisar de um bom motivo para desnomalizar, você precisa criar um bom motivo para normalizar. Os caras da 10Gen (que fazem Mongo) dirão que pensar em hierárquico é uma maneira mais natural de pensar sobre as coisas, com as quais eu concordaria (provisoriamente). Os localizadores também se sentem meio que o SQL-ish, embora você ainda use redes de mapa para consultas de agregação.

Pelo que entendi sobre o Couch, a grande diferença é que há um forte foco na coisa da replicação distribuída. Mongo se concentra mais no desempenho em quantidades enormes de dados (embora tenham também um auto -atendimento e uma ótima história de escala). Eu iria Mongo, a menos que você realmente use os aspectos distribuídos do sofá.

O Node tem que ser a coisa mais legal de todos os tempos, e acho que essa seria uma ótima aplicação para isso. Não tenho experiência com isso, mas pelo que li, é ótimo para muitas solicitações pequenas e aumenta maravilhosamente. O JavaScript idiomático se presta muito bem a todo o modelo de eventos e, com o V8, ele corre apenas obscenamente rápido.