Olhando agora, acho que seria melhor ainda se o exemplo do xadrez mencionasse que a pessoa do meio tem seu próprio tabuleiro e aquele tabuleiro é a fonte da verdade, os clients precisam estar sempre de acordo com ele, os tabuleiros dos clients acabam sendo meramente visuais, um reflexo do tabuleiro central. Ou seja, o jogo e os estados de um jogo multiplayer, sempre ta rolando NO SERVIDOR, os clients só pedem pra fazerem alterações nesse estado central e a cada alteração eles são atualizados de acordo.
Achei legal a analogia dos dois tabuleiros. No caso vocês tinham um socket.on esperando requests num tópico e para cada mensagem, validavam e usavam o socket.broadcast, pelo que entendi. Uma pergunta um pouco mais avançada: No caso de eu ter múltiplas salas (um socket.room por exemplo) e quiser fazer o broadcast apenas praquela sala, eu enviaria um payload e nos clients validaria se está vindo pra minha room usando esse payload, acredito eu. Mas ficaria não tão performatico verificar em cada request o payload, mesmo que usássemos uma lense. Tem como eu fazer uma espécie de load balancear pra esse tipo de request/mensagem de socket quando há um broadcast? Ou alguma abordagem pra diminuir a complexidade de verificações de payload? Exemplo um token estilo jwt ou algo do tipo?
Fala grande Caponi! Obrigado pelos elogios! Com certeza tem abordagens bacanas pra performance cara, mas no Tiny não implementei nada nesse sentido... No Tiny Land eu não comprimi dados nem nada, mas cheguei a usar criptografia (igual um JWT que você mencionou) pra lidar com dados sensíveis no cliente. Tem uma funcionalidade do Tiny Land que usa AES (Advanced Encryption Standard) pra encriptar os dados do jogador e enviar pro cliente (pro client salvar no localstorage o estado do player de uma forma segura). Eu usei AES apenas com a finalidade de criptografar dados sensíveis, não pensando em performance nem buscando compressão, pra segurança é ótimo, mas em relação a quantidade de bytes trafegados não mudou muito. Então não sei se um JWT seria uma solução pra menos tráfego ou mais performance. Com certeza existem estratégias boas pra melhorar performance e tráfego em aplicações q exigem respostas rápidas (tipo um game online), mas nesse quesito sou bem noob xD A cargo de curiosidade, segue a classe que gerencia criptografia e descriptografia no Tiny Land (pode fazer uns testes pra ver se a criptografia diminui os bytes da string original, mas acho que não): github.com/tiny-devs/tiny-dungeon-online/blob/master/server/data/dataManager.ts Segue também um debate sobre compressão e descompressão de dados pra diminuir tráfego de bytes em jogos online (a galera é meio contra) gamedev.stackexchange.com/questions/172243/should-i-compress-websocket-payload-data-in-a-game-where-latency-matters
Olhando agora, acho que seria melhor ainda se o exemplo do xadrez mencionasse que a pessoa do meio tem seu próprio tabuleiro e aquele tabuleiro é a fonte da verdade, os clients precisam estar sempre de acordo com ele, os tabuleiros dos clients acabam sendo meramente visuais, um reflexo do tabuleiro central.
Ou seja, o jogo e os estados de um jogo multiplayer, sempre ta rolando NO SERVIDOR, os clients só pedem pra fazerem alterações nesse estado central e a cada alteração eles são atualizados de acordo.
Muito bom amigo. Quando possível continue com seus vídeos. Abraço
Achei legal a analogia dos dois tabuleiros. No caso vocês tinham um socket.on esperando requests num tópico e para cada mensagem, validavam e usavam o socket.broadcast, pelo que entendi.
Uma pergunta um pouco mais avançada:
No caso de eu ter múltiplas salas (um socket.room por exemplo) e quiser fazer o broadcast apenas praquela sala, eu enviaria um payload e nos clients validaria se está vindo pra minha room usando esse payload, acredito eu.
Mas ficaria não tão performatico verificar em cada request o payload, mesmo que usássemos uma lense.
Tem como eu fazer uma espécie de load balancear pra esse tipo de request/mensagem de socket quando há um broadcast? Ou alguma abordagem pra diminuir a complexidade de verificações de payload? Exemplo um token estilo jwt ou algo do tipo?
Fala grande Caponi! Obrigado pelos elogios!
Com certeza tem abordagens bacanas pra performance cara, mas no Tiny não implementei nada nesse sentido... No Tiny Land eu não comprimi dados nem nada, mas cheguei a usar criptografia (igual um JWT que você mencionou) pra lidar com dados sensíveis no cliente.
Tem uma funcionalidade do Tiny Land que usa
AES (Advanced Encryption Standard) pra encriptar os dados do jogador e enviar pro cliente (pro client salvar no localstorage o estado do player de uma forma segura).
Eu usei AES apenas com a finalidade de criptografar dados sensíveis, não pensando em performance nem buscando compressão, pra segurança é ótimo, mas em relação a quantidade de bytes trafegados não mudou muito. Então não sei se um JWT seria uma solução pra menos tráfego ou mais performance.
Com certeza existem estratégias boas pra melhorar performance e tráfego em aplicações q exigem respostas rápidas (tipo um game online), mas nesse quesito sou bem noob xD
A cargo de curiosidade, segue a classe que gerencia criptografia e descriptografia no Tiny Land (pode fazer uns testes pra ver se a criptografia diminui os bytes da string original, mas acho que não):
github.com/tiny-devs/tiny-dungeon-online/blob/master/server/data/dataManager.ts
Segue também um debate sobre compressão e descompressão de dados pra diminuir tráfego de bytes em jogos online (a galera é meio contra)
gamedev.stackexchange.com/questions/172243/should-i-compress-websocket-payload-data-in-a-game-where-latency-matters
HÁ Muleke :)
Esse vídeo super irônico hsudhdudh gostei
Noice video xD