Dicas para comunicação entre o jogo do navegador JS e o servidor node.js. [fechadas]

Estou mexendo em algum jogo simples de panfleto de caverna baseado em Canvas e gostaria de torná-lo multiplayer eventualmente. O plano é usar o Node.js no lado do servidor.

Os dados enviados consistem na posição de cada jogador, direção, velocidade e tal. Os movimentos dos jogadores são simples física de força, então eu devo poder extrapolar movimentos antes da próxima atualização do servidor.

Algumas dicas ou práticas recomendadas no lado das comunicações? Eu acho que os soquetes da web são o caminho a percorrer. Devo enviar informações a cada passo do ciclo do jogo ou com intervalos especificados? Além disso, não me importo se ele não funcionar com navegadores mais antigos.

Recentemente, fiz um cruzamento de asteróides / guerras de geometria com Node.js / JavaScript:
http://github.com/BonsaiDen/NodeGame-Shooter

Ele tem um servidor gordo que processa o jogo e thin clients que são basicamente apenas visualizações. O cliente faz alguma interpolação e outras coisas para torná-la suave.

Você pode examinar esses dois arquivos, que contêm a lógica de rede subjacente, bem como os modelos de ator e cliente:
http://github.com/BonsaiDen/NodeGame-Shooter/blob/master/client/nodegame.client. js
http://github.com/BonsaiDen/NodeGame-Shooter/blob/master/server/nodegame.js

O jogo inteiro é baseado em atores que lidam com seus "eventos de atualização" (as coisas que são enviadas aos clientes) por conta própria, em sua maioria. Também é possível ocultar atores de um cliente específico para implementar, por exemplo, invisibilidade.

Pode-se também gravar jogos e apenas alimentar as mensagens no cliente para reproduzi-las.

No que diz respeito à tecnologia: os
WebSockets são o caminho a seguir aqui. Também fiz uma codificação binária personalizada para JS que, apesar de desistir de coisas como mais de duas casas decimais em carros alegóricos, é cerca de 50% menor que JSON (e é duas vezes mais rápida em V8 que a codificação JSON nativa )

Eu sugiro manter as coisas separadas.

No Stendhal, que é um MORPG 2D escrito em Java, fizemos o seguinte e funciona muito bem:

• O cliente usa um loop rápido para desenhar. Animação suave e algumas previsões para minimizar o atraso.
• O servidor usa um loop para processar toda a lógica do jogo. No nosso caso, pode ser muito mais lento que o loop de desenho. Enquanto os clientes fazem algumas previsões, o servidor sempre vence.

A comunicação entre cliente e servidor é feita usando ações e percepções:

• Ações executadas pelos usuários, como "subir", são enviadas ao servidor quando ocorrem. O servidor os coloca na fila e os processa em seu próprio loop.
• As percepções são enviadas do servidor para o cliente para atualizar sua visão do mundo.

Fizemos alguns "truques" para obter desempenho adicional:

• Temos dois tipos de mensagens de percepção: uma completa usada no login e os jogadores que entram em uma zona. E atualizações incrementais usadas depois disso. Isso economiza muita largura de banda da rede.
• Dividimos as mensagens de percepção em uma parte pública e uma privada: todos os jogadores na mesma zona compartilham a mesma parte pública, para economizar tempo de processamento, pois a serialização acabou sendo um gargalo no Java (não no JavaScript).

Use socket.io , é uma útil biblioteca de abstração de WebSockets que fornece fallbacks para navegadores que não a suportam.

Além disso, se você optar por um modelo on-line como esse, eu recomendaria mover o processamento de jogos para o servidor. Dessa forma, você só precisa comunicar as alterações gráficas e a entrada do mouse / teclado. Também ajuda bastante para evitar trapaças.