Sistema de Amigos
Resumo
Define como jogadores se conectam fora da partida: como se encontram (busca por nickname, código de amigo, convite por link), como confirmam a relação (pedido bilateral), o que enxergam um do outro (status entre Disponível, Offline e Em Partida) e o que essa relação habilita (status e mensagem direta). A política é aberta — qualquer jogador pode enviar pedido para qualquer outro — mas a amizade só existe quando o outro lado aceita explicitamente.
Esta nota registra as decisões do card Definir sistema de amigos (2026-05-12).
Como adicionar
Três caminhos suportados no V1:
| Caminho | Como funciona |
|---|---|
| Busca por nickname | Pesquisa direta pelo nome de display (Nome e Avatar). Como o nome de display é único, a busca retorna no máximo um resultado. |
| Código de amigo | Cada conta tem um código alfanumérico único, compartilhável. O jogador insere o código do outro para localizá-lo. Útil quando o nickname é difícil de digitar ou ambíguo de pronunciar. |
| Convite por link | Link compartilhável (WhatsApp, Discord, etc.). Abre direto na tela de pedido de amizade dentro do app. |
QR Code despriorizado — fica fora do escopo do V1, mas pode entrar em rodada posterior como conveniência adicional para uso presencial.
Formato exato do código de amigo, regras de compartilhamento do link (validade, single-use vs. multi-use, deep linking iOS/Android) ficam pendentes com o time técnico.
Fluxo de pedido
A amizade é bilateral: nenhum jogador entra na lista de amigos sem confirmação do outro lado.
- Jogador A envia pedido de amizade para B (por qualquer um dos três caminhos acima).
- B recebe o pedido em uma caixa de entrada de amigos no app.
- B pode aceitar, recusar ou ignorar o pedido.
- Se aceitar, ambos passam a se ver como amigos.
Enquanto o pedido está pendente, nem A nem B desfrutam dos privilégios de amizade — não veem status um do outro, não trocam mensagem.
Tempo de vida do pedido pendente (expira em X dias? acumula indefinidamente?), limite de pedidos enviados simultaneamente, e tratamento de pedidos recusados repetidos (anti-spam) ficam pendentes.
Status visível
Apenas três estados são exibidos no V1:
| Status | Quando aparece |
|---|---|
| Disponível | Jogador online no app, sem partida em andamento (menu, perfil, navegação). |
| Em Partida | Jogador em lobby ou em partida ativa. Lobby e partida são tratados como o mesmo estado — o jogo não diferencia. |
| Offline | Jogador sem sessão ativa no app. |
A unificação de “lobby” e “partida ativa” sob Em Partida é proposital: para o amigo na lista, a diferença é irrelevante (o jogador está ocupado com Conduta de qualquer forma).
Não existe status “Ausente”, “Não perturbar”, “Em segundo plano” ou similar no V1. Estados intermediários (ex.: o jogador está em Segundo Plano mas a partida segue) a definir com UI antes da implementação.
O que a amizade habilita
Ser amigo concede ao outro lado:
- Ver status do jogador (Disponível / Em Partida / Offline).
- Enviar mensagem direta fora da partida.
- Convidar para a mesma sala — embora o detalhamento do fluxo de convite para sala dependa do desenho de matchmaking e do fluxo de “Voltar ao Lobby” em Pós-Partida.
- Formar grupo na fila (party) — entrar no matchmaking juntos como unidade; regras de tamanho e comportamento em Fila em Grupo.
Inversamente, sem ser amigo:
- Não é possível ver status.
- Não é possível enviar mensagem direta fora da partida.
- O contato só acontece via partida normal (matchmaking) ou pelo Chat interno de uma partida em que os dois jogadores estejam.
O sistema de mensagem direta entre amigos é mencionado aqui como privilégio mas ainda não tem nota de design própria. Precisa fechar regras de moderação (vale Filtro de Linguagem?), histórico, notificações, etc.
Privacidade
- Qualquer jogador pode enviar solicitação para qualquer outro. Não há configuração de “aceitar pedidos apenas de…“.
- A barreira contra contato indesejado é a recusa/ignorar pedido — sem block formal contra spam de pedidos no V1.
- Quando o sistema de block for introduzido (deferido em Mute para uma fase com base de jogadores maior), o block deve impedir o envio de novos pedidos da pessoa bloqueada. Comportamento detalhado fica para essa rodada.
Limite
- Sem limite imposto pelo design. O jogador pode acumular quantos amigos quiser.
- Se a arquitetura técnica (Unity, Cloud Code, backend) impuser um teto prático (por exemplo, 500 amigos por conta como já acontece em algumas APIs), o jogo respeita esse teto e mostra mensagem clara ao jogador ao atingi-lo.
- O design não pede um limite — apenas aceita o que o ambiente técnico determinar.
Pendências (a definir em rodadas futuras)
- Formato do código de amigo (comprimento, charset, regeneração).
- Convite por link: validade, single-use vs. multi-use, deep linking iOS/Android.
- QR Code como caminho adicional de adição (despriorizado, fora do V1).
- Tempo de vida do pedido pendente e regras anti-spam (limite de pedidos enviados, comportamento após recusa repetida).
- Mensagem direta entre amigos: sistema próprio precisa ser desenhado (moderação, histórico, notificações, filtro de linguagem).
Convite para sala entre amigos— definido em Convite para Sala.- Diferenciação de Segundo Plano vs. Em Partida no status — hoje Segundo Plano não tem indicador específico; revisar.
- Block e sua interação com pedidos de amizade (ver pendência em Mute).
- Lista de bloqueados vs. lista de amigos — UI separada, mesma tela?
- Importar amigos de plataformas externas (Google, Apple, Discord) — fora do V1, avaliar depois.
- Lembrar nome anterior quando um amigo troca de nome (Nome e Avatar) para evitar confusão.
Ver Também
- Nome e Avatar
- Progressão — nível aparece na lista de amigos
- Pós-Partida — Voltar ao Lobby preserva grupo de jogadores
- Mute — block (deferido)
- Chat — chat interno de partida (distinto de DM entre amigos)
- Segundo Plano
- Fila em Grupo — entrar na fila junto como party