1. Introdução

Se você perguntar aos desenvolvedores de jogos sobre sua primeira experiência na criação de jogos, muitos falarão sobre o editor do jogo que eles jogaram. Na maioria das vezes, eles o acham pelo nome que chama a atenção como "editor".

Muito antes do advento do Unity 3D, empresas como a id Software, Epic, 3D Realms, Blizzard e BioWare lançavam ferramentas com seus jogos, esperando que isso permitisse às pessoas criar conteúdo, aumentando o tamanho da comunidade e a vida do jogo. Muitas pessoas não gostaram apenas de usar essas ferramentas - elas se tornaram as portas para a indústria de jogos. O conteúdo que eles criaram mais tarde se tornou parte de seu currículo.


Nos últimos anos, retrospectivas de jogos clássicos ganharam popularidade, mas quase nenhuma atenção é dada às ferramentas clássicas de construção de igrob. Nesta série de artigos, tentaremos preencher a lacuna: entrevistaremos pessoas importantes da indústria e solicitaremos que elas conversem sobre como essas ferramentas clássicas de jogos foram desenvolvidas.

Neste artigo, tive a honra de conversar com John Romero Romero sobre o TEd , o editor de blocos criado pela id Software, que ajudou a lançar 33 jogos.

Primeira reunião com o editor de níveis

David Lightbone : Olá, John. Obrigado por tomar um tempo para conversar comigo!

John Romero : Sem problemas!

DL : Antes de discutirmos o TEd, quero dar um passo atrás: no início dos anos 80, havia muito poucos editores de nível que vieram com o jogo. Na sua entrevista de Honrando o código , você disse que o gerador de terreno da Pegasus] [ foi um dos editores de primeiro nível com os quais você experimentou. Você pode falar sobre essa experiência?
JR : A primeira vez que vi Pegasus] [no Sierra College, no escritório da Apple. Este foi um dos primeiros programas que vi na Apple. Quando joguei, notei que havia uma opção para gerar terreno. Eu pensei: é ótimo que os desenvolvedores tenham construído uma ferramenta para gerar jogabilidade.

É engraçado pensar que esse foi um dos primeiros jogos a criar mods. Eu sou
a primeira vez que vi algo assim, e achei maravilhoso. É engraçado, mas nunca pensei: "Ei, por que não está em outros jogos?", Eu simplesmente não esperava isso dos jogos!

TEd, Editor de blocos

JL : Ok, vamos falar sobre TEd.

[Enquanto conversávamos, lancei dois DOSBox para assistir ao TEd e ao Deluxe Paint]



A primeira coisa que quero falar é sobre o protetor de tela TEd. Diz Deluxe Paint for Tile Maps. Quem conhece um pouco da história da id Software sabe que Adrian Carmack usou o Deluxe Paint ...

JR : Foi usado por toda a indústria de jogos.

JL : Exatamente! Então, a primeira coisa que me chamou a atenção foi que os menus principais do Deluxe Paint e TEd são muito semelhantes, tanto na aparência quanto no sentimento. Você já tentou familiarizar os usuários com o Deluxe Paint ou usou algumas peças retiradas do Deluxe Paint?

JR : Antes da id Software, escrevi várias ferramentas para PC no SoftDisk. Eu escrevi o Pixel Puzzle Maker , uma ferramenta de quebra-cabeça do Softdisk chamada Pixel Puzzler. Eu escrevi um menu suspenso para o criador do Pixel Puzzle e, em seguida, fiz algumas alterações. Parece que eu escrevi outras ferramentas para PC no Softdisk, e quando eu estava trabalhando no id, parece que eu criei outro, porque era muito fácil criar esse sistema com um menu suspenso.

Não foi baseado no Deluxe Paint, porque eu nunca havia usado o Deluxe Paint, mas achei muito mais fácil trabalhar com o menu suspenso do que com um monte de teclas de atalho ... embora também tivéssemos muitas teclas de atalho!



DL : Falando em atalhos de teclado: notei outras semelhanças. Hoje estamos acostumados ao fato de que Control-Z é um cancelamento de uma ação, mas naqueles dias, pelo menos no caso de Deluxe Paint e TEd, o cancelamento era realizado pressionando a tecla "U".

JR : [risos] Uau. Eu inventei isso?

JL : Sim! Aqui, olha, eu preenchi os quadrados, cliquei em "U" e cancelei ...

[Desenho algumas peças e, em seguida, pressione “U” para desfazer a ação anterior]

JR : [risos] Fofo.

Ah, e a propósito, você o lançou no DOSBox, e se você rolar a tela, será muito lento em comparação com o modo de funcionamento do 386 naqueles dias. O programa acabou de voar.

JL : Sério? Não brinque?

JR : Por alguma razão, o DOSBox diminui bastante a velocidade. A rolagem EGA usa o modo Trava, que na época era muito rápido, você só precisava tocar nas teclas, caso contrário, percorreria tudo. Então agora você vê uma versão estranha e muito lenta.

[Nota do autor: John falou sobre a rolagem EGA usando o modo Latch no StackExchange: http://gamedev.stackexchange.com/questions/6488/how-did-they-make-the-screen-move-in-dangerous-dave ]

DL : Ok, então você disse que o TEd tinha muitas teclas de atalho. Ao usar o TEd, você frequentemente precisava ler um arquivo de ajuda para entender como usar essas ferramentas.

JR : Sim, claro. Acho que alguns ainda se lembram do WordStar, que era apenas um bando de pesadelos de teclas de atalho.

JL : [risos]

JR : Naquela época, tocávamos Ultima, e Ultima usava todas as letras do teclado, então era fácil lembrar coisas assim.




[Nota do autor: desenterrei o manual Ultima 1 e John mostrou estar completamente certo ... uma ação foi anexada a quase todas as teclas do teclado!]

JL : Isso é certo! Portanto, nessa fase do desenvolvimento da indústria de jogos, quando se tratava de design de nível, era necessário pegar uma folha de papel milimetrado e colocar ladrilhos e inseri-los no computador.

JR : Sim.



[Nota do autor: após esta entrevista, John me enviou um gráfico em um gráfico para o jogo Mach Six que ele criou. Você também pode ler um artigo do Gamasutra sobre como a Nintendo usou papel milimétrico para desenvolver os primeiros níveis de Zelda no NES]

JL : Então, em que momento a id Software decidiu que a TEd precisava ser criada?

JR : Quando trabalhei no Dangerous Dave em 1988, precisava criar níveis para ele, e pensei: "Por que não usar o jogo em si e deixá-lo criar níveis que podem ser salvos". Foi exatamente o que fiz com o Dangerous Dave.

Quando John Carmack viu isso - e ele trabalhou para o Apple II - ele ficou muito impressionado porque estava acostumado a usar texto para indicar gráficos. Quando decidimos criar algo juntos, escrevi o TEd 1.0 e, alguns meses depois, ele evoluiu para o TEd 5.0, que foi usado para desenvolver 33 jogos lançados.



DL : Uau ... Quando você fala sobre 33 jogos lançados, você quer dizer não apenas os projetos de identificação criados, por exemplo, as séries Commander Keen e Wolfenstein, mas também os externos, por exemplo, Rise of the Triad?

JR : Claro! Mais Corredor 7 e jogos para Gamer's Edge: Shadow Knights, Slordax, Dave Perigoso e a Mansão Assombrada, Rescue Rover 1 e 2, BioMenace ... um monte de jogos!

DL : Então, é verdade que o TEd não foi usado apenas com vista lateral para criar roletes laterais bidimensionais, mas também com uma vista superior para criar atiradores tridimensionais em primeira pessoa?

JR : Exatamente. Foi no TEd 5.0 que todos esses jogos foram criados.



JL : Bom. Estou interessado no seguinte: em algum momento, você e o pessoal da id Software decidiram mudar de jogos bidimensionais para tridimensionais. Você discutiu a idéia de criar um novo editor em vez de TEd?

JR : Sim, resolvemos rapidamente esse problema. Pensamos: “Uma matriz 2D será usada para representar o nível. Ótimo, apenas aplicamos TEd para isso. ” Sim é isso! [risos] Foi muito simples.

JL : Gostaria de fazer mais uma pergunta: Tom Hall cita você no arquivo de ajuda de Rise of the Triad: “Mais cedo ou mais tarde, o programador consegue escrever do que pode se orgulhar - um procedimento espirituoso, elegante e rápido como um raio, que se torna o padrão para código de outros programadores. No entanto, isso não se aplica ao procedimento de preenchimento de TEd. Esse algoritmo lento e burro preenche um plano de dados de uma maneira dolorosamente lenta. Pressione ESC quando congelar. ”

JR : [risos]



JL : [risos] Então, por que você escreveu assim? Esse procedimento de preenchimento tem algum histórico?

JR : Houve vários erros no procedimento de preenchimento. Não gastei muito tempo escrevendo e, mais ou menos , funcionou, mas às vezes não preenchia completamente, por isso tive que clicar manualmente para preencher todas as áreas. Foi fácil de usar.

[Enquanto conversávamos, iniciei o procedimento de preenchimento de preenchimento de inundação e TEd colidiu com o DOSBox com o erro "Dividir por zero"]

JR : [risos]

JL : [risos] Absolutamente! Isso é engraçado, porque eu brinquei um pouco com o editor antes da entrevista e pensei: "Não entendo por que ele disse isso, tudo funciona bem para mim!"

JR : [risos] Bem, ele nunca nos deu o erro de divisão por zero também ... Acho que o problema é que você não selecionou um ladrilho. O programa cai quando você tenta preencher sem um bloco.

[Reiniciei o TEd, que exibia a caixa de diálogo de configuração gráfica]



Veja esta janela de configuração gráfica? TEd permite editar cartões em CGA, EGA e VGA. Ele move todos os dados gráficos para a memória XMS, para que possam ser recuperados do XMS ao alternar os modos gráficos. Ou seja, se o seu jogo suportar todos os três modos gráficos, ele permitirá que você carregue esses blocos. Você pode carregar blocos VGA para que, ao alternar para o modo VGA, todos eles carreguem e residam na memória.

JL : Sim, eu li que era revolucionário o suficiente para aquela época.

JR : Sim. Eu também percebi essa possibilidade: se o cursor estiver em algum lugar do nível, você poderá pressionar Alt-L, após o qual o jogo será carregado e você estará exatamente naquele lugar do nível. Vamos verificar se isso funciona.

[Movo o cursor para o nível e pressione Alt-L. Mensagem de erro aparece]

JL : [risos] E eu também queria falar sobre isso com você ...

JR : [risos]


DL : Quando experimentei o TEd, tirei uma captura de tela desse erro porque queria perguntar sobre isso. Você não verá essas mensagens hoje no Photoshop ou no Maya ... [risos]

JR : Claro, claro! Essa ferramenta foi escrita apenas para mim e Tom [Hall].

JL : Claro! Eu queria perguntar sobre isso: você escreveu esta mensagem de erro especificamente para Tom?

JR : Claro! Foi apenas para Tom. Eu nunca cometeria esse erro. (risos)

JL : [risos] Imagine sua primeira reação.

JR : Ah, sim, ele começou a rir.

[Então, John me mostrou que você precisa adicionar o nome do executável do jogo após o executável TEd para que o editor saiba o que executar quando pressionar Alt-L]

JL : Uau, funcionou!

JR : Sim, mas você se mudou para o início do jogo. Acho que aconteceu que você está usando a versão de lançamento do jogo, que ignora esse parâmetro de linha de comando. A versão comercial não permite isso, caso contrário os jogadores trapaceariam!

JL : Sim, isso é bastante lógico. Mas parece-me que trapacear é um dos aspectos que atrai as pessoas ao desenvolvimento de jogos. Você sabe, eu quero poder mudar de nível para tirar sarro de amigos ...

JR : Sim, claro! (risos)

O futuro das ferramentas de desenvolvimento

JL : Gostaria de terminar a discussão com uma discussão sobre o futuro das ferramentas de desenvolvimento de jogos.

No início dos anos 90, quando eu comecei a criar jogos usando ferramentas escritas por você e outros desenvolvedores, nem sempre era fácil: eu precisava ler o arquivo de ajuda (se ele existisse). Uma certa quantidade de conhecimento técnico era necessária e, muitas vezes, era necessário estudar os scripts ou a programação mais simples. No entanto, ao mesmo tempo, era possível desenhar algum tipo de pixel art de 8 bits e pareceria quase digno. Também poderíamos personalizar de maneira flexível a aparência dos níveis, como desejarmos.

Hoje existem ferramentas como o SnapMap (o editor dos novos níveis de Doom) que são muito mais acessíveis a todos, mas têm muito menos flexibilidade. Há scripts visuais, ou seja, os usuários não precisam aprender scripts ou programação. Ao mesmo tempo, criar recursos de jogo com aparência decente para a maioria das pessoas é uma tarefa inatingível.

Minha pergunta para você é a seguinte: você acha que algumas dessas ferramentas modernas não fornecem flexibilidade suficiente às pessoas que estão entrando na indústria ou você acha que isso é apenas uma evolução do desenvolvimento de jogos - exatamente o mesmo que a transição da linguagem assembly para os compiladores - e isso é apenas nossa indústria avançando?



JR : Este é um desenvolvimento natural. A equipe de desenvolvimento do SnapMap é formada por pessoas cuja carreira começou jogando Doom e usando TEd. A empresa que incorporou a id Software chamava-se Escalation Studios . Ela fez a Ressurreição da Perdição. Conheço essas pessoas há mais de vinte anos. Eles são jogadores muito hardcore, passaram por Doom World e depois por Quake World. Eles estão na empresa desde o momento em que fizemos o Doom. São pessoas cuja vida se dedica à criação de níveis há muitos anos.

Ou seja, o SnapMap é uma evolução natural das ferramentas que as pessoas precisam, não do console. Obviamente, eles não se contentaram com o SnapMap, mas o SnapMap é uma ótima maneira de as pessoas que nunca fizeram design de níveis entenderem se gostam dessa atividade e, nesse caso, podem encontrar ferramentas mais poderosas para si mesmas. Talvez não nesta versão do Doom, mas, por exemplo, no mecanismo Source ou em qualquer outro mecanismo, dos quais existem muitos agora, como o Unreal. Portanto, o SnapMap lhes dará uma idéia do que é.

JL : Sim, isso parece lógico. Ou seja, isso não é um substituto, é o primeiro passo no caminho para o desenvolvimento.

JR : Exatamente, porque a parte mais difícil é criar fragmentos do SnapMap. Portanto, se as pessoas puderem fazer isso na versão PC do Doom, elas imaginarão qual é o design de nível real, pelo menos no exemplo desses fragmentos modulares.

O conselho de John para programadores de ferramentas

DL : Na minha última pergunta, quero voltar para onde começamos: retrospectivas de jogos clássicos.

Às vezes, nos jogos, existem truques e truques que, com o tempo, acabam se perdendo. Eu acho que a coisa mais interessante sobre as retrospectivas dos jogos clássicos da GDC é que as pessoas recuperam o conhecimento perdido. Pessoas como você que estão no setor há muito tempo podem passar essas informações para pessoas que estão entrando no setor.

Então, que conselho você daria aos desenvolvedores de ferramentas modernas?

JR : Primeiro, você precisa escrever uma ferramenta para o usuário desta ferramenta. Por exemplo, se um designer de níveis usar sua ferramenta, é para ele que você faz essa ferramenta. Torne o mais simples possível e adicione o maior número possível de recursos. Também é importante reservar um tempo para tentar usar a ferramenta e entender o que a incomoda nela.

JL : Absolutamente.

JR : Além disso, muitas vezes, quando os designers pedem para adicionar alguns recursos, os programadores de ferramentas não dão passos em direção a eles e não perguntam: “Por que você precisa dessa oportunidade? O que você deseja alcançar com isso? ” Podemos agrupar a funcionalidade em um invólucro conveniente, para facilitar o trabalho. Às vezes, os desenvolvedores jogam componentes ... e é isso, adeus, designers de níveis, descubra por si mesmo!

JL : Certo! (risos)

JR : Também é ótimo quando programadores e usuários de ferramentas estão na mesma sala e a ferramenta é criada com o máximo de comunicação possível entre as duas equipes.

JL : Eu concordo.

JR : Finalmente, você não precisa escrever nada no assembler. [risos] Quero dizer, é muito difícil fornecer suporte para uma ferramenta escrita há dez anos usando linguagens ou funções fortemente associadas à plataforma. Procure abstrair a funcionalidade para poder substituí-la no futuro. Eu mesmo tive esse problema com o TEd, quando em 2001 eu precisava de um editor de blocos para criar níveis para um novo jogo. Eu olhei para o código TEd 5.0, escrito em 1991, e pensei: "Bem, eu não vou usar esse código para nada ..." [risos]

JL : [risos]

JR : Não esqueça que as ferramentas duram mais que os jogos.

JL : Esse é um ótimo conselho. Muito obrigado, eu realmente aprecio o fato de você ter tido tempo para conversar comigo.

JR : Obrigado!