Regras e Fairness

Regras principais

• Cada par de canos atravessado sem colisão vale um ponto.
• Só contas registadas aparecem no leaderboard.
• Cada run tem uma seed única - as posições dos canos são determinísticas e diferentes em cada tentativa.
• Não é permitido usar bots, scripts ou automação para jogar ou submeter pontuações.
• Pontuações manipuladas ou inválidas são removidas sem aviso prévio.

Como a pontuação é calculada

A pontuação é o número de pares de canos que o pássaro atravessa. O contador sobe um ponto no momento em que o centro do cano passa pela posição horizontal do pássaro sem colisão. Não existe pontuação por tempo, distância ou saltos.

A distância percorrida é registada em paralelo (em unidades internas convertidas para quilómetros) como dado informativo, mas não conta para o leaderboard.

Como os saltos são registados

Cada salto é registado com o seu timestamp absoluto desde o início da run, em milissegundos. O cliente envia a lista de timestamps com a pontuação no fim de cada partida.

A precisão do timestamp é importante para o replay. Na versão de regras v5 (simulação a 240 Hz), a janela de aceitação de um salto é de aproximadamente ±2 ms - mais precisa do que em versões anteriores.

Como os replays funcionam

O replay não é um vídeo. É o servidor a re-correr a mesma simulação com os mesmos parâmetros:

• Seed da run - determina todas as posições dos canos.
• Timestamps dos saltos - determinam a posição vertical do pássaro em cada passo de simulação.
• Versão das regras - define o motor de simulação utilizado (v2 a v5).

Com esses três inputs, a simulação é completamente determinística: o mesmo input produz sempre o mesmo output, tanto no cliente como no servidor.

O que é validado no servidor

Após cada partida, o servidor executa os seguintes passos:

1. Re-executa a simulação completa com a seed e os timestamps de saltos recebidos.
2. Compara o score da simulação com o score declarado pelo cliente.
3. Verifica se a duração e a distância da run são compatíveis com a pontuação.
4. Aplica controlos adicionais de integridade.

Se a validação passa, a pontuação é confirmada e publicada no leaderboard. Se não passa, a run fica em estado de revisão para análise ou é rejeitada.

Anti-cheat e fairness

O Flappy Tuga usa validação server-side para garantir que as pontuações no leaderboard são legítimas. Os detalhes da lógica de anti-cheat não são divulgados para não facilitar tentativas de contornar o sistema.

Em termos gerais:

• Pontuações impossíveis de reproduzir na simulação são rejeitadas.
• Runs com duração, distância ou padrão de saltos inconsistentes com o score declarado são marcadas para revisão.
• A seed e os timestamps dos saltos são verificados para consistência mútua.

Os thresholds exactos de validação não são publicados. Pontuações legítimas marcadas incorrectamente (falsos positivos) são revistas manualmente.

Versões das regras

A física e o motor de simulação foram actualizados ao longo do desenvolvimento do jogo. Cada versão é identificada por um número e é guardada com cada run para garantir que a re-simulação usa o motor correcto:

• v1 - versão legada; step variável dependente do browser. Replays com melhor esforço.
• v2 / v3 - simulação canónica a 60 Hz. Replays determinísticos.
• v4 - mundo canónico independente do tamanho do ecrã; 60 Hz.
• v5 - mesma física que v4; simulação a 240 Hz para maior precisão no timing dos saltos.

Pontuações de versões anteriores permanecem válidas e preservadas no leaderboard. Cada run é validada com o motor da versão em que foi jogada.

Porque algumas runs ficam em revisão ou são rejeitadas

Uma run pode ficar em revisão ou ser rejeitada por vários motivos:

• A re-simulação no servidor não conseguiu reproduzir a pontuação declarada.
• A run tem características incompatíveis (por exemplo, duração demasiado curta para a pontuação).
• Um falso positivo do sistema de validação (raro, mas possível).
• Problema técnico temporário na fila de validação.

Em dispositivos com ecrãs de alta frequência (120 Hz, 144 Hz) a jogar em versões anteriores ao v5, a divergência de física entre cliente e servidor pode causar falsos positivos. O v5 foi desenvolvido precisamente para eliminar este problema.

Diferença entre replay público e validation replay

Nem todos os replays são públicos. O replay público é o que podes ver no leaderboard ou no perfil de um jogador - mostra a run visualmente no browser.

O validation replay é a re-simulação interna que o servidor executa para verificar a pontuação. Este processo corre no servidor sem componente visual. O resultado é usado apenas para confirmar ou rejeitar a run.

As runs modernas submetidas ao sistema de validação são re-simuladas no servidor. Nem todas têm replay público - por exemplo, runs antigas ou runs cujo processamento de replay ainda não terminou.

Limitações conhecidas

• Em versões anteriores ao v5, dispositivos de 120 Hz ou mais podem produzir divergências de física que resultam em falsos positivos na validação. O v5 resolve este problema.
• Alguns browsers ou extensões podem interferir com a precisão dos timestamps de saltos, afectando o replay.
• O budget de validação server-side tem um limite de tempo. Em casos raros, uma run muito longa pode esgotar o budget e ficar em estado de revisão.