Índice do artigofaltam 5 min de leitura
Eiji Aonuma, produtor da série Zelda na Nintendo, pediu à equipe que refazia Ocarina of Time uma coisa que o jogo original nunca teve: atalhos para cruzar o mapa mais depressa. A equipe fez os atalhos, jogou com eles, e Aonuma mandou tirar todos. O jogo em questão tem nota 99 na média da crítica reunida pelo Metacritic, site que junta resenhas, e muita gente ainda o considera o seu favorito.
A nova versão chegou às lojas em 5 de novembro, e a equipe contou como trabalhou numa entrevista publicada pela Nintendo dias antes. Quem nunca jogou pode ler o relato como um projeto que toda área de tecnologia conhece: refazer um produto antigo que as pessoas usam de cor, sem estragar o que funciona e sem carregar os defeitos.
Por que este jogo é um caso difícil de refazer
O original saiu em 1998 e foi o primeiro da série em três dimensões. A invenção dele que mais durou nasceu de uma limitação: o controle da época tinha uma alavanca só, e não dava para mover o personagem e a câmera ao mesmo tempo. A equipe criou um botão que prende a câmera no adversário e deixa o jogador cuidar só da luta. Segundo a Nintendo, o recurso virou padrão da série e mudou pouco nos jogos em três dimensões que vieram depois. Todo produto maduro tem soluções assim: nasceram para contornar uma restrição que já não existe, e hoje todo mundo depende delas.
O jeito de trabalhar também era outro. Aonuma conta que havia vários diretores, papéis pouco definidos e um jogo que a equipe foi descobrindo enquanto fazia. Hoje, segundo Hidemaro Fujibayashi, que divide com ele a produção do jogo, um projeto começa pelas ferramentas que deixam o processo eficiente. Quem herdou um sistema feito às pressas por uma equipe que já se foi conhece as duas pontas dessa história.
Para completar, os dois produtores ficaram de propósito um passo atrás e entregaram o trabalho a uma equipe mais jovem. A diretora de arte jogou o original pela primeira vez ao entrar no projeto.
Quatro decisões, e o que cada uma diz a quem refaz um sistema
Os fatos a seguir são da entrevista. A leitura para sistemas de empresa é da X-Apps, a empresa de software que escreve este blog.
Uma decisão foi de gestão. Fujibayashi pediu à equipe que definisse cedo, com clareza, o que mudar e o que deixar como estava. Num sistema de empresa, isso significa escrever a lista do que o usuário não aceita ver mudar antes da lista de novidades. Quase todo projeto começa pela segunda.
Outra foi sobre como construir. Um jeito comum de refazer um jogo é reaproveitar o código antigo e melhorar por cima. Como tinham passado 28 anos, a equipe refez tudo do zero: construía um recurso, comparava com o original e repetia, muitas vezes. Visto de fora, o jogo antigo serviu de especificação. Isso funcionou porque o original estava parado e inteiro, e tudo o que ele fazia podia ser conferido. Numa empresa, começar do zero só se sustenta com a mesma condição: um sistema antigo que dê para consultar, função por função.
A decisão sobre o pulo mostrou quanto custa uma mudança que parece pequena. No original, o personagem pulava sozinho, em lugares escolhidos pela equipe. A nova versão deixa pular em qualquer lugar. Aonuma explicou que o pulo automático também servia a quem desenvolvia, porque havia lugares onde a equipe preferia que ninguém pulasse. Sem essa trava, foi preciso prever todo tipo de comportamento e ajustar os cenários, e uma única mudança aumentou na hora o que precisava ser revisto.
Pense, como exemplo hipotético, em deixar o vendedor editar um pedido já aprovado. O pedido cabe numa linha. Só que cada pedido aprovado pode ter baixado estoque, gerado nota fiscal e seguido para outro sistema, e a regra antiga, a de que pedido aprovado não se edita, poupava a equipe de pensar em tudo isso. O tamanho de uma mudança se mede pelo que ela passa a permitir.
A dos atalhos foi desfeita. Jogando com eles, a equipe percebeu que perdia os momentos de descoberta de quem para no caminho porque algo chamou a atenção. Aonuma tinha autoridade para manter o próprio pedido e voltou atrás depois de usar o resultado. Num sistema, a etapa lenta que todos querem cortar pode ser desperdício ou pode ser a conferência que evita um erro caro. Quem distingue uma da outra é alguém que conhece a operação e usa a versão nova antes de a mudança virar regra.
A equipe ainda aproveitou para pagar uma dívida. Aonuma projetou, em 1998, uma fase que ficou conhecida pela dificuldade, em que o jogador perdia a noção de onde estava, e chamou o conserto de lição de casa atrasada. A correção foi na causa: ficou mais fácil trocar de item e enxergar as salas vizinhas.
Onde um jogo e um sistema de empresa se parecem, e onde não
Nos dois casos, o usuário conhece o produto de cor e nota qualquer diferença, e há comportamentos que ninguém documentou mas todo mundo espera. As diferenças pesam tanto quanto:
| Ponto | No jogo refeito | No sistema da empresa |
|---|---|---|
| O original | Parado desde o lançamento | Continua mudando enquanto o novo é feito |
| Uma etapa demorada | Pode ser parte do valor, como atravessar o mapa sem atalho | Quase sempre é custo para quem quer terminar a tarefa |
| Quem usa | Escolheu jogar | É obrigado a usar e reclama menos em público |
| Quem julga | Crítica e público, no lançamento | A operação, todo dia |
A primeira linha muda o projeto inteiro. Com o sistema antigo em movimento, quem refaz precisa escolher entre congelar as mudanças nele por um período ou conferir de novo cada função sempre que ele mudar. As duas saídas custam, e a escolha precisa estar no plano desde o começo.
Quando o original não tem manual: o aplicativo do Grupo GPS
A X-Apps nunca fez jogo. A ligação com essa história é de método. As equipes de campo do Grupo GPS usavam o GPSi, um aplicativo de checklists e inspeções que só existia no Android. Para levá-lo ao iPhone não havia o código-fonte nem documentação de como o aplicativo conversava com o servidor, e as regras do checklist variavam por área.
O aplicativo antigo virou a referência, como o jogo de 1998. A X-Apps rodou a versão do Android e anotou tudo o que ela pedia ao servidor, função por função. Esse trabalho se chama engenharia reversa: descobrir como um sistema funciona olhando ele funcionar. Das anotações saiu uma especificação escrita, que ficou com o Grupo GPS, e sobre ela foi construída a versão para iPhone.
A diferença em relação ao jogo é a da tabela: o Android ainda mudava durante o projeto, e a referência se mexia enquanto a versão nova era feita.
O aplicativo chegou à loja da Apple em setembro de 2018. A X-Apps entregou ao cliente o código, a especificação e a conta em que o aplicativo está publicado. O gerente de sistemas do grupo contou como a entrega foi recebida:
A qualidade da entrega do GPSi para iOS foi reconhecida em uma reunião com a nossa vice-presidência. Eles elogiaram bastante o desenvolvimento do aplicativo pela X-Apps e gostaram muito do resultado apresentado.
Antes de refazer o seu sistema
Leve estas perguntas a quem usa o sistema todo dia, e não só a quem o mantém:
- O que o usuário não aceita ver mudar? Escreva essa lista antes da lista de novidades.
- O sistema antigo vai mudar durante o projeto? Se vai, decida já se ele congela ou se cada mudança será conferida de novo.
- Que regra antiga poupa a equipe de pensar em muitos casos? Antes de tirá-la, conte quantos são.
- Quem vai usar a versão nova antes de a mudança virar regra? Precisa ser alguém que conhece a operação e pode voltar atrás.
- Que defeito todo usuário conhece e ninguém consertou? Refazer é a hora de corrigir a causa.
Antes de refazer um sistema, decida o que não pode mudar, e só confie na decisão depois de usar o resultado.
Fontes: entrevista Ask the Developer, volume 24, da Nintendo, parte 1, parte 2 e parte 3 (02/11/2026); nota do jogo original no Metacritic. Leitura em 14/11/2026.
