[Feature] Aumentar limite de jogadores por sala para 30 participantes

[caioross]

🚀 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.

---

[caioross]

Resolvido em PR #76 (auto/issue-69-players-30).

Teto elevado 12→30 numa fonte única (ABSOLUTE_MAX_PLAYERS em room.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_players nã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).

[caioross]

Fatia 1 entregue (PR #76, mergeada) — issue segue aberta

A PR #76 elevou o teto para 30 com fonte única (ABSOLUTE_MAX_PLAYERS em src/lib/room.ts, consumida pelos dois clamps da API e pelos dois sliders) e entrou com Refs, não Closes: 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

• Salas aceitam até 30 jogadores (clamp de criação e de settings; slider da Home e do Lobby; cap de sanitizeResults).

Critérios ainda abertos — com os pontos concretos que o quórum levantou

• A interface suporta corretamente essa quantidade. PLAYER_COLORS (src/lib/room.ts) tem 8 cores e colorForId é hash % 8 → com 30 jogadores são ~4 por cor, e a cor é o identificador visual primário em PlayerList, RaceTrack e Lobby. Também: RaceTrack usa minHeight: 80 + N * 34 → ~1.100px com 30 corredores.
• Não há degradação perceptível de desempenho. O progresso é publicado com PROGRESS_THROTTLE_MS = 120 por 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 a textarea da corrida (área sagrada). O caminho provável é React.memo em RaceTrack/TypingCore e/ou throttle adaptativo ao tamanho da sala — a própria issue já previa "otimizar o envio de eventos".
• Chat e placar sincronizados com 30 — só se prova em sessão Realtime real com dezenas de clientes; não é reproduzível localmente.

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.