Mario Super Bros Online

Entendendo o funcionamento multiplayer de fã-clube que todo mundo procura

O projeto que circula como mario super bros online não é nada mais do que uma ROM hackeada com camadas extras de emulação de rede sobre ela. O conceito básico é pegar um build de Super Mario Bros e injetar código Lua ou C que traduza inputs de teclado e joysticks em pacotes UDP entre dois emuladores rodando em máquinas separadas. Isso soa simples quando você lê em fóruns, mas na prática a sincronização é onde tudo costuma desmoronar. A primeira coisa que as pessoas não entendem é que o Mario original foi feito para ser determinístico de 16 bits, então teoricamente dois emuladores devem calcular quadros idênticos se partirem do mesmo estado inicial. O problema real aparece com frames de delay de rede, diferenças entre versões do emulador e a forma como cada um lida com o loop de som. Eu perdi umas três semanas tentando fazer funcionar com ZSNES e Mesen porque eles processam interrupções de joypad em momentos levemente diferentes dentro do ciclo de frame.

mario super bros online

O pipeline que realmente funciona gira em torno de três peças. Primeiro, você precisa de dois emuladores idênticos na mesma versão, com a mesma ROM checksum. Segundo, um servidor relay ou conexão direta P2P que envie os inputsFrame por Frame, não os estados dos personagens. Terceiro, um sistema de roll-back ou input-delay para mascarar a latência. O método que eu uso é input-delay com buffer de 2 frames, o que adiciona cerca de 33ms de latência mas mantém a sincronia sem necessidade de revertimento de estado complexo. Uma pegadinha que quase ninguém menciona é o problema do som. O CPU do NES fica mais lento quando o som está ativo porque o processador tem que cuidar do chip de áudio também. Emuladores diferentes lidam com isso de formas distintas, então dois jogadores podem ter timing ligeiramente diferente só porque um usa um emulador que emula o chip VRC6 e outro não. A solução mais prática é remover completamente a trilha sonora da ROM hack ou usar uma versão com sound disable no core, já que isso também reduz o consumo de CPU em 15 a 20 por cento. Eu tive um caso específico onde dois jogadores com conexões assimétricas, um com 10ms de ping e outro com 85ms, simplesmente não conseguiam jogar juntos usando a configuração padrão. O buffer de 2 frames causava stutter no jogador de baixa latência porque o jogo inteiro era travado pelo mais lento. A workaround que funcionou foi ajustar manualmente o input-delay para 3 frames no lado de quem tinha menor ping e usar um patch que desliga o som condicionalmente baseado no frame count, eliminando a variação de timing do chip de áudio. Depois disso, a sessão rodava estável por horas sem drift.

O download dessas builds geralmente aparece em sites como romhaven ou fóruns do Reddit, mas o risco de malware é real. Eu recomendo extrair a ROM original do seu próprio cartucho via dumper e aplicar os patches diff apenas, ao invés de baixarbinários prontos. O tempo extra de compilar o emulador e montar o ambiente gasta uns 40 minutos na primeira vez, mas evita ter que lidar com trojans disfarçados de .exe no seu PC. Se você precisa de uma alternativa mais segura e já funciona de fábrica, existem forks open source como o Nestopia UE com plugins de netplay que suportam Mario 1.0 nativamente, sem precisar de ROMs modificadas ou injeções de código. O ponto fraco mais óbvio dessa abordagem é que ela não escala acima de dois jogadores. Tentar sincronizar três ou mais instâncias multiplica exponencialmente a complexidade do estado porque cada par de jogadores precisa manter sincronia bilateral, e o jitter de rede de um único participante pode derrubar toda a partida. Para jogos com mais gente, o caminho mais viável hoje em dia é migrar para engines modernas que nativamente suportam state sync, como o projeto SMBX 2 com seu sistema de netplay embutido, mesmo que isso signifique abandonar o visual clássico de 8 bits.