Como os jogos salvavam seu progresso antes dos Memory Cards

Imagine um mundo de jogos sem poder salvar o game. Imagine games como Baldur’s Gate 3, com centenas de horas de jogo, milhares de itens para se colecionar no inventário e decisões para se tomar sem poder salvar o game?

Talvez não com jogos de centenas de horas, mas antes era preciso sentar e terminar o jogo de uma vez só. Às vezes levava duas ou três horas, mas o recurso de salvar um jogo é algo que não era tão comum antes.

O avanço para memory cards e armazenamento interno tirou o peso desses trade-offs. Em paralelo, discos regraváveis e o armazenamento no PC resolveram o problema para quem tinha o hardware. Mas, antes dos memory cards havia duas opções práticas:

• Senhas: sem custo de hardware, mas incômodas e limitadas.

• Memória com bateria no cartucho (SRAM + bateria): experiência natural, mais espaço, mas risco de perda quando a bateria morre.

Salvar significa guardar dados que permitam reabrir o jogo no mesmo ponto: nível, itens, vida, chefes derrotados, e por aí vai. Essa lembrança era chamado de “estado”. Lembrar desse estado era uma necessidade para jogos grandes como um Final Fantasy ou Phantasy Star, em que, sem ter como você salvar, era obrigatório terminar o game em “uma sentada” (lá ele). Nos primeiros consoles e nos PCs da época, existiam três limites claros que dificultavam o salvamento de games:

1. Memória regravável era cara demais.

2. Muitos cartuchos eram só leitura (não tinham onde gravar).

3. Alguns estados de jogo eram grandes demais para caber em soluções simples.

Entender essas soluções mostra duas coisas importantes: como limitações de custo e hardware moldam decisões de design, e por que certos jogos pediam que você anotasse códigos. Também explica por que alguns cartuchos perdem saves com o tempo e por que colecionadores se preocupam em salvar e migrar dados. O desafio era achar algo que custasse pouco e funcionasse bem o suficiente para o jogador e para os devs. Daí surgiram as soluções que você vê a seguir.

Passwords

Os Passwords, ou senhas ou códigos, eram uma solução puramente construída com o software. O jogo pega o estado “mínimo necessário” para continuar — por ex.: nível, armas, chefes vencidos, algumas estatísticas — e transforma isso em uma sequência que o jogador anotava. Quando quisesse voltar, o jogador digitava a senha e o jogo reconstrói o estado. Isso foi usado muito porque não precisava de hardware extra. Cartucho só com ROM rodava normalmente.

Mas tem preço: senhas longas e sujeitas a erro e nem sempre o estado era salvo completamente. Você não voltava exatamente de onde estava ou não tinha exatamente os itens que pegava no “meio do caminho”. O processo é direto:

• Escolhem o que precisa ser salvo — só o essencial.

• Cada dado vira um conjunto de bits (pequenos pedaços de informação).

• Esses bits são juntados numa sequência.

• A sequência vira caracteres (letras, números ou símbolos) para o jogador anotar.

• Quase sempre adicionavam um pedaço de verificação (checksum) para evitar que uma senha errada criasse um estado inválido.

Algumas senhas eram só letras e números. Outras usavam blocos ou ícones para reduzir confusão (0 x O, 1 x I). Em certos jogos, há até palavras curtas no lugar de uma longa cadeia de caracteres — isso facilita lembrar e anotar.

Senhas funcionam bem para jogos por fases ou com pouco estado para salvar. Mas quando o jogo tinha um inventário grande, mapa detalhado ou muitas variáveis, a senha fica enorme. E ninguém gosta de digitar 40 caracteres. Além disso, errar um caractere e perder horas de jogo frustrava bastante.

Mesmo assim, as senhas tinham uma vantagem: não dependiam de bateria nem de hardware especial. Se você anotou a senha, ela dura décadas. Isso ajuda a preservar o progresso para quem coleciona ou documenta jogos antigos.

Um exemplo simples de password era:

• Imagine um jogo em que só importa: nível atual (1 a 8), se o chefe X foi vencido (sim/não) e três itens (cada um 0-3). Dá pra transformar tudo isso em uns 12 bits. Esses 12 bits viram 2 ou 3 caracteres numa tabela feita pelo jogo. Pronto: senha curta. Se você precisa salvar mais coisas, aumenta o número de bits — e a senha cresce.

Nem todo programador aceitava lançar senhas enormes. Então usavam truques de compactação simples:

• Agrupar combinações frequentes e atribuir um índice fixo.

• Usar codificação variável: os estados mais prováveis ganhavam códigos menores.

• Trocar caracteres por ícones para evitar confusão e reduzir erro humano.

Tudo isso diminuía o tamanho da senha sem precisar de hardware extra.

Cartuchos com memória e bateria

Quando os jogos ficaram maiores — principalmente RPGs com inventário pesado — senhas deixaram de servir. A solução prática foi colocar memória de gravação dentro do cartucho. Bons exemplos disso eram jogos como Pokémon, que podiam salvar os monstrinhos que você tinha no inventário e na mochila.

Essa memória chama-se SRAM e ela perde os dados se não tiver energia. Para evitar isso, os cartuchos levavam uma bateria que mantinha a SRAM alimentada mesmo com o console desligado. Assim, os dados “ficavam lá” até a bateria acabar e, como salvar esse estado não consumia muita energia, uma bateria dessas de relógio durava anos. Para o usuário, o processo é simples: você salva no menu e, quando voltar, o jogo carrega automaticamente. Nada de digitar código. O cartucho típico tinha:

• ROM para o código do jogo.

• Um chip de SRAM para guardar os saves.

• Uma bateria que alimentava a SRAM quando o console estava desligado.

• Circuito básico para trocar entre a fonte do console e a bateria.

Programadores tratavam a SRAM como se fosse um pequeno arquivo. Escreviam um cabeçalho (identificação, versão), depois os dados: flags de progressão, inventário, estatísticas. Também era comum ter checksum para detectar corrupção caso a bateria estivesse fraca ou algo desse errado.

As vantagens desse método eram claras, os saves sem digitar, muito mais espaço para salvar, experiência natural para o jogador. Já as desvantagens eram o custo extra no cartucho (memória + bateria) e a vida limitada da bateria. Quando a bateria morria, os saves sumiam. Trocar a bateria às vezes exigia abrir o cartucho e dessoldar o componente — tarefa que muita gente evitava e, lógico, você perdia o seu save.

Hoje, colecionadores trocam baterias e fazem backup dos saves antes. Emulação também permite extrair o arquivo de save e salvá-lo no PC.

Memória interna do console

Antes também dos memory cards se tornarem padrão, alguns consoles já ofereciam uma forma de salvar progresso usando memória interna no próprio aparelho, em vez de depender de cartuchos com bateria ou senhas. Consoles como o Sega CD tinham RAM interna, às vezes alimentada por bateria, que podia guardar os dados de qualquer jogo compatível. O jogador não precisava digitar nada, e o progresso ficava disponível automaticamente sempre que voltava ao jogo.

A memória interna era limitada, tanto em espaço quanto em número de saves simultâneos (cerca de 8mb), mas era uma alternativa interessante quando os cartuchos não tinham bateria ou quando o jogo precisava de um local fixo e compartilhado para salvar. Diferente da SRAM de cartucho, essa memória era fixa e não removível, funcionando para todos os jogos do console que a utilizassem.

O funcionamento era simples: o jogo escrevia diretamente na memória do console, estruturando geralmente os dados com cabeçalho, flags de progresso, inventário e estatísticas, e incluía um sistema de verificação para evitar corrupção. Assim como os cartuchos com bateria, essa memória tornava a experiência de salvar natural e transparente para o jogador.

O grande ponto negativo era a limitação de espaço e o fato de não ser portátil: se o console quebrasse ou perdesse energia sem proteção, os saves se perdiam. Mesmo assim, foi um passo importante na evolução dos métodos de salvar, criando uma ponte entre os cartuchos clássicos e os futuros memory cards removíveis.

Além de senhas e cartuchos com bateria, havia alternativas para os saves dos jogos que eram mais limitadas e incomuns, mas tentavam criar alternativas para você não perder seu progresso em consoles e PC:

• Famicom Disk System (e outros sistemas em disco): o jogo gravava em disco. Isso permitia saves complexos, mas dependia do periférico.

• PC e computadores domésticos: gravavam em disquete ou fita cassete. No PC já era normal salvar em disco.

• Periféricos e cartões proprietários: alguns consoles ou add-ons tinham suas próprias memórias.

• Design do jogo: alguns jogos evitavam salvar ao usar checkpoints frequentes ou níveis curtos — um jeito de reduzir a necessidade de gravação.

Como muitas baterias hoje já acabaram, os colecionadores e emuladores savam essas memórias de outros tempos. As alternativas mais comuns:

• Extrair o arquivo de SRAM com equipamento e salvar no PC.

• Trocar a bateria do cartucho com cuidado.

• Regravar o save no cartucho, se possível.

Existem tutoriais e serviços que fazem isso. Também dá para jogar em emulador usando o arquivo de save e manter tudo salvo para sempre.

A evolução dos jogos, a expansão em tamanho, horas de jogo e a necessidade de criar formas de se salvar o progresso forçou os desenvolvedores a achar soluções práticas. Senhas e cartuchos com bateria foram as duas respostas a essa mesma necessidade, cada uma com vantagens e desvantagens claras. Senhas exigiam esforço do jogador de anotar e lembrar; cartuchos com bateria exigiam investimento no hardware e, com isso, aumento de preço.

Ambos mostram que, no passado, quem criava jogos tinha que decidir entre custo, experiência do jogador e limites técnicos. Hoje a tecnologia resolve esses problemas, mas, para os mais velhos, vale lembrar como funcionava e, para os mais novos, conhecer isso e entender por que algumas medidas antigas ainda aparecem em jogos e coleções.