Sincronização e economia inicial sustentam uma partida multiplayer divertida?
Sincronizar lobby, recursos e construção com baixa latência antes de investir na economia completa do jogo.
CASE FILE. 03 / ESTRATÉGIA / GAME
Castle Wars
Estratégia multiplayer inspirada em Tribal Wars 2. O protótipo cobre autenticação, lobby, mundos, realtime e o primeiro loop de recursos e construção.
- React
- Node.js
- Socket.IO
- Firebase Auth
BRIEF. 01 / PROBLEMA E FRONTEIRA
O produto em uma leitura.
Um recorte deliberado do estado atual. Métricas e hipótese continuam editoriais até que exista evidência pública para substituí-las.
- FLUXO
- LOBBY → PARTIDA RÓTULO EDITORIAL
- LOOP
- RECURSOS + OBRA RÓTULO EDITORIAL
- CAPACIDADES
- 3 frontend / backend / realtime
- PORTA PÚBLICA
- NÃO SUPERFÍCIE PRIVADA
SYSTEM TRACE. 02 / FLUXO PRINCIPAL
Fronteiras antes de frameworks.
Cliente React → gateway Socket.IO → loop de mundo em Node.js → autenticação Firebase.
- 01CLIENT→
World client
React / comandos e projeções
- 02GATEWAY→
Realtime gateway
Socket.IO / salas e presença
- 03LOOP→
World process
Recursos, fila e relógio do servidor
- 04STATE
Persistence boundary
Memória agora / roadmap explícito
intent → policy → authoritative state → observable effectEXECUTION TRACE / ILLUSTRATIVE
Um caminho. Cada decisão à vista.
Sequência editorial para discutir contrato, autoridade e efeito. Não representa telemetria real de produção.
- CLIENT
Emite intenção com versão conhecida do mundo.
build.requested - GATEWAY
Autentica presença, sala e contrato do evento.
command.accepted - LOOP
Valida recurso, fila e relógio no servidor autoritativo.
build.started | rejected - STATE
Avança a versão e publica a projeção da sala.
world.version + 1
DECISION LOG. 03 / TRADE-OFFS
Toda escolha cobra algo.
Validar o loop realtime em memória, declarando a persistência como lacuna em vez de fingir uma infraestrutura pronta.
- 01 / PROTÓTIPO
Estado em memória no primeiro loop
- GANHO
- Valida sincronização e diversão antes de operar infraestrutura maior.
- CUSTO
- Reinício perde o mundo e limita sessões longas deliberadamente.
- 02 / AUTORIDADE
Comando no cliente, decisão no servidor
- GANHO
- Economia e fila de construção preservam uma fonte de verdade.
- CUSTO
- A interface precisa prever latência, rejeição e reconciliação.
- 03 / PROTOCOLO
Eventos pequenos por sala
- GANHO
- Atualizações ficam focadas no mundo que realmente mudou.
- CUSTO
- Versionamento e reentrada precisam reconstruir um snapshot coerente.
RELIABILITY. 04 / FALHAR COM CONTEXTO
Modo de falha. Sinal de volta.
Não são métricas de produção publicadas. São os riscos que o desenho precisa tornar observáveis e os sinais candidatos para a próxima rodada.
- 01
Cliente retorna de uma queda com projeção anterior à do servidor.
- 02
Dois comandos simultâneos disputam o mesmo recurso ou slot de fila.
- 03
Reinício do processo invalida o mundo ainda mantido em memória.
- 01
Diferença de versão entre snapshot do cliente e estado autoritativo.
- 02
Comandos rejeitados por saldo, relógio ou conflito de fila.
- 03
Taxa de reconexão que volta ao jogo sem intervenção manual.
INCIDENT DRILL. 05 / CONTENÇÃO → RECUPERAÇÃO → PROVA
Quando a hipótese quebra.
Exercícios editoriais de resiliência, não incidentes reais nem runbooks de produção. Cada drill transforma um modo de falha em uma resposta discutível e testável.
DRILL-01Cliente retorna de uma queda com projeção anterior à do servidor.SIMULATION / NATIVE
Resposta para: Cliente retorna de uma queda com projeção anterior à do servidor.
- CONTAIN
- Bloquear novos comandos até comparar a versão local com a versão autoritativa da sala.
- RECOVER
- Entregar snapshot atual e cursor de eventos, então reabrir a entrada somente depois do reconhecimento do cliente.
- PROVE
- Confirmar que todos os jogadores observam o mesmo mundo e que nenhum comando foi aplicado sobre versão obsoleta.
DRILL-02Dois comandos simultâneos disputam o mesmo recurso ou slot de fila.SIMULATION / NATIVE
Resposta para: Dois comandos simultâneos disputam o mesmo recurso ou slot de fila.
- CONTAIN
- Serializar a decisão no processo do mundo e rejeitar o comando que perdeu a comparação de versão.
- RECOVER
- Publicar a nova projeção e um motivo de rejeição que permita ao cliente recompor a intenção sem adivinhar.
- PROVE
- Rodar cenários concorrentes e demonstrar conservação de recursos, uma fila válida e versão monotônica.
DRILL-03Reinício do processo invalida o mundo ainda mantido em memória.SIMULATION / NATIVE
Resposta para: Reinício do processo invalida o mundo ainda mantido em memória.
- CONTAIN
- Encerrar a sala como sessão de laboratório, sem fingir que o estado efêmero continua disponível.
- RECOVER
- Criar um novo mundo e usar o incidente como gate para introduzir checkpoint antes de sessões persistentes.
- PROVE
- Garantir que nenhum cliente retome um mundo fantasma e que o limite do protótipo fique visível no lobby.
DESIGN EXERCISE / REVISAR CONTRA TELEMETRIA E RUNBOOKS REAIS ANTES DE OPERAR
EVIDENCE. 06 / O QUE PODE SER DEFENDIDO
Fato à vista. Lacuna também.
Persistir o estado do mundo, introduzir reconciliação e testar conflitos de comandos simultâneos.
- React + Node / Express + Socket.IO
- Firebase Auth
- Recursos + primeira fila de construção
- Estado em memória; persistência no roadmap
- Projeto independente, sem vínculo com a referência
INTERVIEW MODE. 07 / APROFUNDE A CONVERSA
Três pontos para abrir no quadro.
Perguntas que conectam o case a system design, produto e operação sem transformar uma decisão contextual em regra universal.
- 01
Como migrar do protótipo em memória para persistência sem travar o loop.
↗ - 02
Quando enviar evento incremental e quando reconstruir um snapshot.
↗ - 03
Como testar relógio, economia e conflitos concorrentes de forma determinística.
↗
CASE FILE / 03