Como rodar e modificar o primeiro jogo do mario: o que você realmente precisa saber
O primeiro jogo do mario é Super Mario Bros., lançado pela Nintendo em 1985 para o Famicom/NES. É um jogo simples na superfície, mas por trás dele existe uma arquitetura de dados que permite muito mais manipulação do que a maioria das pessoas imagina. Vou explicar isso sem rodeios, porque a verdade é que quase todo mundo que começa a mexer com esse jogo não sabe por onde começar e acaba seguindo tutoriais genéricos que ensinam o básico mas ignoram os problemas reais. A primeira coisa que as pessoas fazem é baixar um emulador e pronto. Super Mario Bros. roda em qualquer emulador NES decente — Nestopia, Mesen, RetroArch com o núcleo QuickNES. Mas se o seu objetivo é apenas jogar, não há nada técnico pra explicar aqui. O interesse real começa quando você quer editar, romper ou examinar como o jogo funciona.
Primeiro jogo do mario:ROM hacking e edição direta
Para editar o jogo, você precisa de uma ROM e de ferramentas específicas. A ROM original do Super Mario Bros. é um arquivo de 32 KB que cabe praticamente em qualquer lugar. O problema é que existem dezenas de versões diferentes — Japonesa, Americana, Europeia, revs variadas — e cada uma tem offsets ligeiramente diferentes. Se você baixar a ROM errada, tudo o que seguir depois vai falhar sem motivo aparente. O mais seguro é usar a ROM NTSC-U v1.0, que é a mais documentada e tem as tabelas de offset mais estáveis. Dica prática: verifique o checksum da ROM antes de começar. A ROM NTSC-U v1.0 tem o checksum 0xC2D8. Se o arquivo que você baixou tiver outro checksum, não use — edite o arquivo errado e vai perder horas tentando entender por que os gráficos estão quebrados ou os inimigos sumindo.
Para o trabalho de ROM hacking em si, a ferramenta mais confiável é o ROM Editor for SMB1 ou o projeto SMW Quest se você quiser algo mais moderno. O ROM Editor é mais lento e menos intuitivo, mas mostra exatamente o que está sendo modificado. Já o SMW Quest é mais visual, mas pode esconder coisas importantes das tabelas de dados. Eu prefiro o primeiro quando preciso de precisão, o segundo para experimentação rápida. Um problema que eu encontrei pessoalmente: ao tentar modificar a posição inicial do Mario no World 1-1, alterei o byte correto no editor, salvei, testei no emulador e o personagem simplesmente despencava pelo buraco na posição errada. O problema era que o jogo usa coordenadas em pixels, mas o editor interpreta como tiles (cada tile = 16x16 pixels). A correção foi multiplicar a posição desejada por 16. O tile 2 em X corresponde ao pixel 32, não ao pixel 2. Isso parece óbvio depois que você descobre, mas leva tempo pra entender.
O que o jogo realmente guarda nos dados
Super Mario Bros. é extremamente eficiente com memória. O jogo inteiro cabe em 32 KB de ROM e usa apenas 2 KB de RAM. Isso significa que cada byte conta. Os designers antigos tinham que pensar de forma muito diferente do que pensamos hoje. Um exemplo disso: os inimigos no jogo não são entidades independentes com IA complexa. Cada Goomba, Koopa e fantasma é controlado por uma máquina de estados simples que é processada em um loop central. O jogo verifica a posição de cada inimigo em relação ao Mario a cada frame, e decide se move, ataca ou para com base em regras muito fixas. Não há pathfinding. Não há variáveis flexíveis.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outra coisa interessante: os blocos quebráveis (tijolos) e os blocos interrogativos têm o mesmo ID de objeto na memória, mas se comportam de formas diferentes porque o código checa bits específicos do byte de propriedade do bloco. Se você estiver editando o jogo e quiser criar um bloco que pareça interrogativo mas funcione como tijolo, precisa modificar tanto o sprite quanto o byte de propriedade correspondente. Fazer apenas uma das duas coisas resulta em comportamento inconsistente.
Speedrunning: a realidade por trás dos recordes
Se o seu interesse é competir ou estudar o jogo sob outra ótica, o speedrunning de Super Mario Bros. é onde a coisa fica mais técnica. O jogo original tem um bug famoso chamado "warping" que permite escapar de fases inteiras. O mais conhecido é o 1-2 shortcut, onde você pula em uma nuvem no final da fase e cai direto no castelo. O problema é que a maioria dos tutoriais ensina o método de forma incompleta. Eles mostram o timing de pulo, mas esquecem de mencionar que a posição exata do Mario no eixo X determina se o warp funciona. Se você estiver dois pixels à esquerda ou à direita, o personagem simplesmente não entra na lógica de transição e cai no abismo. Eu gastou cerca de três semanas tentando estabilizar esse warp antes de perceber que o emulador estava usando frame advance de forma inconsistente — algumas versões do Nestopia avançam frames de maneiras ligeiramente diferentes dependendo da configuração. Mudar para o Mesen resolveu o problema porque ele é mais estrito com o timing de frames.
Outro detalhe que quase ninguém menciona: o jogo tem um timer de tempo limitado em todas as fases exceto no castelo final. Se você demorar demais, o cronômetro zera e o jogo acaba. Isso cria uma pressão constante que muda completamente a estratégia de qualquer nível. Níveis como 2-2 e 3-3 parecem triviais em playthroughs normais, mas sob pressão de tempo exigem rotas alternativas que só aparecem depois de centenas de tentativas.
Limitações que ninguém gosta de admitir
Super Mario Bros. é um produto de 1985. Ele foi feito para uma máquina com 2 KB de RAM e um processador de 1,79 MHz. Isso impõe restrições que parecem arbitrárias hoje em dia. O jogo não suporta telas scrolláveis em todas as direções — o scroll é apenas horizontal. Isso limita drasticamente o design de níveis que podem ser criados. Se você tentar fazer uma fase com scroll vertical, vai esbarrar nas limits do hardware e o jogo vai travar ou mostrar gráficos corrompidos. Além disso, a palette de cores do NES é extremamente limitada. O jogo usa apenas 52 cores simultaneamente na tela, e muitas delas são compartilhadas entre sprites e backgrounds. Isso significa que ao editar gráficos, cores que parecem OK em um contexto podem ficar ilegíveis em outro. Eu já vi editores modernos de SMB que permitem importar sprites com cores de 24-bit, mas ao salvar a ROM, as cores são truncadas para a palette do NES e ficam com aspecto estranho ou desaparecem completamente.
Se o seu objetivo é criar conteúdo novo em vez de modificar o jogo original, considere usar frameworks como SMJS (Super Mario JS) ou SMBX. Eles são mais flexíveis, permitem física customizada e não têm as limitações de hardware dos anos 80. O custo é que você perde a autenticidade da experiência original — o "feel" do jogo de 1985 é algo muito específico que esses engines não replicam perfeitamente. O que eu recomendo dependeria do seu objetivo real. Se quer preservar e modificar o jogo como ele era, use ROM editing com atenção aos checksums e às diferenças entre versões. Se quer expandir o conceito, migre para engines modernas. As duas abordagens são válidas, mas misturá-las sem entender as limits de cada uma geralmente resulta em frustração e projetos inacabados.
