Repository navigation
[Feature] Aumentar limite de jogadores por sala para 30 participantes #69
Description
🚀 Feature
Expandir a capacidade máxima das salas multiplayer.
📖 Contexto
Hoje uma sala suporta até 12 jogadores simultaneamente.
Esse limite funcionou bem durante o desenvolvimento inicial, porém já começa a limitar comunidades maiores, transmissões ao vivo e grupos de amigos.
Há interesse em realizar partidas significativamente maiores.
❌ Problema
O limite atual obriga jogadores a criarem várias salas diferentes.
Isso reduz:
- interação;
- competitividade;
- sensação de comunidade.
Além disso, eventos organizados ficam limitados.
💡 Proposta
Alterar o limite máximo de participantes.
Atual
12 jogadores
↓
Novo
30 jogadores
⚙️ Pontos de atenção
Antes da implementação será necessário validar:
- desempenho dos WebSockets;
- sincronização em tempo real;
- consumo de memória;
- atualização da lista de jogadores;
- impacto no chat;
- impacto no ranking durante a partida.
Caso necessário, otimizar o envio de eventos para evitar tráfego desnecessário.
🎯 Benefícios
- partidas maiores;
- mais interação;
- melhor para streamers;
- ideal para comunidades e eventos.
✅ Critérios de aceite
- Salas aceitam até 30 jogadores.
- A interface suporta corretamente essa quantidade.
- Não há degradação perceptível de desempenho.
- O chat continua funcionando normalmente.
- O placar permanece sincronizado.
Activity
caioross commentedon Jul 26, 2026
Resolvido em PR #76 (
auto/issue-69-players-30).Teto elevado 12→30 numa fonte única (
ABSOLUTE_MAX_PLAYERSemroom.ts); os 2 clamps da API e os 2 sliders (Home/Lobby) agora derivam dela — servidor e UI não divergem. Sem migração (rooms.max_playersnão tem CHECK de teto). Gate verde: typecheck · build · 34 testes · persistência 49 · métricas 37.⚠ Nota honesta: os 30 jogadores correndo ao vivo (chat, sync, os "pontos de atenção" de performance da issue) só se validam numa sessão Realtime real — não reproduzível localmente. Sinalizei ao quórum para pesar se 30 entra direto ou se convém um degrau. PR non-draft com quórum (§7.2 — toca a API de salas).
fix(rooms): elimina os "12" remanescentes e destautologiza o teste do…
caioross commentedon Jul 26, 2026
Fatia 1 entregue (PR #76, mergeada) — issue segue aberta
A PR #76 elevou o teto para 30 com fonte única (
ABSOLUTE_MAX_PLAYERSemsrc/lib/room.ts, consumida pelos dois clamps da API e pelos dois sliders) e entrou comRefs, nãoCloses: o quórum adversarial apontou que os critérios de validação desta issue não foram exercitados com 30 jogadores reais.Critério cumprido
settings; slider da Home e do Lobby; cap desanitizeResults).Critérios ainda abertos — com os pontos concretos que o quórum levantou
PLAYER_COLORS(src/lib/room.ts) tem 8 cores ecolorForIdéhash % 8→ com 30 jogadores são ~4 por cor, e a cor é o identificador visual primário emPlayerList,RaceTrackeLobby. Também:RaceTrackusaminHeight: 80 + N * 34→ ~1.100px com 30 corredores.PROGRESS_THROTTLE_MS = 120por jogador (src/lib/useRoom.ts): com 30 na sala são ~250 eventos publicados/s e fan-out O(N²), cada um disparando re-render da árvore que contém atextareada corrida (área sagrada). O caminho provável éReact.memoemRaceTrack/TypingCoree/ou throttle adaptativo ao tamanho da sala — a própria issue já previa "otimizar o envio de eventos".Vale fatiar os dois primeiros em issues próprias (paleta de cores para salas grandes · fan-out de progresso), que são acionáveis por um Resolvedor; o terceiro depende de teste com gente de verdade.