Rogue, caos e o legado Roguelike

Jogos, Limitações Técnicas e a Teoria do Caos

Caos, além de uma área de estudos da matemática, é um adjetivo que se relaciona ao conceito de desordem ou incompreensão. Foi o adjetivo perfeito para o ano de 1980.

Os jogos eletrônicos existiam há não muito tempo, mas mesmo sem nenhum estudo adequado, já estavam sendo relacionados à delinquência juvenil. 

O desaparecimento de um estudante universitário de 16 anos, que tinha o hábito de jogar Dungeons & Dragons, foram ambos, jogo e desaparecimento, relacionados a práticas de “cultos satânicos”. E o caso dos assassinatos em série em Nova York, atribuídos aos Sons of Sam (filhos de Sam), que ocorreram em 1977, contribuiu para a situação caótica, pois também foram relacionados aos referidos cultos, com notícias infladas pela mídia. Não demorou para alguém fazer uma relação espúria ao Dungeons & Dragons.

Dungeons & Dragons inaugura um estilo de jogo em 1974, em que o jogador assume um papel atuante, como no teatro, mediado por um narrador e situando-se em um mundo de alta fantasia. Até hoje é mal compreendido e não muito bem aceito na sociedade em geral, embora a não aceitação  esteja diminuindo. Apresentaremos uma série especial para jogos de RPG, incluindo Dungeons & Dragons. em breve.

E a sociedade, numa frenética busca por culpados, estava comprando o que estava posto. Os jogos modernos, inclusive os eletrônicos, estavam em baixa. Restava um refúgio, um local que ainda hoje tem um certo ar de mistério para a sociedade em geral: As Universidades.

As universidades ainda possuíam algum prestígio na exploração de jogos, bem como na prática deles. A sociedade em geral, ainda hoje, concede uma certa liberdade no universo da academia e isso promove as inovações que a própria sociedade se beneficia, inclusive em jogos eletrônicos. Colossal Cave Adventure, ou apenas Adventure, como ficou bastante conhecido, inaugurou um novo tipo de jogo, em que um conjunto de cenários relacionados, cada cenário provendo um conjunto de escolhas para o jogador decidir, levava sempre a resultados diferentes. Os cenários eram apresentados de forma descritiva ao jogador, que após ler a descrição, tinha um conjunto de comandos para informar ao computador.

Diversos jogos nesse estilo, que foi denominado de adventure pela indústria, foram produzidos. Cada um com temas variados, desde alta fantasia à ficção científica. Inclusive um que se passa na floresta amazônica, projetado e desenvolvido pelo brasileiro Renato Degiovani.

E para te situar no cenário da época, 1980 foi o ano em que o jogo Pac Man foi lançado, e era considerado revolucionário em termos gráficos e de jogabilidade.

Um encontro fortuito

Em 1980, no campus de Santa Mônica da Universidade da Califórnia, Michael Toy ingressa no curso de Ciência da Computação, interesse que surgiu devido a ele conseguir experimentar alguns jogos quando visitava seu pai no trabalho. Esse foi o gatilho para que ele quisesse aprender a programar computadores, um gatilho que certamente muitos aqui irão se identificar.

Toy conhece um outro estudante, Glenn Witchman, que ingressa na faculdade com o interesse específico em se tornar um projetista de jogos de tabuleiro. A amizade é instantânea. Um com interesse nos resultados que o jogo pode proporcionar; outro com interesse nos processos de orquestração e mecânica do jogo. Eles são o John Romero e o John Carmack originais, ou melhor, Romero e Carmack são uma cópia de Witchman e Toy.

Ambos passaram a dividir o alojamento e viviam se desafiando em suas habilidades. Watchman como designer de jogos e Toy como programador. Watchman buscava algo que pudesse prover um resultado afetivo similar ao Dungeons and Dragons, enquanto que Toy queria criar algo inovador. Mas as máquinas na época eram limitadas. Apenas imprimiam texto e, ainda assim, não era possível formatar os textos ou colocar os caracteres onde se desejava na tela.

Para se construir mapas ou salas era necessário um arquivo por sala. Isso tornava o tamanho do jogo um tanto quanto grande. Lembre-se, estamos falando de 1980, um tempo em que as memórias dos computadores eram contadas em Kilobytes e raramente ultrapassavam 16 Kilobytes! 

A tecnologia era essencialmente limitada e a única forma de quebrar essa limitação era por meio de estudos e experimentações em busca de inovações nos horários livres, pois o uso dos computadores era estritamente regulamentado. Raramente uma pessoa ficava mais de 2 horas por dia no computador, às vezes eram 2 horas por semana. Computadores não eram dispositivos que estavam em todos os lugares, como hoje. Uma universidade inteira possuía poucas máquinas. E todas ficavam no laboratório de computação. Sim, apenas um laboratório de computação.

A tecnologia chave

Foi em 1980 que Ken Arnold, que não tem parentesco com Kevin Arnold, do seriado Anos Incríveis, criou um conjunto de rotinas de programação que permitia ao programador colocar caracteres, ou começar o texto, em qualquer lugar da tela, um recurso que hoje é presente em toda linguagem de programação.

O uso projetado para a Curses, o nome dado ao conjunto de rotina programada por Ken Arnold, era estritamente comercial, mas Toy, ironicamente, gostava de brincar.

Como já mencionei, Toy e Witchman queriam fazer um jogo de aventura, como o Dungeons & Dragons, mas o aspecto estático dos jogos estilo Adventure não ofereciam um atrativo, pois uma vez que se conhece os aspectos desse estilo de jogo, o apelo para jogá-lo novamente diminui bastante. Eles queriam fazer algo diferente e já tinham uma ideia.

O local de aventura foi denominado de Dungeon of Doom, algo como Masmorra do Destino, Masmorra da Destruição ou Masmorra do Apocalipse, sendo que há o boato de que é nela que se encontra o lendário Amuleto de Yendor, um objeto que garante fama, fortuna, poder e felicidade suprema ao portador. O nome do jogo foi dado por Witchman, que o batizou de Rogue, algo como ‘solitário’, pois ao contrário dos jogos de Dungeons & Dragons, em que o jogador faz parte de uma equipe, em Rogue o personagem atua sozinho.

Tudo estava perfeito, não fosse um obstáculo: a limitação tecnológica.

Uma Ordem no Caos… ou um Caos na Ordem?

Com a limitação da tecnologia, entregar o que os projetistas almejavam era uma tarefa difícil. A Curses já dava uma ajuda, mas ainda não era possível montar salas, colocar inimigos e recompensas e ainda havia o código que ditava como o jogo funciona, com as rotinas de interação com o usuário, pois esse também ocupa espaço na memória do computador. Toy tinha que buscar inspiração em outro lugar e esse outro lugar era a área relacionada à computação: a Matemática e sua teoria do caos.

A ideia foi utilizar um conjunto de rotinas para gerar as salas de modo aleatório, utilizando algumas mecânicas conhecidas da teoria do caos. Mas utilizar essas técnicas, de forma pura, muitas vezes fornecia resultados indesejados, como escadas que levam a uma parede ou salas sem acesso. A solução foi simples, apesar de demorada: Toy decidiu usar uma matriz 3×3, como no jogo da velha, para decidir onde as salas iriam se situar, qual seria o formato delas, regras para que não se sobrepusessem e então, construir as ligações entre elas. E, considerando o caráter pseudo-aleatório das rotinas nos computadores, ele poderia, se quiser, gerar a mesma configuração novamente. Futuramente, isso deu espaço a outras possibilidades.

Então, com as masmorras já sendo criadas, colocar os outros elementos não foi trabalhoso. Inimigos com níveis de dificuldade de acordo com o nível da masmorra, alcançado por usar as “escadas”, foi outra inovação, pois também permite uma progressão procedimental e projetar um mecanismo de batalha inspirado nas regras do Dungeons & Dragons, com suas regras já conhecidas, não apresentou dificuldade.

Além disso, eles implementaram o conceito de desconhecimento de pergaminhos e objetos. Isso significa que se você encontra algo que você não sabe o que é, o nome do objeto ou do pergaminho é apresentado de forma cifrada até que você use uma magia de “reconhecer objeto”, o que torna conhecidas todas as propriedades do objeto ou pergaminho, inclusive o nome real.

A morte como desafio

Um problema que a dupla encontrou durante os testes de jogo foi a previsibilidade. Devido à forma que a geração das masmorras e alocação de itens se dava, o mesmo conjunto de comandos sempre te levava aos mesmos lugares, ou seja, era um mundo completamente determinístico, em que tudo ocorria de forma igual, dadas as mesmas entradas, em todas as execuções. A única exceção eram os resultados das batalhas. Isso tornava o jogo entediante após algumas partidas.

Considerando a já mencionada pseudoaleatoriedade dos equipamentos digitais, que são obtidas a partir de um número inteiro chamado de ‘semente’, Toy e Witchman resolveram esse problema de forma engenhosa. A cada nova partida esse número era selecionado de forma aleatória, segundo o relógio do computador. Então, veio a decisão fatal, a morte permanente.

Ao contrário dos jogos como conhecemos hoje, como os da série Zelda ou Final Fantasy, em que podemos gravar um momento para retornar a ele em caso de falha posterior, Rogue permitia gravar o estado do jogo para continuar do mesmo ponto em um momento posterior, mas não para retornar a ele em caso de falha. A dupla implementou uma rotina para, caso o personagem do jogador morra, o sistema automaticamente apaga a sessão de jogo gravada, obrigando o jogador a iniciar uma nova partida do jogo, que será diferente da partida anterior.

Essa solução, conhecida como permadeath, ou morte permanente, em português, foi a responsável por tornar o jogo popular, além de favorecer a emergência narrativa do jogo. Witchman preferiu chamá-la de ‘persistência de consequência’, mas não teve o mesmo impacto.

Ei-lo: Rogue

Para gerar maior engajamento, ou seja, atrair a atenção de jogadores e manter essa atenção, foi implementado um sistema de pontuação e pontuação máxima no jogo. Assim, jogadores se sentiam compelidos a superar seu próprio recorde ou a superar o recorde máximo.

Rogue teve maior sucesso no ambiente universitário, pois era jogado via modem. Dennis Ritchie, um dos inventores da linguagem de programação C, ficou impressionado com o jogo, mas não tanto na forma como a tela era desenhada. E isso era: linha a linha, como em uma impressora.

Toy se dedicou tanto à sua criação que suas notas na universidade despencaram, fazendo-o ser expulso da instituição em 1982. Mas seu empenho em aprender programação para o jogo o garantiu uma vaga no laboratório de computação do campus de Berkeley, da Universidade da Califórnia (UCB), onde ele conheceu o próprio Ken Arnold, que se juntou à equipe para melhorar a forma como os ‘gráficos’ do jogo eram gerados.

Além disso, foi nesse mesmo laboratório que produziram um sistema operacional estilo Unix chamado BSD, o qual permitiu que o executável do jogo fosse incluído junto com o sistema, tornando sua distribuição e consumo mais amplos.

Rogue é implementada para PC apenas em 1984, ano em que Toy sai dos laboratórios de Berkeley para trabalhar como consultor na empresa Olivetti, que estava projetando um computador compatível com o IBM-PC para comercializar. Lá ele conhece Jon Lane, um dos administradores de sistemas da Olivetti.

Lane já conhecia o jogo e sugeriu que ambos montassem uma empresa para comercializá-los no PC. Surge então a ‘A.I. Design’, que licencia o jogo via Epyx, empresa que publicava jogos na época, conquistando, então, os lares em boa parte dos EUA.

Após o contrato com a Epyx, diversas versões de Rogue surgiram para outros tipos de computadores, inclusive aproveitando recursos gráficos para melhorar o apelo visual do jogo. Todos distribuídos pela Epyx.

O Computador como Jogador: Rogue-o-Matic

Rogue tinha uma interface simples. Os comandos eram os de navegação, além de algumas teclas de uso específico, como mostrar o inventário ou usar equipamentos, poções, chaves ou pergaminhos. Além disso, a tela ‘gráfica’ com elementos de texto favorecia o desenvolvimento de sistemas que pudessem interpretar o estado atual do jogo.

Interfaces simples, a possibilidade de interpretar o estado atual do jogo, faltava apenas um mecanismo de decisão para que o próprio computador pudesse jogar Rogue. Esse foi o desafio de quatro estudantes do departamento de Ciência da Computação da Universidade Carneghie-Mellon de Pittsburgh: criar o Rogue-o-Matic, um sistema que joga adequadamente de modo a tentar vencer o jogo, ou seja, encontrar o Amuleto de Yendor e retornar à superfície.

Rogue-o-Matic foi apresentado inicialmente em 1981, antes de Michael Toy trabalhar nos laboratórios da UCB. Em 1983 o Rogue-o-Matic tinha a melhor pontuação mediana, maior que os 15 melhores colocados, inclusive conseguindo vencer o jogo.

Ken Arnold decidiu, como objetivo pessoal, melhorar o jogo para evitar que Rogue-o-Matic pudesse jogá-lo. Surge um dos primeiros embates mentais mediados por computador. A cada versão de Rogue, Rogue-o-Matic deixava de funcionar, obrigando a equipe da Universidade Carneghie-Mellon a trabalhar em uma nova versão e provendo mais um desafio para Arnold trabalhar em uma nova versão.

Rogue-o-Matic diferencia-se dos denominados ‘sistemas especialistas’ da época, pois aqueles eram sistemas que tomavam decisões baseadas em um conjunto estático de regras, enquanto que Rogue-o-Matic inovou esse processo por trabalhar em um contexto dinâmico.

O legado de Rogue

Geração procedimental de fases, morte permanente e dificuldade progressiva procedimental são os três maiores elementos que Rogue forneceu para a área de projeto de jogos. Um jogo que utiliza adequadamente esses elementos ganha o privilégio de ser categorizado como roguelike, algo como: jogo no estilo do Rogue.

E não são poucos os jogos que ganharam esse privilégio. Dentre eles podemos citar jogos como os da série Diablo, inclusive, Rogue foi o jogo inspirador para Diablo, além de jogos recentes, como Torchlight, Don’t Starve, Spelunky,  FTL, que já foi abordado em nossa produção Gamegesis Dixit, além de muitos outros.

E além disso, a solução de geração procedimental de fases foi o diferencial para que a elaboração de jogos complexos se tornassem possível para a época, permitindo, por exemplo, que Elite, um jogo de simulação de combate espacial com gráficos 3D, pudesse apresentar um sistema com 8 galáxias contido em apenas 22KB de memória!

Rogue atualmente

Poucas são as diferenças de Rogue para os jogos atuais. Os gráficos configuram a diferença mais gritante, mas a jogabilidade não difere de jogos como Final Fantasy, por exemplo. Ou seja, com exceção dos gráficos e animações, como em Diablo 3, além das trilhas sonoras e efeitos sonoros, experimentamos Rogue até hoje.

Rogue peca unicamente por resolver os combates de forma aleatória, ou seja, apesar de usar o nível de habilidade do personagem, não do jogador, como elemento de influência, o resultado dos combates ainda é todo derivado da sorte. Mas, para a época, não havia como ser de outra forma. Jogos da série Don’t Starve, ou o jogo Spelunky, resolveram esse problema, mas essa é uma conversa para outra publicação.

Rogue está disponível na Steam, para computadores Mac ou PC, com Windows ou Linux. Que tal experimentar? Será que você tem o que é preciso para recuperar o lendário Amuleto de Yendor das Masmorras da Destruição?

De acordo com as ferramentas de análise da Gamegesis, Rogue implementa um elemento inovador na mecânica do jogo, com uma produção inédita a cada partida e utiliza elementos adequados de persuasão, como a permadeath e a pontuação, focando-se em elementos estéticos que até hoje se fazem presentes no imaginário popular. E mesmo que seus gráficos sejam rudimentares, é certo que você irá se divertir jogando Rogue.

Fontes:

1. Instruções sobre Rogue distribuída com o BSD Unix: https://docs.freebsd.org/44doc/usd/30.rogue/paper.pdf
2. Página pessoal de Glen Witchman (Internet Archive): https://web.archive.org/web/20150217024917/http://www.wichman.org/roguehistory.html
3. The History of Rogue – Gamasutra: https://www.gamasutra.com/view/feature/4013/the_history_of_rogue_have__you_.php
4. Rogue-o-Matic: https://www.cs.princeton.edu/~appel/papers/rogomatic.html
5. @Play – Exploring Roguelike Games by John Harris. Press Start Press, 2016. ISBN 978-0-692-50186-3.