Protocolo do bonk.io

Esta página resume o que a biblioteca faz por baixo. A documentação completa, com todos os IDs de packet e formatos, fica no arquivo BONK_PROTOCOL.md do repositório.

Camadas de rede

Fluxo de uma sessão

1. Login em login_legacy.php, que devolve um token.
2. Descoberta do servidor (getrooms.php para criar, autojoin.php para entrar por URL).
3. Conexão Socket.IO ao servidor indicado, com timesync periódico.
4. Criar (CREATE_ROOM) ou entrar (JOIN_ROOM) na sala.
5. O host responde a cada jogador que entra com os dados iniciais (veja abaixo).
6. Partida: o host envia TRIGGER_START e o servidor ecoa GAME_START para todos.

Duas conexões: Socket.IO e WebRTC

O Socket.IO cobre a sala (jogadores, times, chat, início e fim de partida). Mas o movimento dos jogadores dentro da partida não passa por ele: é sincronizado por WebRTC entre os peers, sinalizado por um broker PeerJS padrão. Para receber esses frames (base do anti-AFK), a biblioteca completa o handshake WebRTC como um jogador comum.

Os frames de input são pequenos pacotes binários. Há um frame por tecla apertada ou solta e nenhum enquanto o jogador está parado.

Dados iniciais de quem entra

Quando um jogador entra, o host envia um pacote com o estado da sala. O client só aceita o primeiro:

Enviar os dois deixa o segundo ignorado. A biblioteca escolhe o certo automaticamente.

Armadilhas que a biblioteca já resolve

• players[] é um array esparso. O índice é o id do jogador; slots vagos são null.
• O criador da sala não recebe JOIN_ROOM. Ele é o player 0 e host.
• room_full é ambíguo. Só é terminal quando o bot ainda não entrou na sala.
• O mapa no INFORM_IN_LOBBY é um objeto JSON, não uma string LZ.
• O IS blob depende do número de jogadores e do mapa.
• bal explícito. Com bal: [], ids não contíguos podem gerar spawns trocados.
• gs.tl precisa refletir o lock real da sala: com o lock ligado e gs.tl: false, os jogadores ficavam congelados.
• Ids de packet têm namespaces separados por direção (o 20 recebido é chat; o 20 enviado é outra coisa).

Numeração dos times

0 spec · 1 FFA · 2 vermelho · 3 azul · 4 verde · 5 amarelo.

Limites de taxa

O servidor limita a frequência de vários comandos e responde com um status-message (rate_limit_tl para o lock de times, rate_limit_cot para trocas de time, etc.). Códigos terminais, como banned, encerram a sala.