Você está na página 1de 300

Machine Translated by Google

276 Capítulo 14: Entrevista: Chris Crawford

“fazer” e “comer” e “ter” e descobri que é maior. Porque essa palavra é um imperialista semântico,
ela vai para todo lugar. Pode ser usado para muitos, muitos significados diferentes, todos
completamente diferentes. Mas então há uma espécie de switcheroo que acontece. Você pode
aplicar a palavra “jogo” a um monte de produtos e atividades, mas assim que as pessoas o associam
a um computador, elas dizem “jogo de computador!” e todo o significado semântico desmorona até
este pequeno ponto. Talvez eu devesse chamar isso de jogo da web, colocar a coisa toda na web.
Ou se eu fizer isso no Mac talvez eu possa chamar de iGame. Mas não ouso chamar isso de jogo
de computador ou videogame.

Por que você acha que as expressões faciais são tão importantes para contar histórias?
Porque a expressão facial é uma das
formas fundamentais de comunicação
humana. É engraçado; outras pessoas
pensam em gráficos onde eu estou
pensando em comunicação. O que
acontece entre o usuário e o
computador é principalmente uma
questão de comunicação. Estou
profundamente desejoso de otimizar
essa comunicação. Isso significa
projetar a tela do computador para
corresponder mais de perto aos
poderes receptivos da mente humana.
E as duas coisas em que somos muito
O mundo da história da Reunião Corporativa no Erasmatron
bons são o reconhecimento facial e a
compreensão linguística. Assim, essas são as duas coisas que os computadores devem enfatizar.
Os jogos de computador não têm nenhum dos dois e isso me apavora. A expressão facial e a
compreensão linguística são, por enquanto, as duas áreas de desenvolvimento mais importantes.
Hoje em dia você pode obter excelentes modelos faciais 3D, embora as expressões neles ainda
sejam ruins. Isso ocorre em grande parte porque as pessoas que os projetam não são artistas, são
engenheiros e criaram essas cabeças anatomicamente corretas. Todo cartunista do mundo sabe
que você nunca desenha um rosto do jeito que realmente é. Para esse tipo de coisa, temos que usar
rostos de desenho animado e não rostos reais.

Quando eu estava jogando com o Erasmaganza, às vezes ele me apresentava três ações
diferentes para escolher, e eu não queria fazer nenhuma delas. Dessa forma, parece um antigo
jogo de aventura com uma árvore de diálogo ramificada. Você vê isso como um problema?

A verdadeira questão não é “Puxa, você só consegue três coisas”. A verdadeira questão aqui é que
você não tem permissão para dizer coisas dramaticamente razoáveis, e isso é uma falha no design
do mundo da história. Ambos os mundos de histórias de demonstração têm esse problema, porque
são mundos de histórias muito pequenos. Se você quiser fugir disso, você deve ter um mundo de
histórias muito maior. “Brawl” tem cerca de cinquenta ou sessenta verbos e “Meeting” tem cerca de cem.
Eu costumava pensar que quinhentos verbos eram o limite para o valor do entretenimento. Agora
acho que é mais como mil verbos. Mas “Reunião” simplesmente não oferece muitas opções porque
é muito pequeno.
Machine Translated by Google

Capítulo 14: Entrevista: Chris Crawford 277

Quanto a saber se o usuário ficará satisfeito com o número finito de opções que ele oferece,
não vejo nenhum problema nisso. Certamente você não tem permissão para nuances em tal
arranjo. Mas você deve ter todas as opções dramaticamente razoáveis. Além disso, se lhe dermos
algum sistema onde você possa aplicar nuances para poder dizer: “Vou dizer isso com um tom de
voz levemente sarcástico”, as infra-estruturas para isso seriam medonhas. Isso tornaria o jogo
muito tedioso. Então eu sinto que a única maneira de fazer isso de forma eficaz é confiná-lo a uma
estrutura de menu. De fato, existem alguns jogos que implementaram a nuance como sua principal
modalidade de interação. Nesses jogos você está interagindo com alguém e você tem esses
controles deslizantes: um é para força, um é para humor e outro é para charme. Mas isso é tudo
que você ganha. Você responde a alguém com tanta força, tanto charme e tanto humor. Estou
tentado há algum tempo a construir algo assim no Erasmatron. Mas o problema é, primeiro, chegar
a alguma generalidade e, segundo, manter a interface limpa e utilizável. Agora, com o menu
simples, você precisa apenas olhar, ver e pressionar. Acho que isso é importante para um meio de
comunicação de massa. Os controles deslizantes de tom são para aficionados por jogos.

O sistema que o Siboot usa para construir frases com ícones e o analisador inverso é
interessante. Por que você optou por não usar um sistema como esse para o Erasmatron?

Porque o grande número de


sentenças em Siboot são
autocompletas. No Siboot, você
poderia clicar em apenas um ícone e
muitas vezes o resto da frase se
preencheria porque essa é a única
opção disponível. A maneira de fazer
isso hoje em dia, aliás, é com menus
pop-up. Eu poderia fazer isso com o
Erasmatron. Por exemplo, suponha
que você tenha um item de menu
convencional que dissesse: “Vou lhe
dar meu cavalo em troca daquela Confiança e Traição: O Legado da Siboot
arma de seis canhões”. As palavras
“cavalo” e “seis armas” podem estar em menus pop-up fornecendo outras opções para o comércio.
Isso exigiria alguma expansão do sistema Erasmatron, mas nada muito sério. A única razão pela
qual ainda não fiz isso é minha falta de vontade de adicionar complexidade. Acredito que o sistema
tem toda a complexidade que precisa e mais um pouco. É sempre fácil adicionar complexidade ao
design, mas estou pensando em termos de simplificação.

Você já teve a chance de jogar The Sims? Parece que muita gente consegue usar aquele
jogo como uma espécie de ferramenta para contar histórias interativas.
The Sims não é uma tentativa de produzir narrativas interativas. Recebi alguns e-mails com Will
Wright sobre The Sims, e ele reconhece que não é uma plataforma interativa de contar histórias,
mas ressaltou que muitas pessoas a utilizam dessa forma. The Sims é exatamente o que
Machine Translated by Google

278 Capítulo 14: Entrevista: Chris Crawford

afirma ser — uma simulação, não um drama. Nenhum drama simula o mundo real. Na peça de
Shakespeare, no meio do discurso de Henrique V aos soldados em Agincourt, ele não diz: “Só um
minuto, pessoal, preciso fazer xixi”. No entanto, no The Sims, ele faz.
Uma vez, quando eu estava jogando The Sims, uma garotinha não conseguia dormir porque havia
fantasmas vindo e assustando-a. Os fantasmas são um toque muito agradável, a propósito. Eles a
mantiveram acordada a noite toda, e ela vagou por toda parte até adormecer, porque um sim que
fica muito tempo acordado é dominado pela sonolência. Ela adormeceu no chão do quarto dos
pais. Amanheceu, mamãe acordou, se espreguiçou, levantou da cama e foi até o banheiro, pisando
no corpo inerte da filha!
Esta é uma boa simulação dos processos físicos da vida diária. É uma simulação atroz dos
processos emocionais da vida diária.
Will construiu um excelente simulador físico. Mas não tem conteúdo de pessoas. É uma
violação direta do meu argumento de “pessoas, não coisas”, pois se concentra no aspecto das
coisas da vida, em todos os detalhes mecânicos. Ir ao banheiro é um módulo importante nesse
programa, enquanto os processos emocionais simplesmente não estão lá. Não quero criticar um
produto brilhante: Will partiu com um objetivo claro e o alcançou, e isso é maravilhoso.
Mas ele não se propôs a fazer o que estou fazendo e, vejam só, não conseguiu. Recuso-me a
criticar The Sims, porque como design é magnífico. Tem um propósito claro e atinge esse propósito
de forma brilhante. É apenas um produto diferente, e não é uma narrativa interativa.

Então, o que faz você querer buscar a narrativa interativa?


É muito mais relevante. Além disso, acho que é muito mais interessante do que o design do jogo.
Os problemas de design dos jogos de computador hoje em dia me aborrecem, porque não são
problemas muito complexos. Eles tendem a ser modelos muito pequenos, bastante fáceis de
calcular. Continuo chocado com o baixo nível de inteligência em muitos desses jogos. O oponente
do computador é realmente estúpido, e esse é o único elemento que ainda me interessa. Eu
gostaria de fazer um jogo com uma IA realmente boa, onde o oponente do computador pode
realmente ser mais esperto que você, e não quero dizer isso no sentido de xadrez, quero dizer algo
complicado como um jogo de guerra. Mas os próprios jogos de guerra são óbvios. Eu sinto que
dominei essa forma e então por que eu deveria continuar me entregando a ela? Há tantas outras
tarefas mais importantes, como contar histórias interativas.
Este é um desafio! Algo em que eu possa realmente afundar meus dentes. Infelizmente, parece
que afundei meus dentes na cauda de um tigre.

Você já tem medo de estar sempre insatisfeito com o Erasmatron?


Considero este o trabalho da minha vida. Este é o ponto culminante de tudo o que tenho
conduzido. Não tenho dúvidas de que, se continuar trabalhando nisso, posso continuar melhorando
essa tecnologia. Tenho grandes dúvidas quanto à sua viabilidade comercial neste momento. Ou
seja, tenho certeza de que daqui a vinte anos as pessoas perceberão que contar histórias
interativas é uma coisa comercialmente maravilhosa e, caramba, devemos fazê-lo. Acredito que
podemos fazer produtos que as pessoas achem muito mais divertidos do que jogos de computador,
porque serão sobre drama em vez de gerenciamento de recursos. Infelizmente, eu não acho que
as pessoas vejam isso ainda. Certamente a indústria de jogos não faz e não fará.
Eles sentirão que The Sims representa o passo correto nessa direção. Eles podem
Machine Translated by Google

Capítulo 14: Entrevista: Chris Crawford 279

continuar a obter mais polígonos nos rostos e fazê-los dançar melhor e assim por diante. Mas em
termos de resolução dramática, eles nem começaram.
Talvez fosse bom se eles seguissem esse caminho, deixando a área do problema real livre
para mim e para as outras pessoas que levam a sério a narrativa interativa. Há indícios de um
anseio por conteúdo dramático. Por exemplo, a Sony chama o chip do PlayStation 2 de “The
Emotion Engine”. Bem, isso é touro, touro total. É um processador gráfico e não tem nada a ver
com modelagem emocional. Mas isso mostra que eles com certeza gostariam de ter algum
conteúdo emocional honesto. Eles simplesmente não estão dispostos a assumir o compromisso no
nível do produto. Depois, há os fatores gêmeos da Internet e Hollywood.
Entre eles, há um forte desejo de estabelecer uma identidade não contaminada por jogos de
computador. Então, entre a Internet e o pessoal de Hollywood, acho que realmente deveríamos ter
uma narrativa interativa. Há muitas indicações nessa direção. Seis anos atrás, quando fui de
chapéu na mão para quase todas as grandes empresas de Hollywood tentando interessá-los, e
acabei desistindo, foi porque todos tinham acabado de se recuperar da experiência de se
queimarem por terem suas próprias divisões de jogos. Então, hoje em dia eles estão começando
com coisas baseadas na web que têm uma perspectiva completamente diferente, e eles podem se
interessar.

Eu me pergunto se você tem uma resposta para os críticos que dizem que contar uma
história de forma interativa está de alguma forma em desacordo com a estrutura fundamental da nar
Obviamente, você não acha que isso seja um problema.
De modo algum, e de fato estou surpreso com a superficialidade desse argumento. A refutação
fácil é o exemplo do vovô sentado com a netinha para lhe contar uma história: “Era uma vez uma
menina que tinha um cavalo”. E a garotinha diz: “Era um cavalo branco?” E o vovô não diz: “Cala a
boca, garoto, você está arruinando minha trama cuidadosamente construída!” Ele diz: “Ah, sim, era
muito branco, branco como a neve”. Ele desenvolve sua história e a garotinha interage com ele.
Ele abraça a participação dela e a incorpora na história, o que torna a história muito melhor. Esse
tipo de narrativa existe desde os primórdios da existência humana. Há muito provamos que, sim,
você pode fazer o público intervir na história sem danificá-la.

Em seu trabalho com jogos, você criou tanto o conteúdo quanto a tecnologia, enquanto com
o Erasmatron você está se concentrando em criar apenas a tecnologia, que permitirá que
outras pessoas criem o conteúdo. Por que você mudou seus esforços nessa direção?

Existem muitas pessoas que poderiam fornecer conteúdo artístico, mas eu sou a única pessoa que
pode fornecer a ferramenta. Portanto, tenho a obrigação moral de me concentrar no talento que é
único para mim. No entanto, ainda há algumas outras coisas que eu quero fazer. Há tanta coisa
acontecendo, eu tenho que alocar meu tempo com muito cuidado, e muitos bons projetos estão em
segundo plano.

Então, como resultado, você não tem muita chance de trabalhar em Le Morte D'Arthur.
Certo, eu tenho que deixar isso borbulhar no meu subconsciente por mais um tempo. E pode nunca
sair, não sei.
Machine Translated by Google

280 Capítulo 14: Entrevista: Chris Crawford

Então, o que vem a seguir para a tecnologia Erasmatron?


Bem, a tecnologia básica está, eu sinto, pronta para ir comercialmente agora. Ainda precisamos
construir um front end e assim por diante, mas estamos prontos para iniciar o processo de
comercialização imediatamente. Minha próxima tarefa principal é comercializar essa tecnologia. Não
tenho certeza de como proceder nesse ponto.

Você estaria interessado em trabalhar em um jogo mais tradicional novamente?


Neste ponto, eu estaria interessado e disposto a consultar pessoas sobre vários designs de jogos.
Ou seja, eu não me importaria de entrar e olhar para um projeto e identificar problemas fundamentais
de design nele, ou ajudar. Mas não acho que gostaria de aceitar a responsabilidade de criar um
produto comercial para a indústria de jogos neste momento. Fico feliz em ajudar alguém a fazer
isso. Mas esse é um processo tão político e desagradável, e cada vez menos tempo é gasto nos
aspectos criativos e mais nos aspectos políticos que não me interessam.

Chris Crawford Gameografia Tanktics,


1978 Legionnaire, 1979 Energy
Czar, 1981 SCRAM, 1981 Tanktics
(atualizado para Atari 800), 1981
Eastern Front (1941), 1981
Legionnaire (atualizado para Atari 800),
1982 Gossip, 1983 Excalibur, 1983 Balance
of Power , 1985 Patton vs. Rommel, 1986 Trust
& Betrayal: The Legacy of Siboot, 1987 Balance
of Power II: The 1990 Edition, 1988 The Global
Dilema: Guns & Butter, 1990 Balance of the
Planet, 1990 Patton Strikes Back, 1991
Machine Translated by Google

Capítulo 15
Obtendo o
Funcionamento da jogabilidade

“Quem quer ser deve deixar de lado a alienação, seguir com o fascínio,
a relação real, o tema subjacente.”
— Neil Peart

onde a maior incógnita é “De onde vem o dinheiro?” não “Como


Hollywood tem um
vamos sistema.
fazer É um sistema
esse filme?” bem e
Produtores conhecido com
talentos de um objetivo
Hollywood bem como
sabem definido,
passar de um tratamento para um roteiro, passando por várias revisões desse roteiro,
depois como reunir o pessoal que vai rodar o filme e, finalmente, uma equipe menor
que vai editá-lo, culminando na finalização do filme. o filme no prazo e no orçamento
(geralmente). Hollywood como um todo tem muito menos controle sobre se o filme final
será bom ou não, mas eles pelo menos sabem como fazer o filme. Raramente um filme
já em produção tem seu roteiro completamente reescrito, seu pessoal reduzido, ou
mais pessoas adicionadas involuntariamente ao elenco e à equipe. Normalmente, os
filmes são concluídos meses e meses antes de serem lançados. Concedido, às vezes o filme p

281
Machine Translated by Google

282 Capítulo 15: Fazendo a jogabilidade funcionar

nunca vai além do estágio de roteiro ou, uma vez concluído, pode não ser lançado como
originalmente pretendido. Mas, no geral, Hollywood tem um sistema eficiente de criação de filmes.
Por outro lado, os desenvolvedores de jogos de computador não têm esse sistema. O
desenvolvimento de um design de jogo é um processo caótico e imprevisível cheio de problemas
que nem mesmo o produtor, designer ou programador mais experiente pode prever. Normalmente,
o desenvolvimento de jogos de computador continua até o último segundo possível, com alterações
feitas até o momento em que o disco mestre de ouro é enviado para os duplicadores. Para jogos
de PC, geralmente um patch segue logo em seguida, já que o jogo nunca foi finalizado corretamente
em primeiro lugar. Por que o desenvolvimento de jogos de computador é tão imprevisível enquanto
a produção de filmes é tão previsível? Concedido, Hollywood tem feito filmes por muito mais tempo
do que a indústria de jogos de computador tem feito jogos, o que lhes dá uma vantagem. Mas além
disso, Hollywood está fazendo um produto muito mais previsível. Filmes diferentes podem ter
histórias e personagens únicos, e podem até usar uma variação de técnicas cinematográficas, mas
grande parte do cinema é uma quantidade conhecida.

Doom ofereceu uma


jogabilidade tão diferente de
qualquer jogo que veio antes
dele que o desenvolvimento
do jogo foi uma espécie de
experimento ousado.

Os jogos originais, por outro lado, são um animal totalmente novo a cada vez. Parte do
problema são os alvos tecnológicos em mudança, onde os programadores devem aprender sobre
novos consoles, sistemas operacionais e placas aceleradoras 3D para cada projeto. Acrescente a
isso o fato de que tantos jogos sentem a necessidade de ter um motor gráfico de ponta. Mas
puramente do ponto de vista do design, um jogo verdadeiramente original é muito mais único em
comparação com outros jogos contemporâneos do que um filme para outros filmes feitos ao mesmo tempo.
Considere jogos como Civilization, The Sims ou Doom. A jogabilidade contida nesses jogos era
radicalmente diferente de qualquer coisa que veio antes deles. É verdade que muitos jogos são
muito menos experimentais e inovadores do que os jogos que acabei de listar, e os jogos que
seguiram mais uma fórmula tiveram uma taxa de sucesso muito melhor em termos de lançamento
no prazo e no orçamento. Isso inclui títulos como os jogos de aventura da Infocom, os títulos de
aventura da Sierra, as revisões anuais de jogos esportivos ou as novas versões de jogos de direção
arcade. No entanto, estes são jogos que, embora incluam novos conteúdos consistindo em novas
histórias e gráficos, oferecem uma jogabilidade muito parecida com as ofertas do ano anterior.
Quando um jogo tenta implementar uma nova forma de
Machine Translated by Google

Capítulo 15: Fazendo a jogabilidade funcionar 283

jogabilidade, mesmo que seja apenas uma variação de um tema comprovado, toda a esperança de previsibilidade
em seu desenvolvimento é jogada aos quatro ventos.
Apenas designers verdadeiramente talentosos têm alguma esperança de prever o que vai ser divertido ou
não em um jogo, e mesmo os designers mais experientes dirão que eles usam muitos protótipos, experimentação
e confusão geral até chegarem ao jogabilidade que eles querem. Esses talentosos designers veteranos não têm
bolas de cristal; eles só têm uma chance melhor de antecipar o que tornará a jogabilidade atraente. Eles realmente
não “sabem” mais do que ninguém.

A coisa mais próxima que o desenvolvimento de jogos tem de um sistema confiável para desenvolver um
jogo original é fazer com que uma pequena parte da jogabilidade funcione primeiro, antes de avançar para
construir o resto do jogo. Isso pode ser chamado de protótipo, demonstração, prova de conceito, nível ou
simplesmente a versão atual do jogo. Esta não é apenas uma demonstração para mostrar a tecnologia do jogo.
Em vez disso, é algo que mostra a jogabilidade do jogo, que incorpora versões preliminares de todos os recursos
descritos no foco do jogo, conforme discutido no Capítulo 5. Esta demo deve ser algo que qualquer membro da
equipe de desenvolvimento possa pegar, jogar e diga: "Sim, isso é divertido, eu quero jogar isso." Ao se concentrar
em obter um pequeno pedaço do jogo totalmente funcional e agradável, o desenvolvedor pode ter uma noção
muito melhor se o jogo final será divertido ou não. Se a jogabilidade simplesmente não sair como o esperado, o
protótipo fornece um aviso antecipado de que o jogo precisa ser redirecionado para uma direção mais promissora
ou, nos piores casos, totalmente abortado.

O Processo Orgânico
Nos jogos em que trabalho, prefiro manter o processo de desenvolvimento o mais orgânico possível e tento não
planejar nada além do necessário naquele estágio de desenvolvimento. Isso pode ser o oposto da abordagem
que muitos estúdios de desenvolvimento preferem, mas acho que é o método mais eficaz para desenvolver o
melhor jogo possível. Devido à natureza altamente imprevisível do design do jogo, que discuti acima, um processo
mais orgânico me deixa espaço e tempo para experimentar como a jogabilidade funcionará. Em vez de escrever
um documento gigantesco, posso primeiro tentar fazer com que uma parte do jogo seja divertida antes de
começar a adicionar detalhes e duração ao jogo. É claro que manter o processo orgânico precisa ser equilibrado
com preocupações com orçamento, cronograma e manter uma grande equipe de desenvolvedores ocupada. De
fato, ter muitos desenvolvedores muito cedo em um projeto pode ser um problema real, pois eles terão que
avançar na criação de conteúdo antes que você tenha certeza de qual deveria ser esse conteúdo. Adicionar muito
conteúdo ao jogo muito cedo pode ser um grande desperdício, se não for realmente restritivo. Esses detalhes
excessivos podem assumir a forma de um documento de design elaborado, um script para o diálogo do jogo,
mapas detalhados das várias áreas que os jogadores explorarão ou até mesmo níveis totalmente construídos
para o jogo. Não faz nenhum sentido criar esses elementos do jogo até que você tenha uma compreensão firme
de como será a jogabilidade e tenha um protótipo funcional que prove que a jogabilidade é divertida.

Demais e antes da hora


O problema de criar scripts, documentos ou níveis sem um protótipo é que esses recursos farão suposições sobre
como a jogabilidade funcionará, suposições
Machine Translated by Google

284 Capítulo 15: Fazendo a jogabilidade funcionar

isso pode se tornar incorreto quando a jogabilidade estiver realmente funcional. Se um designer
constrói um design de jogo elaborado com base em princípios que se revelam falhos, todo o
design do jogo provavelmente precisará ser retrabalhado ou, mais provavelmente, jogado fora.
Mas se as pessoas dedicaram muito tempo à criação desses ativos defeituosos, elas ficarão
compreensivelmente relutantes em jogá-los fora. Se um designer se apega demais a essas
ideias, mesmo que mais tarde se mostrem inviáveis, ele pode tentar se apegar a elas.
Esta é uma tendência humana natural compreensível. Afinal, muito trabalho foi feito para
planejar o jogo com antecedência por meio de um longo documento de design - como tudo
isso pode ser jogado fora? Os ativos não podem ser retrabalhados para serem utilizáveis? Se
você não for ousado o suficiente para jogar fora seu conteúdo impróprio, no final você corre o
risco de produzir um jogo que é remendado após o fato, em vez de construído desde o início
com um claro senso de direção.
Quando comecei a trabalhar no meu primeiro jogo publicado, Odyssey: The Legend of
Nemesis, admito que tinha pouca ideia do que estava fazendo. Eu herdei um motor de jogo e
uma parte da mecânica do jogo do desenvolvedor anterior. Na época, o projeto era muito mal
financiado e, como resultado, a editora solicitou apenas uma pequena quantidade de
documentação sobre para onde o jogo estava indo. Eu elaborei um documento de seis páginas
que descrevia brevemente todas as aventuras que os jogadores teriam. Em primeiro lugar,
como o documento não era muito detalhado, com apenas uma página por ilha principal do
jogo, isso me deixou muito espaço de manobra. Em segundo lugar, quando implementei as
duas primeiras ilhas, aprendi o suficiente sobre como o jogo realmente funcionava e decidi
jogar fora as últimas três ilhas e projetá-las novamente. Como eu tinha escrito apenas dez
breves esboços da jogabilidade em primeiro lugar, não perdi muito trabalho.

Manter a
documentação
de desenvolvimento leve e usar
arte de espaço reservado
manteve o desenvolvimento do
Odyssey extremamente
orgânico.

Outro aspecto interessante da criação do Odyssey foi que eu desenvolvi o jogo


inteiramente usando a arte do espaço reservado. Junto com a engine do jogo, eu herdei uma
boa quantidade de arte de outro projeto e continuei usando isso o máximo possível. Como o
projeto foi subfinanciado, eu não tive um artista para trabalhar durante a maior parte do
desenvolvimento do jogo, então essa decisão foi tomada mais por necessidade do que por previsão.
Machine Translated by Google

Capítulo 15: Fazendo a jogabilidade funcionar 285

No entanto, isso significou que, quando tive dinheiro para contratar artistas para terminar o
projeto, todo o design do jogo estava pronto e totalmente jogável e, como resultado, os artistas
quase não criaram arte para o jogo que não foi usada. Usar a arte do espaço reservado não
impediu nem um pouco o desenvolvimento do jogo. Concentrei-me primeiro em fazer com que
toda a jogabilidade funcionasse e depois consegui me concentrar nos visuais. Como eu não estava
limitado pelo pensamento de perder os ativos artísticos já criados se eu mudasse o design, fui
capaz de levar o design na direção que parecia mais apropriada enquanto trabalhava nele.

No Centipede 3D, uma quantidade significativa de trabalho foi feita antes que a jogabilidade
fosse realmente divertida, e quase todo esse trabalho teve que ser descartado como resultado. A
ideia original para a jogabilidade tinha pouco a ver com como o Centipede original funcionava do
ponto de vista da jogabilidade e apresentava um estilo de jogo mais sinuoso e menos direcionado.
Usando esta concepção de jogabilidade original, seis níveis foram realmente construídos e vários
outros níveis foram planejados no papel. Por várias razões, a jogabilidade simplesmente não era
muito divertida e começamos a ver o que poderia ser feito para corrigir esse problema. No final,
fizemos a IA inimiga funcionar mais como os inimigos do jogo original e ajustamos a jogabilidade
de acordo. Quando tentamos, não tínhamos certeza se funcionaria, mas esse estilo de jogo
acabou funcionando muito bem. Infelizmente, muito do trabalho de design de níveis que havia sido
feito foi perdido. Todos os níveis que foram desenhados no papel foram jogados fora porque eram
incompatíveis com esse novo estilo de jogo. Dos seis níveis que foram realmente construídos, três
tiveram que ser descartados para suportar a nova jogabilidade, enquanto os outros tiveram que
ser alterados significativamente para jogar bem.
Olhando para trás, se tivéssemos nos concentrado em tornar a jogabilidade divertida antes
de fazer um grande número de níveis, poderíamos ter evitado muito trabalho extra e esforço
desperdiçado. Com a jogabilidade funcional, conseguimos elaborar documentos descrevendo
como o resto do jogo funcionaria. Na maioria das vezes, conseguimos manter esses documentos
durante o restante do processo de desenvolvimento, com apenas pequenas alterações necessárias.
Claro que teria sido catastrófico para o projeto se não tivéssemos sido capazes ou não quiséssemos
jogar fora o trabalho que já tínhamos feito. Se tivéssemos tentado manter todos os níveis sem
alterá-los significativamente, o jogo teria mostrado isso e esses níveis seriam muito inferiores aos
feitos com a jogabilidade adequada em mente. Se tivéssemos sido tolos o suficiente para manter
o design inicial completamente, o jogo inteiro teria sofrido e o produto final não teria sido tão
divertido quanto acabou sendo.

Mantenha simples
No início do desenvolvimento, faz sentido trabalhar apenas com seu foco em vez de um longo
documento de design. O foco é curto o suficiente para que possa ser facilmente reescrito
completamente se o seu jogo mudar de direção. No entanto, ao mesmo tempo, o foco lhe dará
uma direção clara para o que você está tentando alcançar com a jogabilidade que está tentando
implementar. Na fase de prototipagem, o foco pode mudar muitas e muitas vezes à medida que
você muda os objetivos do jogo para combinar com o que está funcionando em termos de jogabilidade.
Quando sua prototipagem estiver concluída, você terá um foco sólido que pode razoavelmente
esperar seguir pelo resto do desenvolvimento do jogo.
Infelizmente, nem sempre você tem a opção de manter o processo de design do jogo
orgânico. Se você está trabalhando para uma empresa estabelecida, você pode ter uma equipe completa
Machine Translated by Google

286 Capítulo 15: Fazendo a jogabilidade funcionar

equipe trabalhando em seu projeto desde o início, e essas pessoas precisam se manter ocupadas
fazendo arte, construindo níveis ou codificando sistemas, mesmo que ainda não haja um protótipo
de jogabilidade funcional e divertido. Não é preciso uma equipe grande para fazer a jogabilidade
inicial funcionar e, de fato, uma equipe tão grande só pode atrapalhar seu caminho enquanto você
tenta mantê-los ocupados enquanto experimenta como a jogabilidade funcionará. Você também
pode ter demandas daqueles que financiam o desenvolvimento do seu projeto, seja seu empregador
ou o editor. Quem está pagando as contas pode querer ver um documento de design completo ou
roteiro antes de um protótipo do jogo ser desenvolvido.
Você pode ser forçado a abandonar esses documentos mais tarde, pois a jogabilidade funciona de
maneira diferente do que você esperava. Obviamente, elaborar esses documentos prematuramente
pode ser um desperdício, mas você está sempre em dívida com quem está fornecendo o
financiamento para seu projeto. De certa forma, se possível, pode fazer sentido autofinanciar o
projeto até que você tenha um protótipo totalmente funcional. Trabalhe nele “sob o radar” se você
estiver em uma grande empresa, ou trabalhe no protótipo do jogo antes de tentar encontrar um
editor. Além disso, uma demo jogável tornará o jogo mais fácil de vender para uma editora ou um
comitê de luz verde. Nada prova aos financiadores que seu jogo está indo na direção certa melhor
do que um protótipo atraente.

Construindo o jogo
A melhor maneira de construir seu jogo é incrementalmente. Em vez de trabalhar um pouco em
todos os diferentes componentes do jogo, você deve tentar completar um sistema antes de passar
para o próximo. Trabalhe primeiro nos sistemas mais básicos e essenciais e depois construa os
sistemas que dependem desse sistema. Isso permite que você implemente um sistema, teste-o,
veja se “parece” certo e só então passe para o próximo sistema. Dessa forma, se você precisar
alterar o sistema subjacente para fazê-lo funcionar corretamente, seus sistemas subsequentes
podem ser alterados de acordo, antes que você se dê ao trabalho de implementá-los. Muitas vezes,
pode levar ao desastre quando você tem vários programadores trabalhando simultaneamente na
codificação de uma variedade de sistemas que funcionam juntos. Se um sistema tiver que mudar,
outros sistemas podem precisar ser radicalmente reformulados. É melhor construir uma base sólida
antes de tentar construir em cima dela. Os programadores geralmente gostam de trabalhar em sua
própria parte isolada do código sem considerar totalmente como ela terá que interagir com o resto
do projeto. É importante que sua equipe de programação esteja constantemente focada no quadro
geral de tornar o jogo jogável e divertido.

Tecnologia essencial
É claro que todos os jogos de computador dependem de uma tecnologia subjacente que tem muito
pouco a ver com a jogabilidade, geralmente chamada de mecanismo do jogo. Certamente você
precisa ter certeza de que essa tecnologia subjacente funciona em um certo nível antes que
qualquer trabalho possa ser feito na jogabilidade. No entanto, você não precisa que o motor seja
perfeito ou completo antes de começar a construir seu protótipo. De fato, em um projeto com uma
engine de ponta, esperar até que a engine esteja realmente finalizada pode significar que é tarde
demais para gastar tempo suficiente refinando o próprio jogo. O perigo de trabalhar com tecnologia
desconhecida é projetar em torno de projeções das capacidades da tecnologia. Se você projetar
seu jogo pensando que poderá ter dez inimigos na tela ao mesmo tempo e seu motor for capaz de
lidar com apenas três, você precisará alterar radicalmente
Machine Translated by Google

Capítulo 15: Fazendo a jogabilidade funcionar 287

seu projeto para acomodar essa restrição. Não deve ser surpresa que os jogos mais bem projetados
sejam frequentemente aqueles que não usavam a tecnologia mais avançada disponível quando
foram lançados.
Se a tecnologia simplesmente não estiver pronta, conheço vários designers de jogos que
começam a prototipar seus jogos usando a tecnologia de um projeto anterior. É raro que a
tecnologia realmente construa ou destrua um design de jogo, embora possa fazer ou destruir o
próprio jogo. Mas a tecnologia, por mais imprevisível que às vezes possa ser, ainda é mais
conhecida do que o design do jogo, então faz sentido não se preocupar com isso quando você
estiver prototipando seu jogo pela primeira vez. Como as primeiras áreas que você cria
provavelmente devem ser jogadas fora mais tarde, não é um desperdício fazê-las funcionar usando
uma tecnologia que você acabará jogando fora também.

A tecnologia de
licenciamento pode ser um
tremendo benefício para o
desenvolvimento de jogos
e está se tornando cada vez
mais comum. Retratado aqui:
o motor Unreal frequentemente
licenciado sendo usado no
Unreal Tournament 2004.

Nos últimos anos, o licenciamento de motores tornou-se muito mais comum na indústria.
Isso assume a forma de usar a tecnologia de um jogo específico, como Half-Life ou Unreal , ou de
uma empresa apenas de tecnologia que cria mecanismos mais robustos projetados para funcionar
em vários projetos em várias plataformas; exemplos incluem Renderware da Criterion e Gamebryo
da NDL. A proliferação de mecanismos licenciados significa que a maioria dos projetos não precisa
mais esperar que sua tecnologia seja construída e cada vez mais desenvolvedores de jogos têm o
luxo de começar sabendo o que vão ou não conseguir realizar tecnicamente.

Etapas incrementais
Quando sua tecnologia estiver em um ponto em que você possa começar a desenvolver a
jogabilidade como mencionei anteriormente, tente dividir o design do jogo nas tarefas mais
fundamentais que precisam ser realizadas e, em seguida, nas tarefas que se baseiam nelas. Por
exemplo, suponha que você está construindo um jogo de ação no qual os jogadores navegam um
personagem humanóide pelo mundo do jogo, lutando contra agentes de seguros com um mata-
moscas enquanto coletam kiwis. Fazer o sistema de navegação do jogador funcionar é uma
primeira tarefa lógica a ser enfrentada. Primeiro, faça o personagem se mover para frente e para trás e girar
Machine Translated by Google

288 Capítulo 15: Fazendo a jogabilidade funcionar

navegação básica do mundo. Trabalhe nesse movimento até que ele se sinta muito bem, até que
você se sinta gostando de jogar o jogo dessa maneira simples e apenas de navegação. Agora
você pode aproveitar isso adicionando mais opções de movimento, como metralhar, agachar e
pular. À medida que você adiciona cada novo tipo de movimento, certifique-se de que ele não
interrompa nenhum dos tipos de movimento anteriores e que todos funcionem bem juntos. Apenas
uma vez que estiver firmemente no lugar, você deve tentar adicionar a capacidade de os jogadores
usarem o mata-moscas. Com o mata-moscas divertido de usar, pelo menos de forma limitada, faz
sentido adicionar os agentes de seguro ao jogo. A funcionalidade de IA pode ser dividida em blocos
de construção, assim como o movimento dos jogadores. Primeiro, pegue os agentes de IA do
mundo para que os jogadores possam acertá-los com o mata-moscas. Em seguida, faça com que
os agentes se movam pelo mundo do jogo antes de finalmente adicionar a capacidade de fazer
seu ataque de “auditoria” ou “papelada excessiva”. Finalmente, você pode adicionar os kiwis ao
mundo e a capacidade de os jogadores pegá-los e lançá-los com seu mata-moscas. O que é
essencial neste processo passo a passo é que a cada passo ao longo do caminho o jogo ainda seja jogável e di
Quando você adiciona algo ao jogo que quebra uma parte anterior ou simplesmente o torna menos
divertido, você deve resolver esse problema imediatamente. Agora é a hora de alterar seu design
conforme necessário, antes que o jogo entre em produção total.
Ao longo do desenvolvimento do projeto, acho importante manter sempre uma versão do seu
jogo jogável. Você deve ter seu jogo jogável de alguma forma primitiva o mais rápido possível,
idealmente desde o primeiro dia, e mantê-lo assim até o envio. Muitas vezes, as equipes de
programação passam muito tempo codificando várias peças do jogo sem ter uma versão funcional
que alguém possa sentar e jogar. É muito fácil perder de vista seus objetivos de jogo quando seu
jogo definha em um estado não jogável por grande parte do tempo. Certamente o jogo pode ser
quebrado de várias maneiras, com vários componentes que ainda não funcionam como deveriam
e com arte de espaço reservado usada em muitos locais. Mas contanto que você sempre tenha um
jogo jogável, os membros da equipe podem pegá-lo e jogá-lo, e ver no que estão trabalhando e
como isso afeta o jogo.
E se algo adicionado ou alterado tornar esta versão jogável do jogo menos divertida, você poderá
descobrir imediatamente esse problema e corrigi-lo.

Uma área totalmente funcional


Uma vez que você tenha muitos dos elementos da mecânica do seu jogo funcionando e esteja
satisfeito com eles, o próximo passo é fazer uma seção inteira do jogo que funcione exatamente
como você quer que ela funcione no jogo final. Em muitos gêneros de jogos, isso significa um nível
particular do jogo. Você pode pensar que tem todos os componentes de sua jogabilidade funcionais,
mas uma vez que você realmente tente tornar uma área inteira jogável, você descobrirá rapidamente
o que você esqueceu de implementar ou não antecipou. Concentre-se em obter este nível o mais
próximo possível de um estado final antes de passar para a criação de outros níveis. Se você for
observador, aprenderá muitas lições sobre como o design de níveis deve funcionar para seu jogo
em particular através da criação deste nível, lições que ajudarão a eliminar o elemento de
adivinhação da criação dos outros níveis no jogo. Uma vez que você tenha terminado com este
nível, não será mais o melhor que você pode fazer; você terá aprendido muito, e os níveis
subsequentes que você criar serão mais bem planejados desde o início. Embora você ainda não
precise jogar fora este nível de protótipo, lembre-se de que você provavelmente deve descartá-lo
antes do lançamento do jogo.
Machine Translated by Google

Capítulo 15: Fazendo a jogabilidade funcionar 289

O primeiro nível de rede


feito para a Damage
Incorporated, retratado
aqui, também foi o pior do
jogo. Teria sido melhor
descartá-lo e construir

um novo.

Um exemplo disso é o desenvolvimento do meu jogo Damage Incorporated.


O primeiro nível que criei para o jogo single-player foi feito antes de eu entender completamente
a mecânica do jogo ou as ferramentas de criação de nível que eu usaria. Como resultado, estava
longe de ser divertido de jogar e foi rapidamente jogado fora. O próximo nível que fiz, embora
certamente não seja o melhor do jogo, foi bom o suficiente para fazer o corte final. Para este
nível, eu deliberadamente escolhi um mapa do meio do jogo, para que não fosse o primeiro
conteúdo que os jogadores veriam, já que eu sabia que minha habilidade de criação de mapas
melhoraria depois que eu tivesse mais alguns em meu currículo. Muitas vezes, é uma boa ideia
começar a desenvolver seu conteúdo no meio do jogo. As partes iniciais do jogo precisam estar
no mais alto nível de qualidade possível, então você quer que elas representem seus esforços
mais experientes, enquanto os níveis no final do jogo geralmente tendem a ser mais atípicos e,
portanto, não representam o “ regular” que você deseja que funcione primeiro.
A Damage Incorporated também incluiu vários jogadores no estilo death-match, que usavam
um conjunto completamente diferente de níveis. Devido a restrições de tempo, gastei
significativamente menos tempo equilibrando o jogo em rede do que gostaria. Em particular, o
primeiro nível que criei para o jogo em rede, “Minha mente está dormente, minha garganta está
seca”, acabou não sendo muito divertido de jogar. Tinha várias áreas legais, mas elas não fluíam
muito bem juntas e várias seções no nível eram armadilhas mortais injustas e desequilibradas.
Um dos meus playtesters até sugeriu que seria melhor jogá-lo fora e começar um novo nível do
zero. Infelizmente, não tive tempo de fazer uma substituição e acabou sendo enviado com o jogo.
Felizmente, havia sete outros níveis de rede que eram significativamente mais divertidos de
jogar. No entanto, teria sido melhor se eu tivesse descartado completamente minha primeira
tentativa em nível de rede e feito uma nova.
Em The Suffering, o primeiro nível que construímos foi o primeiro nível do jogo.
Curiosamente, acabou sendo enviado de uma forma bastante próxima de como foi originalmente
planejado e foi um dos nossos níveis mais fortes. Em parte, porque éramos uma equipe bastante
experiente trabalhando com uma mecânica de jogo relativamente conhecida (um shooter). Uma
parte igual do sucesso do nível foi sorte. Embora tenha sido bem-sucedido do ponto de vista do
design do jogo, do ponto de vista tecnológico, o primeiro nível foi construído de tal forma que foi um pesad
Machine Translated by Google

290 Capítulo 15: Fazendo a jogabilidade funcionar

para os designers de nível editarem e constantemente ultrapassaram os limites de nossa tecnologia. Foi
também um dos níveis mais complexos do jogo, com o jogador capaz de retornar a ele mais tarde no fluxo
do jogo, fazendo com que ele contenha o dobro da quantidade de lógica encontrada na maioria dos níveis.
Por causa das lições aprendidas nesse nível, os níveis subsequentes foram muito mais conservadores.
Embora a construção do primeiro nível tenha funcionado criativamente no caso de The Suffering, os
muitos problemas que enfrentamos com ele do ponto de vista da produção demonstram os problemas
com a construção do primeiro nível primeiro.
Algo que você deve estar ciente ao construir a primeira seção totalmente jogável do seu jogo é o
quão difícil é jogar o jogo. Muitas vezes, a dificuldade pode ser ajustada e ajustada posteriormente no
processo de desenvolvimento, durante o teste e o balanceamento. No entanto, os jogos também têm uma
dificuldade fundamental, que é mais intrínseca à sua natureza e que não pode ser facilmente ajustada no
final do ciclo de desenvolvimento. Como você está trabalhando para fazer seu protótipo de jogo funcionar,
tente olhar para ele honestamente em termos de quão difícil será para jogadores iniciantes entrarem.
Traga alguns amigos ou colegas de trabalho e faça-os jogar o jogo. Observe a facilidade com que eles
conseguem pegar os controles e a mecânica. É muito mais simples tornar um jogo mais difícil do que
torná-lo mais fácil. Se você achar que seu jogo está se tornando mais difícil de jogar do que você esperava,
agora é a hora de alterar o design do jogo para torná-lo mais fácil de jogar, antes que seja tarde demais.
Encontrei uma instância desse problema no Centipede 3D, um jogo que era muito mais difícil do que
esperávamos quando foi lançado. Isso ocorreu em parte porque era baseado em um jogo de arcade de
moedas que foi projetado para matar o jogador dentro de quatro minutos de jogo, e em parte porque nós,
desenvolvedores, jogamos tanto o jogo que não parecia difícil para nós. Quando percebemos que o jogo
estava muito difícil, estava muito perto de ser lançado para consertá-lo.

Por causa da mecânica simples do jogo (o jogador e seus adversários são todos mortos por um único
golpe dos adversários), havia pouco que pudesse ser facilmente ajustado para tornar o jogo mais fácil,
exceto redesenhar a maneira como os agentes da IA trabalhavam. Se tivéssemos identificado nosso
problema de dificuldade antes, poderíamos ter feito mudanças fundamentais no jogo para torná-lo mais
fácil de jogar.

Passando por mudanças


Uma grande parte do processo orgânico de design de jogos é poder jogar fora seu próprio trabalho e,
potencialmente, o do resto de sua equipe. Isso inclui arte, código, níveis e até mesmo o próprio design
geral; todo o conteúdo do jogo pode precisar mudar à medida que sua jogabilidade evolui. Um recurso em
particular pode não ser falho por si só, mas se ele não combinar adequadamente com a maneira como a
jogabilidade está funcionando, talvez seja necessário abandonar esse recurso e começar do zero. Muitos
desenvolvedores não estão dispostos a fazer isso, e isso aparece em seus jogos. Ou seus jogos estão
presos a um documento de design inicial que acabou não funcionando tão bem na prática quanto na
teoria, ou seus jogos retêm uma miscelânea de componentes de antes de sua direção ser finalizada. Uma
vez que um designer decide que a direção do jogo precisa mudar, todos os recursos do jogo devem ser
avaliados para ver se eles podem se encaixar nessa nova direção. Se não puderem, devem ser
retrabalhados ou refeitos.

Como já discuti, Centipede 3D mudou de rumo significativamente no meio do desenvolvimento, o


que nos fez jogar fora uma grande quantidade de trabalho. Felizmente, ninguém na equipe ficou insatisfeito
com isso, pois todos percebemos que era do melhor interesse do projeto. Com outros projetos em que
trabalhei, tenho sido mais teimoso e
Machine Translated by Google

Capítulo 15: Fazendo a jogabilidade funcionar 291

ignorou as súplicas de colegas de trabalho e amigos quando diziam que algo precisava ser
retrabalhado ou mudado. Eu estava relutante em jogar fora um trabalho perfeitamente bom, mesmo
que não combinasse mais com o jogo. Assim, posso dizer por experiência própria que, às vezes, o
primeiro passo para corrigir os problemas com o design do seu jogo é admitir que você tem um
problema.
Claro, você deve ter cuidado para não ir muito longe na outra direção, descartando o
conteúdo utilizável. Ao trabalhar em um projeto, é provável que você se familiarize excessivamente
com alguns dos conteúdos que criou, e a familiaridade pode gerar desprezo. Por exemplo, depois
de trabalhar com um nível por muito tempo, um designer provavelmente ficará cansado de olhar
para a mesma geometria dia após dia. O designer pode então sentir a necessidade de retrabalhar
esse nível, não porque realmente precise, mas simplesmente porque será algo novo. Este é um
esforço desperdiçado, já que para jogadores iniciantes, o nível será novo e empolgante. Alterar o
conteúdo do seu jogo apenas por mudá-lo pode levar a um tempo extra de depuração, atrasos no
envio de seu projeto e frustração geral para os membros da equipe que não sabem por que um
trabalho perfeitamente bom está sendo jogado fora e refeito.
As primeiras impressões são muito importantes, especialmente no design de jogos. Sempre
tente se lembrar de como você se sentiu pela primeira vez quando jogou um nível ou tentou fazer
um movimento específico. Foi muito difícil ou muito fácil? Foi intuitivo ou confuso? Outro grande
problema de trabalhar em um projeto por muito tempo é que os designers podem se acostumar
com falhas no projeto. Talvez os controles não sejam intuitivos ou um determinado inimigo ataque
os jogadores de forma arbitrária e injusta. À medida que jogam o jogo repetidamente, os designers
aprenderão a superar e evitar esses problemas no design do jogo, dando a eles a falsa impressão
de que nada está errado com o jogo. O teste de jogo é uma ferramenta essencial para revelar os
pontos fracos no design do jogo com os quais a equipe de desenvolvimento se acostumou, como
discuto no Capítulo 25, “Teste de jogo”. No entanto, antes de chegar ao estágio de teste, tente
sempre se lembrar de sua primeira impressão de um aspecto específico do jogo. Pode até ser
apropriado fazer anotações quando você joga pela primeira vez uma mecânica ou seção do jogo;
não assuma que você vai se lembrar de suas impressões mais tarde. Você pode não corrigir tudo
nestas notas imediatamente, mas para problemas que você mantém em sua mente como
precisando de melhorias no futuro, as notas serão inestimáveis. À medida que você se aproxima
do final do desenvolvimento, pergunte a si mesmo se os problemas que você viu quando jogou
pela primeira vez foram corrigidos ou se ainda estão presentes, criando frustração para outras
pessoas que experimentam o jogo pela primeira vez. Sempre que possível, mesmo que você faça
anotações, é melhor corrigir esses problemas assim que os observar, porque com o tempo você
provavelmente perdoará os problemas mais sutis do jogo.

Programação
Este capítulo foi escrito do ponto de vista de alguém que é designer e programador, como tenho
feito em todos os meus projetos. Estar em tal posição tem muitas vantagens únicas, especialmente
em termos de poder experimentar a jogabilidade. Um designer/programador é capaz de ter uma
ideia para alguma jogabilidade e então pode instantaneamente tentar implementá-la exatamente
como ela quer. Um designer que não programa é forçado a primeiro comunicar sua ideia para a
jogabilidade ao programador e esperar que o design seja entendido. Muitas vezes a comunicação
falha e o designer não consegue exatamente o que queria ou o recurso em questão pode ter um
desempenho inferior.
Machine Translated by Google

292 Capítulo 15: Fazendo a jogabilidade funcionar

implementação do que o que o designer tinha em mente. Como resultado, ou o jogo fica mais fraco ou o designer
deve voltar ao programador e tentar explicar como um determinado recurso deve realmente funcionar. Como o
design de jogos é um processo tão iterativo e experimental, deve haver um círculo constante de feedback entre o
designer e o programador. Obviamente, esse processo é bastante simplificado se o designer e o programador
forem a mesma pessoa.

Muitas vezes acho que, como designer que programa, posso experimentar ideias com muito mais facilidade.
Na verdade, muitas das ideias que tenho eu me sentiria mal tentando conseguir que outra pessoa trabalhasse, já
que não tenho confiança nelas para desperdiçar o tempo de outra pessoa com elas. Mas, no final, algumas
dessas ideias estranhas acabam funcionando muito bem no jogo, e se eu nunca tivesse sido capaz de
experimentar o código sozinho, as ideias talvez nunca tivessem sido tentadas.

Um designer/programador também será capaz de entender melhor a tecnologia envolvida em um projeto e


será mais capaz de ver o que é facilmente realizado e o que não é. Muitas vezes, um designer que não é um
programador ou que não é tecnologicamente experiente irá sugerir uma jogabilidade que é muito difícil de
implementar no motor. Pode ser que um tipo de jogabilidade diferente, embora igualmente funcional, funcione
melhor com a tecnologia do jogo, e se o designer/programador (ou pelo menos um designer com experiência em
programação) perceber isso, ele será capaz de simplificar bastante o jogo. desenvolvimento.

Digamos que um designer queira que uma certa espada tenha um comportamento específico para comunicar aos
jogadores que ela está encantada. O designer pode solicitar que a espada pareça fisicamente dobrar um pouco
dentro da mão do personagem do jogador. O programador designado para configurar esta funcionalidade
amaldiçoa o designer, sabendo que esta é uma tarefa praticamente impossível dadas as restrições do motor que
estão usando. A designer não percebe que criar um sistema de partículas sofisticado ao redor da espada é muito
mais fácil de fazer, embora ela ficaria perfeitamente feliz com essa solução. Como resultado, o programador, não
querendo parecer difícil resistindo ao pedido do designer, gasta muito tempo em uma implementação desafiadora,
quando uma muito mais simples teria satisfeito o designer se ele entendesse melhor a tecnologia e a solicitasse.
Compreender a viabilidade de ideias é uma habilidade que vem com a compreensão de como a programação de
jogos funciona fundamentalmente e como o mecanismo com o qual você está trabalhando é arquitetado. Mesmo
se você não estiver programando ativamente no projeto que está desenvolvendo, poderá entender melhor o que
pode ser feito facilmente com a tecnologia e qual recurso consumirá recursos por meses sem adicionar muito ao
jogo.

Outro problema surge quando o designer e o programador têm ideias diferentes sobre qual deve ser a
jogabilidade do projeto. Ouvi um designer se referir a isso como o “veto de bolso”. Um designer pode chegar a um
programador com uma explicação de como a jogabilidade de uma seção específica do jogo deve funcionar e, se
o programador não concordar, ele simplesmente não pode implementar o que o designer solicitou. Ela pode até
fingir que o pedido do designer é muito difícil ou realmente impossível de implementar quando não é. Felizmente,
os programadores que usam esse tipo de truque não costumam durar muito na indústria. No entanto, um designer
que não sabe programar ficará em dívida com os talentos e inclinações de seus programadores, o que pode ser
eternamente frustrante.

Eu sou da opinião que vale a pena aprender a programar se você quer ser um designer, mesmo que você
nunca consiga programar de acordo com os padrões profissionais e nunca faça nenhum
Machine Translated by Google

Capítulo 15: Fazendo a jogabilidade funcionar 293

codificação nos jogos que você envia. Na verdade, eu originalmente buscava programação porque
queria projetar jogos de computador. Está além do escopo deste livro ensiná-lo a programar, e
certamente há muitos livros disponíveis para ajudá-lo a aprender o que você precisará para
trabalhar em jogos. Grande parte da programação eficaz é uma questão de disciplina. E você nem
precisa ser um programador muito bom para que isso ajude imensamente no seu design. De fato,
quase todos os designers/programadores que conheço vão insistir que não são programadores
muito bons, mas que são persistentes o suficiente para conseguir o que querem de seus jogos.
Como mencionei, saber programar lhe dará uma melhor noção do que é fácil de fazer em um jogo
e do que é difícil, e os programadores irão respeitá-lo por tentar entender melhor seu lado do
desenvolvimento de jogos. Além disso, aprender a programar ajudará você a pensar de forma
lógica e abstrata, um talento de vital importância para programadores e designers de jogos.

Claro, com projetos modernos e equipes de desenvolvimento de cinquenta pessoas, muitas


vezes é difícil ser um designer e um programador, simplesmente devido à quantidade de tempo
que os designers precisarão gastar em seu próprio trabalho e transmitir sua visão para a equipe.
Se você não vai programar em seu projeto, é essencial que você tenha um programador líder com
um bom senso de jogabilidade, alguém em cuja opinião você possa confiar.
De fato, você será bem aconselhado a ter apenas programadores em sua equipe que tenham uma
boa noção do que torna os jogos divertidos. No final, há um número infinito de pequenas decisões
que os programadores tomam que terão um impacto profundo na jogabilidade, detalhes que
nenhum designer pode antecipar. Esses pequenos detalhes têm um enorme impacto no jogo final
e determinam como o jogo “se sente” ao jogar. Muitas vezes, programadores líderes desmotivados
ou desinteressados podem ser encontrados por trás de jogos que parecem boas ideias em teoria,
mas que não são nada divertidos. Muitos projetos passaram de começos promissores a produtos
finais insatisfatórios como resultado de programadores que simplesmente implementam vários
recursos de uma especificação e nunca param um momento para olhar para o jogo inteiro e ver se
é divertido.
Este livro inclui entrevistas com sete pessoas que são indiscutivelmente alguns dos designers
de jogos mais talentosos da história da indústria. É interessante notar que desses sete, todos
foram programadores em algum ponto de suas carreiras e programaram de alguma forma em seus
jogos mais respeitados. De fato, nos primórdios da indústria de jogos de computador, o processo
de desenvolvimento era de escala tão pequena que uma pessoa fazia todo o trabalho, então não
havia necessidade de separar o papel de designer e programador. No entanto, vários dos
entrevistados ainda atuam como programadores líderes em seus próprios projetos. Isso não quer
dizer que não se pode ser um grande designer sem ser um programador, mas acho que designers
que são capazes de programar têm uma vantagem sobre aqueles que não podem, uma vantagem
que lhes permite fazer melhor
jogos.

Quando é divertido?
Fazer sua jogabilidade funcionar é uma das partes mais essenciais do design de jogos, mas
também é uma das mais difíceis de tentar explicar ou ensinar. Muito do processo envolve entender
o que é divertido em um jogo de uma maneira que nenhum livro pode explicar. De fato, o design
de um jogo muda com tanta frequência durante o estágio de implementação que não acredito
Machine Translated by Google

294 Capítulo 15: Fazendo a jogabilidade funcionar

um designer que não esteja trabalhando ativamente no jogo durante esse período pode realmente
ser considerado como o projetou. Se esse chamado designer simplesmente digitasse um
documento de design de 200 páginas e o entregasse ao programador líder para implementar
enquanto o designer brincava em Bora-Bora, o programador líder seria responsável por tomar as
decisões fundamentais que tornaram o jogo divertido ou maçante, estimulante ou insípido,
agradável ou tedioso. Quando o designer está ausente durante o processo de implementação, o
programador líder provavelmente é quem está realmente projetando o jogo.

Os desenvolvedores de jogos
fazem o seu melhor trabalho

quando trabalham em jogos com


os quais se importam e gostam.
O excelente Grim

Fandango parece ser um exemplo


perfeito.

Grande parte da implementação do design do seu jogo depende de reações “instintivas”


pessoais que não é de se admirar que as pessoas tenham grande dificuldade em projetar jogos
para outras pessoas que não elas mesmas. É por isso que tantos jogos voltados para o “mercado
de massa”, mas que são projetados por pessoas que são jogadores hard-core, acabam sendo tão
terríveis. A jogadora hardcore que faz o design deseja estar trabalhando em Grim Fandango , mas
em vez disso está presa trabalhando em Advanced Squirrel Hunting. Mesmo que ela consiga
superar seu desprezo pelo projeto em si, ela provavelmente não terá ideia do que o público que
pode estar interessado em jogar Advanced Squirrel Hunting quer em seus jogos. Muitas vezes, os
recursos serão adicionados a um jogo a mando do marketing, devido aos protestos da equipe de
desenvolvimento. Esses recursos são sempre os piores do jogo, não necessariamente porque são
ideias ruins, mas porque a equipe de desenvolvimento não entende por que eles precisam ser
adicionados ao jogo ou como podem melhorar a experiência de jogo. No final, é muito difícil
projetar um bom jogo que você mesmo não goste de jogar. Se você não gosta de jogá-lo, é
improvável que outros também gostem, mesmo que tecnicamente se encaixem no gráfico de
demonstração que você estava mirando com tanto cuidado.
O primeiro passo no design de um jogo é fazer com que uma parte da jogabilidade funcione
e seja jogável. Depois de ter um protótipo que você pode jogar e achar atraente e divertido nas
quantidades certas, você deve dar um passo atrás e ter certeza de ter uma compreensão firme
sobre o que o torna divertido e como isso pode ser estendido para o resto do jogos. Com esse
protótipo como modelo, agora você pode seguir em frente para fazer o restante do conteúdo do
jogo, replicando a natureza fundamental da jogabilidade, mantendo os recursos adicionais
Machine Translated by Google

Capítulo 15: Fazendo a jogabilidade funcionar 295

conteúdo novo e interessante. Agora que você sabe que o design do seu jogo é bom, pode
finalmente fazer sentido criar um documento de design completo que explique essa
jogabilidade e explore quais variações podem ser usadas para o resto do jogo. Isso
fornecerá uma orientação valiosa para o resto da equipe no desenvolvimento do jogo. De
certa forma, uma vez que o protótipo está funcionando, a parte verdadeiramente criativa e
desafiadora do design do jogo é feita, e o resto do desenvolvimento do jogo é simplesmente
repeti-lo de forma eficaz.
Machine Translated by Google

Capítulo 16

Análise do jogo:
Mito: Os Caídos
Senhores

Desenhado por Jason Jones


Lançado em 1997

maneiras que ninguém mais conseguiu. Seu primeiro título, Minotaur, era um jogo
Os jogossomente
do designer/programador Jason
de rede antes que essas Jones
coisas sempre na
estivessem exploraram a tecnologia
moda (1992). em
Ele criou um
jogo excepcionalmente estimulante usando oponentes humanos em rede que não podiam ver
as telas uns dos outros. Pathways into Darkness pegou a tecnologia 3D simples e a aplicou a
um híbrido de ação/aventura para criar um mundo imersivo e baseado em histórias. Maratona

296
Machine Translated by Google

Capítulo 16: Análise do Jogo: Mito: Os Lordes Caídos 297

e Marathon 2 melhoraram essa tecnologia 3D e a aplicaram a um cenário de jogo de ação, mas com
um mundo de jogo mais instigante do que o encontrado em outros jogos de tiro em primeira pessoa da
época. Mais recentemente, Halo refinou muitos dos conceitos introduzidos em Mara thon, pegando a
física bruta encontrada no jogo antigo e trazendo-a para um novo nível, ao mesmo tempo em que
incorporava veículos, ambientes internos/externos maciços e personagens de IA inteligentes e
finalmente envolvendo tudo em um cenário de ficção científica inteligente e cativante. Entre a ação em
primeira pessoa de Marathon e Halo, no entanto, Jones partiu em uma direção de jogabilidade
totalmente nova com o jogo de estratégia Myth, mergulhando os jogadores em batalhas épicas de
combate estratégico como nenhum outro jogo havia feito. O que é mais importante notar, no entanto,
é que em nenhum desses jogos a tecnologia chega a dominar a jogabilidade, como é frequentemente
o caso quando um jogo usa tecnologia de ponta.
Em vez disso, nos jogos de Jones, a tecnologia e o design de jogos trabalham juntos para acentuar os
pontos fortes um do outro e criar experiências únicas e atraentes.

Desde seu segundo


jogo, Pathways into
Darkness, os jogos de
Jason Jones exploraram
a tecnologia para criar
novas experiências de
jogo.

Uso de tecnologia
O mito é um bom exemplo de pegar um gênero estabelecido e adicionar novos elementos a ele para
transformá-lo em algo novo e único. O gênero original em questão aqui são os jogos de estratégia em
tempo real, como WarCraft e Command & Conquer, que alcançaram uma enorme popularidade cerca
de um ano antes do desenvolvimento de Myth começar. Os jogos eram tão populares e pareciam
simples o suficiente para serem desenvolvidos do ponto de vista tecnológico que, de repente, todos os
editores precisavam ter um. Um mar de jogos clone logo inundou o mercado. A maioria desses jogos
tentou funcionar quase de forma idêntica ao WarCraft e Command & Conquer, com pequenas
melhorias, como sistemas de waypoint para movimentação de unidades e filas de produção. No
entanto, essas mudanças estavam longe de ser revolucionárias e, como resultado, esses jogos não
ofereceram nenhuma razão convincente para o público comprá-los. Consequentemente, eles
desapareceram sem deixar vestígios.
De certa forma, Myth fazia parte do movimento de estratégia em tempo real, mas Jones era
esperto demais para apenas clonar o sucesso dos jogos RTS. Em vez disso, ao que parece, ele examinou a
Machine Translated by Google

298 Capítulo 16: Análise do Jogo: Mito: Os Lordes Caídos

jogos de forma diferente e questionou como eles poderiam ser alterados e melhorados em um
nível mais fundamental. E se, em vez da tecnologia gráfica 2D que todos os jogos até agora
usavam, um jogo usasse um mecanismo verdadeiramente 3D? Com a única exceção de seu
primeiro jogo, Minotaur, os jogos de Jones até agora eram todos em 3D, então fazia sentido para
ele continuar a usar essa tecnologia para seu novo projeto. O componente 3D não seria
adicionado apenas para um toque visual, no entanto. Assim como o Wolfenstein 3D da id
Software , que anos antes havia pegado um jogo de ação relativamente simples e, ao incorporar
a tecnologia 3D, mudou drasticamente a natureza do próprio design do jogo, Myth pegou a
jogabilidade de estratégia e a moldou para se adequar à nova tecnologia. O resultado foi um
design de jogo totalmente novo, não apenas outro clone.
No entanto, parece que a tecnologia 3D usada não estava ditando completamente a direção
do design do jogo. O mecanismo 3D desenvolvido é especialmente adequado para modelar
ambientes externos e, portanto, oferecer suporte à jogabilidade RTS. Em vez de pegar a
tecnologia de seu jogo anterior, Marathon 2, e tentar fazer isso funcionar com um jogo de
estratégia em tempo real, Jones sabiamente recomeçou com um motor totalmente novo.
Marathon 2 usou um mecanismo BSP no estilo Doom, uma tecnologia adequada para ambientes
internos simples e não orgânicos, mas não tão propício às necessidades de jogos RTS, que
exigem ambientes abertos e externos para jogar bem. Assim, foi criado um novo motor de terreno
que se adequava exclusivamente aos requisitos de jogabilidade de um projeto 3D RTS.

Usando seu motor de


terreno 3D, o Myth adicionou
novos elementos de jogabilidade
à estratégia em tempo real
gênero.

Com a tecnologia 3D instalada, certas mudanças no design do jogo podem ser feitas na
forma RTS fundamental, conforme estabelecido por WarCraft e Command & Conquer. Em Myth,
a elevação do terreno onde o combate ocorreu teria um efeito dramático no desempenho das
unidades dos jogadores. Coloque os arqueiros no topo de uma colina para obter a máxima
eficácia. Coloque-os em uma ravina e veja-os serem abatidos. Myth também usa um sistema de
física simples, mas eficaz, que serve para enfatizar a natureza 3D da paisagem.
Quando os jogadores enviam um anão subindo uma colina para jogar um de seus coquetéis
molotov em um inimigo no topo daquela colina, eles devem estar preparados para a garrafa rolar
de volta colina abaixo antes de detonar. Caso o projétil atinja o alvo pretendido, os jogadores podem
Machine Translated by Google

Capítulo 16: Análise do Jogo: Mito: Os Lordes Caídos 299

maravilhe-se enquanto o chão no ponto de explosão ondula de uma maneira visualmente


interessante, alterando a paisagem pelo resto do jogo. Claro, se o alvo for morto, os jogadores
podem esperar que as partes do corpo daquele inimigo destruído rolem de volta colina abaixo em
direção ao anão.
Outra melhoria significativa que resulta do mecanismo 3D é a capacidade dos jogadores de ver
o campo de batalha em um nível de detalhe que não é possível em um jogo 2D de cima para baixo
ou isométrico. Os jogadores podem girar a câmera para ver objetos passados que podem obstruir
sua visão ou simplesmente encontrar o ângulo perfeito para uma determinada batalha. Além disso,
os jogadores podem facilmente ampliar e reduzir a ação. O zoom tem pouco benefício na jogabilidade
e é quase exclusivamente útil para a emoção visceral de ver uma batalha de perto, mergulhando os
jogadores na ação de uma maneira que os títulos 2D RTS simplesmente não conseguem. O ângulo
de visão também é significativamente diferente, estando em um ângulo muito mais baixo em relação
ao campo de batalha do que qualquer jogo de estratégia que o precedeu. A posição da câmera foi
sem dúvida escolhida em parte por razões estéticas e em parte por considerações de jogabilidade.
Independentemente das motivações, o resultado da visão de perto da batalha de Myth é uma
experiência decididamente mais íntima para os jogadores, onde as unidades individuais se tornam
mais importantes e mais reais do que em um jogo RTS com uma perspectiva mais distante. Assim,
a intimidade de um jogo de tiro em primeira pessoa como Marathon é casada com a jogabilidade
tática de um jogo de estratégia, resultando em um tipo totalmente novo de experiência de jogo.
O motor 3D empregado pelo Myth não é tão sofisticado, especialmente para os padrões
modernos. Os personagens na paisagem, por exemplo, são sprites simples em vez de bestas
poligonais totalmente 3D. Sem dúvida, isso foi importante para que um grande número de unidades
pudesse estar na tela ao mesmo tempo. Que graça teria um jogo RTS se pudesse ter apenas três
unidades na tela ao mesmo tempo? Na época, renderizar um grande número de criaturas
humanóides totalmente em 3D na tela de uma só vez levaria os PCs a rastejar, e ainda hoje pode
ser uma tarefa extremamente desafiadora.
Em Myth, cada pedaço de tecnologia é usado para seu maior efeito de jogabilidade, como é
típico de projetos executados por designers/programadores como Jones. Este desenvolvedor híbrido
entende o que a tecnologia pode fazer perfeitamente enquanto também entende o que seria atraente
em termos de jogabilidade, tornando o desenvolvimento de jogos muito econômico.
Assim, quando a tecnologia faz algo que pode melhorar a jogabilidade, o designer/programador
percebe instantaneamente e é capaz de explorá-la ao máximo.
Isso difere muito de muitos projetos em que os programadores implementam funcionalidades
complicadas que nunca são usadas porque os designers nunca a entendem completamente.
É claro que adaptar a jogabilidade de 2D para 3D tem suas desvantagens. Por exemplo, apesar
de ser capaz de aumentar e diminuir o zoom em Myth, nunca é possível diminuir o zoom da ação
tanto quanto gostaria. Isso se deve em parte ao precedente estabelecido por outros jogos RTS, que,
por causa de seus motores 2D, podem ter um ponto de vista muito mais distante, um ponto de vista
que se presta a rastrear e mover um grande número de unidades. Um patch foi lançado para Myth
logo após sua publicação que permitia aos jogadores diminuir o zoom da câmera, mas com o efeito
colateral de diminuir sua taxa de quadros, já que mais paisagem e, portanto, mais polígonos estão
agora à vista. Claro, o motor provavelmente poderia suportar a visualização da paisagem de ainda
mais longe, mas a quantidade de polígonos na tela rapidamente se tornaria proibitiva, diminuindo a
velocidade do jogo de forma inaceitável. Assim, as limitações de um motor 3D passam a restringir
as escolhas de jogabilidade que o designer pode fazer. Outra desvantagem de jogabilidade que
resulta
Machine Translated by Google

300 Capítulo 16: Análise do Jogo: Mito: Os Lordes Caídos

da tecnologia é a câmera muitas vezes confusa. Embora a câmera seja capaz de girar para ver o
lado desejado da ação, essa rotação da câmera pode muitas vezes se tornar chocante e
desorientadora, fazendo com que os jogadores percam o controle de diferentes locais e unidades
no mapa. É como se os jogos de estratégia anteriores tivessem usado um cinegrafista habilidoso
que geralmente mostrava aos jogadores o que eles queriam, mas para Myth o trabalho foi entregue
aos jogadores, que poderiam então ver exatamente qual parte do mundo eles queriam. Infelizmente,
a maioria dos jogadores não estava à altura do desafio de enquadrar a ação. Para um novato, um
jogador casual ou qualquer pessoa sem um bom senso de direção, o movimento da câmera
provavelmente seria totalmente incontrolável.

Foco do jogo

A jogabilidade de Myth
é totalmente focada no
combate tático, deixando de
fora o gerenciamento de
recursos encontrado em
muitos outros jogos RTS.

O mito também é um bom exemplo de um design de jogo bem focado. Como mencionado
anteriormente, Myth foi lançado vários anos após o sucesso de dois outros títulos RTS, Command
& Conquer e WarCraft. Em ambos os jogos, os jogadores constroem estruturas que exploram os
recursos naturais do terreno para criar unidades adicionais. Os jogadores podem então direcionar
essas unidades contra seus oponentes de várias maneiras. Assim, esses jogos RTS que definem
tendências são uma mistura de jogabilidade - parte gerenciamento e construção de recursos, parte
combate. Muitos dos títulos RTS subsequentes, tanto os sucessos quanto os fracassos, copiaram
esse modelo geral, dividindo os esforços dos jogadores entre criação de unidades, exploração de
recursos e implantação de unidades estratégicas.
Mas o Mito não apresenta recursos a serem minerados ou estruturas a serem construídas.
Em vez disso, os jogadores estão focados inteiramente no lado tático do jogo, na experiência de
combate. Os jogadores começam em um nível com uma determinada quantidade de unidades e,
para a maioria dos níveis do jogo, essas são as únicas unidades que recebem para todo o nível.
Em alguns cenários, unidades adicionais são adquiridas posteriormente no nível, mas esses
cenários são as exceções e não a norma. O mito acaba com tudo, exceto os elementos de combate
dos jogos RTS, o que dá à sua jogabilidade um foco único.
Machine Translated by Google

Capítulo 16: Análise do Jogo: Mito: Os Lordes Caídos 301

Essa ênfase tática tem várias ramificações no design geral do jogo. Primeiro, por não precisar se
preocupar com o desenvolvimento de um sistema de exploração de recursos, Jones conseguiu se
concentrar em tornar o modelo de combate o melhor possível. Isso resultou em um combate mais
sofisticado e detalhado do que qualquer outro jogo RTS da época. Em Myth, enfrentar unidades,
formação e posicionamento são mais importantes do que em outros títulos de estratégia. Como os
desenvolvedores não precisavam se preocupar com como os jogadores usariam os recursos, mais
tempo poderia ser gasto no sistema de física e outras tecnologias que melhorariam a experiência de
combate. Por exemplo, essa atenção aos detalhes significava que os arqueiros precisavam se
preocupar em encontrar um tiro certeiro entre as árvores, como o clima afetaria a trajetória de suas
flechas e como seu posicionamento vertical na paisagem afetaria a distância que eles poderiam atirar.

A incapacidade dos jogadores de construir unidades adicionais também afeta o cuidado com que
eles usam as unidades no início de um nível. Em WarCraft , pode-se cometer um erro substancial no
início de um nível e ainda ser capaz de vencer pelo uso inteligente de recursos e criação de unidades.
Em Myth, esse erro é muitas vezes fatal, com os níveis se tornando cada vez menos tolerantes à
medida que o jogo avança. O único recurso dos jogadores quando seu plano de ataque falha é
recarregar o nível. Isso cria um tipo de jogo muito diferente do encontrado em WarCraft. Em Myth, os
jogadores devem pensar completamente em suas ações, em vez de apenas tentar o que primeiro
surgir em suas cabeças. As unidades são muito mais preciosas e, como resultado, os jogadores
passam a cuidar de seu bem-estar. Já que mais coisas podem ser feitas facilmente, as unidades em
WarCraft podem parecer bucha de canhão. Por outro lado, em Myth , uma unidade em particular pode
ser crucial para terminar um nível, e não há como trazê-lo de volta depois que ele for morto.

Narrativa
Apesar de seu design de jogo exemplar, um grande componente do Myth é sua narrativa, que é
conduzida usando vários dispositivos bem integrados. Em primeiro lugar estão as cut-scenes, que
aparecem esporadicamente ao longo do jogo, delineando os principais pontos da trama e estabelecendo
certos níveis. Estes são frequentemente usados mais como “teasers” do que para realmente avançar
a história de forma significativa. Em segundo lugar estão os briefings da missão, que precedem cada
nível. Estes contêm uma grande quantidade de detalhes sobre a progressão da guerra entre a Luz e
as Trevas (as duas forças opostas do jogo). Eles também dão significado ao próximo nível, tornando
o objetivo da missão mais do que apenas uma tarefa arbitrária escolhida pelo designer de nível.

Terceiro, e mais interessante, são os dispositivos de contar histórias no jogo que são usados.
Claro, os níveis são definidos em locais que correspondem às necessidades do enredo, seja uma área
montanhosa congelada e estéril ou um poço de lava fumegante. As batalhas e missões contidas no
nível combinam com a história, conforme explicado pelos briefings da missão.
Mas os jogadores também podem ver e ouvir as trocas entre diferentes personagens dentro do jogo.
Por exemplo, um morador da cidade pode avisar as unidades dos jogadores sobre a localização de
um traidor. As tropas dos jogadores podem fornecer conselhos como: "É melhor voltarmos para a ponte!"
Embora os jogadores nunca percam o controle de suas unidades, o jogo é capaz de acionar esses
diálogos em diferentes pontos-chave nos níveis. Em uma missão, quando as tropas dos jogadores se
aproximam de uma massa intransponível de Myrmidons, o Avatara que os jogadores estavam
guardando dá um passo à frente e diz: “Deixe-me lidar com isso”. Ele inicia uma conversa com
Machine Translated by Google

302 Capítulo 16: Análise do Jogo: Mito: Os Lordes Caídos

o Fetch liderando as forças opostas e o enredo se desenrola ali mesmo no mundo do jogo durante
o tempo do jogo.

Myth conta uma história


convincente através de uma
combinação de briefings de
missão, design de níveis e
jogabilidade.

Em contraste com a maioria dos jogos que usam a narrativa como pouco mais do que um
complemento para um grupo de níveis já existente, o Mito torna a história, os níveis e a jogabilidade
dependentes uns dos outros, fortalecendo cada um como resultado. Os jogadores gostam de jogos
porque gostam da jogabilidade, não porque os jogos são acompanhados por cenas longas e não
interativas. No entanto, os jogadores gostam de ter histórias em seus jogos, pois podem dar
significado à jogabilidade. A melhor maneira de comunicar uma história profunda é torná-la parte
integrante da jogabilidade e revelar um pouco dela aqui e ali durante o tempo real do jogo, algo
que Myth faz habilmente. Claro, o fato de a história de Myth ser de primeira qualidade, o roteiro ser
bem escrito e a dublagem ser profissional certamente ajuda. Contar uma história através da
jogabilidade não fará um jogo nada bom se o enredo for banal, o diálogo for artificial ou a dublagem
for amadora.

Jogos pesados
Myth é um design de jogo feito por jogadores hard-core para jogadores hard-core e não se
desculpa por isso. Longe de tentar capturar o mercado gamer “mainstream” ou “casual” que tantas
empresas tentaram cortejar, Myth é um jogo que assustaria rapidamente qualquer um que ainda
não esteja familiarizado com outros jogos RTS e que não tenha o rápido -clicando habilidades
exigidas pelo mito. Não há nada de errado com isso, é claro, e é agradável ver um jogo que tem a
convicção artística de conhecer seu público e cumpri-lo. De fato, uma vez que os desenvolvedores
do jogo estão entre as fileiras dos jogadores hard-core, faz sentido que eles saibam melhor como
fazer um jogo que esse público goste. Muitas vezes, quando os jogadores hard-core tentam fazer
um jogo que o mítico jogador casual vai gostar, eles acabam fazendo um jogo que eles mesmos
não gostam muito, e que o jogador casual também não se importa muito. É muito difícil para um
artista fazer arte que apele a sensibilidades que estão em desacordo com a sua, o fim
Machine Translated by Google

Capítulo 16: Análise do Jogo: Mito: Os Lordes Caídos 303

resultado muitas vezes sendo trabalhos que são sem apelo para qualquer grupo ou demografia.
Mas o Mito não teve esse problema; seus desenvolvedores criaram um jogo que nenhum jogador
casual jamais seria capaz de jogar. Uma razão para isso é o conjunto de controles incrivelmente
sofisticado e desafiador. Por exemplo, considere o controle da câmera rotativa 3D. Ao contrário de outros
jogos RTS da época, onde a câmera só podia se mover horizontalmente junto com o terreno, a câmera
do Myth pode se mover horizontalmente, aumentar ou diminuir o zoom, girar em torno de um ponto ou
orbitar em torno de um ponto. Mesmo jogadores experientes acham um pouco desafiador se acostumar
com esse sistema. No entanto, uma vez que os movimentos da câmera são dominados, descobre-se que
eles são habilmente projetados e fornecem toda a liberdade que se poderia esperar, dada a tecnologia
que o jogo usa. O jogo também está repleto de teclas especiais para diferentes comandos, como
formações, ações especiais e ataques alternativos. Novamente, esses comandos, uma vez dominados,
fornecem aos jogadores um grande grau de controle sobre como suas unidades se movem e atacam,
mas levam algum tempo para aprender. De fato, essas teclas tornam o jogo impossível de jogar apenas
com o mouse, algo em que quase todos os outros jogos RTS se concentram. O “gesto-clique” é outro
recurso interessante, usado para apontar unidades em uma determinada direção quando chegam a um
determinado local. O sistema de cliques por gestos é bastante poderoso, mas quase impossível de
aprender sem ser ensinado pessoalmente ou praticando muito.

No entanto, para os jogadores hard-core que estão dispostos a dedicar tempo para aprender os controles,
o resultado final é uma experiência de jogo extremamente agradável.
O mito também é um jogo inerentemente difícil. Mesmo para jogadores experientes em títulos RTS,
o jogo provará ser extraordinariamente difícil desde o início. Normalmente, os jogos incluem alguns níveis
simples no início do jogo, a fim de dar aos jogadores uma chance de lutar enquanto ainda estão
aprendendo os controles. O mito não. Imediatamente, os jogadores são apresentados a objetivos
dificilmente alcançáveis, onde um erro pode tornar o nível virtualmente invencível. Ao simplificar o jogo
para se concentrar na experiência tática, os jogadores têm muito menos chance de voltar atrás, já que
literalmente não há como reconstruir suas tropas. A perda de uma unidade específica muitas vezes fará
com que jogadores experientes concluam que o nível agora é muito difícil de vencer, então por que se
preocupar? Eles apenas reiniciarão o nível. O triste é que, apesar de sua grande dificuldade, os níveis
no início do jogo são os níveis fáceis, com os níveis se tornando exponencialmente mais difíceis a partir
daí. No entanto, este é o tipo de desafio que os jogadores verdadeiramente hard-core prosperam. Não é
que os desafios sejam injustos, arbitrários ou imprevisíveis, pelo menos nem sempre. Na maioria dos
casos, os jogadores podem vencer os níveis na primeira vez; é apenas extraordinariamente difícil fazê-lo.

O mito é o tipo de jogo que muitos editores exigiriam que fosse simplificado para que os jogadores
não-hard-core não se assustassem com seus controles complexos ou nível sádico de dificuldade. Mas
se o jogo fosse simplificado significativamente, ainda seria tão atraente quanto agora? Provavelmente
não. Para qualquer pequeno número de jogadores casuais que pudesse ser ganho, um grande número
de jogadores hard-core seria perdido.

Multi-Player Assim como

nos jogos Marathon anteriores e nos jogos Halo depois, a Bungie criou o Myth para se destacar tanto
como um jogo para um jogador quanto como uma experiência para vários jogadores. O mais notável
sobre isso é que a Bungie consegue fazer as duas coisas tão bem. Muitos jogos são criticados
Machine Translated by Google

304 Capítulo 16: Análise do Jogo: Mito: Os Lordes Caídos

por enfatizar um sobre o outro. Quake e Quake II, por exemplo, foram elogiados por seu sólido jogo
em rede enquanto eram criticados por seus jogos single-player sem brilho. Muitos outros jogos
parecem adicionar suporte a vários jogadores como uma reflexão tardia, na esperança de obter
outro ponto de bala na parte de trás da caixa. Centipede 3D é um bom exemplo disso, onde o multi-
player foi adicionado no final do projeto como uma consideração de marketing, e quase nenhum
tempo de design foi gasto para torná-lo divertido.
Vale a pena notar a estratégia bem divulgada da Bungie para fazer um jogo que se destaca
nas arenas de um e vários jogadores. Depois de estabelecerem a tecnologia principal do mecanismo
para o jogo, tornar a rede funcional é o próximo passo. Uma vez que funciona, toda a equipe começa
a jogar jogos em rede e continua jogando até que sejam divertidos. Neste ponto, nenhum trabalho
começou no jogo para um jogador, e a equipe está totalmente focada em melhorar a experiência de
jogo em rede. Somente após a conclusão do design central do jogo em rede, a equipe começa a
trabalhar no jogo para um jogador.
No entanto, isso não quer dizer que o jogo single-player seja apressado. Em vez disso, essa
técnica força a equipe a ter uma pré-produção sólida concluída antes que o tempo seja gasto no
jogo para um jogador. Isso significa que toda a equipe sabe o que “funciona” e torna o jogo divertido
antes mesmo de qualquer nível solo ser criado, resultando em menos retrabalho nesses níveis e
levando a níveis mais divertidos no produto final.
É porque a equipe passou tanto tempo jogando o jogo multi-jogador que os jogos na rede têm
a profundidade de se manter ao longo do tempo. Se a equipe estivesse criando uma experiência
superficial, rapidamente se cansaria dela. O multi-jogador do Myth permite muitos tipos de jogo
diferentes com uma variedade de objetivos, todos exigindo estilos de jogo diferentes.
O interessante sistema de troca de unidades pré-jogo permite que os jogadores criem seu próprio
time “matador”, assim como os jogadores de Magic: The Gathering gastam tempo desenvolvendo o
baralho de cartas perfeito. O jogo em equipe, onde vários jogadores controlam um conjunto de
unidades aliadas e enfrentam outro time, abre muitas possibilidades para estratégias muito
complexas para uma única pessoa realizar. É por causa do tempo que a equipe de desenvolvimento
da Bungie passou jogando o jogo multijogador que ele tem um poder de permanência tão impressionante.

Um todo coeso
O mito também está repleto de pequenos toques de design que adicionam um certo brilho à base
sólida do design central. Enquanto as missões em outros jogos RTS existem como espaços de jogo
independentes e separados, no Myth as missões se tornam parte do todo devido ao uso de unidades
“veteranas”. Essas unidades, se sobreviverem a uma determinada batalha, estarão disponíveis para
os jogadores usarem no próximo nível, e suas habilidades serão notavelmente mais fortes do que
as unidades iniciantes. Isso faz com que os jogadores tratem essas unidades com cuidado especial,
gastando os novatos em explorações mais perigosas. Outro toque legal é a capacidade das unidades
de deixar pegadas no terreno, o que adiciona um elemento interessante para rastrear inimigos em
níveis cobertos de neve. A variedade de missões disponíveis fornece um conjunto de objetivos
muito mais diversificado do que muitos outros jogos RTS, fazendo com que os jogadores modifiquem
drasticamente seu estilo de jogo de nível para nível.
Claro, Myth não está isento de problemas, mesmo que se possa aceitar os controles
desafiadores e os níveis incrivelmente difíceis. Clicar no mapa aéreo às vezes faz com que a câmera
gire de maneiras que os jogadores não esperam, possivelmente jogando fora sua orientação no
mundo e quebrando completamente sua imersão. O mapa aéreo é
Machine Translated by Google

Capítulo 16: Análise do Jogo: Mito: Os Lordes Caídos 305

Os desenvolvedores de Myth
prestaram muita atenção aos
detalhes, o que ajudou a criar
uma experiência de jogo
profunda.

realmente translúcido e desenhado sobre o campo de jogo, o que às vezes pode fazer com
que os jogadores cliquem nele por acidente. O desejo de ver mais do campo de jogo de uma
vez é válido, mesmo que seja uma limitação da tecnologia. No entanto, essas são falhas
realmente pequenas em um design extremamente impressionante. O mito representa como
um grande jogo pode crescer a partir do casamento de tecnologia e jogabilidade. Este não é
um casamento de espingarda, no entanto, mas sim um onde a noiva e o noivo pensaram
cuidadosamente como podem viver felizes juntos, aprimorando os pontos fortes um do outro,
criando algo novo e emocionante no processo.
Machine Translated by Google

Capítulo 17
Desenvolvimento de jogos
Documentação

“Omita palavras desnecessárias. A escrita vigorosa é concisa. Uma frase não deve conter
palavras desnecessárias, um parágrafo não deve conter frases desnecessárias, pela
mesma razão que um desenho não deve ter linhas desnecessárias e uma máquina não
deve ter partes desnecessárias. Isso não requer que o escritor faça todas as suas frases
curtas, ou que ele evite todos os detalhes e trate seus assuntos apenas em linhas gerais,
mas que cada palavra deve contar.”
— William Strunk em seu livro The Elements of Style

mentos, e os fará apenas para atender aos gestores que demandam sua criação.
Muitos designers de jogos
O design se proclamarão
de jogos, melhores
esses designers do quepodem
obstinados documentos
insistir, de desenvolvimento
é algo que não se
pode escrever em um pedaço de papel. E esses designers estão parcialmente corretos; escrever
documentação de desenvolvimento de qualidade é muito difícil. Grande parte do desenvolvimento

306
Machine Translated by Google

Capítulo 17: Documentação de desenvolvimento de jogos 307

documentação que você pode encontrar parece ter sido escrita apenas para
talvez para aplacar um editor que exige ver algo no papel. No entanto, a documentação tem um lugar legítimo na
criação de computadores modernos.
jogos, e é trabalho do designer garantir que esses documentos sejam criados, mantidos e usados de forma eficaz.

A necessidade de documentação de desenvolvimento de jogos é um efeito colateral do aumento do tamanho


das equipes de desenvolvimento de jogos. Nos primeiros dias de desenvolvimento de jogos, quando um
equipe de desenvolvimento consistia em um indivíduo multi-talentoso, documentar a funcionalidade do jogo era
menos importante. Se essa pessoa foi capaz de estabelecer e
implementar uma visão para a jogabilidade do projeto, não importava se ele a escreveu
para baixo ou não.

À medida que as equipes de desenvolvimento cresceram de um para cinco, de cinco para dez, de dez para vinte,
de vinte a trinta, e para a frente e para cima, manter o foco do projeto tornou-se
cada vez mais um problema. À medida que os membros da equipe se tornaram cada vez mais especializados em
certas áreas, um documento de referência que eles pudessem consultar para ver como um determinado sistema
deveria funcionar e como seu trabalho se encaixava no projeto se tornava necessário.
E assim, várias peças de documentação passaram a ser utilizadas, como o documento de projeto,
a bíblia da arte, o documento de design técnico e inúmeras outras obras de referência para
orientando a criação do conteúdo de um jogo. Os documentos de desenvolvimento podem ser uma forma chave de
“segurar as rédeas com força” em um projeto, para garantir que ele não saia do controle
por causa das ambições impraticáveis dos membros da equipe. Anotar ideias e histórias
componentes é uma maneira útil de perceber rapidamente quando um jogo está sendo superprojetado e
se o projeto pode ser concluído no prazo.
Bons documentos trazem benefícios não apenas para o lado da produção do jogo
desenvolvimento, mas também para melhorar o design do jogo em si. Chris Crawford escreveu
mais sobre design de jogos do que provavelmente qualquer outra pessoa, como uma visita ao seu site
(www.erasmatazz.com) será revelado. Crawford usa documentos para refinar e aprimorar seus
próprias ideias e acompanhar como um projeto evolui ao longo de seu desenvolvimento. Pessoalmente, uso um
steno pad para guardar todos os meus pensamentos para um determinado projeto. eu acho que eu posso
depois volte e revise essas notas para ver como cheguei a uma decisão de design específica,
e recordar boas ideias que há muito esqueci.
Claro, é perfeitamente possível ir longe demais na outra direção, gastar todo o
seu tempo trabalhando na documentação e nada disso desenvolvendo o jogo.
E ter uma quantidade enorme de documentos repetitivos certamente não é benéfico, especialmente se a equipe
sentir que está à deriva em um mar de documentação, sem nada
realmente prático para o seu trabalho. Também é possível fazer jogos sem nenhum tipo de
documentação, mas com uma equipe de qualquer tamanho será extremamente difícil. Se alguém espera
trabalhar em uma casa de desenvolvimento ou em uma editora que torna comercialmente viáveis, jogos de
computador profissionais, acostumar-se a trabalhar com documentação é uma necessidade absoluta
necessidade.
Machine Translated by Google

308 Capítulo 17: Documentação de desenvolvimento de jogos

Documente seu jogo


Como designer de jogos, você estará principalmente preocupado com o que é comumente
chamado de documento de design, que explorarei em detalhes no Capítulo 19. No entanto,
existem muitas outras peças de documentação usadas na criação de jogos de computador
modernos. Mesmo que você não trabalhe com todos esses documentos, é importante entender
o que cada um deles deve conter e como os diferentes documentos estão inter-relacionados.
Portanto, antes de se aprofundar na natureza dos documentos de projeto, é apropriado fazer
um levantamento dos diferentes tipos de documentos. Pessoas diferentes em empresas
diferentes ou em situações diferentes invariavelmente usarão uma variedade de nomes
diferentes para os documentos listados abaixo. Você deve perceber que a convenção de
nomenclatura que emprego aqui não é universal, mas os tipos de documentos usados são
bastante comuns em toda a indústria de desenvolvimento de jogos.

Documento de conceito, documento de apresentação ou proposta


Estes são geralmente os primeiros documentos formais criados para um determinado jogo.
Muitas vezes eles são escritos para vender a ideia de um jogo para uma editora (se o autor
trabalha para um desenvolvedor que não publica seu próprio trabalho) ou para a alta
administração (em uma empresa que publica projetos desenvolvidos internamente). Em suma,
este documento é mostrado ao comitê de luz verde, o dinheiro, os processos, os tomadores de
decisão, ou o que quer que se chame, para convencê-los a gastar muito dinheiro na ideia,
financiando assim sua desenvolvimento. Documentos conceituais são as sementes que têm o
potencial de crescer em um jogo completo, mas muitas vezes nunca têm a oportunidade.
Documentos conceituais geralmente são curtos, geralmente não mais do que dez páginas e,
em sua forma mais elegante, incluem muitas artes conceituais. Muitas vezes, os documentos
conceituais se concentram exclusivamente em questões de design de alto nível, explorando a
jogabilidade única que o título fornecerá, detalhando a história do jogo e geralmente fazendo
todos os esforços para deixar o leitor empolgado com o projeto. Escrever um documento
conceitual pode ser muito divertido, já que o escritor consegue se concentrar nas partes mais
emocionantes do jogo e não precisa se preocupar com todos os detalhes confusos da
implementação do jogo. Ao mesmo tempo, é importante não exagerar e prometer o inatingível
com o seu documento de apresentação, já que os leitores mais astutos rapidamente perceberão a implausib
Documentos conceituais às vezes podem ir um pouco além das ideias de alto nível para
se tornarem significativamente mais elaborados. Nesse caso, eles geralmente são escritos por
um comitê, geralmente envolvendo o produtor do jogo, o designer-chefe, o programador-chefe,
qualquer pessoa de marketing que esteja disponível e os artistas principais que contribuem com
uma variedade de esboços, peças conceituais e maquetes de tela. Documentos conceituais
discutem todos os aspectos da ideia do jogo em questão, incluindo como ela pode ser
posicionada no mercado, orçamentos e cronogramas de desenvolvimento, qual tecnologia será
usada, qual será o estilo de arte do jogo, mini-bios dos membros da equipe que esperam
trabalhar no jogo, e uma descrição ampla da jogabilidade. Esses documentos não são muito
úteis no desenvolvimento real do jogo, embora possam ser um trampolim para a criação de
outros documentos, como o documento de design ou a bíblia da arte. Como os documentos
conceituais não se aplicam muito ao desenvolvimento real do jogo, não entrarei em mais
detalhes sobre eles.
Machine Translated by Google

Capítulo 17: Documentação de desenvolvimento de jogos 309

Analise competitiva

Ao escrever uma
análise competitiva, você
precisará incluir uma
discussão e potencialmente
capturas de tela dos líderes
do gênero do seu título.
Para um título RTS, você
quase certamente gostaria
de discutir WarCraft III.

A análise competitiva é outro documento usado na tentativa de vender seu jogo. Às vezes, as
análises competitivas são escritas nos estágios iniciais de um jogo que já recebeu sinal verde, para
mostrar claramente ao departamento de marketing como o jogo se sairá no mercado. Ele
normalmente inclui uma versão mais curta e condensada do documento de apresentação e lista
especificamente os recursos exclusivos do jogo que está sendo desenvolvido.
A análise competitiva lista uma série de outros jogos que foram lançados no passado recente que
são semelhantes ao jogo proposto, fornece uma breve sinopse da ficção e da jogabilidade de cada
um e descreve como cada um desses jogos se saiu (via revisão média pontuação, citações de
várias revisões e números de vendas, se disponíveis).
Para cada um desses jogos lançados anteriormente, o documento continuará descrevendo como
esse jogo se compara ao novo jogo que está sendo desenvolvido. Por exemplo, se você estivesse
escrevendo uma análise competitiva para um jogo de estratégia em tempo real proposto,
provavelmente gostaria de incluir os jogos mais recentes das principais franquias RTS, como a
mais recente adição à série Command & Conquer , a série WarCraft , e a série Age of Empires .
Documentos de análise competitiva normalmente não ajudam muito no desenvolvimento, mas
podem fornecer uma verificação da realidade útil para ajudá-lo a perceber que o jogo que você
espera criar realmente é exatamente o mesmo que outro título lançado seis meses atrás.

Documento de projeto
Em outras partes da indústria de desenvolvimento de software, o equivalente do documento de
projeto é freqüentemente chamado de especificação funcional. De fato, alguns desenvolvedores
de jogos se referem ao documento de design como a especificação funcional. Prefiro “documento
de design” porque é o termo mais usado e porque representa melhor o conteúdo do documento. O
objetivo do documento de design é descrever e detalhar completamente a jogabilidade do jogo.
Para grandes projetos de equipe, o documento de design serve como um trabalho de referência
vital de como os diferentes aspectos do jogo precisam funcionar, com, idealmente, equipe
Machine Translated by Google

310 Capítulo 17: Documentação de desenvolvimento de jogos

membros referindo-se a ele ao longo do desenvolvimento do jogo. Os produtores costumam usar


o documento de design como um trampolim para agendar o projeto. Um documento bem escrito e
completo também pode ser de vital importância quando um jogo é
posteriormente convertido para outra plataforma por uma equipe de desenvolvimento diferente. O
documento pode servir como uma ferramenta de referência ideal para essa nova equipe entender como o
jogo deve funcionar quando eles começam a portá-lo para um novo sistema, assumindo que é
atualizados ao longo do projeto.
Considerando que uma especificação funcional para, digamos, um aplicativo de planilha pode ser
extremamente detalhado e completo, um documento de design para um jogo é necessariamente menos
completa por causa da natureza mais orgânica, dinâmica e iterativa do desenvolvimento de jogos, como
discuti no Capítulo 15, “Como fazer a jogabilidade funcionar”. Como desenhista
trabalhando em um grande projeto de equipe, o documento de design será a especificação primária
com o qual você precisará se preocupar. A essência de um documento de design é o detalhamento da
mecânica do jogo: o que os jogadores são capazes de fazer no mundo do jogo, como eles fazem
e como isso leva a uma experiência de jogo atraente. Documentos de design normalmente também
incluem os principais componentes de qualquer história que o jogo possa contar e um
detalhando os diferentes níveis ou mundos que os jogadores encontrarão no jogo. Além disso
incluídas serão listas de diferentes personagens, itens e objetos que os jogadores irão
interagir no mundo do jogo. Pode-se pensar nos aspectos importantes do design
documento como não muito diferente do que um jornalista procura em uma notícia: o que o
jogadores fazem (quais ações os jogadores podem realizar), onde eles fazem (o cenário do jogo),
quando eles fazem isso (em que hora e em que ordem os jogadores devem realizar
diferentes ações), por que eles fazem isso (as motivações dos jogadores) e como eles fazem isso (o que
comandos são usados para controlar o jogo).
O documento de design também pode ser definido pelo que não inclui. A maioria dos
conteúdo contido nos outros documentos listados neste capítulo não deve ser encontrado em
o documento de design, incluindo a maior parte das informações encontradas no roteiro, o documento
de design técnico e a bíblia da arte. Em particular, um documento de projeto não deve
gastar algum tempo descrevendo o desenvolvimento do jogo do ponto de vista técnico. Forma da
plataforma, requisitos do sistema, estrutura de código, algoritmos de inteligência artificial e o
como são todos os tópicos que devem ser abordados no documento de design técnico e, portanto,
evitados no documento de projeto. O documento de design deve descrever como o jogo
funcionará, não como essa funcionalidade será implementada.
Da mesma forma, discussões sobre o marketing do jogo, explorações de como ele
ser posicionado em comparação com outros jogos no mercado, e as projeções de vendas são todas
inadequado no documento de projeto. Além disso, cronogramas, orçamentos e outras informações de
gerenciamento de projetos devem ser omitidos. Esta informação certamente deve ser
registrado em alguns documentos, como o documento de apresentação ou cronograma do projeto, mas
devem ser estritamente excluídos do documento de projeto. Eu pensaria que tal exclusão seria óbvia
para qualquer pessoa que estivesse realizando um documento de design, mas já vi muitos
documentos de design que gastaram metade de suas páginas considerando como o jogo será vendido.
O documento de design precisa descrever como o jogo funciona para que alguém
trabalhando na equipe de desenvolvimento pode ver exatamente o que ele precisa criar. Incluindo
materiais que são mais sobre o lado comercial do desenvolvimento do jogo só serão
na forma de informações mais apropriadas.
Machine Translated by Google

Capítulo 17: Documentação de desenvolvimento de jogos 311

O documento de projeto e sua criação são discutidos com mais detalhes no Capítulo 19, “O
Documento de Projeto”. Você pode encontrar exemplos de documentos de projeto nos dois
apêndices deste livro.

Fluxogramas

Os fluxogramas podem frequentemente ser incluídos como parte do documento de projeto ou como
documentos separados. No desenvolvimento de jogos, os fluxogramas têm dois usos principais. A
primeira é rastrear a navegação dos jogadores em opções de menu fora do jogo, como aquelas que
os jogadores usam para iniciar um novo jogo ou carregar um salvo. Os fluxogramas também podem
ser usados para mapear as áreas em que os jogadores progridem no jogo, principalmente em jogos
baseados em níveis. Além dessas aplicações mais óbvias, os fluxogramas podem ser bastante úteis
para representar visualmente os resultados de quaisquer decisões que os jogadores possam tomar
em seu jogo. Os fluxogramas são um meio de representar visualmente uma parte da jogabilidade,
seja micro ou macro, e muitas vezes podem evoluir para árvores de decisão completas com muitos
ramos, cada um representando uma escolha do jogador que leva a novas escolhas ou volta a
decisões anteriores. Essas representações visuais podem ser úteis não apenas para um designer
tentando descobrir quais serão as consequências das ações de um jogador, mas também para
comunicar a sequência de eventos e escolhas para outros membros da equipe. Com cenários
complexos envolvendo muitas ramificações, uma representação de fluxograma será muito mais
eficaz para transmitir suas ideias do que o que você poderá transmitir apenas com texto. Os
fluxogramas podem ser feitos à mão ou desenvolvidos usando várias ferramentas de criação de fluxogramas,

Bíblia de histórias

Para jogos que contam histórias, uma parte dessa história deve ser incluída no documento de
design. Certamente, um resumo da história geral do jogo é essencial, e uma descrição completa do
fluxo do jogo precisará incluir partes da história, mas o documento de design geralmente não pode
incluir tudo. Isso é especialmente verdadeiro se o jogo que está sendo desenvolvido envolve uma
história complexa com uma variedade de personagens e locais, ou se o jogo se passa em um
universo com uma história específica. Uma bíblia de histórias pode ser o melhor lugar para
documentar essas informações. Muitas vezes, o autor da história de um jogo terá em mente uma
visão para o universo e seus habitantes além do escopo do jogo, como de onde vêm os personagens
do jogo e quais são suas motivações, e como o mundo do jogo veio a ser o estado em que está
quando os jogadores o encontram. O que os jogadores experimentam pode ser apenas a ponta do
iceberg proverbial, com o autor da história tendo em mente dez vezes mais detalhes sobre o mundo
do jogo do que é realmente comunicado aos jogadores através do jogo. Outros aspectos do universo
podem apenas ser sugeridos. Ao ter um plano completo para a história de fundo do jogo, mesmo
que os jogadores não aprendam tudo diretamente, o escritor da história terá uma chance muito
maior de manter a narrativa do jogo consistente e plausível.

Uma bíblia de histórias, então, é um bom lugar para documentar a história de fundo
potencialmente extensa de um jogo. Separar essas informações do documento de design
propriamente dito evita sobrecarregá-lo com muitas informações que são menos centrais para a
criação do jogo. Pesar um documento de design com muita história de fundo é uma maneira fácil de
dar profundidade e completude perceptíveis, mas pode esconder o fato de que a especificação não
cobre totalmente a mecânica do jogo e outras informações mais vitais. No entanto, a história de fundo ainda é
Machine Translated by Google

312 Capítulo 17: Documentação de desenvolvimento de jogos

importante e, portanto, o valor de sua documentação na bíblia da história. Uma vez que uma bíblia
de história foi criada, quando um artista deseja aprender mais sobre o personagem que está
modelando, ele pode recorrer à bíblia e descobrir sobre a infância desse personagem. Ele pode
tornar sua arte melhor, ajustando-a à história de fundo. Quando um dublador se pergunta como ele
deve interpretar esse mesmo personagem, se ele leu a bíblia da história, ele estará trabalhando na
mesma base de informações que o artista. Usada corretamente, uma bíblia de histórias pode
aumentar a consistência de um jogo.
Caso haja uma sequência ou um spin-off feito do jogo, a bíblia da história do jogo se torna
ainda mais útil quando a equipe de desenvolvimento do projeto derivado tenta entender que tipo de
nova linha de história pode ser criada. Como a bíblia da história incluiu mais conteúdo do que
realmente foi usado no projeto original, ela fornecerá à nova equipe muitas áreas inexploradas do
universo do jogo. Se a bíblia da história for seguida corretamente, o novo jogo se encaixará em
perfeita continuidade com o original. À medida que essa equipe cria o novo jogo, a bíblia pode ser
expandida e atualizada para que projetos futuros sejam igualmente consistentes.

O formato de uma bíblia de histórias é bastante aberto, e o autor da bíblia deve fazer o formato
mais adequado às informações que ele planeja incluir. Muitas vezes, a bíblia da história consiste
em várias narrativas históricas diferentes de comprimentos variados. Uma narrativa pode descrever
a história do mundo do jogo, detalhando os principais eventos que levaram o mundo ao estado em
que se encontra quando os jogadores iniciam o jogo. Da mesma forma, o documento pode incluir
narrativas para os diferentes personagens principais que os jogadores encontram no jogo. Os
tópicos discutidos incluem a infância do personagem, como ele subiu para qualquer posição que
ele tenha no jogo e o que motiva o personagem a agir como age. Ao ter uma noção do passado do
personagem, quando chegar a hora de escrever o roteiro do jogo, o escritor do jogo estará melhor
equipado para criar diálogos convincentes e críveis para os diferentes personagens. De menor
importância, mas talvez ainda apropriadas para a bíblia da história, são as histórias dos vários itens
ou locais principais que os jogadores encontram no mundo. Uma espada poderosa pode ter uma
história colorida que os NPCs podem sugerir quando falam do objeto para os jogadores. Um
santuário em particular pode ter um segredo obscuro próprio. No entanto, o autor deve sempre ter
o cuidado de tentar manter em mente quanta informação será realmente útil para a criação do jogo,
e não deve se sentir obrigado a explicar completamente a linhagem de cada último personagem e
objeto do jogo.
Inclua apenas as informações que você acha que serão importantes para a criação do jogo.
O estilo de escrita da bíblia da história deve ser mais em prosa do que o estilo de ponto de
bala do próprio documento de design. É mais provável que um membro da equipe usando uma
bíblia de histórias queira sentar e ler algumas páginas de cada vez, e apreciará o conteúdo da
bíblia que lê e flui bem. Dividir o documento por caractere, item ou evento importante ainda é útil
para o leitor, portanto, é uma boa ideia usar uma boa quantidade de títulos com títulos apropriados.
Você também pode incluir vários diagramas no documento para complementar o conteúdo escrito,
como linhas do tempo, fluxogramas de eventos ou árvores de relacionamento de caracteres. Esses
gráficos podem ser úteis para permitir que o leitor entenda um mundo de jogo particularmente
complexo.
Por outro lado, mesmo com um mundo de jogo complexo, você pode não precisar de uma
bíblia de histórias. Se o autor do roteiro do jogo consegue acompanhar os personagens e suas
motivações em sua cabeça, e se a probabilidade de uma sequência trabalhada por outra equipe
for baixa, a criação de uma bíblia de história complexa pode não ser um bom uso tempo de ninguém. Tudo
Machine Translated by Google

Capítulo 17: Documentação de desenvolvimento de jogos 313

depende do estilo de trabalho da equipe, principalmente do designer-chefe e do roteirista, que podem


ou não ser a mesma pessoa. Certamente muitos grandes autores conseguiram escrever romances
muito mais complexos do que o seu jogo provavelmente será sem manter mais do que algumas notas
rabiscadas para si mesmos, se tanto. Muitos filmes complexos têm apenas um roteiro para suas
histórias, com os atores responsáveis por interpretar as motivações de seus personagens com base
apenas nas falas que eles deveriam falar. Pode ser que o autor do roteiro tenha criado uma bíblia de
histórias para seu uso pessoal, e nunca achou por bem compartilhá-la com mais ninguém. A bíblia da
história é uma ferramenta que pode ajudar na criação da história do jogo, mas pode não ser uma
ferramenta que todo roteirista ou designer de jogos sente necessidade de usar.

Roteiro
Se um jogo tem uma história, é bem provável que em algum momento os jogadores sejam solicitados
a ouvir a narração, ouvir os personagens falando ou ler informações sobre as próximas missões. Este
diálogo e as descrições que o acompanham das situações durante as quais o diálogo ocorre (direções
do palco) devem estar contidos no roteiro do jogo. O roteiro de um jogo pode ser escrito por uma
variedade de pessoas: um designer, um artista, o produtor do jogo ou alguém cuja única função no
projeto é escrever o roteiro, alguém que foi contratado especificamente por suas habilidades de
escrita de diálogos.
O script pode assumir diferentes formas dependendo do tipo de eventos do jogo que o diálogo
acompanhará. Por exemplo, se o jogo tem cutscenes no estilo de filme, o roteiro pode se assemelhar
a um roteiro de filme, com descrições das ações que os jogadores testemunham e indicações
aproximadas do que a câmera está olhando em um dado instante. Ou o roteiro dessas cut-scenes
pode ser mais parecido com o de uma peça de teatro, focando principalmente no diálogo. Para
conversas no jogo, o script se concentrará principalmente no diálogo, já que os jogadores ainda estão
no controle do jogo e, portanto, no controle da direção em que a câmera do jogo está apontando. Mas
um roteiro para as cut-scenes do jogo pode incluir “direções de palco” ou “direções definidas” junto
com descrições para as animações de personagens que o acompanham para ajudar o artista a criar
os movimentos apropriados para acompanhar o diálogo.

Por exemplo, aqui está um trecho de um script que poderia ser usado para uma cena em um
jogo de aventura:

Quando o JOGADOR se aproximar de PAUL e SANDY após ressuscitar a ÁRVORE DA PÚBLIA,


PAUL ficará visivelmente emocionado com a chegada do jogador. Ele imediatamente explode
em elogios efusivos pelas conquistas do jogador:
PAUL: Essa é a solução pela qual temos orado! Você salvou nossa grande Árvore, e nada
que possamos fazer poderá agradecer o suficiente. Por favor, aceite este sinal de nossa
gratidão...
PAUL joga um SACO DE FLIMFLAMS aos pés do jogador. SANDY dá um passo à frente:
SANDY: [Apologeticamente] Sabemos que não é muito, mas...
PAUL: [Interrompendo] É tudo o que temos!
SANDY: [Encolhendo-se] Por favor, não nos odeie por nossa pobreza...
Machine Translated by Google

314 Capítulo 17: Documentação de desenvolvimento de jogos

A natureza não linear dos jogos exige que o roteiro seja organizado e apresentado de forma diferente de
um roteiro de peça, filme ou televisão. Se os jogadores tiverem conversas ramificadas com NPCs, como
em um RPG ou em um jogo de aventura, o script precisará assumir uma forma especial conducente à
natureza não linear do intercâmbio. Aqui, um script pode usar pequenas quantidades de pseudocódigo,
usando IF-THEN-ELSE ou taxa de sintaxe do tipo SWITCH para comunicar quando os jogadores ouvirem
diferentes partes do diálogo.
Voltando ao nosso exemplo de jogo de aventura, aqui está um layout possível para uma conversa
mais não linear. Este jogo utiliza o antigo sistema de conversação “palavra-chave”, onde os jogadores
digitam uma palavra e o personagem com quem se está falando pode ou não ter informações sobre
aquele assunto: SE o jogador perguntar sobre “FLIMFLAM”:

PAUL: Um FlimFlam é uma gota de orvalho, caída do céu da manhã, cuidadosamente


embrulhada em uma folha de bebê da Árvore da Abundância. Possui propriedades curativas
especiais para Humanóides, quando esfregado na nuca.

SE o jogador perguntar sobre “TREE” OU “PENTY”:


PAUL: A Árvore da Abundância tem sido a fonte de vida do meu povo desde antes que
qualquer um de nós possa se lembrar. Sem a sombra que ela proporciona, meu povo fica
exausto ao sol do meio-dia. Sem suas folhas, não temos nada para comer. Sem sua força, meu
povo é fraco.
DEFAULT, se o jogador perguntar sobre qualquer outra coisa:
PAUL: Eu não sei do que você fala, estranho. Não somos o mais inteligente dos povos; não
somos tão sábios quanto um grande viajante, como você.
O diálogo no jogo pode variar aleatoriamente entre várias expressões que comunicam a mesma
informação, mas a dizem de forma diferente. Declarações OR simples entre diferentes linhas de diálogo
podem comunicar ao leitor do script que o jogo escolherá aleatoriamente entre várias linhas de diálogo
diferentes.
Mais uma vez retornando ao nosso jogo de aventura, aqui temos uma amostra de diálogo que
os jogadores podem ouvir durante o jogo real:
Quando o jogador esbarra em PAUL, ele diz: “Oh, com
licença, implorando por seu perdão”.
OU

"Oh querida, parece que estou bloqueando seu caminho."


OU

“Minha mãe sempre disse que eu nasci para atrapalhar ela.”


Não há sintaxe padrão do setor que determine a forma de um script interativo. Cabe ao designer, produtor
e roteirista criar um formulário que melhor documente o diálogo que eles precisarão usar em seu jogo.
Alguns jogos de RPG, como Deus Ex, envolvem tanta conversa e árvores de diálogo ramificadas que
empregam linguagens de script bastante robustas e avançadas para o designer ou escritor usar para
implementar o diálogo. Os designers geralmente desejam escrever seus scripts interativos para
corresponder à taxa de sincronização encontrada em tal editor, de modo que, quando chegar a hora de
implementar o diálogo, o processo seja bastante simplificado.
Machine Translated by Google

Capítulo 17: Documentação de desenvolvimento de jogos 315

Jogos que apresentam


muitas conversas
ramificadas, como Deus
Ex, geralmente incluem
uma linguagem de script
especificamente para
implementar o diálogo.

O roteiro do jogo também é onde se pode encontrar o texto do que o personagem lê em um


briefing de missão ou em um livro que possa encontrar. Qualquer texto contido no jogo, desde sinais e
cartazes nas paredes até os comandos emitidos para o personagem do jogador por um comandante
fora da tela, está incluído no roteiro do jogo.
À medida que os jogos tentam incorporar mais e mais histórias, os scripts que documentam todos
os diálogos que eles incluem tornaram-se necessários. A coisa mais importante a ser lembrada ao
trabalhar no script do seu jogo é que as pessoas geralmente estão jogando seu jogo não pelo diálogo,
mas pela jogabilidade. Se eles quisessem assistir a um filme, eles teriam feito isso. Em vez disso, eles
inicializaram seu jogo. Eles podem gostar de ouvir alguns diálogos inteligentes enquanto estão jogando,
mas geralmente não estão tão interessados em ouvir cenas longas e prolongadas que mergulham na
história sem fim. Se a jogabilidade for boa, os jogadores vão querer voltar a ela o mais rápido possível.
Se os jogadores se acharem mais cativados pelo diálogo em seu jogo do que pela jogabilidade, você
precisa se perguntar por que está se incomodando em fazer um jogo.

Bíblia de arte

A bíblia da arte geralmente é composta principalmente de esboços conceituais e outros recursos aos
quais os artistas podem se referir enquanto trabalham na criação de vários recursos visuais para o jogo.
Às vezes, o texto acompanha essas imagens, seja na forma de notas manuscritas em esboços
conceituais ou descrições de texto descrevendo os parâmetros que os artistas devem seguir ao criar
novos elementos para o jogo. A bíblia da arte geralmente não é compilada ou escrita pelo designer,
mas pelo artista principal que trabalha com sua equipe. É claro que as informações contidas na bíblia
da arte precisam corresponder e ser consistentes com a história e os personagens descritos nos outros
documentos do jogo, incluindo o documento de design, roteiro e bíblia da história. Portanto, ao construir
a bíblia da arte, o artista trabalhará em estreita colaboração com os designers, escritores e produtores
para garantir que seu trabalho se encaixe na visão geral do jogo.

A bíblia da arte é o lugar onde a aparência e a sensação do jogo são estabelecidas de forma
abrangente e detalhada. Descrições do estilo de arte a ser empregado no jogo (art déco,
Machine Translated by Google

316 Capítulo 17: Documentação de desenvolvimento de jogos

anime, animação cel da Warner Bros., neo-realismo e assim por diante) serão encontrados na
bíblia acompanhados de esboços que comunicam o estilo do jogo melhor do que palavras jamais
poderiam. É importante manter as descrições do estilo de arte do mundo do jogo neste documento
em vez de no documento de design para permitir que cada documento se mantenha como uma
ferramenta de referência abrangente. É claro que os designers de um projeto devem ler e se
familiarizar com a bíblia da arte, pelo menos para garantir que ela esteja no caminho certo com o
resto do jogo. Uma bíblia de arte também pode conter diretrizes técnicas que os artistas precisam
seguir para criar recursos que funcionem com o mecanismo do jogo, conforme detalhado no
documento de design técnico. Isso pode incluir limitações de polígonos a serem seguidas ou a
duração e número de quadros envolvidos em diferentes animações.

O minuto do jogo
O minuto do jogo é tipicamente um documento de uma a três páginas que descreve em detalhes
uma pequena seção do jogo. Esses documentos geralmente são escritos muito cedo no
desenvolvimento, quando o que exatamente consiste a jogabilidade ainda é bastante nebuloso.
Esses documentos podem ser usados para comunicar à equipe ou à alta administração a direção
do jogo e servir como uma verificação da realidade para garantir que todos estejam totalmente de
acordo com a forma como o alto conceito do jogo realmente se desenrolará. Por esta razão, a
jogabilidade descrita no minuto do jogo deve ser representativa de uma experiência de jogo
relativamente média, não uma batalha de chefe ou a missão de treinamento. Como de muitas
maneiras o minuto do jogo deve funcionar como uma verificação da realidade, ele realmente
precisa descrever sua experiência de jogo de “carne e batatas”. As atas do jogo são escritas em
estilo prosa e entram em detalhes específicos sobre o que exatamente o jogador está fazendo de
momento a momento no jogo. Alguns minutos de jogo chegam ao ponto de listar cada botão ou
tecla que os jogadores fariam para atingir os vários objetivos do jogo.

Minutos de jogo podem ser muito úteis, mas também podem ser um pouco problemáticos,
pois representam uma única maneira de jogar um cenário. Este problema pode ser melhorado
escrevendo o texto de tal forma que sugira o que o jogador pode fazer de forma diferente em uma
determinada situação. Por exemplo, em um jogo de ação e aventura, o jogador pode ver: “Ao virar
da esquina, o jogador vê uma Besta Blugbatter intimidadora. O jogador pensa em carregá-lo e
atacá-lo com seu aguilhão de gado, mas depois lembra que as Bestas Blugbatter são imunes à
eletricidade, exceto em um ponto fraco na base do pescoço. Como a Fera ainda não viu o jogador,
o jogador rapidamente recua na esquina e espera lá em silêncio. Sabendo que a Besta logo estará
patrulhando nessa direção, o jogador espera surpreendê-lo e atacá-lo por trás...” Além disso, um
designer pode querer considerar escrever várias versões diferentes de um minuto de jogo para
mostrar como abordagens para um determinado cenário podem funcionar. Por mais que o designer
tente corrigir esse problema, ele ainda está preso a uma narrativa que descreve apenas uma
sequência específica de eventos. Às vezes, os membros da equipe que não entendem o que um
minuto de jogo deve realizar podem até ficar confusos ao lê-lo, perguntando-se: “Isso é tudo o que
o jogador pode fazer?” No entanto, se usado corretamente e se a equipe estiver totalmente ciente
da função do documento, um minuto de jogo pode ser uma ferramenta muito útil quando o jogo
ainda não está em um estado jogável porque o projeto ainda está em desenvolvimento.
Machine Translated by Google

Capítulo 17: Documentação de desenvolvimento de jogos 317

Storyboards
Os storyboards são um dispositivo estabelecido de cinema e televisão para esboçar ou simular
cenas antes de serem realmente filmadas. Os storyboards podem ser incluídos como parte da
bíblia da arte ou podem ficar sozinhos como seu próprio documento separado. Os storyboards são
mais úteis para mapear cenas não interativas, que são bastante cinematográficas por natureza e,
portanto, são adequadas para storyboards. Isso permite que os membros da equipe de
desenvolvimento forneçam feedback e correções sobre essas cutscenes antes que alguém se dê
ao trabalho de filmar ou renderizá-las. Os storyboards também podem ser usados como esboços
conceituais ou maquetes de como o mundo do jogo aparecerá para os jogadores se o mecanismo
do jogo ainda não estiver pronto para ser usado. Esses storyboards podem ser úteis tanto para
fazer toda a equipe entender em um estágio inicial para onde o jogo está indo, quanto para
convencer os financiadores a financiar o desenvolvimento do projeto. Assim como o documento do
minuto do jogo descrito acima, os storyboards podem ser problemáticos porque representam
necessariamente uma única maneira de jogar em uma determinada área. Como eles têm suas
origens no cinema, os storyboards tradicionais são completamente lineares e podem sugerir aos
leitores que o jogo é mais cinematográfico do que realmente deveria ser. De fato, quando as
pessoas se apaixonam pelo que veem em um storyboard, elas podem tentar limitar as escolhas do
jogador a fazer apenas o que foi desenhado. Pode ser vantajoso usar algum tipo de storyboard de
ramificação, onde as consequências das principais escolhas dos jogadores são desenhadas e
depois dispostas como um fluxograma ou árvore de decisão. Infelizmente, às vezes, quando as
pessoas ficam muito empolgadas com o storyboard de um jogo, pode ser outro caso de inveja do
filme, onde os desenvolvedores realmente desejam ser cineastas. Os storyboards podem ser úteis,
mas apenas até certo ponto. No final, eles não podem substituir a jogabilidade de prototipagem no
computador, levando o jogo a um estado um pouco jogável e, em seguida, refinando-o até que seja
realmente divertido e todas as escolhas do jogador estejam disponíveis para os testadores explorarem.

Documento de design técnico Um


documento de design técnico (TDD) é a especificação irmã do documento de design.
Enquanto o documento de design se concentra em como o jogo funcionará, o documento de design
técnico discute como essa funcionalidade será implementada. Você também pode pensar desta
forma: o documento de design comunica como o jogador experimenta o jogo, enquanto o
documento de design técnico aborda como essa experiência será implementada. Às vezes
chamado de especificação técnica, o documento de design técnico costuma ser escrito pelo
programador líder em um projeto e é usado como ponto de referência pela equipe de programação.
Aqui é onde a estrutura do código é apresentada e analisada. O documento de design técnico é
onde os programadores do projeto podem recorrer para descobrir como devem implementar um
sistema específico. O documento pode incluir a estrutura geral do código, quais classes principais
serão usadas, descrições da arquitetura de renderização, detalhes de como a IA funcionará e
qualquer quantidade de outras informações do lado da implementação. O pseudocódigo é
apropriado, embora não obrigatório, no documento de design técnico. Embora o documento de
projeto técnico possa ser uma boa ideia, no passado muitos projetos conseguiram passar por ciclos
de desenvolvimento perfeitamente bem-sucedidos sem que um documento de projeto técnico fosse
criado. Por outro lado, com os projetos cada vez mais complicados de hoje, orçamentos crescentes
e o consequente aumento no escrutínio colocado em todos os títulos, a maioria dos jogos
desenvolvidos agora usa um ou
Machine Translated by Google

318 Capítulo 17: Documentação de desenvolvimento de jogos

mais TDD. Se esse TDD acaba sendo seguido ou não é outra questão. Em parte para ajudar a
resolver o problema de TDDs inúteis, muitos desenvolvedores evitam escrever um TDD maciço e
altamente detalhado no início do projeto e escrevem mais um esboço ou documento de estrutura
antecipadamente. Então, à medida que o desenvolvimento avança, eles escrevem TDDs menores
à medida que cada recurso do jogo está prestes a ser implementado.
Como mencionei, os documentos de projeto técnico são usados principalmente pela equipe
de programação. No entanto, é muito importante que um designer com qualquer tipo de experiência
em programação (ou mesmo sem nenhuma) consulte os documentos de design técnico para seu
projeto, pois certamente conterão descrições gerais de como a IA e outros algoritmos funcionarão,
além de outras informações críticas para a jogabilidade. Assim como olhar através da bíblia da arte
é importante para um designer, ler o documento ou documentos de design técnico, mesmo que ele
não consiga entender todos eles, dará ao designer a chance de garantir que a equipe de
programação esteja no caminho certo .

Cronogramas e Documentos de Negócios/ Marketing


Eu os incluo na minha lista de documentos de desenvolvimento de jogos para enfatizar que
cronogramas, orçamentos e informações de projeção de marketing não pertencem ao documento
de design. Em muitas ocasiões, li documentos de design que continham seções inteiras sobre
como o jogo poderia ser vendido. De fato, alguns dos chamados documentos de design são pouco
mais do que planos de marketing disfarçados. Essas informações orientadas aos negócios não
são apropriadas no documento de design, nem pertencem a nenhum dos outros documentos que
discuti aqui, exceto o documento conceitual. O documento de design é sobre o design funcional do
jogo, não como ele será anunciado ou vendido no varejo. É melhor separar esses planos de
marketing e dados de negócios em documentos distintos, onde as pessoas preocupadas com
essas informações possam analisá-las melhor.
Ao trabalhar em um projeto de grande orçamento que espera pelo menos recuperar seu
investimento de capital, é importante ter projeções de marketing bem pensadas, orçamentos,
cronogramas e qualquer número de outros documentos que ajudarão o pessoal de relações com a
imprensa, representantes de vendas , e artistas de publicidade quando estão trabalhando em seu projeto.
O designer-chefe de um projeto deve oferecer seus serviços para ajudar na criação e manutenção
desses documentos da maneira que puder, embora a redação desses documentos geralmente
recaia sobre pessoas mais sintonizadas em vender e gerenciar, em vez de criar. Muitas vezes, é
responsabilidade do produtor do jogo desenvolver e manter esses documentos. Ainda assim, é
responsabilidade moral do designer garantir que as pessoas que financiam o projeto saibam que
tipo de jogo estão adquirindo. Isso os torna menos propensos a ficarem chateados no caminho
quando o jogo termina e não combina com os anúncios e a arte da caixa que eles já gastaram
grandes quantias de dinheiro criando. E quando os naipes entendem o que torna seu jogo bom, é
muito menos provável que exijam mudanças ou, pior ainda, cancelem-no. Se os empresários estão
realmente satisfeitos com o produto final, é muito mais provável que fiquem entusiasmados com a
promoção e venda do jogo, o que só pode significar que mais pessoas acabarão jogando.
Machine Translated by Google

Capítulo 17: Documentação de desenvolvimento de jogos 319

Sem documentação padrão


Diferentes empresas podem ter padrões diferentes para a documentação que criam para auxiliar
e orientar o desenvolvimento de um jogo. Embora possam ter nomes diferentes para os
documentos daqueles que usei acima, acho que essas categorias abrangem a grande maioria
dos documentos que as empresas criarão. Algumas equipes podem dividir o documento de
design em dois documentos, um contendo apenas informações de jogabilidade e o outro
contendo apenas descrições de história e progressão de nível. Algumas equipes de
desenvolvimento podem criar apenas um documento de design, sem necessidade de uma bíblia
de histórias. Algumas equipes de programação podem achar que não precisam de um
documento de projeto técnico. Alguns diretores de arte podem passar pelo desenvolvimento de
um jogo sem uma bíblia de arte formal. Algumas equipes que trabalham em projetos
multimilionários podem até passar por eles sem qualquer documentação, embora isso seja cada
vez mais inédito, pois os editores exigem documentação para que tenham uma ideia exata de qual jogo e
Além disso, os editores gostam de ter alguma prova tangível de que a equipe de desenvolvimento
tem uma boa ideia do que está fazendo. Normalmente, a quantidade de documentação exigida
por um editor é inversamente proporcional à confiança e experiência de você e sua equipe como
desenvolvedores. Quanto mais nova e não comprovada sua equipe, mais garantias as pessoas
que financiam seu projeto vão querer ter certeza de que você não está jogando dinheiro fora.

Os benefícios da documentação
Além de deixar os naipes felizes, uma boa documentação realmente pode ajudar a tornar seu
jogo melhor, independentemente de você estar desenvolvendo-o sozinho em seu porão ou com
uma equipe de trinta outros desenvolvedores. Eu listei vários documentos separados acima e,
ao longo do projeto, pode ser difícil mantê-los em ordem, organizados e acessíveis aos membros
da equipe que precisam deles a qualquer momento. Para ajudar com isso, alguns
desenvolvedores começaram a usar o Wiki, um sistema baseado na web para organizar
documentos e permitir que os membros da equipe modifiquem ou atualizem facilmente qualquer
documento, mantendo o controle de versão e o histórico de cada arquivo. Embora não sem
suas desvantagens, um sistema Wiki permitirá que você mantenha seus documentos
organizados, ao mesmo tempo em que permite que eles sejam mantidos atualizados à medida que o pro
Como designer de jogos, você deve estar envolvido e interessado na criação de toda a
documentação descrita acima. Como líder ou designer sênior, a criação e manutenção do
documento de design, bíblia da história e roteiro são de sua responsabilidade.
Cada documento pode ser escrito por um indivíduo ou trabalhado coletivamente por várias
pessoas. Por exemplo, você pode não escrever o script sozinho se houver um escritor disponível
mais qualificado para compor diálogos atraentes. No entanto, como designer-chefe, você ainda
deve se preocupar que a história, o roteiro e a jogabilidade se encaixem. Certificar-se de que
todos os documentos sejam consistentes entre si e estejam alinhados com a visão e o foco do
projeto é algo que o designer precisa levar muito a sério.
Machine Translated by Google

Capítulo 18
Entrevista:
Jordan Mechner

A única reclamação que se poderia ter sobre o trabalho de Jordan Mechner em informática
jogos é que ele não fez mais deles. Cada um dos jogos que ele tem
projetado e liderado - Karateka, Prince of Persia e The Last Express
— teve uma elegância e sofisticação únicas que raramente se encontra no
mundo dos jogos de computador. Mas a indústria de jogos teve que prescindir
Mechner por vários períodos de tempo enquanto perseguia seu outro grande amor,
fazendo um filme. De fato, é o conhecimento de Mechner sobre cinema que ajudou a contribuir
para a qualidade de seus jogos. Mas essa qualidade não vem
cutscenes épicas e mecânicas de jogo pouco interativas que muitas vezes vêm
sobre quando os desenvolvedores tentam mesclar filmes e jogos. Em vez disso, Mechner
combinou técnicas de filmes e jogos de maneiras únicas e inovadoras, ajudando seus títulos a
contar histórias visualmente, mantendo as qualidades que fazem
eles grandes jogos. Isso é o mais evidente em seu trabalho mais recente, o
incrível Prince of Persia: The Sands of Time. Esta entrevista foi originalmente conduzida em
torno do lançamento da revista The Last Express for Inside Mac Games . Para inclusão neste
livro, Mechner teve a gentileza de preencher o
entrevista um pouco, expandindo-a para cobrir toda a amplitude de seus vinte anos no
desenvolvimento de jogos de computador.

320
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 321

O que inicialmente o atraiu para os jogos de computador?


Bem, era 1979, e eu estava no segundo ano do ensino médio. O primeiro computador com o qual
tive a chance de jogar foi o PDP-11 que tínhamos em nossa escola. Mas era muito difícil conseguir
tempo para isso, e o professor responsável não deixava os alunos lerem os manuais, com medo
de que isso nos desse a capacidade de entrar e mudar as notas e coisas assim. Então foi esse
jogo de adivinhação de tentar aprender como fazer o computador fazer qualquer coisa. Então,
quando um amigo meu me mostrou seu novo Apple II, foi como um sonho tornado realidade – ter
um computador em sua própria casa que você pudesse usar quando quisesse. E estava
completamente aberto; você poderia abrir o topo e ver como ele foi feito e você poderia ler todos
os manuais que o acompanhavam. E, claro, a ironia era que naquela época eu não conhecia
nenhum manual que explicasse a linguagem de montagem. Então, eu estava apenas analisando o
código de montagem do sistema operacional do computador para tentar descobrir o que os
diferentes comandos significavam. Ao longo dos anos eu peguei isso, e mais livros foram lançados.
Era apenas este grande brinquedo.

Você sempre quis fazer jogos com o computador?


Bem, acho que os jogos eram o único tipo de software que eu conhecia. Eles eram o único tipo
que eu gostava. Naquela época, eu realmente não via nenhum uso para um processador de texto
ou uma planilha. Joguei todos os jogos que pude encontrar e, no meu tempo livre, tentei escrever
meus próprios jogos. Esse foi apenas o primeiro uso que me ocorreu.

Então essa foi a origem do Karateka?


Demorou alguns anos para chegar lá. O primeiro projeto realmente ambicioso que fiz foi um jogo
chamado Asteroids. Essa foi minha tentativa de fazer por Asteroids o que um jogo chamado Apple
Invaders havia feito pelo outro jogo de moedas mais popular da época. Achei que se o Apple
Invaders fosse um grande sucesso porque era exatamente como o jogo de moedas, então eu
poderia fazer a mesma coisa para Asteroids. Mas meu timing estava um pouco errado. Na verdade,
terminei uma linguagem assembly, versão de alta resolução do Asteroids e assinei um contrato
com uma editora. Mas então a Atari acordou para o fato de que esses jogos de computador
estavam roubando suas franquias de arcade extremamente lucrativas, então seus advogados
assustaram todo mundo e que o jogo Asteroids nunca foi publicado.

Então você fez Karateka?


Não, então eu fiz um jogo que tinha uma forte semelhança com Asteroids , exceto que, em vez de
pedras, você tinha bolas quicando de cores vivas e, em vez de envolver a borda da tela, elas
ricocheteavam, daí seu nome: Deathbounce. Enviei para Broderbund (isso foi em 1982, eu era um
calouro na faculdade) e recebi um telefonema de Doug Carlston, que na época estava cuidando
dos envios e administrando a empresa. Fiquei muito empolgado ao receber uma ligação de alguém
da indústria de jogos de computador. Ele disse: “Parece que está bem programado, estamos
impressionados com a suavidade da animação e assim por diante. Mas parece meio antiquado. Dê
uma olhada no nosso novo jogo, Choplifter.” Doug teve a gentileza de me enviar uma cópia do
Choplifter de Dan Gorlin, que era o jogo mais vendido na época, junto com um joystick para jogar.
Esse foi o jogo que realmente me despertou para a ideia de que eu não precisava copiar os jogos
de arcade de outra pessoa, eu tinha permissão para criar o meu próprio!
Machine Translated by Google

322 Capítulo 18: Entrevista: Jordan Mechner

Karateka surgiu de
um monte de ideias, todas
convergindo ao mesmo
tempo. Choplifter me
mostrou o que era possível
em termos de rolagem
suave e um design de jogo
original.
Enquanto isso, eu estava
recebendo megadoses de
exposição ao cinema; Yale
tinha cerca de uma dúzia
de sociedades de cinema
e eu estava tentando ver
em quatro anos todos os
Karateca
filmes já feitos. Seven
Samurai foi meu novo filme favorito de todos os tempos. Minha mãe naquela época gostava muito
de karatê, e eu tive algumas aulas durante o verão no dojo local. Finalmente, eu estava tendo
aulas de estudos de cinema (sempre perigosas) e começando a ter delírios de grandeza de que
os jogos de computador estavam na infância de uma nova forma de arte, como desenho animado
nos anos 20 ou filme nos anos 1900. Então, todas essas fontes de inspiração foram incorporadas ao Karateka.
O que fez a grande diferença foi usar uma câmera Super 8 para filmar meu professor de karatê
passando pelos movimentos e traçando-os quadro a quadro em uma Moviola. Era rotoscopia, o
mesmo truque que a Disney usou para Branca de Neve nos anos 30. Isso fez a animação parecer
muito melhor do que eu poderia ter feito à mão e melhor do que os outros jogos que estavam por
aí. Trabalhei em Karateka por alguns anos entre as aulas e enviei para Broderbund no final do
meu segundo ano. Eles ficaram satisfeitos e publicaram.

Então um dos seus objetivos era mesclar técnicas cinematográficas com um jogo de ação
para criar um híbrido único?
Muito definitivamente. O corte transversal acelerado para criar suspense havia sido usado por DW
Griffith em 1915; Achei que deveria ser tentado em um jogo de computador. A limpeza horizontal
para transição entre cenas eu tirei de Seven Samurai. O prólogo de texto de rolagem no início. E
coisas bobas, como dizer THE END em vez de GAME OVER.
Usei as poucas técnicas que consegui descobrir como fazer gráficos de alta resolução em um
Apple II.

Karateka é realmente muito curto. Foi uma decisão deliberada, para manter o jogo focado?

Bem, não me pareceu curto na época. Na verdade, quando eu enviei para Broderbund, só tinha
um nível: você entrava no palácio e lutava. Uma das primeiras coisas que me sugeriram foi ter três
níveis diferentes: você está do lado de fora, você está no palácio, então você está embaixo. Eu
não estava pensando em termos de horas de jogo, eu só queria torná-lo legal.
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 323

O final é um truque bem tortuoso, onde se o jogador se aproximar da princesa na postura de


“ataque” ela o chutará. Como você chegou a isso?
Parecia um pequeno
truque divertido. Você só
tem uma vida nesse jogo:
você chega o mais longe
que puder, e se você for
morto, é “The End” e você
tem que começar o filme do
começo novamente. Então
eu imaginei que a maioria
dos jogadores, quando eles
finalmente chegassem ao
fim, iriam correr direto para
os braços dela. Mas não é
uma trapaça total, há uma
pequena pista ali, onde ela
estende os braços para Karateca

você, e então, se você correr em direção a ela, ela abaixa os braços. Então isso é um sinal de que
algo não está certo.

Mas eu não sei se alguém já jogou esse jogo e fez certo na primeira vez.

Sim, em retrospecto, isso foi muito desagradável. Não sei se conseguiríamos escapar disso hoje. A
outra coisa que conseguimos em Karateka foi que se você jogasse o outro lado do disco, se você
colocasse o disco de cabeça para baixo, o jogo jogava de cabeça para baixo. Eu esperava que pelo
menos algumas pessoas ligassem para o suporte técnico da Broderbund e dissessem: “A tela está de
cabeça para baixo, acho que algo está errado com meu monitor ou meu computador”. Dessa forma, a
pessoa do suporte técnico poderia ter a sublime alegria de dizer: “Ah, você provavelmente colocou o
disco de cabeça para baixo”. E o cliente ficaria feliz em desligar pensando que isso era verdade para
todos os softwares de computador. Achei extremamente corajoso da parte da editora aumentar o custo
dos produtos em vinte e cinco centavos apenas por uma brincadeira.

Então, Prince of Persia cresceu com suas experiências em Karateka?


Bem, havia uma grande lacuna entre Karateka e Prince of Persia em termos de minha própria vida.
Terminei a escola e tirei um ano de folga. Eu não tinha certeza se queria fazer outro jogo de
computador. A inspiração mais direta foi um jogo de Ed Hobbs chamado The Castles of Doctor Creep,
que não teve grande circulação, provavelmente porque só estava disponível no Commodore 64. Meus
colegas de faculdade e eu passamos muito tempo horas jogando esse jogo. Tinha esses quebra-
cabeças engenhosos do tipo Rube Goldberg, onde você aperta um botão e isso abre um portão, mas
fecha outro portão, e assim por diante. Assim, a ideia de uma frase para Prince of Persia era fazer um
jogo que combinasse a engenhosidade de The Castles of Doctor Creep com a animação suave de
Karateka. Então, quando você corria e pulava, você não era apenas um pequeno sprite voando pelo
ar, seu personagem realmente parecia ter peso e massa, e quando você caía nos espinhos, parecia
que realmente doía.
Machine Translated by Google

324 Capítulo 18: Entrevista: Jordan Mechner

Outra inspiração foram os primeiros oito minutos de Raiders of the Lost Ark. Eu queria fazer
um jogo com esse tipo de ação. E então havia o cenário das Mil e Uma Noites . Eu estava
procurando por um cenário que não tivesse sido feito até a morte em jogos de computador, e
alguns animadores da Broderbund, Gene Portwood e Lauren Elliot, sugeriram este. Voltei e reli
as Mil e uma noites e parecia oferecer muita promessa. Tinha todas aquelas grandes
possibilidades de histórias que foram absorvidas em nosso inconsciente coletivo – gênios, as
viagens de Sinbad, a caverna de Aladim. Estava apenas clamando para ser feito como um jogo
de computador.

Você disse que tinha tirado um tempo antes de fazer Prince of Persia. O que finalmente fez
você querer voltar e fazer outro jogo?
Esse foi o ano em que escrevi meu primeiro roteiro de filme. Foi escolhido por Larry Turman, um
homem muito bom que produziu cerca de cinquenta filmes, incluindo The Graduate. Tivemos um
ano de reuniões com diretores e estúdios e chegamos perto de conseguir, mas no final não deu
certo. Mais tarde eu descobri que para um roteirista de primeira viagem, isso não é considerado
um mau começo. Mas eu tinha sido mimado pelos jogos de computador e pensei: “Meu Deus,
acabei de passar seis meses aqui em Los Angeles esperando que algo aconteça, e o filme nem
está sendo feito”. Em comparação, eu sabia que se terminasse Prince of Persia, seria publicado.
Então achei melhor ficar com isso. No momento em que todas essas coisas boas começaram a
acontecer com o roteiro, eu tinha cerca de seis meses em Prince of Persia, e deixei isso de lado
por quase um ano para me concentrar no roteiro. Foi muito assustador voltar a programar depois
de tanto tempo de folga; Eu estava com medo de não ser capaz de lembrar meu próprio código-
fonte. Mas voltei, peguei de novo e terminei.

Uma coisa sobre Prince of Persia é que ele pega essa quantidade finita de elementos do
jogo e os estende por todos esses níveis. No entanto, nunca fica monótono ou repetitivo.
Como você conseguiu isso?
Esse foi realmente o
desafio do design.
Era modular, pois havia
um número finito de
elementos que podiam
ser recombinados de
diferentes maneiras.
É a mesma coisa que
você tenta fazer em um filme.
Você planta uma linha de
diálogo ou um objeto
significativo, e quinze ou
trinta minutos depois você
paga de forma inesperada.
Príncipe da Pérsia
Um exemplo em Prince of
Persia seriam os pisos
soltos. A primeira vez que você encontra um é uma armadilha: você tem
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 325

passar por cima para não cair. Mais tarde, ele reaparece, não como uma armadilha, mas como uma
rota de fuga: você tem que pular e bater no teto para descobrir que há um pedaço de teto solto que
você pode derrubar por baixo. Mais tarde, você pode usar um para matar um guarda deixando-o cair
na cabeça dele, para abrir uma placa de pressão, ou - um novo tipo de armadilha - para quebrar
acidentalmente uma placa de pressão para que você nunca possa abri-la novamente.
Foi necessário tornar o Prince of Persia modular porque a memória do computador era muito
limitada. A animação suave do personagem, com tantos frames intermediários e tantos movimentos,
estava ocupando uma grande porcentagem daquele computador de 64K. Quando a eficiência não é
um problema, você sempre pode agregar valor de produção a um jogo colocando um ambiente
completamente novo ou efeito especial ou inimigo, mas quando você está literalmente sem RAM e sem
espaço em disco, você tem que pensar de forma criativa.
O que, por sua vez, força o jogador a pensar criativamente. Há uma certa elegância em pegar um
elemento com o qual o jogador já acha que está familiarizado e desafiá-lo a pensar sobre isso de uma
maneira diferente.

Prince of Persia é realmente um jogo simples de controlar, especialmente se comparado aos


jogos de ação modernos. Esse era um objetivo de design seu?
Absolutamente. Essa foi uma consideração muito forte tanto em Karateka quanto em Prince of Persia,
e passei horas tentando descobrir como integrar certos movimentos. Deve ser com o joystick ou com o
botão? Pessoalmente, tenho um forte preconceito contra jogos que exigem que eu use mais de um ou
dois botões. Esse é um problema, na verdade, que tenho com os jogos de ação modernos. No momento
em que descubro se estou usando A, B, X, O ou um daqueles pequenos botões na parte inferior do
controle que você nunca usa, exceto para um movimento especial de emergência, perdi a ilusão que
sou eu quem está controlando o personagem.

Idealmente, você quer que o jogador esteja tão acostumado a manusear o joystick e os botões
que a ação comece a parecer uma extensão dele mesmo. O truque aqui, obviamente, é que quando
você traz um novo movimento que você não usou antes, você quer que o jogador de alguma forma já
“saiba” qual botão ou que combinação de ações vai trazer aquele movimento. Em Prince of Persia
houve lances em que pensei: “Isso seria ótimo, mas não tenho um botão para isso, então deixe para lá.
Seria legal, mas não ajuda o jogo em geral.”

Uma grande restrição foi


manter os controles simples Príncipe da Pérsia

e consistentes.
Machine Translated by Google

326 Capítulo 18: Entrevista: Jordan Mechner

No que diz respeito ao design do jogo, parece que Prince of Persia foi uma extensão lógica do
que você fez em Karateka, e Prince of Persia 2 foi por sua vez uma extensão disso.
Mas The Last Express parece estar em uma direção completamente nova. O que te fez fazer
algo tão diferente quanto Last Express?
Acho que não penso no Last Express como uma nova direção. Eu ainda estava tentando resolver o
mesmo problema de como contar uma história e criar uma sensação de drama e envolvimento para
o jogador. Existem várias fórmulas de jogos de ação comprovadas que evoluíram desde os dias de
Prince of Persia. Parte do que me interessava em fazer um jogo de aventura era que parecia ser um
campo muito aberto, pois não havia muitos jogos que tivessem encontrado um paradigma viável de
como fazer um jogo de aventura.

Então não foi a inspiração de outros jogos de aventura?


Não, pelo contrário, na verdade. Se você olhar para as antigas aventuras de texto de Scott Adams
dos anos 80, é surpreendente o quão pouco os jogos de aventura progrediram em termos de
experiência que o jogador tem: a sensação de imersão e a sensação de vida que você recebe dos
personagens e a história. Então acho que foi o desafio de tentar revitalizar ou reinventar um gênero
moribundo que me atraiu.

O que o inspirou a definir o jogo no Expresso do Oriente em 1914?


No design de jogos de computador, você está sempre procurando por um cenário que lhe dê as
emoções e aventuras que você procura, ao mesmo tempo que precisa ser um espaço restrito para
projetar um bom jogo em torno dele. Por exemplo, coisas como cidades são muito difíceis de fazer.
Um trem me pareceu o cenário perfeito para um jogo. Você tem um espaço confinado e um elenco
limitado de personagens, e ainda assim você não tem aquela sensação estática de que você entraria,
digamos, em uma casa mal-assombrada, porque o próprio trem está realmente se movendo. A partir
do momento em que o jogo começa, você está em uma cápsula fechada que está se movendo, não
apenas em direção ao seu destino - Paris a Constantinopla - mas também está se movendo no
tempo, de 24 a 27 de julho, de um mundo em paz para um mundo na guerra. O tique-taque do relógio
dá um movimento para frente e direciona a narrativa, o que acho que funciona muito bem para um
jogo de computador.

A Orient Ex press, é
claro, é o trem perfeito para
uma história que trata do
início da Primeira Guerra
Mundial.
O Expresso do Oriente em
1914 era a “novidade”; foi
uma inovação como a
Comunidade Europeia
Económicaé
hoje, um símbolo da
unidade da Europa. Na
época isso

O Último Expresso
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 327

era possível viajar de uma ponta a outra da Europa, uma viagem que costumava levar semanas, em poucos
dias, sem problemas nas fronteiras e assim por diante. Nesse trem você tinha um corte transversal de
pessoas de diferentes países, diferentes classes sociais, diferentes ocupações – um microcosmo da Europa
em um ambiente confinado. Todas essas pessoas que viajavam juntas e faziam negócios juntas, viram-se
subitamente separadas por linhas nacionalistas para uma guerra que duraria quatro anos e que destruiria
não apenas o tecido social, mas também os próprios trilhos de trem que fizeram o Expresso do Oriente
possível. Para mim, o Expresso do Oriente é um símbolo muito dramático e pungente do que era aquela
guerra. E um ótimo cenário para uma história.

Então você diria que seu ponto de partida para Last Express foi: “Eu quero fazer um jogo de
aventura; que tipo de história posso contar dessa forma?” Ou foi: “Aqui está uma história que quero
contar; que tipo de jogo me permitirá contar efetivamente?”

Definitivamente o último. Tomi Pierce [co-escritor de The Last Express] e eu queríamos contar uma história
no Expresso do Oriente em 1914, logo antes da guerra: como fazemos isso? Eu realmente não me
concentrei no fato de que era uma mudança de gênero de Prince of Persia ou o que isso significaria para o
marketing. Tornou-se evidente à medida que trabalhávamos na história que, dada a quantidade de
personagens, a ênfase em suas motivações e personalidades, a importância do diálogo e das diferentes
linguagens, o que estávamos projetando era um jogo de aventura. Eu conscientemente queria fugir da
sensação de jogo de aventura. Eu pessoalmente não gosto da maioria dos jogos de aventura. Eu queria
ter uma sensação de imediatismo enquanto você está se movendo pelo trem, e ter pessoas e vida surgindo
ao seu redor, ao contrário da sensação usual de jogo de aventura onde você entra em um espaço vazio
que está apenas esperando por você. algo.

Foi por isso que você adicionou o aspecto “tempo real” ao Last Express, algo que não estamos
acostumados a ver em jogos de aventura?

Claro, não é tecnicamente em tempo real, mais do que um filme. O relógio está sempre correndo, mas
jogamos um pouco com a taxa em que o tempo passa. Reduzimos a velocidade em certos pontos para dar
ênfase dramática, aceleramos em certos pontos para manter as coisas em movimento. E nós temos elipses
onde você corta o trem, então você corta e é uma hora depois.

Mas ainda assim, é mais em tempo real do que as pessoas estão acostumadas em jogos de aventura
tradicionais.

Ou até mesmo em jogos de ação. Estou impressionado com o número de chamados jogos de ação onde,
se você colocar o joystick para baixo e sentar e assistir, você está apenas olhando para uma tela em branco.
Depois de limpar essa sala de inimigos, você pode ficar sentado lá por horas.

Você mencionou cinema lá atrás, e eu sei que em 1993 você fez seu próprio documentário, Waiting
for Dark. Sua experiência com cinema o ajudou na produção de Last Express?

Tem sido extremamente útil, mas acho que também pode ser uma armadilha. O cinema tem um vocabulário
incrivelmente rico de truques, convenções e estilos que evoluíram ao longo dos últimos cem anos de
cinema. Alguns foram usados em jogos de computador e realmente funcionam bem,
Machine Translated by Google

328 Capítulo 18: Entrevista: Jordan Mechner

outros ainda estão esperando que alguém descubra como usá-los, e outros não funcionam
muito bem e tendem a matar os jogos para os quais são importados. O exemplo clássico é o
chamado “filme interativo”, que é uma série de cut-scenes encadeadas por árvores de escolha:
faça isso e pegue a cena A e continue, faça aquilo e pegue a cena B e perca. Para Last
Express, eu queria que o jogador sentisse que estava se movendo livremente a bordo de um
trem, com a vida girando ao seu redor e os outros personagens fazendo suas próprias coisas.
Se alguém passar por você no corredor, você deve ser capaz de se virar, vê-los andando pelo
corredor na outra direção, e segui-los e ver para onde vão. Se você não estiver interessado,
você pode simplesmente continuar andando. Eu penso nisso como uma experiência não linear
no cenário mais linear possível, ou seja, um trem expresso.

Todos os seus jogos apresentam cutscenes de uma forma ou de outra, e em Karateka,


Prince of Persia e Last Express todos eles foram integrados ao jogo para serem
visualmente indistinguíveis da jogabilidade. Foi uma decisão consciente de sua parte?

Absolutamente. Parte da estética desses três jogos é que, se você sentar e assistir, deverá ter
uma experiência visual suave como se estivesse assistindo a um filme.
Considerando que, se você estiver jogando, deve ter uma experiência tranquila controlando-o.
Deve funcionar tanto para o jogador quanto para alguém que está de pé sobre o ombro do
jogador observando. As cut-scenes e a jogabilidade devem parecer o mais possível como se
pertencessem ao mesmo mundo. Karateka usou o corte transversal em tempo real para gerar
suspense: quando você está correndo em direção ao guarda, e depois corta para o guarda
correndo em sua direção, depois corta de volta para você, depois volta para a cena em que o
guarda entra no quadro. Esse é um exemplo primitivo, mas que funcionou muito bem.
Mesma ideia em Last Express: você está no ponto de vista em primeira pessoa, você vê
August Schmidt andando em sua direção pelo corredor, então você corta para uma tomada de
reação de Cath, a personagem do jogador, vendo-o chegando. Então você ouve a voz de
August, e você corta para August, e quase sem perceber você muda para uma cena de diálogo
em terceira pessoa. A cena termina com uma cena de August andando pelo corredor, e agora
você está de volta ao ponto de vista e está controlando-o novamente. Entendemos o significado
dessa sequência de planos intuitivamente porque já vimos muito isso no cinema.

Um exemplo clássico é
Janela Indiscreta
Alfredde
Hitchcock. Todo o filme é
construído em torno do
tríptico de plano, plano de
ponto de vista, plano
reação, de
onde
cerca de metade do filme
é visto através
O Último Expresso
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 329

Os olhos de James Stewart. Essa é a unidade básica de construção do Last Express em termos de
montagem.

Por outro lado, em Prince of Persia 2, as cut-scenes eram na verdade imagens pintadas que
pareciam um pouco diferentes da jogabilidade real. Parece que me lembro de não ter gostado
tanto assim...
Eu concordo com você sobre isso. Há um efeito de distanciamento nessas cenas, elas fazem você se
sentir como se estivesse assistindo a um livro de histórias. Mas era o efeito que estávamos buscando
na época.

No momento, parece haver uma tendência de afastamento das cenas de vídeo em movimento
total em jogos de computador...
E com razão, porque as cutscenes full-motion às vezes custam tanto quanto o jogo inteiro e é discutível
se elas realmente melhoraram a jogabilidade. Além disso, há o problema de que a qualidade das cut-
scenes na maioria dos casos era bem baixa, se você comparar com uma boa TV ou bons filmes.

Então você fez uma tentativa consciente de fazer algo diferente ao fundir um estilo de filmagem
com um estilo de criação de jogos?
Minha esperança é que Last Express ofereça algo que realmente não foi oferecido por nenhum outro
jogo de aventura, ou realmente um jogo de qualquer gênero, que é realmente encontrar-se em um
mundo povoado por pessoas. Personagens interessantes e completos, que não são apenas fisicamente
distinguíveis, mas têm sua própria personalidade, seu próprio propósito na história, seus próprios planos
de ação. E através do mecanismo de apontar e clicar bastante convencional, você está realmente
interagindo com um mundo que não é apenas visualmente rico, mas também ricamente povoado.

Então, como você desenvolveu o método de interação do jogador com o jogo?

Nosso objetivo era mantê-lo o mais simples possível. Apontar e clicar me atraiu porque sempre vi Last
Express como um jogo que atrairia um público mais mainstream de adultos. Pessoas que não costumam
jogar jogos de computador e não são particularmente habilidosas com um joystick não vão ficar paradas
para aprender um grande número de teclas e o que todas elas fazem. Apontar e clicar é algo que os
adultos da nossa sociedade sabem fazer, então o desafio era construir um jogo onde você não
precisasse saber fazer nada além de pegar um mouse e movê-lo pela tela. O cursor muda à medida que
você passa por diferentes regiões para mostrar o que você pode fazer: você pode virar à esquerda,
pode falar com um personagem diferente. As especificidades de como isso funciona evoluíram à medida
que o testamos.
Durante o desenvolvimento, resolvemos problemas como: “O 'up' e o 'forward' precisam ser cursores de
formatos diferentes?” Decidimos que sim. “O 'olhar para cima' e 'levantar' precisam ser diferentes?”
Decidimos que não, ambos podem ser a seta para cima. Mas a ideia básica de que seria baseado em
pontos de acesso, apontar e clicar fazia parte do design original.
Machine Translated by Google

330 Capítulo 18: Entrevista: Jordan Mechner

Então, quanto filme você filmou para Last Express? Parece que há uma quantidade
monstruosa de filmagens ali.
Todo o projeto, devido ao
seu tamanho, foi um
grande desafio logístico. A
filmagem durou apenas
três semanas. O que não
é muito, quando se
considera que uma
filmagem comum de longa-
metragem leva pelo menos
quatro semanas, rodando
em média três páginas de
roteiro por dia.

Enquanto durante três


semanas, filmamos cerca
de quinze páginas de por
roteiro
dia. Tínhamos alguns O Último Expresso
truques que nos permitiam
avançar tão rápido: o fato de ser tudo em tela azul, o fato de estarmos filmando em silêncio e ter
gravado o som anteriormente, e o fato de estarmos rodando pouco, filmando sete e meio quadro
por segundo em algumas cenas, cinco quadros por segundo em outras. Com o objetivo de selecionar
quadros-chave e depois reanimá-los, como você vê no jogo finalizado. Tudo isso nos permitiu filmar
muito material.
Mas em termos de acompanhamento... Só para dar um exemplo, a primeira fase das filmagens
foi no corredor do trem. Colocamos uma trilha de quinze metros representando o corredor, com
linhas amarelas no chão pintado de azul com uma parede cíclica pintada de azul atrás dela. E por
três dias marchamos com todos os trinta personagens no trem para cima e para baixo naquele corredor.
O momento-chave, quando um personagem caminha em direção à câmera, é o momento do contato
visual - amigável ou hostil - a nuance desse olhar sendo uma das coisas que o traz para o jogo
como Cath, faz você sentir que não é apenas uma presença fantasma no trem, mas que as pessoas
estão reagindo a você, mesmo quando passam por você no corredor. Nos primeiros três dias,
apenas filmamos caminhadas por corredores, e tínhamos basicamente uma ciência. A câmera ficou
bloqueada por três dias; não se moveu. Se a câmera se movesse, teríamos imagens que não se
alinhavam.
Depois de três dias no corredor nos mudamos para o restaurante, e novamente tivemos que
fazer isso de uma forma bem inusitada. Em vez de filmar uma cena de cada vez e cobrir cada cena
com uma variedade de configurações de câmera, como faríamos em um filme, filmamos uma
configuração de câmera de cada vez. De cada configuração de câmera, filmávamos todas as
diferentes cenas ou ações que poderiam ser vistas desse ângulo ao longo de toda a história.
Travaríamos a câmera em cada posição, digamos, a visão “sentado à mesa olhando para frente”.
Montamos as outras mesas e filmamos cada ação que podia ser vista daquela vista – August
Schmidt entra, senta-se, pede o jantar, o garçom traz a comida, ele come, põe o guardanapo de
lado, levanta e vai embora.
Então, com a câmera configurada de um ângulo diferente da sala de jantar, teríamos o mesmo
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 331

atores repetem as mesmas ações. Tornar a filmagem o mais eficiente possível foi um quebra-
cabeça, descobrir quais atores trazer em quais dias e quando deixá-los ir, e é mais econômico
mover a câmera mais uma vez para que possamos enviar um bando de atores em casa cedo,
ou devemos deixar a câmera onde está e pagar os atores pelo dia inteiro. Isso vezes dezenove
dias foi uma filmagem logisticamente muito complicada. Com muita ação sendo filmada de
vários ângulos, já que no jogo você nunca sabe de que ângulo o jogador vai ver.

E uma vez que tudo foi filmado, deve ter sido um tremendo desafio manter tudo em
ordem.
Fizemos a edição em um Avid; sem isso não sei o que teríamos feito. Despejamos tudo em
enormes discos rígidos neste sistema de edição não linear baseado em Macintosh e
selecionamos os quadros que queríamos. Levamos esse sistema Avid ao limite. A certa altura,
nosso editor de filmes teve que ligar para o suporte técnico porque o sistema estava ficando
muito lento. Quando ele disse a eles quantos efeitos ele tinha, eles ficaram surpresos e não
podiam acreditar que ainda estava funcionando. Tivemos mais dissoluções de quadros em
apenas uma de nossas cenas do que eles previram que alguém jamais teria em um filme
normal. Estávamos escolhendo quadros parados e dissolvendo de um para o outro, para que
cada quadro do jogo fosse um efeito especial.
O número oficial é que tivemos quarenta mil frames de animação no jogo.
Em comparação com um filme de animação, no entanto, esse número é enganosamente
baixo. Em uma cena de diálogo típica, estamos dissolvendo entre quadros estáticos em média
uma vez a cada segundo ou uma vez a cada dois segundos, enquanto um filme convencional
roda vinte e quatro quadros por segundo. Então, para obter o equivalente em termos de quanta
ação realmente cobrimos, você precisa multiplicar quarenta mil por vinte e quatro. Além disso,
muitos quadros são reutilizáveis. Você tem cento e cinquenta quadros do personagem andando
pelo corredor em direção à câmera, depois cento e cinquenta quadros se afastando da câmera.
Usando apenas esses trezentos quadros, o personagem condutor do trem, digamos, pode
passar dez horas andando ao longo do jogo. Quando você entra na sala de jantar, você vê
seis mesas, e cada mesa pode ter sua própria ação acontecendo de forma independente. Se
você jogar o jogo do início ao fim cinco vezes, na sexta vez você poderá ver dois personagens
juntos na sala, enquanto antes eles sempre estavam na sala separadamente. Só porque a
ação se desenrola um pouco diferente. Portanto, o número de combinações dessa filmagem é
praticamente ilimitado.

Então, o que fez você criar o efeito de se dissolver entre os quadros a cada um ou dois
segundos usados no Last Express? Por que você não usou o estilo mais tradicional de
movimento total ao longo do jogo?
Do nosso ponto de vista, o movimento total é basicamente um efeito especial caro. Parece
ótimo, como nos corredores, como nas lutas. Mas se tivéssemos decidido usar isso para todo
o jogo, acho que teríamos acabado com algo visualmente muito chamativo, mas não muito
profundo. Estamos limitados tanto pela quantidade de quadros que podem ser mantidos na
RAM quanto pelo número de CDs. Mas, em última análise, você está limitado pela capacidade
do processador. Quando você entra no restaurante e está cheio de pessoas, com várias
animações diferentes acontecendo na tela ao mesmo tempo, além de várias faixas de áudio
Machine Translated by Google

332 Capítulo 18: Entrevista: Jordan Mechner

streaming do CD, isso só


é possível porque cada
personagem é animado
apenas a cada poucos
segundos.

Mas também há uma


desvantagem estética no
movimento total. Digamos
que as limitações
tecnológicasser
pudessem
superadas,
e
tivemos um loop de trinta
segundos de um
personagem jantando.
Mais cedo ou mais tarde
você percebe que o
personagem está se O Último Expresso
repetindo. Então você diz:
“Por que é que quando ele toma um gole de sua taça de vinho e depois dá uma mordida no bife,
o bife continua sendo reabastecido toda vez que ele o come?” Isso não é útil para o jogo, distrair
a atenção do jogador seguindo aqueles pequenos pedaços de movimento completo. No fim das
contas, decidimos que o importante para o jogo é que o jogador acredite que o personagem está
lá, jantando por uma hora e quinze minutos. E a qualquer hora durante essa hora você pode falar
com ele. O fato é que a dissolução entre quadros estáticos dá uma sensação impressionista de
“jantar” tão boa quanto o movimento completo, e de certa forma melhor, porque você não tem
essa falha quando o filme faz um loop. Então, com essa convenção, uma vez que o jogador a
aceita, ela abre o mundo e dá a você a capacidade de contar essa grande história que dura três
dias e três noites com trinta personagens fazendo todo tipo de coisa. Teria sido uma história
drasticamente menor se tivéssemos mantido o movimento total.

Percebi nos créditos que para quase todos os personagens você tem um ator fazendo a
atuação física – o que o jogador vê na tela – e outro fazendo a voz. Por que você decidiu
usar atores diferentes para os aspectos visuais e de áudio do jogo?

A seleção de elenco foi um tremendo desafio com um elenco onde você tem apenas dois
americanos, e todos os outros são franceses, russos, austríacos, sérvios, árabes. . . O Expresso
do Oriente era um trem verdadeiramente multilíngue. Tomamos a decisão de que os personagens
não apenas falassem inglês com sotaque estrangeiro, como quando estão conversando com o
herói americano, mas também falassem sua língua nativa, legendada, sempre que normalmente o fariam.
Quando os dois regentes franceses estão conversando um com o outro fora de serviço, eles
naturalmente estariam falando francês. Então, escalar atores americanos que podem fazer um
falso sotaque alemão ou francês simplesmente não era aceitável para nós. Precisávamos de
falantes nativos para cada idioma. Acho que tivemos muita sorte de conseguir um elenco tão bom
tanto para os rostos quanto para as vozes. Mas pedir o rosto perfeito, a voz perfeita e a
nacionalidade perfeita para se unir em uma pessoa para cada papel seria pedir demais –
especialmente em São Francisco, com nosso orçamento! Novamente, o fato de não estarmos fazendo full-mo
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 333

dublagem nos deu a flexibilidade que precisávamos no casting.


Tatiana é um caso a parte. Usamos três agências de elenco e testamos centenas de atores
em Los Angeles e São Francisco, procurando o rosto e a voz de uma princesa russa de seis anos.
A atriz que acabou fazendo a voz é russa e mora em LA, a que filmamos é americana e mora em
São Francisco. Para encontrar um ator que fosse tão bom para os dois, certamente precisaríamos
sair do estado, se não para a Rússia!

A propósito, gravamos as vozes primeiro e depois criamos visuais animados para combinar,
para que os dubladores ficassem livres para criar sua própria performance, como fariam com uma
peça de rádio ou fazendo um desenho da Disney. Dá-lhe um desempenho de voz mais natural do
que overdubbing. Eu acho que quando você força os atores a dublar a ação filmada anteriormente,
você perde algo na performance.

A realidade parece ter sido um objetivo dominante no design do jogo, sejam os falantes
nativos para a dublagem ou os vagões de trem autenticamente modelados. Por que você se
esforçou tanto para tornar o jogo o mais real possível?

É uma questão de respeito ao jogador. Seja um mundo de história ou um mundo de fantasia, acho
que os jogadores respondem à quantidade de detalhes e consistência que os criadores do jogo
colocaram nele. E mesmo que o jogador não preste atenção suficiente aos condutores para
descobrir que um deles está perto da aposentadoria e o outro é um jovem casado, ou que têm
visões políticas opostas, mesmo assim, sempre que você passa eles no corredor e ouvir um pouco
de uma de suas conversas, você tem a sensação subliminar de que está ouvindo uma conversa
real entre duas pessoas reais. Se não tivéssemos nos incomodado, sempre que você passasse,
ouviria algo artificial e pensaria: “Sabe, isso soa como algo que eles acabaram de encenar para
meu benefício”. O fato de que o que você vê no jogo é apenas a ponta do iceberg, e que todos os
personagens têm sua própria história e sua própria realidade sob a superfície, você sente a massa
disso e o peso disso, embora você não vejo nada além da ponta.

Você acha que os jogos de computador em geral deveriam buscar maior realismo?
Bem, realismo é um termo um pouco carregado. Não quero dizer que os jogos devam ser mais
realistas em termos de representação do nosso mundo. Mesmo algo como Super Mario Bros., que
é completamente um cenário de fantasia, tem sua própria consistência. Se um personagem pode
pular de uma borda e flutuar até o fundo em uma situação, você não deve ter outra situação em
que ele pula e é esmagado. Desde que os criadores realmente tenham tempo para pensar: “Quais
são as regras da gravidade neste mundo e em que circunstâncias você pode se machucar?” Desde
que o jogo siga suas próprias regras, os jogadores irão aceitá-lo. Em Last Express, escolhemos
um momento histórico real, e estávamos muito conscientes em tentar representar fielmente o que
estava acontecendo no mundo naquele momento, e respeitar essa realidade ao desenhar as
restrições do nosso mundo ficcional.
Machine Translated by Google

334 Capítulo 18: Entrevista: Jordan Mechner

Você usa uma técnica muito original em Last Express onde, embora os atores tenham sido filmados, no final
eles parecem desenhos muito bem elaborados. Por que você decidiu fazer assim?

Para começar, gosto do aspecto


estético dos desenhos

animados. Eu acho que a


aparência das pessoas dos
desenhos animados contra um

fundo renderizado
muito
em 3D
atraente.
é
Filmes
como Branca de Neve e os Sete
Anões tinham razões técnicas

para serem planos – eles eram


pintados em cels – mas eles
trazem o personagem bem, e
eu acho que é um visual que
tem boas conotações para
aqueles de nós que quando
crianças queria entrar no

desenho animado e se tornar


um dos personagens. O Último Expresso

Eu acho que para jogos de computador há outra vantagem em ter os personagens como desenhos animados,
ao invés de pessoas ao vivo, filmadas. A experiência do jogador de jogos de computador depende de ser capaz de
se colocar em um mundo de fantasia, suspender a descrença e acreditar que o que você está fazendo realmente tem
um efeito sobre esses personagens fictícios. Se você está assistindo a um ator ao vivo filmado, intelectualmente sabe
que é alguém que foi filmado em um palco de som, fantasiado, com luzes e câmeras, e o que quer que ele esteja
dizendo e fazendo na tela é o que ele fez no set. . Você sabe que está assistindo a uma cena. Considerando que com
um desenho animado, eles não são reais para começar, então se você pode acreditar que um personagem de
desenho animado pode andar e falar, por que ele também não deveria ser capaz de mudar seu comportamento em
resposta às suas ações como jogador - por por exemplo, fugir quando ele vê você chegando?

Então isso aumenta a suspensão da descrença?

Ou, pelo menos, não o quebra, enquanto a ação filmada o faria. E acho que isso é parte do motivo pelo qual as
cutscenes de vídeo não tiveram sucesso em jogos de computador em geral.
Não é apenas um bom ajuste.
Finalmente, é claro, há uma última razão pela qual o estilo cartoon funciona em Last Express, que é histórico.
A maior parte das imagens que temos, culturalmente, de 1914, chegam até nós através de desenhos da época:
desenhos de jornais, anúncios de revistas, cartazes de artistas como Alphonse Mucha e Toulouse-Lautrec, que eram
em estilo Art Nouveau que era realmente o precursor da história em quadrinhos moderna. Então eu acho que quando
vemos alguém em 1914 vestido de desenho animado, parece certo de certa forma,
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 335

Considerando que se víssemos uma pessoa de 1914 como um modelo poligonal 3D, não teria o mesmo
ressonância.

Então você acha que um jogo com um cenário mais moderno poderia usar a mesma abordagem
de personagens de carros para os visuais?
Bem, eu gosto muito do visual, e poderia funcionar em muitas situações diferentes. Eu não acho que
precisa ser um cenário histórico. Mas era apenas mais uma razão pela qual, para o Last Express, era
perfeito demais para resistir.

Então, já que os personagens acabaram parecendo desenhos animados, por que você não os
desenhou desde o início, em vez de filmar atores e depois fazê-los parecer desenhos?

Uma razão foi que, para obter a alta qualidade de animação e expressão cel-type que você tem em um
filme da Disney, você precisa gastar tanto dinheiro quanto a Disney gasta. Por mais caro que este jogo
fosse para os padrões de jogos de computador, é uma pequena fração do que você gastaria em um
filme de animação. Queríamos garantir a consistência de que o mesmo personagem se pareceria com
o mesmo personagem, fosse visto de perto ou de longe, com raiva ou feliz, e de ângulos diferentes e
muito difíceis de desenhar. E para conseguir isso para quarenta mil quadros animados, não há como
fazer isso com o orçamento que tínhamos.

O objetivo do nosso rotoscópio automatizado era pegar um quadro filmado em preto e branco e
transformá-lo em algo parecido com um desenho de linha de caneta e tinta, onde um artista poderia
puxar esse quadro e colori-lo em menos de dois minutos. Chegamos ao ponto em que o montamos
como uma linha de montagem. E não só isso, mas você poderia ter dois artistas diferentes trabalhando
no mesmo personagem, e como a digitalização e a rotoscopia foram feitas automaticamente, produziria
resultados muito semelhantes. Anna se parece com Anna, independentemente de quem a coloriu para
essa sequência.
Não queríamos que parecesse uma imagem de filme processada e não queríamos que parecesse
exatamente com um desenho animado. Se você vir um personagem andando em sua direção no
corredor e não tiver certeza se está olhando para um desenho ou uma imagem filmada processada,
então praticamente alcançamos nosso objetivo. E eu acho que nós fizemos. Ocasionalmente, alguém
pergunta: “Você desenhou tudo isso à mão?” Se eles não podem dizer que foi filmado, então funcionou.

Achei que um dos elementos de design mais inovadores do jogo é o sistema de save-game que
você usou. Os jogadores nunca salvam o jogo, mas o Last Express lembra automaticamente de
tudo o que fazem, e eles podem “rebobinar” para qualquer ponto do jogo que quiserem, se
quiserem tentar algo de uma maneira diferente. Como você chegou a esse sistema?

Estou feliz que você perguntou. Estou muito orgulhoso do sistema de save-game. O engraçado é que
algumas pessoas, incluindo alguns revisores, simplesmente não entenderam. Ainda recebemos
ocasionalmente uma crítica em que eles dizem: “É uma pena que você não possa salvar seu jogo”.
Nosso objetivo, é claro, era uma extensão da filosofia de design que entrou no sistema de apontar e
clicar; queríamos que fosse muito simples, muito transparente e intuitivo. Ter que pensar no fato de que
você está em um computador, e você tem que salvar um arquivo, e como você vai nomear o arquivo, e
como isso se compara ao seu arquivo de jogo salvo anterior - para mim isso
Machine Translated by Google

336 Capítulo 18: Entrevista: Jordan Mechner

quebra a experiência. A ideia era que você simplesmente sentasse e jogasse, e quando parasse
de jogar, você poderia simplesmente sair e ir jantar, ou usar o computador para outra coisa, ou
qualquer outra coisa. E quando você voltar a jogar, ele deve automaticamente colocá-lo de volta
de onde parou. E se você cometer um erro, deve ser capaz de rebobinar, como rebobinar uma
fita de vídeo, voltar ao ponto em que acha que errou e começar a tocar a partir daí. E acho que
funciona. Os seis ovos de cores diferentes foram inspirados, eu acho, no Monopólio , onde você
pode escolher qual peça quer: o chapéu ou o carro. . .
A ideia era que, se você tem uma família de seis, todos terão seu próprio ovo, e quando alguém
quiser jogar, pode simplesmente mudar para seu próprio ovo e pegá-lo de onde parou. As
pessoas que reclamam que você só pode ter seis jogos salvos, ou que você tem que usar cores
em vez de nomes de arquivos, são fixadas no sistema de arquivos de jogos salvos convencional;
eles perderam o ponto. Um arquivo egg não é um jogo salvo; é essencialmente uma fita de vídeo
contendo não apenas seu último ponto de salvamento, mas também todos os pontos ao longo
do caminho que você não parou e salvou. Normalmente, você pode retroceder de três a cinco
minutos em tempo real do ponto desejado.

A música também parece ter sido efetivamente usada em Last Express. Ele muda
dependendo do que está acontecendo no jogo, ao contrário da música na maioria dos
jogos de aventura que apenas toca em segundo plano, nunca mudando. Como você
abordou o aspecto musical do jogo?
Sabíamos que a música seria muito importante para a textura do jogo, e encontrar o compositor
certo era muito importante. E nós o encontramos: Elia Cmiral, um compositor de cinema muito
talentoso da Tchecoslováquia, que, aliás, não é um jogador de jogos de computador, nunca havia
feito um jogo de computador, e acho que até hoje nunca jogou um jogo de computador . Nós
abordamos isso como uma história, como situações, e uma vez que ele entendeu que havia
situações mutuamente contraditórias possíveis na mesma história – que em um resultado Cath é
esfaqueada e morta e em outro resultado ele supera isso e continua a história – ele não teve
nenhum problema em marcar as diferentes variações. (Elia desde então alcançou sucesso como
compositor de Hollywood com trilhas para Ronin, Stigmata e outros filmes.)

Na verdade, embora o clichê seja que o compositor sempre quer adicionar mais música e
diminuir os efeitos sonoros para que a música fique mais alta, Elia é muito disciplinada sobre o
papel da música. Para cenas em que eu achava que ele colocaria um grande acorde dramático
ou pelo menos um pouco de sublinhado, ele dizia: “Não, isso é brega, funciona melhor sem isso”.
Então ele estava realmente reduzindo o número de situações, guardando a música para lugares
onde realmente poderia acrescentar algo. Não temos nenhuma música de fundo no Last Express;
não há nenhum ponto em que a música está apenas se repetindo no fundo, esperando que você
faça alguma coisa. A verdadeira música de Last Express é o barulho do trem. Você fica muito
sintonizado com mudanças sutis no ambiente: uma porta se abre, o barulho do trem fica mais
alto, ou você ouve uma porta se fechar em algum lugar, ou ouve um estrondo de trovão à
distância, ou o trem desacelera ao chegar Uma estação. Tudo isso quase vem ao primeiro plano
na trilha sonora, de modo que quando a música aparece é realmente perceptível.
E nas cenas dramáticas, as cut-scenes, nós pontuamos como você faria em um filme, usando
música, espero sutilmente, para trazer à tona os diferentes personagens e situações. O fato de
Anna, a protagonista, ser violinista, deu a Elia um importante motivo instrumental para a partitura.
Há algumas horas de jogo no segundo dia em que Anna está praticando em
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 337

seu compartimento, e se você anda pelo trem você a ouve tocando partitas de Bach, afinando,
tocando escalas e assim por diante. O tema principal de sua personagem também é um tema de
violino, e aparece em diferentes formas em diferentes situações à medida que a história se desenvolve.

É um jogo que você realmente não gostaria de jogar com o som desligado.
Certamente perderia muito sem o som. No Last Express o som é mais do que apenas o diálogo.
Sem a mudança no ruído ambiente, a música, os efeitos sonoros operando como pistas, a sensação
de ouvir uma conversa tão longe que você não consegue distinguir as palavras e depois se aproximar
dela, e depois o efeito de ouvir conversas em línguas estrangeiras que você não consegue entender,
não importa o quão perto você esteja, tudo isso é realmente essencial para a experiência de The
Last Express. É engraçado porque as pessoas tendem a se concentrar nos gráficos. Mas uma das
coisas tecnicamente mais inovadoras que fizemos foi na trilha sonora. A maioria das pessoas não
está ciente disso, mas na verdade temos seis faixas de som sendo simultaneamente transmitidas do
CD e mixadas na hora. Por exemplo, você pode ter o ruído ambiente do trem, o efeito sonoro de
uma porta se abrindo, duas pessoas conversando, trovões rolando à distância e um pouco de música
saindo da última cena, e tudo isso acontecendo no mesmo tempo. Realmente cria uma tapeçaria
sonora muito rica.

Novamente diferente de muitos outros jogos de aventura, Last Express oferece uma
experiência bastante não linear para o jogador, onde parece haver várias maneiras de chegar
ao fim. Você acha que a não linearidade em jogos de aventura é importante?

É crucial; caso contrário,


não é um jogo. Existem
alguns modelos de jogos
dos quais eu queria me
afastar, um dos quais é
onde você tem que fazer
uma certa coisa para
chegar à próxima cena ou
a história não progride.

Outra é o tipo de árvore


ramificada, estilo “Escolha
sua própria aventura”, onde
há dez maneiras de ahistória
terminar, e se você tentar
todas as dez opções,
chegará a todas as dez. O Último Expresso

Uma das sequências de


quebra-cabeça que acho que funcionou melhor em Last Express é uma das primeiras, onde você
encontra o corpo de Tyler e precisa descobrir o que fazer para se livrar dele. Existem várias soluções
igualmente válidas, e cada uma tem suas próprias desvantagens, efeitos de ondulação ao longo da
linha. Por exemplo, se você esconder o corpo na cama, corre o risco de que quando o condutor vier
arrumar a cama ele descubra o corpo ali, então você
Machine Translated by Google

338 Capítulo 18: Entrevista: Jordan Mechner

tem que lidar com isso de alguma forma. Você pode evitar esse problema jogando o corpo pela
janela, mas se fizer isso, o corpo será descoberto pela polícia. E eles embarcam no trem na
próxima parada e você tem que descobrir como se esconder da polícia quando eles vão de
compartimento em compartimento verificando passaportes. De qualquer forma, suas ações têm
consequências sobre as pessoas ao seu redor. Como outro exemplo, se você jogar o corpo pela
janela, poderá ouvir François, o garotinho, dizendo à mãe: “Ei, vi um homem sendo jogado pela
janela”. E ela vai dizer a ele: “Cala a boca, seu pirralho, não conte mentiras!”

Eu nem tinha notado isso.

O jogo está cheio de pequenas coisas assim.

Então é por isso que você não gosta de outros jogos de aventura, porque eles são muito
definidos no estilo “primrose path”?
Alguns jogos de aventura têm ótimos momentos, mas em termos de experiência geral, é raro que
um jogo mantenha consistentemente um nível tão alto. Em Last Expresstoo, há partes do jogo que
não correspondem às expectativas criadas por aquele primeiro quebra-cabeça de descarte do
corpo. Desarmar a bomba é algo com que eu não estava tão feliz. Você apenas tem que cerrar os
dentes e seguir os passos; não há como contornar isso. Não é um quebra-cabeça particularmente
inteligente. Mas, novamente, a principal preocupação era que a história funcionasse no geral e que
a experiência geral fosse satisfatória.

Ouvi muitos designers de jogos de aventura dizerem que para contar uma história de forma
eficaz, você realmente precisa limitar as opções do jogador e forçá-lo a seguir um caminho específico.
Você concorda com essa noção?
É verdade, claro; é apenas uma questão de como você limita o que o jogador faz. O limite óbvio
demais para mencionar no Last Express é que você não pode sair do trem. Toda vez que você
desce do trem, o jogo termina. A única maneira de vencer é ficar no trem até Constantinopla.
Então, nesse sentido, sim, é a história linear definitiva. Você está em um trem, você não pode sair.
Mas dado isso, dentro do trem você deve poder se movimentar o mais livremente possível. Há
algumas portas que tivemos que fechar porque teriam mudado muito a história e não nos deixariam
chegar ao final que queríamos. E se você pegar a arma e passar pelo trem e matar todo mundo?
Decidimos que você simplesmente não pode fazer isso. Então, definitivamente, há uma troca.
Quanto mais opções malucas e inusitadas você der ao jogador, mais isso limita a complexidade e
o poder da história que você se propôs a contar. Considerando que, se você quiser manter uma
narrativa central muito ambiciosa e de grande alcance, então você precisa começar a fechar as
portas em torno disso, para garantir que o jogador permaneça no jogo.

Cada jogo aborda esse desafio de uma maneira diferente. Com Last Express, o tema do trem
nos deu a metáfora de que precisávamos para mantê-lo nos trilhos. Acho que quando as pessoas
percebem que estão no trem, o tempo está passando, e elas precisam fazer certas coisas antes
de certas paradas, e precisam chegar a Constantinopla ou então não chegaram ao fim de a linha;
uma vez que eles obtêm isso, a história funciona. É uma questão de encontrar um equilíbrio para
o que funciona para cada história em particular. O que é certo para um jogo pode não
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 339

estar certo para outro. Eu nem começaria a saber como usar o mecanismo Last Express para fazer
um jogo que não fosse ambientado em um trem.

Last Express parece não ter vendido bem por causa da falta de um mercado de jogos de
aventura. No entanto, os jogos de aventura costumavam ser muito populares. Eu estou
querendo saber se você tinha alguma idéia do que aconteceu com todos os jogadores de jogos de aven
Essa é uma boa pergunta, e devo dizer que fui pego de surpresa quando acordei e descobri que o
mercado de jogos de aventura estava morto, porque nunca pensei muito em termos de gêneros.
Mesmo fazendo Last Express, o fato de Prince of Persia ser um jogo de ação enquanto Last Express
era um jogo de aventura, eu simplesmente não estava pensando dessa forma, certo ou errado. Como
jogador de jogos, eu não sou um grande jogador de jogos de aventura, por muitas razões. Normalmente
os gráficos não eram muito bons, as linhas da história eram meio arbitrárias e artificiais, os personagens
e o enredo simplesmente não se sustentavam em termos do tipo de história que eu gostaria de ver
em um filme ou romance.
Então, com Last Express , eu queria fazer um jogo que tivesse o que eu via como as qualidades
que faltavam na maioria dos jogos de aventura que estavam por aí. Então, como jogador, acho que
tenho que assumir minha parcela de culpa por não apoiar o mercado de jogos de aventura. Acho que
subestimei o grau em que o mercado de jogos foi estratificado pelos diferentes gêneros. Você tinha
pessoas por aí que se viam como jogadores de jogos de ação, como jogadores de jogos de estratégia,
como jogadores de RPG ou como jogadores de jogos de aventura. Eu nunca comprei jogos dessa
forma, mas acho que depois de alguns anos lá no início dos anos 90, até as publicações de jogos de
computador começaram a estratificar os jogos de acordo com o gênero. Assim como as editoras, as
lojas também, e acho que não esperava isso.

Então você não tem nenhuma ideia sobre por que o mercado de jogos de aventura secou?
Bem, só posso olhar para a minha própria experiência como jogador. Eu gostava de jogar jogos de
aventura nos dias de Scott Adams, e então fiquei meio entediado com eles. Acho que os criadores de
jogos de aventura precisam parar de perguntar: “Para onde foi o mercado?” Acho que a pergunta é:
“Por que as pessoas não acham mais esses jogos divertidos de jogar?” Talvez seja alguma coisa
sobre os próprios jogos.

Seus dois primeiros jogos, Karateka e Prince of Persia, foram ambos esforços solo, onde você
fez todo o design, escrita, programação e até desenhou a arte. Como você compara trabalhar
com uma grande equipe no Last Express a trabalhar sozinho?

É muito mais emocionante e recompensador do que trabalhar sozinho, porque você tem a chance de
trabalhar em colaboração com uma grande equipe de pessoas talentosas que são realmente dedicadas
e que se destacam em suas próprias especialidades. Foi uma das experiências mais emocionantes
da minha vida profissional. A desvantagem, é claro, é que você gasta todo o seu tempo se preocupando
com a origem da próxima folha de pagamento. Uma coisa que era muito legal nos velhos tempos era
que o custo de desenvolver um jogo era insignificante. Uma vez que você pagou os dois mil dólares
pelo computador e obteve cinco disquetes vazios, basicamente foi pago. Considerando que com um
grande projeto há muita pressão para cumprir orçamentos e cronogramas.
Machine Translated by Google

340 Capítulo 18: Entrevista: Jordan Mechner

Os jogos de computador parecem ser uma das únicas formas de arte que passaram de
empreendimentos predominantemente solo para esforços mais colaborativos, pelo menos
para títulos comerciais. Como você acha que isso afeta os jogos finais?
É interessante. O que
estou fazendo agora,
escrevendo roteiros de
filmes, me lembra mais
programação do que
qualquer outra atividade
que fiz em muito tempo.
Assim como programar,
escrever roteiros é
basicamente uma questão
de fechar a porta atrás de
você em uma sala com um
computador e nada mais.
Você está tentando criar
algo do zero. Se você
Karateca
escreve um roteiro que
vira filme, nesse ponto,
como um jogo de computador moderno, você tem todo o circo, com pessoas altamente
especializadas e habilidosas, e é uma colaboração criativa entre centenas ou mais, todos os quais
trazer sua própria área de especialização. Um filme de grande orçamento, apesar de todo o caos
diário da produção, vive ou morre na força do roteiro que foi escrito, muitas vezes, anos antes. Um
jogo moderno é um esforço colaborativo da mesma forma, com um orçamento muito apertado, com
dinheiro sendo gasto diariamente, geralmente com uma editora que aposta em poder enviá-lo em
uma determinada data. Aí, novamente, o que faz funcionar ou não é a força do conceito, a visão
inicial, que costuma anteceder toda a produção. Simplesmente não há tempo para mudar de ideia
durante a produção sobre o que o jogo deveria ser.

Mas isso tende a limitar que tipo de designer de jogos pode ser bem-sucedido, não é?
Aquele que precisa fazer mudanças radicais ao longo do projeto para encontrar a
jogabilidade ideal teria tido mais sucesso em 1982 do que agora. Agora ele não estaria
trabalhando.
Ele simplesmente não estaria trabalhando em uma produção multimilionária de grande orçamento.
Acho que um jogo como Tetris está ao alcance de qualquer pessoa sonhar e programar, e se levar
um ano para encontrar a combinação perfeita de regras que o tornará infinitamente viciante, tudo
bem, não é tão caro. Mas você não pode assumir um projeto com o mais recente mecanismo 3D e
quarenta artistas à sua disposição e ligar e pensar que no meio do caminho você vai dizer: “Ah,
agora eu percebo o que este jogo realmente precisa, eu gostaria Eu tinha pensado nisso há um
ano.”
Estamos em um momento muito difícil no setor. Não tenho certeza se faz muito sentido do
ponto de vista econômico ser um desenvolvedor. Acho que faz sentido ser um editor, mas mesmo
assim só há espaço para alguns. Este é um momento assustador porque o número de acessos é
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 341

pequeno, mas o tamanho desses acertos é maior do que nunca. Se você é um editor com um Myst ou um
Tomb Raider que vende dois ou três milhões de unidades, isso é ótimo; seus outros dez títulos podem ser
flops e você ainda sobrevive. Mas se você é um pequeno desenvolvedor com apenas um título em produção,
como foi o Smoking Car, você precisa tirar a sorte grande. Apenas um punhado de títulos a cada ano vende
mais de meio milhão de unidades, e essa é a categoria que você precisa aspirar para justificar o tipo de
orçamento de que estamos falando.

E para fazer um jogo com os valores de produção da Last Express você precisa mesmo de um grande
orçamento?

Acho que em Last Express estendemos bastante o orçamento para o que realmente conseguimos na tela.
Economizamos muito dinheiro; conseguimos que as pessoas trabalhassem por menos do que seus salários
usuais ou adiassem salários, não gastamos muito dinheiro na filmagem, usamos um elenco não sindicalizado
e uma equipe não sindicalizada, e não tínhamos quaisquer grandes nomes. Então, praticamente economizamos
dinheiro em todos os lugares em que podíamos pensar. E, no entanto, apenas por causa da natureza do
projeto, da escala do jogo, do número de pessoas envolvidas e do tempo que levou, acabou custando muito.

Se você não se importa em dizer, quanto custou o jogo?


Cerca de cinco milhões.

E o desenvolvimento levou quatro anos; essa era sua intenção original?

Demorou dois anos a mais do que o planejado.

O que fez com que demorasse muito mais do que você pensava?

O desenvolvimento de ferramentas foi um deles. Para desenvolver nossa própria tecnologia de rotoscopia,
tivemos que fazer muitos testes – diferentes tipos de fantasias, maquiagem, processamento – para que ficasse
do jeito que queríamos. Esse foi um. E a modelagem 3D; aquele modelo era enorme, o interior e o exterior do
trem, e o número de imagens renderizadas era enorme. Modelagem e renderização 3D, animação e
desenvolvimento de ferramentas foram as áreas que ultrapassaram seus limites. A filmagem propriamente dita
chegou dentro do cronograma e do orçamento; Essa era a parte fácil.

Então, olhando para trás, você gostaria de ter conseguido fazer o projeto em menos tempo, com um
orçamento menor? Ou você está satisfeito que isso é apenas quanto tempo foi necessário?

Bem, pessoalmente tomei um banho no Last Express, financeiramente. Então, nesse sentido, provavelmente
não foi uma jogada inteligente. E me sinto mal por nossos investidores que também esperavam que o jogo
vendesse meio milhão de unidades e ficaram desapontados. É como ter comprado um bilhete de loteria
extremamente caro.
Por outro lado, estou orgulhoso do jogo, feliz por termos feito isso e não acho que poderíamos ter feito
muito mais barato do que fizemos. Estou feliz com o jogo finalizado. Claro, o ideal teria sido projetar um jogo
menor. Se, no começo, nós olhássemos para as coisas e dissessemos: “OK, isso vai levar quatro anos e custar
cinco milhões de dólares”, não haveria uma editora no mundo que teria tocado nisso. Eu mesmo não teria
tocado! Para melhor ou pior, há uma certa quantidade de vontade
Machine Translated by Google

342 Capítulo 18: Entrevista: Jordan Mechner

auto-ilusão que a maioria de nós na indústria de software se entrega apenas para sair da cama pela
manhã. Mesmo os jogos que levam dois anos para serem desenvolvidos geralmente começam com o
produtor e o departamento de marketing dizendo um ao outro que isso pode ser feito em um ano e
lançado no Natal. Quanto mais tecnicamente ambicioso o projeto, menos você sabe no que está se
metendo.
A indústria cinematográfica, por outro lado, é relativamente boa em orçamentar e agendar
filmagens e fazê-las no tempo necessário. A desvantagem é que eles não costumam tentar coisas
realmente novas. Quando o fazem, como usar uma nova tecnologia pela primeira vez, ou filmar em
locações em um país devastado pela guerra, ou filmar no mar, geralmente experimentam o mesmo
tipo de orçamento e excesso de cronograma que são comuns em jogos de computador. No Last
Express, toda a produção dependia do desenvolvimento desse novo processo de rotoscopia, então,
até certo ponto, no início, quando dissemos: "Sim, vamos desenvolvê-lo e levará x meses e custará
tanto", estávamos basicamente operando com fé cega, seguindo em frente assumindo que poderíamos
resolver quaisquer problemas que houvesse e que funcionaria – o que acabou acontecendo. É muito
difícil fazer projeções precisas de tempo e custo quando você está fazendo algo pela primeira vez. No
Last Express estávamos fazendo talvez dez coisas que nunca haviam sido feitas antes, todas ao
mesmo tempo. Isso provavelmente foi imprudente.

No geral, o planejamento irrealista não é uma coisa boa para os desenvolvedores; isso realmente
não nos ajuda. Um dos meus arrependimentos sobre este projeto foi que estávamos sob tanta pressão
financeira no dia a dia que eu passava metade do meu tempo me preocupando com o jogo e metade
do meu tempo me preocupando em arrecadar dinheiro. Essa é a situação em que nos coloquei ao
empreender um projeto tão ambicioso.

Last Express é o primeiro de seus projetos pessoais em que você não fez nenhuma programação.
Você sente falta disso tudo?
Uma grande coisa sobre programação é que, quando você está realmente em movimento, você pode
se trancar em uma sala e ter a satisfação de progredir todos os dias; é só você e a máquina. As vezes
em que eu mais sentia falta disso geralmente era quando eu tinha acabado de passar dois dias em
reuniões consecutivas. Por que essas reuniões tinham que acontecer e por que eu tinha que estar
nelas? No Last Express, tivemos quatro programadores trabalhando no projeto e, embora muitas vezes
eu invejasse o destino deles, tive minhas mãos mais do que ocupadas com o design do jogo, roteiro,
artistas e animadores, escalando e dirigindo os atores na gravação de voz e filme filmar, trabalhando
com o compositor, designer de som e editor, para listar algumas coisas que eu realmente gostei de
fazer. Em vários pontos, ofereci meus serviços aos programadores, mas como minha última área de
conhecimento de código era em 6502 Assembly Language [no Apple II], eles decidiram que não
precisavam realmente de mim.

Last Express é um jogo extremamente único em configuração e design. Em contraste, a maioria


dos novos jogos lançados parecem ser ambientados em cenários de fantasia ou ficção científica,
e são todos baseados no grande sucesso do ano passado. Como você se sente sobre a
tendência da indústria em relação aos jogos “eu também”?
Com a exceção ocasional magnífica, acho que você está certo sobre a maioria dos jogos. Não sei se
o problema do “eu também” é principalmente em termos de ambientação. Acho que sinto isso mais em
termos de gêneros. Você pode pegar Doom e mudar as texturas para que fique
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 343

um trem expresso em
1914, mas não acho que
seja realmente disso que
a indústria precisa. O que
é mais interessante para
mim é experimentar o
design do jogo em si, como
o jogo é construído, o que
o jogador está realmente
fazendo, tentando criar
uma nova forma que
funcione. Esse tipo de
experimentação era muito
mais fácil de fazer quando
o preço das ações da
editora não dependia do
sucesso ou fracasso do O Último Expresso
experimento. É
definitivamente mais fácil obter apoio para algo que é uma sequência ou variação de uma fórmula
comprovada. Quanto mais difícil for descrever ou explicar algo novo, menos pessoas ou empresas
estarão dispostas a arriscar dinheiro com isso. Acho lamentável, mas não sei o que fazer a respeito.
É praticamente um resultado inevitável do ciclo; quando vamos à loja de informática como
comprador e procuramos o próximo jogo, sejamos honestos, o que estamos procurando? Estamos
mais inclinados a olhar para coisas que são fortemente promovidas, sobre as quais lemos em
revistas. Portanto, títulos que saem com pouca fanfarra terão mais dificuldade em alcançar o
mercado maior. Então, de certa forma, como público, estamos recebendo o que pedimos. Mas
como designer de jogos, sim, sinto falta disso.
Meus amigos que ganham a vida com filmes sempre diziam: “Cara, eu realmente invejo você
fazendo jogos de computador. Lá você tem a chance de fazer algo realmente original. Enquanto
aqui em Hollywood tudo o que eles querem são recauchutagens da sequência do ano passado.” É
interessante como a indústria de jogos agora tem o mesmo conjunto de problemas que os cineastas
reclamam há anos. Talvez ainda pior. Junto com valores de produção maiores, mercados maiores
e cerimônias de premiação mais chamativas, alcançamos uma espécie de paralisia de gênero e
tornou-se mais difícil abrir novos caminhos.

Então você se sente frustrado mais do que qualquer coisa.


Acho que renunciou. Acho que toda nova forma de arte passa por estágios de sua evolução. Com
os jogos de computador, vivemos os excitantes primeiros anos, e agora estamos nos anos de
dores de crescimento. Isso definitivamente não significa que a inovação pare. Mesmo no cinema,
que tem cem anos, a cada dois anos sai um filme que, seja por causa de mudanças sociais ou
mudanças tecnológicas, não poderia ter sido feito alguns anos antes, e é um valioso passo à frente.
É só que você precisa eliminar centenas de clones e filmes medíocres para encontrar essas poucas
joias. Acho que estamos no mesmo lugar com os jogos de computador. Todos os anos, de centenas
de novos jogos, há alguns que empurram o envelope de uma maneira nova e interessante. O
melhor que podemos
Machine Translated by Google

344 Capítulo 18: Entrevista: Jordan Mechner

fazer é continuar tentando fazer isso, e parar de reclamar sobre os gloriosos primeiros anos passados,
porque eles acabaram!

Então, quão envolvido você estava com o projeto Prince of Persia 3D ?


Meu envolvimento se limitou a dar a eles o sinal verde no início e oferecer conselhos ocasionais e
consultoria criativa ao longo do caminho. Era um projeto Broderbund.
Andrew Pedersen, o produtor, iniciou. Era seu bebê. Ele reuniu a equipe e trabalhou duro por dois
anos. Então eu não posso levar o crédito por isso.

É muito difícil pegar um jogo 2D e fazê-lo funcionar em 3D, com total liberdade de movimento
para o jogador.
Esse é o problema, realmente. Quando você converte Prince of Persia para 3D por cima do ombro,
um problema é como você mantém os controles simples. E a outra é como o jogador sabe em que tipo
de ambiente ele está. Porque você só vê o que está bem na sua frente. Um exemplo grosseiro é que
você está correndo em direção à beira de um abismo. Com uma visão lateral, você pode olhar para
ele e ver se é um salto de três espaços ou um salto de quatro espaços e você vai limpá-lo ou não. Se
for muito longe, você sabe que nem faz sentido tentar.
Considerando que em um jogo 3D por cima do ombro, você não sabe o quão longe está até tentar. E
mesmo assim, quando você cai, você se pergunta: “Eu não estava no limite? Ou eu não pulei na
direção certa?” Por isso, torna-se um tipo diferente de jogo. Você ganha em termos de imediatismo
visceral e, claro, de riqueza do ambiente, mas acho que perde algo em termos de estratégia limpa.

Então você não acha que fazer todos os jogos em 3D é necessariamente a abordagem correta?

Bem, você tem que distinguir a tecnologia de gráficos 3D em tempo real de uma interface específica.
Eu acho que há muito que pode ser feito com motores gráficos 3D em tempo real.
Doom, o jogo de tiro em primeira pessoa, foi obviamente o primeiro protótipo e essa foi a tendência por
alguns anos. E então Tomb Raider e Super Mario fizeram a seguinte câmera.
Prince 3D se enquadra nessa categoria. Então, acho que o desafio é encontrar novas maneiras de
apresentar a ação cinematográfica que seja tão divertida quanto os jogos antigos, mas que ainda
tenha toda a emoção visual dos novos jogos 3D. Acho que ainda há muito terreno para percorrer.
Prince 3D teve alguns momentos intrigantes nele que eu gostaria de ver empurrados muito mais longe
para inventar a próxima grande coisa em jogos de ação 3D.

Li que você gostou bastante de Tomb Raider . Isso parecia ser uma tentativa de colocar Prince
of Persia em um ambiente 3D para produzir algo novo e emocionante.

Acho que a palavra-chave lá é novo. Sim, fiquei muito empolgado com Tomb Raider como jogador,
porque era algo que não tinha sido visto antes. Mas acho que agora que isso foi feito, podemos ver
mais claramente os prós e os contras desse tipo de jogo. Se você quer fazer Tomb Raider hoje, você
precisa encontrar uma maneira de ir além do que eles fizeram em 96. Você não pode simplesmente
fazer a mesma coisa repetidamente.
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 345

Então você encontrou alguma boa solução para a navegação espacial 3D no Prince of
Persia 3D?

Para mim, Prince of Persia 3D é um pouco complexo, em termos de número de armas e de


movimentos. Não é o tipo de jogo que eu projetaria para mim mesmo.
Mas eles estavam visando um público específico. Eu acho que o público principal, como eles
viram, eram pessoas que eram jogadores muito mais hardcore do que eu com o primeiro Prince
of Persia.

Como surgiu Prince of Persia: The Sands of Time e como você se envolveu com o
projeto?
Em 2001 a Ubisoft me abordou com a ideia de trazer Prince of Persia de volta e fazer um novo
jogo para consoles. Subi a Montreal para conhecer Yannis Mallat que era o produtor do projeto
e a pequena equipe que ele havia montado.

Eles já tinham começado o desenvolvimento?


Na verdade, foi meio
interessante a maneira
como eles começaram.
Eles me mostraram alguns
AVIs que haviam feito nas
semanas anteriores. Estes
eram AVIs muito rápidos.
Eles não se concentravam
na aparência do mundo
ou em qualquer tipo
gráfico de sinos e
assobios. Eles eram muito
grosseiros e tinham um
personagem animado
subindo uma parede, Príncipe da Pérsia: As Areias do Tempo
pulando em uma escada.
Apenas pequenas demos muito rápidas do tipo de jogabilidade que eles tinham em mente. A
grande inovação que já estava aparente estava aqui era um cara que podia correr nas paredes.
Então eles realmente pegaram a dinâmica do Prince of Persia 1, que era um side-scroller 2D, e
o trouxeram verticalmente para uma terceira dimensão. O que era algo que eu não tinha visto
em nenhum jogo de ação e aventura no estilo Tomb Raider . Foi apenas uma ideia brilhante
que abriu um mundo inteiro de possibilidades de como este jogo poderia capturar a emoção
dos antigos side-scrollers em um jogo 3D moderno em tempo real. Então, com base nisso,
fizemos um acordo para a Ubisoft seguir em frente e iniciar este projeto. Meu envolvimento
aumentou. Inicialmente pensei que seria apenas um consultor no projeto, mas entrei para
escrever a história e o roteiro, e assim que fiz isso acabei dirigindo os atores na gravação de
voz e finalmente me juntei ao projeto em tempo integral como designer de jogos. Eu estava
viajando entre Los Angeles e Montreal e minhas viagens foram ficando mais longas e frequentes
até que, na fase final do projeto, me mudei para Montreal com minha esposa e filhos. Isso foi
nos últimos quatro meses, no verão de 2003.
Machine Translated by Google

346 Capítulo 18: Entrevista: Jordan Mechner

Então você foi sugado de volta ao desenvolvimento de jogos contra sua vontade?
Essa é uma boa escolha de palavras. [risos] A outra palavra que eu usaria é seduzir. Foi um projeto
tão divertido e a equipe era tão talentosa e trabalhando tão duro e o potencial estava tão claro
desde o início. Eles queriam fazer algo realmente extraordinário. A Ubisoft Montreal ainda não
estava no mapa como está agora, seguindo Splinter Cell e Sands of Time. Na época, essa equipe
ainda não havia feito esse tipo de jogo de alto nível, mas certamente era capaz disso. Eles só
tinham que provar isso para o mundo. Era uma atmosfera muito refrescante; trabalhar com eles foi
um verdadeiro prazer.

É interessante que Sands of Time seja tão radicalmente diferente da encarnação 3D anterior
do jogo, Prince of Persia 3D.
Essa foi uma das primeiras coisas que falei com a Ubisoft quando eles propuseram fazer um novo
jogo de Prince of Persia . Nenhum de nós queria fazer outro Prince of Persia 3D. Então nós meio
que asseguramos um ao outro que não era isso que tínhamos em mente.
O problema com Prince of Persia 3D desde o momento em que foi proposto e até os estágios
iniciais, a pergunta óbvia a ser feita era: “Isso não é apenas Tomb Raider com calças largas e um
turbante?” E, no final das contas, acho que no final era realmente Tomb Raider com calças largas
e um turbante. Isso não foi suficiente. Então, para Sands of Time, a Ubisoft e eu basicamente
dissemos que nem vamos olhar para Prince of Persia 3D. Vamos dar uma olhada nos títulos
originais – por que eles eram divertidos, que aspectos disso nos fazem pensar que um remake
agora vale a pena fazer? Quais são os aspectos que queremos tentar capturar do original? De que
forma isso vai ser um jogo totalmente novo e diferente? Sands of Time, em muitos aspectos, foi
como fazer um título original. Fazia tanto tempo desde Prince 1 e 2, dez anos, que as expectativas
do que um videogame deveria ser são tão diferentes agora. Não havia possibilidade de literalmente
seguir as regras do jogo ou o personagem ou a história ou qualquer coisa assim. Precisávamos de
um novo personagem, nova história, nova jogabilidade, novas regras.
Prince of Persia , em última análise, representou um estilo de jogo, um tipo de sentimento que
você tem ao jogá-lo. Uma das principais inspirações para Prince 1, em 1986, quando comecei a
programá-lo no Apple II, foram os primeiros dez minutos de Raiders of the Lost Ark. A ideia de
fazer um jogo que tivesse esse tipo de execução, pulando, improvisando essas respostas
acrobáticas a um ambiente perigoso. E é claro que a história é um filme de aventura de fanfarrão
no espírito de Raiders, e

Príncipe da Pérsia: As Areias do Tempo


Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 347

antes disso os filmes de Errol Flynn e Douglas Fairbanks nos anos 30. Então tudo isso também foi
uma inspiração para Sands of Time. Mas quando você chega aos detalhes do que o personagem
do jogo pode fazer e como você o controla, não nos sentimos compelidos a seguir as regras que
foram criadas no side-scroller 2D de dez anos de idade. E eu acho que isso foi tudo para o bem.

Para dar um exemplo, poções: você encontra uma poção, você bebe, ela restaura sua força.
Isso foi bom no Prince 1, mas não funcionaria no novo jogo. Por que você teria elixires mágicos
úteis em uma masmorra, esperando que alguém os encontrasse e os bebesse? Por que eles já
não foram bêbados por um guarda sedento ou prisioneiro? Em um side-scroller 2D de 1989, você
pode assumir uma certa suspensão de descrença. Mas quando você tem um ambiente realista que
é ricamente renderizado com toda a beleza pictórica e efeitos de iluminação e assim por diante
que o PS2 ou Xbox são capazes, simplesmente não faz sentido. Em última análise, seguimos com
o conceito de que a própria água é a substância que o revive. A água é uma característica natural
dos palácios e jardins islâmicos e persas. Você tem fontes e cachoeiras. Essa foi uma maneira de
pegar um recurso do ambiente e torná-lo útil e importante para a jogabilidade. Então, em qualquer
lugar que você encontrar água no jogo, mesmo se estiver em uma piscina, se você beber, ela
restaura sua força. Esse é um exemplo. Se você jogou Prince 1 e Sands of Time, você pode ver
que, quando você vai direto ao assunto, quase todos os recursos do jogo são diferentes. É apenas
o sentimento geral, o espírito, que foi preservado.

A adaga é um elemento muito bom no jogo, porque é muito importante tanto para a
jogabilidade quanto para a história. Isso começou como uma mecânica de jogo ou um
dispositivo de história?
Rebobinar na verdade começou como um desejo de jogabilidade do diretor criativo Patrice Desilets.
Quando você morre e precisa reiniciar, você meio que quebra o feitiço do envolvimento do jogador
no jogo. Patrice pensou que rebobinar seria uma maneira agradável e orgânica de permitir que o
jogador continuasse jogando ininterruptamente, sem morrer com tanta frequência. Isso deu origem
a um desafio de engenharia, que era “Isso pode ser feito no PS2, em um sistema de console que
não possui disco rígido?” Os engenheiros trabalharam nisso por um tempo e acabaram provando
que era possível. Portanto, foi uma ideia de jogabilidade que deu origem a uma inovação de
engenharia que levou à questão da história: “Como justificamos o jogador com essa habilidade?” e
ao conceito do punhal e das Areias do Tempo.

As Areias do Tempo têm várias funções na história. Em primeiro lugar, eles são a substância
que permite voltar no tempo. Como jogador, você precisa encontrar maneiras de coletar a areia e,
ao voltar no tempo, usá-la. Segundo, a maneira como você coleta a areia é matando essas criaturas
de areia que são possuídas pela areia.
Eles são como monstros mortos-vivos no sentido de que você pode acertá-los quantas vezes
quiser com sua espada, mas a única maneira de se livrar deles para sempre é usar a adaga para
recuperar as areias que os possuem, então eles desintegrar. Então a areia lhe dá um incentivo e
uma razão para querer lutar contra esses inimigos. Todos os outros poderes do tempo — ser capaz
de congelar seus inimigos, mover-se em hipervelocidade, o vórtice de areia que, quando você entra
nele, dá a você um vislumbre do que está por vir — surgiram de tentar pegar a ideia central e tecê-
la através de tantos aspectos do jogo quanto possível, mantendo a história o mais limpa e simples
possível.
Machine Translated by Google

348 Capítulo 18: Entrevista: Jordan Mechner

A narrativa em Sands of Time é muito elegante, mas o enredo é bem simples. Você acha que
mais jogos deveriam se esforçar por enredos simplificados? Ou isso foi apenas algo que o
Príncipe da Pérsia pediu especificamente?
É bom que um jogo seja o mais simples possível. Mas dependendo do tipo de jogo, exige um tipo
diferente de simplicidade. A complexidade em Sands of Time deve vir das acrobacias, as porcas e
parafusos de como você passa por esta sala. Você se agarra ao pilar e depois pula na plataforma,
ou corre na parede e balança na barra? Esses são os tipos de problemas que devem absorver o
jogador. Portanto, a história não deve distraí-los com coisas que não têm nada a ver com a
jogabilidade. As cut-scenes em Sands of Time são relativamente breves e tendem a conter o
mesmo tipo de ação que está no jogo. No jogo você está fazendo ação acrobática e lutando contra
monstros. Então isso é principalmente o que você está fazendo nas cut-scenes também, com a
ocasional breve linha de diálogo gritada. As conversas que você tem com a personagem feminina,
Farah, estão bem no meio dessa ação, esse relacionamento que está sendo desenvolvido muito
rapidamente sob fogo e pressão. Não estamos cortando para outro lugar para ter grandes cenas
de diálogo entre personagens que nunca conhecemos antes. As duas maiores cut-scenes do jogo
são a que inicia a história, quando o príncipe realmente usa a adaga para abrir a ampulheta para
liberar as Areias do Tempo, abrindo efetivamente a caixa de Pandora, e depois uma no final que a
resolve. A premissa da história tem um elemento sombrio, em que o próprio herói causa a catástrofe
que torna necessário jogar o jogo. Então tudo isso se encaixa muito bem.

Embora você tenha mantido a história em Sands of Time bastante simples para uma aventura
de ação moderna, em termos do anterior Prince of Persias ou Karateka é um pouco mais
complexo. Por exemplo, o príncipe nunca falou antes, e as cutscenes eram muito mais
curtas e menos frequentes.
Prince 1 e Karateka eram como filmes mudos. Os filmes mudos não tinham diálogos; eles tinham
cartões de título. Hoje em dia, com o nível de som e gráficos a que estamos acostumados,
esperamos que os personagens falem, a menos que haja uma história que os impeça de falar,
como em um jogo como Ico onde eles não compartilham uma linguagem comum . Mas aqui você
tem um rei, um príncipe e uma princesa; você não vai escapar sem definir seus personagens e
suas personalidades até certo ponto. Então é mais uma questão de criar uma história e diálogo,
tanto nas cutscenes quanto na própria ação do jogo, que irá desenvolver as relações entre os
personagens e avançar a história enquanto entretém o jogador.

Também em contraste com os jogos anteriores do Prince of Persia , que como você
mencionou anteriormente se orgulhavam de ter controles bastante simples, este novo é
realmente bastante complexo, com todos os movimentos diferentes que o príncipe pode
fazer com suas múltiplas armas, e assim para frente. Isso foi feito para trazer a jogabilidade
às expectativas modernas?
Isso é de rigueur para o gênero. Não é um jogo portátil que você joga no celular, não é um jogo de
apontar e clicar como Last Express; este é um jogo de ação para console, e seu público será
composto por pessoas que gostam de pegar um controle e jogar.
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 349

No entanto, dentro disso,


acho que fizemos um
bom trabalho em manter
os controles simples e
consistentes. Nós não
tínhamos o tipo de
combinações memorizadas
semi-arbitrárias ondeacertar
tem que você
XX-Triângulo-Círculo.

Cada um dos quatro


botões de ação faz uma
coisa bastante simples e
compreensível, e a partir
disso é gerada muita
riqueza sobre o que o
Príncipe da Pérsia: As Areias do Tempo
jogador pode realmente fazer.
E isso vem de ter os
controles sensíveis ao contexto. Assim, por exemplo, pressionar X se você estiver agarrado a
um pilar fará com que você seja ejetado desse pilar, enquanto que se você pressionar X quando
estiver no chão, fará você rolar ou pular , dependendo da situação. Em Sands of Time, é o
mesmo princípio de Prince 1: nosso objetivo era levar o jogador ao ponto em que ele não
precisasse pensar em qual botão ele iria apertar, mas apenas desenvolver aquele instinto de
alcançar um determinado botão em certos tipos de situações e fazer com que a riqueza flua
disso.

Prince of Persia: The Sands of Time parece estar avançando e inovando a mistura de
narrativa/jogabilidade que é muito popular nos dias de hoje. Como você vê essa evolução
nos próximos anos?
Certamente a história está se tornando mais apreciada como um elemento dos jogos. Mas os
jogos não são sobre história. Um filme é sobre a história, um jogo é sobre a jogabilidade. Uma
boa história pode enriquecer um jogo, pode aumentar o prazer, da mesma forma que uma boa
partitura musical pode aumentar o prazer de um filme. Mas os designers de jogos às vezes
podem cair na armadilha de desenvolver uma história realmente complexa e pensar que de
alguma forma torna o jogo mais complexo ou mais interessante. A maioria dos jogos de ação/
aventura com histórias complexas sofre de uma alternância desajeitada entre jogabilidade e
cutscenes. Minha preferência pessoal para melhorar o aspecto da história dos jogos de ação é
trazer a história para a jogabilidade. Se uma interação pode acontecer enquanto você está
jogando e não enquanto você está sentado e assistindo a uma cena, então esse é o melhor
lugar para isso. Sands of Time faz isso até certo ponto na relação entre o príncipe e Farah.
Enquanto eles estão lutando contra monstros, eles gritam um para o outro, eles chamam os
avisos um para o outro e, ocasionalmente, se o príncipe for ferido após uma briga, Farah
expressará preocupação. Há muitas oportunidades naturais para o humor, enquanto o humor
em uma cena pode parecer meio forçado. Os momentos em que paramos o jogo para uma
cena entre o príncipe e Farah são realmente muito poucos e breves, e essas cenas se
concentram em reviravoltas significativas na trama que fluem da jogabilidade e depois voltam com apos
Machine Translated by Google

350 Capítulo 18: Entrevista: Jordan Mechner

Você espera um dia se livrar completamente das cutscenes?


Ah, absolutamente. Quanto
mais podemos criar uma
experiência perfeita onde
a história se desenrola
através da jogabilidade,
mais convincente esse
mundo se torna. Quando
você traz a história das cut-
scenes para a jogabilidade,
a jogabilidade torna-se
mais cinematográfica. Em
Sands of Time, a câmera
não
fica apenas colada atrás
da cabeça do príncipe,
seguindo-o.

Príncipe da Pérsia: As Areias do Tempo

Às vezes você entra em uma sala e a câmera faz uma abordagem cinematográfica, mostrando o
ambiente, enfatizando certas características, direcionando sua atenção para certas pistas. Durante
o jogo, a câmera cortará de um ângulo para outro para uma introdução dramática de inimigos, para
mostrar o príncipe desembainhando sua espada para lutar, para mostrar o que Farah está fazendo.
À medida que a câmera do jogo se torna mais inteligente e livre, isso permite que você faça coisas
no jogo que antes você só poderia fazer em cutscenes.

Você acha que algum dia conseguirá trabalhar em outro jogo que não seja um novo Prince
of Persia?
Por mais que tenha gostado de trabalhar em Sands of Time, não prevejo repetir esse nível de
envolvimento pessoal em um jogo de Prince of Persia . Esta foi uma situação especial porque era
realmente essencial tanto para a Ubisoft quanto para mim começar a série da maneira mais forte
possível. Foi um intervalo tão longo entre Prince 2 e Sands of Time – dez anos – que não parecia
fazer uma sequência, parecia um título original. Agora que Sands está pronto, há muitos grandes
talentos na Ubisoft Montreal e eles são muito bons em construir suas franquias e levá-las em novas
direções. Estou animado para ver o que a Ubisoft fará com Prince , mas para o meu próximo jogo,
estou mais interessado em explorar ideias originais e novas direções.

Isso não quer dizer que terminei com Prince of Persia porque meu projeto atual é escrever o
roteiro do filme Prince of Persia , que Jerry Bruckheimer está produzindo para a Disney. John
August e eu somos produtores executivos do projeto.

Você acha que seus designs de jogos mudam muito ao longo de um projeto?
Com Karateka e Prince of Persia eu tive o luxo de deixar o jogo evoluir com o tempo, já que era
apenas eu em uma sala com um computador, sem orçamento e sem resultados corporativos. Achei
que Prince of Persia levaria um ano e acabou levando três,
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 351

e tudo bem — era isso. Last Express foi diferente porque era um projeto tão grande. Com
a máquina que construímos com centenas de pessoas e computadores em rede, todo dia
era caro, então mudar o design no meio do caminho não era uma opção. Lá eu passei
muito mais tempo no começo tentando trabalhar o jogo em detalhes. Você só precisa
rezar para que o design original seja sólido e não tenha falhas graves que se revelarão
no futuro.

Mas seus jogos anteriores mudaram significativamente ao longo de seu


desenvolvimento?
Oh sim. Um exemplo:
Prince of Persia
originalmente não
deveria ter combate.
Uma das minhas ideias
brilhantes foi uma
resposta para o que eu
via como a violência
clichê dos jogos de
computador. Eu queria
que o jogador fosse um
inocente desarmado em
um mundo hostil cheio
de espinhos e armadilhas.
sangrenta Príncipe da Pérsia
Haveria muita violência
dirigida contra o jogador,
o que seria seu trabalho evitar, mas você nunca a distribuiria. Essa também foi uma
maneira de lidar com o fato de que eu não achava que havia memória de computador
suficiente para ter outro personagem correndo na tela ao mesmo tempo. Felizmente, eu
tinha amigos leais que continuavam me pressionando para adicionar combate. Quando
seus amigos dizem que seu jogo é chato, é melhor você ouvir.
Shadow Man, o personagem, foi um acidente fortuito porque pensei: “Não há como
adicionar outro personagem lá, não temos memória para isso”.
Só se o personagem se parecesse exatamente com o Príncipe, se ele usasse os mesmos
quadros de animação. Não me lembro quem sugeriu isso, mas ao mudar o personagem
um pouco e depois fazer um OR exclusivo com ele mesmo, você conseguiu uma forma
preta com um contorno branco cintilante. Então eu tentei isso, e quando vi Shadow Man
correndo pela tela eu disse: “Legal, há um novo personagem”. Então isso sugeria todo o
enredo do espelho e pular pelo espelho e ter um alter ego maligno que o seguiria e
tentaria frustrá-lo fechando um portão que você queria que fosse aberto ou jogando coisas
na sua cabeça. E então houve a resolução, onde você luta contra o Shadow Man no final,
mas você não pode matá-lo, já que ele é você mesmo, e se você o matar, você morre.
Então você tem que encontrar uma maneira de resolver isso. Chame de junguiano ou
como quiser, era uma forma de aproveitar o fato de não termos tanta memória.
Machine Translated by Google

352 Capítulo 18: Entrevista: Jordan Mechner

Então mais tarde você deve ter encontrado um pouco mais de memória para poder colocar os
outros personagens.

Muito do tempo gasto na programação de um jogo como Prince of Persia em um computador como o
Apple II é pegar o que você já fez e refazê-lo para torná-lo menor e mais rápido. Eventualmente, as
coisas que estavam lá ficaram mais eficientes e deixaram espaço suficiente para criar um conjunto
limitado de formas de personagens para os guardas. Se você notar, há muita coisa que os guardas
não podem fazer. Eles não podem correr e pular e perseguir você. Tudo o que eles podem fazer é lutar.

Seus jogos foram todos muito atraentes visualmente. Como você equilibrou a aparência visual
dos jogos com os requisitos da jogabilidade?
Acho que junto com o que já falamos sobre a simplicidade dos controles e a consistência da interface,
o visual é outro componente onde muitas vezes é tentador comprometer. Você pensa: “Bem,
poderíamos colocar uma barra de menu aqui, poderíamos colocar um número no canto superior direito
da tela representando quantas poções você bebeu”, ou algo assim. A solução mais fácil é sempre
fazer algo que, como efeito colateral, torne o jogo feio. Então eu tomei como uma das regras básicas
que o layout geral da tela tinha que ser agradável, tinha que ser forte e simples. Para que alguém que
não estivesse jogando, mas que entrasse na sala e visse outra pessoa jogando, ficasse impressionado
com uma composição agradável e pudesse parar para assistir por um minuto, pensando: “Isso parece
bom, parece que eu estou assistindo a um filme”. Isso realmente força você, como designer, a lutar
para encontrar a melhor solução para coisas como inventário.

Você não pode pegar a primeira solução que se apresenta, você tem que tentar resolvê-la dentro da
restrição que você mesmo estabeleceu.

Então, o que fez você decidir parar de trabalhar em jogos e seguir como roteirista em tempo
integral?

Eu sempre alternei jogos e projetos de filmes. Acho que há muito valor em recarregar suas baterias
criativas em um meio diferente. Karateka se inspirou muito em meus estudos de cinema em Yale,
especialmente filmes mudos. Prince of Persia não teria sido tão rico se eu não tivesse passado aqueles
dois anos depois de Karateka pensando e respirando filme, escrevendo um roteiro. O mesmo com
Last Express. Esse projeto veio logo após a realização de um pequeno documentário em Cuba
chamado Waiting for Dark. E Sands of Time veio depois da minha maior pausa dos jogos, vários anos
durante os quais escrevi roteiros e dirigi outro documentário, Chavez Ravine. Neste momento, o
desafio de escrever o filme do Príncipe da Pérsia e fazer um bom filme é minha principal prioridade.
Depois disso, não sei se meu próximo projeto imediato será um filme, um videogame ou qualquer outra
coisa. Para mim, um projeto atraente é aquele em que tenho que me convencer a desistir , em vez de
me convencer a fazê-lo.

A tecnologia está evoluindo muito rápido. Um videogame agora é tão diferente do que um
videogame foi há dez anos, quem pode dizer o que estaremos fazendo em dez anos?
Machine Translated by Google

Capítulo 18: Entrevista: Jordan Mechner 353

Então não é que você prefira trabalhar de forma mais linear. É mais uma busca alternativa
para você.
É uma forma diferente, mas muitos dos desafios são surpreendentemente semelhantes. Com um
jogo de computador, embora seja um meio não linear de contar uma história, você ainda tem o
fascinante mistério do que há em um mundo específico ou um conjunto específico de personagens
que torna esse jogo emocionante e emocionante. O que faz as pessoas dizerem: “Quero jogar
este jogo, quero ser o Mario”, e depois olhar para outro jogo que pode ser tecnicamente tão bom e
dizer: “Não tenho interesse em ser esse personagem neste mundo”. O mesmo com um filme.
Há uma química misteriosa entre um público e um contador de histórias que faz com que o público
decida, mesmo com base apenas no trailer, se eles querem ou não viver essa história em particular.

As duas formas de arte não são tão diferentes quando se trata de sentar e lutar com um
conjunto de elementos e tentar colocá-los em algum tipo de forma finita.
Os desafios de pegar um gênero estabelecido e abrir novos caminhos com ele de alguma forma,
de torná-lo surpreendente e cheio de suspense, de usar economicamente os elementos à sua
disposição, são muito semelhantes, seja um jogo ou um filme. A coisa mais difícil com Karateka e
Prince of Persia no Apple II foi voltar a ele dia após dia, olhar para algo que me levou uma semana
para programar e dizer: “Sabe de uma coisa? Consegui fazer funcionar, mas agora tenho que
jogar fora e encontrar algo diferente.” O mesmo com roteiro. Você tem que estar disposto a jogar
fora seu próprio trabalho repetidamente ao longo de um longo projeto para chegar a esse conjunto
finito de elementos que funciona perfeitamente.

Ouvi muitas pessoas dizerem que o cinema foi a forma de arte dominante do século 20, e
agora os jogos vão dominar o século 21. Como alguém que trabalhou tanto em jogos quanto
em filmes, gostaria de saber se você gostaria de comentar o que pensa sobre o futuro dos
dois meios.
Eu não sei. Eu meio que coço a cabeça com esse tipo de afirmação. O filme é uma forma de arte
mais dominante do que a música? O que isso realmente significa? Acho que o cinema e os
videogames são formas de arte muito diferentes. Estamos passando por um período interessante
agora, onde os videogames são mais como filmes, e filmes, ou pelo menos um certo tipo de filme
de sucesso de verão, são mais como videogames do que em qualquer momento no passado. Há
um grande interesse em Hollywood e na indústria de videogames em criar esse tipo de propriedade
de marketing cruzado para que você possa ter o filme de sucesso, o videogame de sucesso e o
passeio de parque temático de sucesso, todos lançados ao mesmo tempo. Mas isso não significa
que todo filme feito tem que ser um filme pipoca de verão. Também não significa que todo
videogame que é feito tem que ser esse tipo de coisa espetacular, orientada para a história e
amigável ao filme. O exemplo extremo de um jogo que não tem potencial cinematográfico é algo
como Tetris. Ele tem sucesso puramente como um jogo. A diferença entre o Tetris e o Blue de
Krzysztof Kieslowski é enorme. [risos] Portanto, há muito espaço para inovação em ambos os
campos, e isso não vai mudar tão cedo.
Machine Translated by Google

354 Capítulo 18: Entrevista: Jordan Mechner

Jordan Mechner Gameografia


Karateca, 1984
Príncipe da Pérsia, 1989
Príncipe da Pérsia 2, 1993
O Último Expresso, 1997
Prince of Persia 3D, 1999 (Consultor)
Príncipe da Pérsia: As Areias do Tempo, 2003

Esta entrevista apareceu originalmente em uma forma diferente na revista Inside Mac Games ,
www.imgmagazine.com. Usado com permissão.
Machine Translated by Google

Capítulo 19

O design
Documento

“Não foi até Ultima IV: Quest of the Avatar, que Ultimas realmente começou a ter
histórias convincentes e propositais, e foi o primeiro jogo da série a ter um
subtexto de comentários sociais. Não só eu queria construir mundos que fossem
grandes, épicos e significativos, eu também queria adicionar um subtexto para
cada jogo que pode não ser necessariamente óbvio nas ações que seus
personagens tomaram no jogo, mas um que finalmente daria a jogo um significado mais dura
Então em Ultima IV você tinha que provar que era uma boa pessoa, alguém que
poderia ser um exemplo para o povo da Britannia. O jogo agia como um 'Big
Brother', exigindo que os jogadores se comportassem de maneira 'heroica' para
ganhar o jogo. Achei esse design muito legal, já que os jogadores estavam
acostumados a fingir ser o herói, mas eles batiam em todos os habitantes da
cidade para se tornarem poderosos o suficiente para derrotar o personagem que
deveria ser o grande vilão, mesmo que ele geralmente não fez nada de ruim no
jogo.”
— Richard Garriot

355
Machine Translated by Google

356 Capítulo 19: O Documento de Design

one para me dizer qual era o formato oficial de um documento de design. Eu sabia
Por alguns anos,
que os enquanto
roteiros eu ainda era
de Hollywood um aspirante
tinham a designer
um formato muito profissional, eu queria
preciso e imaginei alguns
que
deveria haver algo comparativamente rigoroso para documentos de design. Que tipo de
informação é suposto incluir? Como deve ser colocado? Qual formato ele deve usar? Só
recentemente, depois de vários anos como profissional, descobri o grande segredo, e é
um que tenho o prazer de transmitir a você neste livro. Sim, aqui meus anos de
experiência na indústria de jogos transmitirão a você essas informações preciosas.
Não existe formato! Todo mundo que escreve um documento de design de jogo
apenas cria seu próprio formato! Você já ouviu falar de algo tão incrível? Sempre que
pergunto às pessoas que formato devo usar para um documento específico, elas
invariavelmente respondem: “Bem, você sabe, o formato padrão”. Ninguém sabe realmente
o que é esse formato “padrão” mítico, mas todos se referem a ele. No final, contanto que
comunique a natureza do jogo de forma eficaz e com detalhes suficientes, tudo o que você
entregar às pessoas que revisarão seu documento será considerado o formato “padrão”.
Há definitivamente um certo tipo e quantidade de informação que pertence a um documento
de projeto e que deve ser incluído para que seja útil, mas não há um formulário padronizado
que você deva usar para documentar esses dados.
Certamente, em algumas empresas, especialmente as grandes, pode haver um
formato acordado que todos os designers internos devem usar para seus documentos.
Seu documento de design acabará se destacando se divergir muito de outros documentos
de design do setor. Faz sentido para você colocar as mãos em todos os documentos
oficiais de design que puder, assim como você pode procurar exames práticos antes de
fazer os principais testes padronizados. Idealmente, você poderá obter alguns documentos
que foram usados para jogos que foram realmente publicados. Ou, pelo menos, você vai
querer revisar documentos escritos por designers que completaram e enviaram jogos.
Isso é difícil de fazer, já que as empresas de jogos são fanáticas por proteger sua
propriedade intelectual e não querem revelar o quão caótico seu desenvolvimento interno
pode ser, mas veja o que você pode encontrar. Os documentos de design Atomic Sam e
The Suffering incluídos no final deste livro são bons para começar.
Um documento de design tem tudo a ver com comunicar uma visão para um jogo, para
mapear o máximo de informações possível sobre como esse jogo funcionará, o que os jogadores
experimentarão e como os jogadores interagirão com o mundo do jogo. Organizar e estruturar
todas essas informações em seções apropriadas é um dos principais desafios para escrever um
bom documento de design. Novamente, muitas empresas podem preferir seus documentos em
um formato diferente do que descrevo aqui, e você certamente deve organizar seus dados na
forma desejada pelas pessoas para quem está escrevendo. Se a equipe de desenvolvimento
estiver familiarizada com a navegação em documentos de design escritos em um formato
específico, você deverá moldar seus dados para se adequarem a esse formato. Lembre-se, o
documento de design não é o resultado final de seus esforços; o jogo é. Como tal, o formato do
documento de design é relativamente sem importância. Enquanto o formato permitir a
comunicação efetiva das informações pertinentes, o documento de projeto será um sucesso.
Machine Translated by Google

Capítulo 19: O Documento de Design 357

O estilo de escrita
Antes de nos aprofundarmos em quais seções seu documento de design deve conter e quais áreas
ele deve cobrir, vale a pena discutir o estilo que você deve empregar ao escrever seu documento.
O documento de design destina-se a ser uma ferramenta de referência e, como tal, você deseja
facilitar a pesquisa e a consulta das pessoas o máximo possível. Grande parte disso será manter
um bom Índice, como discutiremos em breve. Ao escrever o texto do seu documento, você vai
querer dividi-lo com muitos títulos, títulos, subtítulos e assim por diante. Isso tornará mais fácil para
os leitores folhear o documento e ampliar as informações que estão procurando. Dividir suas
informações em listas, numeradas ou com marcadores, sempre que possível, permitirá que os
leitores percebam facilmente quais atributos diferentes uma determinada parte do jogo precisará
incluir. Alguns acham mais difícil escrever em um estilo de ponto de bala, pois exige que você
alterne constantemente recuos e títulos em negrito, em vez de apenas incluir todas as suas ideias
em um único parágrafo narrativo. Você pode achar mais fácil escrever seu documento primeiro e
depois voltar e formatá-lo corretamente. Dessa forma, você baixa todo o conteúdo e, quando volta
a editar o documento, pode formatá-lo corretamente simultaneamente. Outros designers realmente
preferem escrever em um estilo de ponto de bala desde o início para manter suas ideias em ordem.
Embora escrever em um estilo de marcadores possa envolver mais problemas para você, o
resultado final é um documento mais útil para os membros de sua equipe. Além disso, os gerentes
e executivos irão apreciá-lo, pois torna o documento muito mais fácil de ler.

Alguns designers usam ferramentas especiais de escrita para compor seus documentos.
Esses podem ser aplicativos mais adequados para escrever texto com muitos títulos, subtítulos,
listas com marcadores e assim por diante. Esses vários aplicativos podem permitir a autoformatação
e o recuo do texto, o que pode economizar muito tempo que você gastaria em um processador de
texto normal arrastando marcadores de recuo e paradas de tabulação. Dito isto, nunca usei tal
ferramenta, nem nunca trabalhei com alguém que o fez. O principal problema com essas
ferramentas é que, uma vez que seu documento esteja pronto, você precisará passá-lo
eletronicamente para que todos possam ler. As chances são pequenas de que todos terão essa
ferramenta de formatação exclusiva. Em vez disso, eles terão um processador de texto regular. O
documento será lido por todos, desde os outros membros de sua equipe de desenvolvimento até
as pessoas na gerência e os executivos de sua editora. Você não pode esperar que todas essas
pessoas tenham instalado qualquer ferramenta eclética de criação de documentos de design que
você escolheu. Se a ferramenta que você usa fornecer um exportador para um formato de arquivo
de processador de texto padrão, como Rich Text Format (.rtf), isso geralmente resolverá esse
problema, mas certifique-se de que o exportador realmente exporte um documento que corresponda
ao que você compôs. Ainda assim, sempre me contentei em usar processadores de texto padrão
para minhas próprias necessidades e não senti a necessidade de uma ferramenta mais capaz.
Embora haja uma grande tentação de fazer o que for necessário para “aumentar” seu
documento para torná-lo mais completo e completo, você deve evitar ao máximo a repetição de
informações. Isso é desafiador quando você fala sobre um elemento de jogabilidade que depende
diretamente de outro sistema que você discutiu dez páginas atrás.
Em vez de redescrever o sistema, encaminhe seu leitor para a definição original do sistema. Isso
é importante, pois, à medida que você atualiza o documento ao longo do desenvolvimento do
projeto, precisará alterar os dados em apenas um local
Machine Translated by Google

358 Capítulo 19: O Documento de Design

em vez de vários. Muitas vezes, se o mesmo mecanismo de jogo for descrito em detalhes em mais
de um lugar, quando chegar a hora de fazer uma alteração, apenas uma das descrições será
atualizada. Isso deixa a outra descrição desatualizada, resultando em um documento internamente
inconsistente. Nada é mais frustrante para o leitor do que encontrar informações contraditórias no
documento de design. Informações inconsistentes em uma especificação também podem levantar
uma bandeira vermelha para os produtores, que começarão a questionar sua competência para
desenvolver um jogo quando você não conseguir manter seus fatos corretos.
Muitas pessoas gostam de ler documentos de design em seus computadores, pois isso lhes
permite pesquisar palavras e navegar pelo documento com mais facilidade do que com uma
grande pilha de papel em sua mesa. Para essas pessoas, faz sentido incluir hiperlinks sempre que
apropriado. A maioria dos processadores de texto modernos facilita a criação de links de uma
parte do documento para outra, permitindo que o leitor navegue rapidamente para outra seção
relevante. Isso pode ser bastante útil, pois você tenta evitar repetir mais do seu design do que o
absolutamente necessário. Em vez de repetir, inclua um hiperlink para o local pertinente para que
o leitor possa pular para lá se precisar lembrar como funciona um sistema específico. Um sistema
de hipertexto Wiki pode ser ótimo para permitir que você vincule facilmente de uma parte de um
documento a outra ou, mais frequentemente, quebre seu documento grande em partes menores
que podem ser interligadas facilmente. O Wiki também permite que você vincule facilmente a outro
conteúdo que não pertença ao documento de design, como o documento de design técnico de um
determinado recurso ou a bíblia de arte que mostra a aparência de um determinado personagem.

Ao escrever seu documento, você quer escrever o melhor que puder, mas lembre-se de que
o documento de design deve ser um documento de referência para a criação de um jogo divertido,
não um documento divertido em si. Você quer que sua escrita comunique as informações
necessárias da maneira mais concisa e sucinta possível. Não gaste muito tempo se preocupando
em tornar o documento estimulante à leitura. Ninguém está procurando entusiasmo ao ler a maior
parte de um documento de design; eles estão procurando informações. Normalmente, tento fazer
da Introdução e da Visão Geral da História as seções mais legíveis do documento, onde alguém
possa realmente sentar e ler essas seções e se interessar ao fazê-lo. Mas para o resto do
documento, você terá sucesso se simplesmente conseguir incluir todas as informações necessárias.
Gastar muito tempo vestindo-o com palavrões extravagantes não fará nada para melhorar seu
jogo. Da mesma forma, embora você deva tentar escrever da maneira mais correta possível, não
gaste muito tempo se preocupando em editar o documento por erros gramaticais. Se os membros
de sua equipe — o público do seu documento — puderem lê-lo e obter as informações de que
precisam, ficarão felizes. Eles realmente não vão se importar se você usou um gerúndio
corretamente ou não. Dito isto, se o seu documento estiver tão seco ou mal escrito que ninguém
consiga ler, as pessoas terão menos probabilidade de recorrer a ele para obter as informações de
que precisam. Além disso, se você estiver escrevendo seu documento de design como um
documento de pitch realmente grande que você espera convencer as pessoas a financiar seu
projeto, talvez seja necessário ser um pouco mais refinado e orientado a vendas com sua escrita,
mantendo o documento útil e relevantes para a equipe de desenvolvimento.

À medida que você escreve seu documento, será muito tentador comparar elementos de seu
design com outros jogos, certamente aqueles que os leitores provavelmente já jogaram.
Embora no Capítulo 5 eu tenha desencorajado você a usar tais comparações em seu foco, no
documento de projeto as comparações podem ser realmente úteis, mas com uma ressalva: você deve
Machine Translated by Google

Capítulo 19: O Documento de Design 359

explicar completamente o seu sistema, mesmo que seja “igual à mecânica encontrada em Super Mario 64”.
Uma comparação com um jogo popular pode fornecer ao leitor um ponto de partida para a
compreensão de um sistema de jogo complexo que você está descrevendo. Se ela conseguir se
lembrar daquele jogo, ela instantaneamente terá uma ideia do que você está falando. Claro, para
evitar qualquer confusão, você ainda deve incluir uma descrição completa desse aspecto do seu
design. As comparações raramente são úteis o suficiente para substituir uma explicação completa
de como um sistema deve funcionar. Portanto, não confie em uma comparação como uma
muleta para poupar o trabalho de documentar alguma jogabilidade. No entanto, tendo começado
com a comparação, seus leitores terão uma chance melhor de entender exatamente o que você
está querendo dizer quando você passar a descrever e documentar completamente o sistema.

Embora as comparações
com jogos existentes, como
o muito citado Super Mario
64, possam ser apropriadas
no documento de design, o
designer deve ter o cuidado
de explicar completamente
o que ela quer dizer com a
comparação.

As Seções
Os documentos de design de jogos que escrevo normalmente se dividem nas seguintes seções
principais. Dentro de cada uma delas, haverá outras subdivisões, e nem todos os jogos podem
exigir que todas essas seções sejam usadas.
• Índice
• Introdução/Visão Geral
• Mecânica do Jogo

• Inteligência Artificial •
Elementos do Jogo

• Visão geral da
história • Progressão do
jogo • Menus do sistema
Machine Translated by Google

360 Capítulo 19: O Documento de Design

Índice
O leitor pode rir ao pensar que listo isso como uma parte importante do documento. É claro que um
documento com mais de cinquenta páginas e contendo várias seções terá um índice — por que
mencionar isso? O que chama a atenção, no entanto, é a natureza da seção do Índice. Como a
criação de um índice é uma tarefa demorada para um grande corpo de texto, como um documento
de design, é improvável que você tenha tempo para fazer um. Na ausência de um índice, o Índice
acaba sendo a ferramenta que as pessoas usam para navegar em seu documento. Quando um
membro da equipe de desenvolvimento precisa encontrar uma informação específica em seu
documento, ela tenderá a procurar primeiro no Índice para tentar descobrir onde essa informação
é mais provável. Portanto, quanto mais detalhado e inclusivo for o Índice, maior a probabilidade de
ela encontrar rapidamente as informações de que precisa.

Nenhum índice simples em estilo de romance servirá no documento de design - em outras


palavras, nenhuma listagem de apenas oito seções separadas com o leitor a navegar pelas páginas
dentro das seções por conta própria. O Índice deve incluir subseções, subsubseções e talvez até
sub-subsubseções. Já discutimos como você precisará usar títulos em negrito em todo o documento
para facilitar a navegação. Além disso, qualquer processador de texto comercial permitirá que você
transforme esses títulos em entradas em um índice. Essas entradas serão atualizadas
automaticamente para você à medida que esses títulos se movem no documento. A maioria dos
processadores de texto permite que alguém que esteja lendo o documento em seu computador
clique em uma entrada no índice e seja levado diretamente para a parte apropriada do documento.

Fazer um sumário detalhado para o seu documento de design é crucial para torná-lo útil.

Introdução/ Visão Geral ou Resumo Executivo É uma boa


ideia ter uma visão geral de uma página do design do seu jogo no início do
documento. Este resumo não é muito útil para desenvolvedores que trabalham
ativamente no projeto, que, como você deve se lembrar, são o público-alvo do documento.
No entanto, para novos membros da equipe que entram no projeto, um resumo será um bom ponto
de partida para entender o jogo. De fato, para quem lê o documento pela primeira vez, seja um
produtor, um executivo ou um profissional de marketing, ter uma ideia do “quadro geral” do jogo
por meio de um resumo de uma página pode ser bastante útil. Mesmo que quem ler a Introdução
não tenha tempo de ler o resto do documento, este resumo de uma página deve permitir que
entendam a essência da jogabilidade.

A Introdução deve limitar-se a uma única página. Mais do que isso e a Introdução deixa de
ser um resumo eficaz. Qualquer informação que não caiba em uma única página simplesmente
não faz parte do design central do jogo. Se você estiver ultrapassando o limite, descubra o que é
menos importante entre os dados que você tem no resumo e corte-o. Repita esse processo até
que o resumo caiba em uma única página. Pense no resumo como seu currículo: mais de uma
página e você pode perder seu leitor. Escreva um primeiro parágrafo emocionante que resuma
todo o jogo, com os parágrafos seguintes preenchendo a estrutura descrita na abertura.
Machine Translated by Google

Capítulo 19: O Documento de Design 361

Antes de escrever o documento de design, você deveria ter trabalhado na definição do foco
do seu jogo, como explorei no Capítulo 5, “Foco”. Esse foco é um excelente ponto de partida para
o seu resumo. Lembre-se de que o foco é resumir os pontos mais atraentes do seu jogo em um
único parágrafo. Comece com seu foco como o parágrafo de abertura de sua visão geral e, em
seguida, use os parágrafos a seguir para entrar em mais detalhes sobre cada parte atraente do
seu jogo.
Um dos parágrafos do corpo da sua visão geral deve resumir a história do jogo, se houver.
Neste parágrafo, concentre-se nas aventuras que os jogadores experimentarão durante o jogo,
sem se deter tanto na história de fundo ou na história do mundo do jogo.
Siga o jogo até a conclusão da história, mencionando os diferentes tipos de mundos que os
jogadores navegarão e os personagens que encontrarão. Tenha sempre em mente que este é
apenas um resumo, por isso não precisa se aprofundar muito. Basta tocar nos pontos altos da
sua história e passar para o próximo parágrafo.
Os outros parágrafos do corpo de sua Introdução devem discutir diferentes aspectos de sua
jogabilidade, usando as partes principais conforme delineado em seu foco. Quais características
da jogabilidade são mais centrais para o jogo e serão mais instrumentais para fazer com que os
jogadores queiram jogar seu trabalho por horas e horas? Claro, você não deve se concentrar em
recursos que todos os jogos possuem (“O Projeto X inclui a capacidade de salvar o jogo do
jogador a qualquer momento!”), mas sim em recursos que farão seu jogo se destacar, as partes
que definem seu jogo como uma experiência única e envolvente.
A conclusão deve então chegar e resumir toda a visão geral, com uma ênfase especial em
por que este jogo será tão atraente para o usuário, o que este jogo faz que nenhum outro jogo
tem. O leitor deve terminar a página com uma nota positiva, entusiasmado com o projeto. Pense
neste resumo de página como uma forma de reunir as tropas, animar a equipe e deixar as
pessoas empolgadas com o projeto sem forçá-las a ler todo o documento.

Mecânica do jogo
A seção Mecânica do Jogo é a parte mais importante do seu documento. Ao olhar para um
documento de design pela primeira vez, esta é a seção que eu olho primeiro para determinar o
que a jogabilidade realmente é para o jogo. De fato, a seção de Mecânica do Jogo também pode
ser chamada de seção de “jogabilidade”, pois descreve o que os jogadores podem fazer no jogo
e como o jogo é jogado. Ao descrever que tipo de ações os jogadores podem realizar, a seção
de Mecânica do Jogo define o próprio jogo.
Por causa disso, a seção de Mecânica do Jogo é uma das mais difíceis de escrever no documento
de design. Descrever a jogabilidade é uma proposta extremamente desafiadora e, como resultado,
muitos documentos de design de jogos ruins pulam esta seção completamente, preferindo se
concentrar na história, visuais ou sistemas de menus, todos os quais são tópicos mais fáceis de
escrever. O velho ditado diz: “Escrever sobre música é como dançar sobre arquitetura”.
Escrever sobre jogabilidade é igualmente desafiador e imperfeito, mas deve ser feito para que
seu documento de design seja útil para a equipe que criará seu jogo.
Exceto pelas referências necessárias ao personagem do jogador, você deve evitar detalhar
quaisquer objetos ou personagens específicos do mundo do jogo na seção Mecânica do Jogo.
Salve essas descrições para as seções de conteúdo relevantes posteriormente no documento.
Por exemplo, você vai querer descrever os possíveis efeitos das diferentes armas que os
jogadores podem pegar e como os jogadores irão controlar essas armas, mas você vai querer salvar o
Machine Translated by Google

362 Capítulo 19: O Documento de Design

lista real das diferentes armas encontradas no mundo do jogo até mais tarde no documento.
As armas específicas representam instâncias da funcionalidade que você descreve na seção
Mecânica do Jogo. Você pode pensar nisso da seguinte maneira: muitos jogos diferentes podem
ser feitos a partir do que você apresenta na seção Mecânica do Jogo. Por exemplo, os documentos
de design para os jogos Thief seguem uma descrição quase idêntica da Game Mechanics. São
apenas as armas, itens, níveis e inimigos que mudam de Thief para Thief II. O jogo principal
permanece o mesmo, e é o jogo principal que você está documentando na seção Mecânica do
Jogo.

As sequências costumam
usar uma seção de
mecânica de jogo em
seus documentos de
design que é idêntica ou
extremamente semelhante
ao jogo original. Retratado
aqui: Ladrão II.

Faz sentido introduzir as diferentes capacidades dos jogadores na mesma ordem em que
alguém que joga o jogo pela primeira vez as experimentaria. Por exemplo, comece simples. Quais
são os movimentos mais básicos que os jogadores podem fazer? Digamos que você esteja
trabalhando em um jogo onde os jogadores controlam um substituto do mundo do jogo (seja um
humano, uma nave espacial, um avião, um robô ou o que sua imaginação possa ter inventado).
Você provavelmente deve começar com como esse personagem se move para frente e para trás,
vira para a esquerda e para a direita e assim por diante. Depois de introduzir os movimentos mais
simples, introduza os mais complexos, como pular, agachar, rolar e assim por diante, conforme
apropriado. Se o seu jogo for mais um jogo RTS ou RPG no estilo Diablo, pode ser que os
jogadores movam seus substitutos usando apontar e clicar, e você desejará descrever precisamente
como isso funciona. Quão bom deve ser o pathfinding do personagem do jogador? O que o jogo
faz quando o substituto não consegue alcançar o local em que os jogadores clicaram? Você tem
botões separados para selecionar um personagem e depois movê-lo, ou é mais um sistema de um botão?
Ao descrever os movimentos do personagem, você deve listar os comandos físicos que os
usuários precisam executar para realizar esses movimentos. Por exemplo, “Para avançar, os
jogadores precisarão pressionar e segurar o botão Avançar. Se os jogadores apenas tocarem no
botão Avançar, o personagem do jogador se moverá apenas uma pequena quantidade.”
Provavelmente é uma boa ideia nomear as diferentes teclas ou botões que os jogadores têm como
seus controles em vez de se referir a eles especificamente; use “Botão Avançar” em vez de “Seta
para cima” ou “botão X azul”. Isso mantém sua descrição dos controles dos jogadores mais
Machine Translated by Google

Capítulo 19: O Documento de Design 363

independente de plataforma e permite que você altere quais teclas fazem o que mais tarde, sem
fazer você alterar muitas instâncias da “seta para cima” em seu documento de design. Um programador
que está implementando seu sistema de controle não se importa tanto com a atribuição literal de tecla
para um comando, mas precisa saber quantos comandos diferentes os usuários terão e quais ações
do mundo do jogo estão associadas a quais comandos.

Depois de descrever como os jogadores comandam seu substituto no mundo do jogo, o próximo
passo lógico é descrever o modelo de movimento do substituto. Segue um modelo de física realista
ou algo mais simplista? Ele atinge a velocidade máxima lentamente ou atinge a velocidade terminal
imediatamente? Ele se move mais lentamente em declives do que em superfícies planas? Sua
capacidade de resposta é rápida e precisa como Quake ou lenta e precisa como Tomb Raider? Como
ele reage quando bate em um objeto – desliza, vira ou simplesmente para? Esses são os tipos de
detalhes que você precisará considerar e descrever em profundidade.

Pode ser que mover peças de jogo ou substitutos de jogadores não seja a operação chave em
seu jogo. Pense no que os jogadores que iniciam um jogo fariam primeiro e descreva isso. Se você
estivesse descrevendo Railroad Tycoon, por exemplo, você gostaria de falar sobre como os jogadores
estabelecem os trilhos e as regras que regem isso. Se você estava escrevendo o documento de
design para Lemmings, você pode querer descrever como os jogadores podem transformar um
lemming normal em um lemming especial, como um bloqueador ou um escavador. Se você estivesse
descrevendo SimCity, você gostaria de explicar como os jogadores dividem uma área.

RPGs como Diablo II


geralmente começam o
jogo com o jogador criando
seu personagem. É claro
que isso precisará ser
totalmente descrito no
documento de design.

Se o seu jogo começa com jogadores que precisam criar seu personagem, como fariam em um
RPG como Diablo, você vai querer descrever esse processo, resumindo o significado de cada
estatística que os jogadores devem escolher. O que significa “força” ou “destreza”? Mais tarde, na
seção de Mecânica do Jogo, quando você estiver descrevendo uma ação que é afetada por uma
estatística específica, você poderá encaminhar o leitor de volta à definição original dessa estatística
específica.
Machine Translated by Google

364 Capítulo 19: O Documento de Design

Tendo começado com o básico, você pode prosseguir para as ações mais complexas dos
jogadores, tentando estruturar logicamente o documento para que cada ação subsequente se baseie
na anterior o máximo possível. Você quer que suas diferentes mecânicas de jogo fluam uma para a
outra para que o leitor possa ver a estrutura da construção do jogo.
E, é claro, você quer evitar fazer referência a mecanismos que ainda não definiu ou detalhou.

Certamente os tópicos que você abordará variam muito dependendo do tipo de jogo que você
está criando. Se o seu jogo envolve combate, você precisará analisar isso em detalhes, explicando
como os jogadores usam armas diferentes e quais são os possíveis efeitos dessas armas no mundo
do jogo. Se o substituto do jogador for capaz de pegar e manipular objetos, você vai querer explicar
completamente como eles são pegos, como eles são acessados, como funciona o gerenciamento de
inventário e assim por diante.
A seção de Mecânica do Jogo também é um lugar adequado para expor que tipo de quebra-
cabeças os jogadores podem encontrar no mundo do jogo. De fato, se o seu jogo for um jogo de
quebra-cabeça, isso ocupará uma grande parte da seção de mecânica. Você vai querer descrever
como os quebra-cabeças funcionam e como os jogadores são capazes de manipulá-los, e dar
orientação sobre como os quebra-cabeças serão criados, sem realmente listar quebra-cabeças
específicos. Assim como nas descrições de armas específicas, salve listas de quebra-cabeças para
as seções de conteúdo mais adiante no documento. Por exemplo, digamos que você esteja
descrevendo quebra-cabeças no Prince of Persia original. Você gostaria de explicar que os quebra-
cabeças podem envolver bater em placas de pressão, tetos demolidos escondidos, segmentos de
piso caindo, portões que podem ser levantados e abaixados pelas placas de pressão, espinhos que
saltam do chão e das paredes, poções especiais, certos tipos de efeitos mágicos e quaisquer outros
componentes que o mundo do jogo permita. Na verdade, você não listará nenhuma configuração
específica desses componentes que serão encontrados nos níveis. Salve isso para as seções
específicas de nível mais adiante no documento, ou para os designers de nível descobrirem por conta
própria. Aqui você deve listar a paleta de objetos e comportamentos a partir dos quais os quebra-cabeças podem s

Descrever a variedade de
componentes de quebra-
cabeça encontrados em um
jogo como Prince of Persia
é apropriado na seção de
Mecânica do Jogo.

Se o jogo em questão envolve jogadores mudando para modos diferentes para realizar tarefas
diferentes, cada um desses modos deve ser descrito em detalhes.
Por exemplo, no Drakan original: Ordem da Chama, os jogadores manobram o
Machine Translated by Google

Capítulo 19: O Documento de Design 365

substituto do jogador, Rynn, através do mundo usando as teclas para frente e para trás, enquanto
o mouse gira o personagem. No entanto, quando os jogadores pressionam a tecla de inventário,
o jogo entra no modo de inventário. A partir deste modo, os jogadores não controlam mais os
movimentos de Rynn, mas são apresentados a um cursor do mouse com o qual o inventário de
Rynn pode ser manipulado usando a funcionalidade padrão de arrastar e soltar. No documento
de design do Drakan, o designer gostaria de descrever claramente como os controles mudam de
um modo para o outro e como o mundo do jogo é manipulado em cada um.
Algumas seções do documento de design serão dependentes da tecnologia que o jogo
usará, seja 2D ou 3D, indoor ou outdoor, em tempo real ou pré-renderizado.
Embora se tente separar os aspectos tecnológicos do jogo no documento de design técnico e
mantê-los fora do documento de design o máximo possível, o que está sendo criado ainda é um
jogo de computador e, como tal, está inerentemente ligado à tecnologia. ele vai usar. Escrever
um documento de design sem ter qualquer noção de que tipo de tecnologia o jogo terá acesso é
geralmente impossível e, na melhor das hipóteses, impraticável. Você não precisa saber quantos
polígonos por segundo o mecanismo será capaz de manipular, ou se suportará NURBS ou não.
No entanto, você precisa ter algum conhecimento básico das ferramentas que estarão disponíveis
para o designer. Projetar um sistema de controle ou combate que funcione em um mundo 3D e
um que funcione em um mundo 2D são tarefas completamente distintas e diferentes. Você quer
jogar com os pontos fortes da tecnologia que o jogo usará enquanto se esquiva dos pontos
fracos.
Por exemplo, a seção Mecânica do Jogo precisará descrever o que os jogadores veem
enquanto estão jogando. Isso inclui como os jogadores veem o mundo, que tipo de visão da
câmera será usada e como os jogadores poderão afetar a posição da câmera. Para escrever
sobre isso, você precisa saber o que a câmera será capaz de fazer, o que depende inteiramente
da engine do jogo. Pode ser que o mecanismo suporte apenas uma visão em primeira pessoa,
apenas uma visão lateral ou qualquer outra limitação.
No entanto, como os jogadores veem o mundo é uma parte tão central do design do jogo que
você deve discutir isso na seção de Mecânica do Jogo.

A GUI é extremamente
importante para jogos
como Alpha Centauri e
precisará ser
detalhadamente descrita
no documento de design.
Machine Translated by Google

366 Capítulo 19: O Documento de Design

A interface gráfica do usuário (GUI) no jogo é de importância crítica para o seu jogo e,
portanto, deve ser descrita em detalhes na seção Mecânica do jogo. Você deve descrever
quaisquer dados sobrepostos na representação do mundo do jogo, como, para um jogo de ação, a
saúde dos jogadores ou outras estatísticas necessárias durante o jogo. A seção GUI também deve
abranger quaisquer outras GUIs que fazem parte da jogabilidade, como o que os jogadores veem
quando seu substituto se envolve em uma conversa ou ao gerenciar o inventário. Descrever a
interface gráfica é ainda mais importante para jogos como Alpha Centauri ou The Sims, que incluem
muitas GUIs diferentes e nos quais os jogadores usam constantemente a GUI para jogar o jogo. As
descrições dessas GUIs podem ser incluídas em uma parte da seção de Mecânica do Jogo ou
podem ser detalhadas durante a descrição do sistema para o qual são relevantes. Lembre-se de
que você deseja que seu documento de design seja o mais fácil de ler possível. Se o diretor de
arte estiver procurando as diferentes GUIs que precisam ser criadas e elas estiverem espalhadas
pela seção de Mecânica do Jogo, algumas podem ser perdidas. Por outro lado, um programador
pode preferir encontrar a GUI para um determinado sistema incluído na descrição desse sistema.

Você precisa decidir qual abordagem é do melhor interesse do seu documento e do projeto. Na
seção Game Mechanics, você deseja descrever apenas as GUIs que são usadas no jogo e,
portanto, são relevantes para a jogabilidade. Qualquer uma das GUIs de front-end usadas quando
os jogadores estão iniciando um novo jogo ou carregando um antigo não fazem parte da
jogabilidade. Como tal, as GUIs front-end devem ser separadas na seção System Menus, que
discutirei mais adiante neste capítulo.
É fácil supor muito ao escrever uma seção de Mecânica de Jogo, mas um bom designer
evitará assumir qualquer coisa. Por exemplo, um designer pode estar trabalhando em um jogo de
tiro em primeira pessoa nos moldes de Quake . Ela pode assumir que quando os jogadores
atropelam um objeto, seu personagem automaticamente o pega. A designer jogou tantos jogos de
tiro em primeira pessoa que é totalmente óbvio para ela que é assim que ela quer que funcione.
Mas se ela não anotar no documento, a equipe de programação pode presumir que funcionará de
outra maneira, copiando seu próprio jogo favorito. Não assuma que os mesmos componentes de
jogabilidade que são óbvios para você serão óbvios para quem estiver lendo seu documento.
Soletre tudo explicitamente para que não haja espaço para confusão.

Você quase pode pensar na seção de Mecânica do Jogo como uma primeira passagem
extremamente detalhada no manual. Você está descrevendo em detalhes intensos como os
jogadores realizarão cada ação diferente no mundo do jogo – quais comandos os jogadores usarão
e quais serão os resultados desses comandos. Se você está escrevendo seu documento de design
de jogo como um jornalista pode escrever uma notícia, na seção de Mecânica do Jogo você deve
se preocupar com o “o quê” e “como” – o que os jogadores fazem em seu jogo e como eles fazem
isso. Mais tarde no documento, você chegará ao “onde”, “quando” e “por que”.

Inteligência artificial
Se a seção de Mecânica do Jogo descreve como os jogadores podem interagir com o mundo do
jogo, então a seção de Inteligência Artificial documenta como o mundo reagirá às ações dos
jogadores. Como os oponentes que os jogadores enfrentam no mundo do jogo se comportarão? O
que eles farão em quais situações? Esta seção também pode descrever como o mundo do jogo se
comporta quando os jogadores não estão fazendo nada. Por exemplo, poderia discutir
comportamentos ambientais, como como as pessoas da cidade lidam com seus negócios diários.
Machine Translated by Google

Capítulo 19: O Documento de Design 367

Em jogos como Doom II, a


mecânica do jogador e o
comportamento dos
agentes de IA são discretos
o suficiente para serem
descritos em seções
separadas do documento de design.

Alguns autores de documentos de design podem preferir incluir a seção Inteligência Artificial na seção
Mecânica do Jogo, mas prefiro mantê-los separados, se possível.
A inclusão ou não da seção Inteligência Artificial na seção Mecânica do Jogo depende da natureza do seu
jogo. Para alguns jogos como Tetris, a IA é tão insignificante que não garante sua própria seção. Para um
jogo como o Lem mings, onde os controles do jogador e a IA estão intimamente interligados, faz todo o
sentido que o autor do documento de design os discuta na mesma seção. Mas para um jogo como Doom,
onde a manipulação dos jogadores de seu substituto no mundo do jogo, o Space Marine, é relativamente
diferente do comportamento dos inimigos que ele luta, faz sentido dividir as informações em duas seções.
Essa separação facilita a navegação do programador pelo documento, uma vez que o processo de trabalhar
no movimento dos jogadores e as criaturas que eles vão lutar são normalmente tarefas de codificação
separadas.

Na seção de IA, você fará o possível para descrever completamente como espera que o jogo se
comporte para os jogadores. Se você estiver trabalhando em um jogo no qual os jogadores movem seus
personagens em um mundo de jogo onde ele encontra outros personagens, você desejará descrever como
esses personagens reagem. Eles ignoram os jogadores até iniciarem uma conversa ou são atraídos pelos
jogadores? Eles podem encontrar caminhos ao redor da área de maneira aparentemente inteligente ou
estão andando em caminhos predefinidos? Alguns NPCs podem iniciar combates com jogadores; quando
e por que eles decidem fazer isso? É baseado em ver o personagem? Ouvindo isso? Eles são ativados por
gatilhos especificados pelo designer de níveis? Talvez todas as três ações iniciem o combate em diferentes
situações. Quão inteligentes são os personagens? Eles são capazes de se esconder nas esquinas,
atacando os jogadores de locais seguros? Eles fogem quando feridos? Há uma série de perguntas que
você deve responder na seção de IA, o suficiente para dar ao programador de IA uma ideia do que ele
precisa implementar. Quanto mais perguntas você responder, maior a probabilidade de os programadores
criarem comportamentos no jogo que correspondam às suas expectativas e visão.

Projetar uma IA para um jogo de estratégia pode ser um processo significativamente mais complicado.
Suponha que você esteja trabalhando em um jogo RTS como WarCraft ou em um título de estratégia
baseado em turnos como Civilization. Que tipo de estratégias o inimigo usará para dominar as unidades
dos jogadores? Como as unidades funcionarão juntas? Se aplicável, quando o computador
Machine Translated by Google

368 Capítulo 19: O Documento de Design

jogador decidir construir mais unidades, e quantas ele fará? A IA pegará e se defenderá contra
diferentes tipos de ataque realizados pelos jogadores, como manobras de flanco? A IA inimiga
deve ser uma partida real para os jogadores ou o equilíbrio é alcançado porque o computador
simplesmente possui equipamentos mais poderosos? Se necessário, você pode fornecer um
passo a passo de uma única experiência de jogo e como a IA inimiga se comportaria em
diferentes momentos desse jogo.

Descrever as
táticas colaborativas que
a IA usará é muito
importante no documento
de design de jogos de
estratégia como WarCraft
II.

Trabalhar na seção de Inteligência Artificial é um bom lugar para contar com a ajuda de
programadores em sua equipe. Descubra com que tipos de IA eles têm experiência em trabalhar
e explore como isso pode ser aplicável ao seu projeto. Descubra o que é difícil de realizar e o
que é fácil. Muitas vezes, é difícil para um designer (especialmente se ela não for programadora)
compreender que fazer um agente de IA fugir quando ferido é uma tarefa trivial, enquanto fazê-
lo encontrar o caminho até algumas escadas e pular uma borda pode ser extremamente difícil .
Em vez de ir para noções tortas do que você gostaria que a IA em seu jogo fosse capaz,
trabalhe apenas com objetivos reais e realizáveis.
Lembre-se de que um programador que lê um documento de design cheio de descrições de IA
implausíveis que não é de forma alguma fundamentada na realidade provavelmente ficará
irritado com o documento, e será um desafio para esse documento ser levado a sério no futuro.
Ter um programador trabalhando com você na documentação de IA do jogo ajudará a tornar
essa seção do seu documento muito mais forte, além de garantir que o programador de IA
realmente entenda o que se espera dos agentes no jogo.
Ao trabalhar em sua seção de Inteligência Artificial, tente seguir as mesmas regras que
você fez ao escrever a seção de Mecânica do Jogo. Não se refira a NPCs específicos no jogo,
mas sim a comportamentos gerais que diferentes agentes podem exibir. Você chegará aos
NPCs específicos e qual conjunto de comportamentos eles usarão na seção Elementos do
Jogo, mais adiante no documento. Novamente, tente não assumir nada. Coloque o máximo de
detalhes possível sobre como os agentes em seu jogo se comportarão, mesmo que pareça óbvio para você.
Machine Translated by Google

Capítulo 19: O Documento de Design 369

Elementos do jogo: personagens, itens e objetos/ mecanismos


Se você pensa nos designers de nível de sua equipe como pintores, então os elementos do jogo
são as cores que eles têm em sua paleta. Esses elementos são as diferentes partes do seu jogo
que serão reunidas nos níveis para criar uma experiência atraente para os jogadores. Os designers
poderão pegar esses elementos e, combinando-os de maneiras únicas e interessantes, criar uma
variedade de níveis que manterão os jogadores interessados por horas. É claro que nem todo jogo
tem níveis, mas quase todo jogo tem elementos de jogo. Se esses elementos são os vários tipos
de inimigos que os jogadores lutam em Robotron: 2084, os diferentes tipos de construções
especiais que podem ser criadas em SimCity ou os diferentes blocos em Tetris, eles precisam ser
listados e detalhados na seção Elementos do Jogo.
Agora que você gastou muitas páginas focando na mecânica de jogo mais geral e nos
recursos de inteligência artificial do seu jogo, é hora de passar para o conteúdo específico. Lembre-
se de que você manteve as seções de mecânica de jogo e IA gerais o suficiente para que se
pudesse fazer muitos jogos diferentes usando-as. Essas seções podem até permanecer
relativamente inalteradas para uma sequência, caso seu jogo tenha uma. Mas os inimigos, NPCs,
objetos, itens e mecanismos que os jogadores encontrarão no mundo do jogo provavelmente serão
exclusivos deste jogo. Esse conteúdo geralmente está intimamente ligado à história, que você
aprofundará mais tarde nas seções Visão geral da história e Progressão do jogo do seu documento.
Na verdade, é um sorteio se você quiser listar seus personagens, itens e objetos antes ou depois
das seções da história. Cabe a você determinar o que faz mais sentido para seu documento e jogo
específicos.
Costumo usar três classificações de elementos do jogo: personagens, itens e objetos/
mecanismos. Você pode querer criar uma seção separada em seu documento de design para cada
uma das classes, ou você pode fazer de cada classe uma subseção diferente em uma seção de
Elementos de Jogo com tudo incluído.
• Personagens: A classe de personagens inclui todos os inimigos que os jogadores enfrentarão,
todas as personalidades que eles podem encontrar e potencialmente conversar, e todos
os diferentes tipos de agentes de IA no jogo. Pense no agrupamento de personagens
como contendo todos os elementos ativos e não controlados pelo jogador no jogo. • Itens:
A classe de itens inclui qualquer entidade que os jogadores possam pegar e usar ou manipular
de alguma forma. Certamente, quaisquer armas que os jogadores possam usar serão
listadas aqui, assim como quaisquer itens que possam entrar no inventário dos jogadores,
como notas, chaves ou elixires de saúde.
• Objetos/Mecanismos: O terceiro grupo contém o que chamo de objetos ou mecanismos.
Esses elementos são entidades que aparecem no jogo, que não são dirigidas por IA e que os
jogadores não podem pegar, mas podem operar de alguma forma. Isso inclui portas,
interruptores, elementos de quebra-cabeça ou outros objetos que podem ser manipulados ao
longo do jogo.

Novamente, dependendo do tipo de jogo em que você está trabalhando, talvez não seja
necessário usar todas as três classificações. Um jogo de tiro como Half-Life teria todos os três: os
alienígenas que os jogadores lutam estariam entre os personagens, as armas que encontrariam
seriam listadas em itens e os diferentes mecanismos do mundo do jogo que os jogadores
encontrariam, como os raios laser redirecionáveis, cairiam sob a terceira classificação. Um jogo
RTS como StarCraft, no entanto, pode ter uma lista de unidades (que é essencialmente uma
Machine Translated by Google

370 Capítulo 19: O Documento de Design

combinação de personagens e itens) detalhando todas as diferentes unidades que os jogadores


ou seus adversários podem controlar, juntamente com uma lista de objetos/mecanismos que
detalha quaisquer objetos com os quais os jogadores interagem, como portas ou teletransportadores.
Se o RTS que está sendo projetado for aquele em que as unidades podem pegar objetos, no
entanto, você pode querer criar uma terceira classificação, afinal. Um RPG como Diablo pode
adicionar quarto e quinto agrupamentos para listar as habilidades e feitiços dos jogadores,
respectivamente, já que esses são elementos do jogo que realmente não se enquadram em
nenhuma das três classificações que discuti. Tente separar os elementos do mundo do jogo,
sejam eles quais forem, nos agrupamentos mais lógicos possíveis. Dependendo da natureza do
seu jogo, é razoável ter apenas uma classe ou até dez; jogos atraentes podem ser criados em ambos os casos

O documento de design
de Diablo II pode conter
seções separadas de
Elementos de Jogo para
descrever os feitiços e
habilidades do jogador.

Dentro de cada classe, tente listar os objetos na ordem mais lógica possível e agrupe
diferentes subclasses de objetos. Por exemplo, se você estiver trabalhando em um RPG, você
pode querer listar todas as suas poções em um local, todas as suas armas brancas em outra
seção e todas as suas armas de longo alcance em outra. Um RTS pode querer separar suas
unidades em ofensivas, defensivas e de construção, ou talvez estáticas e móveis.
Mais uma vez, dê uma olhada no tipo de jogo que você está fazendo e tente adivinhar o método
de representação que melhor se adapta aos dados que você está apresentando e que o torna
facilmente navegado e compreendido pelos leitores. A seção Elementos do Jogo deve fornecer
informações para as equipes de arte e programação. A equipe de arte precisará garantir que os
recursos de arte sejam criados para todos os elementos que você descreve. A equipe de
programação vai querer ler a seção de elementos do jogo em combinação com as seções de
mecânica do jogo e IA para obter uma compreensão completa do que o jogo deverá fazer.
Mantenha os artistas, outros designers e programadores em mente enquanto você trabalha na
catalogação dos personagens, itens, mecanismos do jogo e quaisquer outras classificações que
seu jogo possa exigir.
Ao listar e descrever esses elementos do jogo, você deve evitar atribuir estatísticas reais a
qualquer um deles. Este nível de detalhe sobre os itens ou inimigos simplesmente não é algo que
você possa prever antes de ter um jogo em funcionamento no qual você possa testar o
Machine Translated by Google

Capítulo 19: O Documento de Design 371

comportamento da IA ou armas e equilibrá-los adequadamente. Estatísticas que você cria na pré-produção,


onde você não tem chance real de balancear o jogo ou experimentá-las, são uma perda de seu tempo,
assim como de qualquer pessoa que possa ter que lê-las.
Em vez disso, tente escrever descrições dos elementos do jogo em questão e sua relação com os
outros elementos. Como eles se comparam em dificuldade entre si? Quais características um determinado
agente de IA possui? Este é mais ou menos provável de fugir em combate?
Quais recursos de IA esse elemento usará e para qual efeito pretendido? Como a entidade e seus vários
efeitos aparecem para o jogador? Quão grande é em comparação com outros objetos? Inclua informações
suficientes para um programador entender qual código será necessário para a entidade e descrição
suficiente para que um artista possa fazer um esboço conceitual. Você deseja fornecer o máximo de
detalhes úteis possível sem exagerar.
Os leitores, sejam artistas, programadores ou outros designers, saberão quando você está documentando
apenas por documentar, e nesse caso seu documento deixa de ser prático e útil. Não desperdice seu tempo
fazendo-os ler resmas de penugem para obter as informações de que precisam.

Visão geral da história

Embora não seja estritamente necessário para um documento de design, acho que ter uma breve visão
geral da história pode ser bastante útil em um documento de design, supondo que seu jogo tenha uma história.
Devidamente escrito, a visão geral fornece a todos os leitores do documento uma narrativa fácil de ler do
que acontece no jogo. Assim como a visão geral do documento de design, a Visão geral da história é uma
maneira rápida de todos na equipe entenderem o “quadro geral” da história. Para conseguir isso, você deve
manter a visão geral em um comprimento facilmente legível enquanto tenta incluir todos os principais pontos
da história. Algumas páginas devem ser suficientes, embora isso possa variar dependendo da complexidade
da história do jogo; um shooter pode exigir apenas uma página, enquanto um RPG pode demorar um pouco
mais.
Certamente você não precisa incluir todas as missões secundárias do jogo ou descrever todas as
conversas que os jogadores terão ou todos os personagens que os jogadores conhecerão. Tente tornar a
Visão geral da história o mais atraente e legível possível, para que as pessoas queiram lê-la. Embora a
seção de Mecânica do Jogo possa ser difícil de ler com suas listas de marcadores e atenção aos detalhes,
sua Visão Geral da História deve ser um prazer de ler. Na verdade, se não for um prazer, tente descobrir
por que não. É porque sua história não é tão convincente?
Você precisa refiná-lo e melhorá-lo para torná-lo mais interessante?

Progressão do Jogo
Dependendo da natureza do jogo, a seção de Progressão do Jogo pode ser a mais longa do
documento de design. É aqui que o designer do jogo divide o jogo nos eventos que os
jogadores experimentam e como eles mudam e progridem ao longo do tempo. Esta seção
fornecerá um guia tanto para a equipe de arte quanto para os designers de nível sobre quais
tipos de ambientes eles precisarão criar para o jogo. Os designers de níveis tomam esta
seção como uma diretriz para o que cada nível deve incluir e, em seguida, preenchem todos
os detalhes à medida que constroem cada nível, reunindo todos os componentes do jogo.

Para muitos tipos de jogos, incluindo RPGs, jogos RTS, jogos de tiro em primeira pessoa, ação/
aventuras e simuladores de voo baseados em missões, o Game Progression
Machine Translated by Google

372 Capítulo 19: O Documento de Design

a divisão será melhor feita por nível. Para cada nível, você deve descrever em detalhes quais
desafios os jogadores enfrentarão, qual história (se houver) acontece neles e a estética visual dos
níveis. Descubra e descreva quais serão os principais desafios em um determinado nível: lutar com
uma horda de inimigos no local A, conhecer e conversar com um personagem específico no local
B e resolver um quebra-cabeça de jogabilidade no local C. Você certamente não precisamos dividir
o nível até o ponto em que cada conflito seja listado em detalhes minuciosos. Assim como as
estatísticas do personagem, isso é algo que você só poderá fazer quando estiver realmente
trabalhando com o nível, quando puder experimentar o conflito de uma certa maneira e testá-lo.
Explique como a aparência do nível comunicará a história do jogo, se aplicável. Quais objetos e
itens devem estar em quais locais para que a história progrida adequadamente? Discuta também
quais elementos da “paleta” do jogo estarão disponíveis neste nível. Que tipos de inimigos os
jogadores esperam encontrar e que tipos de itens eles encontrarão ao longo do caminho?

Mais do que tudo, tente colocar em palavras como o nível deve afetar os jogadores, não
apenas em termos de quão difícil será o nível, mas que tipo de experiência de jogo os jogadores
terão. Como você quer que os jogadores se sintam quando estiverem jogando o nível, e como
esses sentimentos devem flutuar ao longo do nível? Os jogadores devem sentir conflitos e desafios
constantes, ou este nível é mais lento e centrado na exploração? A história está em um clímax
neste nível, resultando em maior tensão, ou o nível é mais lento, concentrando-se em preencher a
história de fundo do jogo? Ao escrever sua progressão no jogo, sempre tenha em mente como os
jogadores devem se sentir ao jogar um determinado nível e tente comunicar esse estado emocional
em sua escrita.
É claro que nem todo jogo tem níveis e, portanto, sua progressão no jogo pode não se dividir
tão facilmente em unidades independentes. Mas a maioria dos jogos tem estágios de algum tipo.
Tente determinar quais são os estágios do seu jogo e divida sua progressão no jogo nesses
estágios. Por exemplo, o jogo de arcade original Centipede tem uma série de ondas que os
jogadores jogam. Nesse jogo, uma vez que os jogadores matam todos os segmentos da centopéia,
eles progridem para a próxima onda. As ondas são cíclicas, com cada onda subsequente lançando
uma centopéia diferente, seja em termos de comprimento ou velocidade.

Jogos de estratégia
de forma livre, como
a série SimCity , não
exigirão uma seção de
Progressão do Jogo,
pois o que acontece
durante o jogo é
inteiramente determinado
pelas escolhas do jogador
e pela mecânica do jogo.
Retratado aqui: SimCity
2000.
Machine Translated by Google

Capítulo 19: O Documento de Design 373

Além disso, de cada onda para a próxima, as condições sob as quais certos inimigos aparecem mudam.
Por exemplo, a pulga nunca sai em ondas em que há uma centopéia de doze segmentos no campo de jogo.
Se alguém escrevesse uma progressão de jogo para Centipede (que não precisaria ser muito longa), seria
necessário dividi-la por ondas, delineando claramente como o jogo muda de onda para onda.

Alguns jogos podem não precisar de uma seção de Progressão de Jogo. Por exemplo, um documento
de design para um jogo de estratégia como Civilization ou um brinquedo de software como SimCity pode
descrever toda a jogabilidade relevante nas seções de Mecânica do Jogo, IA e Elementos do Jogo. Como
os níveis nesses jogos são gerados aleatoriamente de qualquer maneira, não há muita utilidade em ter uma
seção de Progressão do Jogo. No entanto, se o jogo em questão incluir certos cenários que começam em
níveis predefinidos em configurações específicas (como os jogos SimCity fazem), uma seção de Progressão
do Jogo seria o local ideal para descrever esses diferentes cenários e como eles desafiarão os jogador.

Menus do sistema
A seção Menus do Sistema é onde você deve detalhar o menu principal e quaisquer outras telas de opções
que os jogadores serão apresentadas em vários pontos fora do próprio jogo. Esses menus não afetam a
jogabilidade de maneira significativa e, como resultado, devem ser separados em sua própria seção
exclusiva. Você deve incluir descrições de como os jogadores salvarão o jogo e como o carregarão mais
tarde.
Descreva que tipo de interface os jogadores terão com esses menus: eles usarão apontar e clicar com base
no ponteiro do mouse ou usarão as teclas Enter e de seta, ou ambas? Tente ser tão completo quanto você
acha necessário para garantir que os menus do sistema sejam intuitivos o suficiente para permitir que os
jogadores se divirtam jogando o jogo em si. Os produtores adoram ver que você descreveu completamente
o fluxo desses menus, portanto, pode ser importante incluir uma seção de menus do sistema, embora, na
minha opinião, essa seção não seja realmente necessária para um documento de design completo. Pode
até fazer sentido tornar a seção Menus do Sistema em seu próprio documento separado, já que eles são
tão divorciados da jogabilidade propriamente dita.

A opinião de um homem
Nas páginas anteriores, apresentei o formato que gosto de usar para documentos de design de jogos.
Deixe-me repetir que não é de forma alguma o formato padrão da indústria. Muitos grandes documentos de
design usaram formatos totalmente diferentes dos meus, tanto em termos de estrutura quanto em termos
de quantos detalhes eles forneceram. Mas se você apresentar um documento estruturado como expliquei,
você não será ridicularizado ou considerado um tolo. Como afirmei anteriormente, o mais importante é que
você comunique sua visão do jogo para as pessoas que estão lendo seu documento. Você é livre para
apresentar suas informações de projeto da forma que fizer mais sentido para você, ao mesmo tempo em
que fornece o máximo de clareza e utilidade para seus dados.

Parte da razão pela qual o formato do documento de design pode variar tanto de projeto para projeto
é que os jogos ainda não são (nem acho que serão) uma forma de arte padronizada, como peças de teatro,
filmes ou sinfonias. Assim como o guia de estilo de um escritor para um livro de receitas e um romance
seria extremamente diferente, dificilmente se pode esperar que o documento de design de um jogo de tiro
em primeira pessoa como Halo seja da mesma forma que um para um jogo de tiro em primeira pessoa como Halo.
Machine Translated by Google

374 Capítulo 19: O Documento de Design

jogo de estratégia como Rise of Nations. O que os jogos realizam e as experiências que eles
proporcionam são radicalmente diferentes uns dos outros e, portanto, seus documentos de design
também devem ser diferentes. Claro, dentro dos jogos existem certos gêneros ou tipos de
jogabilidade, e o formato do documento de design para um determinado gênero, como um jogo de
tiro em primeira pessoa, pode ser padronizado. Mas mesmo assim, à medida que a forma do
atirador muda, à medida que implementa novos estilos e mecânicas de jogabilidade, a estrutura do
documento precisará se adaptar a essas mudanças para comunicá-las de maneira eficaz.

O documento de design
para um jogo de tiro em
primeira pessoa, como
Halo, seria extremamente
diferente de um usado para
um jogo de estratégia.

Documentos de projeto pouco auspiciosos


Como recomendei anteriormente, pode ser útil tentar obter alguns documentos profissionais de
design de jogos para dar uma ideia do que a indústria espera em tais especificações. No entanto,
você deve ter cuidado. É provável que o documento que você obtenha não seja bom. Muitos dos
documentos que foram usados para jogos publicados e que foram escritos por profissionais
experientes são realmente terríveis. A título de exemplo, e para melhor ensinar a você o que evitar,
explorarei alguns dos diferentes tipos de documentos de design horríveis e por que eles falham tão
miseravelmente no que deveriam realizar.

O Documento Especial Wafer-Thin ou Ellipsis


Esses pequenos volumes finos, certamente não mais do que trinta páginas, assustam e
surpreendem o experiente designer de jogos com sua total e completa falta de qualquer conteúdo
útil. Eles usam descrições sem sentido como “a jogabilidade será divertida” e “a capacidade de
resposta será nítida”. Nesses documentos, muitas comparações com outros jogos são feitas: “Isso
joga como Super Mario 64” ou “O jogo tem um esquema de controle semelhante ao Quake”.
Embora tais comparações possam ser um pouco úteis, como já discuti, o escritor do Wafer-Thin
Document quase sempre falha em explicar o esquema de controle de Super Mario 64 ou Quakein
em qualquer detalhe, muito menos o esquema a ser usado pelo jogo em questão. .
Machine Translated by Google

Capítulo 19: O Documento de Design 375

Muitas vezes, esses documentos gastam muito tempo, talvez metade de suas páginas,
falando sobre a história de fundo. Normalmente, essa história de fundo é muito fraca e mal
desenvolvida e está apenas tangencialmente relacionada ao jogo que está sendo desenvolvido. O
Wafer-Thin Document também gasta muito tempo falando sobre como os menus funcionarão. Não
os menus do jogo, mas os menus do sistema onde os usuários selecionam o tipo de jogo que
desejam jogar, definem suas opções e assim por diante. Muitas maquetes são feitas e as opções
são cuidadosamente listadas. O que exatamente as opções afetarão no jogo raramente é descrito
em detalhes, já que o jogo em si é mal definido. Descobrir o sistema de menus é algo melhor
perseguido quando o jogo está funcionando, quando o designer sabe que tipo de opções podem
ser importantes e quais opções de jogabilidade os jogadores terão; certamente está longe de ser
a parte mais difícil do design do jogo, nem o sistema mais importante a ser definido primeiro.
Documentos Wafer-Thin são frequentemente construídos por gerentes que gostam de pensar
que são designers de jogos. A razão pela qual eles também podem ser chamados de Documentos
Especiais de Reticências é que eles geralmente estão cheios de elipses. Por exemplo, os mundos
que os jogadores encontrarão no jogo serão descritos da seguinte maneira: “Jungle World é um
lugar muito quente e pegajoso onde os Macacos Garguflax balançam e atormentam o jogador. . .
” E isso será tudo o que o documento fornece como descrição para o mundo, terminando
em reticências, como se dissesse “insira o design do jogo aqui”. Não está claro se os escritores
desses documentos planejam voltar e preencher as reticências mais tarde ou que talvez eles não
considerem digno de seu valioso tempo para realmente explicar como o jogo funciona. Eles apenas
assumem que alguém em algum lugar irá preenchê-lo e fazê-los parecer bons.

Outro exemplo do conteúdo encontrado nos Documentos Especiais Ellipsis pode ser: “Os
jogadores terão a opção de muitas armas legais. Por exemplo, o Gargantuan Kaboom causa o
dobro do dano das outras armas dos jogadores e tem um efeito especial.
O Barboon Harpoon permitirá que os usuários matem inimigos à distância com um belo efeito de

câmera. Outras armas serão igualmente divertidas e legais. . . Aqui o escritor do Ellipsis Special
falha em descrever as armas que o jogo terá em qualquer nível útil de detalhes, e então, tendo
listado duas armas, decide deixar o resto para a imaginação do leitor. Claro, os leitores são muito
úteis a dizer que as outras armas serão “divertidas e legais”. Os escritores do Ellipsis Special
pensam erroneamente que essa é toda a descrição necessária para desenvolver um jogo.

A única vantagem do Documento Especial Wafer-Thin ou Ellipsis é que ele permite que quem
implemente o design praticamente assuma o projeto e o transforme em seu próprio. Digo que isso
é uma vantagem, já que geralmente as ideias que o gerente incluiu no Wafer-Thin Document são
mais do que ridículas e não tornam a jogabilidade viável.
Mas é preciso ser cauteloso. Os problemas surgem quando o gerente aparece seis meses depois
e reclama: “Mas não foi isso que eu escrevi!”

O tomo da história de fundo


Ao contrário dos escritores de Documentos Especiais Ellipsis, a designer que escreve o Back-Story
Tome passa muito tempo trabalhando em seu documento. Esses livros (é difícil chamá-los de
meros documentos) geralmente se estendem por centenas de páginas — documentos de 300,
400, até 500 páginas não estão fora de questão. Tem muita informação aí.
O primeiro erro que esses documentos cometem geralmente é um índice pobre e a falta de
um índice. Em um documento de projeto, informações bem ordenadas e uma boa tabela de
Machine Translated by Google

376 Capítulo 19: O Documento de Design

conteúdo pode substituir um índice, mas a ausência de ambos é um grande erro. Os problemas são
agravada quando o documento é tão longo quanto Guerra e Paz. A razão primária para
a existência de documentos de design de jogos é permitir que os membros da equipe procurem rapidamente
informações sobre uma seção do jogo em que estão trabalhando. Se um programador quiser
sabe como a IA de um inimigo específico vai funcionar, ela precisa encontrar essa informação de forma
rápida e fácil. Se ela não conseguir encontrá-lo, ela pode simplesmente inventar algo. Similarmente,
quando um artista quer ter uma ideia das texturas que serão necessárias para uma determinada área do
jogo, ela quer ser capaz de encontrar onde essa área é descrita o mais rápido possível.
Documentos de design não são lidos como romances. Ninguém começa no começo e vem
fora no final. Principalmente, os documentos de projeto são materiais de referência e, se os membros da
equipe não conseguirem recuperar facilmente os dados que estão procurando, eles podem desistir.
No entanto, uma vez que se começa a caçar através de um desses Tomos da História
surpreso ao descobrir que, de fato, não há informações sobre a jogabilidade lá. Isso é tudo
história de fundo. E com 500 páginas, é muito mais uma história de fundo do que a maioria dos jogos de computador
alguma vez usar. A história de todos os personagens do jogo, os amigos desses personagens,
e todos os pais e irmãos relevantes são descritos em detalhes minuciosos. Pode ser
coisas muito interessantes (embora geralmente seja uma bagunça desorganizada), mas no final o
o leitor fica com muito pouca idéia de como o jogo deve funcionar. Esses documentos são muitas vezes o
sinal do romancista frustrado ou de um escritor de um ambiente não interativo.
meio que não entende verdadeiramente o desenvolvimento de jogos. Muitos jogos fazem da contação de
histórias uma de suas preocupações centrais, e uma bíblia de histórias pode ser bastante útil para
criação. Nesse caso, faz sentido discutir até certo ponto a história do jogo no documento de design. Mas
antes de tudo, um documento de design deve conter
o design do jogo, que é muito diferente da história de um jogo. Lembre-se, seu mais
consideração importante ao escrever um documento de design deve ser “o que o jogador pode
Faz?" Embora esses tomos sejam muito significativos em termos de peso e provavelmente
impressionar os capitalistas de risco, o programador que tem que trabalhar com um documento como sua
única orientação vai acabar projetando o jogo ela mesma.

O Documento Exagerado
Alguns designers acham que podem descrever todos os aspectos de um jogo no documento de design.
Certamente é verdade que muitos documentos de projeto carecem dos detalhes necessários para serem
útil, como encontramos no Documento Especial Ellipsis discutido acima, mas ao mesmo
tempo, ir a um nível de detalhe excessivo pode ser uma perda de tempo do designer também
como a da pessoa que tem que vasculhar todo esse excesso de informação. Além disso, a documentação
excessiva pode levar à ilusão de que o designer criou um
documento completo e completo, quando na verdade ela entrou em detalhes demais sobre
certos assuntos enquanto pula outras áreas que precisam ser abordadas.
Por exemplo, suponha que o jogo que está sendo documentado tenha vários caracteres
que realizam certas ações no mundo do jogo. Digamos que o jogo tenha pessoas da cidade e
eles precisam andar, sentar e levantar, conversar uns com os outros e dormir. O documento deve descrever
esses comportamentos na seção AI. Um documento verdadeiramente completo
pode dividir isso em animações separadas: ficar de pé, sentar de pé,
sentado ocioso, em pé ocioso, andar, conversar com gestos de mão e assim por diante. Provavelmente isso é
não é necessário, já que bons animadores e artistas poderão destrinchar isso melhor
do que um designer pode. Mas alguns designers podem exagerar e realmente esboçar ou listar
Machine Translated by Google

Capítulo 19: O Documento de Design 377

os quadros de animação individuais. Isso é um absurdo. Não há como saber no estágio do documento de
design quantos quadros de animação serão necessários para uma determinada animação.
Esse tipo de decisão só pode ser tomada e ajustada durante a produção do jogo. Sem mencionar que listar
quadros de animação é um insulto ao animador que só se sentirá desmoralizado por esse grau de
microgerenciamento. Além disso, o documento de design deve se ater ao design da jogabilidade e não se
desviar do território da bíblia da arte ou de outra documentação de arte.

Outro exemplo pode ser o que chamo de “balanceamento de dados”. Estas são as estatísticas reais
das armas, itens e personagens encontrados no jogo. O documento de design provavelmente deve listar quais
atributos diferentes armas e personagens terão. Por exemplo, uma arma pode ter alcance, precisão, número
de tiros e cadência de tiro. Além disso, o documento de design pode querer descrever as qualidades de uma
determinada arma: “A espingarda de cano duplo tem um curto alcance e baixa precisão, mas causa uma
grande quantidade de dano em uma grande área”. No entanto, listar os valores dos atributos de uma arma
não é muito útil no documento de design. Dizer “Precisão da espingarda: 2” não serve para nada, pois o
número “2” não tem nenhum contexto e, portanto, nenhum significado. Esses valores são melhor determinados
quando o jogo está realmente funcionando, quando um designer pode balancear as armas conforme elas
serão usadas pelos jogadores e assim o designer pode experimentar diferentes configurações para obter os
efeitos desejados. Criar grandes tabelas cheias de dados antes que essas informações sejam realmente
testáveis é uma grande perda de tempo. Preencher um gráfico rapidamente pode ser uma maneira de
transmitir algumas ideias brutas que eram difíceis de descrever apenas com palavras, mas na melhor das
hipóteses essa tabela é uma primeira passagem que sem dúvida mudará muitas vezes antes do lançamento
do jogo.

Assim como as minúcias da animação e os dados de balanceamento precisos, o código-fonte também


não pertence ao documento. Os designers que começam a escrever algoritmos em seus documentos de
design estão indo longe demais. Não importa se o designer também é um programador.
Não deve haver código, nem mesmo pseudocódigo, no documento de design. A inclusão de código servirá
apenas para inchar o documento e distrair as informações omitidas que precisam ser cobertas. Algumas
explicações lógicas simples do tipo if-then-else podem ser úteis e são completamente apropriadas. Esses
exemplos podem ajudar a comunicar todas as contingências para a pessoa que está realmente escrevendo o
código e, se nada mais, forçar o designer que escreve o documento a considerar todos os casos e resultados
possíveis que o jogo precisará suportar. Mas quando os exemplos começam a parecer código C++ compilável,
você sabe que seu documento está exagerando.

Se houver alguma informação útil no Documento Overkill, ela está tão escondida no rio de dados inúteis
que os membros da equipe ficarão intimidados demais para procurá-la. A autora acha que pode planejar tudo
com antecedência e que é muito mais talentosa do que qualquer membro de sua equipe. Embora essa atenção
excessiva aos detalhes possa ser impressionante para aqueles que realmente não sabem o que estão fazendo,
um documento de design que vai longe demais só enfurece a equipe que tem que trabalhar com ele.

O documento Pie-in-the-Sky
Esses documentos de design geralmente têm intenções nobres com grandes ideias para uma jogabilidade
verdadeiramente magnífica. Infelizmente, os escritores deles normalmente não têm qualquer compreensão
técnica do que o computador é capaz ou do que uma equipe de vinte pessoas provavelmente realizará em um
ano e meio. Como resultado, esses documentos excessivamente ambiciosos apresentam ideias extravagantes sem
Machine Translated by Google

378 Capítulo 19: O Documento de Design

base na realidade ou viabilidade e acabam frustrando e enfurecendo as equipes designadas para


“fazê-los acontecer”.
Documentos Pie-in-the-Sky incluem ideias como “uma réplica totalmente modelada de
Manhattan será o principal mundo de jogo dos jogadores, completo com agentes de IA representando todos os
sete milhões de habitantes da cidade em tempo real.” Os autores de
Os documentos pie-in-the-Sky não querem ser incomodados com detalhes confusos, como o
realidade que nenhum sistema de computador existente pode simular sete milhões de humanos em qualquer tipo
de prazo razoável (sem falar em tempo real). Outro recurso sugerido pode ser “um
será incluído um analisador de linguagem natural que permite aos usuários digitar frases completas e complexas
em inglês, às quais os caracteres responderão com suas próprias dinamicamente
diálogo gerado.” O designer culpado não quer ouvir que as instituições de pesquisa
trabalham há décadas em processadores de linguagem natural que ainda têm problemas
com frases curtas e simples. Quando confrontado com um documento Pie-in-the-Sky que
você deve trabalhar, a primeira coisa a fazer é convocar uma reunião de verificação da realidade envolvendo
programadores e artistas, bem como a gerência que deseja que este documento seja implementado. Com todos
eles na mesma sala, alguns cálculos simples e rápidos em uma peça
de papel ou quadro branco muitas vezes revelará quão fundamentalmente impraticável é o jogo proposto, e se a
administração ainda se recusar a aceitar a realidade da situação,
pode ser hora de começar a procurar um novo emprego. Documentos do Pie-in-the-Sky são muitas vezes
combinados com Ellipsis Specials para criar documentos de design verdadeiramente miseráveis, onde o
designer culpado esboça um projeto completamente impraticável sem se preocupar em entrar em
muitos detalhes sobre isso.

O Documento Fossilizado
Qualquer um dos documentos de projeto falhos acima também pode ser um Documento Fossilizado. Com efeito, um
documento de projeto que não necessariamente sofre de qualquer um dos problemas acima e
era uma boa ferramenta de referência se tornará um Documento Fossilizado ao longo de um
projeto se o designer não for diligente em seus esforços para manter o documento atualizado. eu
não conheço nenhum projeto de jogo original cujo design não tenha mudado significativamente durante o
curso de seu desenvolvimento, e quando o design muda, mas o documento de design não
não, esse documento começa a ficar fossilizado.
Suponha que um programador da equipe de desenvolvimento procure algo no Documento Fossilizado e as
informações que ele encontra estejam desatualizadas. Ela pode começar a implementar
a antiga funcionalidade modificada há muito tempo. Em algum momento, um designer ou produtor que
ciente das mudanças que ocorreram no projeto, perceberá que o programador está criando um sistema que não
é mais adequado e castigará o
programador para fazê-lo. Isso cria frustração para ambas as partes, sem mencionar o desperdício de tempo do
programador. Além disso, sempre que o programador precisar saber
algo sobre o design no futuro, ela não confiará no documento de design e
em vez disso, irá caçar um designer ou produtor para descobrir como um determinado sistema deve funcionar.
Claro, isso anula o propósito do documento, já que o designer
deve parar tudo o que ela está trabalhando para explicar o sistema ao programador. Isto
novo sistema pode ser descrito corretamente no documento, mas o programador não está
vai ser queimado novamente usando o Documento Fossilizado. Quando o projetista não
atualizar o documento quando ocorrerem alterações de design, todo o documento se tornará menos útil. Ninguém
pode confiar nele e, como resultado, ninguém se incomodará em lê-lo.
Machine Translated by Google

Capítulo 19: O Documento de Design 379

Os sistemas de wiki podem ser ótimos para manter mais facilmente um documento ou uma
coleção de documentos atualizados. Com o Wiki, qualquer membro da equipe pode atualizar uma
seção do documento por meio de seu navegador da Web, e o controle e o histórico completos de
versão são suportados para evitar a perda acidental de dados. Assim, por exemplo, o programador
que está implementando um recurso específico pode modificar ligeiramente o texto do documento de
design para corresponder como o recurso realmente funcionou, adicionar mais informações ou
vincular ao documento de design técnico recém-criado para esse característica específica. Em um
projeto grande o suficiente, manter o documento de design completamente atualizado pode ser um
trabalho de tempo integral.

Uma questão de peso


Costuma-se brincar que os documentos de design não são lidos, eles são pesados. Isso não é
surpreendente, dado o peso de muitos documentos de projeto e a falta de desejo entre os membros
da equipe de lê-los. Surpreendentemente, esta afirmação é muitas vezes verdadeira. Certa vez, ouvi
uma ex-produtora de uma grande editora de jogos falar sobre sua experiência com documentos de
design e o processo de aprovação do projeto. Ela disse que os “decisores” trariam uma escala para
suas reuniões de “luz verde”. Quando se tratava de dois projetos semelhantes que eram relativamente
dignos de financiamento, eles pegavam o documento de design de cada projeto e o colocavam na
escala. Qualquer um que pesasse mais seria aceito, o outro rejeitado. Por mais que me doa dizer, se
você está no negócio de jogos comerciais e rastejando por dólares em editoras, você precisa tornar
seu documento robusto. Você precisa que seja impressionante para pegar e folhear. Muitos nunca
vão lê-lo em tudo. Outros lerão apenas a Visão Geral e o Índice no início. Mas todo mundo vai pegá-
lo e comentar sobre seu peso.

Claro, muitos desses documentos super-espessos contêm muitas informações de valor


insignificante para o desenvolvimento real do projeto. Eles podem ser exemplos estelares de um dos
tipos de documentos com falha que discuti anteriormente, como um Back-Story Tome ou um Overkill
Document. É seu desafio como designer de jogos tornar o documento o mais prático possível,
fornecendo apenas informações úteis no documento, ao mesmo tempo em que o torna robusto o
suficiente para impressionar os naipes. Pode-se querer incluir um grande número de fluxogramas ou
esboços conceituais ou optar por usar uma fonte maior, sem ser muito óbvio. De fato, um grande jogo
(embora simplista) pode ter um documento de design perfeito com apenas dez páginas. É de se
perguntar quantos jogos grandes e simples foram deixados de lado por editores que não se
impressionaram com a massa de seus documentos de design.

Felizmente, nos últimos anos, muitos editores e desenvolvedores parecem estar cientes da
dificuldade de manejar documentos de design maciços. O consultor de design Mark Cerny tem
pregado o conceito de iniciar o desenvolvimento com apenas um documento de design “macro”
simples de talvez dez páginas que pode ser expandido conforme necessário ao longo do
desenvolvimento. Como já discuti, outros estão começando a usar o Wiki como um meio de organizar
e interligar muitas informações de design contidas em muitos documentos menores. E cada vez
menos editoras estão financiando o desenvolvimento com base apenas em um documento de design
semelhante a uma lista telefônica, com protótipos e documentos gráficos de pitch de alto nível se
tornando cada vez mais importantes. Os dias de preencher o documento de design apenas por causa
dele parecem estar chegando ao fim.
Machine Translated by Google

380 Capítulo 19: O Documento de Design

Lendo-o
Depois que seu documento de design estiver escrito, um dos seus maiores desafios pode ser fazer com
que qualquer pessoa da equipe de desenvolvimento o leia. Muitas vezes, muitos programadores, artistas
ou mesmo outros designers não vão querer dedicar tempo a uma leitura cuidadosa do seu documento.
Outros podem ter sido queimados por documentos de design ruins no passado e chegarão à conclusão
de que o seu é de qualidade igualmente ruim. Manter seu documento atualizado, incluindo apenas
informações úteis, fornecer um índice detalhado e limitar-se a elementos de jogabilidade práticos e
realizáveis ajudará. Incluir vários resumos curtos e de alto nível antes de cada seção do documento
também pode ajudar os membros da equipe a obter informações de alto nível sobre aspectos do jogo
sobre os quais não precisam saber muito. Ao mesmo tempo, esses resumos podem dar aos leitores
uma visão geral antes de mergulhar nos detalhes do documento. Se os membros de sua equipe testarem
seu documento e acharem que é de qualidade superior, é mais provável que retornem a ele para
referência quando estiverem realmente implementando um determinado sistema ou trabalhando em
uma obra de arte específica. Como acontece com qualquer documento escrito, você precisa ganhar a
confiança de seus leitores se quiser mantê-los lendo.

Outro método importante de ler seu documento de design é torná-lo facilmente disponível para
qualquer pessoa que queira lê-lo. Mantenha-o no mesmo sistema de controle de origem que sua equipe
usa para gerenciamento de ativos. Você deseja que os membros de sua equipe possam obter a versão
mais recente do documento de design com a mesma facilidade com que obtêm a versão mais recente
do jogo. Como você estará constantemente revisando e atualizando seu documento para mantê-lo
atualizado com o projeto (e para evitar que ele se torne um Documento Fossilizado), o controle de
origem será uma ferramenta valiosa para acompanhar as revisões anteriores. Sem querer, mas um
sistema Wiki rodando na intranet de uma empresa também pode ser ótimo para distribuir o documento
para a equipe, com os desenvolvedores a qualquer momento podendo ler facilmente a versão mais
recente do documento através de seus navegadores da web. .
Ao fazer o check-in da versão mais recente do documento, envie um e-mail à sua equipe informando
que está disponível e explicando o que mudou. Dessa forma, as pessoas podem facilmente passar por
cima das mudanças. Se uma das alterações for relevante para o trabalho deles, eles poderão obter a
versão mais recente do documento da rede e ler as atualizações relevantes. Atualizar seu documento
não adianta nada se ninguém souber que você o atualizou ou se as pessoas ainda estiverem lendo
revisões antigas. Provavelmente é uma boa ideia usar um número de versão com seu documento, como
1.3 ou 2.7. Inclua este número de versão, juntamente com a data, em um cabeçalho em cada página.
Muitas vezes as pessoas imprimem um documento de design e não percebem quão antigo ou fossilizado
ele é. Se eles puderem comparar rapidamente uma data e um número de versão, eles saberão qual
versão do documento possuem e se precisam obter uma nova.

A documentação é apenas o começo


Alguns designers ou aspirantes a designers parecem pensar que um documento de design completo é,
por si só, suficiente para construir um jogo. De fato, algumas empresas fizeram designers escreverem
documentos de design, apenas para que esses designers passassem a escrever outros documentos de
design enquanto uma equipe separada realmente executa seu design. Na melhor das hipóteses, um
documento de design é um esboço, mais a sugestão de um jogo do que qualquer outra coisa, e
Machine Translated by Google

Capítulo 19: O Documento de Design 381

sem estar envolvido na criação de um jogo até que ele se torne mestre de ouro, não se pode
realmente considerar que projetou o jogo. Um designer que se orgulha de seu trabalho desejará
estar presente durante todo o projeto, pronto para alterar o design conforme necessário para
torná-lo o jogo mais atraente possível e atualizando o documento à medida que o design for
alterado e revisado (e tenha certeza de que será ser continuamente alterado e revisto). Um
designer de jogos comprometido vai querer estar lá para equilibrar as armas, a IA, os controles e
certamente os níveis. Ela vai querer garantir que o jogo siga o foco e que a visão inicial seja
realizada.
Se um designer escreve um documento de design e depois o passa a outros para realmente
construir, as pessoas que fazem a criação real mudarão o design para corresponder aos seus
próprios interesses e impulsos artísticos. O documento de design será um trampolim para seus
próprios atos de criação, não para os do designer original. O documento de design é parte
integrante da criação do jogo, talvez, mas um documento de design não é tudo o que é necessário.
Para reivindicar qualquer tipo de autoria significativa no projeto, um designer precisa estar
envolvido durante a duração. De certa forma, escrever o documento de design é a parte mais fácil
do design de jogos de computador. Na verdade, pegar o documento e criar uma experiência de
jogo atraente é muito, muito mais difícil.
Machine Translated by Google

Capítulo 20
Análise do jogo:
Os Sims
Projetado por Will Wright
Lançado em 2000

tify como um que eles gostariam de jogar. De fato, um grupo de foco realizado no
Baseadoinício
apenas em seu conceito,do
do desenvolvimento The Sims foi
projeto nãotão
é um jogo que muitas
desfavorável pessoas do
que o designer imaginariam
jogo, Will
Wright, teve problemas para colocar qualquer equipe no projeto. E por que seria divertido?
“Controle uma coleção de personagens em casa em um subúrbio simulado.” Para ouvir essa
descrição do jogo, parece perturbadoramente muito parecido com a vida real, mundana e
suburbana para ser divertido. De fato, tudo o que é simulado no jogo é a vida doméstica – nada de sair par

382
Machine Translated by Google

Capítulo 20: Análise do jogo: The Sims 383

concertos ou pistas de patinação para esses “sims”. Mas ouvir alguém falar sobre The Sims é
instantaneamente ficar intrigado. “Bem, eu estava tentando fazer meu sim flertar com essa mulher,
mas o marido dela ficou chateado e derrubou meu personagem!” Então, o que torna este jogo tão
brilhante e tão diabolicamente divertido?
Para resumir, os jogadores começam a jogar The Sims criando primeiro os personagens que
desejam controlar, atribuindo quantidades a diferentes atributos: Puro, Extrovertido, Ativo,
Brincalhão e Agradável. Os jogadores podem então colocar esses personagens em uma casa, pré-
construída ou construída por eles mesmos. A partir daí, é responsabilidade dos jogadores garantir
que a casa tenha todos os objetos que os sims precisarão para viver: uma cama, um banheiro,
uma cozinha, um telefone, objetos de entretenimento e assim por diante. Os indicadores de
necessidades ajudam a comunicar o que o sim precisa para alcançar a felicidade, incluindo listas
de Fome, Energia, Conforto, Diversão e Social. Os jogadores também devem fazer com que seus
sims encontrem uma maneira de trazer dinheiro para pagar por todas as coisas bacanas que os
jogadores compram, um objetivo alcançado olhando as listas de empregos no jornal. Além disso,
o jogo tem um componente social elaborado, onde outros Sims podem ser convidados, conversar,
entreter, flertar e fazer amizade. O jogo oferece uma variedade incrível de áreas para os jogadores
explorarem, é surpreendente que todas elas também sejam bastante profundas em sua funcionalidade.

Abdicando da autoria
The Sims é um bom exemplo do que Doug Church em uma palestra da Game Developers
Conference descreveu como “abdicação da autoria” em jogos de computador. Ou seja, em vez de
o designer do jogo apresentar a história do jogo com antecedência, como é o caso de 95% dos
jogos de aventura, RPG e ação feitos hoje, a autoria da história do jogo é abdicada aos jogadores.
Os jogadores podem então levar a história para a direção que quiserem, não importa quão lasciva,
monótona ou banal ela possa ser. De fato, a princípio, os jogadores podem nem pensar na
experiência como uma história, assim como podem não pensar em sua própria vida como uma
história. No entanto, ainda é uma história. No The Sims, a narrativa torna-se mais um esforço
colaborativo entre os jogadores, que dirigem a ação, e o

The Sims fornece uma


estrutura sobre a qual os
jogadores podem criar suas
próprias histórias.
Machine Translated by Google

384 Capítulo 20: Análise do jogo: The Sims

designer de jogos, que fornece a estrutura, as ferramentas e o espaço com os quais os jogadores
podem trabalhar. Como os jogadores estão intimamente envolvidos na criação da história, essa história
se torna deles e, como resultado, os jogadores se envolvem muito mais no jogo.
Em vez de ter suas cordas puxadas pelo designer de jogos, como aconteceu em tantos outros jogos,
são os jogadores que agora estão puxando as cordas. A sensação de empoderamento é realmente
tremenda.
É amplamente aceito que The Sims é um brinquedo de software e não tecnicamente um jogo,
embora seja frequentemente chamado de jogo e discutido no mesmo fôlego que outros títulos que
definitivamente são jogos. De fato, The Sims é um brinquedo porque não apresenta um objetivo definido
para os jogadores, embora possa insinuar ou implicar um. Não há “ganhar” ou “perder” The Sims além
do que os jogadores definem esses termos. Talvez os jogadores pensem que perderam quando seus
sims morrerem como resultado de um fogo de cozinha. Ou talvez os jogadores pensem que venceram
quando seu sim conseguir construir a maior e mais extravagante casa do bairro e atingir o ápice de sua
carreira escolhida. No entanto, essas condições de vitória/derrota são aquelas que os jogadores estão
sugerindo para o jogo, não aquelas que o jogo exige. Isso abdica da autoria para os jogadores mais do
que um jogo orientado a objetivos jamais poderia. Por exemplo, toda vez que alguém joga um jogo de
corrida como San Francisco Rush, o final do jogo é predeterminado; assim que os jogadores ou um de
seus oponentes cruzarem a linha de chegada na pista, o jogo termina. Assim, o fim da “história” que
Rush está contando é predeterminado. Os jogadores podem ser capazes de criar o quão bem seu
próprio carro se sai nessa corrida e que tipo de tática ele usa para tentar vencer, mas como a história
termina é uma quantidade conhecida e imutável. Mesmo um jogo como Civilization, que dá aos
jogadores uma grande liberdade sobre como eles vão jogar seu jogo, ainda restringe os jogadores
dizendo que o jogo acabou quando o ano 2000 chegar, quando uma civilização vencer a corrida
espacial, ou quando um atinge o domínio militar. Ao configurar as condições de vitória, o designer do
jogo está criando como o jogo terminará. Como o The Sims e outros brinquedos de software não ditam
como o jogo deve terminar, os jogadores devem decidir quando é o suficiente. O assunto familiar do
The Sims certamente ajuda os jogadores a definir seus próprios objetivos enquanto jogam; como eles
entendem o mundo do The Sims, os jogadores têm alguma ideia do que o sucesso nesse mundo pode
significar e, assim, podem criar seus próprios objetivos facilmente. Alguns jogadores, talvez
principalmente os aficionados de jogos hard-core, veem essa falta de ganhar e perder como um prejuízo
para o jogo, mas para muitos jogadores parece tornar a experiência de jogo ainda mais atraente.

Assunto Familiar
Claro, The Simsis não é o brinquedo de software original, nem é o primeiro de Will Wright. Seu primeiro
sucesso com o gênero de brinquedo de software veio com SimCity. Também simulava um sistema
sofisticado e permitia que os jogadores controlassem verdadeiramente o destino de sua cidade. Embora
SimCity seja um título excelente e divertido, The Sims é ainda mais atraente. Muito disso tem a ver com
o fato de que os jogadores de The Sims estão controlando humanos em vez de uma cidade. Em outras
palavras, segue a insistência de Chris Crawford de que os jogos devem se concentrar em “pessoas,
não coisas”. Em geral, a maioria dos jogadores achará as pessoas muito mais interessantes do que as
coisas, e os jogadores serão capazes de formar um vínculo emocional com uma pessoa simulada muito
mais fácil do que com uma cidade simulada. Depois de jogar The Sims por um tempo, os jogadores
ficarão tristes quando os avanços amorosos de seus sims forem rejeitados ou quando sua casa for incendiada.
Machine Translated by Google

Capítulo 20: Análise do jogo: The Sims 385

chão. Embora certamente não seja tão inteligente ou interessante quanto os humanos reais, as
pessoas simuladas no The Sims estão perto o suficiente de serem plausíveis para que os jogadores
queiram acreditar nas existências virtuais de seus sims e preencherão as deficiências da simulação
por si mesmos.
Além disso, quase todos os jogadores que jogam The Sims terão um conhecimento profundo
do assunto que está sendo simulado antes de começarem a jogar. Eles sentirão que são uma
espécie de especialista nesse assunto de “vida suburbana” e pensarão que serão capazes de jogar
melhor como resultado. Por exemplo, os jogadores sabem por instinto que devem montar um
banheiro com chuveiro, vaso sanitário e pia. Se o trabalho fosse simular a vida diária de uma forma
de vida alienígena em outro planeta, os jogadores teriam muito menos ideia de como proceder e
precisariam descobrir a cultura da forma de vida antes que pudessem esperar ter sucesso no jogo.
Como os jogadores já sabem muito sobre o assunto do The Sims, eles são muito mais atraídos
pelo jogo. A partir do momento em que iniciam o jogo, os jogadores se sentem bem porque estão
colocando seu conhecimento do mundo real em uso na criação dessas vidas simuladas. Quando
Will Wright criou o SimEarth, ele criou um jogo envolvendo sistemas sobre os quais os jogadores
sabiam muito pouco, e isso pode explicar por que tantas pessoas acharam o jogo bastante difícil.
Para SimCity, os jogadores tinham uma noção melhor do que estava acontecendo; embora não
fossem especialistas em planejamento e dinâmica urbana, os jogadores pelo menos achavam que
sabiam como uma cidade deveria ser organizada e estavam familiarizados com problemas como
trânsito, poluição e crime. Com The Sims, a maioria dos jogadores sabe infinitamente mais sobre o
assunto do que sobre planejamento urbano. Assim, o jogo é muito mais atraente para jogar. Sua
própria familiaridade atrai os jogadores como nada mais pode.

Claro, simular um assunto com o qual muitos dos jogadores estarão familiarizados também
pode ser um desafio; se o designer errar, os jogadores saberão instantaneamente. No simulador
de vida alienígena, quem pode dizer o que é preciso, já que o mundo e as criaturas são feitos para
começar? Isso concede ao designer mais licença artística de como o mundo é construído. No
entanto, em uma simulação de realidade como The Sims, se o designer fizer a escolha errada
sobre o que provocará um sim a fazer qual ação, os jogadores verão o erro.

Embora o assunto
do The Sims possa
parecer banal, o jogo
é tão fascinante porque
oferece aos jogadores
um mundo seguro
para experimentar.
Machine Translated by Google

386 Capítulo 20: Análise do jogo: The Sims

e sua suspensão de descrença será quebrada instantaneamente. Trabalhar com um assunto com o
qual os jogadores são íntimos pode servir para atraí-los, mas se não for feito corretamente, também
pode afastá-los.

Experimentação segura
Na primeira inspeção, pode-se pensar que o que The Sims simula é realmente tão interessante. De
fato, para os suburbanos que provavelmente possuem um computador para jogar o jogo e têm a renda
disponível para comprá-lo, quão diferente é o mundo do jogo do The Sims da vida real? Parece que
as qualidades escapistas e de realização de desejos que muitos jogos possuem estão totalmente
ausentes no The Sims. Além disso, The Sims nem apresenta “a vida com todos os pedaços sem graça
cortados”. Os sims dos jogadores ainda precisam se envolver nos aspectos mais mundanos da vida
moderna, como ir ao banheiro, trabalhar, pagar contas e tirar o lixo. Isso é divertido? Estranhamente,
é, já que essas tarefas mais tediosas dão um ar de “realismo” aos procedimentos, o que torna os
sucessos ou fracassos dos jogadores ainda mais significativos.

O que The Sims realmente oferece aos jogadores é um ambiente para experimentação segura.
Embora a prudência possa impedir os jogadores de seguir uma carreira como criminoso ou atleta
profissional na vida real, o jogo permitirá que os jogadores levem seus sims nessa direção com pouco
risco para os jogadores. Embora a construção de uma casa seja um grande empreendimento
envolvendo grande risco financeiro para o comprador, no The Sims, os jogadores podem construir
casas luxuosas, gastar dinheiro em bugigangas frívolas para seus sims, dar festas selvagens na
banheira de hidromassagem ou buscar relacionamentos homossexuais apenas para ter uma noção.
de como a vida poderia ser se eles a vivessem de forma diferente. Se esses estilos de vida
experimentais não funcionarem tão bem quanto os jogadores esperavam, a única perda é para seus
sims, um efeito consideravelmente menos sério do que a falência do mundo real ou o ostracismo
social. De fato, se os jogadores evitarem salvar seu jogo após um evento ou decisão catastrófica, a
perda será facilmente desfeita por completo. A vida que os jogadores controlam no The Sims pode ser
bem parecida com a deles, mas a capacidade de experimentar coisas novas sem medo de sérias
repercussões torna a experiência atraente e emocionante.

Profundidade e Foco
Uma grande parte do que faz o The Sims funcionar é a variedade de opções que os jogadores são
apresentados para o que eles podem fazer com seus Sims. Abdicar da autoria é muito bom, mas se o
designer não fornecer aos jogadores escolhas significativas o suficiente, os jogadores se verão apenas
capazes de criar uma gama muito estreita de histórias. De fato, é responsabilidade do designer na
criação de um brinquedo de software projetar esse brinquedo com uma gama de possibilidades
suficientemente ampla para que o apelo de brincar com ele não se esgote rapidamente.
E Wright fez isso habilmente com The Sims, deixando os jogadores com uma sensação constante de
que há muito mais para fazer e ver no mundo do jogo, que nunca se poderia esperar fazer tudo.

Os jogadores podem se concentrar em construir sua casa, começando com algumas das casas
pré-construídas ou construindo uma do zero. Um conjunto robusto de ferramentas de construção de
casas e paisagismo permite que os jogadores criem uma variedade muito grande de casas,
provavelmente nunca duas casas construídas do zero sendo iguais, mesmo com
Machine Translated by Google

Capítulo 20: Análise do jogo: The Sims 387

milhões de pessoas jogando o jogo. Uma vez que uma casa é construída ou comprada, os jogadores
podem se concentrar em preenchê-la com todos os tipos de bens interessantes, que têm uma variedade
de efeitos sobre os habitantes da casa. Claro, os jogadores também podem construir os habitantes,
escolhendo entre uma grande variedade de personalidades, tipos de corpo, idades, etnias e até
penteados, com a opção de fazer crianças ou adultos, bem como homens ou mulheres. Uma vez que
os Sims se mudam para a casa, os jogadores são capazes de determinar o que comem, o que estudam,
que carreira seguem, como se divertem e com quem socializam. Seja construção de casas, aquisição e
localização de propriedades, criação de personagens ou controle de vida, qualquer um desses
componentes inclui muito mais opções do que a maioria dos jogos oferece. Quando todos esses
sistemas diferentes são combinados, o leque de opções disponíveis para os jogadores aumenta
exponencialmente, criando um jogo com profundidade verdadeiramente sem precedentes.

Claro, o que os sims não podem fazer no jogo também é significativo. Os sims não podem sair
de suas casas, exceto para ir trabalhar, e quando o fazem, os jogadores não podem segui-los. Ser
capaz de ir a outros lugares seria legal, mas considere o quão mais complexo o jogo precisaria ser para
simular o resto do mundo. Uma enorme quantidade de trabalho adicional teria sido necessária e, se
essa limitação sensata não tivesse sido feita no início do desenvolvimento do título, talvez nunca tivesse
sido concluída. Ao se concentrar na vida doméstica, o jogo é capaz de “acertar” de uma forma que não
poderia ter sido o mundo do jogo de The Sims maior. Em suma, o que teria sido ganho em amplitude
teria sido perdido em profundidade. Se um designer gasta todo o seu tempo adicionando uma gama
irracional de possibilidades ao jogo, é provável que qualquer um dos recursos incluídos no jogo seja
muito mais superficial do que se o designer soubesse como concentrar seus esforços.

The Sims também captura habilmente o estilo de jogo “só mais uma coisa”. Esse tipo de
jogabilidade talvez seja melhor exemplificado por Civilization, onde os jogadores estão constantemente
ansiosos pela próxima tecnologia a ser descoberta, pela próxima unidade a ser construída ou pela
próxima descoberta de um novo território. Da mesma forma, no The Sims, os jogadores podem estar
trabalhando para que seus Sims conheçam novas pessoas, tentando avançar em suas carreiras,
esperando adicionar um acréscimo à casa e pensando em um dia criar um filho, tudo ao mesmo tempo.
Por causa dessas aspirações constantes, nunca há um bom lugar para parar de jogar; há constantemente
algo no horizonte para esperar.
Portanto, o jogo é fabulosamente viciante, com jogadores cativados dedicando horas e horas, dia após
dia e semana após semana de suas vidas ao jogo.

Interface
O melhor que a interface de um jogo pode esperar fazer é não arruinar a experiência dos jogadores. O
trabalho da interface é comunicar aos jogadores o estado do mundo e receber informações dos
jogadores sobre o que eles querem mudar nesse mundo de jogo. O ato de usar essa interface de
entrada/saída não pretende ser divertido por si só; é a interação dos jogadores com o mundo que deve
ser a experiência atraente. Mas como a interface determina como os jogadores interagem com o mundo,
se essa interface não estiver à altura da tarefa, na melhor das hipóteses os jogadores ficarão frustrados
e, na pior das hipóteses, os jogadores serão incapazes de realizar as ações que desejam.

A interface de usuário do The Sims é um belo exemplo de como fazer uma interface corretamente.
Ele fornece aos jogadores uma quantidade impressionante de informações sobre o mundo do jogo,
Machine Translated by Google

388 Capítulo 20: Análise do jogo: The Sims

enquanto permite que os jogadores façam de forma fácil e intuitiva as alterações que quiserem.
Ao contrário de muitos jogos de ação modernos, o tutorial fornece principalmente aos jogadores
informações sobre como jogar o jogo, não como manipular a interface. A interface é tão simples e
intuitiva que os jogadores a pegam com muito pouca dificuldade, sem dúvida o resultado de testes
rigorosos. De fato, Wright afirmou que dez versões da interface foram descartadas antes de
chegarem à versão com a qual foram enviadas. O fato de a ajuda estar incorporada em toda a
interface é fundamental, permitindo que os jogadores cliquem em qualquer item de texto para obter
uma explicação de como é importante e por que é relevante.

The Sims tem


uma interface
extremamente intuitiva
que inclui várias
maneiras para o jogador
realizar a mesma ação.

Uma grande parte do sucesso do esquema de entrada/ saída do The Sims é sua semelhança
com os sistemas que os jogadores provavelmente entenderão antes mesmo de começarem a
jogar. Por exemplo, os botões que determinam a velocidade de simulação do jogo parecem aqueles
encontrados em um toca-fitas, algo com o qual quase todos os jogadores estarão familiarizados.
Uma grande parte da interface é uma reminiscência do Microsoft Windows, com os players de
apontar e clicar espelhando esse sistema operacional sempre que apropriado. A manipulação de
itens também lembra o Windows; os jogadores podem usar arrastar e soltar para colocar objetos
ou simplesmente clicar e clicar. O “X” padrão do Windows aparece no canto superior direito das
caixas de diálogo para indicar que elas podem ser fechadas, e as combinações regulares de botões
OK/Cancelar são usadas sempre que apropriado. Embora a funcionalidade espelhe o Windows de
várias maneiras, é importante observar que a aparência da interface não se parece exatamente
com o Windows. Todos os botões são bem desenhados em um estilo de arte amigável que está
muito longe da esterilidade fria e utilitária do Windows. Se o jogo usasse a arte real da caixa de
diálogo que o Windows fornece, os jogadores seriam instantaneamente lembrados de trabalhar
com o seletor de arquivos ou alguma outra interface do Windows, não uma experiência que eles
provavelmente lembrarão com carinho, certamente não como uma atividade “divertida”. No entanto,
ao colocar um novo estilo visual no comportamento do Windows, a interface é intuitiva e familiar
aos jogadores sem realmente lembrá-los do gerenciamento de arquivos.
Outro exemplo disso é o menu “head” usado ao longo do jogo. Quando os jogadores querem
que um sim execute uma ação em um objeto específico, os jogadores simplesmente clicam em
Machine Translated by Google

Capítulo 20: Análise do jogo: The Sims 389

o objeto em questão. A partir daí, uma cabeça flutuante de seu sim atual aparece, com uma
variedade de ações diferentes que o sim pode realizar em torno dele em um círculo. Os jogadores
então simplesmente movem o mouse até a ação que desejam e clicam nela. Enquanto move o
ponteiro, a cabeça do sim realmente rastreia o cursor, observando-o onde quer que vá.
Este menu funciona de forma idêntica a um menu pop-up no Windows, mas com várias vantagens
distintas. A primeira é que ele não se parece com um menu pop-up e, portanto, os jogadores não
o associam a funcionalidades chatas do Windows. Segundo, o menu apenas lista as opções
disponíveis para o objeto atual naquele momento. Um menu pop-up normal listaria todos os objetos
possíveis, com as opções atualmente indisponíveis acinzentadas.
Terceiro, por ter a cabeça do sim no centro, o menu aproxima os jogadores da essência do que
eles estão fazendo: direcionar o sim para realizar uma determinada ação. A diretiva que eles estão
dando ao seu amado sim é mais íntima do que teria sido através de um menu pop-up mais estéril,
sem graça e padrão.

Comportamento controlado versus autônomo


No The Sims, os jogadores podem direcionar seus Sims para realizar certas ações: tirar o lixo, ligar
para um amigo, tomar banho e assim por diante. Os sims também funcionarão por conta própria
sem a direção dos jogadores. Os sims contêm lógica interna suficiente para atender às suas
necessidades mais urgentes, seja comer, ir ao banheiro, jogar um jogo de pinball ou ler o jornal de
hoje. À medida que os jogadores fazem acréscimos à casa ou compram mais bens, os sims vão
até novos objetos e aplaudem ou reclamam deles, sua reação depende do quanto eles gostam de
cada objeto em particular. Isso comunica aos jogadores se o sim geralmente ficará feliz com a
nova posse ou se o sim preferiria que ela não estivesse lá. Como a forma como a casa é montada
é um grande componente da felicidade total do sim, isso fornece informações cruciais aos jogadores
sobre a melhor forma de configurar a casa.

Os sims têm alguma


inteligência própria,
o que libera o jogador
de ter que se preocupar
com todos os detalhes
de suas vidas.
Machine Translated by Google

390 Capítulo 20: Análise do jogo: The Sims

O comportamento autônomo dos sims também permite que os jogadores montem a casa e
depois se sentem e observem como os sims vivem nela. Isso torna o jogo mais parecido com
SimCity, no qual os jogadores só podem configurar a estrutura da cidade - suas ruas, suas zonas,
seus principais edifícios - e depois ver como os habitantes da cidade vivem nela. Os jogadores de
The Sims podem construir uma casa agradável que eles acham que seria boa para morar, depois
sentar e assistir os Sims habitarem, usando seu comportamento padrão. Isso fornece mais um
caminho para uma jogabilidade interessante.
Os sims geralmente não têm a previsão dos jogadores e, como resultado, terão um
desempenho melhor, serão mais produtivos e ficarão mais felizes se os jogadores direcionarem
cada movimento com inteligência. Por exemplo, os sims não tentarão melhorar suas habilidades de
carreira por vontade própria, como melhorar sua criatividade aprendendo a pintar. Portanto, muitas
vezes é do interesse dos jogadores substituir as escolhas internas dos sims sobre qual ação realizar
a seguir, se eles quiserem que o sim atinja todo o seu potencial. Isso mantém o jogador se sentindo
inteligente, ou pelo menos mais esperto que o computador. No entanto, o comportamento autônomo
evita que os jogadores tenham que microgerenciar cada pequena decisão. Claro, ser capaz de
dizer aos sims exatamente o que fazer é uma parte fundamental do jogo, mas se os jogadores
estão controlando vários sims ao mesmo tempo, planejar algo para cada um deles fazer em um
determinado momento pode ser uma tarefa e tanto. . O comportamento interno dos sims ajuda a
descarregar essa responsabilidade dos jogadores quando eles não querem se preocupar com isso.

Uma lição a ser aprendida


The Sims é talvez o design de jogo comercial mais original lançado nos últimos anos. O jogo não
toma como ponto de partida nenhum outro jogo publicado, mas parece ter emergido inteiramente
do cérebro de Will Wright. Olhar para o jogo é maravilhar-se com a sua criatividade e inovação. Há
tanta coisa bem feita no The Sims que um livro inteiro poderia ser dedicado a uma análise de seu
design. O jogo é realmente como uma casa de bonecas computadorizada, proporcionando-nos a
capacidade de representar cenários humanos reais para melhor entendê-los. A descrição da casa
de bonecas encontrada no jogo é bastante esclarecedora:

Casa de bonecas Will Lloyd Wright


Esta maravilha do design da casa de bonecas é para todos, permitindo que
crianças e adultos encenem fantasias de controlar pequenas famílias. Esta
réplica incrível vem completa com móveis e itens decorativos incrivelmente
realistas. Não se surpreenda se horas e horas forem gastas desfrutando deste
pequeno mundo.

O que talvez seja mais interessante e atraente em The Sims é o potencial que ele tem para nos
ensinar sobre nossas próprias vidas. Qual é a relação que temos com os bens que possuímos?
Como o espaço em que vivemos afeta nossas vidas? Como o ciúme começa em um relacionamento?

Claro, ninguém argumentaria que The Sims é uma simulação completamente precisa das
motivações e atividades humanas, mas precisa ser completamente preciso para nos fazer pensar
sobre nossas vidas de maneiras novas e interessantes? Enquanto movemos nossos sims
Machine Translated by Google

Capítulo 20: Análise do jogo: The Sims 391

e observá-los interagir, podemos discordar de como a simulação modela seu comportamento.


Mas nesse desacordo, pensamos sobre o que realmente esperamos que eles façam,
com essa reflexão lançando uma nova luz sobre as relações que mantemos em nosso
vidas. Este, ao que parece, é o potencial dos jogos de computador - não nos permitir escapar
da vida real ou mesmo substituí-la, mas abrir novas áreas de pensamento, poder ver
o mundo através de um par de olhos diferente e voltar para nossas próprias vidas equipados com
essa informação inestimável.
Machine Translated by Google

Capítulo 21
Projetando Projeto
Ferramentas

“O homem é um animal que usa ferramentas... Sem ferramentas ele não é nada, com ferramentas ele é tudo.”

— Thomas Carlyle

Aquele jogo. Para criar conteúdo superior, a equipe de design precisará ser
Uma parteequipado
integralcom
do ferramentas
desenvolvimento dedeum
de criação bom
jogos jogo eé bem
robustas criarprojetadas.
conteúdoPortanto,
atraente para
pode-se
concluem que projetar um bom jogo é projetar boas ferramentas de criação de jogos.
Além dos ambientes de desenvolvimento que os programadores usam para compilar o código
do jogo e os pacotes gráficos que os artistas usam para fazer a arte do jogo, a ferramenta de
criação de jogos mais usada é o editor de níveis. O que distingue esta ferramenta das outras que
mencionei é que ela é tipicamente construída especificamente para um projeto ou, pelo menos,
para a engine que a equipe está usando para impulsionar o jogo. É responsabilidade da equipe de
desenvolvimento tornar este editor de níveis o mais poderoso possível para facilitar o trabalho

392
Machine Translated by Google

Capítulo 21: Projetando Ferramentas de Projeto 393

dos designers de nível e permitir que eles criem o melhor mundo de jogo possível.

Os níveis simples
encontrados nos primeiros
jogos, como Defender ,
não exigiam a criação de
um editor de níveis
sofisticado.

Claro, nem todo jogo tem níveis. Muitos dos jogos de arcade clássicos do início dos anos 1980,
como Missile Command ou Space Invaders , não têm níveis como pensamos agora. E os jogos que o
fizeram, como Defender ou Tempest, certamente não exigiram editores de nível sofisticados para criar
seus mundos de jogo. Os títulos esportivos possuem níveis bastante simples e, em sua maioria, exigem
a construção de estádios visualmente agradáveis para cercar a jogabilidade. Jogos como Civilization e
SimCity geram automaticamente a base de um nível usando aleatoriedade combinada com regras
internas específicas que garantirão que o mapa seja divertido de jogar. Eles então permitem que os
jogadores e a IA construam o resto por conta própria, durante o jogo. Discuto a natureza dos níveis nos
jogos com mais detalhes no Capítulo 23, “Design de níveis”. Muitos jogos modernos empregam níveis
sofisticados, níveis que têm um tremendo impacto na forma e na forma da jogabilidade que ocorre neles.
Esses jogos exigem que sua equipe de desenvolvimento crie um editor com o qual os designers de
níveis possam construir o mundo do jogo.

Surpreendentemente, muitas equipes de desenvolvimento não investem tempo de programação


suficiente para tornar suas ferramentas o mais fortes possível. Muitas vezes, as equipes não têm ideia
do que é padrão em outras ferramentas usadas no setor. Freqüentemente, não se investe tempo
suficiente no pré-planejamento e no projeto completo de como um editor de níveis funcionará. Como
resultado de todos esses fatores, muitas vezes leva muitos meses até que as ferramentas de design de
nível sejam razoáveis para serem usadas. Freqüentemente, um programador fica preso a implementar
ou melhorar o editor de níveis como trabalho “extra” em um cronograma já completo e é forçado a usar
o método confiável de implementação “código como o inferno” para fazê-lo a tempo. Muitas vezes, os
principais recursos de economia de tempo não são adicionados até a metade de um projeto, quando os
designers do jogo já estão irremediavelmente atrasados em seu próprio trabalho. O investimento inicial
nas ferramentas e seu suporte contínuo durante todo o projeto certamente dá muito trabalho, mas no
final é um tempo bem gasto.
Machine Translated by Google

394 Capítulo 21: Projetando Ferramentas de Projeto

Funcionalidade Desejada
Então, que tipo de funcionalidade um editor de níveis deve incluir? Muitos podem sugerir que uma parte
importante de qualquer editor de nível é ter teclas de atalho conectadas a todas as funcionalidades
importantes. Outros recomendariam muitas configurações configuráveis que permitem que diferentes
designers ativem e desativem os recursos de sua preferência, quando precisarem usá-los. Escusado
será dizer que um editor de níveis deve ser estável o suficiente para que um designer possa usá-lo por
várias horas sem travar. Mas essas sugestões são todas óbvias; eles são o mínimo que um editor deve
fazer para ser útil. Que tipos de recursos devem ser incluídos para permitir que um editor realmente
brilhe, para capacitar os designers a fazer o melhor trabalho possível?

Visualizando o nível
O objetivo mais importante para uma ferramenta de criação de mundo deve ser permitir que o designer
veja o mundo que está criando e, ao mesmo tempo, permitir que ele faça modificações nele. Isso
geralmente é chamado de What You See Is What You Get (WYSIWYG) no domínio de processadores
de texto e pacotes de editoração eletrônica, mas não é algo em que os editores de nível sejam
universalmente bons. Vou chamar essa visão WYSIWYG de “visão do jogador”, pois ela representa o
que os jogadores verão quando jogarem o jogo. O mundo que o designer está criando deve ser visto na
janela de visualização do jogador usando o mesmo mecanismo de renderização que o próprio jogo
empregará, seja 2D ou 3D, sprites ou modelos, controlado por software ou acelerado por hardware. Esta
parece ser a característica mais importante de qualquer editor de níveis. Como um designer pode
esperar criar um mundo bonito se ele deve primeiro ajustar as configurações do mundo no editor e
depois executar um aplicativo separado para ver como fica no jogo?

O designer deve ser facilmente capaz de mover a câmera na visão deste jogador para que ele
possa manobrá-la rapidamente para qualquer seção do mapa que ele precise ver para trabalhar no
nível. Este movimento é provavelmente melhor realizado com um modo simples de “vôo” no qual o
projetista pode controlar a posição da câmera usando movimentos simples e chaves giratórias. Neste
modo, a câmera deve se mover sem colidir com a geometria ou outros objetos do mundo do jogo.
Embora também se queira fornecer um modo para a visão do jogador onde o designer possa manobrar
pelo mundo do jogo como os jogadores farão no jogo final, o editor deve sempre permitir que o designer
se mova pelo nível sem restrições. Para editar um nível com precisão, o designer deve ser capaz de
olhar de perto o que quiser sem ter que se preocupar que uma árvore bloqueie seu caminho.

Cada diferença que existe entre o que o designer vê no editor e o que vai aparecer no jogo fará
com que os níveis pareçam muito piores. Suponha que apenas a visão apagada esteja disponível no
editor, enquanto o jogo em si tem uma iluminação sofisticada que cria sombras pronunciadas. Isso criará
frustração para o designer, pois ele não poderá dizer facilmente como o nível aparecerá no jogo. Claro,
o nível parece ótimo ao jogar, mas enquanto estiver no editor ele tem que adivinhar como será a
iluminação e como as mudanças que ele fizer afetarão o nível final. Uma limitação como essa seria
especialmente inaceitável se a jogabilidade dependesse mais de iluminação e sombras.

É claro que o mundo como aparecerá no jogo nem sempre é a melhor visão para editar esse
mundo. Por esta razão, os editores de nível geralmente precisam incluir uma “visualização de edição”
além da visualização do jogador. A visualização de edição geralmente é de cima para baixo, mas também pode
Machine Translated by Google

Capítulo 21: Projetando Ferramentas de Projeto 395

consistem em uma vista de estrutura de arame rotativa ou em várias vistas. A última opção é
particularmente útil para a edição de mundos de jogos em 3D. Por exemplo, a popular ferramenta
de edição do motor Quake Worldcraft, que foi usada para criar todos os níveis no Half-Life, fornece
ao designer a configuração popular de “tri-view”, com a qual o designer pode ver de cima para
baixo (ao longo do eixo Y), de um lado (ao longo do eixo X) e de outro lado (ao longo do eixo Z)
simultaneamente em três janelas separadas. As três vistas laterais aparecem em adição a uma
janela 3D de “visão do jogador”. Ter várias visualizações é de particular importância para editar
arquiteturas 3D complexas e sobrepostas, como as encontradas nos níveis do Quake . Em
contraste com a janela de visualização do jogador, que existe para mostrar ao designer exatamente
como será o nível no jogo, o objetivo da visualização de edição é permitir que o designer modifique
e molde facilmente o que vê na janela de visualização do jogador. É claro que o editor deve permitir
que as visualizações de edição e a visualização de um jogador apareçam na tela simultaneamente,
e as alterações feitas em uma janela devem ser refletidas instantaneamente em todas as
visualizações. Além disso, só porque eu me refiro a uma visualização como “visão do jogador” e
outra como “visão de edição” não significa que os usuários não devam poder editar todo o conteúdo
do jogo em todas as visualizações.

A visualização fornecida no
editor de nível Zoner para
Odyssey era perfeitamente
adequada para editar um
mundo 2D.

Em alguns casos, pode não haver necessidade de visualizações separadas de editor e player.
Por exemplo, em um mundo 2D como o encontrado no meu primeiro jogo, Odyssey: The Legend
of Nemesis, a visão de mundo do jogador pode ser perfeitamente adequada para editar os níveis.
Enquanto eu trabalhava nos muitos níveis desse jogo, nem uma vez desejei outra visão do mundo
do jogo. Da mesma forma, em StarCraft, a representação do mundo como aparece no jogo é
suficientemente clara para permitir que o designer faça modificações diretamente nele. Por esta
razão, o Editor de Campanha de StarCraft fornece apenas uma janela de visualização do jogador
para o designer editar. No entanto, para o editor de StarCraft , pode ter sido benéfico fornecer uma
visualização de edição separada. Por causa da visão isométrica que o jogo usa, uma visão que às
vezes pode ser confusa de se olhar, uma visão estritamente de cima para baixo na qual o designer
poderia editar seu nível poderia ter sido bastante útil na colocação e manipulação de unidades e
outros jogos elementos. O Editor de Campanha StarCraft inclui um
Machine Translated by Google

396 Capítulo 21: Projetando Ferramentas de Projeto

“mini-mapa” de cima para baixo do nível que está sendo criado, mas o designer não pode realmente
alterar o nível usando essa visualização, nem o mini-mapa é grande o suficiente para permitir uma
edição fácil.

A grande imagem
Argumentei que é importante para o editor de níveis de um jogo permitir que o designer veja o nível
exatamente como ele o verá no jogo final, mas a janela de visualização do jogador nem sempre precisa
representar exatamente o que os jogadores verão. Pode ser bastante útil se o editor de níveis também
puder mostrar ao designer várias informações extras sobre o nível que ajudarão na criação desse nível.
Por exemplo, suponha que o jogo que está sendo desenvolvido envolva vários monstros manobrando
o nível em caminhos predeterminados. Ser capaz de ver exatamente onde esses caminhos vão é a
chave para entender como o nível funciona e para garantir que os caminhos estejam configurados
corretamente.
Em muitos editores de nível, esse tipo de informação de funcionalidade de nível é comunicada na
visualização de edição, mas não na visualização do jogador, mas faz sentido exibir esses dados em
ambos os lugares. Certamente a janela de visualização do jogador nem sempre deve ser preenchida
com esse tipo de informação de funcionalidade de nível, mas a capacidade de ativar e desativar a
renderização de diferentes dados pode ser bastante útil na configuração dos comportamentos do nível.
Isto é especialmente verdadeiro para jogos 3D. Voltando ao exemplo do caminho, por que o designer
deveria extrapolar em sua cabeça da vista 2D de cima para baixo ou de edição lateral exatamente
onde um caminho terminará na vista 3D? Em vez disso, o editor deve apenas desenhá-lo para ele, para
que não haja suposições.
Ao trabalhar no Centipede 3D, um programador estava adicionando um código que impediria os
jogadores de subir ladeiras muito íngremes. Para depurar esse novo código de restrição de inclinação,
ele adicionou uma funcionalidade ao editor de níveis que permitia ativar e desativar as linhas que
separavam os diferentes triângulos que compunham a paisagem. Essas linhas mudariam de cor
dependendo se uma determinada borda pudesse ou não ser cruzada pelos jogadores. Os próprios
triângulos eram marcados com um X vermelho se fossem muito íngremes para os jogadores
descansarem. O programador adicionou essa funcionalidade principalmente para ajudar na depuração
do código de restrição de inclinação, nunca percebendo o benefício que seria para os designers de
nível. Agora os designers podiam ver exatamente onde os jogadores podiam e não podiam viajar no
nível. Um efeito colateral ainda melhor foi a renderização dos limites triangulares, que criavam uma
espécie de visão em arame da paisagem, funcionalidade que não estava disponível anteriormente no
editor. Isso simplificou enormemente a edição da geometria, pois agora os designers podiam ver
exatamente quais triângulos criavam quais inclinações e depois modificar o nível de acordo. A adição
da visualização de estrutura de arame e os marcadores de restrição de inclinação levaram diretamente
a uma geometria melhor e mais refinada no jogo final. E a beleza dessa funcionalidade é que ela pode
ser ativada e desativada no editor, então se o designer quiser ver como o nível ficou, ele pode desativá-
lo, e se ele quiser ver como ele funciona, ele pode ativá-lo .

Assim como acontece com os caminhos, também pode ser útil se o designer puder ativar e
desativar a renderização de objetos como gatilhos e outros objetos normalmente invisíveis. Da mesma
forma, pode ser extremamente útil exibir as informações delimitadoras dos objetos no mundo (que
geralmente não correspondem exatamente à composição visual do sprite ou modelo do objeto), para
que o designer possa observar facilmente como as informações delimitadoras afetarão o capacidade
de jogadores e NPCs para navegar no mundo do jogo. Marcando onde os jogadores podem e
Machine Translated by Google

Capítulo 21: Projetando Ferramentas de Projeto 397

não pode ir também pode ser bastante útil. E, novamente, cada parte desses dados de funcionalidade
deve ser facilmente ativada ou desativada por meio de tecla de atalho, menu ou botão, para que o
designer tenha a opção de ver exatamente os dados necessários para o problema em que está
trabalhando. E os dados devem ser absolutamente renderizados na janela de visualização do jogador,
além da visualização de edição, para que o designer possa ver exatamente como o gatilho, caminho,
restrição de inclinação ou outro objeto é colocado no mundo do jogo, sem ter que adivinhar de uma visão de cima p
Ao usar uma visão visualmente autêntica do mundo do jogo que também pode exibir dados de
comportamento do jogo, o designer é capaz de trabalhar nas qualidades estéticas de um nível, bem como
em seus atributos de jogabilidade.

Pulando no jogo
Para jogos em que os jogadores estão manipulando um personagem através de um mundo, é importante
que o designer seja capaz de saber facilmente como o nível “se sente” ao navegar. Para este fim, além
de fazer com que a visão do mundo do jogador represente o que os jogadores verão no jogo, pode ser
bastante útil permitir que o designer realmente manobre nessa visão como faria no jogo real. Com esse
tipo de adição, o designer é capaz de testar se os jogadores serão capazes de dar um certo salto, como
será a sensação de navegar em uma determinada curva “S” e se o personagem dos jogadores se move
suavemente em um set. de escadas. Além desse modo de “jogabilidade”, o editor de níveis deve manter
o modo de “voo” sem restrições que mencionei anteriormente.

O editor de níveis Forge


da Bungie para o motor
Marathon incluiu um “modo
visual” onde o designer poderia
realmente manobrar seu nível
exatamente como um jogador
faria no

jogos.

O editor Vulcan para o motor Marathon da Bungie foi particularmente adequado para permitir que o
designer testasse a “sensação” do nível enquanto o construía. A tecnologia Marathon era semelhante,
mas um pouco melhor que a de Doom, e foi licenciada para uso em vários outros jogos, incluindo meu
jogo Damage Incorporated. Vulcan foi posteriormente revisado, renomeado para Forge e lançado com o
jogo final da série, Marathon Infin ity. Vulcan/Forge permitia um “modo visual”, que funcionava como uma
janela de visualização do jogador. No modo visual, o designer podia navegar pelo mundo da mesma
forma que os jogadores fariam no jogo final. A desvantagem disso foi que o designer não conseguiu editar
o
Machine Translated by Google

398 Capítulo 21: Projetando Ferramentas de Projeto

mundo, além de textura e posicionamento de iluminação, enquanto nesta visão. Isso se deve, sem
dúvida, à velocidade dos processadores disponíveis quando o editor foi criado e ao tamanho
comparativamente pequeno dos monitores acessíveis na época. Hoje, seria definitivamente
esperado que essa visualização pudesse ser aberta simultaneamente com outras visualizações,
permitindo que os usuários alternassem entre ela trivialmente com um clique do mouse ou
pressionamento de tecla de atalho. Da mesma forma, os designers esperariam poder editar mais
do que apenas a iluminação e a textura nessa visualização. No entanto, o modo visual em Vulcan
foi bastante útil, e a mudança do modo de edição para o modo de jogo foi rápida o suficiente para
permitir ao designer fazer uma mudança, ver como se sentia e depois voltar para fazer mais alterações conforme
Claro, pode-se concluir que o próximo passo lógico é permitir que o designer realmente jogue
o jogo na visão do jogador. Dessa forma, o projetista pode ver quão bem os diferentes mecanismos
funcionam e que tipo de desafio os diferentes adversários apresentarão. No entanto, isso abre o
programador para uma grande quantidade de dificuldades de implementação. Para que os objetos
do mundo do jogo funcionem como funcionam no jogo, muitos objetos se moverão da posição em
que começaram quando os jogadores começarem o nível. Por exemplo, um troll agressivo pode
correr em direção ao personagem do jogador e atacar. Esses objetos em movimento também se
movem no editor de níveis? E o que acontece se o designer salvar o nível neste novo estado?
Certamente isso é uma má ideia, já que todos os locais em que as entidades foram cuidadosamente
colocadas serão alterados. O que um designer quer é poder testar rapidamente um nível em
qualquer local, e assim que terminar o teste de jogo, o nível volte ao seu estado “não jogado”. Isso
pode ser feito permitindo que o designer entre rapidamente em um “modo de teste” e saia dele com
a mesma rapidez, retornando-o instantaneamente à funcionalidade do editor de níveis. Quanto mais
rápida for essa transição, melhor, pois quanto mais rápida e fácil ela for, maior a probabilidade de o
designer querer ir e voltar para testar e testar novamente a jogabilidade de seu nível. Se o designer
tiver que esperar um minuto ou mais para jogar o teste, ele não poderá tentar tantas mudanças
diferentes no nível antes de se atrasar. Por esta razão, faz sentido ter um programador focado em
suavizar e acelerar esta transição tanto quanto possível.

Qualquer designer de jogos experiente lhe dirá que o sucesso ou o fracasso de um jogo
depende em grande parte de quão bem ele é testado e equilibrado. Mesmo o design de jogo inicial
mais brilhante pode ser completamente destruído se o jogo implementado não for completamente
testado. Não me refiro apenas aos bugs, mas à jogabilidade – para como o jogo se sente ao jogar
e como ele cativa os jogadores. O teste de jogo é um processo iterativo que envolve experimentar
um tipo de jogo, modificá-lo, tentar novamente e repetir esse loop até que o jogo seja divertido.
Pode ser muito difícil, então, iterar adequadamente através de testes de jogo se o editor de níveis
não facilitar a modificação dos níveis do jogo e, em seguida, permitir facilmente que o designer
experimente o que foi alterado. Quanto mais fácil for para os designers entrar no jogo, tentar algo,
sair do jogo, fazer uma mudança de conteúdo e depois voltar, maior a probabilidade de repetir o
ciclo de teste de jogo várias vezes até o jogo é o mais perfeito possível. Se o editor de níveis não
facilitar esse teste, os designers provavelmente ficarão frustrados ou simplesmente não terão o
tempo necessário para equilibrar o jogo o suficiente.
Machine Translated by Google

Capítulo 21: Projetando Ferramentas de Projeto 399

Editando o mundo
As melhores ferramentas de desenvolvimento para um jogo são compostas por uma delicada mistura
de programas de prateleira e editores proprietários. Uma boa equipe saberá exatamente quanto de
cada usar para não desperdiçar o tempo de seus programadores fazendo com que eles desenvolvam
ferramentas excessivamente sofisticadas quando um bom pacote comercial for mais adequado, nem
restringir irracionalmente os esforços de seus designers por não permitindo-lhes refinar o conteúdo
do jogo a partir de um editor de nível personalizado. Embora nenhuma equipe deva ser forçada a
desenvolver um jogo sem um editor de níveis, é igualmente imprudente forçar a equipe a fazer toda
a criação de conteúdo do jogo a partir de ferramentas proprietárias.
É importante que o editor de níveis realmente permita que o designer modifique todos os
aspectos críticos de jogabilidade de um nível. Parece-me um site pré-requisito óbvio para um editor,
mas ouvi tantas histórias de equipes trabalhando com o 3D Studio MAX e “editores de entidade” que
vale a pena mencionar. Muitas vezes, as equipes pensam que podem usar uma ferramenta pronta
como o MAX para criar toda a geometria do mundo e, em seguida, criar um editor de níveis apenas
para importar as malhas do MAX e posicionar os itens, NPCs e outros jogos - entidades do mundo.
Embora isso seja viável com tempo e tenacidade suficientes, não levará a níveis tão bons quanto
um editor completo. À medida que o designer está colocando criaturas no mapa, ele precisa ser
capaz de alterar simultaneamente a geometria para se adequar ao posicionamento daquela criatura.
Se um designer precisar sair do editor e executar um aplicativo de modelagem 3D (que raramente é
conhecido por sua velocidade), modifique a geometria nesse programa e reimporte o nível para o
editor proprietário antes que ele possa testar suas modificações, ele certamente será desencorajado
de fazer muitos “ajustes” na geometria. Como resultado direto, a geometria não parecerá tão boa ou
jogará tão bem no jogo final. Não permitir que um designer edite a arquitetura crítica de jogabilidade
do nível no próprio editor é o mesmo que amarrar um braço atrás das costas. É minha experiência
que os designers trabalham melhor com as duas mãos livres.

Quando comecei a trabalhar no Centipede 3D, o editor de nível que tínhamos era mais um
manipulador de entidade de jogo do que um editor de nível adequado. A geometria para um
determinado nível foi derivada de um mapa de altura quadrado em escala de cinza, com aqueles
usados no Centipede 3D todos consistindo de 32 x 32 pixels. Cada pixel representava um valor de
altura na paisagem. Esses mapas de altura, que podiam ser criados no Photoshop ou em qualquer
outra ferramenta de envio de pixels, eram uma boa maneira de criar uma versão inicial da geometria de um n
Infelizmente, na versão do editor usada no início do projeto, os mapas de altura só podiam ser
modificados em um programa de pintura; eles não podiam ser editados no próprio editor. Isso foi
uma pena, já que olhar para uma representação 2D de cima para baixo de um nível 3D não é
exatamente a melhor maneira de ter uma ideia de como o nível acabará ficando. Como resultado,
os níveis que foram criados no início do projeto eram simples e um pouco planos. Não que os
designers de níveis não estivessem trabalhando duro para tornar os níveis atraentes, apenas que
havia muito que poderia ser feito com as ferramentas fornecidas.
No entanto, no meio do projeto, a funcionalidade foi adicionada à ferramenta para permitir que
o designer edite os mapas de altura enquanto estiver no editor de níveis. Os mapas de altura ainda
podiam ser criados no Photoshop e trazidos para o jogo, e essa era a melhor maneira de fazer um
primeiro passo na arquitetura do nível. Após essa primeira passagem, no entanto, a geometria foi
facilmente manipulada no editor de níveis, onde o designer pôde ver o nível em 3D enquanto
modificava o mapa de altura. Como resultado, os designers puderam
Machine Translated by Google

400 Capítulo 21: Projetando Ferramentas de Projeto

ajustar a geometria até ficar perfeita. A mudança na qualidade dos níveis foi dramática. Como
sempre, o tempo não nos permitiu voltar e refazer os níveis anteriores. Como os níveis foram
feitos na ordem em que apareceram no jogo, qualquer um que jogue Centipede 3D poderá dizer
em que ponto os designers de níveis receberam a ferramenta nova e aprimorada. Não que os
designers não pudessem criar níveis com a encarnação anterior do editor, era apenas que a
edição de níveis era muito mais difícil que os níveis não pareciam tão bons quanto os designers
queriam.
Há muito a ser dito sobre ser capaz de criar geometria de nível sofisticado em um pacote
3D completo, e até mesmo editores de nível com recursos sofisticados de edição de geometria
se beneficiariam da capacidade de importar arquitetura criada externamente.
A chave para criar ativos de arte de jogos de qualidade, sejam eles sprites 2D ou modelos 3D, é
poder importar de pacotes comerciais. Eu não sei se alguém já foi forçado a criar arte de sprite
2D para um jogo usando apenas uma ferramenta interna. No entanto, parece que muitos artistas
infelizes só foram autorizados a modelar personagens ou outros objetos usando ferramentas de
modelagem proprietárias. Discuti como é importante permitir que os designers de nível manipulem
a arquitetura de um nível no editor. Mas certamente forçar designers de jogos ou artistas a
modelar cada elemento do mundo do jogo no editor de níveis é um grande erro. Os artistas
devem ser capazes de criar objetos do mundo do jogo, como árvores, armas ou latas de lixo em
seu pacote de modelagem favorito e importá-los para o jogo.
Simplificando, não há como a equipe de programação de um jogo ser capaz de codificar um
pacote de edição de arte com todo o poder, robustez e estabilidade de um Photoshop, 3D Studio
MAX, Maya, Softimage ou qualquer um de vários de outros produtos populares de prateleira.
Sem os muitos recursos encontrados nesses pacotes, os artistas simplesmente não conseguirão
criar a arte da melhor qualidade possível. Além disso, a maioria dos artistas já está familiarizada
com um ou mais desses pacotes e, portanto, quando entrarem no projeto, estarão muito mais
perto de estar “atualizados”.
Ao mesmo tempo, a equipe precisará ser capaz de manipular essa arte usando ferramentas
proprietárias. Ter um editor interno para configurar animações, nós em um esqueleto, dados de
colisão ou outras informações é essencial para que a arte funcione corretamente dentro do jogo.
As equipes que tentam evitar a configuração de qualquer tipo de software de edição de arte
frustrarão seus artistas, designers ou quem quer que fique preso em configurar a arte e suas
animações para funcionar no jogo. Uma ferramenta proprietária de manipulação de arte que faz
exatamente o que o mecanismo de jogo precisa é um ingrediente-chave em uma experiência
suportável de desenvolvimento de jogos.

Linguagens de script e comportamentos de objetos


Parece ter se tornado a norma para os jogos usar um sistema onde os designers podem
configurar e equilibrar o inimigo, a arma e outros comportamentos do jogo exatamente como eles
precisam, sem envolver um programador. Muitos jogos agora incluem linguagens de script que,
embora relativamente simples, permitem a criação de entidades complexas sem exigir que o
próprio mecanismo de jogo seja recompilado. Essas linguagens de script fornecem muitos
benefícios ao desenvolvimento de jogos. Provavelmente o mais importante é que eles incentivam
a criação de comportamentos mais exclusivos no jogo, sejam eles entidades reutilizáveis no jogo,
como NPCs, ou eventos únicos para um nível específico, como NPCs realizando uma conversa
específica enquanto o jogador assiste em Metade . -Vida.
Machine Translated by Google

Capítulo 21: Projetando Ferramentas de Projeto 401

Um grande benefício de um sistema de script projetado adequadamente é que ele é


completamente portátil para outros sistemas. Isso significa que quando o jogo é portado do PC
para o Dreamcast, por exemplo, todos os comportamentos inimigos que foram roteirizados e
depurados no PC serão igualmente funcionais no Dreamcast, desde que o interpretador de scripts
e suas funções associadas estejam devidamente portado também. Nesse sentido, uma linguagem
de script robusta também é mais estável para trabalhar do que a programação em C. A linguagem
de script dá ao autor do script menos oportunidade de travar completamente o jogo, e quando um
script faz algo ilegal, o jogo pode cuspir uma mensagem informativa em vez de apenas travar.
Muitas vezes, as linguagens de script não são tão complexas quanto a programação C real e,
portanto, permitem que designers com algum conhecimento de programação assumam a criação
de comportamentos de mundo únicos, liberando programadores mais difíceis de encontrar para
tarefas mais complexas. Na maioria dos sistemas, os scripts também podem ser carregados sob
demanda, o que significa que apenas os scripts que uma seção específica do jogo usa precisarão
ser residentes na memória, liberando assim mais sobrecarga de código. Um bônus adicional de
um jogo com uma linguagem de script é que ela permite a modificação complexa do usuário desse
jogo. Um sistema de script bem projetado e adequadamente poderoso capacitará os jogadores
motivados a fazer seus próprios “mods” para o jogo para distribuição aos amigos.
As linguagens de script também têm seu lado negativo. O primeiro é o tempo envolvido na
implementação de um sistema de script. Se a linguagem for realmente útil para o jogo, conforme
descrito acima, ela precisará ser muito estável e fornecer ao usuário muito poder, o que certamente
não é trivial de implementar. Depurar um script problemático também pode ser bastante
problemático, já que nenhum desenvolvedor de jogos terá tempo para implementar um depurador
simbólico tão bom quanto o que vem com o Visual Studio ou CodeWarrior.
Na maioria das vezes, os scripts são compilados em tempo de execução e, como resultado,
podem ser significativamente mais lentos que o código C/C++. Novamente, não importa o que o
desenvolvedor faça em termos de otimização do desempenho dos scripts, ele não será capaz de
igualar o poder de compilação dos compiladores C++ feitos pela Watcom, Microsoft ou Metrowerks.
E, finalmente, embora uma das grandes vantagens das linguagens de script seja que elas podem
ser usadas por não programadores, geralmente acontece que, se a linguagem de script for
realmente poderosa o suficiente para criar IA para um NPC, é vai ser tão complexo que requer um
programador para usá-lo de forma eficaz. E se o tempo de um programador está sendo usado na
criação de scripts, por que impedi-lo de apenas fazer seu trabalho de codificação em C?
Claro, uma das principais vantagens dos scripts é que eles simplificam bastante o
balanceamento da jogabilidade. Em vez de um programador ajustar um número no código e
esperar que o jogo recompile, um designer pode ajustar um valor em um script e simplesmente
executar o jogo. Mas e se alguém quiser obter esse benefício de scripts sem ter que implementar
um sistema de script? E se, em vez disso, os designers pudessem ajustar os parâmetros de
comportamento no próprio editor de níveis? Esta é a abordagem adotada pelo Riot Engine da
Surreal Software. No Level Editor do Surreal, os designers têm acesso a todas as configurações
ou “variáveis de comportamento” para uma determinada IA, arma ou outra entidade do mundo do jogo.
Os comportamentos em si são codificados em C++, com os programadores deixando “ganchos”
para todas as configurações cruciais que determinam como o objeto do mundo do jogo se
comportará, como a velocidade com que ele se move, qual é o raio de detecção, o que ele faz
quando é destruído, e assim por diante. Isso fornece grande parte do benefício de balanceamento
de jogo das linguagens de script, capacitando os designers a ajustar infinitamente o jogo enquanto
ainda aproveitam a velocidade de um poderoso compilador e depurador C++. Essa funcionalidade faz com
Machine Translated by Google

402 Capítulo 21: Projetando Ferramentas de Projeto

O Riot Engine Level Editor


da Surreal Software permite
que o designer ajuste todos
os tipos de configurações
para diferentes entidades do
mundo do jogo.

editor de níveis não é apenas uma ferramenta para modificar os níveis do jogo, mas o transforma mais em
um editor de jogabilidade, onde o designer é capaz de alterar grande parte do conteúdo do jogo em tempo
real. Claro, você nem sempre precisa de um editor sofisticado para obter variáveis facilmente ajustáveis;
muitos jogos permitiram que os designers modificassem os valores da jogabilidade por meio de arquivos de
texto que podem ser editados em qualquer editor de texto e que são lidos pelo jogo em tempo de execução.
É claro que manter vários arquivos de texto pode ser menos amigável do que um editor especificamente
projetado para modificar esse tipo de dados. Mas, ao mesmo tempo, se você não tiver tempo suficiente para
investir em suas ferramentas, editar arquivos de texto pode ser preferível a dados que só podem ser
modificados em um editor especialmente desajeitado ou quebrado.
“Eventos com script” em níveis são outra coisa que as linguagens de script de jogos fazem bem. Cada
nível do jogo pode ter um script único que configura e aciona vários comportamentos únicos naquele nível.
Ter comportamentos complexos e únicos tornou-se recentemente uma preocupação muito maior dos
desenvolvedores de jogos. Um exemplo inicial e influente foi o excelente uso da Valve de eventos roteirizados
integrados à jogabilidade mais dinâmica adequada em Half-Life. Claro, há uma diferença fundamental entre
“eventos com script” e a “linguagem de script” que se usa para configurá-los. Half-Life tinha ótimos eventos
roteirizados, mas aparentemente um método difícil de usar para configurá-los. Criar um sistema de script
sólido e simples é a melhor maneira de garantir que os designers o utilizem.

Em vez de envolver uma linguagem de script baseada em texto compilada separadamente, os editores de
nível podem incluir a capacidade de capacitar os designers a configurar facilmente eventos de jogos complexos.
O editor STOMP da Surreal Software, usado nos jogos Drakan e The Suffering, embora não seja o software
mais livre de bugs já escrito, permite que designers e animadores configurem sequências de script complexas
com relativa facilidade no editor e as visualizem em real -time 3D à medida que são construídos. As
sequências, que podem ser usadas como cut-scenes e eventos com script no jogo, podem ser facilmente
editadas em tempo real usando uma interface que lembra o Adobe Premiere. O Editor de Campanhas de
StarCraft é um exemplo especialmente bom de um sistema de script mais orientado para a jogabilidade com
uma interface bem concebida e amigável. Seu editor “Triggers” permite que os designers usem uma interface
de apontar e clicar muito familiar para configurar eventos complexos com script. Os menus pop-up fornecem
listas
Machine Translated by Google

Capítulo 21: Projetando Ferramentas de Projeto 403

de todos os comandos disponíveis e, em seguida, outros pop-ups mostram ao designer todos os


diferentes parâmetros que podem ser passados para esses comandos. Todo o sistema é facilmente
compreensível para quem o vê pela primeira vez, com comandos escritos em inglês simples. Assim,
o Editor de Campanha permite que eventos únicos ocorram nos níveis de StarCraft sem envolver a
sobrecarga de uma linguagem de script completa.

O StarCraft Campaign
Editor permite scripts
fáceis usando gatilhos e
uma interface simples de
apontar e clicar.

Nós contra eles


Por mais lamentável que seja, o desenvolvimento das ferramentas para um projeto muitas vezes
se resume a uma batalha entre os programadores e os designers. Os programadores de jogos
geralmente relutam em trabalhar em ferramentas por vários motivos. Primeiro, muitos dos
programadores que queriam entrar no mundo dos jogos o fizeram porque não queriam programar
bancos de dados, planilhas ou pacotes de modelagem 3D. Eles queriam fazer jogos, e as
ferramentas muitas vezes parecem muito com “programação real”. Há também uma percepção de
que obter o código de alguém no jogo é mais importante do que obtê-lo nas ferramentas. Se o título
for um grande sucesso, o jogo será jogado por milhões de pessoas. As ferramentas para um
determinado projeto, no entanto, serão usadas por talvez dez ou vinte pessoas. Quando os amigos
de um programador perguntam no que ele trabalhou enquanto estava naquela empresa maluca de
jogos, a maioria dos programadores não quer ter que responder: “Eu trabalhei nas ferramentas”. Há uma cer
Para complicar ainda mais, a percepção de que o tempo de um programador é mais valioso
do que o de um designer. Então, se um designer tem que gastar cinco vezes mais tempo fazendo
um nível porque um programador não tem tempo para melhorar o editor de nível, tudo bem. O nível
ainda é feito, certo?
Como afirmei anteriormente, os desenvolvedores de jogos não devem se perguntar: “As
ferramentas permitem que o conteúdo do jogo seja criado?” Em vez disso, eles devem perguntar:
“As ferramentas permitem que o conteúdo do jogo seja bem feito?” Se um designer está
constantemente lutando com as ferramentas de criação de níveis, ele não será capaz de investir
tempo para refinar verdadeiramente o nível. Na verdade, ele pode estar tão irritado com o programador perc
Machine Translated by Google

404 Capítulo 21: Projetando Ferramentas de Projeto

preguiça que ele joga as mãos para cima com desgosto e não trabalha no nível tanto quanto poderia de
outra forma. Um bom designer de níveis será inspirado por um bom conjunto de ferramentas para fazer
o melhor trabalho possível, porque ele pode ver resultados diretos. O exemplo que usei antes sobre a
ferramenta de design de níveis e a qualidade resultante dos níveis no Centipede 3D é uma boa lição
para desenvolvedores de jogos. Com a criação de uma ferramenta de edição de nível superior, a
qualidade do nível melhorará drasticamente.
Um programador de ferramentas deve se orgulhar de ter trabalhado em uma ferramenta realmente
boa que facilite o trabalho do designer. O programador responsável por um editor de níveis bem
concebido e bem implementado que facilite muito a criação de belos níveis deve sentir que desempenhou
um papel vital na criação desses níveis. Pois sem os recursos do editor de níveis, o designer não seria
capaz de criar as paisagens ou estruturas que criou. O designer deve sempre fazer questão de lembrar
o programador que possibilitou a criação de tais níveis e ser devidamente agradecido por seus esforços.

O WarCraft III World


Editor da Blizzard
configura automaticamente
as transições entre
diferentes tipos de
texturas de paisagem,
poupando assim muito
trabalho aos designers.

Em um ponto, adicionei um recurso de texturização ao Riot Engine Level Editor. Na época, o Riot
Engine empregava texturas de ladrilhos para sua paisagem, com texturas de transição disponíveis para
quando uma textura de grama encontra uma textura de rocha, por exemplo. Eu adicionei a funcionalidade
que permitia ao editor colocar automaticamente as transições apropriadas entre dois tipos de textura
diferentes. Curiosamente, esse foi um recurso incluído no editor de níveis do meu primeiro jogo publicado
de cinco anos antes, Odyssey: The Legend of Neme sis. De fato, essa funcionalidade de transição
automática é encontrada em muitos editores de nível de terreno 2D, como o StarCraft Campaign Editor
da Blizzard ou o WarCraft III World Editor.
Antes de adicionar o recurso, os designers de nível da Surreal tiveram que escolher manualmente a
textura de transição necessária. Certamente o recurso de autotransição não era absolutamente
necessário para a criação de níveis. Todos os níveis do jogo Drakan foram feitos sem o uso da
ferramenta de transição automática, e certamente eram níveis muito bonitos com transições em todos
os lugares certos. A diferença fundamental é que
Machine Translated by Google

Capítulo 21: Projetando Ferramentas de Projeto 405

essas transições levaram muito tempo do designer para configurar. Assim que adicionei a ferramenta
de transição automática, os designers ficaram encantados, pois agora uma grande e tediosa parte de
seus trabalhos havia sido praticamente eliminada. Um deles até disse: “Richard pode decolar no
próximo mês e nós poderíamos continuar pagando a ele”. Ele gostou do recurso que eu adicionei e
foi atencioso o suficiente para me comunicar seus agradecimentos. Com elogios como esse, os
programadores de ferramentas são muito mais propensos a continuar adicionando recursos bacanas ao editor.

A melhor das intenções


No entanto, é preciso ter cuidado. Às vezes, quando os programadores são encarregados de adicionar
funcionalidades ao editor, eles podem acabar adicionando recursos que ninguém realmente precisa.
É difícil para um programador que, na maioria das vezes, não faz os níveis do jogo e, portanto, não
gasta muito tempo trabalhando com o editor de níveis, entender corretamente o que falta nesse editor.
De fato, o que um programador pode ver como um recurso legal pode se tornar uma funcionalidade
que nenhum designer jamais desejará usar. Quando um programador se dá ao trabalho de
implementar um recurso para o editor e os designers não conseguem usá-lo, o ressentimento tende a
crescer no programador. Então, quando um designer chega ao programador solicitando que um
recurso mais prático e necessário seja adicionado ao editor, o programador provavelmente o ignora,
pensando: “Ele nunca usou a ferramenta de deformação de vértices na qual trabalhei tanto, então por
que deveria Eu trabalho nesse modelo de alinhador para ele? Esqueça."

Qualquer um que tenha trabalhado na indústria sabe que, de várias maneiras, designers e
programadores pensam de forma diferente. Por esta razão, é muito importante que os designers e
programadores estejam em constante comunicação sobre quais recursos o editor precisa e como
eles podem ser implementados da melhor maneira. Ao desenvolver um conjunto de ferramentas
interno, o programador tem a tremenda vantagem de ter sua base de usuários no corredor.
Ele não precisa adivinhar o que eles querem do programa; em vez disso, ele pode ir perguntar a eles.
Da mesma forma, os designers têm a vantagem de poder ir ao desenvolvedor do editor e fazer
sugestões sobre como a ferramenta deve funcionar. Com um bom fluxo de informações entre as
partes envolvidas, as ferramentas não podem deixar de melhorar.
Uma técnica possível para facilitar a criação de uma boa ferramenta é designar um programador
para ser o principal responsável pela manutenção e melhoria do editor de níveis, em vez de passar
as tarefas do editor para “quem tiver tempo”. Este programador pode então se familiarizar com o
funcionamento da ferramenta e pode se orgulhar de que é uma boa aplicação. Se um programador
fizer a maior parte do trabalho do editor, os designers saberão a qual programador podem recorrer
com suas sugestões de melhorias para a ferramenta. Esse programador terá uma noção melhor do
que os designers gostam e não gostam. Claro, se o programador designado para trabalhar na
ferramenta realmente deseja estar trabalhando em efeitos de iluminação ou IA, a ferramenta sofrerá
como resultado. Encontrar um programador que realmente queira trabalhar na ferramenta é importante
para que essa estratégia tenha sucesso.

Outra tática útil é fazer com que um programador faça um nível completo e simples usando a
ferramenta. Dessa forma, o programador pode facilmente identificar áreas de melhoria no editor e
pode finalmente entender do que os designers estão reclamando há tantas semanas. Se o nível for
de qualidade suficiente e atender às necessidades do projeto, você pode até considerar enviar esse
nível criado pelo programador com o jogo.
Mas mesmo se você não fizer isso, o entendimento que o programador ganha ao usar o
Machine Translated by Google

406 Capítulo 21: Projetando Ferramentas de Projeto

editor como é realmente usado será inestimável. Sem realmente ter que sentar e usar totalmente o
aplicativo que está criando, o programador provavelmente concluirá que os designers estão
enfatizando demais os problemas com o editor (conhecido no jargão da indústria como “chorão”).
Mas, ao realmente ter que usar a ferramenta em que está trabalhando, um programador
provavelmente identificará facilmente as deficiências do editor que podem ser facilmente corrigidas
através de algumas horas de codificação. Os designers frequentemente não conseguem entender a
complexidade das diferentes tarefas de programação e, como resultado, fazem solicitações de
recursos quase impossíveis no editor de níveis, enquanto pensam que problemas facilmente remediados não pod
Talvez a melhor solução de todas seja ter um designer que também seja programador e, portanto,
passe muito tempo trabalhando com o editor. Esse designer/programador está diretamente motivado
para melhorar a ferramenta com a qual deve trabalhar todos os dias e provavelmente fará o que
puder para torná-la a melhor ferramenta possível. Dez anos atrás, tenho certeza de que isso não era
tão incomum, mas para projetos em grande escala em desenvolvimento hoje é bastante raro.
Programar um editor de níveis e projetar níveis tornaram-se tarefas que consomem totalmente o
tempo de um desenvolvedor individual e, infelizmente, os dias do designer/programador parecem
ser uma coisa do passado.

Um editor de jogos para todas as estações


Um editor de níveis não precisa estar livre de bugs. Software livre de bugs é o que se compra nas
lojas, se tiver sorte. Ferramentas internas realmente ótimas podem ter muitos bugs. O importante é
que essas ferramentas sejam bugadas de maneiras previsíveis. Os bugs devem ocorrer em padrões
que os projetistas possam aprender a prever e ensinar a eles mesmos a evitar. Uma vez que um
designer se torne adepto das ferramentas, ele saberá o que não fazer e será capaz de contornar
facilmente os pontos problemáticos. Ferramentas de editor de nível proprietário são um lugar no
desenvolvimento de software onde a velha piada “Doutor, dói quando eu faço isso!” “Então não faça
isso!” realmente soa verdadeiro.
É claro que, se as ferramentas usadas em um projeto forem boas o suficiente, o marketing pode
pegar e ter a ideia brilhante: “Ei, podemos liberar as ferramentas com o jogo!”
De fato, enviar um jogo com seu editor de níveis e fazer com que os usuários criem níveis adicionais
para o seu título pode ajudar a manter vivo o interesse em um jogo muito depois de ter sido lançado.
Os fãs hardcore vão adorar fazer “mods” para o jogo circular entre seus amigos ou o público em
geral. Para que as ferramentas sejam lançadas, elas realmente precisarão ser relativamente livres
de bugs, ou pelo menos muito mais estáveis do que quando estavam sendo usadas apenas internamente.
A possibilidade de liberar o editor de níveis para os fãs deve funcionar como um incentivo para
estimular a equipe de programação a criar as melhores ferramentas possíveis. Claro, alguns editores
ainda não conseguem ver a lógica de fazer com que a comunidade de fãs construa add-ons e se
recuse a liberar as ferramentas usadas para a criação do jogo. O argumento que eles costumam dar
é que, se os usuários podem construir mais níveis, quem vai querer comprar a sequência? É claro
que a id Software, a empresa que popularizou a liberação de editores de nível para o público,
continua a se sair muito bem financeiramente, sugerindo que o pensamento protecionista em termos
de editores de nível é um tanto tolo.
No final, tudo se resume ao que deve ser reconhecido como um axioma na indústria de jogos:
um jogo só pode ser tão bom quanto as ferramentas usadas em sua criação. Uma ferramenta de
design de níveis bem concebida pode fazer a diferença entre um ótimo jogo e um medíocre. Pode-se
pensar no editor de níveis ideal como um lugar onde o designer tem
Machine Translated by Google

Capítulo 21: Projetando Ferramentas de Projeto 407

controle total do mundo do jogo: de sua arquitetura (onde os jogadores podem ir), de sua aparência
estética (iluminação, textura e sons) e de sua jogabilidade (NPC, item e
posicionamento, movimento e comportamento de outra entidade). Claro, o melhor editor de níveis em
o mundo não vai compensar um motor abaixo da média, um jogo fundamentalmente falho
design, ou uma equipe de desenvolvimento desmoralizada. Mas esses são temas para outro capítulo.
Machine Translated by Google

Capítulo 22
Entrevista: Will
Wright

É difícil medir o impacto que o jogo SimCity , de Will Wright, teve na indústria. Na época de seu
lançamento em 1989, o jogo era tão radicalmente diferente de qualquer outra peça de entretenimento
interativo por computador que por muitos anos o projeto teve problemas para encontrar uma editora.
Agora a influência do jogo pode ser vista nos inúmeros jogos “construtores” lançados todos os anos.
Sid Meier admite prontamente que SimCity foi uma de suas principais inspirações ao fazer
Civilization. Surpreendentemente, Wright conseguiu superar SimCity com seu grande triunfo, The
Sims. Novamente Wright saiu totalmente do campo esquerdo com um jogo que ele teve que lutar
para ser feito. Enquanto a maioria dos jogos lançados nos últimos dez anos levam apenas pequenos
passos evolucionários de melhoria, com The Sims Wright criou algo verdadeiramente revolucionário
que foi o design de jogo mais original visto em anos. Conversar com Wright é uma experiência por
si só, pois a pessoa fica instantaneamente ciente do motivo pelo qual ele desenvolveu jogos tão
brilhantes e inovadores.

Como você se interessou pelo desenvolvimento de jogos?


Eu me apaixonei totalmente por computadores logo depois que comprei um Apple II por volta de 1980.
Acabei de me apaixonar por jogos. Quando criança, passei muito tempo construindo modelos e comprei alguns

408
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 409

dos primeiros jogos, como a primeira versão do Flight Simulator com os gráficos de estrutura de arame.
Você tinha que escrever seu próprio patch de linguagem de máquina para executá-lo - isso era
engraçado. Mas apenas a ideia de que você poderia construir seu próprio micromundo dentro do
computador me intrigou. Então eu vi isso como uma espécie de ferramenta de modelagem. Em algum
momento eu me apeguei tanto a essas coisas que decidi que tentaria fazer um eu mesmo, e isso foi bem
na época em que o Commodore 64 foi lançado pela primeira vez. Então comprei um desses, imaginando
que seria melhor começar em uma nova máquina onde todos estivessem em igualdade de condições,
porque outras pessoas aprenderam o Apple II anos antes de eu decidir fazer isso. Então eu comprei um
Commodore assim que ele saiu e mergulhei nele, e aprendi o mais rápido que pude. E foi nisso que fiz
meu primeiro jogo.

Então, como você criou o design de Raid Over Bungeling Bay?


Naquela época, quase todos os jogos eram jogos de arcade, você sabe. Eu sempre amei helicópteros,
então eu queria fazer um pequeno jogo de helicóptero. E então eu estava olhando para o Commodore.
Foi impulsionado provavelmente mais pela tecnologia do que pelo lado do design do jogo.
Descobri que o Commodore tinha um truque muito legal onde você podia redefinir um conjunto de
caracteres, fazer com que parecesse com gráficos e então rolar suavemente pela tela. Assim, você pode
dar a impressão de estar rolando sobre esse bitmap enorme, quando na verdade tudo o que você está
fazendo é mover caracteres ASCII na tela. E quando eu vi esse recurso, eu pensei que seria muito legal,
porque eu sabia que a Apple não poderia começar a se mover tanto em termos de gráficos ao redor da
tela tão suavemente. Então eu projetei o jogo em torno desse recurso de certa forma.

Eu entendo que o jogo era muito mais popular no Japão do que nos Estados Unidos.

Acho que isso foi certo quando a pirataria provavelmente estava no auge. Vendemos cerca de 30.000
cópias nos Estados Unidos, o que era a média para um jogo como aquele. Mas então todo mundo com
quem conversei que tinha um Commodore naquela época tinha jogado. Considerando que o mesmo
jogo na Nintendo no Japão vendeu cerca de 750.000 cópias. Era um sistema de cartuchos, então não
havia pirataria.

Você ainda olha para o jogo de forma positiva?


Oh sim. Eu olho para trás com boas lembranças. Foi uma experiência de aprendizado. Foi um daqueles
momentos em que você percebe que os últimos dez por cento, fazer o jogo sair, essa é a parte realmente
difícil. E a menos que você planeje os últimos dez por cento, é apenas um assassino. Então eu aprendi
muitas lições com isso. E naquela época a programação não era tão elaborada quanto agora. Cada jogo
foi escrito por uma pessoa e esse jogo tinha cerca de oito mil linhas de linguagem de máquina. Assim
você pode controlar totalmente a memória e controlar totalmente a máquina. Foi um bom veículo de
aprendizagem. É uma pena que os programadores que aprendem a programar hoje em dia estejam
vindo de um ponto de vista totalmente diferente.

Você quer dizer porque eles estão usando linguagens de programação de alto nível?
Oh sim. O que não é necessariamente ruim, eu acho. Mas você ainda tem os velhos hacks como eu.
Havia oito bytes de memória livre naquela máquina quando terminei isso
Machine Translated by Google

410 Capítulo 22: Entrevista: Will Wright

jogo, e me senti mal por não ter usado os oito últimos. E há muitos truques que você faz quando está
ficando sem memória, porque a memória era a maior preocupação.
Havia alguns truques legais para isso.

Eu li que a ferramenta de edição de níveis para Bungeling Bay foi sua inspiração para SimCity.

Era um conjunto de caracteres que na verdade descrevia um monte de ilhas com pequenas estradas e
cidades. E então havia uma área tão grande que desenvolvi meu próprio programa de edição de personagens
para desenhar essa cena que eu poderia rolar suavemente, como um programa de pintura. Descobri que
estava me divertindo muito mais com o programa de pintura do que com o jogo que, depois que terminei o
jogo, continuei jogando com o programa de pintura. E eventualmente evoluiu para SimCity.

Então você não citaria nenhum outro jogo que inspirou SimCity?

Eu diria que a maior inspiração,


se houvesse, foi o trabalho de
Jay For ester, que é considerado
o pai da dinâmica de sistemas e
uma das primeiras pessoas a
usar um computador para
simulação.

Então, quando comecei a ter a


ideia do SimCity, comecei a ir à
biblioteca e a ler. Ele fez muito
do seu trabalho nos anos 50,
trabalhando com computadores
muito primitivos e modelos muito
primitivos, mas mesmo assim
ele foi a primeira pessoa a tentar SimCityName

simular uma cidade. E ele fez


isso com vinte variáveis: uma era população, outra era produção, uma era taxa de natalidade, coisas assim.
Modelos muito simples.
A dinâmica de sistemas é uma maneira de olhar para um sistema e dividi-lo em, basicamente, estoques
e fluxos. Os estoques são quantidades, como a população, e os fluxos são taxas, como a taxa de
mortalidade, a taxa de natalidade, a imigração. Você pode modelar quase tudo usando apenas esses dois recursos.
Foi assim que ele começou a dinâmica de sistemas e essa foi a abordagem que ele adotou para sua
modelagem. Descobri as coisas dele quando comecei a trabalhar no SimCity e comecei a me ensinar
técnicas de modelagem. Também me deparei com coisas mais recentes com autômatos celulares, e SimCity
é realmente um híbrido dessas duas abordagens. Porque sua abordagem não era espacial, enquanto os
autômatos celulares oferecem muitas ferramentas espaciais realmente interessantes para propagação, fluxo
de rede, proximidade e assim por diante. Então, o fato de que a poluição começa aqui, se espalha por aqui
e lentamente diminui cada vez mais, e você pode realmente simular ondas de propagação através dessas
estruturas espaciais. Então SimCity , em certo sentido, é como um grande autômato celular tridimensional,
com cada camada sendo alguns
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 411

característica da paisagem como crime ou poluição ou valor da terra. Mas as camadas podem interagir
na terceira dimensão. Assim, as camadas de crime e poluição podem impactar a camada de valor da
terra.

O que o fez pensar que tais técnicas acadêmicas poderiam levar a algo que as pessoas
achariam divertido?
Naquele momento, eu não estava tentando construir algo que as pessoas tocassem pelo valor do
entretenimento. É mais como se eu estivesse apenas me divertindo fazendo isso sozinho. Ao mesmo
tempo eu estava lendo sobre dinâmica urbana, apenas no lado teórico. E ter essa pequena cidade de
cobaias no meu computador enquanto eu lia sobre o assunto tornou o assunto muito mais interessante.
Assim, eu podia ler uma teoria e tentar descobrir como formalizá-la, codificá-la, colocá-la no modelo e
ver quais eram os resultados.

Em que ponto você começou a pensar que poderia ser algo com o qual outras pessoas
poderiam se divertir?

Depois de cerca de seis meses, comecei a anexar alguns gráficos a ele. Era bastante abstrato para
começar. E então comecei a pensar, sabe, esse pode ser um jogo interessante. Na verdade, eu tinha
feito meu primeiro jogo com a Broderbund Software, e mostrei para algumas pessoas lá e elas
acharam muito legal. Eles concordaram em pegá-lo, e nós tínhamos um contrato para isso e tudo
mais. E eu trabalhei nele por cerca de um ano até o ponto em que estava onde eu queria que
estivesse. E eles continuaram pensando que não estava acabado. Eles ficavam dizendo: “Quando vai
ser um jogo? Quando haverá uma situação de ganho/perda?” Era muito incomum para a época, e
isso foi cerca de cinco anos antes de ser realmente lançado. Isso foi por volta de 1985, e nós não o
lançamos até 1989.

Eles não acharam que era um jogo suficiente para se encaixar com seus outros produtos?
Eles simplesmente não viam como poderiam vendê-lo. E eu simplesmente deixei lá, e eles deixaram
lá, e foi isso.

Então você ficou muito desanimado?


Eu sempre pensei que era uma coisinha legal que eu fazia; Eu nunca pensei que seria uma coisa de
stream principal. Mas achei que valeria a pena colocá-lo no mercado. Então, mais tarde, conheci meu
eventual parceiro, Jeff Braun, e mostrei a ele. E ele achou muito legal. Ele realmente, realmente
estava nisso. Ele, na verdade, achava que provavelmente havia um grande mercado para algo assim.
Nesse ponto, nós dois decidimos começar uma empresa, e foi quando começamos a Maxis.

Então, ele ficou parado, inédito, por vários anos?


Sim, por alguns anos. Na época em que decidimos começar a Maxis, o Macintosh tinha acabado de
sair, e o Amiga estava saindo, e decidimos que reescreveríamos o jogo para esses computadores.
Então, contratamos alguns programadores e recodifiquei o simulador em C. Tudo já estava em
assembly antes. Tivemos esses outros programadores ajudando nos front-ends gráficos no Mac e no
Amiga, e essas foram realmente as primeiras versões lançadas. Na verdade, voltamos e lançamos a
versão do Commodore cerca de um mês depois de lançá-las.
Machine Translated by Google

412 Capítulo 22: Entrevista: Will Wright

Então originalmente SimCity não tinha uma interface de apontar e clicar baseada em mouse?
Não, na verdade aconteceu.
O Lisa tinha saído enquanto
eu estava fazendo isso no
modo Com, e na verdade eu
tinha implementado um
sistema baseado em cursor com ícones.
A interface estava em um
Commodore, mas ainda tinha
aquela sensação icônica de
programa de pintura. Parecia
MacPaint de certa forma.
Então, de fato, ele tinha um
front-end gráfico semelhante,
mas com uma resolução muito menor.

SimCityName

O design mudou muito em relação ao que você havia feito originalmente?


Ficou mais elaborado, mais camadas foram adicionadas e havia maior resolução no mapa, mas
tinha a mesma estrutura básica para a simulação e os mesmos conjuntos básicos de ferramentas.
Mas, por exemplo, havia apenas estradas, não havia estradas e rodovias. O mapa tinha 80 por 90,
em vez de 128 por 128. Claro, os gráficos tinham resolução muito menor; eles eram cerca de quatro
pixels quadrados para um bloco, em vez dos dezesseis eventuais. Mas o núcleo do modelo e o
ajuste do modelo não mudaram muito. E na verdade não mudou muito para SimCity 2000 ou 3000.

Então a Maxis finalmente o lançou no mercado publicando-o por conta própria?


É realmente meio interessante. Depois de refazermos no Mac e no Amiga, sabíamos que podíamos
produzir nas caixas e tudo mais, mas precisávamos de um distribuidor. E, de fato, voltamos ao
Broderbund e mostramos a eles, e quando viram as versões para Mac e Amiga ficaram muito mais
impressionados. Além disso, anos depois, o mercado estava entrando em jogos muito mais
interessantes. Nesse ponto, eles se ofereceram para se tornar nosso distribuidor e, portanto,
tínhamos uma relação de publicação de afiliados com a Broderbund. Estávamos incorrendo na
maior parte do risco financeiro porque éramos nós que pagamos pelas caixas e tudo mais, então
eles não estavam arriscando tanto assim. As pessoas da Broderbund eram pessoas muito legais e
eu não guardo rancor contra eles. Eles nos ajudaram muito a tirar a Maxis do chão. E os Carlstons,
as pessoas que começaram a Broderbund, foram meus modelos para os empresários. Eles eram
apenas pessoas muito legais de se lidar.

Você veio com o termo “brinquedo de software”?


Acho que sim, porque eu estava dando uma palestra na Game Developers Conference, lá atrás, e
decidi que esse seria o nome da minha palestra. Era “Brinquedos de software: a interseção de
criatividade, empatia e...” alguma coisa. Alguma conversa de alto escalão.
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 413

Como você distinguiria entre um brinquedo de software e um jogo?


Os brinquedos podem ser usados para construir jogos. Você pode jogar com brinquedos. Mas você
também pode se envolver em brincadeiras mais livres com brinquedos. Não precisa ser uma atividade
direcionada a um objetivo. Eu acho que os brinquedos são mais abertos do que os jogos. Podemos usar
uma bola para jogar um jogo como basquete, ou podemos simplesmente jogar a bola para frente e para
trás, ou posso experimentar com a bola, quicando-a em diferentes coisas. Então, eu pensaria nos
brinquedos como uma categoria mais ampla. Além disso, os brinquedos podem ser combinados. Posso
amarrar a Barbie ao meu carro de controle remoto e conduzi-la, criando assim uma nova atividade
combinando brinquedos. Os jogos tendem a ser universos isolados onde há um conjunto de regras e,
uma vez que você deixa esse universo, o conjunto de regras não tem sentido. Outra maneira de pensar
sobre isso, e esta é uma versão mais recente da mesma ideia, é que costumo pensar nos jogos que
fazemos mais como um hobby, enquanto a maioria dos jogos é pensada mais em termos de um filme ou
forma cinematográfica. Os filmes têm um começo e um fim, há um clímax, há uma história em particular,
e muitos jogos são construídos mais nesse modelo.
Nossos jogos são mais como um hobby, que você aborda de uma maneira diferente. Como com
um modelo de trem, algumas pessoas se envolvem totalmente com a paisagem e os detalhes das
falésias e das colinas. Outras pessoas entram na pequena aldeia no meio. Outras pessoas entram na
mudança nas faixas. E, às vezes, eles se complementam quando uma comunidade se constrói em torno
de um hobby. Você terá certas pessoas na comunidade que estão muito em certos aspectos do hobby e
eles têm conhecimentos que podem ensinar a outras pessoas. E você tem subespecializações dentro da
comunidade. As pessoas podem criar coisas e trocá-las, ou podem apenas compartilhar ideias. Eu tendo
a pensar nos hobbies como sendo um pouco mais baseados na comunidade do que o modelo
cinematográfico. Isso é mais uma experiência compartilhada, é uma espécie de moeda cultural: “Ah,
você viu aquele filme ontem à noite? O que você acha?"

Mas com um brinquedo de software como o SimCity, apenas uma pessoa está realmente jogando
de cada vez.

A comunidade a que me refiro agora mais do que nunca é a comunidade online. Posso ficar online e
começar a negociar estratégias com as pessoas, ou posso fazer upload da minha cidade, da minha
família ou das minhas histórias, ou posso fazer skins para o The Sims. E se alguém ficar realmente bom
nisso, pode ter uma posição na comunidade: “Ah, ele faz as melhores skins”. Então, há toda essa
comunidade na web que se desenvolve em torno do jogo, com pessoas criando coisas e compartilhando
coisas.

O que é mais possível agora do que quando SimCity foi lançado originalmente.
Quando o SimCity foi lançado, eram apenas alguns quadros de mensagens esporádicos em alguns dos
serviços online como CompuServe ou AOL posterior. Era principalmente apenas conversas de bate-papo
e coisas assim. Não havia realmente um fórum onde as pessoas pudessem se encontrar. Não era
realmente uma comunidade online muito envolvente. Mas mesmo antes de termos nosso primeiro site,
as pessoas já carregavam suas cidades para a AOL e as negociavam. Havia grandes seções com
centenas de cidades negociando. A CompuServe foi o primeiro lugar onde grandes coleções de cidades
começaram a aparecer, não muito depois do lançamento do jogo.
Machine Translated by Google

414 Capítulo 22: Entrevista: Will Wright

A maior reclamação que vi sobre SimCity, e vi isso principalmente de outros


desenvolvedores de jogos, é que, como não é um jogo e não há objetivos, não prende
muito bem a atenção do jogador.
Acho que atrai um tipo diferente de jogador. Na verdade, algumas pessoas jogam muito objetivo.
O que ele realmente faz é forçar você a determinar os objetivos. Então, quando você inicia o
SimCity, uma das coisas mais interessantes que acontece é que você tem que decidir “O que eu
quero fazer? Eu quero fazer a maior cidade possível, ou a cidade com os moradores mais felizes,
ou o maior número de parques, ou o menor crime?” Toda vez que você tem que idealizar em sua
cabeça, “O que a cidade ideal significa para mim?” Requer um jogador um pouco mais motivado.
O que você compra em certo sentido é mais replayability porque não estamos impondo nenhum
objetivo estrito em você. Poderíamos ter dito: “Faça sua cidade chegar a 10.000 pessoas em dez
anos ou você perde”. E você sempre teria que jogar dessa maneira. E haveria estratégias para
chegar lá, e as pessoas descobririam as estratégias, e seria isso. Ao deixá-lo mais aberto, as
pessoas podem jogar o jogo de várias maneiras diferentes.
E é aí que se tornou mais como um brinquedo.
As simulações em geral
oferecem um espaço de jogo
muito mais amplo para
explorar. Provavelmente não
existem duas cidades em
SimCity que sejam idênticas
e criadas por pessoas
diferentes. Considerando
que, se você olhar para um
jogo como Zelda, tenho
certeza de que existem
dezenas de milhares de jogos Zelda salvos que são idênticos.
Computacionalmente, você
pode ver isso como o espaço
de fase do sistema, ou
quantas variáveis são
SimCityName
necessárias para descrever
um estado atual do sistema.
Outra maneira de ver isso é quanta exploração criativa é permitida ao jogador. Quão único é o
seu jogo do meu jogo? Em certo sentido, isso implica um certo nível de criatividade disponível
para você. Em algumas situações isso também pode ser interpretado como quantas maneiras
diferentes existem para resolver um determinado problema. Então, se começarmos exatamente
com a mesma cidade que tem muito tráfego, há uma enorme variedade de maneiras de atacar
esse problema com sucesso. Em muitos jogos há uma porta trancada e até que você encontre
essa chave, você não conseguirá destrancá-la.

Por isso, oferece ao jogador muito mais variedade.


Há muito mais variedade, mas também, porque cada jogador pode ter uma abordagem única,
eles podem ser mais criativos. E quanto mais criatividade o jogador pode realizar em um jogo,
mais empatia ele tende a sentir com aquele jogo. Especialmente você vê isso no The Sims. Se
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 415

eles passam todo esse tempo construindo uma família e administrando suas vidas por meses, as
pessoas realmente começam a simpatizar com esses personagens porque investiram muito tempo
na criação deles. E os personagens, nesse sentido, são um reflexo não apenas de si mesmos,
mas um reflexo de sua compreensão atual do jogo. O mesmo com o SimCity. Você pode ver a
cidade de alguém no SimCity a qualquer momento, e o design da cidade é um reflexo do que eles
entendem sobre o modelo. Do seu entendimento, essa era a melhor maneira de construir uma
rede rodoviária naquele ponto.

Mas quando eles entenderem melhor o jogo...


Muda, exatamente. Você pode voltar para uma cidade antiga e dizer: “Ah, certo, foi quando eu
pensei que as rodovias realmente funcionavam bem, antes de saber que elas não funcionavam”.
Então, em certo sentido, reflete seu modelo mental do jogo.

Mas se você jogar Zelda uma segunda vez...


Seu modelo mental realmente não evolui muito. Você aprende as surpresas, mas seu modelo dos
mecanismos subjacentes não é tão diferente assim que você joga o jogo.

Estou um pouco curioso sobre o recurso de desastre no SimCity. Parece estranho que os
jogadores queiram gastar muito tempo construindo algo e depois apenas destruí-lo com
um maremoto ou um incêndio.
Sim, eu sempre achei isso meio curioso.

Você deve ter antecipado isso, no entanto, já que você o colocou no jogo desde o início.

Não, na verdade, não estava na versão original do Commodore. Mais tarde eu adicionei, no
entanto. Quando comecei a mostrar a versão do Commodore, a única coisa que tinha lá era um
trator, basicamente para apagar erros. Portanto, se você acidentalmente construiu uma estrada
ou um prédio no lugar errado, pode apagá-lo com o trator. O que descobri foi que, invariavelmente,
nos primeiros cinco minutos as pessoas descobriam a escavadeira e explodiam um prédio com
ela por acidente. E então eles ririam. E então eles iriam atacar a cidade com o trator. E eles
explodiriam todos os prédios, e eles estariam rindo muito. E isso realmente me intrigou, porque
era como se alguém encontrasse um monte de formigas e o cutucasse com um graveto para ver
o que acontecia. E eles tirariam isso de seu sistema em dez minutos, e então eles perceberiam
que a parte difícil não era destruí-lo, mas reconstruí-lo. E assim as pessoas se divertiam muito
destruindo a cidade com uma escavadeira, e então descobriam: “Uau, acabou a energia. Uau, há
um incêndio começando.” E é aí que eles começam o processo de reconstrução, e é isso que
realmente os prende. Porque eles perceberiam que a destruição era tão fácil neste jogo, foi a
criação que foi a parte mais difícil. E isso é quando todos os jogos eram sobre destruição. Depois
de ver isso acontecer com tantas pessoas, eu finalmente decidi: “Bem, eu poderia muito bem
deixá-los sair de seus sistemas, vou adicionar alguns desastres ao jogo”. E foi isso que me deu a
ideia do menu desastre.
Machine Translated by Google

416 Capítulo 22: Entrevista: Will Wright

Além disso, você teve os desastres ocorrendo aleatoriamente.

Sim, isso parecia óbvio depois que eu tinha o menu de desastre, que eles deveriam acontecer
aleatoriamente, mas eu não tinha isso originalmente.

SimEarth parece ser uma extensão lógica do SimCity. Como surgiu a ideia desse jogo?

Foi mais o meu interesse por


determinados assuntos que me levou a isso.
Eu estava muito interessado em
certas teorias, principalmente a
hipótese de Gaia, e também questões
ambientais gerais que muitas vezes
são contra-intuitivas. Achei que seria
interessante ter um modelo de um
ecossistema global. Aprendi muito
com o SimEarth. Na verdade, fiquei
muito orgulhoso da simulação do
SimEarth, e bastante decepcionado
com o design do jogo.

O que você quer dizer?


Não foi um jogo muito divertido. Na
verdade, é um modelo muito bom, e
fizemos muitas pesquisas sobre os
modelos climáticos atuais, e ainda
nunca vi ninguém fazer um modelo
integrado com uma litosfera integrada,
SimEarth
hidroesfera e atmosfera juntos assim.
E estávamos obtendo alguns efeitos no modelo que eram efeitos reais, que realmente aparecem,
que mesmo alguns dos modelos mais elaborados que o NCAR [Centro Nacional de Pesquisa
Atmosférica] faz não estavam capturando. Mas no que diz respeito ao jogo, comecei a perceber que
você pode olhar para todos os nossos jogos Sim e dividi-los em uma de duas categorias: os
econômicos e os biológicos. E, em geral, os econômicos sempre se saíram melhor.

Quais você incluiria nesse grupo?


SimCity, SimTower, SimCity 2000, The Sims e SimFarm, embora seja um pouco dos dois.
Os biológicos seriam SimAnt, SimEarth e SimLife, aproximadamente.

Por que você acha que os econômicos têm sido mais bem sucedidos?
Eu acho que tem muito a ver com quanto controle você tem sobre os sistemas. Os sistemas
biológicos tendem a ser coisas muito moles e moles que você pode fazer alguma coisa, e então ele
meio que reage e se adapta. Não está muito claro o que você fez com ele, porque ele evoluirá ao
seu redor. Considerando que nos econômicos você tem crédito muito melhor
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 417

atribuição. Quando algo der errado, você pode dizer: “Ah, é porque eu esqueci de fazer isso. Eu
deveria ter comprado um desses.” Acho que as pessoas podem raciocinar sobre seus fracassos e
atribuir crédito aos fracassos mais facilmente com os modelos econômicos. Além disso, a ideia de
que você tem dinheiro e ganha dinheiro dessa maneira e gasta dinheiro com isso parece muito
natural para as pessoas, enquanto que quando você entra em coisas complexas como diversidade,
teias alimentares e coisas assim, as pessoas simplesmente não t tem um instinto para isso.

E nada é mais frustrante do que jogar e não entender porque está perdendo...

Certo, exatamente. E assim no SimEarth as pessoas estariam jogando e de repente seu planeta
congelaria e eles não teriam ideia do porque isso aconteceu. E eu, como engenheiro de simulação,
também não podia contar a eles!

Uma coisa que eu gosto no SimEarth é como ele pode tocar tons que comunicariam
informações sobre o estado do seu planeta.
Eu sempre quis fazer mais com isso,
mas nunca consegui. Tem havido
algum trabalho interessante sobre
auralização de dados. Em vez de
visualização, você pode pegar dados
complexos e mapeá-los para o som,
porque existem certas faixas de som
que somos incrivelmente bons em
discriminar. Na verdade, houve
algum trabalho feito no Santa Fe
Research Institute nessas áreas.
Uma das coisas que eles fizeram
que foi notável foi pegar dados de
sismógrafos, de terremotos e outros
enfeites, e mapeá-los em ondas
sonoras, usando praticamente a
mesma forma de onda apenas
mapeada para uma frequência
diferente. E eles fizeram a mesma
coisa com testes nucleares
subterrâneos.

Do sismógrafo, se você observar as SimEarth


formas de onda, elas são praticamente
idênticas. É realmente difícil dizer qualquer diferença entre o teste nuclear e o terremoto. Mas
quando você mapeia para o som, há um estanho muito definido no teste nuclear, que você pode
reconhecer instantaneamente. E é interessante que, não importa como eles mapeassem as ondas
visualmente, eles não conseguiram encontrar uma maneira de discriminá-las. Mas assim que
mapearam para soar, ficou óbvio.
Machine Translated by Google

418 Capítulo 22: Entrevista: Will Wright

Então você pensou que poderia comunicar melhor ao jogador a condição de seu planeta
através do som?
Bem, foi apenas um pequeno experimento estúpido nessa direção. Em algum momento eu
gostaria de sentar e fazer direito. O que eu achei que funcionou muito bem foi onde mapearia sua
atmosfera em tons continuamente, começando no Pólo Norte e indo para o Pólo Sul. E se você
deixasse isso em segundo plano com o volume baixo, era muito útil, porque você poderia dizer as
mudanças disso muito mais cedo do que você poderia realmente vê-las refletidas nos gráficos
visuais. E assim, como uma espécie de alarme de limiar, achei que funcionou muito bem. Porque
você poderia realmente estar fazendo isso subconscientemente. Depois de um tempo, você
começa a se acostumar com essa pequena melodia e, de repente, quando a melodia muda, ela
vem ao primeiro plano de sua mente. E pode estar fazendo isso enquanto você está fazendo
outras coisas, então você não precisa ficar sentado olhando para a tela o tempo todo. Sempre
achei isso muito legal.

SimEarth é um jogo bastante sério comparado a muitos de seus outros títulos. Por que
você optou por essa abordagem?
Eu não queria fazer muita antropomorfização no jogo. Um dos preceitos do jogo é que os humanos
são a inteligência evoluída neste planeta. Poderia facilmente ter sido tricordados ou qualquer outra
coisa. Então eu estava realmente tentando evitar uma abordagem centrada no ser humano para o
jogo. E, realmente, o foco do jogo deveria estar no planeta. Estou tentando me colocar de volta na
minha mentalidade de quando trabalhei nisso, foi há muito tempo. Quero dizer, é uma daquelas
coisas que uma vez que você entra no assunto você fica fascinado por ele. Eu ainda estou até
hoje simplesmente deslumbrado com a deriva continental e coisas assim, coisas que a maioria
das pessoas acha que parece muito chata. Então é meio difícil expressar a paixão que eu tinha
por esse assunto. SimAnt foi exatamente da mesma maneira. Ainda assim, acho que as formigas
são a coisa mais legal por aí, e não acho que comuniquei isso claramente com o jogo.

SimAnt parece ser muito mais maluco que SimEarth ou até SimCity.
É difícil levar as formigas
muito a sério. Além disso,
SimAnt realmente me
surpreendeu. É a primeira vez
que fiz um jogo que atraiu um
público totalmente diferente
do que eu
esperava.
SimAnt foi realmente um
grande sucesso com crianças
de dez a treze anos. Os pais
compravam, e as crianças
jogavam, e as crianças
adoravam. Ainda hoje muitas
pessoas me dizem: “Adorei o
SimAnt; era o meu jogo
favorito.” E fez SimAnt
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 419

muito bem. Só que eu esperava que fossem mais pessoas mais velhas que apreciariam como as
formigas são incrivelmente interessantes como exemplo de inteligência distribuída. De certa forma,
eu estava tentando usar uma abordagem maluca para mostrar como as formigas são intrinsecamente
interessantes como um sistema de processamento de informações. Mas, na verdade, acabei apelando
para crianças de doze anos que adoravam brincar com formigas.

Um simulador de formigas parece ser uma premissa bem estranha para um jogo. Por que você
escolheu fazer isso?

Eu teria que explicar por que eu amo formigas. SimAnt sempre me pareceu óbvio. Eu estava sempre
me perguntando por que ninguém nunca tinha feito uma fazenda de formigas computadorizada, e eu
continuei esperando que alguém fizesse isso por anos, mas eles nunca fizeram. A hora parecia certa.
A maioria dos meus jogos foram fortemente influenciados por coisas que li. Então, o SimEarth foi meio
inspirado por James Lovelock e a hipótese Gaia. SimAnt foi definitivamente inspirado pelo trabalho de
Edward Wilson, que é como o mirmecologista. Ele escreveu muitos livros. Na verdade, ele escreveu
um livro vencedor do Prêmio Pulitzer no ano em que SimAnt foi lançado, chamado The Ants, que foi
um recurso incrível. Usamos muitos de seus livros pesadamente na construção do modelo para o
SimAnt. Na verdade, provavelmente não poderíamos ter projetado o modelo sem o trabalho dele, pois
provavelmente não poderíamos ter feito o SimEarth sem o trabalho de James Lovelock.

Você encontrou alguma resistência em fazer um jogo tão único e estranho quanto o SimAnt?

Não, de jeito nenhum. Acho que encontrei mais resistência no SimEarth porque todo mundo estava
esperando SimCity 2 e eu realmente não queria fazer SimCity 2, queria fazer algo diferente.

SimAnt parece ser muito mais um jogo do que SimCity ou SimEarth.


Acho que provavelmente o SimAnt foi minha reação exagerada ao SimEarth. Quando o SimEarth foi
lançado, percebi no final que, Deus, isso é como sentar na cabine de um 747 em queda livre.
Isso é o que parece para a maioria dos jogadores. Então eu queria que o SimAnt fosse na direção
oposta: algo não intimidante, algo alegre, algo divertido, algo onde fosse realmente claro o que deu
errado. Embora eu nunca pudesse dizer o quão bem sucedido foi, uma das coisas que eu realmente
queria fazer com o SimAnt era ter a ideia de que você tem essa luz, fácil de entrar no jogo, mas você
fica cada vez mais sério sobre isso. É por isso que tínhamos esse pequeno banco de dados online
sobre formigas, a pequena enciclopédia. E a ideia era fazer com que as pessoas se interessassem o
suficiente, apenas através do jogo, para que elas realmente começassem a ler esta pequena
enciclopédia e muito disso pertenceria à jogabilidade. Então você pode realmente aprender novas
estratégias para o jogo enquanto ao mesmo tempo absorve todas essas informações legais sobre
formigas.

O jogo me lembra um jogo de guerra muito estranho.


É como um jogo RTS. No SimAnt fizemos algumas coisas malucas. O SimAnt , em certo sentido, era
muito experimental. Havia algumas coisas estranhas lá, como o botão misterioso. Na interface, há um
botão que tem esse grande ponto de interrogação, e é o botão misterioso. Toda vez que você
pressiona esse botão, algo muito estranho acontece,
Machine Translated by Google

420 Capítulo 22: Entrevista: Will Wright

e geralmente é diferente.
Há trinta coisas diferentes
que podem acontecer, e são
coisas totalmente estranhas.
Tipo, todas as suas formigas
morrem. Ou suas formigas dobram.
Ou uma tempestade
gigantesca começa. Ou você
muda de lado. Coisas
totalmente não lineares e
aleatórias acontecem quando
você clica nesse botão.

SimAnt

Mais ou menos como os desastres de SimCity levados ao extremo...


É quase desastres de nível meta. Coisas que de repente apagariam seu jogo ou lhe dariam o
dobro do número de seus oponentes. Como os desastres em SimCity, o que muitas pessoas
fariam é jogar e jogar e jogar por horas e quando estivessem prontos para parar, pouco antes de
desistirem, eles incendiariam a cidade apenas para o inferno. No SimAnt , as pessoas jogavam o
jogo por um tempo e, pouco antes de desistir, apertavam o botão misterioso para ver o que ele
faria hoje.

Seu próximo projeto foi SimCity 2000. Como isso aconteceu?


Bem, na verdade, antes de
fazer isso, passei cerca de
seis meses trabalhando na
primeira encarnação do The
Sims. Na verdade, eu tinha
feito um pequeno protótipo e
alguma codificação. Nesse
ponto, Fred Haslam estava
trabalhando em SimCity 2000.
Ele era o cara com quem
acabei fazendo e que tinha
feito SimEarth comigo.
SimCity 2000 não estava indo
tão rápido quanto todo mundo
gostaria, e eles não gostaram
dos gráficos e todas essas
SimCity 2000
coisas, então eu fui arrastado
para ele. Neste ponto, a empresa estava realmente dependendo de SimCity 2000 ser um best-
seller e tudo isso, então basicamente larguei tudo o que estava fazendo no The Sims e mergulhei
com Fred. E, de fato, peguei o shell de código que havia escrito para o The Sims, e
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 421

na verdade, acabou usando-o para SimCity 2000. Na verdade, se você voltar e olhar para o código-
fonte do SimCity 2000, até hoje as rotinas de desenho dizem DrawHouse e DrawYard, porque era
o shell de código original do The Sims. Então eu entrei nisso, e Fred e eu basicamente começamos
do zero. Fred e eu trabalhamos muito bem juntos, e fizemos isso em tempo quase recorde, para
essa complexidade de um jogo. Fizemos isso em cerca de doze meses.

Então a ideia era melhorar o que funcionou bem no SimCity original?


Aproximadamente. Além disso, naquele momento, tínhamos centenas e centenas de cartas de fãs
dizendo: “Ah, você deveria fazer SimCity novamente e adicionar isso, adicionar aquilo e adicionar
o outro”. E eu li todas aquelas cartas. E havia algumas coisas que eram muito comuns. E então
adicionamos as sugestões realmente comuns e óbvias: altitude, montanhas, um sistema de água,
mais tipos de estradas, esse tipo de coisa. Além disso, eram todas as coisas que eu gostaria de
ter feito em SimCity que, agora que os computadores eram mais rápidos e os gráficos eram
melhores, nós podíamos fazer.

Então, comparado ao SimAnt, parece muito menos maluco. Isso foi porque você estava
trabalhando com a franquia de prêmios da empresa?
Foi maluco o suficiente, eu acho, à sua maneira. Tinha a esperada loucura de SimCity , além de
muitas coisas que não estavam no SimCity original. Tínhamos muitas coisas escondidas no SimCity
2000 que as pessoas não perceberam por muito tempo que ajudaram a sua longevidade. Lá estava
o Monstro do Lago Ness. Ele só aparecia a cada dois ou três meses em que você jogava o jogo e
só aparecia por cerca de quatro segundos. E então havia muitos rumores sobre isso. Dois meses
após o lançamento do jogo, as pessoas começaram a dizer que tinham visto esse monstro na
água, e a maioria das pessoas não acreditou neles porque era muito raro. E foi quase um ano
depois de lançarmos o jogo que alguém conseguiu tirar uma captura de tela dele. E então você
teve o Capitão Hero.
Somente sob certas condições estranhas você conseguiria esse super-herói que voaria e
combateria seus desastres por você. Então tínhamos muitas coisas assim escondidas no jogo. O
SimCity original não tinha esse nível de profundidade.

Você se sentiu constrangido já que estava apenas fazendo uma sequência?


Na verdade, não. Nesse ponto eu estava mais no modo de gerenciamento de projetos. Eu tinha
uma ideia bem clara de qual seria o design, já que estávamos basicamente fazendo uma sequência,
o que é sempre mais fácil. Era mais apenas garantir que a engenharia fosse boa e que o
desempenho fosse decente. Era um pedaço de código bem apertado. O SimCity 2000 original
rodava em 1,3 megas em um Mac. Então, para o que era, era realmente muito difícil trabalhar
naquela pequena memória.

O SimCopter foi seu próximo projeto?


Isso veio um pouco depois, já que eu estava trabalhando no The Sims em segundo plano
enquanto trabalhava no SimCopter. Então, naquele momento eu tinha um programador dedicado
ao The Sims. Na verdade, no SimCopter, o comportamento das pessoas que andavam por aí
estava usando uma forma muito antiga de Edith, que era a linguagem de programação que
desenvolvemos para o The Sims. Muitas pessoas na Maxis decidiram que realmente queríamos
Machine Translated by Google

422 Capítulo 22: Entrevista: Will Wright

tente algo em que você


estava fazendo um jogo 3D
dentro do SimCity. Então
essa era a premissa original
do SimCopter. Eles me
perguntaram: “Você pode
criar um jogo onde você está
fazendo algo em 3D no
SimCity? Seja o que for,
dirigindo por aí, voando por
aí, seja o que for.” Então
SimCopter foi o design que
eu criei. Foi o primeiro jogo
em 3D que fiz e, na verdade,
o primeiro jogo em 3D que
muitos da nossa equipe SimCopter
fizeram também. Então
estávamos definitivamente subindo uma curva de aprendizado alguns anos atrás de muitas outras pessoas.
O maior problema com o SimCopter eu acho que não estava no design do jogo, estava nos
gráficos. Eles eram realmente abaixo do padrão para quando foi lançado.

Gostou do jeito que ficou? Ou você não se importou tanto porque estava mais interessado
em trabalhar no The Sims?
Bem, eu estava realmente me concentrando no SimCopter. Não tínhamos uma equipe grande o
suficiente, basicamente tínhamos quatro pessoas fazendo isso. E para fazer um produto 3D
naquele momento, isso não era suficiente. Então, eu senti que estava realmente com recursos
limitados no produto, além disso, tínhamos esse cronograma difícil que absolutamente
precisávamos fazer. Por várias razões, não podíamos perder o Natal, o que significava que
realmente não podíamos mirar muito alto. Se tivéssemos mais seis a oito meses para trabalhar
nisso, graficamente acho que teria ficado muito, muito melhor. A jogabilidade e afinação eu
ainda estou muito feliz. Poderia ter usado mais algumas missões. Mas havia algo muito legal
em ter uma cidade que você construiu em SimCity por muitas horas e, de repente, estar nela em
3D e ver as pessoas e os carros e voar ao redor dela. Havia uma qualidade realmente sinistra
nisso. Funcionou bem.

Agora, você não estava envolvido com SimCity 3000. Você estava apenas esgotado com
a ideia de fazer outro simulador de cidade?
Sim, é mais ou menos isso. Você acertou em cheio com isso. Era uma piada em torno da Maxis
que sempre que a equipe do SimCity vinha me pedir conselhos, eu corria. Eles finalmente
desistiram. Você sabe, o dia em que lançaram o SimCity 3000 foi um dos dias mais felizes da
minha vida. Eles provaram que temos uma equipe dentro da Maxis que sabe construir SimCity
sem o meu envolvimento. E antes, quando 2000 chegou, não havia mais ninguém a quem
recorrer. Eu tive que trabalhar nisso ou simplesmente não ia acontecer. Considerando que agora
temos a experiência interna para fazer SimCity, uma equipe realmente grande e talentosa. A
franquia está em boas mãos do meu ponto de vista.
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 423

Então você ficou satisfeito por não ter que se envolver com isso.
Isso é um eufemismo. Apenas fazer uma sequência para mim foi excruciante. Uma vez que eu
entrei nele, eu me diverti com SimCity 2000. Mas há tantos jogos que não foram feitos em tudo
que eu gostaria de fazer, ao invés de voltar e refazer jogos que eu já fiz. Provavelmente, minha
parte favorita de projetar um jogo é pesquisar e aprender um novo assunto, e mergulhar
totalmente nele. E passei muito tempo lendo sobre dinâmica urbana e planejamento urbano.
Ainda amo o assunto, mas estou meio esgotado com a pesquisa nessa área. Há tantos outros
assuntos que eu adoraria mergulhar e aprender agora.

Eu tenho uma pergunta sobre SimCity 3000. Quando eu vi originalmente um protótipo


para o jogo, era totalmente 3D. Mas quando foi lançado, voltou ao ponto de vista
isométrico clássico. Por que isso mudou tão radicalmente?
Bem, por várias razões, e
foi uma decisão muito difícil
de tomar. Em retrospecto,
estou convencido de que foi
a decisão certa.
Parte disso tinha a ver com
a interface do usuário. Muitas
pessoas que jogam SimCity,
que tendem a ser um grupo
muito mais amplo, muitos
dos jogadores mais casuais,
têm dificuldade em se
movimentar e controlar uma
era de câmeras 3D. E quando
você coloca em cima disso a
ideia de editar um sistema e SimCity 3000
depois dar a eles uma
câmera tridimensional, pega o que costumava ser uma coisa muito simples, tipo Lego, e o
transforma em um AutoCAD. "O que estou olhando? Ah, entendo, estou de frente para o prédio
a cinco centímetros de distância. Torna-se esse tipo de experiência. Então isso fazia parte. A
outra parte era a tecnologia. Sem restrições muito severas sobre o que você poderia construir,
simplesmente não poderíamos ter uma taxa de quadros decente e ter o nível de detalhe que
poderíamos ter em um ponto de vista isométrico. Estamos chegando ao ponto hoje em que é praticame
Mas você lida com limitações reais de RAM de memória de textura e limitações poligonais
reais. Na época em que estávamos trabalhando nisso, não havia pessoas suficientes com
hardware 3D para exigir isso. Então teríamos que ter uma solução de software que fosse
aceitável. Havia muitas razões, mas eu diria que as duas principais foram desempenho e
interface do usuário.

Então você começou o The Sims logo depois de terminar o SimAnt.


Há muito tempo, sim. Eu também tive alguns projetos que comecei e depois matei ao longo do
caminho.
Machine Translated by Google

424 Capítulo 22: Entrevista: Will Wright

Alguma coisa de interesse?


Bem, eu tinha o projeto Z. Por um tempo lá eu tive o projeto X, Y e Z. X foi o que nós chamamos de
The Sims por mais tempo. Y era SimCopter. Para Z, eu queria fazer uma simulação do Hindenburg.
E eu realmente pesquisei isso e realmente gostei. Essa foi uma ideia muito estranha. Mas era uma
combinação de Myst e um simulador de vôo, se você pode imaginar isso. Seria um Hindenburg
virtual muito elaborado, lindamente e meticulosamente desenhado que você poderia percorrer e
explorar, cada pequeno canto e recanto. Mas também seria completamente funcional, então cada
válvula que você acionasse teria o efeito real, e cada chave que você acionasse faria o que a chave
real fazia.
E você se encontraria de repente, no Hindenburg, sobre o Atlântico, indo para Lakehurst. Você seria
o único a bordo, você estaria neste navio fantasma.
Basicamente, a história continuaria se repetindo e, se você não fizesse a coisa certa, sempre
explodiria quando chegasse a Lakehurst. E então seria uma espécie de jogo de mistério. E nós
íamos pegar as dez ou vinte principais teorias sobre por que o Hindenburg explodiu, existem algumas
delas na verdade. E toda vez que você inicia um novo jogo, ele escolhe um desses aleatoriamente.
Então, toda vez que você jogasse o jogo, não seria a mesma razão pela qual ele explodiu. Portanto,
haveria um conjunto totalmente diferente de coisas que você teria que fazer para evitá-lo. Na
verdade, você também pode ir até a cabine de controle e pilotar a coisa, você pode voar para
diferentes áreas. Na verdade, você teria que aprender a pilotar um zepelim do zero, o que para uma
pessoa é bastante difícil.

Isso é realmente muito diferente de qualquer um dos seus outros jogos.


Sim. Você sabe o que realmente matou mais esse projeto, a razão pela qual eu realmente desisti
dele? Parece um motivo muito pequeno, mas foi o fato de o Hindenburg ter uma suástica na cauda.
E mesmo que tivéssemos tirado a suástica, muitas pessoas têm essa associação em sua mente do
Hindenburg como um símbolo nazista. O que é lamentável, porque o cara que projetou e construiu o
Hindenburg foi um dos adversários mais ferozes dos nazistas, e ele realmente teve que assinar esse
pacto com o diabo para construir a coisa. E assim os nazistas realmente pagaram por sua construção
final. Então, de qualquer forma, esse foi um dos meus designs de jogo fracassados.

Então, The Sims permaneceu praticamente o mesmo durante todo o seu desenvolvimento?
Definitivamente, passou por uma mudança de foco, da arquitetura para mais sobre as pessoas, mas
não muito importante. Na verdade, descobri uma fita, pouco antes de terminarmos The Sims, que eu
tinha esquecido que tinha. Era uma fita de um dos primeiros grupos de foco que fizemos em 1993.
E na fita do grupo de foco, o moderador descreve o conceito que eu escrevi do The Sims, e é
notavelmente próximo do que acabamos enviando.

O grupo focal gostou da ideia?


Não, na verdade, essa foi provavelmente a experiência de grupo focal mais negativa que já vi. Na
verdade, foi bastante notável. Eles o odiavam universalmente.

Foi por isso que você não conseguiu pessoal para o projeto no início?
Sim, isso era parte disso, isso certamente não ajudou. Não foi minha ideia ter o grupo focal em
primeiro lugar. Nosso pessoal de marketing disse: "Ei, vamos ter um grupo de foco e
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 425

certifique-se disso.” É claro que, quando todos no grupo de foco disseram: “Não há como eu
comprar isso”, isso tornou um pouco mais difícil para mim vender a ideia.

Então, como você finalmente teve a chance de fazê-lo?


Eu convenci todo mundo a me dar pelo menos um programador para trabalhar nisso em segundo
plano. Era um cara chamado Jamie Doornbos, que viria a ser o programador principal. Um cara
muito brilhante, jovem de Stanford, um bom estudante de ciências. Era ele que estava
desenvolvendo o modelo de comportamento comigo em segundo plano. Estávamos tentando
descobrir como poderíamos simular um sistema aberto em que os comportamentos fossem
expansíveis e eles tivessem o nível de inteligência que precisaríamos para o jogo, para que eles
pudessem basicamente viver toda a vida em casa e nós pudéssemos simulá-lo de forma razoável.
Então Jamie e eu provavelmente passamos um ano e meio apenas trabalhando no modelo de
comportamento, como um pequeno projeto de pesquisa. Em algum momento, começou realmente
a funcionar, e realmente parece muito bom. E foi nesse ponto que comecei a ter mais pessoas na
equipe. E mesmo assim, tive que lutar, chutar e lutar por cada pessoa que consegui.

Após seu sucesso com SimCity, é surpreendente que ninguém confie em você.
Mas, na verdade, é engraçado, porque recentemente comecei em algumas outras coisas do tipo
back-burner. O último que fiz, comecei a contar essa ideia para as pessoas, e todo mundo disse:
“Isso é ótimo, isso é ótimo, vá fazer, aqui está um programador”. E, em certo sentido, foi
decepcionante. É muito mais satisfatório quando todo mundo diz: “Isso é uma merda, de jeito
nenhum vai dar certo” e então você vai refutá-los, em vez de todo mundo dizer: “Ah, isso vai ser
ótimo” e então se não der certo para ser grande . . . Então, em certo sentido, sinto falta da luta.

Qual foi sua inspiração original para The Sims?


Acho que a inspiração original para The Sims veio de um livro chamado A Pattern Language ,
escrito por um professor de arquitetura de Berkeley chamado Christopher Alexander. É um livro
muito interessante, meio polêmico no mundo da arquitetura. É quase como a versão ocidental do
feng shui. Ele tem duzentas e cinquenta e seis regras de design, e cada uma examina algum
aspecto do comportamento humano e então deriva uma regra de design que você pode usar. E as
primeiras regras são onde as cidades devem ser colocadas no campo. À medida que você sobe
as regras, para regra dez ou quinze, começa a falar sobre o design das cidades e bairros e os
sistemas de circulação dentro das cidades. E então você se move

Os Sims
Machine Translated by Google

426 Capítulo 22: Entrevista: Will Wright

até as regras mais altas e é sobre como projetar um quarteirão de bairro e onde você deve colocar
as escolas e centros de recreação. E então ele se aproxima, e é sobre como você deve colocar sua
casa no quintal e como você faz as áreas privadas e públicas da casa. E à medida que você sobe
para o nível mais alto, é sobre onde você deve colocar seus plantadores de flores no peitoril da
janela e como colocar um banco de jardim. Assim, as regras passam por todas essas escalas
diferentes, mas todas são baseadas em aspectos do comportamento humano.
E eles tentam extrapolar. O fato de gostarmos de ter espaços privados, e muitas de nossas
atividades em casa consideramos atividades privadas, e outras são atividades públicas.
E assim o design da casa deve refletir isso. Deve haver algumas áreas claramente privadas na casa
e áreas mais claramente públicas. Então, é assim que ele olha para um aspecto do comportamento
humano e então extrapola uma regra de design a partir dele. E então ele dá exemplos de como
você pode implementar essa regra de design. Então, basicamente, ele está apresentando uma
proposta para uma gramática do design. E muitas pessoas discordam da gramática específica que
ele criou, mas sempre achei sua tentativa muito nobre.

Então você pensou que poderia criar uma simulação que simulasse as regras dele.

Não era nem mesmo suas regras que eu estava atrás. O que eu procurava era tentar obter essa
ligação entre o comportamento humano e o design. Se você olhar para a maioria das revistas de
arquitetura hoje em dia, elas são sobre quais texturas estão neste ano, quais cores, quais tecidos
ou quais estilos de decoração. Eles têm muito pouco a ver com o comportamento humano. A
arquitetura costumava ser sobre como você projeta espaços para facilitar as ações, tarefas e
atividades humanas. Ele escreveu um livro anterior chamado Notas sobre a Síntese da Forma , que
deixou o ponto um pouco mais claro. Na verdade, ele fez um monte de design do terceiro mundo,
onde ele iria estudar essas tribos ou culturas, pessoas bastante primitivas, e observar suas
atividades. Quais atividades eles fizeram juntos e quais grupos de pessoas colaboraram nessas
atividades. E a partir disso ele conseguiu extrapolar algumas regras de design para sua cultura.
Como suas casas devem ser dispostas e como suas cidades e aldeias devem ser organizadas. E
eu apenas pensei que era uma abordagem muito refrescante para a arquitetura, voltando às razões
funcionais e requisitos da arquitetura em oposição ao tipo de abordagem estética e “arquitetura
como arte moderna”. Se você olhar para muitos desses livros de arquitetura moderna, verá essas
casas lá nas quais eu não gostaria de morar. Elas têm uma aparência muito legal, e parecem muito
bonitas, especialmente quando estão vazias e são tão rígido. Mas eu não conseguia me imaginar
morando neles. Há essa grande desconexão.

Então originalmente tinha que fazer mais com a construção de sua casa?
Tinha mais a ver com permitir o comportamento e a interação por meio do design. E, em certo
sentido, ainda mantém isso. Apenas com não exatamente a mesma quantidade de foco.

Quando joguei, fiquei muito mais envolvido nas interações interpessoais.

Sim, acho que foi aí que o foco realmente mudou. Não percebemos o quão envolvente seria a parte
social do jogo. O conceito original era que você estava tentando manter essa família feliz em casa.
A ideia de que você teria esses visitantes que você
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 427

desenvolver esses relacionamentos de longo prazo foi definitivamente um conceito posterior.

Então isso cresceu organicamente de outros aspectos do jogo?

Tinha muito a ver com o sucesso do nosso modelo comportamental, que estava funcionando melhor do que
imaginávamos. Ou, pelo menos, a interpretação das pessoas do nosso modelo comportamental.
O que quer dizer que estávamos enganando-os melhor do que pensávamos que faríamos.

Então você está dizendo que as pessoas percebem o modelo comportamental como mais
impressionante do que realmente é?
Na verdade, isso também se
tornou um grande foco do design.
Houve outro livro que se tornou
muito influente mais tarde no
design, um livro chamado
Understanding Comics , de Scott
McCloud.
E ele faz alguns pontos muito
bons que são muito aplicáveis
ao design de jogos.
Uma das que mais utilizamos é
a ideia de que a atividade é uma
colaboração, neste caso entre o
game designer e o jogador.

Os Sims
E também que o nível de
abstração que você apresenta ao jogador dá a eles uma pista muito significativa de quanto disso eles devem
modelar em sua cabeça versus no computador. Então, de fato, quando alguém está jogando The Sims e
interpretando a experiência, eles podem não perceber, mas estão fazendo muito da modelagem em sua
cabeça, não no computador. O computador vai ficar lá e vai aparecer essa conversa sem sentido. A maioria
das pessoas vai realmente sentar lá e interpretar grosseiramente o que está dizendo. Eles dirão: “Ah,
entendo, ele está chateado porque ela não levou o lixo para fora”. E eles estarão simulando em suas
cabeças o outro lado do modelo com um nível de detalhes maior do que o computador jamais poderia.

As pessoas não podem deixar de olhar para uma sequência de eventos e sobrepor algum tipo de narrativa
a ela.
Percebemos isso um tempo atrás, então realmente decidimos fazer uso disso. E então, quando
projetamos suas conversas e a linguagem icônica e até seus gestos, tentamos deixá-los abertos à
interpretação para que os jogadores possam entrar e ter interpretações bastante criativas do que estão
vendo na tela. E então, mais tarde, estávamos assistindo as pessoas jogando o jogo nas primeiras sessões
de teste e algumas das narrativas que eles estavam criando eram tão divertidas e divertidas que foi isso que
nos deu a ideia de colocar o recurso de scrapbook. Com isso, eles podem realmente gravar sua narrativa
particular do que está acontecendo e depois compartilhá-la.
Machine Translated by Google

428 Capítulo 22: Entrevista: Will Wright

Você achou que The Sims seria um sucesso tão grande?


Eu sempre pensei que The Sims parecia ter muito mais potencial do que SimCity já teve.
Eu nunca estive tão confiante sobre SimCity. E eu não sei por que eu estava tão confiante sobre
The Sims, mas só porque ele se aproximava muito da natureza humana, eu sempre suspeitei que
as pessoas gostariam de jogar com outras pessoas, o mais próximo possível. E a maioria dos
jogos não permite que você se aproxime tanto das pessoas, ou, se o fazem, é em um formato
linear e muito roteirizado. Não está em um formato aberto.

Normalmente é mais como um Zelda , onde você pode conversar com esse personagem,
mas eles sempre dizem a mesma coisa.
Exatamente, e instantaneamente o modelo quebra na sua cabeça e você diz: “Ah, é apenas um
robô e está repetindo a mesma coisa várias vezes”. E se pudéssemos mantê-lo em aberto, e não
tentássemos nos aproximar muito das pessoas e deixar a interpretação lá, as pessoas poderiam
razoavelmente acreditar que eram pequenas criaturas com desejos e relacionamentos e todas
essas coisas.

Entre todos os elogios, vi muitas pequenas reclamações sobre o jogo. Como se não
houvesse fins de semana, ou você nunca pudesse brincar com seus sims fora do ambiente
doméstico. Você costuma ouvir essas reclamações sobre seus jogos?
Isso acontece muito. Provavelmente aconteceu mais com The Sims do que com qualquer outro
título em que trabalhei, provavelmente porque mais pessoas se consideram especialistas no
assunto do que em formigas ou termodinâmica de planetas. É difícil olhar para o SimEarth e dizer:
“Bem, eu realmente não acho que as correntes oceânicas tenham uma taxa de transferência
térmica tão grande com a atmosfera”. Mas qualquer um pode olhar para o The Sims e dizer: “Bem,
não acho que iríamos dar um tapa nela por isso”. Somos mais especialistas nesse campo, então
isso é meio natural. A outra coisa, porém, é que, a julgar pelas coisas que eles sentem que estão
perdendo, as pessoas não percebem o quanto está realmente clicando e funcionando. Porque
havia tantas centenas de coisas que precisavam funcionar antes de reclamarem dos fins de
semana. Para os fins de semana serem a grande preocupação, isso implica que muitas outras
coisas pelas quais estávamos suando estão realmente funcionando.

Decidir o que incluir e o que deixar de fora foi uma função de quanto tempo você teve para
completar o jogo?
Isso foi certamente uma grande parte disso, embora sempre que chegássemos a uma dessas
situações tentássemos deixar o jogo em aberto para que pudéssemos expandi-lo nessa direção
com um download. Não demonstramos totalmente o quanto podemos expandir o jogo com objetos
baixados. Além disso, é fácil para as pessoas dizerem que querem fins de semana, mas não estão
pensando em todas as ramificações disso, o que fizemos. E a maioria das pessoas, quando eu
sento e explico por que não temos fins de semana, de repente eles percebem por que não e dizem:
“Ah, você está certo, acho que não quero fins de semana”.

Então, como você decidiu quais limites colocar na simulação?


Isso era muito uma questão de recursos. Poderíamos ter colocado a boate e o trabalho e tudo isso
e acrescentado mais um ano ao desenvolvimento do jogo. Nesse ponto, teria passado do seu
melhor tempo. Outra coisa é que poderíamos ter feito tudo isso em um
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 429

agenda, mas fez tudo muito pior. Achei que preferia fazer a casa muito bem do que fazer tudo mal. O
que eu acho que é o que teria acontecido, realisticamente, sabendo como os projetos vão.

Então, seu conselho para os designers de jogos é focar seus projetos?


Você também precisa entender qual será o núcleo da diversão no jogo.
E se você está adicionando essas coisas apenas para colocar mais marcadores na parte de trás da
caixa, mas não está realmente tornando o jogo mais divertido, é um esforço totalmente desperdiçado.
Há um velho ditado japonês que eu amo, e é sobre jardinagem: “Seu jardim não está completo até
que não haja mais nada que você possa remover”.

Então você acha que esse ditado se aplica ao design de jogos?


Ah, muito. Se você olhar para a quantidade de coisas que tiramos deste jogo, provavelmente o
surpreenderia. Como as necessidades, por exemplo. Você sabe, nós temos as oito necessidades.
Em algum momento eram doze, depois dez, e então finalmente oito. Na verdade, estávamos muito
mais preocupados em simplificar o jogo do que em expandi-lo. E nossa interface. Nossa interface
passou por onze iterações — redesenhos totais e completos da interface. E cada um acabou soltando
um botão aqui, um botão ali, ou encontramos formas de combinar a funcionalidade. Eu realmente
pensei que The Sims, se fosse acessível, atrairia um público muito amplo, mas tinha que ser
incrivelmente acessível, através da interface. Não poderia ser sua interface de jogo de estratégia
padrão, ou desligaríamos a maior parte de nossa base de clientes. Então, saímos do nosso caminho
para fazer essa interface. A maioria das pessoas nem percebe como as partes são elegantes. Quer
dizer, partes disso ainda são bastante desajeitadas, mas há algumas coisas que realmente suou, que
são pequenos, pequenos detalhes, mas acabaram fazendo uma enorme diferença. Muito disso são
pequenas coisas que se somam, como os menus de tortas. Você pode clicar, arrastar e soltar um
objeto ou clicar, soltar, mover e clicar novamente. Portanto, estamos basicamente espelhando a
funcionalidade do Windows com a qual a maioria das pessoas está acostumada.

Tendo a cabeça 3D subindo e respondendo, olhe na direção em que você move o mouse. O
fato de que cada pedaço de texto na interface tem ajuda incorporada. Muitas pessoas não percebem
isso, mas você pode rolar qualquer palavra para baixo nessa interface, e ela será realmente destacada
à medida que você rolar sobre ela, e se você clicar nela, aparecerá uma explicação bastante elaborada
do que é . Então fizemos muita ajuda incorporada. E coisas assim só se somam. Não há nada que
realmente faça funcionar. Provavelmente rodamos uma centena de testadores de jogo por essa coisa
no último ano de desenvolvimento. E essas eram coisas em que um dos outros designers ou eu
sentávamos e os observávamos tocar por uma hora e escrever notas sobre todos os erros que
cometeram e equívocos que tiveram. Então fizemos muitos testes na interface. Se cinco pessoas
cometeram o mesmo erro conceitual que você rotaciona fazendo isso, ou elas estavam tentando
arrastar um objeto fazendo aquilo, então tentaríamos descobrir uma maneira de resolver isso sem
quebrá-lo para todos os outros. pessoas.
Machine Translated by Google

430 Capítulo 22: Entrevista: Will Wright

Você sempre teve a interface icônica para seus jogos, mas cada interface é um pouco
diferente da anterior. Por que é que?
É muito difícil fazer uma
interface fora de contexto.
Você realmente precisa dar
uma olhada no que o jogo
precisa e como você vai
interagir com as coisas no
jogo. Isso vai determinar muito
da sua interface. Você também
precisa dar uma olhada no
ambiente em que está vivendo,
ou seja, o que os outros
aplicativos e os outros jogos
estão fazendo? Houve coisas
que fizemos no The Sims para
manter a consistência com o
SimCity 3000. Como a rolagem
Os Sims
do botão direito, onde você
clica com o botão direito do mouse e arrasta, e a rolagem da borda - tentamos espelhar o SimCity
lá. E em geral você apenas aprende. Acho que cada interface em que trabalhei para um jogo foi
melhor que a anterior. Além disso, como os jogos atingem um público cada vez mais amplo de
pessoas mais casuais, isso coloca ainda mais requisitos nessa interface. Só tem que ser muito
mais fácil se você vai capturar essas pessoas. Costumava ser gente de computador hard-core
jogando esses jogos, e eles toleravam qualquer coisa. Agora são as pessoas que são muito mais
casuais, e se acharem a interface frustrante em dois minutos, vão largar o jogo.

Em geral, eu diria que os designers de PC, inclusive eu, ainda estão alcançando os
desenvolvedores de console. Isso é algo que o pessoal do console aprendeu há muito tempo na
Nintendo e na Sega porque eles estavam lidando com um público casual e amplo, principalmente
crianças mais novas. Portanto, eles tinham interfaces muito mais acessíveis, simples e
compreensíveis muito antes de nós termos do lado do computador.

Para The Sims você tem um mundo híbrido com personagens 3D andando por um mundo
isométrico. Isso foi pelos mesmos motivos do SimCity 3000?
Sim, desde a edição e construção da casa e tudo isso, se tivéssemos uma câmera 3D completa e
tudo isso, acho que não teria como ter sido tão fácil quanto agora. Também teríamos alguns
problemas reais de carga gráfica. Não poderíamos obter os detalhes que tínhamos nos objetos se
fossem geometria.

Houve alguma pressão para fazer o jogo em 3D já que tantos outros jogos eram em 3D?

Cerca de três anos atrás, parecia que tudo estava indo para 3D, e se você não fosse 3D, você
estava simplesmente morto. Em algum momento esse tipo de histeria passou e as pessoas
começaram a olhar para os jogos mais vendidos e perceber, ei, você ainda tinha Age of Empires, SimCity e
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 431

todos esses jogos muito bons de venda que não eram 3D. Na verdade, se você olhar para os
jogos mais vendidos, uma minoria deles são 3D. Então agora a ideia de que os consumidores
aceitariam um jogo não 3D é um dado adquirido. Não existe essa ideia de que tem que ser 3D
se faz sentido ou não.

Gostei muito da maneira como os personagens falam em The Sims. Isso foi uma limitação
de espaço em disco, ou você seguiu o jargão para deixar aberto à interpretação do
jogador?
Mesmo se tivéssemos cinco CDs de voz gravada, essas coisas ficariam muito repetitivas. E
minha maior preocupação era que não ficasse repetitivo e que você não ouvisse a mesma corda
repetidamente. Na verdade, gravamos centenas e centenas de cordas de voz, cada uma com
diferentes nuances emocionais. E decidimos que a voz era inteiramente para o conteúdo
emocional: você poderia dizer se a pessoa estava paquerando, chateada, descontraída ou
cansada pelo tom da voz e pela cadência. Mas a maneira como isso funciona é que, porque
você não entende a semântica, porque você não está ouvindo as palavras, você naturalmente
senta lá e imagina as palavras com bastante fluidez. Mas o contexto emocional você consegue
com muita facilidade. Você sabe: “Uau, ela parece chateada.”
Então, sim, estou realmente muito feliz com a maneira como isso funcionou. Você os ouve
falando repetidamente, mas é muito difícil ouvir as repetições exatas. Porque na verdade você
está ouvindo muitas formas de onda se repetirem eventualmente. Mas, na verdade, projetamos
essa linguagem para que fosse muito difícil de detectar. E esse foi um processo longo e lento,
descobrir como fazer isso. Originalmente, estávamos planejando usar uma linguagem real, mas
uma muito obscura que as pessoas não entendiam. E fizemos muitos testes com navajo e
estoniano. E eles ainda eram muito reconhecíveis. Mesmo que você não entendesse o idioma,
você ainda reconheceria isso: “Ah, isso foi o que acabei de ouvir”. Muito disso tinha a ver com o
número de consoantes duras em um enunciado, e também com a cadência e a velocidade em
que estava indo. Foi um longo processo para descobrir isso.

Parece notavelmente progressivo para um jogo incluir as possibilidades homossexuais


que The Sims inclui. Por que você escolheu permitir isso?
Uma das coisas que sabíamos
que muitas pessoas fariam
com este jogo era modelar
sua família real. E a última
coisa que eu queria fazer era
dizer: “Oh, não vamos
reconhecer sua família”.

Então, queríamos dar às


pessoas uma maneira
razoável e bastante aberta
de construir qualquer família
de origem, que pudessem
imaginar ou com quem
quisessem brincar. Mas
estávamos lidando com uma questão ética e moral
Os Sims
Machine Translated by Google

432 Capítulo 22: Entrevista: Will Wright

campo minado que tivemos que enfiar com muito cuidado. E havia muitas coisas que deixamos de
fora do jogo de propósito. E havia muitas coisas que realmente queríamos ter no jogo em vários
níveis, e a homossexualidade era uma das coisas que realmente queríamos ter no jogo, de alguma
forma.

Que tipo de coisas você deixou de fora de propósito?


Houve algumas coisas que se tornaram um pouco problemáticas e fizemos pequenas modificações.
Uma delas foi a questão da violência doméstica. Quando os personagens ficam chateados, eles
podem se esbofetear. Não sei se você percebeu, mas existem dois tipos de tapa.
Há um tapa onde eles levantam o braço para trás e depois batem e é como se estivessem quebrando
a mandíbula. E há outro que é uma espécie de tapa insultante do Exército Britânico. Sempre que você
tem pessoas do mesmo sexo batendo, elas usam o tapa bem forte, como um homem batendo em
outro homem ou uma mulher batendo em outra mulher. Mas sempre que você tem um homem batendo
em uma mulher ou uma mulher batendo em um homem, eles usam o tapa educado. Porque antes,
quando a gente tinha o tapa no braço, e você tinha o marido batendo na mulher, isso incomodava
muita gente, só do ponto de vista da violência doméstica. E essa foi uma daquelas coisas em que
estávamos no limite e sendo muito cuidadosos, mas sem perder o recurso.

Por isso, retém o conteúdo emocional sem ser muito violento.


Certo, e isso não faz as pessoas pensarem em abuso doméstico sério. E, de fato, foi engraçado,
porque também temos uma interação de ataque. Se eles realmente não gostam um do outro, eles
podem entrar em uma briga. Mas como fizemos a briga como uma briga de desenho animado – há
essa grande nuvem e você vê braços e pernas saindo – ninguém teve nenhum problema com isso.
Mesmo que fosse um homem e uma mulher, sempre foi tão caricatural que nunca foi um problema
comparado ao tapa. Havia certos lugares que simplesmente não queríamos ir com o jogo. Por
exemplo, pedofilia. E em geral eles não se matam. Os sims não se matarão diretamente, embora
objetos possam matá-los e vários desastres podem matá-los. Então, sim, havia certas coisas que
decidimos deixar de fora, certas coisas que queríamos entrar e outras que tínhamos que ter muito
cuidado com a forma como tratávamos.

Com a inclusão da homossexualidade, houve alguma preocupação de que senadores que até
então se preocupavam com a violência agora se indignassem com o The Sims?

Na verdade, houve e é muito surpreendente para mim que não tenha se materializado nem um pouco.
De jeito nenhum. Simplesmente não houve reação a isso, e isso realmente me surpreendeu. Eu
pensei principalmente que se viesse, viria dos conservadores cristãos ou de algum outro grupo assim.
Talvez eles simplesmente não joguem esses jogos, talvez eles se importem menos, eu não sei. Sim,
mas não tivemos absolutamente nenhum problema com isso. Tivemos algumas pessoas nos quadros
de avisos, provavelmente garotos de quatorze anos reclamando, mas você pode dizer a idade pela
ortografia.

Parece que houve muitas decisões morais que você tomou ao projetar o jogo. Por exemplo, a
jogabilidade parece ser voltada para melhorar seu
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 433

carreira para que você possa obter mais coisas. Parece bastante materialista.
Sim, essa era realmente a intenção. Isso é o que a maioria das pessoas interpreta quando vê o jogo,
e mesmo quando o joga por um tempo acha que é muito materialista. São apenas as pessoas que
jogam há muito tempo que começam a perceber o lado negativo. Praticamente todos os objetos têm
algum estado de falha interno ou requisito de manutenção. Se você continuar comprando coisas, elas
acabarão estragando ou morrerão ou precisarão ser limpas ou qualquer outra coisa. Então, de certa
forma, é como se você estivesse enchendo sua casa com todas essas bombas-relógio em potencial.
E então, em algum momento, você acaba gastando tanto tempo consertando essas coisas e fazendo
isso, aquilo e aquilo, que esses objetos que você comprou originalmente para economizar seu tempo
acabam sugando todo o seu tempo. E isso é muito longo na jogabilidade que você começa a perceber isso.
Mas foi definitivamente projetado dessa maneira. Então, em certo sentido, são as pessoas que
começam a jogar o jogo que dizem: “Deus, eu não posso acreditar como esse jogo é materialista”.
Mas então são os jogadores hard-core que dizem: “Deus, não vou comprar tanta porcaria na próxima
vez que jogar”.

Acho que é aberto o suficiente para que os jogadores possam tentar se concentrar nos
aspectos sociais em vez da aquisição de objetos.
De certa forma, o lado social tem a mesma dinâmica, onde você faz esses amigos, mas as amizades
decaem com o tempo. E seus amigos, quando chegarem a um certo ponto, vão ligar para você e
dizer: “Ei, é melhor você me convidar, não vejo você há um tempo”. Então, uma vez que você fizer
cerca de vinte amigos, você começará a perceber que todos os dias eles estão clamando para vir, e
que estão sugando seu tempo de uma maneira diferente.

O que você pode me dizer sobre a linguagem de script Edith?


Bem, isso era o que Jamie e eu estávamos trabalhando por mais tempo. É uma linguagem de script
de programação, é visual, e na verdade desenvolvemos nosso próprio editor e depurador, todos
integrados ao jogo. Então, na verdade, você executa isso de dentro do jogo e pode programar,
depurar e percorrer objetos enquanto estiver jogando.

Então você pode usá-lo para adicionar novos objetos ao mundo?


Na verdade, quase todo o comportamento do jogo está nesses objetos, incluindo as interações
sociais das pessoas, e tudo é programado nessa linguagem. Os primitivos desta linguagem estão
todos no topo de rotinas de código de nível C. As rotinas de código de nível C são coisas como
primitivas de roteamento, espiadas e cutucadas de variáveis e coisas assim. Mas a linguagem em si
é muito limpa, e há cerca de trinta ou quarenta primitivos dos quais tudo é construído.
O principal, porém, é que é todo código tokenizado independente de máquina que viaja com o objeto.
O que significa que você pode colocar um novo objeto no jogo e instantaneamente as pessoas
saberão quando usá-lo, quando é apropriado usá-lo e como usá-lo. E as animações, efeitos sonoros,
código e tudo estão contidos no objeto que você baixa.

Então você criou a linguagem para facilitar a adição de novos objetos.


Sim, essa era a especificação original da linguagem. Queríamos ter uma linguagem na qual
pudéssemos escrever todo o comportamento que fosse totalmente expansível, no nível do objeto.
Dessa forma, o comportamento das pessoas dentro da casa é totalmente uma função das coisas em seus
Machine Translated by Google

434 Capítulo 22: Entrevista: Will Wright

casa e sempre podíamos adicionar coisas novas, até mesmo coisas do Cavalo de Tróia, na casa.

Como o objeto cobaia.


Sim, o objeto cobaia é um exemplo. Na verdade, no projeto, estávamos pensando que eles
deveriam ficar doentes, e planejamos ficar doentes, mas simplesmente ficamos sem tempo. Mas
então percebemos: “Ei, poderíamos fazer um download”. Claro, ninguém vai baixar a doença,
então nós a escondemos na cobaia. É engraçado, porque algumas das primeiras análises do jogo
diziam: “Tem todas essas coisas, mas não tem doença. Não sei por quê.” Claro, essas são
provavelmente as mesmas pessoas que reclamaram quando demos a eles. A razão pela qual
estamos lançando esta linguagem é que eventualmente eu quero que os usuários comecem a
fazer essas coisas.

E você o simplificou o suficiente para que você não precisasse ser um programador hard-
core para usá-lo?
Você teria que saber programar, mas não teria que ser um programador hardcore. Quero dizer,
esta é uma linguagem muito mais simples do que o Visual Basic.

Não te incomoda que, com uma ferramenta como essa, o jogo nunca esteja completamente
“pronto”?

Sim, acho que, novamente, se você voltar ao modelo de hobby, os hobbies nunca terminam. Eles
são apenas uma coisa em constante crescimento. E crescem muito em função da quantidade de
pessoas envolvidas e do quanto estão comprometidas. E quanto mais ferramentas poderosas eles
têm, mais forte o hobby se torna e infecta mais pessoas.

Eu também li uma citação sua onde você disse: “A verdadeira atração de longo prazo do
The Sims é como uma plataforma de contar histórias”. Agora, quando a maioria dos
desenvolvedores de jogos fala sobre histórias em jogos, eles estão falando sobre eles no
sentido de Zelda . Para essas pessoas, algo como The Sims não tem nenhuma história.
Há uma grande diferença
entre Zelda e The Sims. Você
está criando a história no The
Sims; em Zelda você está
descobrindo a história. Em
certo sentido, as histórias são
apenas um aspecto do
envolvimento do jogador.
Na verdade, existem todos
esses níveis diferentes.
Algumas pessoas casuais
jogam o jogo por algumas
horas e se divertem e o largam.

Outras pessoas vão jogar por


mais tempo e começar a Os Sims
projetar muito legal
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 435

casas, e talvez até carregá-los no site para as pessoas verem. Outras pessoas que se aprofundarem
ainda mais no jogo não apenas construirão famílias interessantes e casas legais, mas também usarão
isso para contar uma história e enviá-la para compartilhá-la com outras pessoas. E as pessoas ainda
mais hardcore começarão a editar skins ou papéis de parede personalizados para o jogo e começarão
a compartilhá-los. E, em breve, eles poderão criar seus próprios objetos, objetos personalizados e
colocá-los na web para compartilhar. Portanto, existem esses diferentes níveis de envolvimento do
jogador. E cada nível mais alto é um número muito menor de pessoas. Mas, em certo sentido, eles
estão alimentando as pessoas abaixo deles. Temos algo como dez mil casas em nosso site que as
pessoas enviaram, mas essas dez mil casas foram visualizadas mais de cem mil vezes.

Então é como um esquema de pirâmide.


Exatamente. Há cerca de trinta pessoas por aí fazendo skins muito boas para o jogo.
Mas provavelmente há trinta mil que os estão baixando e usando. Então, para seus fãs realmente
hardcore e talentosos, se você der a eles as ferramentas e a capacidade de criar conteúdo para os
outros noventa e nove por cento, eles o farão. E só vai beneficiar os dois lados. Isso dá a eles um
público para o qual construir essas coisas, e dá ao público coisas legais para o jogo que podem
eventualmente atraí-los mais fundo. Vai aumentar a probabilidade de que essas pessoas casuais
eventualmente se tornem essas pessoas do núcleo duro.

Então, algum dia, todos no planeta terão que jogar The Sims.
Certo, então isso é como o esquema de zumbis, onde os zumbis andam por aí, e então eles começam
a comer cérebros e transformar as outras pessoas em zumbis. . . Em algum momento, quando são cinco
zumbis contra o mundo, não parece muito bom, mas quando você obtém uma massa crítica de zumbis
e eles começam a converter outras pessoas em zumbis rápido o suficiente...

No The Sims , você é listado apenas como designer de jogos, enquanto no passado você atuou
como programador e designer. Você fez alguma programação no projeto?

Eu fiz um pouco de programação no código Edith. Eu não toquei no código C no The Sims.
É provavelmente o primeiro projeto em que não fiz nenhuma codificação em C. Fiz muita programação
das interações sociais e outras coisas em Edith, mas na maior parte, mesmo naquela época, era mais
uma questão minha entrando e ajustando e ajustando os algoritmos da maneira que eu queria. Tínhamos
uma equipe muito boa no The Sims, uma ótima equipe de engenheiros. Então eu não senti nenhuma
necessidade de entrar no código.

Não é algo que você sente falta?


Ah, eu meio que perdi. Eu gostava de entrar em Edith e hackear coisas. Mas havia tanto a ser feito no
lado do design que não tive tempo para desperdiçar programação.
Para não dizer que programar é perda de tempo, mas nunca fui um grande programador. Sempre fui
persistente e sempre conseguia fazer coisas legais com código de computador só porque era persistente.
Quer dizer, eu conheço grandes programadores, e não sou um.
Machine Translated by Google

436 Capítulo 22: Entrevista: Will Wright

Então você não teve problemas para comunicar sua visão do projeto para a equipe de
engenharia?
Houve problemas, mas não por falta de previsão ou inteligência. Só porque era uma coisa complexa.
Na verdade, eu mesmo não sabia o que estávamos construindo há muito tempo; muito disso foi
experimental. Mas sim, em termos de equipe de programação, eu sempre poderia sentar e explicar
a dinâmica que eu estava procurando e ter muita confiança em consegui-la.

Você também fez a transição de fazer tudo sozinho no SimCity para trabalhar em uma grande
equipe no The Sims. Quão grande era a equipe?
Depende do que você conta como equipe. Você sabe, provavelmente havia sessenta pessoas que
trabalharam nisso em algum momento, mas o que eu consideraria que a equipe cresceu para cerca
de trinta.

Então, essa é uma grande mudança de trabalhar em um pequeno grupo. E a gestão necessária
para uma equipe tão grande é bastante significativa.
É, e tem muito a ver com a qualidade das pessoas envolvidas. E a Electronic Arts também, eles
vieram com uma orientação totalmente diferente. Antes de eles chegarem, eu tinha quatro ou cinco
pessoas trabalhando no The Sims. E na verdade era um pequeno grupo muito bom e estava
funcionando muito bem, mas eu simplesmente não conseguia mais recursos. Quando a Electronic
Arts entrou, eles vieram e disseram: “O que você precisa?” E esse foi o ponto em que começamos
realmente a construir a equipe. Mas a Electronic Arts também tem um conceito muito forte de
produção e o que os produtores fazem. Eles têm dez níveis de produtores, e eles colocam uma
carga muito pesada sobre os produtores. Portanto, é uma daquelas coisas em que, se você colocar
as pessoas certas nesses slots, essas coisas funcionam muito bem; você pode realmente gerenciar
uma equipe muito grande com eficiência. Se você colocar as pessoas erradas nesses slots, é um
desastre total, um desastre absoluto. Nesse ponto, as práticas de contratação tornam-se importantes,
e como entrevistar e garantir que você consiga as pessoas certas e como descobrir rapidamente se
não tem a pessoa certa. Então é um modelo que funciona com os componentes certos e as pessoas
certas, mas se você pegar as pessoas erradas, você estragou tudo.

Basicamente, temos as pessoas certas. Ao mesmo tempo, em nossa situação na Maxis, a


Electronic Arts trouxe esse cara para administrar o estúdio, para substituir a maior parte de nossa
antiga gestão. Seu nome era Luc Barthelet. E Luc e eu nos demos bem desde o primeiro dia. Nós
nos damos muito bem. Luc não é seu gerente típico em nenhum sentido possível. Quero dizer, ele é
muito tecnicamente alfabetizado. Então, para o SimCity 3000, eles estavam tendo problemas com o
modelo de tráfego, e ele entrou e escreveu o código de tráfego.

Sério?
Sim, o código de nível C. Portanto, é incomum que você tenha alguém executando um estúdio que
também possa escrever alguns dos códigos mais complicados em uma de suas simulações. E Luc
é esse tipo de cara. Há realmente uma arte na gestão, e Luc é ótimo em saber exatamente em que
nível você precisa se concentrar em um determinado dia. E então houve um momento em que era
crucial que tivéssemos esse recurso no SimCity 3000. Isso teria um grande impacto no sucesso do
produto, e esse foi o dia em que ele tirou seu compilador
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 437

e começou a trabalhar no código de trânsito. Na maioria dos casos, era: “Como o distribuidor
alemão se sente em relação a este produto?” e ele estaria ao telefone com o distribuidor alemão.
Você realmente tem que escolher suas batalhas. E se você escolher as batalhas certas, só terá
que vencer cinco por cento delas. Então, de qualquer forma, há esse certo conhecimento de
negócios que certas pessoas que a Electronic Arts trouxe tinham em abundância, com o qual
fiquei muito impressionado em aprender.

Como surgiu o The Sims Online e quais eram os objetivos iniciais do design?
A EA queria explorar o espaço
online. Tivemos uma espécie
de sucesso com The Sims e
queríamos alavancar a
franquia no espaço online; foi
assim que surgiu o projeto.
Os primeiros objetivos de
design eram fazer um jogo
online extremamente acessível
que parecesse muito diferente,
meio mais alinhado com o
mundo The Sims , e onde
principalmente os jogadores
estivessem construindo o
mundo em que estavam
jogando. Além disso, The Sims Online
queríamos colocar mais
ênfase nas conexões sociais entre os jogadores, quase como uma topologia alternativa na qual
os jogadores estavam jogando.

Qual foi o processo pelo qual você passou para adaptar um jogo tão distinto para um
jogador para ser multijogador?
Muito disso eram questões táticas estranhas. A primeira coisa mais aparente quando alguém
jogava The Sims Online era o fato de que eles não conseguiam acelerar o tempo. Tínhamos que
ter uma linha do tempo para todos, obviamente. Como iríamos deixar os jogadores customizarem
o ambiente era meio que uma discussão em andamento. Todos queríamos que os jogadores
pudessem trazer conteúdo personalizado. Acabou sendo extraordinariamente difícil de conseguir
por uma série de razões.

Por que foi isso?


Tinha a ver com problemas de largura de banda e validação do conteúdo, garantindo que fosse
robusto o suficiente para não travar o aplicativo de alguém. Para nós, foi o primeiro grande jogo
online que construímos. E, de fato, se você olhar por baixo do capô dessa coisa, há dez peças de
software bastante elaboradas rodando em plataformas diferentes que precisam ser sincronizadas
para que a coisa funcione. Ele provou ser um ambiente de atrito muito, muito alto para o design.
Por outro lado, tínhamos muitos recursos para os pacotes de expansão do The Sims que
estávamos recebendo pela metade do preço, porque eles estavam sendo desenvolvidos de qualquer mane
Machine Translated by Google

438 Capítulo 22: Entrevista: Will Wright

os ativos de arte e tudo. Reprogramamos a maioria deles, até certo ponto. Mas ainda tínhamos esse
grande conjunto de conteúdo que era uma grande vantagem, que não estávamos desenvolvendo
apenas para o jogo online.
No The Sims Online , estávamos tentando ter diferentes metajogos que os jogadores pudessem
seguir com base em diferentes categorias de lotes. Então estávamos tentando fazer diferentes
caminhos econômicos viáveis, para alguém construir uma casa romântica ou uma casa de
entretenimento ou uma casa de habilidades ou uma casa de trabalho. Então, também estávamos
olhando para diferentes grupos sociais aninhados que queríamos ter no jogo. Primeiro é você, e
então você pode ter um grupo próximo de amigos com os quais você se conecta através da rede de
amizade, então você pode ter alguns companheiros de brincadeiras de longo prazo que você traz
para uma casa e se tornam colegas de quarto e esse é um grupo social maior, e depois acima que
tínhamos o bairro onde diferentes famílias podiam formar associações juntas. Até hoje eles ainda
estão meio que trabalhando no próximo nível, que seriam níveis acima do bairro, os clubes,
eventualmente evoluindo para uma forma de governança.

Como você projetou o jogo para que essas redes sociais funcionassem bem e não apenas
uma grande confusão de pessoas?
Bem, o design mudou bastante, mas inicialmente queríamos ter uma ligação bem estreita entre quem
estava em sua rede social e com quem você realmente passava o tempo jogando. Queríamos que
as pessoas reconhecessem formalmente quem eram seus amigos, de uma maneira Friendster, e
depois deixassem isso visível para outros jogadores. Assim posso encontrar amigos do meu amigo
ou ver se tínhamos alguém em comum que ambos conhecíamos. E então isso se tornou um
componente importante do jogo, pessoas declarando amizades ou inimigos e então tendo essa
estrutura aparecendo, a teia de amizade que você podia ler, basicamente um gráfico de rede social.
Nesse sentido, incluímos certas estruturas de recompensa para que, se você tivesse além de um
certo número de amigos, começasse a ganhar mais interações sociais para seu avatar. Para muitas
pessoas, esse se tornou o jogo principal. Para outras pessoas, havia todo um outro jogo baseado na
topologia gráfica, ou nas casas que as pessoas estavam construindo. E isso era mais um jogo
econômico, onde os jogadores ganhavam dinheiro e depois gastavam em sua casa para construir
um lugar legal para o qual eles, esperançosamente, atrairiam outras pessoas. E então se tornou um
tipo de jogo de quem pode construir a casa mais legal em que todo mundo quer passar o tempo.
Uma espécie de modelo capitalista, econômico. Então os jogadores estavam competindo para
entreter os outros jogadores. E essa era a dinâmica básica que estávamos buscando; queríamos
recompensar os jogadores por entreter uns aos outros em vez de matar uns aos outros.

Você mencionou antes como não consegue ajustar o tempo no The Sims Online.
Esse é um recurso bastante crítico na versão original do The Sims.
Sim, quando você está indo dos Sims offline para os Sims online , a primeira coisa que você percebe
é que você continua tentando acelerar o tempo e não há botão para isso. Porque você passa muito
tempo nos Sims offline com o tempo passando, chegando às partes interessantes.
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 439

Foi um problema que você tentou resolver?


Houve coisas que fizemos,
mas não conseguimos
contornar o fato central de
que todos os corpos estavam
na mesma linha do tempo.
Por exemplo, sempre que
você diz a um sim para ir a
algum lugar no The Sims
Online, ele praticamente corre
em todos os lugares para
minimizar o tempo de
roteamento. Nós
experimentamos muito com o
tempo de transporte e custo
entre lotes, e acabamos
fazendo isso de uma maneira
The Sims Online
leve, mas na maioria das
vezes descobrimos que não era divertido - ter um lote mais distante leva mais tempo para chegar.
Portanto, não havia muita topologia no mundo nesse sentido. Embora tenhamos começado a
adicionar um pouco de topologia a ele, em termos de seus motivos, seus motivos serão drenados
à medida que você se move entre os lotes, e quanto mais você avança, mais seus motivos são
drenados, então mais você precisa recarregar. muitos. Então queríamos ter algum sentimento de
localidade. Mas, além disso, muitas de suas interações foram aceleradas, de modo que, quando
você dorme no The Sims Online , acontece cerca de cinco ou seis vezes mais rápido que o The
Sims offline. Então, essas interações que você estava basicamente usando apenas para preencher
seus motivos, suas barras, onde não era uma atividade interessante, mas mais apenas uma coisa
de manutenção, nós aceleramos em relação aos Sims offline. Então fizemos muitos ajustes para tentar aliv

No final, você sentiu que resolveu suficientemente o problema?


Para a maior parte sim. Uma vez que ajustamos essas coisas, naquele ponto não parecia grande
coisa. O truque era não colocar o jogador em uma situação em que ele ficasse sentado esperando
que algo fosse concluído e não tivesse nada para fazer. Temos outras coisas que demoram mais
para acontecer, mas você está realmente tomando decisões ou há um minijogo envolvido.

Você passou muito tempo tentando fazer o jogo como os Sims offline? Ou você apenas viu
o The Sims Online como um jogo separado?
Ficou bem claro para nós desde o início que era um jogo totalmente diferente. Parecia muito com
The Sims. Essa foi a parte estranha é que as pessoas olham para isso e dizem: “Ah, isso é The
Sims”. E então eles jogam e percebem que é um jogo totalmente diferente. Em primeiro lugar,
você está controlando apenas uma pessoa, você não tem esse controle divino, não é permitido
trapacear, você não pode acelerar o tempo, as outras pessoas são pessoas reais fazendo Deus
sabe o quê. O conceito original era que iríamos construir algo que não fosse tão elaborado e seria
uma experiência peer-to-peer. E devido a alguns negócios
Machine Translated by Google

440 Capítulo 22: Entrevista: Will Wright

decisões foi decidido que deveríamos construir um mundo online persistente com uma assinatura
mensal. Então, cerca de seis ou oito meses de projeto, abandonamos tudo e seguimos uma direção
totalmente diferente para apoiar isso. Originalmente, estávamos basicamente projetando um jogo
que não tinha uma economia segura, que se baseava mais na ideia de conteúdo personalizado
fluindo, e provavelmente estava ainda mais próximo de uma sala de bate-papo gráfica IM [Instant
Messenger].

Ouvi dizer que o jogo é chamado de sala de bate-papo mais cara do mundo.
Na verdade esse era um dos nossos objetivos de design, mesmo com o persistente. Nosso objetivo
era realmente um público muito casual de pessoas que eram totalmente diferentes dos jogos online.
E então, no nível mais básico, decidimos que, se nada mais, deveria ser a sala de bate-papo gráfica
definitiva. Na verdade, estávamos olhando para dois alvos. Estávamos analisando os clientes da
AOL e os jogadores do The Sims . Na época em que começamos este projeto havia uma relação
muito estreita entre a AOL e a EA, o que não é grande coisa agora, mas na época era considerado
um aspecto muito importante do projeto. Olhando para trás, acho que o jogo precisava ser muito
mais emocionante e ter estruturas de objetivos mais óbvias. Acho também que o custo da assinatura
online realmente nos matou porque se você olhar para a nossa base de jogadores e quantos deles
nem sequer têm cartão de crédito. Eles não são jogadores hard-core.

Esses são os jogadores do The Sims offline?


Sim certo. Até os clientes da AOL, muitos deles.

Os clientes da AOL não precisam ter cartões de crédito para se inscrever?

Bem, seus pais fazem, essa é a coisa. Muitas das pessoas que estão realmente gastando tempo na
AOL são, na verdade, crianças de doze e treze anos. Seus pais obtêm AOL para eles. Eu, como um
jogador hard-core, estou realmente relutante em pagar dez dólares por mês para assinar um jogo
como esse. Conseguir que um jogador casual como aquele que comprou talvez um ou dois jogos na
vida faça isso... Ao conversar com as pessoas, acabou sendo uma barreira enorme para entrar no
jogo.

Você faria o jogo significativamente diferente se estivesse projetando-o agora?


Sim, eu mudaria significativamente o design do jogo e procuraria um modelo de negócios totalmente
diferente. Até que pudéssemos encontrar um modelo de negócios diferente, acho que nem me daria
o trabalho de tentar.

Você fez muitos ajustes no jogo depois que ele foi lançado?
Sim, estávamos fazendo isso um pouco. Uma boa parte disso era apenas ajustar as coisas de
nível; reajustar objetos que estavam no mundo, estruturas de recompensa e assim por diante. Outras
partes estavam, na verdade, reestruturando a estrutura de recompensas ou as atividades. Passamos
muito tempo nos quadros, antes e depois do lançamento, onde postávamos nossos primeiros
designs nos quadros e recebíamos feedback dos jogadores, muito antes de o recurso ser realmente
implementado. E faríamos modificações no recurso com base nesse feedback inicial.
Tínhamos três áreas das placas. Um que era apenas idéias de céu azul que estávamos pensando.
Em seguida, tivemos um para coisas que estavam em design e estávamos postando nossas
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 441

documentos de design para os


jogadores lerem. E então o
último foi “Isto está prestes a ser
implantado”. Então, tínhamos
três níveis de designs que fluíam
por onde os jogadores tinham
visibilidade bastante alta e
sabiam o que estava por vir. E
eles sentiram que tiveram uma
interação muito boa com a
equipe de design.

Por outro lado, se você observar


a interação, cerca de metade ou
mais dos recursos que
descrevemos no quadro,
The Sims Online
invariavelmente metade dos
jogadores diria: “Ah, adoramos”, e a outra metade dos jogadores diria: “Ah, nós odiamos.” Não é como se
sempre houvesse um feedback muito claro sobre o que era bom ou ruim.
Porque tínhamos jogadores no jogo fazendo coisas totalmente diferentes com estruturas motivacionais
totalmente diferentes. Então, você simplesmente não pode agradar a todos o tempo todo.

Então, como você decidiu o que adicionar?


Algumas das coisas que achávamos que eram fundamentais que precisávamos forçar o design, mesmo
que os jogadores fossem meio a favor e contra. Nesse ponto, tivemos que seguir nosso próprio
pressentimento, nosso próprio senso de design. Acho que parte disso é bom, em geral, dar aos jogadores
a capacidade de ter feedback. Se eles sabem que você os está ouvindo, essa é a metade da batalha. Os
jogadores estão vendo que é uma divisão equilibrada, então, se você cair de um lado ou de outro, eles
não vão realmente culpá-lo. Mas se noventa por cento dos jogadores dizem que é uma merda e você vai
em frente e faz isso, é aí que eles vão te pegar.

Como foram os testes de jogo no The Sims Online?


Foi um pouco complicado porque nossos testes iniciais eram apenas testes internos com trinta ou quarenta
pessoas jogando, e não tínhamos a massa crítica necessária para validar muitos dos recursos. Então, foi
só quando entramos nos testes beta que tivemos uma noção real de como os jogadores iriam se comportar.
Também tivemos diferentes tipos de jogadores fluindo pelo jogo em diferentes momentos. No teste beta,
tivemos um tipo de jogador muito diferente do que tínhamos cinco meses após o lançamento. E eles
valorizavam os recursos de maneira totalmente diferente.

Como assim?

As primeiras pessoas eram mais socializadoras, as pessoas posteriores eram mais buscadoras de
objetivos, em geral. Além disso, os jogadores ficaram mais casuais ao longo do tempo, basicamente,
apenas em termos de quão experientes eles eram. Acho que ficou mais jovem com o tempo. Estávamos coletando
Machine Translated by Google

442 Capítulo 22: Entrevista: Will Wright

muitas métricas sobre os jogadores que estudamos todos os dias. E estudaríamos as tendências
nessas métricas, em termos de quais objetos eles estão comprando, o que estão fazendo, quais
interações sociais estão escolhendo, quantos amigos eles têm e todas essas coisas, procurando
padrões. Era incrível como às vezes apenas uma coisinha desequilibrada mudava radicalmente o
padrão de jogo de todos. E essas eram principalmente questões de equilíbrio econômico, algumas
delas envolvendo façanhas. Alguém encontraria um exploit baseado em um dos objetos de trabalho
do jogo e, de repente, na semana seguinte, todos estariam usando esse objeto de trabalho e
ninguém usaria nenhum dos outros. Na verdade, provavelmente encontramos muitos de nossos
exploits e bugs mais rapidamente através das métricas do que quando os jogadores os reportaram
ou os testadores os encontraram.

Então, a mudança em seu público ao longo do tempo tornou o jogo difícil de equilibrar?
Parecia que estávamos sempre tentando nos equilibrar contra um alvo em movimento. Às vezes
tentávamos liderar o alvo, mas eu diria que sempre foi um processo bastante caótico. Normalmente,
poderíamos olhar para as métricas e dizer, OK, isso está desequilibrado, e então teríamos duas ou
três possibilidades diferentes de equilibrar. E quando começamos a equilibrar essa coisa, de
repente algo mais parecia maluco, e nós olhávamos para isso. E é claro que tudo está inter-
relacionado também. Havia algumas tendências sociais também que eram coisas de longo prazo,
modismos que aconteciam no mundo, que ninguém previa e que começaram a afetar as coisas.

O que seria um exemplo disso?


Há um mapa no jogo onde você pode ver miniaturas das casas enquanto você rola pelo mapa. As
miniaturas têm cerca de 50 pixels de largura. Em algum momento, algum corpo decidiu decorar
seu telhado, e eles fizeram isso de uma forma em que usavam cores diferentes nas telhas, e
quando você fez a miniatura, acabou ficando com essa foto bem legal. Alguém fez Madonna ou
Michael Jackson ou algo assim. Então alguém fez isso um dia, e então todo mundo disse que é
legal, e então dentro de duas semanas havia dez desses no mundo, e duas semanas depois todos
os outros telhados estavam decorados com alguma imagem. Foi apenas uma daquelas coisas que
ninguém realmente previu, e foi preciso um jogador para descobrir isso. Alguém escreveu um
programa que realmente escaneava uma imagem e então configurava automaticamente um telhado
no jogo. Mas coisas assim aconteciam o tempo todo.

Você gostou de ver esse tipo de comportamento emergente?


Ah sim, isso era realmente o que queríamos encorajar o máximo possível. Especialmente aqueles
como aquele, que não estavam afetando outras pessoas. Tem outros que eram mais problemáticos,
como toda essa organização mafiosa que começou no jogo, que virou um grande negócio. Tornou-
se provavelmente o maior ponto de conflito em todo o jogo. Foi bem organizado; eles realmente
tinham capos e toda essa estrutura hierárquica de relatórios, e havia centenas de jogadores
envolvidos nela. E eles se viam como os guardiões do jogo. Eles realmente saíam e lamentavam
os jogadores que achavam que não estavam jogando direito ou que estavam tentando arruinar o
jogo. Então eles eram basicamente vigilantes. Mas então outras pessoas pensaram que estavam
apenas implicando com as pessoas sem motivo aparente. E então havia esse outro grupo chateado
com a máfia
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 443

que estava se opondo a eles. Isso se tornou essa grande luta pelo poder no jogo. Tínhamos essas teias de
amizade e, como uma das coisas nessa rede de amizade, estávamos avaliando quem era a pessoa mais
popular no jogo por quantos amigos eles tinham.
E houve uma mulher que rapidamente foi para o topo dessa lista e foi ela quem realmente fundou a máfia.
Porque ela já tinha essa incrível rede social e aproveitou isso para se tornar a chefe da máfia. Ela ficou
muito famosa. Algumas pessoas a amavam e achavam que ela estava ajudando o mundo; outras pessoas
achavam que ela era a pior griefer de todo o jogo.

Isso foi algo que você sentiu que precisava parar?


Tínhamos certos termos de serviço específicos, portanto, se alguém violasse esses termos de serviço e
outra pessoa denunciasse, tínhamos a obrigação de entrar e lidar com isso. Essas pessoas da máfia eram
muito, muito boas em apenas contornar a borda disso, e então eles quase nunca faziam nada que
ultrapassasse os limites dos termos de serviço. Em outras palavras, você pode entrar e fazer de alguém
um inimigo. Isso é apenas parte do design do jogo. Basicamente, você recebe as recompensas por ter
muitos amigos e perde essas recompensas se tiver mais inimigos. Então, uma de suas táticas era decidir
que havia uma pessoa que estava fazendo algo ruim ou que os havia desprezado ou enganado um novato
ou o que quer que eles não gostassem. Então eles espalhariam a palavra através da rede da máfia, e
então cinquenta deles atacariam aquela pessoa e todos o declarariam um inimigo, o que removeria todas
as coisas sociais que ele havia conquistado.

Essa era a maneira que eles estavam sofrendo. Então, na verdade, estava dentro das regras do jogo.
Mas estávamos acompanhando isso bastante, e foi realmente interessante a turbulência social que
isso causou no jogo. Em certo sentido, foi bom; Eu acho que o jogo realmente precisava mais disso. Porque
o que isso levou as pessoas a fazer foi polarizar, e se reunir e falar sobre isso, e o que eles vão fazer.
Basicamente, ter um inimigo comum em ambos os lados fez com que as pessoas se unissem mais
fortemente. Algumas semanas depois que isso aconteceu, algo interessante aconteceu. Não estava muito
claro se alguém estava na máfia ou não – você não podia realmente olhar para alguém e dizer, e
frequentemente eles não deixavam você saber. E essa onda de macarthismo varreu o mundo, com pessoas
acusando alguém de estar na máfia: “Não, não estou!” "Sim ele é!" Coisas seriam sussurradas sobre várias
pessoas. Foi meio interessante como todos esses comportamentos sociais humanos se manifestaram
nesse pequeno microcosmo.

Acho que essa é uma maneira de saber quando você foi bem-sucedido, quando criou um sistema
que permite que esse tipo de comportamento aconteça.
Pelo menos você permitiu que uma certa quantidade de natureza humana fluísse para ele.

Anteriormente, você mencionou o uso de métricas para avaliar o estado do jogo antes de fazer
ajustes. Você achou que podia confiar mais nas métricas do que no feedback dos jogadores?

Acho que ambos foram valiosos. As métricas não lhe dariam nenhuma visão sobre intenção ou motivação.
Eles apenas dizem que mais pessoas estão fazendo isso hoje do que amanhã, e você não tem ideia do
porquê. Então, nós realmente íamos conversar com as pessoas ou olhar para quadros de mensagens e
tentar descobrir as reais motivações por trás dos comportamentos. Também, muito
Machine Translated by Google

444 Capítulo 22: Entrevista: Will Wright

as pessoas diriam que


odiavam uma ideia, mas então
você a coloca no jogo e de
repente... Os jogos são tão
emergentes às vezes que
mesmo que você diga aos
jogadores o que você está
prestes a fazer, eles não
podem realmente imaginar o
resultado real disso no jogo.
Então, às vezes você tem que
descontar o que os jogadores
estão lhe dizendo, se acontecer
de ser algo que parece que
vai ser um tipo de dinâmica
muito não linear e não intuitiva. The Sims Online
Mas você ainda sabe que tem
um problema de relações públicas, que precisa vender aos jogadores o valor do recurso.

Você está trabalhando no The Sims 2 atualmente?


Não, realmente não. Estou trabalhando em outra coisa agora.

É curioso para mim como você pode fazer uma sequência de um jogo tão bom quanto The
Sims sem apenas tornar o jogo mais complicado, mas não necessariamente melhor.
Sim, isso é meio que um ponto pegajoso. Qualquer jogador vai olhar para um jogo e dizer: “Ah,
seria muito mais legal se eles adicionassem isso, aquilo e aquilo”. E, realmente, você chega a um
ótimo jogo não adicionando um monte de coisas, mas descobrindo o que tirar. E essa é a parte
realmente difícil. Por outro lado, a tecnologia progrediu, provavelmente os jogadores estão um
pouco mais avançados. Você obviamente quer fazer algo diferente com ele.
É uma luta com uma sequência de alto nível como essa, porque com os primeiros Sims nós éramos
esse pequeno jogo e o fato de termos conseguido foi uma vantagem. Com algo como The Sims 2,
parece que tudo o que eles podem fazer é falhar. Há todas essas expectativas acumuladas sobre
o projeto. Mas acho que você tem que descobrir qual era o núcleo do jogo original que as pessoas
gostavam e quais partes do jogo original eram irrelevantes ou tangenciais ao sucesso. E essas são
as áreas nas quais você tem oportunidades de entrar e expandir, modificar, repensar. E, claro, a
tecnologia progrediu, mas há muitas considerações que a envolvem.

Você está feliz por estar trabalhando em algo diferente de The Sims?
O primeiro protótipo que fiz do The Sims foi em 93, então já se passaram mais de dez anos.
Na verdade, trabalhei no SimCity cerca de dez anos, desde a primeira versão do SimCity até a
última em que trabalhei, que foi o SimCity 2000, e dez anos é o meu limite para qualquer coisa.
[risos] E desde o The Sims Online, eu meio que segui em frente, e estou em um espaço totalmente
diferente agora, o que é muito divertido. O que eu gosto é encontrar outros
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 445

maxima no espaço de design de jogos, e ocasionalmente encontro um máximo legal como SimCity
ou The Sims. E é claro que a empresa quer continuar explorando esse máximo, fazendo muitas
coisas, basicamente construindo uma franquia. Mas em algum momento eu só tenho que me
afastar e procurar outro máximo.

Havia princípios orientadores que as pessoas deveriam seguir ao projetar e desenvolver a


família de jogos Sim?
Bem, basicamente sempre os vimos como sendo, em sua maioria, não violentos, embora tenhamos
quebrado essa regra algumas vezes. Mas, na maioria das vezes, consideramos essa uma de
nossas características distintivas. Muitos de nossos funcionários que trabalham para nós realmente
querem trabalhar para a Maxis porque a Maxis é conhecida por seus jogos não violentos. Eu não
quero soar como se eu estivesse fazendo alguma declaração moralista, porque eu amo Doom e
Quake e essas coisas. Alguns dos meus jogos favoritos são jogos de guerra. Eu jogo jogos de
guerra pesadamente. Eu só acho que há tantas pessoas fazendo esses jogos que não precisamos,
e eles estão fazendo um bom trabalho também. Então eu prefiro fazer jogos que ninguém está fazendo.
Mas do ponto de vista do público, temos essa reputação de tender para os jogos mais não
violentos, mais educativos, mais socialmente relevantes.

Você já se sentiu constrangido fazendo jogos de simulação no estilo Maxis? Você já quis
fazer Raid Over Bungeling Bay II?
Em certo sentido, SimCopter
foi quase Raid Over Bungeling
Bay II. Havia muitos easter
eggs escondidos no SimCopter.
Na verdade, você pode pegar
um Apache e devastar a
cidade. Na verdade, se você
tivesse o Apache e encontrasse
uma usina nuclear, poderia
explodir a cidade inteira.
Mesmo no The Sims, algumas
vezes, tentei fugir do
politicamente correto aqui e
ali. Então, há muitas coisas
que fizemos no The Sims que
não são terrivelmente
SimCopter
politicamente corretas, que
nem fazem sentido, sabe, mais do lado maluco. Nós não tentamos deixar a coisa da Maxis nos
restringir, mas a coisa da violência doméstica provavelmente foi um bom exemplo. Você verá
muitos jogos onde há um nível muito maior de violência, muito maior do que um homem batendo
em uma mulher. Mas estávamos sensíveis a como as pessoas interpretariam isso, sabendo que
as famílias estariam jogando.
Machine Translated by Google

446 Capítulo 22: Entrevista: Will Wright

Seus jogos sempre parecem ter esse forte componente educacional. Eu estava me
perguntando, como você equilibra isso com tornar o jogo divertido?
Eu nunca me preocupei com a educação até que o jogo fosse divertido. Qualquer valor educacional
que um programa possa ter é totalmente desperdiçado se as pessoas não o jogarem. Provavelmente
o jogo com o qual mais aprendi foi o SimEarth. SimEarth foi potencialmente o jogo mais educativo
que já fiz, mas ainda assim não foi divertido. Um número surpreendente de pessoas comprou; Ainda
estou surpreso com os números de vendas. Acho que a maioria deles jogou por duas horas e depois
guardou. Então eu realmente acho que a diversão tem que vir em primeiro lugar. E o lado
educacional, não é algo que você coloca, tem que ser fundamental para o design.
No The Sims, era tudo sobre aprender a extrapolar o design do comportamento. Essa é uma lição
bastante profunda, não é apenas um fato que vou ensinar a você. É mais como uma maneira de ver
as coisas. Se todo o design for fiel a isso, pode ser educacional em algum nível profundo, mesmo
que você jogue o jogo por horas e não pense nele como educacional nem uma vez. Uma das
principais coisas que SimCity ensina – não é explícito, mas está lá – é a forma do caos. O fato de
que os planos mais bem elaborados sempre podem dar errado, e que o sistema é mais complexo
do que você pensa. Construir uma estrada para resolver o trânsito nem sempre resolve o trânsito;
freqüentemente gera tráfego. Esses tipos de lições são difíceis de explicar em outras mídias. Mas
quando você os experimenta por meio de um processo como o SimCity, você realmente aprende a
lição muito mais profundamente. É experiência ao invés de exposição.

Você já teve que comprometer o realismo para tornar o jogo divertido?


Ah, o tempo todo. Há também uma coisa frequente que fazíamos em nossos jogos em que
decidíamos corresponder às expectativas e não à realidade. Na verdade, as usinas nucleares não explodem.
Eles simplesmente não. Mas quando todo mundo viu, eles disseram: “Oh, uma usina nuclear, posso
fazê-la explodir?” É só o que eles pensaram. Então, há muitas coisas que fazemos só porque as
pessoas esperam que aconteçam dessa forma por diversão, mesmo que não seja realista.

Com a natureza aberta de seus jogos, você precisa gastar muito tempo testando-os?

Nós fazemos, mas é um tempo inestimável. Você gasta esse tempo, ou então passa meses
construindo a coisa errada e resolvendo os problemas errados. Acabamos de testar o que chamamos
de “kleenex” em um pequeno componente do multijogador do The Sims no qual estamos trabalhando.
Temos esta exibição de dados que é complicada e distorcida. E o programador acabou de
implementá-lo há alguns dias, então agendamos cinco pessoas para vir hoje.
Nós os chamamos de kleenex playtesters porque os usamos uma vez e nunca mais voltam, só
porque queremos pessoas que nunca o viram antes, sem nenhum pré-conceito sobre isso. Nós nem
mesmo dizemos a eles o que é, apenas dizemos: “Olhe para isso, brinque com isso”, e pedimos que
nos descrevam o que estão vendo e o que isso representa. Recebemos um feedback muito
consistente de todas as cinco pessoas hoje, onde entendemos que três das variáveis que estávamos
comunicando todos entenderam, as outras três não tinham ideia. Então, para o último testador,
desativamos as três últimas variáveis com as quais todos estavam tendo problemas e ficou perfeito.
Fazemos isso em todas as etapas do projeto agora. Não é só no final que temos tudo funcionando,
fazemos isso com pequenos componentes, até os protótipos de arte. E esta foi uma lição que
realmente me foi ensinada pelo falecido Dani Berry. Ela é quem fez MULE e todos aqueles
Machine Translated by Google

Capítulo 22: Entrevista: Will Wright 447

coisas. Ela estava perfurando isso em mim anos atrás, que o teste de jogo é provavelmente a coisa mais
desvalorizada que qualquer designer de jogos pode usar, e você realmente tem que fazer isso. E eu
comecei a seguir o conselho dela e ela estava certa. É simplesmente inestimável.

Seja SimCity ou The Sims, você parece ter um talento especial para criar designs de jogos únicos
e muito originais em torno de tópicos complexos. Estou curioso para saber como você cria novas
ideias de design.
Acho que cada designer tem uma técnica totalmente diferente. Então, acho que se você perguntar a
todos os designers de jogos como eles projetam um jogo, obterá respostas totalmente diferentes. Acho
que muitas vezes meu próprio processo interno é bastante opaco até para mim. Vou tentar muitas
maneiras diferentes de olhar para um assunto e não ficar preso em um ponto de vista ou uma abordagem.
E para mim o valor está em um conjunto de diversas abordagens que executo em paralelo. Cada
abordagem é uma maneira de olhar para jogos ou entretenimento ou qualquer outra coisa; algumas
podem ser abordagens muito analíticas, outras podem ser abordagens muito emocionais ou cinestésicas.
E, geralmente, e essa é a parte opaca, algo na minha cabeça está realmente me dizendo: “Ah, estou
conseguindo uma melhor tração nessa abordagem”. Ou “E essa?
Esta é uma maneira realmente estranha de pensar sobre isso.” Então, muitas vezes eu tento imaginar
qual é a maneira mais estranha de abordar um assunto ou um desafio, apenas supondo que isso me
levará a um caminho diferente do que a maioria das pessoas seguirá para chegar lá. Eles podem acabar
no mesmo ponto, mas se eu adotar uma abordagem totalmente diferente do problema, é provável que
descubra alguns máximos que outras pessoas não estão vendo. Todo ano eu tento dar uma palestra na
Game Developers Conference para falar sobre design e processo e tudo isso, e nunca estou muito
satisfeito, porque ainda sinto que meu processo interno é bastante desconhecido para mim. Essa é a
única razão pela qual eu realmente dou palestras, eu realmente não gosto de falar. Eu não sou realmente
uma pessoa social, sou um cara bem introvertido, na verdade. Mas acho que quando tenho que preparar
palestras, na verdade estou tendo que cavar em minha própria experiência e auto-refletir sobre meu
próprio processo de pensamento. Então, na verdade, acho isso mais valioso para mim do que
provavelmente as pessoas que realmente ouvem as palestras, porque me força a ficar conscientemente
ciente, pelo menos até certo ponto, do meu processo interno.

Em Understanding Comics, Scott McCloud fala sobre os dois tipos de pessoas criativas: aquelas
que gostam de examinar seu processo e aquelas que não querem por medo de que ele vá quebrar.

Não estou preocupado em quebrá-lo, é só que ele está enterrado lá bem fundo, e é preciso muito cavar
para chegar até ele.

Tanto para SimCity quanto para The Sims, você teve problemas para convencer alguém de que
eles seriam populares. Você acha que existem muitos jogos por aí com o mesmo problema que
nunca veem a luz do dia? O que você recomenda que alguém com uma ideia maluca de jogo faça?

Oh, eu tenho certeza que eles estão em todo o lugar. É meio deprimente pensar nisso, quantas obras-
primas maravilhosas existem por aí. Para mim, é que eu sou um cara muito, muito persistente. Eu acho
que se você for muito, muito persistente, se você realmente quiser alguma coisa, você pode fazer
acontecer. Pode levar anos. Com SimCity foram uns cinco anos para lançar a primeira versão. Com The
Sims era como sete. Além disso, com base em
Machine Translated by Google

448 Capítulo 22: Entrevista: Will Wright

meu histórico, não sei se sou eu quem dá conselhos lá. Sempre que surge algo incomum como
The Sims, gosto de pensar que, de repente, as pessoas dizem: “Ei, isso foi realmente inusitado e
vendeu muito bem!” Talvez isso possa ajudar a dar luz verde a alguns outros projetos inusitados
em outras empresas que estavam tendo problemas para serem aprovados. Mas acho que
realisticamente é mais provável que eles digam: “Ah, queremos um jogo como The Sims”.
Infelizmente, essa é provavelmente a lição que eles vão tirar disso.

Os Sims

Gameografia de Will Wright


Invasão sobre Bungeling Bay, 1984
SimCity, 1989
SimTerra, 1990
SimAnt, 1992
SimCity 2000, 1994
SimCopter, 1997
The Sims, 2000
The Sims Online, 2002
Machine Translated by Google

Capítulo 23
Design de nível

“Minha política sempre surge da parte instintiva dos seres humanos. Por
exemplo, o inventor criou o telescópio porque queria fazer alguma coisa que
permitisse às pessoas ver longe e além? Não, acho que era mais simples. O
inventor deve ter tido um forte desejo de ver longe. Começo com a hipótese de
que as pessoas fazem produtos porque seus desejos e instintos os fazem querer.
Os desejos e instintos humanos estão no cerne do design de jogos. Agora
existem novos dispositivos sendo lançados, mas qualquer que seja a nova forma
de tecnologia que apareça, sempre projetaremos de acordo com o que os
humanos desejam instintivamente”.
— Tetsuya Mizuguchi

eram executadas por uma pessoa agora são executadas por várias pessoas. Isto
À medida que os jogosdo
a divisão de trabalho
computador
é cresceram
necessáriaem para
tamanho e escopo, asoportuna
a conclusão tarefas quedos
no passado
jogos
sofisticados e massivos que os editores exigem e o mercado espera.
Um dos papéis únicos criados por meio dessa divisão de trabalho foi o de designer de níveis.
Uma vez que a jogabilidade central de um jogo é estabelecida, é o trabalho do designer de níveis
criar o mundo do jogo no qual essa jogabilidade ocorre, para construir espaços que sejam
divertidos para os jogadores jogarem.

449
Machine Translated by Google

450 Capítulo 23: Design de Nível

O número de designers de níveis necessários para um projeto é diretamente proporcional à


complexidade dos níveis a serem usados nesse projeto. Para um jogo 3D com arquitetura
extremamente detalhada que deve ser construída pelo designer de níveis, não é absurdo ter dois
níveis por designer, talvez apenas um. Às vezes, o designer principal do jogo também atua como
designer de níveis, às vezes ela elabora planos para os níveis para os designers de níveis
construirem e às vezes ela apenas supervisiona a equipe de designers de níveis trabalhando no
projeto. Para um jogo 2D mais simples, não está fora de questão para o designer-chefe do jogo
criar todos os níveis do jogo. Mesmo com um jogo 3D muito detalhado e complexo, não está fora
de questão para o designer principal construir primeiro o nível de protótipo ao qual todos os níveis
subsequentes são comparados.
O design de níveis é onde todos os diferentes componentes de um jogo se juntam. De certa
forma, criar um nível é como montar um quebra-cabeça; para construir os níveis, o designer de
níveis deve fazer uso do motor do jogo, arte e jogabilidade principal. Muitas vezes, o design de
níveis é onde os problemas de um jogo se tornam mais aparentes. Se o motor não estiver à altura,
os níveis começarão a se comportar de forma irregular em certas situações, ou a taxa de quadros
não será capaz de suportar os efeitos planejados. Se a arte for feita na escala errada ou tiver
problemas de renderização de qualquer tipo, essas dificuldades surgem quando o designer de
nível começa a colocar a arte no mundo. Se a jogabilidade do título não for capaz de suportar uma
ampla variedade de níveis para preencher um jogo inteiro, ou, pior ainda, se a jogabilidade não for
nada divertida, esse problema ficará aparente durante o processo de design de níveis. É
responsabilidade do designer de nível trazer esses problemas à atenção da equipe e ver que as
dificuldades são resolvidas adequadamente. Muitas vezes, isso pode fazer com que o designer de
nível seja um dos membros menos apreciados da equipe, já que ele deve estar sempre
incomodando as pessoas para resolver problemas, mas se ela tentar ignorar os problemas que
encontrar, o jogo será pior como resultado. O trabalho do designer de níveis é aquele que vem
com grande responsabilidade.
Com todos os diferentes aspectos do conteúdo do jogo para se preocupar, o trabalho do
designer de níveis certamente não é fácil. Além de garantir que todos os componentes do jogo
estejam perfeitos, se o próprio trabalho do designer de nível não for da mais alta qualidade, o jogo
provavelmente falhará miseravelmente. Se os níveis não trazem os melhores aspectos do motor,
da arte e da jogabilidade, não importa o quão bons esses componentes possam ser. Sem bons
níveis para juntar tudo, o jogo não conseguirá atingir seu potencial.

Níveis em jogos diferentes


A definição de um “nível” varia muito de jogo para jogo. Geralmente se refere ao mundo do jogo de
side-scrollers, jogos de tiro em primeira pessoa, aventuras, simuladores de vôo e jogos de RPG.
Esses jogos tendem a ter áreas distintas que são chamadas de “níveis”. Essas áreas podem ser
restritas por área geográfica (mundo de lava versus mundo de gelo), pela quantidade de conteúdo
que pode ser mantida na memória de uma só vez ou pela quantidade de jogo que “parece certa”
antes que os jogadores recebam um breve adiamento antes do início do próximo nível. Embora
muitos jogos de arcade clássicos, como Centipede ou Space Invaders, tenham ocorrido inteiramente
em um nível, outros, como Pac-Man ou Joust , ofereceram variações simples no mundo do jogo e
desafios de jogo para prolongar sua jogabilidade. Assim, os diferentes labirintos do Pac-Man
constituem seus níveis. Dentro
Machine Translated by Google

Capítulo 23: Design de Nível 451

A Joust fez mudanças


simples em seu mundo
de jogo para produzir
diferentes níveis.

um jogo de estratégia baseado em campanha como StarCraft, os níveis ou cenários são definidos
por mapas acompanhados de objetivos que os jogadores devem cumprir, como defender os
terráqueos contra as forças Protoss neste período de tempo. Em um jogo de corrida, um nível seria
uma das pistas disponíveis no jogo. Em um jogo esportivo, digamos beisebol, os níveis seriam os
diferentes estádios apresentados no jogo. Aqui a diferença entre os vários níveis é completamente
estética, pois em termos de mecânica de jogo, um jogo de beisebol jogado no Wrigley Field é
apenas sutilmente diferente de um jogado no Yankee Stadium.

Jogos como Civilization e SimCity têm níveis, mas uma diferença importante dos jogos
descritos acima é que a totalidade do jogo de um jogador ocorre em um único nível. O nível base
também é gerado aleatoriamente seguindo regras cuidadosamente projetadas e, a partir daí, é em
grande parte responsabilidade do usuário construir o nível enquanto ele joga. É por isso que esses
títulos são frequentemente chamados de jogos de “construtor”. Para esses títulos, a autoria do nível
é quase totalmente abdicada aos jogadores.
Este capítulo trata principalmente de jogos que usam níveis pré-construídos que têm um grande
impacto na jogabilidade. Embora os títulos esportivos e os jogos “construtores” possam ter níveis,
sua construção é deixada para os artistas e jogadores, respectivamente, e, portanto, geralmente
não é uma preocupação dos designers. Para jogos como Doom, Tomb Raider, Super Mario 64,
Maniac Mansion, Pac-Man, StarCraft e Fallout, no entanto, o design dos níveis tem tudo a ver com
a jogabilidade e, portanto, o designer deve estar intimamente envolvido com sua criação.

Separação de Nível
Como um jogo é dividido em seus níveis de componentes tem um enorme impacto no fluxo do jogo.
Os jogadores geralmente jogam um jogo um nível de cada vez. Se um pai anuncia o jantar enquanto
uma criança está jogando, é provável que essa criança implore para poder “apenas terminar este
nível”. Em jogos de console, frequentemente os jogadores só podem salvar seu jogo entre os níveis,
Machine Translated by Google

452 Capítulo 23: Design de Nível

o que dá mais importância ao final de um nível como a conclusão de uma unidade de jogo. Um
nível pode funcionar como um ato em uma peça, um capítulo em um livro ou um movimento em
uma sinfonia. Dá ao público a chance de ver uma unidade discreta dentro de um trabalho maior,
para entender qual parte do trabalho foi concluída e o que espera pela frente.
Níveis cuidadosamente orquestrados são configurados de forma que tenham uma série de
momentos de tensão e liberação para criar uma curva emocional para o jogador experimentar.
Quando os jogadores finalmente veem que o nível terminou, eles sabem que realizaram uma
quantidade significativa de jogabilidade e devem se sentir orgulhosos de si mesmos.
As limitações técnicas geralmente ditam onde o final de um nível deve ocorrer. Apenas tantas
texturas, sons e dados de nível podem caber na memória de uma só vez, e quando esses recursos
são usados, a jogabilidade tem que parar por tempo suficiente para que diferentes dados do
mundo sejam carregados. Novas tecnologias apresentam a oportunidade de um ambiente mais
perfeito mentos. Mesmo no PlayStation tecnicamente limitado, o desenvolvedor Insomniac
conseguiu evitar o carregamento de telas inteiramente em Spyro the Dragon, em vez de apenas
fazer Spyro voar no ar por um segundo (enquanto os dados necessários são trocados) e depois
fazê-lo voar de volta à terra no novo nível. Para jogadores casuais assistindo Spyro, o intervalo é
muito menos chocante do que ver uma tela de “carregamento” aparecer. Os níveis de Spyro the
Dragon ainda precisam ser divididos em seções entre essas telas sem carregamento, no entanto,
o que significa que a jogabilidade nesses níveis ainda é limitada a uma certa quantidade de
espaço. Um bom designer, é claro, pode usar as restrições de memória e usá-las adequadamente
para criar níveis divertidos e desafiadores de jogar, ao mesmo tempo em que se encaixam no
espaço disponível. Novamente, o designer deve aceitar as limitações do hardware e abraçá-las.
Half-Life é outro exemplo interessante de divisão de níveis. Aqui, a equipe da Valve queria
criar uma experiência mais perfeita para os jogadores, mas ainda estava usando a limitada
tecnologia Quake . Quake tinha apresentado cerca de trinta níveis, cada um dos quais levava uma
quantidade significativa de tempo para carregar. Em Quake os níveis existiam em universos
separados um do outro; nunca um monstro perseguiria jogadores de um nível para outro, nunca
os jogadores retornariam a um nível anterior. Os programadores da Valve criaram um sistema
onde, se os níveis fossem pequenos o suficiente, eles poderiam ser carregados em menos de
cinco segundos. Eles também fizeram modificações para que os monstros pudessem rastrear os
jogadores através dos limites entre os mapas. Os designers de níveis da Valve conseguiram fazer
seus níveis muito pequenos, muito menores do que um nível padrão de Quake , mas depois
criaram uma grande quantidade deles. As áreas entre dois níveis contêm arquitetura idêntica, de
modo que os jogadores podem atravessar a fronteira entre dois desses níveis e, além da breve
mensagem de carregamento, nem saber que cruzaram um limite de nível. O resultado é uma
experiência muito mais perfeita para os jogadores. Evidentemente, a equipe ainda sentia a
necessidade de arcos de história no jogo, já que os “títulos dos capítulos” de texto aparecem
brevemente na tela em pontos-chave durante o jogo. De fato, esses títulos funcionam muito bem
como mini-recompensas para os jogadores, deixando-os saber que realizaram uma boa parte da
jogabilidade, como costumava ser transmitido por uma carga de nível longo. Mas desde que as
equipes de programação e design foram capazes de criar um sistema de carregamento de níveis
quase contínuo, a equipe de design foi capaz de separar o jogo nessas unidades de narrativa
sempre que se sentisse melhor, em vez de onde a tecnologia ditasse. O ideal para um jogo
imersivo como Half-Life, é claro, seria eliminar completamente esses tempos de carregamento.
Desde que Half-Life foi lançado, alguns jogos conseguiram criar um mundo completamente
contínuo, incluindo Jak & Daxter e Dungeon Siege. Esses jogos só
Machine Translated by Google

Capítulo 23: Design de Nível 453

conseguiu esse feito após o investimento de uma grande quantidade de tempo de desenvolvimento,
embora a recompensa pareça ter valido a pena.

Ordem de nível
A ordem em que os níveis ocorrem também é importante para o fluxo geral do jogo.
Talvez grandes níveis de tiroteio devam ser alternados com níveis mais estratégicos ou de quebra-
cabeça. Se um jogo colocar todos os seus níveis estratégicos no início do jogo e depois encher o
final com mais episódios orientados para a ação, o jogo parecerá mudar no meio do caminho,
perturbando o equilíbrio que os jogadores esperam. No mínimo, o designer deve saber como a ordem
dos níveis afetará o fluxo do jogo e deve estar ciente de como a movimentação de diferentes níveis o
afetará. Por exemplo, se um jogo tem trinta níveis e seis monstros chefes, uma maneira lógica de
colocar esses adversários no jogo seria no final do quinto, décimo, décimo quinto, vigésimo, vigésimo
quinto e trigésimo níveis. Os chefes certamente não precisam estar nesses níveis precisos, e cada
um pode ser ligeiramente deslocado para frente ou para trás na ordem dos níveis sem causar
problemas sérios. Se os chefes fossem colocados um nos últimos seis níveis do jogo, isso seria
obviamente desequilibrado. Parece estranho para os jogadores que depois de vinte e quatro níveis
de jogabilidade sem monstros, de repente eles tenham que lutar contra um em cada nível.

A maneira como o jogo é dividido em seus diferentes níveis e a ordem em que esses níveis
devem ocorrer difere de jogo para jogo. Para um jogo como Unreal, como nas séries Doom e Quake
antes dele, os designers foram instruídos apenas a fazer alguns níveis legais, com pouca preocupação
com a história (já que nenhum desses jogos realmente tinha uma) ou quais eventos deveriam
acontecer antes de quais outros eventos. Algum pensamento foi colocado em que ponto certos
adversários apareceriam pela primeira vez no jogo e, portanto, os níveis anteriores eram mais restritos
em quais criaturas eles poderiam usar. Da mesma forma, é claro, os níveis anteriores tinham que ser
mais fáceis e os posteriores, mais difíceis. Mas, na maioria das vezes, os designers de níveis apenas
tentaram fazer os níveis mais legais possíveis, quase trabalhando no vácuo dos outros designers.
Certamente eles veriam o trabalho um do outro e isso poderia inspirá-los a melhorar seus próprios
níveis, mas nenhum dos níveis realmente tinha que combinar tematicamente com os níveis que
vieram antes ou depois dele, e a falta de uma história significava que isso não afetar negativamente
o jogo.
Em jogos como Indiana Jones and the Infernal Machine, Knights of the Old Repub lic ou The
Suffering, no entanto, a história desempenha um papel muito maior. Para que a história funcione, os
níveis precisam apoiá-la. Portanto, para um jogo mais centrado na história, muito planejamento prévio
é feito pelas equipes de design e história do jogo sobre quais eventos da história precisam acontecer
em quais níveis. Em que tipos de ambientes esses níveis devem ocorrer? Que tipos de adversários
os jogadores vão lutar lá? A ordem em que os níveis aparecem no jogo não pode ser alterada tão
facilmente quanto em Doom, pois isso também mudaria radicalmente a história. Para que todo o jogo
flua e aumente em dificuldade adequadamente, o tipo de jogabilidade encontrado em cada nível deve
ser planejado com antecedência. Os níveis não precisam ser planejados nos mínimos detalhes, no
entanto, é melhor deixar isso para o designer de níveis, que pode colocar os encontros individuais,
objetos ou quebra-cabeças menores conforme melhor se encaixam no nível. Um mini documento de
design explicando o que o nível deve realizar para funcionar dentro da história do jogo permitirá que
o designer de nível saiba exatamente o que deve incluir no nível; a partir daí ela pode preencher os
detalhes.
Machine Translated by Google

454 Capítulo 23: Design de Nível

Em um jogo como
The Suffering, a história e
os níveis estão tão
entrelaçados que os níveis
não podem ser reordenados
e ainda fazem algum
sentido.

Os componentes de um nível
Uma vez que os níveis que um jogo precisa tenham sido decididos, possivelmente com alguma
ideia de como esses níveis devem apoiar a história, a próxima tarefa é realmente criar esses níveis.
Independentemente de sua localização no jogo como um todo, o objetivo de cada nível é fornecer
uma experiência de jogo envolvente para os jogadores. Ao trabalhar nos níveis de um jogo, é
importante ter em mente constantemente o foco do jogo. O que este jogo está tentando realizar?
Quão importantes são os diferentes aspectos do jogo? O que o nível precisará fazer para suportar
o tipo de jogabilidade que este jogo tem? Além disso, dependendo da quantidade de design de pré-
produção feito nos níveis, pode ser necessário considerar como esse nível pode ser reproduzido
de maneira diferente dos outros. É um nível de “pensamento” depois de um de ação intensiva?
Este nível é mais sobre exploração e descoberta do que construir a força do personagem ou
personagens do jogador? Em The Suffering, tomamos uma decisão consciente de destacar
algumas áreas em termos de tom e jogabilidade, como o nível do asilo.
Como esse nível estava localizado no meio do jogo, quando o atingiram, os jogadores se
acostumaram a um fluxo constante de combate e estavam prontos para algo um pouco mais lento
e mais orientado a quebra-cabeças.
Antes do início do design de níveis, a equipe de design deve reunir e detalhar os diferentes
componentes de jogabilidade do jogo, já que cada membro deve entender completamente como a
jogabilidade funciona. Para níveis específicos, isso pode significar que o designer líder faz um
mapa 2D aproximado da área e depois deixa o designer de nível terminar, ou pode significar que
o designer de nível elabora o mapa e o executa pelo líder. Não importa, cada designer de nível
deve entender como seu nível usará essa jogabilidade antes de começar a construir qualquer
coisa. Em alguns jogos é fácil fazer grandes mudanças no layout de um nível, como em um jogo
baseado em blocos como StarCraft. Se surgirem problemas com o nível, ele pode ser facilmente
retrabalhado. Para um jogo usando a última encarnação do motor Unreal , no entanto, uma vez
que um nível é construído e o departamento de arte poliu sua estética, é muito trabalhoso alterá-lo
radicalmente. Os produtores ficarão relutantes em investir
Machine Translated by Google

Capítulo 23: Design de Nível 455

mais um mês de tempo de construção de arquitetura para retrabalhar um nível porque não está
jogando bem. Portanto, entender com antecedência a jogabilidade do jogo e o nível em questão é
importante. Uma maneira talvez simplista, mas ainda útil, de quebrar os componentes da
jogabilidade de um nível é em termos de ação, exploração, resolução de quebra-cabeças, narrativa
e estética.

Um nível para a
última revisão do
sofisticado mecanismo
Unreal requer muito
mais trabalho do que um
para um jogo 2D mais
simples. Como resultado,
fazer alterações em um
nível Unreal é
significativamente mais
demorado. Retratado
aqui: Unreal Tournament
2004.

Açao

A ação é o componente mais óbvio dos níveis para muitos jogos e, de fato, para muitos títulos, o
elemento de ação é a única justificativa para a existência do nível. Claro que existem alguns jogos
que evitam totalmente o componente de ação, como muitos jogos de aventura ou quebra-cabeça,
mas quase todos os outros jogos contêm alguns componentes de ação, seja ele explodir demônios
em um jogo de tiro como Doom, incapacitar cogumelos ambulantes em Super Mario 64, matando
mutantes em Fallout, matando furtivamente um guarda em Metal Gear Solid, ou acelerando perto
dos carros dos oponentes em Need for Speed: Underground.

Qualquer que seja o componente de ação do seu jogo, o trabalho do designer de nível é
entender quanta ação o nível contém e em que ritmo esse componente de ação deve ser
apresentado aos jogadores. Qual porcentagem do seu nível deve ser cheia de ação e emocionante?
Quantas batalhas os jogadores irão lutar? O combate é rápido e furioso ou há “intervalos” ou
intervalos entre grandes conflitos? A linha de adrenalina dos jogadores deve estar bombando
durante todo o nível por causa de um medo constante da morte? É claro que a quantidade de ação
depende inteiramente do tipo de jogo que você está fazendo, mas, independentemente disso, você
precisa ter uma ideia clara da quantidade de conflitos que os jogadores encontrarão.

Para um jogo com muita ação, deve-se ter em mente como essa ação se desenrolará ao
construir os níveis. O designer de níveis deve considerar como a IA inimiga funciona e quais tipos
de mapas levarão aos conflitos mais interessantes. Que geometria dará aos jogadores muitos
locais para se abaixar e cobrir enquanto se esquiva do inimigo
Machine Translated by Google

456 Capítulo 23: Design de Nível

fogo? Como os níveis podem ser melhor configurados para encorajar os jogadores a descobrir
sua própria estratégia para derrotar a oposição? Saber que tipo de ação seu jogo terá e como
essa ação se desenrola melhor é fundamental para projetar níveis que tragam o melhor da
jogabilidade de ação.

Exploração
O que os jogadores farão quando não estiverem no calor da batalha? Exploração é uma parte
importante de muitos títulos de ação/aventura, como Tomb Raider ou Super Mario Bros. Em vez
de apenas fornecer uma ponte entre diferentes cenários de ação, se adequadamente projetada, a
exploração pode realmente ser muito divertida para os jogadores. Muitas vezes é difícil para a
equipe de design ver isso depois de trabalhar em um mapa por meses. Quão divertido é explorar
a arquitetura com a qual você já está dolorosamente familiarizado? Sempre tente ter em mente
que para os jogadores que experimentam um mapa pela primeira vez, a emoção de explorar um
novo mundo virtual pode ser bastante estimulante. Pode ser importante mostrar constantemente
seu nível para espectadores ou testadores de primeira viagem e obter feedback sobre se eles
gostam de explorar o nível ou não.
O designer deve ter em mente como os jogadores irão explorar o nível para saber a melhor
forma de desenhá-lo. Que obra de arte ou arquitetura legal os jogadores verão na próxima esquina?
Quão empolgados ou inspirados estarão os jogadores ao encontrar novas áreas? Tornar a
exploração emocionante uma parte do seu jogo vai além da criação de uma arquitetura emocionante
para os jogadores. Também é determinado por como o nível flui e o que os jogadores terão que
fazer para alcançar uma nova área empolgante. Ser jogado bem no meio de uma bela arquitetura
é muito menos satisfatório do que ter que navegar por uma grande área do mapa para finalmente
chegar a uma recompensa de exploração.
Parte de fazer o aspecto de exploração de um jogo funcionar é determinar o fluxo de um
nível. Os jogadores precisarão explorar várias ramificações de um caminho principal e crítico ou
geralmente terão apenas uma maneira de proceder? O caminho que os jogadores devem seguir
para completar o nível será óbvio no início, ou eles precisarão experimentar e procurar um pouco
antes de encontrá-lo? Jogos que são muito orientados para a ação tendem a colocar os jogadores em

Já em Super Mario Bros. no


Nintendo Entertainment System,
os jogos de Miyamoto incluíam a
exploração como um componente
chave da jogabilidade.
Machine Translated by Google

Capítulo 23: Design de Nível 457

um caminho que leva diretamente ao próximo conflito. Jogos que incentivam os jogadores a
bisbilhotar podem tornar o caminho menos óbvio.
Certa vez vi alguém criticar os jogos de Shigeru Miyamoto como sendo todos sobre
exploração e, portanto, jogos não muito bons. A observação de que a exploração é o foco do Mario
posterior foi correta. O erro foi afirmar que esta não é uma parte divertida da jogabilidade, como
milhões de fãs de Mario vão refutar. O desafio está em tornar a exploração divertida e
recompensadora para os jogadores, algo que os jogos de Miyamoto fazem com maestria.

Resolução de quebra-cabeças

Às vezes, progredir em um nível envolve mais do que apenas encontrar um caminho para a
próxima área enquanto mata os adversários que estão em seu caminho. Em vez disso, pode
envolver descobrir o que precisa ser feito para abrir uma certa porta ou remover um grande
obstáculo do caminho. Alguns dos exemplos mais simples disso são os quebra-cabeças “switch
flip” encontrados em muitos jogos de tiro em primeira pessoa mais antigos. Nesses jogos (muitas
vezes sem motivo específico) os jogadores precisam navegar por uma grande seção do mapa para apertar
Esta ação abre uma porta em outro lugar que leva os jogadores a outra área onde outro interruptor
precisa ser acionado. E por aí vai. Este interruptor pode ser uma chave ou qualquer outro objeto
que abra uma porta ou pode ser disfarçado como algum tipo de dispositivo que bloqueia o
progresso dos jogadores. Por exemplo, Call of Duty disfarçado alternando como colocar explosivos
em armas antiaéreas. Esta é a forma mais simples de quebra-cabeça em um jogo de ação/
exploração. Aqui o foco é principalmente nos jogadores explorando até encontrarem o quebra-
cabeça, com a solução do quebra-cabeça sendo trivial. No caso do interruptor, uma vez encontrado,
tudo o que os jogadores precisam fazer é girá-lo.
Alguns diriam que todos os quebra-cabeças são chaves no final, mas isso perde um ponto
importante e uma oportunidade para uma jogabilidade mais atraente. Variantes mais sofisticadas
na combinação de interruptor/porta podem ser situações que exigem que os jogadores realmente
descubram algo para progredir. Talvez um feixe de laser precise ser refratado em uma série de
cantos para que os jogadores sigam em frente. Para refratá-lo corretamente, os jogadores
precisarão mover várias placas refletivas. Os jogadores devem entender a física simples da
situação que governa como o feixe se comportará quando refletido de maneiras diferentes. Em The
Suffering, logo no início os jogadores chegam a um quebra-cabeça em que precisam bloquear um
portão que fica se fechando com uma grande estátua de pedra. Os jogadores precisam experimentar
o ambiente e a mecânica do jogo para resolver esse quebra-cabeça. Com desafios desse tipo, o
foco aqui muda de apenas encontrar o quebra-cabeça para encontrá-lo e então descobrir como
manipulá-lo corretamente. A experiência de jogo do jogador é aprimorada por esse quebra-cabeça
em vez de apenas atrasar o final de seu jogo. É importante ter em mente determinar quanta ênfase
seu nível terá na resolução de quebra-cabeças, especialmente no contexto do jogo como um todo.
Uma maneira certa de frustrar os jogadores é lançar de repente um monte de quebra-cabeças
arbitrários depois que o jogo inteiro até aquele ponto foi mais orientado para a ação.
Machine Translated by Google

458 Capítulo 23: Design de Nível

Narrativa
Em um jogo histórico
como Gettysburg!, a
jogabilidade está muito
ligada a uma história
particular da história.

O cenário é uma grande parte da narrativa, e os níveis são um componente vital para
estabelecer o cenário de um jogo. Portanto, os níveis são parte integrante de contar a história
de um jogo. Se a história é mais do que algo acrescentado a um jogo já concluído, só faz
sentido que os níveis do jogo e a história funcionem em sinergia. Dependendo do tipo de
narrativa que o jogo emprega, pode ser necessário que os jogadores conheçam e conversem
com personagens nos níveis, como em Half-Life ou em quase qualquer RPG. Configurar os
níveis para apoiar a aparência desses personagens se torna muito importante. Em alguns
jogos, é óbvio que os níveis foram projetados desde o início com a história em mente. Por
exemplo, em Myth: The Fallen Lords, os objetivos dos jogadores para um certo nível estão
diretamente ligados à progressão da história. Da mesma forma em The Suffering, mapeamos
toda a história e depois tentamos descobrir quais ambientes de nível interessantes funcionariam
dentro da narrativa. Em um jogo de guerra histórico como Gettysburg!, as batalhas que os
jogadores travam devem estar vinculadas à história, já que dificilmente poderia ser uma
simulação histórica de outra forma. De fato, qualquer jogo que espera contar uma história
realmente precisa ter certeza de que seus níveis suportam essa história; os jogadores
perceberão quando os níveis foram construídos à toa e mal estão conectados ao enredo do jogo.
Conhecer os objetivos da história para um determinado nível antes de construir esse
nível é crucial para comunicar a história de forma eficaz. A história ainda deve ser solta o
suficiente para permitir que o designer de nível seja criativo para criar o melhor nível possível.
Ainda existem preocupações sobre a jogabilidade – sobre equilibrar a quantidade certa de
estratégia, ação, quebra-cabeças e exploração – e como é quase impossível equilibrar esses
componentes antes que o nível realmente exista, o designer de nível não deve ser limitado
por um história restritiva. De fato, pode acontecer que a história precise mudar para acomodar
as necessidades de jogabilidade do nível, mas ter uma ideia de qual história precisa ser
contada em um determinado nível é essencial para projetar esse nível para que ele se encaixe
adequadamente no narrativa geral.
Machine Translated by Google

Capítulo 23: Design de Nível 459

Estética
A aparência e o som de um nível são provavelmente os fatores determinantes por trás do trabalho
de muitos designers de nível. E é fácil perceber porquê: a estética da superfície é sempre
comentada primeiro pela gestão, pela imprensa ou mesmo pelos jogadores. Eu certamente não
contestaria que a aparência de um nível é crucial para seu sucesso geral. Ao mesmo tempo, no
entanto, o componente estético se torna um problema quando a aparência do nível se torna a
principal preocupação do designer, uma situação que geralmente tem um efeito prejudicial sobre
como o nível é reproduzido. Suponha que um designer de níveis gaste muito tempo criando uma
enorme e linda catedral para um nível, e a aparência dessa catedral está constantemente na
vanguarda de sua mente. E se acontecer que a catedral é difícil para os jogadores navegarem, os
agentes de IA ficam facilmente confusos ao tentar encontrar o caminho, e toda a estrutura é um
pouco mais do que o mecanismo pode suportar, resultando em um nível lento? Se a catedral
parece ótima e sua construção consumiu muitas horas-homem, quem vai querer cortá-la? Isso
pode se traduzir em algumas capturas de tela fabulosas na parte de trás da caixa; pena que não
vai ser divertido jogar.
Uma grande parte do trabalho do designer de níveis é equilibrar a aparência com os outros
requisitos de um determinado nível, como listei acima. Há sempre um meio-termo alcançável onde
o nível parece bom, joga bem, renderiza rapidamente e atende às necessidades da história do
jogo. Os designers de níveis passam muito tempo aprendendo os “truques” de um determinado
mecanismo ou editor de níveis. O que eles podem fazer para usar o menor número de polígonos e
ainda ter uma boa aparência? Muitas vezes, as soluções que eles apresentam não são
necessariamente “reais”, mas sim “falsificadas”. É claro que todo o propósito de criar níveis para
um mundo virtual é criar conteúdo “falso”, então um designer de níveis não precisa se preocupar
se um efeito for alcançado por “fingir” algo. Se os jogadores não podem dizer que é falso, se eles
não podem ver por trás da cortina mágica, isso é tudo que importa. Um dos princípios por trás de
todos os efeitos especiais é criar algo que se pareça com algo que não é. O trabalho do designer
de níveis é fazer com que os jogadores vejam algo que se parece com algo que não é, dando o
nível que o designer de níveis Unreal Cliff Bleszinski chamaria de “schlack” e que outros chamam
de “cromo”: um revestimento brilhante e sofisticado sobre um nível desinteressante . Brilhante e
bonito não é necessariamente uma coisa ruim, apenas não deve ser usado para substituir uma jogabilidade
O lado visual de um nível pode ter um grande impacto nas outras preocupações do nível de
um jogo, como listei antes. Por exemplo, para tornar um nível jogável, as texturas em um nível
devem ser dispostas de tal forma que os jogadores possam ver onde devem ou não ir. Em vez de
se perguntar se uma determinada inclinação é muito íngreme para seu substituto no mundo do
jogo subir, uma textura diferente pode servir como uma dica visual para os jogadores sobre quais
inclinações são transitáveis e quais não são. A iluminação pode ser usada para esconder áreas
secretas, ou um grande quebra-cabeça no nível pode ser descobrir como acender as luzes. Se
certas áreas especiais devem ser recompensas pela exploração diligente, fazer com que essas
áreas especiais pareçam impressionantes é essencial para manter o interesse dos jogadores no
nível.
Muito tempo pode ser gasto na estética de um nível. A quantidade de tempo é diretamente
proporcional à complexidade do motor e do editor de nível usado, bem como ao efeito visual
desejado do nível. Na verdade, pode ser que todos os elementos de jogabilidade e história do nível
possam ser configurados primeiro e, em seguida, a aparência visual possa ser ajustada nas
próximas semanas. A iluminação pode ser ajustada infinitamente, as texturas podem ser alteradas
Machine Translated by Google

460 Capítulo 23: Design de Nível

ou trocados por outras texturas, e as faces do polígono podem ser ajustadas para representar melhor o
efeito visual que a equipe está tentando alcançar. De fato, o trabalho de design de níveis tornou-se tão
trabalhoso que muitas equipes de design começaram a passar o passe estético para a equipe de arte, uma
técnica usada no desenvolvimento de Halo e Half-Life 2. Não se preocupe com quem está fazendo o
trabalho estético , o designer de nível deve estar totalmente ciente dos efeitos que as mudanças na
aparência do nível terão na jogabilidade.

Equilibrando tudo
Como um bom nível deve equilibrar ação, exploração, resolução de quebra-cabeças, narrativa e estética, o
trabalho do designer de nível é um ato de equilíbrio. Mesmo que o nível pareça melhor de uma certa
maneira, como isso afeta a história que está sendo contada? Os requisitos da história para o nível significam
que ele não pode ter muito em termos de combate? Quão importante é o combate para o jogo, e o nível
pode sobreviver sem ele? A quantidade de elementos de quebra-cabeça no nível está impedindo os
jogadores de explorá-lo?
A ação, a exploração, a resolução de quebra-cabeças, a narrativa e as qualidades estéticas de um nível de
jogo têm interdependências, das quais o designer de níveis deve estar constantemente ciente e
constantemente mantendo. O preço de um bom design de nível é a vigilância eterna.

Fluxo de nível
Para diferentes tipos de jogos, o que um nível deve realizar muda significativamente. Considere jogos de
ação/exploração como Super Mario 64, Tomb Raider ou Doom. Embora a jogabilidade nesses três jogos
seja significativamente diferente, as funções que os níveis servem em cada um são notavelmente
semelhantes. Em todos esses jogos, os jogadores costumam jogar o nível de um ponto inicial distinto para
um ponto final separado. Uma grande parte de jogar o nível é explorar os espaços que ele contém e, como
resultado, uma vez que os jogadores tenham jogado o nível, é significativamente menos divertido jogar uma
segunda vez. Além disso, quaisquer encontros que os jogadores possam ter com personagens ou
adversários nesses níveis são cuidadosamente predeterminados e configurados pelo designer de níveis.
Toda vez que os jogadores jogam esse nível, eles terão aproximadamente a mesma experiência de jogo da
última vez que jogaram. O fluxo do nível é mais ou menos linear, com talvez apenas algumas opções de
como ir do ponto A ao ponto B.

Os RPGs oferecem aproximadamente o mesmo padrão de fluxo que os jogos de ação/exploração


discutidos acima, mas com um pouco mais de não-linearidade. O designer geralmente pretende que os
jogadores naveguem para um local específico de uma maneira específica. Os RPGs tendem a ser um pouco
mais não lineares do que os jogos de ação/aventura, geralmente permitindo que os jogadores escolham a
ordem em que as diferentes ações podem ser executadas. Muitas vezes, a jogabilidade no estilo “hub”
permite que os jogadores se ramifiquem em diferentes aventuras enquanto retornam a um local central,
como uma cidade. Os jogadores também podem ficar na cidade para aprimorar suas habilidades pelo tempo que quiserem
No final, porém, os RPGs oferecem fluxo de nível semelhante aos títulos de ação/aventura.
Em um nível de um jogo de estratégia como WarCraft ou Civilization, no entanto, a ação é menos
enlatada e o fluxo de nível é menos claramente definido. WarCraft e Civilization podem ser tão diferentes
um do outro quanto Super Mario 64 e Doom, mas a maneira como eles usam seus níveis é a mesma. A
exploração não é uma parte tão central da diversão desses jogos de estratégia, e as batalhas podem ocorrer
em qualquer parte do mapa. Diferentes locais podem fornecer vantagens estratégicas específicas quando
usados corretamente, mas as batalhas podem
Machine Translated by Google

Capítulo 23: Design de Nível 461

comece em um local e vá para outro, ou certas seções do mapa podem ficar completamente
inexploradas e inexploradas pelos jogadores e seus oponentes. A jogabilidade em tal mapa
geralmente é significativamente menos previsível do que no mapa de um jogo de ação/
exploração. O fluxo do nível é mais nebuloso.

O fluxo de um nível de
um jogo de estratégia
em tempo real como
WarCraft é menos definido
do que em um jogo de
ação/exploração:
encontros de combate
podem ocorrer em todo o
mapa.

Claro, há pelo menos uma característica distintiva que torna o fluxo de nível em Civilization
significativamente diferente do de WarCraft. Em Civilization, qualquer jogo consiste em jogar
em apenas um nível. Ou seja, os jogadores iniciam um jogo de Civilization em um nível e jogam
nesse nível até ganhar ou perder, enquanto em WarCraft os jogadores encontram uma série
de cenários em uma série de níveis. Civilization apresenta uma experiência de jogo muito mais
contínua para os jogadores, o que pode torná-lo muito mais viciante. Enquanto um jogo como
WarCraft apresenta aos jogadores um ponto de parada fácil - o fim de um nível - um jogo como
Civilization não tem essas interrupções. Ambos os tipos de jogos podem incluir níveis com
fluxos imprevisíveis, onde diferentes jogadores podem jogar os níveis de maneira
significativamente diferente, mas como os jogadores em Civilization passam todo o tempo em
um mapa, a sensação geral do jogo é radicalmente diferente. Claro, o fato de Civilization ser
baseado em turnos enquanto WarCraft é em tempo real também muda significativamente o
fluxo dos jogos, mas isso é uma mudança na jogabilidade e não uma mudança no design e uso
de níveis.
Voltando aos nossos jogos de ação/exploração, se tivéssemos que pegar um nível
multiplayer de death-match de um jogo como Quake, veríamos que o fluxo do nível é muito
mais próximo ao de um jogo de estratégia. Ou seja, explorar o nível é menos importante e o
combate pode ocorrer de maneiras completamente imprevisíveis em todo o mapa. De fato,
muitos jogadores de jogos multiplayer de partidas mortais encontrarão um mapa de que gostam
e o manterão, pelo menos por um tempo. Os jogadores precisarão ter explorado o mapa
completamente antes de realmente terem a chance de vencer uma partida mortal naquele
mapa, certamente ao jogar com jogadores mais experientes. A exploração e a memorização do
mapa podem ser parte integrante do metajogo na medida em que tal exploração leva à vitória
dos jogadores em jogos futuros, mas a exploração é apenas um meio para um fim, não um fim
em si mesmo, ao contrário de um jogo para um jogador onde a exploração é uma grande parte da divers
Machine Translated by Google

462 Capítulo 23: Design de Nível

Jogos de estilo “sandbox” como Grand Theft Auto, The Getaway ou True Crime são interessantes
em como eles combinam elementos de RPG, estratégia e fluxos de níveis de partidas mortais. Neles,
os jogadores precisam ir a locais diferentes para obter missões de pessoas, muitas vezes cobrindo
terrenos que percorreram anteriormente para chegar lá, assim como em um RPG.
E como um jogo de estratégia, as sequências de ação e combate podem fluir por todo o mapa
dependendo de onde a batalha acontece. Finalmente, como um mapa de combate mortal, os
jogadores só começarão a se destacar no jogo depois de memorizarem as ruas da cidade e, assim,
conseguirem chegar aos locais mais rapidamente.
Com exceção dos jogos de corrida, os jogos esportivos normalmente fornecem um fluxo de
ouvido muito não linear à sua jogabilidade. O fluxo dos níveis de um jogo de basquete se assemelha
mais aos níveis de uma partida de morte ou de um jogo de estratégia do que os mapas de um jogo
de ação/exploração. A ação ocorre em todo o nível ou quadra, com o movimento dos jogadores
fluindo para frente e para trás ao longo do nível, cobrindo o mesmo terreno, mas de maneiras únicas
e imprevisíveis. Explorar o nível é relativamente sem importância, pois a forma do nível é
completamente simples e normalmente a quadra inteira ou uma grande parte dela está na tela de
uma só vez.
Em um jogo de corrida, os jogadores se movem de um local de início distinto para um local de
término distinto. Esse movimento é bastante semelhante a um jogo de ação orientado à exploração,
como Doom, com as principais diferenças de que normalmente os locais de início e fim da corrida
são os mesmos (os loops da pista) e geralmente o caminho da corrida é repetido várias vezes antes
que o nível seja sobre. Embora haja uma boa dose de não-linearidade em termos de jogabilidade e
como os jogadores correm contra seus oponentes, o fluxo de nível é ainda mais linear do que em um
título de ação/aventura. Jogos de corrida modernos, como Project Gotham Racing ou Cruisin' World,
incorporam alguns dos elementos de exploração de jogos de ação/exploração, tornando os níveis
visualmente impressionantes e variados, tornando a primeira vez que os jogadores dobram uma
esquina uma experiência esteticamente emocionante. Jogos de corrida mais antigos (como o
venerável Pole Position) dependiam mais do desafio de navegar na pista para entreter os jogadores
do que da emoção de correr por locais novos e fantásticos. Muitos jogos de corrida mais modernos
também incluem caminhos alternativos ou atalhos que os jogadores podem usar para obter resultados
de jogabilidade variados. Os jogos SSX , que são jogos de corrida apesar de não envolverem carros,
são particularmente bons em fornecer uma grande variedade de caminhos secretos para os jogadores
explorarem. O fluxo ainda está na mesma direção geral, mas algumas ramificações permitem que os
jogadores se concentrem em mais do que apenas quão firmemente eles podem fazer uma determinada curva.
Da minha discussão sobre esses gêneros de jogos e a maneira como a jogabilidade flui em
seus respectivos níveis, pode-se dividir os jogos em aproximadamente dois grupos: aqueles com
níveis mais lineares (ação/aventura, role-playing e jogos de corrida) e aqueles com mais experiências
de jogo não lineares e imprevisíveis (jogos de estratégia, esportes e jogos de morte para vários
jogadores). Claro, isso não quer dizer que os dois não se sobreponham. Por exemplo, níveis
específicos de StarCraft fazem de tudo para incentivar os jogadores a jogá-los em um caminho
específico, especialmente os níveis internos de equipes pequenas. Da mesma forma, muitos mapas
do Super Mario 64 permitem vários caminhos viáveis que os jogadores podem usar para jogá-los. Se
o designer for criativo o suficiente em seus esforços, a distinção entre os dois tipos de níveis pode
ser borrada, o que muitas vezes pode levar a uma jogabilidade mais variada e interessante.
Machine Translated by Google

Capítulo 23: Design de Nível 463

Elementos de Bons Níveis


À medida que você projeta um nível, há um número aparentemente infinito de detalhes que você deve manter em
mente. Você deve se preocupar em equilibrar os elementos de ação, exploração, solução de quebra-cabeças,
narrativa e apelo estético. Você deve trabalhar com os artistas e
programadores para obter os efeitos desejados. Para níveis 3D, você deve certificar-se de que o
todo o nível é otimizado para que possa ser executado no sistema de destino. E na pior das situações, você tem
que lidar com ferramentas de design de nível indisciplinadas que parecem frustrar todos os seus
tentar fazer algo legal.
Frequentemente, um designer de níveis apresenta regras práticas a serem seguidas ao fazer um
nível, mesmo que ela não as escreva. Cada designer terá sua própria lista de
“fazer” e “não fazer” que ela guarda em sua mente, e essa lista pode mudar significativamente de projeto para
projeto. Alguns jogos terão suas próprias “regras de design”
estabelecido com antecedência e que os projetistas podem seguir, mas também há
regras que podem ser aplicadas a qualquer projeto. Aqui apresento uma lista parcial de minhas próprias regras, que
use para tentar fazer um nível que seja estimulante para jogar.

Os jogadores não podem ficar presos

Isso deve ser óbvio, mas é um erro frequente de designer novato. Os jogadores devem
nunca fique irremediavelmente preso ao jogar o seu nível. Não deve haver poços que
pode cair, mas não sair, nenhum objeto que, quando movido incorretamente, bloqueie permanentemente o
progresso dos jogadores, e nenhuma porta que não abra se os jogadores se aproximarem
eles de uma certa maneira. Embora esse objetivo possa parecer perfeitamente óbvio, na verdade consumirá uma
grande quantidade de seu tempo como designer de níveis. Considere um quebra-cabeça onde os jogadores
tem uma certa quantidade de dinamite, e essa dinamite precisa ser usada para abrir um buraco
uma parede para que os jogadores possam progredir no nível. E se os jogadores usarem toda a sua dinamite
explodindo as coisas erradas? Sem mais dinamite, os jogadores agora estão completamente presos. Da mesma
forma, suponha que os jogadores precisem falar com um NPC em particular para obter um
determinado objeto. E se, em vez de falar com esse personagem, os jogadores o matarem? Qualquer
o jogo deve terminar quase instantaneamente, ou deve haver alguma maneira alternativa de progredir
através do jogo. Projetar seu nível de tal forma que, não importa o que os jogadores façam, eles
ainda pode terminar o nível, leva muito pensamento e planejamento. Como designer de níveis, você
deve estar sempre se perguntando: “Mas e se os jogadores tentarem dessa maneira?”

Sub-objetivos

À medida que os jogadores jogam um nível, eles devem ter sub-objetivos compreensíveis. Em vez de jogar todo o
nível apenas tentando chegar à saída ou atingir algum objetivo grande,
os jogadores devem ser capazes de reconhecer que existem várias tarefas que podem realizar
que contribuem para o objetivo final. Um exemplo muito simples disso seria os diferentes
chaves em Doom. Os jogadores sabem que, uma vez que obtêm a chave azul, estão muito mais próximos
para terminar o nível. Em um jogo de corrida arcade como o San Francisco Rush, em vez de ter apenas uma linha
de chegada por pista, a maioria dos jogos tem vários “pontos de verificação” ao longo do percurso.
rastreie em que jogadores recebem um bônus de tempo e são informados de quão bem eles estão indo.
Em um RPG, os jogadores podem estar trabalhando para derrotar uma força maligna que está atormentando a terra,
mas ao longo do caminho eles são capazes de ir em várias missões secundárias para aldeões que precisam de seus
Machine Translated by Google

464 Capítulo 23: Design de Nível

Em jogos de corrida como a


série San Francisco Rush ,
os jogadores recebem sub-
objetivos através de
checkpoints, que concedem
mais tempo.
Retratado aqui: San
Francisco Rush: The
Rock — Alcatraz Edition.

ajuda. Essas várias missões secundárias levam os jogadores em direção ao objetivo maior e
fornecem aos jogadores um feedback positivo de que eles estão, de fato, jogando bem o jogo.
Plataformas como Ratchet & Clank são particularmente boas em liderar jogadores através dos
níveis com seus muitos captadores, com a aquisição de cada um basicamente sendo um
pequeno sub-objetivo. Um sub-objetivo é inútil se os jogadores não entenderem o que
realizaram. Portanto, também é importante fornecer aos jogadores algum tipo de recompensa
por atingir o objetivo, seja sinos e apitos audiovisuais, uma nova arma, pontos de bônus ou
mais tempo no relógio de corrida. Se o designer não fornecer sub-objetivos suficientes em um
determinado nível ou se esses sub-objetivos forem tão transparentes que os jogadores não
percebam que os atingiram, os jogadores podem ficar confusos sobre o que deveriam estar
fazendo e se eles estão cada vez mais perto do sucesso.

Pontos de referência

Quanto mais complexo for o seu nível, mais os jogadores ficarão confusos ao navegar nele.
A menos que a confusão seja seu objetivo, o que normalmente não deveria ser, é uma boa
ideia configurar pontos de referência memoráveis em seu nível para facilitar a exploração dos
jogadores. Um marco é qualquer objeto único em seu nível que os jogadores reconhecerão na
segunda vez que o virem, seja uma sala particularmente ornamentada, uma grande estátua ou
uma piscina de lava fumegante. Em termos de exploração, então, quando os jogadores
retornarem a esse ponto de referência, eles saberão que estão retornando a um local que
visitaram anteriormente e, assim, começarão a entender o layout do nível. Os pontos de
referência não precisam necessariamente ser grandes sinais vermelhos rotulados como
“Checkpoint A”, mas podem ser trabalhados na história e na configuração do próprio nível. Por
exemplo, Grand Theft Auto III tornou a grande Liberty City muito mais fácil de aprender a
navegar, incluindo muitos edifícios grandes e únicos como parte do mapa. Cada um desses
marcos, além de ajudar o jogador a aprender o nível, apoiou perfeitamente a ficção do jogo.
Machine Translated by Google

Capítulo 23: Design de Nível 465

Caminho crítico

Mesmo sendo um grande defensor da jogabilidade não linear, também sou um grande fã de um
bom caminho crítico em um nível. Um caminho crítico dá aos jogadores um senso de direção que
eles podem usar para completar o nível. Essa direção pode ser uma direção física, como “ir para
o norte” ou “ir para o arco-íris”, ou pode ser um objetivo mais ambíguo, como encontrar uma
criatura e derrotá-la ou recuperar um objeto importante. Sempre dar aos jogadores um objetivo
principal a cumprir é crucial para tornar seu nível jogável. Os jogadores devem ter um objetivo e,
como discuti, sub-objetivos que trabalhem para atingir esse objetivo principal.
Os jogadores devem sempre estar cientes do objetivo e dos sub-objetivos relacionados, e devem
sempre ter uma noção do que podem fazer para progredir no nível. Objetivos secundários
opcionais separados podem ser menos óbvios ou ocultos, mas nada frustra mais os jogadores do
que não ter ideia do que devem fazer. Ter um caminho crítico claramente estabelecido é uma boa
maneira de ajudar a evitar que os jogadores fiquem confusos.

Retrocesso Limitado Se o
seu jogo depende da exploração para uma grande parte de seu valor de jogabilidade,
provavelmente é uma má ideia fazer os jogadores retrocederem por grandes seções do
nível que eles já exploraram para continuar no jogo. Isso não quer dizer que seu nível
não possa ter caminhos de ramificação para os jogadores explorarem. Significa apenas
que cada ramo deve retornar ao caminho principal sem que os jogadores precisem
voltar ao longo do mesmo caminho. Se o seu jogo é mais um jogo de RPG ou aventura
onde criar a ilusão da realidade é importante, a necessidade de retroceder pode ser mais aceitá
Grand Theft Auto III é certamente um exemplo de um cenário realista que resulta na necessidade
de retrocesso, embora o jogo melhore a situação tornando a condução pela cidade divertida, não
importa quantas vezes você faça isso. Certamente em um jogo de RTS, esportes ou death-match,
os jogadores estarão cobrindo o mesmo terreno repetidas vezes, mas o apelo de um jogo de
basquete ou WarCraft não está tão ligado à exploração quanto Super Mario 64, que faz um muito
bom trabalho de eliminar totalmente a necessidade de retrocesso.

Sucesso pela primeira vez

Se a maioria dos jogadores consegue superar o seu nível na primeira vez que o joga, você
provavelmente fez um nível muito fácil. No entanto, deve existir a possibilidade de os jogadores
conseguirem passar pelo seu nível na primeira tentativa. Não quero dizer, no entanto, que os
jogadores possam fazer todas as escolhas certas apenas por acaso. Em vez disso, você deve
fornecer dados suficientes aos jogadores para que eles tenham uma chance razoável de evitar
todos os obstáculos colocados em seu caminho se forem observadores e perspicazes o suficiente.
Sempre que os jogadores falharem em seu nível, eles devem sentir que tiveram uma boa chance
de evitar essa falha se tivessem sido mais observadores ou tivessem pensado mais antes de agir.
Nada frustra mais os jogadores do que perceber que a única maneira de passar de nível é por
tentativa e erro combinado com sorte cega. Claro, seu nível ainda pode ser difícil. Suas pistas
sobre o que fazer podem ser bastante sutis, os monstros a serem derrotados podem ser muito
fortes, ou as escolhas a serem feitas podem ser realmente desafiadoras, mas se os jogadores
fizerem tudo perfeitamente, eles devem ser capazes de passar pelo seu nível primeira vez que
jogam.
Machine Translated by Google

466 Capítulo 23: Design de Nível

Áreas navegáveis claramente marcadas


Os jogadores devem ter uma ideia clara de onde poderão ir no nível simplesmente observando o
ambiente. As encostas nas quais os jogadores deslizarão devem parecer significativamente mais
íngremes do que as encostas nas quais podem ser percorridas. As texturas podem ser usadas para
diferenciar entre as áreas em que os jogadores podem navegar e aquelas em que não podem. Pode ser
muito frustrante para os jogadores quando uma área que parecia não ser navegável se torna a única
saída de uma área específica. Outro exemplo pode ser uma sala com dez portas.
Os jogadores tentam três dessas portas e todas estão trancadas. Neste ponto, os jogadores
provavelmente concluirão que as portas estão lá apenas para exibição e pararão de tentar qualquer uma
das outras portas. Nenhuma informação, seja visual ou através de uma pista verbal, é dada aos jogadores
para indicar que as outras portas podem ser abertas quando as três primeiras que eles tentaram não
foram. Se a única saída desta sala for pela única porta destrancada, sugiro que esta área foi mal
projetada. A única maneira de sair de tal sala é através de tentativa e erro tedioso. A diversão em um
jogo pode envolver tentar chegar a certas áreas ou a emoção de correr por essas áreas, mas há pouca
diversão em determinar quais áreas o designer decidiu arbitrariamente que poderiam ser navegadas e
quais não poderiam.

Escolhas
Isso pode parecer óbvio, mas as escolhas são algo que os designers de nível muitas vezes esquecem
de ter em mente enquanto estão construindo seus níveis. Bons níveis dão aos jogadores opções de
como atingir os objetivos, assim como uma boa jogabilidade dá aos jogadores muitas opções de como
eles vão jogar o jogo. As escolhas não significam necessariamente vários caminhos através de um nível,
embora isso também possa ser uma boa ideia. Em um jogo de tiro em primeira pessoa, as escolhas
podem significar dar aos jogadores opções diferentes de como eliminar todos os inimigos em uma sala –
muitos lugares diferentes para se esconder, locais diferentes de onde os inimigos podem ser atingidos e
assim por diante. Essa configuração cria uma variedade de estratégias diferentes que derrotarão com
sucesso a horda de demônios que avançam. As escolhas também podem significar objetos bônus que
são desafiadores para os jogadores obterem, como um lançador de foguetes no meio de uma piscina de
lava – os jogadores têm a opção de arriscar ou não. Em um jogo de estratégia, escolhas interessantes
significam diferentes lugares onde as batalhas podem acontecer ou diferentes lugares que os jogadores
podem escolher para reunir suas tropas ou reunir recursos. Nos jogos de aventura, o gênero mais notório
por não dar aos jogadores opções suficientes, as escolhas significam várias soluções para os quebra-
cabeças do jogo, personagens diferentes para conversar e muitas maneiras diferentes de se mover no
jogo. De fato, se um designer vai adicionar opções aos seus níveis, é importante que ele tenha certeza
de que está adicionando opções interessantes. A decisão de ir para a esquerda ou para a direita em
torno de um pilar é uma escolha, mas se ambos levam ao mesmo lugar e produzem basicamente a
mesma experiência, a escolha não é muito interessante. Se um lado do pilar está pegando fogo enquanto
o outro lado tem um bandido intimidador guardando, a escolha é mais interessante. Os jogadores ficam
frustrados quando sentem que estão presos a apenas uma maneira de jogar, especialmente se essa não
for a maneira como gostariam de jogar.

Uma lista pessoal


Certamente a lista que forneci acima está longe de ser completa. À medida que você trabalha como
designer de níveis, faz sentido estabelecer sua própria lista de metas de design a serem lembradas enquanto
Machine Translated by Google

Capítulo 23: Design de Nível 467

criando seu nível. Conforme você trabalha em níveis que são bem recebidos por seus colegas ou
jogadores, tente analisar os níveis para ver o que você fez bem. Em seguida, tente abstrair essas
realizações em uma lista de metas a serem lembradas ao trabalhar nos níveis subsequentes.
Esta lista não precisa necessariamente ser formalmente escrita; apenas manter uma lista de
verificação mental pode ser suficiente. As opções que listei aqui podem ser um começo para sua
própria lista, ou você pode encontrar um conjunto de metas completamente diferente. Cada designer
aborda o design de níveis à sua maneira.

O processo
O processo de construção de um nível pode variar muito de designer para designer. O que funciona
para uma pessoa pode não funcionar para outra. Cada equipe provavelmente terá seu próprio
processo e método para construir um ambiente. Dito isso, descobri que a seguinte progressão de
etapas funciona bem para mim. Posso nem sempre seguir os passos com precisão, mas de um modo
geral, essa progressão produz resultados mais consistentes e eficientes do que apenas iniciar um
nível sem nenhum plano do que fazer primeiro ou como proceder.

Etapa 1. Preliminar
Antes de iniciar
o desenvolvimento de
um jogo de ação/exploração
como os encontrados na
série Tomb Raider , é
importante ter um conjunto
de movimentos claramente
definido para o jogador.

Antes de começar a projetar um nível para o jogo, pergunte a si mesmo se a jogabilidade está em um
estado próximo ao final. Você tem uma base sólida para construir? Sua mecânica de jogo está bem
definida? O jogo vai mudar tanto que o nível que você projeta não será mais divertido de jogar? Ou
pior, o nível não será mais jogável? Por exemplo, suponha que você esteja desenvolvendo uma ação/
aventura em terceira pessoa como Tomb Raider. Antes de começar a criar um nível para o jogo, você
precisa determinar quão final é o movimento do personagem principal. Mais movimentos para o
personagem serão adicionados?
Será que algum dia a heroína do jogo será capaz de dar um salto duplo para frente que mudará
radicalmente a distância que ela poderá pular? Muitas vezes, quando você começa a trabalhar em um nível
Machine Translated by Google

468 Capítulo 23: Design de Nível

o jogo em si está longe de ser completo, e algumas mudanças provavelmente serão feitas no
movimento do personagem principal. Mas se a equipe está ciente de que mudanças radicais no
modelo de movimento do jogador serão feitas, ter designers de nível começando a trabalhar em
níveis é um grande erro.
Em um projeto em que trabalhei, começamos a trabalhar nos níveis antes que a habilidade do
personagem principal de pular fosse adicionada ao jogo. Como resultado, uma vez que foi
adicionado, voltamos e tivemos que modificar os níveis para incluir áreas que usariam essa
habilidade de salto. Infelizmente, depois que o salto estava no jogo por um tempo, ficou claro que o
salto não era muito divertido e que teríamos que voltar aos níveis e remover muitos dos saltos que
havíamos feito. o resultado final não foi tão limpo como se soubéssemos desde o início como o salto
funcionaria. O problema aqui era que a produção havia começado nos níveis antes que a mecânica
do jogo fosse suficientemente elaborada, implementada e seu nível de diversão verificado. Como
discuti no Capítulo 15, “Colocando a jogabilidade funcionando”, você provavelmente precisará ter
um nível em andamento enquanto trabalha na implementação da jogabilidade, para poder testar
diferentes comportamentos à medida que são adicionados. Mas trabalhar em mais do que um nível
específico é uma perda de tempo que pode ser prejudicial para o projeto a longo prazo. Além disso,
pode fazer sentido descartar o nível de teste assim que a jogabilidade estiver firmemente
estabelecida, já que esse nível preliminar geralmente acaba longe de ser o melhor trabalho de que
você é capaz.

Etapa 2. Esboço Conceitual e Esboçado Antes de começar


a trabalhar em um nível, acho que é muito importante entender o que esse nível precisará
fazer do ponto de vista da jogabilidade e da história. Que tipo de desafios os jogadores
enfrentarão aqui e que tipos de ambientes facilitam melhor esses desafios? Quão
emocionante e estressante é a jogabilidade neste nível? Onde os jogadores precisarão ser
recompensados? Quais elementos da história precisam ser transmitidos através do nível?
Em todos os momentos, mas especialmente durante a fase de planejamento, você deve
ter em mente o foco do jogo e como seu nível funcionará para apoiar esse foco.
Uma vez que o designer tenha alguma noção do que o nível deve realizar, um esboço a lápis e
papel do layout geral do nível é uma boa ideia. Isso evita os perigos de “se projetar em um canto”.
Digamos que você esteja projetando um prédio em um complexo militar para um jogo de tiro em
primeira pessoa totalmente em 3D. Em seu complexo, você precisa incluir uma sala com um grande
gerador. Quando você começa a fazer a arquitetura para o prédio, primeiro desenha todos os
corredores, depois começa a trabalhar em algumas das salas mais frias antes de finalmente chegar
à sala do gerador. Então, opa, acontece que você não deixou tanto espaço quanto necessário para
o gerador. A sala agora é muito pequena para ser facilmente navegável. Infelizmente, a única
maneira de torná-lo grande o suficiente envolve rasgar muitos dos corredores que você já fez. Nesse
ponto, alguns projetistas apenas moveriam a sala do gerador para um local menos lógico ou menos
ideal, em vez de ter que refazer muita geometria que eles já gastaram tempo construindo. É claro
que um esboço de nível nem sempre pode evitar esse problema, mas, se feito corretamente, pode
indicar ao projetista o quão pequena era a sala do gerador em um momento em que torná-la maior
envolve apenas o uso da borracha em seu lápis. As alterações em um esboço são muito mais fáceis
de fazer do que as alterações em um nível totalmente construído. Um esboço também pode ser
valioso como algo que você pode mostrar ao seu líder de equipe, que pode querer dar uma olhada
para ter certeza de que você está certo
Machine Translated by Google

Capítulo 23: Design de Nível 469

acompanhar o resto da equipe e o jogo como um todo.

Etapa 3. Arquitetura Base/ Bloqueio

À medida que os
mecanismos de jogo
se tornam mais
sofisticados, a quantidade de
tempo necessária para construir
um nível aumenta drasticamente.
Por exemplo, um nível
profissional usando o mecanismo
Quake III Arena levará semanas
para ser concluído facilmente.

Quando estiver satisfeito com seu esboço, a construção real do nível pode começar.
Esta etapa de construção varia em tempo e escopo dependendo da complexidade do nível que
está sendo criado. Por exemplo, um mecanismo 2D baseado em blocos permitirá uma construção
muito mais rápida de um nível do que um mecanismo 3D. Da mesma forma, a complexidade do
mecanismo 3D usado alterará radicalmente quanto tempo é necessário para construir o nível.
Um excelente mapa feito com o motor Doom pode ser feito em um dia ou dois. Um nível de
qualidade semelhante feito com o motor Quake III muito mais sofisticado pode facilmente levar
semanas de trabalho duro.
Neste ponto, lembre-se de que você está apenas criando o layout base para o seu nível.
Você não está adicionando detalhes como iluminação ou texturização, nem está se concentrando
em tornar a geometria o mais bonita possível. Nesta primeira passagem, você deseja obter o
nível até o ponto em que os jogadores possam navegar por ele e todos os locais sejam acessíveis.
Neste ponto, faz sentido usar texturas temporárias e formas primitivas de geometria.
Em vez de colocar uma cadeira real no jogo, basta colocar uma caixa com a escala apropriada.
Isso permite que você tenha uma noção se o layout do nível está certo sem perder mais tempo
do que o necessário.

Passo 4. Refinar a arquitetura até que seja divertido


Neste ponto, você precisa repetir o passo três até que seu nível comece a parecer bom e
navegar nele comece a ser divertido. Por exemplo, se você estiver trabalhando em um
jogo de tiro em primeira pessoa, você deve experimentar a navegação de seu personagem
pelo mundo 3D e ver se os cantos são divertidos para girar, se os saltos são da dificuldade
certa e se as áreas saem no tamanho que você queria. Dê uma olhada no nível como um
todo e veja se faz sentido e flui como você esperava. Uma vez que você realmente passe
algum tempo olhando e navegando no nível como os jogadores fariam, em vez de apenas brincar
Machine Translated by Google

470 Capítulo 23: Design de Nível

com ele no editor de níveis, você tem mais chances de determinar se o seu nível está funcionando.
Se o nível não estiver funcionando como você deseja, agora é a hora de fazer alterações até que
isso aconteça.

Passo 5. Jogabilidade Base


Agora que seu nível parece certo em termos de navegação do jogador, é hora de
começar a implementar a jogabilidade que seu nível usará. Certamente você tinha a
jogabilidade em mente em todas as etapas deste processo e planejou tudo antes mesmo
de começar a construir, mas agora é a hora de ver se realmente funcionará como você
esperava. Os melhores designers podem ter ideias e esboços para níveis cujo sucesso
se traduz totalmente em níveis divertidos no final. Outros começam com um esboço,
constroem alguma arquitetura e, quando chega a hora de adicionar a jogabilidade,
descobrem que precisam fazer algumas modificações significativas no que já
construíram. Com a experiência vem a capacidade de prever se as ideias abstratas se
tornarão divertidas ou não. Antes de se tornar experiente, no entanto, o processo envolve muita ten

Configurar a jogabilidade
em um nível de um jogo
como Duke Nukem 3D
consiste em colocar
monstros e armas e
configurar quebra-cabeças.

A jogabilidade de um nível consiste em quaisquer ações que os jogadores possam realizar


nesse nível. Em um jogo de tiro em primeira pessoa como Duke Nukem 3D, isso significa colocar
os monstros que os jogadores atirarão e os itens que os jogadores pegarão. Em um jogo de RPG
ou aventura, isso é expandido para incluir quaisquer quebra-cabeças que os jogadores precisem
resolver, os personagens com os quais os jogadores podem conversar e as missões nas quais
esses NPCs enviam os jogadores. Em um jogo de estratégia em tempo real, o designer precisará
descobrir o posicionamento inicial das unidades e as quantidades para os jogadores e seus
oponentes, bem como quaisquer reforços que possam aparecer mais tarde no nível. De certa forma,
títulos de esportes e corridas têm mais facilidade com essa etapa, pois sua jogabilidade é a mesma
de nível para nível e, portanto, não precisa de muita configuração para um estádio ou pista específico.
Machine Translated by Google

Capítulo 23: Design de Nível 471

Passo 6. Refinar a jogabilidade até que seja divertido


Claro, a jogabilidade é o que faz ou quebra o jogo, por isso é absolutamente essencial que o
designer repita o passo cinco até que o nível seja divertido de jogar. Às vezes, refinar a
jogabilidade pode levá-lo de volta ao passo número três. Pode acontecer que a área que você
pensou que funcionaria bem não seja adequada às capacidades da IA. Ou que a criatura que
você pensou que seria capaz de saltar de uma fissura em um penhasco não tem espaço
suficiente para se esconder. Você pode precisar alterar o layout do seu nível para compensar
os problemas que descobrir quando começar a implementar a jogabilidade.

Para alguns designers, modificar a arquitetura de nível existente para se adequar à jogabilidade
pode ser um processo bastante doloroso. Por exemplo, suponha que um designer construa alguma
arquitetura com a qual esteja satisfeito do ponto de vista estético. Se a jogabilidade não funcionar
nesse espaço, o designer pode relutar em voltar e retrabalhar essa geometria e, em vez disso, pode
se contentar com uma jogabilidade abaixo do padrão. Claro, esta é a escolha errada a fazer. Por
mais doloroso que seja, para obter a melhor jogabilidade, talvez seja necessário jogar fora parte do
seu trabalho. É por isso que sugeri apenas fazer a arquitetura base sem refiná-la demais; dessa
forma, fazer mudanças radicais no nível não significa que muito trabalho foi desperdiçado. No final,
a jogabilidade deve sempre superar todas as outras considerações, seja estética, história ou
tecnologia. Se não for divertido no final, nada mais importa.
Portanto, é lógico que você deve primeiro se divertir no nível antes de gastar muito tempo em outros
aspectos do nível.
Este é o passo em que seu nível realmente se reúne e você começa a ter uma noção se é um
sucesso. Agora você pode pegar este espaço que você criou e realmente começar a jogar nele. Se
você não começar a se divertir neste momento, talvez seja necessário dar uma olhada no seu nível
e se perguntar por que não é divertido jogar. Na pior das hipóteses, você pode perceber que o nível
nunca será divertido e, como resultado, você precisa começar do zero. Idealmente, no entanto, este
estágio pode ser verdadeiramente revelador, pois todo o trabalho que você coloca no nível começa
a se unir e a valer a pena.

Passo 7. Refinar a Estética Agora


que o nível está jogando bem, você tem a oportunidade de fazer com que pareça bom também.
Você deve se lembrar que nas etapas três e quatro nós apenas configuramos a arquitetura básica,
o suficiente para permitir que os jogadores naveguem e para dar uma ideia do nível. Agora é a hora
de texturizar seu nível conforme necessário, aplicar efeitos de iluminação, adicionar objetos
decorativos e realmente aprimorar seu nível do ponto de vista visual. Dependendo do seu processo
de desenvolvimento, este pode ser o ponto em que você entrega o nível a um artista. Muitas equipes
passam a maior parte do tempo trabalhando na estética de seus níveis, e certamente você deve
dedicar tempo para que o nível pareça o melhor possível. Mas, como enfatizei, é crucial que você
adie o aprimoramento do nível até ter certeza de que o nível funciona bem e que cumpre seus
objetivos de jogabilidade. Caso contrário, você pode perder seu tempo fazendo áreas bonitas que
acabam sendo descartadas. Como você está aprimorando o nível esteticamente, você deve sempre
se lembrar de não quebrar nenhuma jogabilidade que você já configurou.
Machine Translated by Google

472 Capítulo 23: Design de Nível

Passo 8. Teste de jogo


Agora que todas as partes do seu nível estão no lugar, é hora de mostrá-lo a outras pessoas,
deixá-los jogar e obter algum feedback. O teste de jogo é uma parte crucial do design de
jogos, e o design de níveis não é diferente. Esses assuntos de teste podem incluir outros
membros de sua equipe, mas também devem incluir pessoas menos intimamente envolvidas
com seu projeto. Muito pode ser dito para um novo par de olhos olhando para o seu jogo e
seu nível e dando-lhe feedback sobre se a jogabilidade cumpriu o que você esperava.
Testar um nível pode ser tão fácil quanto dar um nível a alguém, pedir-lhe para
jogá-lo e fazer com que ela lhe diga o que pensa. Outro método útil, especialmente
para teste de nível, é estar lá com o testador quando ele tentar jogar seu nível e
observar como ele joga. Ela fica presa em locais que você não tinha pensado? Ela
tem dificuldade em encontrar o caminho de volta? As situações de jogo fornecem a
ela um desafio suficiente? Observar outras pessoas jogando seu nível pode ser
extremamente educativo e informativo sobre se o nível flui e se joga bem.
Na pior das hipóteses, o teste de jogo pode revelar que seu nível não é tão divertido de
jogar quanto você pensava, e que uma grande reformulação será necessária para torná-lo
divertido. Como designer, você não deve resistir quando alguém lhe disser que seu nível é difícil
de navegar, confuso ou simplesmente sem graça. Certamente, obtenha uma segunda, terceira
e quarta opinião sobre isso, mas quando você começar a ouvir as mesmas reclamações de
várias pessoas diferentes, você precisa perceber que pode haver alguma verdade em seus
comentários e seu nível pode precisar de uma séria reformulação. Muitos designers que
investiram muito tempo e energia em um nível acham muito difícil receber críticas ao seu
trabalho. Não há como negar que ouvir alguém destruir o valor de um mês de trabalho pode ser
desanimador, mas esse é o objetivo do playtest. Você precisa levar a sério os comentários de
seus testadores, reconhecer os problemas com seu nível e começar a trabalhar no nível
novamente. Testes de jogo completos muitas vezes podem ser a diferença entre um nível meramente bom e
1.

Variações do Processo

É claro que o processo de design de nível que descrevo acima não é a única maneira de fazer um
nível. Assim como os “prós” e “nãos” do design de níveis que descrevi anteriormente, cada designer
de níveis precisa encontrar o método que funciona melhor para si e para sua equipe. Muitos bons
designers usam um método não totalmente diferente do que descrevi acima, mas com variações
que melhor se adequam ao seu próprio estilo de design.
Uma variação potencialmente útil é incorporar as etapas de três a seis. Em vez de colocar
todo o nível, você pode começar com uma sala ou área específica. Então, antes de prosseguir
para configurar o resto do nível, tente configurar a jogabilidade apenas nessa área. Quando
estiver satisfeito com o desempenho dessa seção, passe para a configuração do resto do nível,
adicionando jogabilidade às áreas à medida que você as cria. Dessa forma, se uma área tiver
que ser ampliada para que a jogabilidade funcione corretamente, menos trabalho será
desperdiçado, pois as áreas ao redor podem não ter sido construídas ainda. Como mencionei
antes, é importante ter cuidado para não se projetar em um canto. Você não quer gastar muito
tempo trabalhando na jogabilidade de uma área específica apenas para removê-la mais tarde,
pois o resto do nível não cabe mais no espaço disponível. Se você vai configurar a jogabilidade
para áreas específicas antes que todo o nível seja construído, faz mais sentido construir a arquitetura
Machine Translated by Google

Capítulo 23: Design de Nível 473

para um espaço de jogo completo e discreto, como um edifício ou estrutura específica. Então você
pode fazer a jogabilidade funcionar nessa área inteira antes de passar para a próxima.
Outra ideia útil é incorporar o teste de jogo no início do processo, talvez após a etapa seis.
Depois de ter seu nível jogável, peça a algumas pessoas cujas opiniões você confia para tentar
jogar o nível. A estética pode não ser totalmente refinada ainda, e você certamente deve explicar
isso a eles enquanto eles tocam, mas se você conseguir obter feedback neste estágio inicial, poderá
fazer alterações importantes antes de gastar muito tempo refinando a estética do nível. Uma
possível desvantagem de testar o nível tão cedo é que outros podem não ser capazes de entender
que visualmente o nível ainda não está completo. Como resultado, eles podem ficar preocupados
em criticar a aparência do seu nível em vez de fornecer feedback sobre a jogabilidade. Certifique-
se de comunicar que tipo de feedback você está procurando neste estágio e espere que os
testadores possam ver além da falta de efeitos de iluminação sofisticados. O teste neste estágio
inicial não substitui o teste após o nível ser mais final, mas pode evitar algumas surpresas
desagradáveis e pode tornar o teste final mais suave.

Quem faz o design de níveis?


Ao longo deste capítulo, falei como se você fosse responsável por todos os aspectos do seu nível.
Muitos estúdios de desenvolvimento ainda operam no método “um designer, um nível” de design de
níveis. Isso tem muitas vantagens, é claro, pois ajuda a manter os níveis focados. Esse designer
está constantemente ciente do que seu nível exige em termos de jogabilidade, arte e programação,
e pode manter esse nível no caminho certo. Quando chegar a hora de configurar a iluminação do
nível, por exemplo, o designer vai lembrar que ela pensou que a jogabilidade em uma parte do nível
seria melhor no escuro com luz intermitente desorientadora. Ter uma pessoa trabalhando em um
nível do início ao fim ajuda a garantir que o nível tenha uma consistência de visão que pode levar a
uma ótima jogabilidade.
Mas a técnica “um designer, um nível” não é o único método que pode funcionar, e muitos
desenvolvedores adotaram mais uma abordagem de “equipe” para o design de níveis. Se sua
equipe tem um designer que é particularmente bom em fazer arquitetura bonita, mas é menos
habilidoso em fazer os agentes de IA funcionarem, pode fazer sentido ter um designer diferente
para configurar a jogabilidade nos níveis desse designer. Os artistas podem ser mais bem treinados
e adequados para fazer um nível parecer especialmente bonito. Um designer ou artista pode ser
particularmente bom em efeitos de iluminação, enquanto outro pode ser adepto das sequências de
script. Você pode querer que o designer de som configure seus efeitos sonoros, pois ele será
melhor em colocar corretamente os efeitos de áudio que criou. O preço de ter um nível de alta
qualidade quase inevitavelmente envolverá um maior grau de especialização dos membros de sua
equipe. Claro, como acontece com qualquer tarefa que é dividida entre várias pessoas, você precisa
ter certeza de que todos estão “na mesma página” em termos do que esse nível está tentando
realizar. Por exemplo, o designer de arquitetura pode ter construído um desfiladeiro que ele pensou
que seria ideal para uma emboscada, mas quando o designer que configura a jogabilidade aparece,
ele pode não notar esse desfiladeiro em particular e pode configurar encontros em locais menos
ideais. A comunicação entre as diferentes pessoas que trabalham em um determinado nível é
essencial, assim como entre as equipes de programação, arte e design.
Como afirmei anteriormente, à medida que os jogos se tornam mais complexos, torna-se
necessário dividir tarefas que costumavam ser realizadas por uma pessoa entre várias pessoas. Como
Machine Translated by Google

474 Capítulo 23: Design de Nível

os jogos continuam a se tornar mais complicados, os designers se especializam cada vez mais,
e ter várias pessoas trabalhando em um único nível se tornará cada vez mais comum.
Manter o jogo focado em tal projeto será um grande desafio, o que enfatiza a importância dos líderes de projeto e
dos designers de nível líder. No entanto, como as pessoas
se especializarem em uma determinada área de design de níveis, existe a possibilidade de que eles possam se tornar
melhor em sua área específica de especialização como resultado, elevando o nível em termos de qualidade final.
Além disso, se uma pessoa configurar a IA e a jogabilidade para todos os níveis do
jogo, esses níveis como um todo podem atingir uma consistência de jogabilidade maior do que se cada
level designer estava montando sua própria jogabilidade. Se gerenciados corretamente, esses designers e artistas
de nível altamente especializados podem levar a níveis melhores no jogo final.

Colaboração
À medida que os jogos crescem em complexidade, o número de designers de níveis necessários para um jogo em
particular aumentou. Considerando que um designer costumava ser capaz de controlar verdadeiramente cada
última faceta do design de um jogo, agora um designer líder deve encontrar designers de nível em que possa confiar
para construir níveis que darão uma contribuição significativa para o design do jogo. Embora um
designer-chefe pode ser capaz de olhar por cima do ombro desses designers de nível e fazer sua
melhor direcionar os esforços, no final ela delegou uma grande parte da criação da jogabilidade a esses membros
inestimáveis de sua equipe. Isso pode ter um lado bom, pois mais
vozes no design do jogo podem tornar o jogo uma experiência mais robusta e um mau
lado, à medida que a clareza da visão artística é diluída por tantas pessoas diferentes trabalhando no projeto. Tais
são os perigos da maioria dos jogos comerciais modernos
desenvolvimento.
Machine Translated by Google

Capítulo 24

Análise do jogo:
Grand Theft Auto
III
Projetado por Chris Rothwell, Craig Filshie,
William Mills e James Worrall
Lançado em 2001

projeto baseado em sistemas. O título apresenta um mundo de jogo no qual comportamentos emergentes
Emetermos devariedade
uma ampla design de jogo, Grand
de opções TheftseAuto
de jogadores III é para
combinam um exemplo brilhantede
criar uma experiência dojogo
triunfo de
incrível,
onde os jogadores se sentem verdadeiramente capacitados para jogar como quiserem. Se as vendas puderem

475
Machine Translated by Google

476 Capítulo 24: Análise do Jogo: Grand Theft Auto III

ser extrapolado para a popularidade, então Grand Theft Auto III e sua sequência Grand Theft Auto:
Vice City cativaram mais jogadores do que qualquer outro jogo da geração de console PlayStation
2. Qualquer um que tenha jogado esses jogos pode lhe dizer o motivo: os jogos combinam de
maneira brilhante uma mecânica central divertida e exclusiva, dando aos jogadores liberdade
suficiente no ambiente para que o jogo se torne uma experiência divertida que os jogadores
desfrutarão por muito mais tempo do que quase qualquer outro jogo de ação.
Em termos de produção, Grand Theft Auto III é um exemplo de uma sequência bem feita, e
como as sequências podem aproveitar o avanço da tecnologia para levar seu design de jogo a
novos lugares. Muitas sequências de jogos incorporam tecnologia de renderização e gráficos mais
avançados meramente pelo desejo de melhorar o visual de um jogo e, infelizmente, esses
aprimoramentos geralmente acabam atrapalhando a mecânica de jogo do jogo original. Grand Theft
Auto III, por outro lado, usou a tecnologia para alterar radicalmente a experiência de jogo e tornar
o novo jogo muito mais jogável do que seus antecessores. Ao mudar a visão da câmera de cima
para baixo encontrada em Grand Theft Auto e Grand Theft Auto 2 para a familiar câmera de
perseguição de jogos de corrida, Grand Theft Auto III tornou a experiência de dirigir muito mais
intuitiva e muito mais divertida. Enquanto dirigir nos jogos anteriores era muitas vezes frustrante,
pois os jogadores só podiam ver tão longe à frente de seu veículo em uma visão de cima para
baixo, com uma câmera de perseguição, os jogadores podiam ver claramente as ruas em que
estavam descendo. A adição de alguma física relativamente simples ao modelo de direção tornou
a mecânica central fundamentalmente agradável de uma maneira que estava faltando nos jogos
anteriores.

Mundo de jogo crível


Desde o início da série, o maior gancho dos jogos Grand Theft Auto tem sido seu cenário realista
com o qual qualquer um que tenha dirigido um carro em uma cidade pode se conectar
imediatamente. Mesmo com os gráficos particularmente caricaturais e a visão de cima para baixo
do primeiro Grand Theft Auto, a ideia de dirigir por uma cidade, arremessando-se como um louco
pelas calçadas ou becos, potencialmente atropelando os pedestres que estão no seu caminho,
esmagando seu carro no processo, e então roubar qualquer carro que você pudesse encontrar,
provou ser excepcionalmente atraente. Qualquer um que já tenha ficado irritado esperando
pedestres lentos atravessarem uma faixa de pedestres provavelmente já se perguntou: “E se eu os
atropelar?” Todo mundo já fantasiou em evitar um engarrafamento colocando o carro na calçada
como em um filme de ação. Qualquer um que tenha visto um veículo chique parar ao lado deles
em um semáforo entende o desejo de abandonar seu próprio carro e pegar este melhor.
Estas são todas as atividades tabus que muitas pessoas fantasiam diariamente. Certamente, eles
nunca fariam isso na vida real, mas no contexto seguro de um mundo de jogo onde a pior
consequência é ter que recomeçar o jogo, quem não gostaria de experimentá-lo?
E como os dois primeiros jogos de Grand Theft Auto foram sucessos por si só, podemos concluir
que muitos jogadores estavam dispostos a ignorar a mecânica de direção desajeitada para que
pudessem se envolver nessas atividades tabu.
Grand Theft Auto III é um modelo de como realmente evoluir seu jogo com uma sequência.
Ele mantém o emocionante gancho de dirigir na cidade dos primeiros jogos enquanto corrige seus
problemas de ponto de vista e controle, tornando o jogo muito mais atraente para muito mais pessoas.
De fato, muitos dos conceitos de design encontrados no terceiro jogo também estão presentes no
primeiro, sejam os telefones tocando dando aos jogadores suas missões, a sensação de um
Machine Translated by Google

Capítulo 24: Análise do Jogo: Grand Theft Auto III 477

viver na cidade com outros carros e pedestres, todos vivendo suas vidas de uma maneira crível, os
mini-jogos de “fúria” ou a natureza satírica do jogo-ficção, incluindo o rádio do carro altamente
divertido.
Embora no cinema e no mundo literário as sequências sejam muitas vezes vistas como uma
maneira grosseira de lucrar com um sucesso anterior, nos jogos é preciso considerar as sequências
de maneira um pouco diferente. Os jogos em geral continuam sendo jogados por muito mais tempo
do que suas contrapartes de mídia linear; pense em quantas pessoas ainda consideram xadrez,
Monopólio ou Scrabble seus jogos de tabuleiro favoritos e continuam a jogá-los ano após ano. Com
um jogo baseado em história para um único jogador, o jogo pode ser principalmente divertido por
causa de sua mecânica, mas essas mecânicas se tornam significativas e interessantes por causa
do conteúdo específico do jogo (seja a localização, a seleção de objetos utilizáveis, ou as missões
e enredo). Os jogadores ainda podem aproveitar a mecânica depois de esgotarem todo o conteúdo.
Assim como o RPG de mesa Dungeons & Dragons gerou pacotes de cenários infinitos que alguém
poderia jogar usando as mesmas regras básicas, quando os jogadores realmente amam um jogo
de computador eles querem continuar explorando sua mecânica, mas com conteúdo novo e
interessante. No lado do PC, isso geralmente pode ser feito com um pacote de missão. No entanto,
devido às limitações técnicas dos consoles, os desenvolvedores geralmente são obrigados a lançar
um jogo totalmente novo apenas para fornecer mais conteúdo para os jogadores experimentarem
(como Grand Theft Auto: Vice City, que manteve basicamente a mesma mecânica de seu
antecessor). Ao mesmo tempo, uma sequência dá aos designers a oportunidade de polir e refinar
suas mecânicas de jogo, consertando o que foi gritantemente quebrado e adicionando os recursos
que eles se arrependeram de cortar devido a restrições de tempo na primeira vez.
Finalmente, com a tecnologia de jogos avançando tão rapidamente, os jogos podem parecer
radicalmente melhores em apenas alguns anos. Em particular, a cada geração de hardware de
console, os jogadores querem ter novas versões de seus jogos favoritos que explorem plenamente
os novos recursos tecnológicos de seus novos sistemas. Às vezes, o avanço da tecnologia é tão
significativo que os desenvolvedores conseguem repensar seu jogo e levá-lo a um novo patamar,
como foi o caso de Grand Theft Auto III. Quando a experiência fundamental de um jogo pode ser
melhorada tanto quanto naquele jogo, dificilmente se pode dizer que as sequências de jogos são
puramente exploração.

A Living City Grand Theft

Auto III é um dos poucos jogos orientados para a ação que apresenta aos jogadores um mundo de
jogo que realmente parece estar vivo. Ao contrário de tantos outros jogos que alegaram ser
ambientados no mundo real, GTA3 tornou esse mundo crível, misturando-se com a realidade
exatamente o suficiente para permitir que os jogadores suspendessem sua descrença. Em primeiro
lugar, a paisagem do GTA3 permite que os jogadores naveguem pela cidade da maneira que
quiserem. Os jogadores podem dirigir por qualquer rua ou beco, por qualquer ponte, por qualquer
parque, subir qualquer conjunto de escadas que seja larga o suficiente e até usar rampas para pular
obstáculos. Há muito pouca sensação de ser artificialmente restringido, como é frequentemente
experimentado na maioria dos jogos, evitando assim a sensação de “os designers não queriam que
eu fosse para lá, então há uma parede invisível bloqueando meu caminho”. No GTA3, os jogadores
são confinados por um número limitado de muros altos e cercas, mas mais pela água que circunda
a ilha em que o jogo se passa. Essa consistência da navegação mundial é possibilitada por uma
simulação de física do carro, que inclui capacidade de resposta suficiente para fazer com que a direção pare
Machine Translated by Google

478 Capítulo 24: Análise do Jogo: Grand Theft Auto III

quase crível (pelo menos no sentido de filme de ação), mas mantém a condução divertida e bastante
tolerante. Da mesma forma, embora os carros sejam capazes de sustentar muito mais danos do que
é real, se você tratar um carro mal o suficiente, ele acabará explodindo, esperançosamente sem você
dentro dele.
Dentro da cidade, o jogo também apresenta uma simulação de trânsito muito crível, com carros
esperando por semáforos, ficando do lado direito da estrada, buzinando uns para os outros, e alguns
carros entrando e saindo entre outros. Da mesma forma, a simulação de pedestres parece tão
autêntica, com os cidadãos vivendo suas próprias vidas na cidade em vez de parecer que foram
colocados lá estritamente para o benefício dos jogadores. Em nítido contraste com a maioria dos
jogos, GTA3 cria a sensação de que este mundo não gira em torno do jogador; o personagem do
jogador é apenas um cara em uma cidade cheia de personagens obscuros. Ao mesmo tempo, a
simulação de tráfego e de pedestres reagirá às ações dos jogadores de maneira crível. Se os jogadores
correrem e socarem um desses civis aleatórios, ele reagirá enquanto os outros cidadãos fogem
aterrorizados. Qualquer polícia que estiver por perto correrá para tentar parar a luta. Se os jogadores
pararem o carro no meio da rua, o trânsito parará e os motoristas buzinarão. Tudo isso contribui para
a sensação de um mundo crível.
Embora o mundo do jogo esteja longe de ser "real", o mundo é reconhecível e esses vários sistemas
criam um espaço consistente no qual os jogadores gostam de jogar. De uma forma que, infelizmente,
poucos jogos fazem, Grand Theft Auto III promove o espírito de jogo nos jogadores, incentivando-os a
experimentar aquele salto maluco, ver se eles conseguem encontrar algum caminho dentro da cerca
para um power-up bronzeador ou desafiando-os para tentar ultrapassar uma equipe SWAT inteira.
David Jones, Diretor Criativo da DMA Design quando os dois primeiros jogos Grand Theft Auto foram
desenvolvidos, afirmou que o primeiro objetivo dos jogos era construir um ambiente urbano crível no
qual os jogadores pudessem se divertir apenas brincando. Transformar o jogo em um jogo de crime e
roubo de carro veio depois, depois que a simulação da cidade já era agradável por si só.

Apesar da impressionante simulação de mundo de Grand Theft Auto III , é igualmente


interessante o que o mundo do jogo não tenta fazer. Os pedestres e o tráfego na rua são inteligentes
o suficiente para sustentar a ilusão da realidade, mas ao mesmo tempo não são exatamente brilhantes.
Por exemplo, os pedestres às vezes parecem estar andando pelo mundo como zumbis e podem
facilmente ficar presos em um carro estacionado no meio de uma calçada. Além disso, esses civis não
fazem muito esforço para sair do caminho de um carro que vem direto para eles. Uma simulação mais
avançada desses pedestres provavelmente poderia ter corrigido esses problemas, mas poderia tê-los
tornado mais caros computacionalmente e significar que menos desses NPCs poderiam estar andando
na rua a qualquer momento. Claramente, os designers chegaram à conclusão de que ter NPCs
suficientes para fazer o mundo parecer realmente vivo era mais importante do que tornar cada um
deles super inteligente. O mesmo acontece com a arte: se olharmos para os gráficos, nenhuma peça
é particularmente de tirar o fôlego. Mas tomados em conjunto, os gráficos tornam-se impressionantes
devido ao tamanho da cidade e à quantidade de variedade contida nela. Para tornar o mundo tão
grande e permitir que os jogadores vejam tão longe a qualquer momento, a arte do jogo é bastante
poligonal. De fato, os desenvolvedores parecem ter adotado um estilo de arte caricatural mais
compatível com sua potência gráfica limitada, provavelmente porque entenderam suas limitações no
início do desenvolvimento e decidiram abraçar essas restrições em vez de combatê-las. Mas os
jogadores perdoam a aparência um tanto barata do jogo por causa de sua incrível profundidade como
experiência de jogo. Dentro
Machine Translated by Google

Capítulo 24: Análise do Jogo: Grand Theft Auto III 479

Grand Theft Auto III, os jogadores nunca podem entrar nos edifícios durante o jogo, com toda
a interação interior acontecendo exclusivamente durante as cutscenes. Muitos jogos certamente
permitiram que os jogadores entrassem em espaços internos, e essa limitação é uma das
omissões mais óbvias no GTA3. Parte do problema inerente ao desenvolvimento de um jogo
baseado em um mundo quase realista é que os jogadores anseiam por mais e mais realismo
enquanto jogam e podem ficar frustrados quando atingem os limites da simulação. No entanto,
pode-se entender por que os designers do GTA3 fizeram essa escolha: dados todos os outros
sistemas e conteúdo que precisavam criar, poder também entrar nas estruturas teria sido uma
dor de cabeça totalmente nova e eles quase certamente não teriam tempo suficiente para
implementá-los em alto nível de qualidade. De fato, Grand Theft Auto: Vice City incluiu espaços
internos, mas falhou em implementá-los particularmente bem, tornando as seções internas
algumas das partes mais fracas e frustrantes dos jogos. No GTA3, decidir não deixar os
jogadores entrarem foi uma escolha sábia e, uma vez que a maioria dos jogadores se
familiarizou com essa restrição, eles entenderam os limites do espaço de simulação e
esqueceram o desejo de entrar.
Apesar do quanto os jogadores podem fazer no jogo, é interessante notar quão poucas
ações os jogadores podem realmente realizar. Todo o jogo é baseado em mover-se pelo
ambiente, seja de carro ou a pé. Cada modo é diferente, com o deslocamento do pé realizado
pressionando o controle esquerdo na direção que você deseja que seu personagem vá,
enquanto dirigir envolve dirigir o carro com o controle esquerdo enquanto acelera, desacelera
ou usa o freio de mão com vários botões. Os jogadores são capazes de realizar ataques em
qualquer modo, a pé usando brigas ou armas, em um veículo batendo em alvos (outros
veículos ou humanos) ou atirando pela janela no estilo “drive-by”. A interface para atacar é
bastante simples, principalmente no modo veículo. Quando a pé com armas de projétil, a
segmentação automática é empregada, embora a interface para isso seja uma das partes
mais fracas do jogo. Além da navegação pelo mundo e do ataque, os jogadores também
podem pegar objetos simples passando por cima deles; a pé são itens como dinheiro ou
armamento, enquanto em um carro pode-se parar o veículo ao lado dos passageiros para
deixá-los entrar, se forem receptivos. Cada modo adiciona mais algumas opções personalizadas:
a pé, você pode correr e pular, enquanto no carro você pode trocar a estação de rádio, buzinar
ou acessar recursos personalizados do veículo, como jogar o jogo em táxi, ambulância, ou
modo de carro de bombeiros.
Para um jogo com uma gama tão ampla de potencial expressivo do jogador, as mecânicas
acima são bastante limitadas. Grand Theft Auto III parece positivamente simplista em
comparação até mesmo com os atiradores em primeira pessoa modernos padrão, quase todos
os quais incluem recursos como agachar, metralhar e recuar, disparo de armas alternativo,
um inventário complexo e assim por diante. De fato, em termos do grande número de botões
que os jogadores precisam usar, Grand Theft Auto III é um pouco mais simples do que a
maioria das aventuras de ação modernas. Ele pode não alcançar o que Brian Moriarty chamou
de interfaces “desesperadamente simples” de avanços no mercado de massa como Myst ou
Tetris, mas o jogo faz mais para acomodar usuários não entusiastas do que a maioria de seus
contemporâneos. O jogo fornece sua profundidade através dos jogadores combinando essas
mecânicas e improvisando dentro do espaço do jogo.
Machine Translated by Google

480 Capítulo 24: Análise do Jogo: Grand Theft Auto III

Ações e Consequências
De muitas maneiras, o design baseado em sistemas de Grand Theft Auto III centra o jogo em ações
e suas consequências. Por exemplo, os jogadores têm a liberdade de dirigir de forma imprudente
na cidade e atropelar quaisquer pedestres que estejam em seu caminho. Mas se houver um policial
por perto que presencie a matança desenfreada, os jogadores de repente se tornarão procurados
pela polícia por seu crime (que é representado no medidor de procurados dos jogadores) e
precisarão evitar a aplicação da lei até sua morte. nível desejado diminui. Da mesma forma, os
jogadores podem roubar qualquer carro que quiserem no jogo, mas se um policial testemunhar o
roubo, o nível de procurado dos jogadores aumentará.
Roubar um carro da polícia também é possível, mas a polícia fica especialmente louca quando os
jogadores o fazem e os persegue ainda mais obstinadamente. Fora apenas a reação da polícia aos
crimes, se os jogadores atirarem em um membro de uma gangue, os outros membros da gangue
podem vir atrás deles com armas em punho. Os jogadores podem dirigir seus carros tão
imprudentemente quanto quiserem, caindo nas laterais dos prédios ou fazendo saltos insanos.
Mas toda vez que os jogadores atingem algo, o carro sofre danos e, depois de sofrer impactos
suficientes, acaba explodindo. Assim, os jogadores são forçados a fazer escolhas interessantes e
às vezes difíceis: podem cortar cantos para chegar a algum lugar mais rapidamente, prejudicando
seu passeio ao longo do caminho, mas se o danificarem demais, ficarão sem nenhum tipo de
transporte. Se eles jogarem pelo seguro, seu tempo de viagem será maior e eles podem falhar na
missão. Da mesma forma, a polícia faz os jogadores pensarem duas vezes sobre as escolhas que
fazem. Os jogadores podem precisar de um carro agora para passar por uma missão, mas há um
policial observando. Eles podem fugir dos policiais? Ou eles têm tempo para correr ao virar da
esquina e tentar roubar um veículo quando estão fora de vista?
O design de níveis de Grand Theft Auto III é outro componente chave do jogo que oferece aos
jogadores escolhas significativas. Embora existam muitos minijogos e outras diversões em que os
jogadores podem participar para refinar suas habilidades ou ganhar dinheiro extra, o núcleo do jogo
envia os jogadores em uma variedade de missões diferentes. As missões são muito bem
configuradas para fornecer aos jogadores uma boa variedade de objetivos a cumprir, todos os quais
exploram as mesmas mecânicas centrais do jogo, mas as reutilizam de maneiras interessantes. Os
jogadores terão missões em que precisam assassinar um inimigo específico, roubar um carro
específico, pegar uma pessoa ou um pacote e deixá-lo em um segundo local e assim por diante. As
missões são configuradas para garantir que os jogadores explorem todas as diferentes partes da
cidade, frequentemente cruzando toda a ilha para cumprir uma missão específica. De uma
perspectiva de fluxo de nível, o mais interessante é como os jogadores podem seguir qualquer rota
que quiserem pela cidade para chegar a algum lugar. Além disso, em algumas missões, o alvo do
trabalho pode se movimentar livremente e imprevisivelmente pelo espaço da cidade. Uma batalha
que começa fora de um restaurante específico pode levar a uma perseguição pela cidade que se
desenrola de forma diferente cada vez que o usuário a experimenta. Algumas missões são
cronometradas, o que significa que os jogadores precisarão fazer escolhas cuidadosas sobre qual
rota tomar ou quanto tempo deixarão uma batalha acontecer. Isso torna o fluxo do mapa em Grand
Theft Auto III mais parecido com um jogo de estratégia ou esporte, onde uma batalha pode fluir
natural e dinamicamente pelo ambiente. Não há caminho crítico para o mapa. Liberty City do GTA3
é tão grande que navegar pode ser bastante assustador no começo, com os jogadores gastando
uma boa quantidade de tempo se perdendo antes de descobrir o caminho. Essa experiência é como
se mudar para uma nova cidade e precisar aprender a configuração do terreno. Felizmente, cada centímetro de L
Machine Translated by Google

Capítulo 24: Análise do Jogo: Grand Theft Auto III 481

e há muitos pontos de referência distintos para os jogadores usarem para se orientar. Um mapa
HUD inovador e útil mostra aos jogadores as ruas próximas e aumenta e diminui suavemente o
zoom com base na velocidade atual do jogador, tornando a navegação na cidade desconhecida
muito mais fácil. E como a mecânica central do jogo e a implementação de física leve tornam a
condução de um veículo tão agradável, os jogadores estão mais do que dispostos a dedicar o
tempo necessário para aprender o caminho, pois podem se divertir muito fazendo isso.
Mais do que qualquer outro título de ação e aventura, Grand Theft Auto III é um jogo que faz
com que os jogadores contem histórias sobre a incrível sequência de perseguição que tiveram
com a polícia ou toda a improvisação que usaram para realizar uma missão. Pessoalmente,
lembro-me de uma missão em que tive que matar um chefe da máfia rival que acabou me
perseguindo em seu veículo blindado Mafia Sentinel. Nosso confronto havia se espalhado por
várias partes da cidade, e meu carro havia sofrido tantos danos que estava pegando fogo e tive que aban
Meu inimigo ainda estava no meu encalço e, sem veículo, eu era um alvo fácil. Lembro-me de
que estávamos brigando perto de um posto de gasolina quando abandonei o carro, e um bandido
estava correndo para mim quando pulei um muro baixo que ele colidiu. De repente, seu carro
sofreu mais danos do que eu consegui infligir batendo nele com meu veículo agora morto. Ele
ainda não estava fora de serviço, porém, e ele dirigiu ao redor do muro para tentar me atropelar
novamente, mas desta vez eu me agachei atrás de uma bomba de gasolina, na qual ele começou
a bater. Consegui fazer várias dessas manobras de matador até que seu carro finalmente
explodiu com todo o dano que sofreu, e eu passei na missão. Foi definitivamente um momento
“eu não poderia fazer isso de novo se eu tentasse”. Eu havia passado na missão, cujo objetivo
era completamente predeterminado, mas a maneira como eu o cumpri envolvia um método que
eu havia inventado na hora. Eu tinha feito isso de uma maneira que os designers do jogo
provavelmente não teriam previsto. Como resultado do meu envolvimento na autoria do cenário,
é uma das experiências mais memoráveis que já tive em um videogame. Esses são os tipos de
cenários que o design de jogos baseado em sistemas bem implementado torna possível.

Narrativa
Em meio a toda a jogabilidade emergente e escolhas interessantes, Grand Theft Auto III também
consegue contar uma história convincente. A maior parte dessa narrativa acontece em cutscenes,
mas é interessante notar como elas são curtas e diretas. A abertura do jogo consegue transmitir
muitas informações - o envolvimento do personagem do jogador em um assalto a banco, a
namorada que o traiu e o deixou para morrer, o julgamento que o manda para a prisão, o
envolvimento posterior do personagem principal em um transporte de prisão quebra que o deixa
foragido da lei - tudo em aproximadamente dois minutos. As cutscenes que vêm no início de cada
missão são ainda mais curtas e diretas. O fato de o jogo ser extremamente bem escrito e ter
dublagem de primeira qualidade certamente ajuda a tornar a dependência de cenas mais
perdoáveis.
Mas o jogo conta sua história através de mais do que apenas as cut-scenes, com a
capacidade de acreditar de Liberty City apoiando perfeitamente a ficção do jogo. Os jogadores
são enviados em missões para vários bairros que mostram os diversos tipos de vida que existem
na cidade, com os tipos de carros circulando e os pedestres andando pelas calçadas combinando
adequadamente com o sabor dos bairros, tudo contribuindo para um mundo notavelmente
consistente. As estações de rádio que os jogadores podem sintonizar enquanto dirigem qualquer um dos
Machine Translated by Google

482 Capítulo 24: Análise do Jogo: Grand Theft Auto III

veículos também contribuem para este espaço ficcional, com cada estação tocando os temas
satíricos do jogo e sua abordagem mordaz da cultura americana. E, novamente, a escrita no rádio
é uma das melhores sátiras que você provavelmente encontrará em qualquer meio.
Embora as missões e cenas que compõem o arco da história principal sejam completamente
pré-roteirizadas e não possam mudar com base nas ações dos jogadores, os designers tomaram
várias decisões que permitem que os jogadores ainda sintam que a história é deles.
Em primeiro lugar, embora os objetivos em si não mudem, a ordem em que os jogadores tentam
muitas das missões é deixada a seu próprio critério. Além disso, os jogadores podem jogar através
do arco da história principal do jogo sem sequer participar de todas as missões, o que significa que
cada usuário provavelmente jogará uma subseção diferente do conteúdo disponível. Além disso,
em Grand Theft Auto III os designers deliberadamente mantiveram o personagem principal mudo
para que os jogadores pudessem se sentir mais imersos no jogo, evitando o efeito de distanciamento
de ter um personagem principal que fala. Como os jogadores já estão fazendo escolhas no mundo
do jogo que definem a personalidade de seu personagem, impedi-lo de falar permitiu que essa
personalidade fosse dominante na mente dos jogadores, em vez de algo que os designers
estabeleceram para eles. Curiosamente, Vice City adicionou discurso para o personagem principal,
embora isso não tenha sido particularmente elogiado pelos usuários ou pela imprensa.
Claro, dificilmente alguém poderia discutir Grand Theft Auto III sem trazer à tona a controvérsia
que seu lançamento criou na grande mídia. O que parece ter incomodado mais as pessoas foi a
capacidade dos jogadores de ter a opção de atropelar pedestres inocentes e, especificamente,
pagar para dormir com uma prostituta e depois matá-la para receber seu dinheiro de volta. Tais
queixas parecem vir de críticos que não entendem completamente a natureza de um mundo
interativo. Em tal mundo, os jogadores têm a opção de jogar como quiserem. Seria melhor se os
pedestres magicamente saíssem do caminho dos carros dos jogadores? Que lição isso daria aos
jogadores? De fato, muitos jogadores do jogo farão de tudo para evitar matar sem sentido. Eu
discuti o jogo com muitos jogadores que deliberadamente evitam matar inocentes enquanto se
movem pelo mundo; eles simplesmente veem isso como algo que não querem fazer e isso se torna
parte de sua experiência de interpretação de papéis. No final, criar um mundo onde os jogadores
são capazes de fazer escolhas significativas significa criar um mundo onde eles podem fazer
algumas escolhas muito ruins. As pessoas que reclamam de um jogo que permite fazer escolhas
tão ruins são as mesmas que preferem censurar o que as pessoas podem ler e ver em outras
mídias também. Se alguém acredita na liberdade de expressão para romances e filmes, deve
também permitir aos jogadores a liberdade de agir como quiserem dentro de um espaço de jogo
simulado.
Já vi alguns membros da comunidade de desenvolvimento reclamarem de todos os prêmios
que o jogo recebeu. Certamente um jogo que leva violência e assuntos tabus tanto quanto Grand
Theft Auto III não deveria ser recompensado? Certamente, não deve ser recompensado apenas
com base nisso, nem deve ser recompensado com base em seu tremendo sucesso popular. No
entanto, o fato é que Grand Theft Auto III, através de seu design baseado em sistemas e
jogabilidade emergente, empurra os jogos para seu tremendo potencial mais do que a maioria dos
outros jogos de memória recente. E com base nisso, o jogo realmente merece todos os elogios que
recebeu.
Machine Translated by Google

Capítulo 25
Teste de jogo

“O denominador comum, eu acho, é a paixão. Todo mundo diz: 'Bem, por que
os jogos não são melhores - por que não existem mais jogos realmente bons?'
E acho que a resposta é que o que essa indústria não faz, surpreendentemente,
é jogar os jogos que ela faz. Criamos um jogo, pedimos às equipes que
trabalhem todas as horas que Deus manda, e não lhes damos tempo para
jogar o jogo. Isso é realmente o que faz a diferença – sentar e jogar por horas
e horas e horas.”
—Peter Molyneux

ciclo. É então que você pega o projeto em que está trabalhando há meses
Playtesting podedurante
ou anos, ser umaosdas partes
quais maisaemocionantes
apenas do desenvolvimento
equipe de desenvolvimento jogoudo jogo
o jogo
e mostrá-lo para pessoas de fora da equipe. E, se tudo correr bem, você pode ver
como eles se divertem com seu trabalho, querem jogar mais, elogiam o que você
fez e têm sugestões de como você pode melhorar. O teste de jogo não é apenas um
pequeno passo para que o jogo seja enviado para os duplicadores ou carregado para o

483
Machine Translated by Google

484 Capítulo 25: Teste de jogo

Internet. Em vez disso, o teste de jogo é um momento chave durante o qual você pode transformar
seu jogo de médio para excelente, de algo que mostra promessa para um jogo que é realmente
ótimo. Poucos jogos saíram das mãos do desenvolvedor em forma absolutamente perfeita.
Idealmente, é o ciclo de teste que dá ao seu jogo o impulso extra para ser o melhor possível.

Vale a pena esclarecer o que exatamente quero dizer quando digo playtesting. Isso não é o
mesmo que depuração. A depuração é uma tarefa mais orientada à programação na qual todos os
aspectos inerentemente quebrados do jogo são rastreados e corrigidos. Isso pode ser qualquer
coisa, desde a implementação imprópria de algumas mecânicas de jogo até problemas gráficos e
problemas que realmente travam o jogo. Certamente esses bugs devem ser eliminados, mas isso
é mais uma questão de preocupação para a equipe de programação.
Playtesting é o equivalente de design da correção de bugs, embora seja consideravelmente
menos cortado e seco. Quando os testadores olham para um jogo, eles tentam ver se o jogo é
divertido e tentam encontrar falhas na mecânica do jogo. Isso pode ser qualquer coisa, desde uma
unidade em um jogo RTS que é muito poderosa e permite que os jogadores que a adquirem no
início dominem totalmente o jogo, até a natureza ilógica de como um agente de IA inimigo ataca
os jogadores, até um pouco intuitivo e difícil de usar. Sistema de controle. É na fase de playtesting
que a mecânica do jogo é testada e refinada. Infelizmente, alguns desenvolvedores de jogos se
concentram inteiramente em corrigir bugs e muito pouco em determinar se o jogo é realmente
divertido de jogar. Como resultado, pode não haver nada realmente errado com o jogo, e pode ser
completamente estável em todos os sistemas em que deve ser executado. Pena que ninguém quer
jogar o jogo porque não é divertido. Todos os jogadores preferem ter um jogo que funcione muito
bem e trave ocasionalmente do que um que funcione perfeitamente, mas não valha o tempo que
leva para jogá-lo. Pelo menos o primeiro jogo é divertido algumas vezes, enquanto o último é chato
o tempo todo.

Encontrando os testadores certos


Encontrar os testadores certos talvez seja um dos maiores desafios de um designer de jogos ao
testar seu jogo. Não é qualquer um que será capaz de jogar um jogo de forma eficaz. Quase
qualquer jogador pode dizer se gosta ou não do seu jogo, mas um número surpreendentemente
pequeno será capaz de explicar por que não gosta e o que você pode fazer para melhorá-lo. É
claro que obter feedback da impressão geral de alguém sobre o jogo pode ser útil: “isso foi
divertido” ou “isso foi tedioso” ou “isso foi muito difícil” são todas as informações que você poderá
aplicar ao seu trabalho para para melhorar seu jogo. Conselhos realmente úteis, no entanto, vêm
em uma forma mais construtiva: “Quando eu estava lutando contra o décimo segundo palhaço no
nível três, achei que ele era muito difícil de derrotar. Eu não tinha ideia do que deveria fazer para
matá-lo, ou se os ataques que eu estava tentando estavam tendo algum efeito. Achei que talvez eu
devesse rolar a pedra para ele, mas não consegui descobrir como fazê-lo.” Neste exemplo, o
playtester forneceu ao designer informações muito específicas sobre o problema e uma explicação
detalhada de por que ele achava que não era muito divertido jogar. Playtesters que podem fazer
esse tipo de análise de forma consistente são extremamente raros, tornando um playtester
talentoso um ativo verdadeiramente inestimável para sua equipe.
Uma parte fundamental do trabalho eficaz com testadores é conhecê-los bem o suficiente
para saber com que seriedade suas opiniões e quais preconceitos eles podem ter. Diferentes
testadores terão motivações diferentes, o que necessariamente irá colorir as opiniões que eles
Machine Translated by Google

Capítulo 25: Teste de jogo 485

te dar. É por isso que escolher uma pessoa aleatória na rua para testar seu jogo às vezes pode
ser ineficaz, já que você não tem experiência anterior com ela e, portanto, não sabe se pode confiar
na opinião dele ou não. Quando você tiver experiência com um determinado testador, poderá saber
se essa pessoa tem alguma deficiência. Por exemplo, alguns testadores podem ser melhor
descritos como “chorões” que reclamam de tudo, mesmo de coisas que não precisam ser
consertadas. Outros testadores podem ser tímidos, dizendo apenas: “Talvez você devesse olhar
para o poder da unidade Elephant Rider”, quando o que eles realmente querem dizer é:
“Obviamente, o Elephant Rider joga completamente fora do jogo”. Tente o seu melhor para
entender as personalidades dos testadores com quem você trabalhará; é fundamental para usar
efetivamente o feedback que eles lhe dão. E, no final, independentemente das tendências dos
testadores, se vários deles apresentarem um problema semelhante, provavelmente algo está
errado, mesmo que eles estejam diagnosticando o problema incorretamente. Da mesma forma, se
você tiver pessoas aleatórias suficientes na rua dizendo que algo está errado com seu jogo,
provavelmente vale a pena investigar.

Quem deve testar


Existem vários tipos de testadores que um projeto pode ter, e é uma boa ideia ter alguns de cada
grupo trabalhando em seu projeto. Nenhum tipo de testador pode fornecer todo o feedback que
você precisa para o seu projeto. De fato, faz sentido que haja um bom número de testadores, já
que ter uma ampla gama de opiniões pode ser essencial para ir além do preconceito individual e
entender se o seu jogo funciona bem ou não. Embora os argumentos possam ser feitos para
manter o tamanho de sua equipe pequeno, especialmente em termos de designers e programadores,
os testadores de jogo realmente são mais felizes.
O primeiro tipo de playtester é um membro da equipe de desenvolvimento. Esses certamente
não são os únicos testadores que você deve ter, e alguns tecnicamente não considerariam essas
pessoas como testadores. No entanto, durante todo o projeto, é importante que os membros de
sua equipe joguem o seu jogo. Isso serve a vários propósitos. Primeiro, isso os mantém
entusiasmados com o projeto. Assumindo que o desenvolvimento está indo bem, eles veem para
que finalidade sua arte, som, código ou construção de nível está sendo usada. Em segundo lugar,
à medida que veem seu trabalho em ação, ficam mais aptos a entender como ele pode ser
melhorado. E terceiro, eles podem fornecer feedback sobre como o jogo está funcionando e o que
você pode fazer para melhorá-lo. No final do projeto, em particular, quando toda a arte, a maior
parte do código e os níveis estiverem concluídos, os membros da equipe de desenvolvimento
poderão fornecer feedback essencial sobre as seções do jogo que podem precisar de algum
melhorias de última hora. É claro que os membros da equipe de desenvolvimento estão muito
próximos do projeto e, como resultado, podem estar longe de serem objetivos em seus comentários
sobre ele. Além disso, como eles jogam o jogo há tanto tempo, eles terão problemas para vê-lo
com novos olhos e suas opiniões serão distorcidas de acordo. Além disso, uma vez que contribuíram
para o projeto, eles podem gostar ou não de seu próprio trabalho por motivos pessoais. Da mesma
forma, eles podem gostar ou não das ideias de outros membros da equipe não por causa dos
méritos das próprias ideias, mas por causa de suas opiniões sobre essa pessoa. Apesar dessas
desvantagens, obter feedback de teste de jogo dos membros de sua equipe é essencial.

O segundo tipo de playtester é o playtester tradicional. Este é alguém que começa a testar
seu jogo no estágio em que ele entra em “alfa” e é realmente totalmente jogável, e continua até
que o projeto seja lançado. Muitas vezes, esses testadores gastam metade do
Machine Translated by Google

486 Capítulo 25: Teste de jogo

seu tempo rastreando bugs no código, mas eles também fornecem feedback vital sobre como o
jogo está jogando, se é muito fácil ou muito difícil, se os controles são intuitivos ou obtusos, e
assim por diante. Em projetos totalmente financiados, esses testadores geralmente são funcionários
pagos que passam uma semana inteira testando seu jogo e fornecendo relatórios de bugs.
Normalmente, esses testadores adoram jogos de computador e jogam muitos deles, tanto como
parte de seu trabalho quanto em seu tempo livre. Portanto, suas opiniões sobre como a jogabilidade
precisa mudar são compreensivelmente distorcidas para a perspectiva do jogador hard-core.
Além disso, como esses testadores trabalham no projeto por tanto tempo, eles podem se acostumar
com certos problemas inerentes ao jogo e podem parar de reclamar sobre essas deficiências.

Muitos testadores de
primeira impressão foram
usados para refinar e
aperfeiçoar a interface no The Sims.

A terceira classe de playtesters são testadores de primeira impressão. Will Wright, em sua
entrevista no Capítulo 22, refere-se a essas pessoas como “testadores de lenços de papel”, já que
na Maxis eles são usados uma vez e nunca mais. Wright os usou extensivamente para testar a
GUI do The Sims. São pessoas que não estão na equipe de desenvolvimento nem testando o jogo
em tempo integral. Em vez disso, esses testadores jogam o jogo por um curto período de tempo e
fornecem sua reação instintiva sobre o desempenho do jogo. Isso pode ser por algumas horas ou
alguns dias. Esses testadores de primeira impressão são úteis porque veem o jogo como os
jogadores iniciantes veriam. Eles podem fornecer feedback essencial sobre controles não intuitivos,
apresentação pouco clara de informações ou partes injustamente difíceis do jogo. É essencial ao
observar esses testadores de primeira impressão que os desenvolvedores não digam nada para
treiná-los ou influenciar como eles jogam. Além disso, o ponto importante sobre testadores de
primeira impressão é que você deve continuar trazendo novos, já que um humano só pode
realmente ter uma primeira impressão de um jogo uma vez; depois disso, eles são “contaminados”
por seu conhecimento de como o jogo funciona. Especialmente no final do projeto, quando a equipe
de desenvolvimento está extremamente familiarizada com o jogo e os testadores tradicionais já o
jogaram por mil horas ou mais, os testadores de primeira impressão podem ser essenciais para
garantir que o jogo não seja muito difícil de aprender. jogar.
Machine Translated by Google

Capítulo 25: Teste de jogo 487

O quarto tipo de playtesters inclui designers de jogos ou desenvolvedores que não


trabalhando em seu projeto. São pessoas que você conhece e confia e cujas opiniões você respeita. Eles podem
não ser capazes de testar seu projeto em tempo integral como tradicional
testadores podem, mas o feedback que eles fornecem pode ser extremamente útil. Jogo companheiro
designers que não estão trabalhando em seu projeto poderão jogar seu jogo e fornecer informações sobre seus
pontos fortes e fracos de maneiras que outros testadores não podem.
Esses testadores entendem o design do jogo de uma forma que lhes permite analisar como seu
projeto pode ficar curto e como ele pode ser melhorado. Muitos jogos experientes
designers usarão esses testadores particularmente no início do processo, quando ainda
tentando entender se o novo design do jogo é realmente atraente ou não.
Esses designers de jogos que se tornaram testadores serão mais capazes de ignorar as falhas óbvias do jogo
neste estágio inicial, como bugs ou recursos incompletos, e podem parecer
além para ver se o jogo mostra a promessa de se tornar um bom jogo no futuro.
Steve Meretzky, no Capítulo 10, menciona a utilidade dos “Almoços dos Imps”. Nesses
almoços, os implementadores da Infocom se reuniam para discutir seus diferentes projetos de jogos
Ideias. Quando um novo título da Infocom se tornasse jogável, outros implementadores seriam
o primeiro a começar a testar o jogo, enquanto ainda havia tempo para fazer qualquer
mudanças necessárias. É claro que colegas designers de jogos normalmente estarão ocupados demais para gastar
muito tempo jogando seu jogo e dando feedback. Qualquer feedback que esses designers derem a você pode ser
extremamente útil, tanto para ajudá-lo a identificar o problema
áreas que você não havia previsto, além de garantir que seu design está no caminho certo
claro, se realmente for. Se você não tiver a sorte de ter amigos desenvolvedores com
tempo livre suficiente para avaliar seu jogo, existem vários consultores de design no
indústria que, por uma taxa, estão disponíveis para revisar seu trabalho e fornecer informações valiosas
comentários.
A quinta classe de testadores que considero de particular valor são os não-jogadores. Tudo de
os tipos de testadores que discuti até agora foram, em sua maioria, muito grandes
fãs de jogos. Eles terão uma tolerância especialmente alta para as coisas que os jogos tradicionalmente fazem
mal, como ter controles excessivamente complexos ou simplesmente serem muito difíceis de
Toque. Ter algumas pessoas que não são grandes entusiastas pode fornecer um feedback fabuloso,
apontando problemas fundamentais que os jogadores hard-core ignorarão e perdoarão.
Esses testadores podem ser literalmente qualquer um: o cara que vem consertar a máquina de café, um
vizinho, o pai de um membro da equipe ou, literalmente, alguém na rua. Enquanto
eles serão honestos sobre o que pensam do seu jogo, a opinião de qualquer um pode ser valiosa aqui. Combinando
o terceiro grupo, testadores de primeira impressão, com testadores que não são jogadores
pode ser particularmente útil para determinar se uma interface é muito confusa ou se o jogo é
muito implacável. Esses testadores raramente serão capazes de fornecer feedback construtivo sobre
como você pode melhorar seu jogo, mas eles serão capazes de apontar problemas fundamentais de uma forma
que outros testadores não podem.

Quem não deve testar


Existem várias pessoas ou grupos de pessoas em quem você normalmente não pode confiar como
testadores. São pessoas cujas opiniões são influenciadas por suas próprias motivações pessoais, ou que podem
não estar dispostas a fornecer opiniões verdadeiramente objetivas. Embora você possa
ser forçado a ouvir o feedback dessas pessoas, é importante entender as motivações por trás de seus comentários
para que você possa aplicar seus conselhos adequadamente.
Machine Translated by Google

488 Capítulo 25: Teste de jogo

O primeiro desses testadores inadequados é seu chefe. Uma parte fundamental do relacionamento
do designer de jogos com um playtester é ser capaz de obter o feedback do playtester e aplicá-lo como o
designer achar melhor, não como o playtester ditar. Os testadores de jogo geralmente não entendem o
jogo o suficiente para fornecer a melhor solução para um problema que encontram, e se seu chefe for a
pessoa que encontrou o problema, é provável que ele tente impor uma solução a você, mesmo que seja
não é o melhor para a situação.
Alguns chefes podem ser sábios o suficiente para entender que, como designer do jogo, você sabe a
melhor forma de corrigir um problema. Eles mostram os problemas e não se importam em como você os resolve.
No entanto, receber o conselho de alguém que está assinando seu salário não pode ser o mesmo que o
conselho de alguém que está em uma posição menos dominante.
A segunda classe de pessoas inadequadas para testar seu jogo inclui qualquer pessoa do
departamento de marketing. O pessoal de marketing tem muitas agendas conflitantes ao olhar para o seu
jogo e é improvável que lhe diga o que realmente pensa dele. Em vez disso, eles tentarão descobrir o que
o “alvo demográfico” quer. Como mencionei repetidamente neste livro, é extremamente difícil prever o que
um público diferente de você vai gostar ou não, mas é isso que o pessoal do marketing tenta fazer. Você
não quer que a adivinhação deles, que quando se trata de jogabilidade está errada com a frequência certa,
atrapalhe seu jogo. Além disso, as opiniões dessas pessoas provavelmente serão influenciadas pelo que
está “quente” na indústria no momento, muitas vezes caindo na síndrome do “jogo da semana”. Tudo isso
não significa que o feedback deles não tenha valor, apenas que você precisa entender como isso é afetado
por sua própria agenda. Independentemente disso, você não deve considerar o feedback deles da mesma
forma que considera o restante dos seus dados de teste de jogo.

Um terceiro grupo de pessoas que não deve testar seu jogo consiste naqueles que são muito próximos
de você pessoalmente, sejam eles seus amigos próximos, sua família ou seu parceiro. Quando essas
pessoas olham para o seu jogo, embora possam alegar que estão sendo objetivas, sua verdadeira agenda
geralmente é fortalecer seu relacionamento com você. Como resultado, eles hesitarão em criticar seu jogo
com muita severidade. Alguns amigos podem entender que a melhor maneira de fortalecer sua amizade
com você é dizer a verdade, mas muitos vão adoçar suas opiniões por bondade equivocada. É verdade
que muitos autores usam seus cônjuges como sua primeira e mais eficaz linha de crítica, e se você puder
desenvolver um relacionamento que seja tão honesto, pode ser uma coisa maravilhosa.

Mas o fato é que muitos relacionamentos não são tão honestos, e você não deve se enganar pensando
que o feedback deles é completamente objetivo.
O quarto tipo de pessoa que você não quer que teste seu jogo são os idiotas.
Idiotas tendem a dizer coisas idiotas e ter opiniões idiotas, e como resultado não será de muita ajuda para
você. É melhor perceber e isolar os idiotas o mais rápido possível e, se você precisar trabalhar com eles,
aprenda a ignorar tudo o que eles dizem. Claro que estou exagerando; os idiotas certamente não dominam
as equipes de teste. Mas de vez em quando você encontrará um testador que é melhor ignorar
completamente.
O quinto grupo são testadores que pensam que estão projetando seu jogo para você.
Esses testadores podem ter algumas sugestões úteis, mas na maioria das vezes tentarão fazer com que
você mude aspectos do seu jogo não porque estejam errados, mas simplesmente porque teriam feito
diferente. Um testador realmente bom reconhecerá que você é a força artística por trás do projeto e que o
jogo refletirá sua individualidade.
Machine Translated by Google

Capítulo 25: Teste de jogo 489

preferências. Eles vão sugerir maneiras de fortalecer o jogo, em vez de simplesmente mudá-lo.

Um sexto grupo a ser cauteloso são os fãs extremamente hard-core, particularmente aqueles
que são fanáticos pelo gênero do seu jogo ou, no caso de uma sequência, a versão anterior do
jogo. Esses testadores tenderão a ver todas as diferenças em seu jogo em relação a outros jogos
do mesmo gênero como sendo uma falha séria de design e, como resultado, sufocarão qualquer
criatividade que você tente incorporar em seu novo jogo. Atrair os fãs estabelecidos de sua
franquia pode ser muito importante para sequências; no entanto, seguir todos os conselhos deles
pode resultar em um jogo que não seja suficientemente diferente de seus antecessores.

Quando testar
Quando é o momento certo para começar a testar seu jogo? Como discuti anteriormente neste
capítulo, o teste de jogo pode ser uma parte fundamental do ciclo de desenvolvimento do seu jogo,
desde o momento em que você o torna jogável até o lançamento final. Dito isso, há momentos
específicos em que determinados tipos de teste são mais bem aplicados, e outros momentos em
que certos tipos de teste podem ser ineficazes ou até inúteis. Saber quando usar cada tipo de
testador é fundamental para não perder tempo.
É claro que sua equipe de desenvolvimento deve jogar o jogo o máximo possível em todas
as fases de seu desenvolvimento. Como mencionei, isso é essencial para mantê-los interessados
no projeto e para que possam fazer o melhor trabalho possível.
Assumindo que o jogo não está desmoronando, um desenvolvedor que sabe exatamente como
está contribuindo para o projeto e como esse projeto está se saindo estará mais bem informado e
motivado para fazer o melhor trabalho possível.
O teste inicial é melhor feito por pessoas experientes em desenvolvimento de jogos, que você
conhece muito bem e cujas opiniões você tem em alta conta. Os testes iniciais exigem que o
testador ignore muitos problemas: o jogo trava com frequência, toda a arte é reservada, as seções
do jogo estão obviamente incompletas, há apenas um nível para jogar e assim por diante. Muitas
pessoas, ao receberem tal jogo, serão incapazes de olhar além dessas deficiências extremas. Por
exemplo, testadores tradicionais, mesmo que você diga a eles para ignorar as grandes seções do
jogo que estão faltando, provavelmente começarão a apontar os erros completamente óbvios que
precisam ser corrigidos. No entanto, um líder de controle de qualidade bastante experiente
entenderá melhor o processo de desenvolvimento e poderá começar a fornecer feedback valioso
bem cedo no projeto. Além disso, um amigo que também é designer de jogos poderá olhar para o
trabalho e ver além de suas deficiências atuais, vendo se o jogo se mostra promissor. Esses
designers viram seus próprios projetos no estado em que o seu está atualmente e entendem por
que nem tudo funciona ainda. Esses profissionais experientes serão capazes de reconhecer e
explicar os problemas fundamentais que o design do seu jogo contém melhor do que qualquer
outra pessoa.
Faz sentido estabelecer um pequeno grupo de pessoas em cujas opiniões você confia e a
quem você pode mostrar seu jogo em vários estágios de desenvolvimento. Podem ser colegas
designers de jogos, como discutido acima, ou amigos que entendem o processo de desenvolvimento
de jogos e poderão fornecer comentários úteis. Ao longo do projeto, você pode continuar mostrando
seu jogo para esse grupo confiável, para que eles possam ver como o jogo está progredindo e dar
suas opiniões sobre se eles gostam de onde o jogo está indo e se eles acham que essa direção é
o melhor possível. Desde a
Machine Translated by Google

490 Capítulo 25: Teste de jogo

esses testadores trabalharão com você ao longo do projeto, eles terão uma melhor compreensão
do jogo e por que ele se desenvolveu dessa maneira. E, como mencionei antes, se você não puder
pedir favores a amigos que tenham tanta experiência, considere contratar um consultor de design
para vir periodicamente ao longo do projeto e criticar seu trabalho.

À medida que você está implementando a GUI e os controles, fará sentido trazer alguns
testadores de primeira impressão para experimentar esses novos controles. Configure um nível de
teste simples, área ou situação em que os jogadores possam tentar usar os controles e a GUI e
veja como esses testadores se saem. Isso faz sentido, já que o aspecto mais importante do design
de interface e controle é que esses sistemas são tão intuitivos quanto possível, e a melhor maneira
de determinar isso é fazendo com que alguns jogadores iniciantes os experimentem. Não deve
demorar muito para determinar se seus sistemas de E/S são intuitivos, pois se os jogadores não
os descobrirem imediatamente, você saberá que seu jogo precisa ser trabalhado.
À medida que o jogo se torna mais completo, quando a maioria dos recursos está completa e
uma grande parte do jogo é jogável, faz sentido trazer os testadores tradicionais para revisar o
trabalho. Esse período é normalmente chamado de “alfa”, embora essa definição varie de empresa
para empresa. Quando eles começam a testar, os testadores tradicionais encontrarão um número
aparentemente infinito de bugs no código, pois eles tentam todos os tipos de ações que a equipe
de desenvolvimento nunca previu, mas você deve incentivá-los a olhar além dos bugs e fornecer
feedback. sobre a jogabilidade em si, se puderem. É claro que obter feedback neste estágio inicial
é muito melhor do que no “beta” quando, se o projeto estiver em um cronograma apertado, o foco
será menos em refinar o jogo e mais em colocá-lo para fora. Em algum momento, você deixa de
poder fazer mudanças fundamentais na jogabilidade por medo de quebrar o jogo de alguma forma
importante. Como resultado, você precisará fazer alterações em grande escala enquanto ainda há
tempo suficiente para rastrear todos os bugs que podem causar. Mesmo com o balanceamento
simples do jogo, sem tempo para testar completamente as repercussões de uma mudança, você
deixa de poder mudar qualquer coisa por medo de que isso atrapalhe outra coisa. É por isso que
iniciar os testes de jogabilidade com antecedência suficiente para que você ainda possa corrigir os
problemas é tão essencial.
Em projetos com prazos apertados e editais “devem ser enviados até o Natal”, a administração
às vezes gosta de pensar que pode acelerar o desenvolvimento trazendo testadores mais cedo, às
vezes muito antes de o jogo atingir o alfa. Dessa forma, eles pensam erroneamente, uma vez que
o jogo finalmente chega ao beta, ele já terá a maioria de seus bugs removidos e poderá ser enviado
imediatamente. Claro, o que eles não entendem é que, antes de um jogo ser “completo”, é provável
que mude fundamentalmente do ponto de vista do código. À medida que esse código muda de
maneiras importantes, os bugs antigos são eliminados completamente enquanto os novos são
introduzidos. Se os testadores apontarem bugs no código antigo e os programadores tiverem que
gastar tempo corrigindo-os, isso é essencialmente um desperdício de tempo, já que esses bugs
seriam eliminados completamente mais tarde, quando partes do código fossem reescritos, e você
ainda ficaria com os novos bugs que a reestruturação do código trará. Dito isso, pode fazer sentido
trazer um pequeno grupo de testadores muito experientes mais cedo, que possam fazer testes
direcionados de sistemas específicos que a equipe de desenvolvimento acha que estão prontos
para teste.
Até certo ponto, o mesmo vale para a jogabilidade. Quando grandes partes do jogo estão
faltando, fazer com que os testadores relatem problemas como “Níveis 10, 12 e 17 não têm
inimigos para lutar e, portanto, não são muito divertidos de jogar” está longe de ser útil. Forçando
Machine Translated by Google

Capítulo 25: Teste de jogo 491

designers passarem por esses bugs sem sentido desperdiçarão muito mais tempo do que
podem economizar. Faz mais sentido trazer os testadores tradicionais apenas quando o jogo
estiver em um estado que seja realmente apropriado para teste. No final, trazê-los cedo demais
só atrasará o progresso do jogo.

Como testar
Como você faz seus testadores trabalharem em seu jogo é tão importante quanto quem você
testa e quando você os faz. Os designers de jogos costumam arruinar a eficácia de seus
testadores cometendo vários erros fundamentais na maneira como interagem com eles. Todos
esses são problemas que podem ser facilmente evitados, desde que o projetista esteja
consciente da maneira como lida com seus testadores e do que faz e não diz a eles.
A parte mais importante da interação com os testadores é passar a maior parte do tempo
assistindo-os jogar em vez de dizer a eles como jogar. Deixe-os jogar o jogo do seu jeito e veja
como eles se saem. A tentação de corrigir as ações dos playtesters é grande e pode ser difícil
de resistir. No momento em que os testadores tradicionais começam a jogar, o designer já
jogou tanto que está intimamente familiarizado com o que os jogadores “devem” fazer em uma
determinada situação e como o jogo “deve” ser. jogado em geral. Ao assistir por cima do ombro
de um playtester pela primeira vez, a tentação é dizer: “Vá até lá em seguida” ou “Você quer
usar os botões strafe para isso” ou “Por que você não tenta pegar o poder-foozle?” Observar
alguém tropeçar enquanto joga um jogo com o qual o designer está intimamente familiarizado
pode rapidamente transformá-lo em um professor.

Mas o objetivo do teste de jogo é ver como os jogadores realmente jogarão o jogo sem
que o designer do jogo treine todos os seus movimentos. Certamente, o designer não pode
caber na caixa em que o jogo vem ou mesmo ser baixado pela internet. Uma certa quantidade
de tropeços e aprendizado dos controles é de se esperar, e a melhor maneira de jogar é deixar
os testadores fazerem essa exploração inicial por conta própria. E se os jogadores realmente
ficarem presos ou se eles nunca conseguirem dominar os controles, o designer precisa se
perguntar o que está causando esses problemas. O jogo é muito difícil ou muito confuso?
Como torná-lo mais simples para que os jogadores tenham uma boa chance de entendê-lo e
aprender a jogar? Essas são as lições que um designer deve tirar do playtest, mas são lições
que o designer nunca aprenderá se corrigir o jogo do testador a cada passo. Além disso,
quando me sento em uma sessão de playtesting, se os testadores não souberem melhor, tento
fingir que não estou na equipe de desenvolvimento para evitar que eles coloram suas opiniões
para serem legais comigo. De fato, a maioria dos testes de foco de jogabilidade são conduzidos
usando um espelho unidirecional, uma vez que as pessoas se comportam de maneira diferente
quando pensam que estão sozinhas do que se tiverem alguém de pé sobre seus ombros
fazendo anotações, independentemente de quão quieta essa pessoa seja ou de quem ela afirme. ser es
Enquanto observa os testadores jogarem, o designer deve tentar observar a maneira como
eles tentam jogar o jogo. Os jogadores não podem tentar a abordagem ou solução que o
designer pensou para uma situação específica. O designer deve então perguntar se o jogo
suporta o que o testador está tentando fazer e, se não, poderia e deveria? O período de teste,
se iniciado cedo o suficiente, é um momento em que o designer pode adicionar uma amplitude
de conteúdo ao jogo que permitirá que o jogo realmente aceite vários estilos de jogo. Até este
ponto, as pessoas que jogavam o jogo estavam limitadas ao
Machine Translated by Google

492 Capítulo 25: Teste de jogo

equipe de desenvolvimento e os testadores preliminares que podem ter sido trazidos. Agora que
há uma gama maior de pessoas jogando o jogo, o designer provavelmente observará uma gama
maior de estilos de jogo do que ele havia previsto. O período de teste é quando o designer pode
fazer com que o jogo aceite esses estilos de jogo, permitindo que os jogadores realmente joguem
o jogo do seu jeito em seus próprios termos.
É claro que o designer não pode estar presente em todos os testes de jogo que o jogo
passará, não se o jogo for completamente testado e lançado em um prazo razoável. Muitas vezes,
você precisará confiar no que os testadores relatam a você sobre suas experiências de jogo.
Embora não seja tão útil quanto assistir os testadores jogarem em primeira mão, essa informação
pode ser bastante útil. Quando você recebe esse feedback, é crucial ouvir verdadeiramente o que
os testadores lhe dizem. Isso pode parecer óbvio, mas é surpreendente quantos designers preferem
ignorar o feedback que recebem em seu jogo.
Muitas vezes, a maioria dos testes de um jogo, particularmente aqueles feitos por testadores
tradicionais, ocorre no final do processo de desenvolvimento, depois de muito trabalho ter sido
colocado no projeto. Neste ponto, o designer provavelmente está bastante confiante de que o jogo
está funcionando como ele quer que funcione. Portanto, pode ser difícil para o designer ouvir os
testadores contradizer isso, talvez apontando problemas fundamentais no jogo que o designer
procurou por meses de desenvolvimento.
A primeira defesa do designer é muitas vezes alegar que os testadores não sabem do que
estão falando. As desculpas podem variar desde o testador ser um tolo até o testador não ser o
público-alvo do jogo até o testador apenas reclamar por causa disso.
Concedido, muitas vezes os testadores fazem sugestões para mudanças na jogabilidade que
devem ser evitadas, e se apenas um testador em dez sugerir que uma determinada parte da
jogabilidade precisa ser alterada, pode ser por causa da preferência pessoal desse testador. Mas
quando o designer ouve a mesma reclamação de vários testadores diferentes, ele precisa perceber
que provavelmente há algo errado com o jogo que precisa ser resolvido. Os testadores podem nem
estar reclamando sobre o aspecto certo do jogo ou sugerindo uma correção apropriada, mas o fato
de que algo está arruinando sua experiência merece investigação. O designer deve evitar descartar
as reclamações dos testadores e analisar honestamente cada reclamação para ver se ela tem
algum mérito. É incrível o número de designers que vão resistir a toda e qualquer sugestão que os
testadores fazem. Muitas vezes, esses mesmos designers se arrependem de sua obstinação mais
tarde, quando o jogo é finalmente lançado, apenas para ter jogadores e membros da imprensa
reclamando dos mesmos problemas que os testadores reclamaram anteriormente. Claro, uma vez
que o jogo é lançado, é tarde demais para fazer algo radical sobre os problemas.

Testes guiados e não guiados


Pode-se dividir o tipo de teste que está sendo feito no projeto em duas classes distintas: guiado e
não guiado. O teste guiado geralmente acontece no início do projeto, quando o jogo ainda não está
completamente funcional. Nesse período, o designer sabe quais partes do jogo estão claramente
incompletas, mas quer obter algum feedback sobre uma seção do jogo que ele acha que está
funcionando razoavelmente bem. Em seguida, o designer pode direcionar os testadores para
experimentar um determinado nível ou seção de jogo. O teste direcionado também pode ocorrer
mais tarde no projeto, quando o jogo inteiro está funcionando, mas uma seção específica acaba de
ser alterada ou retrabalhada. Neste ponto, o designer pode precisar de feedback apenas sobre essa seção,
Machine Translated by Google

Capítulo 25: Teste de jogo 493

para ver se as alterações corrigem um problema existente ou quebram o jogo de alguma forma
importante. Um designer também pode direcionar seus testadores para tentar maneiras loucas e
ilógicas de jogar o jogo, para ver se o jogo quebra nessas circunstâncias. O que pode parecer uma
maneira tola de jogar o jogo para você ou até mesmo o testador pode muito bem ser um estilo que
muitos jogadores tentarão usar ao jogar o produto final. Os testadores mais experientes sabem
continuar tentando todos os estilos de jogo que podem imaginar ao testar o jogo.
É essencial permitir e incentivar seus testadores a fazer testes não guiados também.
Dê-lhes o jogo, diga-lhes para começarem a jogá-lo, observe o que eles fazem e ouça o feedback
deles. Muitos designers cometem o erro de usar apenas testes guiados, geralmente fazendo com que
os testadores testem apenas o sistema no qual estão trabalhando no momento. Quando os testadores
apresentarem reclamações sobre alguma outra parte do jogo, o designer reclamará que não está
interessado em trabalhar nisso agora, ou que a parte problemática do jogo já está “pronta”. O teste
dirigido tem seu lugar, mas se é tudo o que o designer faz, é provável que ele perca problemas
maiores no jogo que ele pode nem ter percebido que eram problemáticos. Testes não direcionados
dão ao designer feedback sobre o jogo de forma holística, algo essencial para resolver todos os seus
problemas.
É claro que, mesmo quando você direciona seus testadores para testar apenas uma determinada
seção do seu jogo, muitas vezes eles não serão capazes de resistir a apontar os outros problemas
que encontrarem ao longo do caminho. É preciso um testador extremamente disciplinado para testar
verdadeiramente apenas o sistema que o designer solicita. Receber feedback sobre partes do jogo
em que você não está trabalhando no momento pode ser frustrante, mas pode ser útil a longo prazo.
Quando os testadores lhe derem sugestões fora do tópico sobre como melhorar o jogo, mesmo que
você não queira resolver esses problemas imediatamente, tome cuidado para anotá-los para voltar mais tarde.
Nada é mais frustrante do que reconhecer um problema no jogo depois que ele foi lançado, apenas
para perceber que um de seus testadores lhe contou sobre o problema a tempo de corrigi-lo.

Balanceamento
A única vez em que você pode equilibrar adequadamente um jogo é quando a maior parte do jogo
está concluída. Equilibrar seu jogo com antecedência, antes que toda a jogabilidade esteja funcionando
e todos os níveis, se houver, sejam feitos, só pode ser considerado um balanceamento preliminar. O
balanceamento preliminar pode ser muito valioso, no entanto, e você vai querer fazê-lo apenas para
que seu jogo se divirta o mais cedo possível, com o pleno conhecimento de que precisará ajustá-lo
mais tarde. Dito isto, você não pode realmente ter uma noção de como o jogo inteiro precisa funcionar
e como a dificuldade deve aumentar ao longo de todo o jogo até que o conteúdo do jogo esteja
completo. Você pode ver seu jogo como uma coleção de diferentes sistemas que formam um grande
sistema. Para um jogo baseado em níveis, cada nível pode ser considerado um sistema em si. Então,
dentro de cada nível, cada encontro de combate ou quebra-cabeça pode ser considerado um sistema.
Para que o jogo seja equilibrado, todos esses sistemas devem estar em vigor, pois a alteração de um
sistema afeta como os outros sistemas devem ser configurados para alcançar o equilíbrio geral que
você procura. Ao mesmo tempo, se você esperar que todos os sistemas sejam finais e alguns estejam
atrasados, você pode ficar sem tempo para deixar o jogo tão equilibrado quanto quiser. Por exemplo,
em The Suffering, muitos aspectos dos níveis não foram concluídos até bem tarde no desenvolvimento
e, como resultado, o balanceamento foi adiado até que fosse tarde demais para fazê-lo no nível de
qualidade que gostaríamos. Iniciando
Machine Translated by Google

494 Capítulo 25: Teste de jogo

equilibrar um pouco mais cedo, antes que cada elemento do jogo esteja pronto, pode ser
necessário para garantir que você não fique sem tempo.

Balanceamento em
The Suffering
ocorreu muito tarde
no desenvolvimento.

O momento em que o jogo está em grande parte completo e o verdadeiro balanceamento


se torna possível geralmente coincide com o momento em que o jogo está em teste completo.
Isso funciona da melhor maneira, já que balanceamento e teste são atividades intimamente
interligadas. O balanceamento geralmente envolve alterar algumas configurações do jogo e
depois jogá-lo para ver se essas mudanças criam a quantidade de desafio em que você está
interessado. Para cada passagem no balanceamento, você e os testadores devem tentar jogar
o jogo. Em seguida, os testadores podem fornecer feedback sobre quão eficazes foram seus
esforços para equilibrar o jogo e, combinado com sua própria análise da condição do jogo, você
pode fazer mais alterações e repetir o processo novamente. As pessoas que conseguem
equilibrar um jogo sozinhas, sem a participação de outros testadores, são raras. Muitas vezes,
os designers que tentam equilibrar um jogo sozinhos conseguem equilibrar o jogo apenas para
si mesmos, geralmente resultando em um jogo muito difícil.
A melhor maneira de equilibrar o jogo é dividir os diferentes sistemas em grupos de
números que podem ser facilmente ajustados e ajustados. Por exemplo, suponha que você
esteja fazendo algum tipo de jogo de ação de combate corpo a corpo. Se os jogadores usarem
um taco de beisebol no jogo, esse taco terá vários atributos diferentes associados a ele, como
quanto dano ele causa, quão rápido ele ataca, quantas vezes ele pode ser usado antes de
quebrar, quanto custa comprar, quantas mãos são necessárias para segurá-lo e assim por diante.
Da mesma forma, pode-se também dividir os atributos de inimigo, jogador e outros atributos
do sistema em coleções de números que podem ser ajustados para variar a utilidade ou desafio
daquele objeto. São esses valores que você ajustará e massageará continuamente para
alcançar o equilíbrio que procura. Isso, claro, pressupõe que em um nível básico seu jogo já é
divertido, com uma variedade suficiente de encontros desafiadores. Se você esperar até tarde
demais para ter o jogo divertido em um nível básico, pode se tornar muito arriscado fazer as
alterações necessárias.
Machine Translated by Google

Capítulo 25: Teste de jogo 495

Enquanto você está se equilibrando, você deve estar bem ciente de como os diferentes
valores que você muda afetam uns aos outros. Você pode mudar uma arma para tornar uma
situação de combate muito divertida, mas acaba tornando outro local no jogo realmente imbatível.
Quanto mais complexo for o seu jogo, maior será o impacto das alterações feitas nos sistemas que
você pode ignorar. Enquanto você está equilibrando, você deve considerar completamente cada
parte do jogo que suas mudanças estão afetando e certifique-se de não quebrar o jogo. A única
maneira de ter certeza de que você não jogou fora o jogo inteiro é testando-o completamente.
Como resultado, fazer alterações significativas perto da data de envio é uma experiência
estressante. E se as alterações que você fizer quebrarem algo que ninguém pega antes que o jogo
seja enviado para o duplicador?
É claro que o método de balanceamento que descrevi acima exige que os dados que afetam
o comportamento das diferentes entidades do jogo sejam acessíveis e modificáveis pelo designer.
Isso significa que o código precisa ser escrito de forma a facilitar a alteração dessas informações.
Este último ponto pode parecer óbvio, mas já vi muitos mecanismos nos quais alterar informações,
como estatísticas de armas, estava longe de ser fácil ou totalmente impossível. Desde o início do
desenvolvimento do jogo, os programadores devem ter em mente como os designers irão equilibrar
o jogo no final do projeto. Se, em vez disso, eles enterrarem uma coleção de “números mágicos”
no código, o jogo ficará “bloqueado” em um estado específico, impossibilitando o equilíbrio. Embora
o balanceamento só possa ocorrer quando o jogo estiver praticamente completo, a equipe de
programação deve começar a se preparar para esse balanceamento desde o início do projeto ou o
balanceamento eficaz será impossível. Para que o designer tenha alguma chance de equilibrar
bem o jogo, essas informações de balanceamento devem ser extraídas do código por meio de
arquivos de configuração, ferramentas de edição de níveis ou outros formatos acessíveis ao
designer.

Seu jogo é muito difícil


Quando escrevi a primeira edição deste livro, incluí o seguinte parágrafo: Ao equilibrar
seu jogo, você deve sempre ter em mente uma regra prática: seu jogo é muito
difícil. Independentemente do tipo de jogo que você está fazendo ou do quão
talentosa sua equipe de desenvolvimento pode ser, quando seu jogo estiver
perto da conclusão e entrar em teste, será muito difícil.

Tendo acabado de completar O Sofrimento, no entanto, agora posso dizer que nem sempre é esse
o caso. Seguindo a regra geral “seu jogo é muito difícil”, conseguimos tornar The Suffering muito
fácil, pelo menos de acordo com a imprensa e muitos dos fãs. Isso ocorreu em parte porque não
alocamos tempo suficiente para equilibrar o jogo, como mencionei anteriormente.
No entanto, ainda acho que o parágrafo acima contém muita verdade, já que na maioria das vezes
os jogos são muito difíceis quando entram na fase de equilíbrio.
Os jogos geralmente são muito difíceis porque, até o ponto em que os testes começam,
apenas a equipe de desenvolvimento tem jogado o jogo de forma consistente. A equipe de
desenvolvimento tem trabalhado no projeto de nove a dezoito meses e durante esse tempo eles
aprimoraram suas habilidades de jogo e se tornaram muito bons no jogo, provavelmente melhores
do que 90% dos jogadores que jogarão o jogo. A fim de manter a jogabilidade interessante para si,
a equipe de desenvolvimento tornou o jogo um pouco desafiador para eles próprios jogarem, o que
por sua vez significa
Machine Translated by Google

496 Capítulo 25: Teste de jogo

será muito difícil para 90 por cento dos jogadores lá fora.


O primeiro comentário que os testadores costumam fazer é: “Este jogo é muito difícil”. Como
discuti acima, sua primeira reação será ignorar essa reclamação, atribuir isso à incompetência ou
inexperiência deles com o jogo. “Eles vão melhorar”, você pode dizer. E, infelizmente, isso é
verdade. Se o jogo passar três meses em testes, os testadores serão tão bons no jogo quanto o
resto da equipe de desenvolvimento. Então eles também provavelmente vão parar de pensar que
o jogo é difícil. É totalmente provável que o jogo seja lançado com a equipe de desenvolvimento,
incluindo os testadores, sem ter ideia de quão difícil é.
Como designer, você deve ter muito cuidado para manter uma noção honesta de quão difícil
é o seu jogo e, durante a fase de balanceamento, você deve se concentrar em tornar o jogo algo
que os jogadores iniciantes tenham uma chance razoável de ter sucesso quando começarem.
jogando. Lembre-se sempre de qual foi a primeira impressão dos testadores e pergunte a si mesmo
se você abordou os problemas que eles identificaram imediatamente.
Se necessário, você deve trazer novos testadores de primeira impressão para ver se o jogo ainda
é muito difícil.
Infelizmente, às vezes você nem sempre consegue tornar seu jogo mais fácil apenas com o
balanceamento. Você pode ter criado um design de jogo que, em um nível fundamental, é difícil de
jogar. Se você realmente quer que seu jogo seja algo que os jogadores iniciantes tenham facilidade
em entrar, você precisa se concentrar nisso desde o início do design do seu jogo. Meu projeto
Centipede 3D é um bom exemplo de como um jogo pode se tornar muito mais difícil do que a
equipe de desenvolvimento jamais imaginou. Tentativas foram feitas para equilibrar o jogo para
torná-lo mais fácil, mas a jogabilidade foi intrinsecamente projetada para combinar com a do jogo
de arcade original. Como resultado direto, Centipede 3D fez todo o possível para tornar o jogo dos
jogadores curto e rápido. Infelizmente, os jogadores de jogos caseiros querem que seus jogos
durem um pouco mais do que recebem por 25 centavos no fliperama. Por mais difícil que o jogo
fosse em sua versão de lançamento, é assustador pensar que antes de entrar na fase de equilíbrio
o jogo era facilmente dez vezes mais difícil.

Os jogos Marathon
foram testados quanto
à dificuldade, forçando
a equipe de
desenvolvimento a
jogar o jogo na
dificuldade mais difícil
usando apenas a arma
mais fraca, o punho. Na
foto: Maratona 2.
Machine Translated by Google

Capítulo 25: Teste de jogo 497

Quando o designer Jason Jones estava equilibrando os jogos Marathon , ele tinha uma técnica
interessante para garantir que o jogo não fosse muito difícil. Se ele e outros membros da equipe de
desenvolvimento pudessem jogar o jogo inteiro em sua configuração mais difícil usando apenas a arma
“punho” do jogo, ele imaginou que o jogo seria razoavelmente desafiador para outros jogadores. Claro, outros
jogadores obtêm armas muito mais poderosas e fáceis de usar do que o punho, e eles não precisam jogá-lo
na dificuldade mais difícil. Jones se prejudicou para ver o quão difícil seria o jogo para jogadores normais.

Usar técnicas como esta é sábio. Se o designer puder vencer o jogo com os dois braços amarrados nas
costas, outros jogadores provavelmente terão uma boa chance de jogar com os dois braços à sua disposição.

No final, equilibrar o seu jogo geralmente é mais um “sentimento instintivo” do que qualquer outra coisa.
Alguns desenvolvedores, como a Microsoft, tentaram desenvolver testes mais objetivos para determinar o
quão equilibrado é um jogo, acumulando métricas do jogador sobre o tempo médio que os jogadores
passaram em um nível, número de vezes que falharam em um desafio antes de passá-lo, quanta munição
eles se esgotaram, e assim por diante. Embora esses dados possam ser bastante valiosos, eles nunca
podem substituir totalmente o instinto de design. Embora você quase sempre suponha que seu jogo é muito
difícil, existem algumas outras regras que você pode seguir para equilibrar seu jogo.
Você precisa ser capaz de ver seu jogo de forma holística, entender como os jogadores que têm muito menos
experiência com o título do que você o jogarão e perceber o que os desafiará sem ser injusto ou mesmo
cruel. Saber equilibrar um jogo é uma habilidade que vem com a experiência, tanto de jogar outros jogos
quanto de projetar o seu próprio. Para se tornar realmente hábil no equilíbrio, você deve fazer as duas coisas
o máximo possível.

A Visão Artística
Mencionei em vários pontos ao longo deste livro o mal que é conhecido como grupo focal. É importante
entender a distinção entre playtesters e grupos focais. Grupos focais, particularmente aqueles reunidos no
início do desenvolvimento de um jogo, geralmente são grupos de pessoas “fora da rua” que recebem uma
apresentação de uma ou duas horas, geralmente em uma série de jogos diferentes. Muitas vezes eles não
têm permissão para jogar os jogos, pois muitas vezes os jogos ainda nem foram desenvolvidos. Eles ouvem
sobre conceitos de jogos e, com base nas descrições, são questionados se estariam interessados em
comprar tal jogo ou não. Os playtesters, por outro lado, são pessoas que os membros da equipe de
desenvolvimento conhecem ou que pelo menos têm a chance de conhecer.

Conhecer uma pessoa é crucial para entender o quão seriamente você deve levar sua opinião. Além disso,
os testadores podem jogar os jogos em questão, enquanto os primeiros membros do grupo de foco
geralmente não. Como resultado dessas diferenças fundamentais, os grupos focais tendem a ser antitéticos
à criação de jogos originais e criativos e incentivam o desenvolvimento de jogos seguros e menos inovadores.
Como Mark Cerny colocou, um grupo de foco pode dizer principalmente “o que era legal quinze minutos
atrás”. Pode-se imaginar como o grupo de foco para jogos como Pac-Man, Tetris ou Civilization reagiria.
Sabemos pela entrevista com Will Wright no Capítulo 22 que o grupo de foco do The Sims foi tão ruim que o
jogo quase foi cancelado. Deveria dizer que os grupos focais são administrados pelo departamento de
marketing, enquanto os testes de jogo são administrados pela equipe de desenvolvimento. O principal
interesse de um grupo é ganhar dinheiro para a empresa da maneira mais simples possível,
Machine Translated by Google

498 Capítulo 25: Teste de jogo

enquanto o segundo, espera-se, está interessado em produzir jogos atraentes e estimulantes. É


claro que os dois motivos não precisam necessariamente estar em desacordo, mas quando se visa
principalmente o primeiro em vez do segundo, é provável que acabe sem nenhum dos dois. Os
grupos de foco também podem ser conduzidos posteriormente no desenvolvimento, quando o grupo
pode realmente jogar uma seção do jogo. Esses testes podem ser muito mais úteis e informativos,
principalmente ao tentar obter a opinião de pessoas que não jogam muitos jogos. Uma vez que
estas são pessoas “fora da rua”, no entanto, será difícil avaliar a opinião individual de cada pessoa.
Como resultado, para que os dados do teste de foco sejam estatisticamente válidos, você precisará
de um número bastante grande de participantes.

Quando lançado, Tetris


era um jogo
extremamente único. As
chances são de que um
grupo de foco inicial para
o jogo teria sido terrível.
Retratado aqui: modo
clássico em The Next
Tetris.

Como você está testando, é importante lembrar que você não pode agradar a todos.
Dada uma equipe de teste grande o suficiente, é provável que haja pessoas que não gostem de
partes do seu jogo, ou mesmo que não gostem do jogo inteiro. Se você começar a tentar deixar
todas as pessoas da equipe de teste felizes, muitas vezes acaba tornando o jogo menos divertido
para outras pessoas. Embora você possa ter começado com um jogo que muitas pessoas gostaram
muito e algumas pessoas acharam chato, se você começar a tentar agradar a todos, pode acabar
com um jogo que todo mundo acha bom, mas que ninguém gosta. verdadeiramente entusiasmado.
Dada a escolha, eu sempre prefiro dar a um certo grupo de pessoas uma experiência que eles
realmente amam do que tentar dar a todos algo que eles gostam apenas marginalmente.
Playtesting também não deve significar design de jogo por comitê. Você não precisa pegar
todas as sugestões que sua equipe de desenvolvimento apresenta e implementá-las. Algumas
dessas idéias podem ser perfeitamente razoáveis, mas você pode sentir que elas simplesmente não
se encaixam no seu jogo. Essa é uma resposta totalmente aceitável para se ter. No final, pode ser
que cada playtester que você tenha lhe diga que alguma parte do jogo deve mudar, mas se você
sente, no fundo, como um artista, que não quer mudar essa parte do jogo, então deixe como está.
No final, você deve ser o árbitro final do que acontece no jogo. Um comitê, seja composto por
executivos, testadores ou até mesmo membros da equipe de desenvolvimento, nunca pode ter a
unidade de visão e certeza de propósito que pode ser mantida por uma única pessoa. Isso torna o
desenvolvimento de jogos um
Machine Translated by Google

Capítulo 25: Teste de jogo 499

proposição mais arriscada para o designer de jogos, já que se o jogo falhar, ele será o
grande culpado. Ao mesmo tempo, se for bem-sucedido, as pessoas reconhecerão sua
impressionante conquista. Afinal, ser artista e fazer um trabalho de qualidade é correr riscos.
Machine Translated by Google

Capítulo 26
Entrevista: Douglas
Igreja

Em uma indústria cada vez mais empenhada em fornecer uma experiência mais
cinematográfica, altamente orquestrada e amplamente roteirizada para os jogadores,
alguns desenvolvedores continuaram a contrariar a tendência. Esses dissidentes
insistem que não é o designer de jogos sozinho que deve criar uma experiência de jogo,
mas sim o designer e o jogador em colaboração. Ao criar jogos onde os jogadores
fazem escolhas significativas e complexas, esses designers se esforçam para enfatizar
a interatividade que, entre todas as formas de arte, apenas os jogos podem proporcionar.
É interessante notar que a maioria desses desenvolvedores está de alguma forma
ligada à história do desenvolvedor de Boston Looking Glass Studios, que na década de
1990 criou uma série de jogos excepcionalmente atraentes que estavam muito à frente
de seu tempo. Uma das pequenas bandas originais de designers/programadores lá no
início do Looking Glass, Doug Church foi um dos principais visionários de design do
estúdio. Em particular, seus três jogos Ultima Underworld, System Shock e Thief
ultrapassaram os limites do que um jogo imersivo e baseado em sistemas poderia ser,
ao mesmo tempo em que misturava técnicas inovadoras de narrativa. Church é aquele
designer raro que abdicou totalmente da autoria da experiência de jogo para seus
jogadores, contando com sua criatividade para completar a equação que leva a uma
experiência interativa verdadeiramente atraente.

500
Machine Translated by Google

Capítulo 26: Entrevista: Doug Church 501

Qual foi a sua motivação para entrar no desenvolvimento de jogos?


Eu trabalhei em alguns joguinhos na faculdade com alguns amigos, então eu estava meio
interessado em jogos na época. Encontrei alguns amigos e comecei a escrever alguns jogos
online, nada muito sofisticado, mas era divertido fazer pequenos projetos criativos de três a
quatro pessoas. Meu primeiro show não foram jogos, porém, foram simulações de rede. Mas
então, quando ouvi que um amigo de um amigo estava começando um grupo de jogos, pensei:
“Claro, isso parece mais divertido”. Eu não sei, a motivação para dirigir pode ser um pouco forte,
mas eu definitivamente gostava disso. E eu definitivamente estava procurando oportunidades
para fazer jogos.

O que o desenvolvimento de jogos atraiu você para ele?


Eu sempre joguei. A ideia de estar em uma experiência interativa é realmente atraente e a ideia
de criar isso e deixar as pessoas experimentarem sempre foi algo que parecia legal. Eu sempre
gostei de ler ficção, e os jogos pareciam um passo natural em alguns aspectos. Diferente de
outras maneiras também.

Quais foram as origens do projeto Ultima Underworld ?


Paul Neurath e Ned Lerner
foram para Wes Leyan juntos
e depois fizeram um jogo
chamado Deep Space for Sir
Tech. Então Paul saiu e fez
Space Rogue para Origin e
Ned saiu e fez um Chuck
Yeager inicial para EA, e
então ele fez Car & Driver.
Space Rogue já era meio
RPG, mas com um motor de
vôo 3D de contagem de
polígonos muito, muito baixo.
Ultima Underworld: O Abismo Stygian
E nesse mesmo sentido ele
teve a ideia de fazer um
simulador de masmorras. E então ele montou uma pequena equipe de quatro de nós em maio
de 1990, e usando parte do código de montagem da Car & Driver, parte do antigo código
matemático de Paul, mais um monte de código que hackeamos juntos, escrevemos uma demo
em May, que ele então levou para a CES em junho de 1990 para mostrar à Origin. E ele disse a
eles: “Ei, vamos fazer um simulador de masmorra 3D; vai ser ótimo.” E eles basicamente
disseram: “Claro, tanto faz, diga-nos quando terminar”.
Então, nós meio que trabalhamos nisso por um ano, colocando a tecnologia básica em
funcionamento, e depois lançamos alguns conceitos de história. E então aquele que um dos
outros caras e eu escrevemos pegou o suficiente para que eles se sentissem confortáveis com
ele como um Ultima, e então fomos em frente e construímos isso, basicamente. Nós só fomos ao
Texas duas vezes nesse projeto, uma vez no ponto de dez meses e outra no ponto de dezesseis
meses. Warren [Spector] foi o terceiro produtor do projeto, mas foi ele quem o manteve. Ele entrou por vo
Machine Translated by Google

502 Capítulo 26: Entrevista: Doug Church

no meio do projeto, e então no último trimestre ele começou a vir muito para Boston.

A Origin não era muito protetora da franquia Ultima ?


Bem, a primeira história que foi escrita, que eu não escrevi, mas um dos outros caras escreveu, era
um pouco de fantasia tradicional demais e não tinha elementos de Ultima suficientes , e eles
disseram: “Bem, isso não parece muito Ultima. Tente novamente." Eu era um grande fã de Ultima , e
Dan Schmidt, que foi o outro cara que escreveu a história de Underworld, talvez não fosse tão grande
fã de Ultima quanto eu, mas ainda era um grande fã. Portanto, não abordamos como que história
queríamos escrever, mas sim o que era uma história legal de Ultima que poderíamos contar. Nós
certamente achamos divertido e interessante, mas estávamos muito conscientes de como escrever
uma história de Ultima aqui. Nós certamente não escrevemos a melhor ou mais incrível história de
Ultima já escrita – nós a escrevemos em cerca de dois dias ou o que quer que seja – mas estávamos
definitivamente pensando “Deveria haver as oito virtudes, e é uma história de Ultima ”. E eles eram
basicamente “Bem, parece muito Ultima, vá em frente”.

Ultima Underworld parece ter sido bastante ambicioso em como misturou gêneros,
combinando tecnologia de simulação com um RPG. Como isso aconteceu?

Você tem que dar muito crédito a Paul primeiro, simplesmente porque ele teve a ideia inicial. E se
você olhar para trás no Space Rogue, esse era um RPG de mapa de ladrilhos 2D no estilo Ultima,
mas então você entrava em sua nave e voava em 3D e atirava em piratas ou não e atirava em
policiais ou não. Era um RPG de história bastante inicial e bastante aberto com um elemento 3D de vôo espacial.
Que era definitivamente um gênero muito híbrido, porque o material espacial era muito chamativo,
onde havia buracos de minhoca onde você tinha que seguir esses anéis 3D pelo espaço, e havia
batalhas e trocas, e ainda havia essa pequena caminhada baseada em histórias. ao redor do mapa
de peças, converse com as pessoas e assim por diante. Então eu acho que foi muito natural para
Paul.
Dos caras originais que
foram contratados, havia
algumas pessoas que tinham
um pouco de experiência no
jogo. Um deles nós nos
livramos bem cedo porque ele
não era apropriado para o que
estávamos fazendo, e então
os outros dois caras que
pegamos eram amigos meus
da escola que eu recrutei.
Então, três de nós quatro
construindo a tecnologia e
Ultima Underworld II: Labirinto dos Mundos
todos nós fazendo o design,
nenhum de nós tinha experiência em jogos e todos tínhamos vinte anos. Na faculdade, no final dos
anos 80, os consoles não eram tão importantes. Na verdade, eu tinha jogado Space Rogue porque
um dos meus amigos tinha um Mac, mas os clusters eram todos caixas Unix, então eu corri
Machine Translated by Google

Capítulo 26: Entrevista: Doug Church 503

X-Trek e Net Hack e coisas assim, mas eu não tinha jogado um jogo de PC em cinco anos ou algo
assim. Então nós apenas dissemos: “Vamos fazer um jogo de masmorra muito legal em 3D, vamos
lá”. É interessante, porque muitas pessoas falam sobre como estávamos fazendo um jogo de
Dungeon Master , mas até onde eu sei nenhum de nós jamais jogou Dungeon Master. Era um “Ei,
vamos nessa”. Não tínhamos ideia de que estávamos fazendo algo que não fosse apenas óbvio
em algum sentido, porque não tínhamos contexto e a última vez que qualquer um de nós jogou um
jogo foi quando tínhamos quatorze anos. Jogávamos jogos na faculdade, mas eram muito
diferentes; você está jogando X-Trek em rede ou algo assim, não parece um jogo de computador
doméstico. Para Underworld , escrevemos quatro sistemas de movimento e três sistemas de
combate, porque acabamos de escrever algo: “Ah, isso parece legal, vamos em frente”. Ficávamos
pela metade e dizíamos: “Eh? Isso não está funcionando.” O que é bom de várias maneiras; nos
permitiu fazer muitas coisas que provavelmente não teríamos feito de outra forma. Mas também
significava que trabalhávamos muito. Todo o tempo, basicamente, por muito tempo. Gastamos
muito tempo e muita energia para fazê-lo funcionar.

Dado tudo isso, é bastante impressionante que acabou tão bem quanto foi.
Foi meio incrível que já foi feito. Lembro que meu primeiro pensamento quando o vi em uma loja
foi: “Eles não sabem que não somos profissionais? Nós nunca tivemos uma licença para fazer isso!
Se as pessoas comprarem isso, elas vão perceber...” É muito estranho ver sua coisa embrulhada.
É muito estranho, você tem aquele momento de “Espere um segundo, acho que vou fazer o que
quero fazer da minha vida”.
É interessante. Paul estava muito no dia a dia no início do projeto. Mais tarde, ele se envolveu
mais na direção da Looking Glass, que era a Blue Sky na época, iniciando novos projetos e lidando
com coisas de negócios e dinheiro e tudo isso. Mas devo dizer que ele foi uma grande ajuda no
início, apenas nos dando uma estrutura de base muito aberta. Ele era muito bom em pintar um
quadro de onde ir. Ele trouxe essa ideia de jogos como uma coisa incrível, criativa e aberta e você
pode fazer todas essas coisas incríveis, e o que queremos fazer? E não tenho certeza se
funcionaria agora com oitenta pessoas por US$ 12 milhões ou o que quer que façamos nos jogos
hoje em dia, mas para três, quatro pessoas em um pequeno escritório alugado em New Hampshire,
a maioria de nós vinte anos de idade e não sendo particularmente pago pilhas de dinheiro, foi
incrível.
Paul deu um exemplo muito bom ao encontrar a equipe certa. E muitos de nós estudamos
juntos, então tínhamos aquele “Você está na faculdade, e você é engenheiro, e vai descobrir as
coisas”. O que, mais uma vez, muitas vezes leva a muita surra e trabalho duro e tentativas e
tentativas. É como se sempre fôssemos uma equipe de pré-produção, porque no nosso maior
número éramos cinco. Eu conhecia cada linha de código, conhecia cada nível, escrevi conversas,
escrevi um monte de editor. Você poderia manter o jogo inteiro em sua cabeça e isso permitiria
iterar e improvisar de uma maneira que é muito mais difícil agora. Então eu acho que Paul
estabeleceu uma agenda muito boa de “Você é um programador/designer, você tem que se
preocupar com a criatividade, você tem que fazer isso, você tem que conhecer seu computador,
você tem que tem que ser inteligente, você tem que escrever código rápido...” E para a parte final
do jogo, quando Warren se envolveu realmente, ele não só foi muito criativo para nos ajudar a dar
os retoques finais e limpá-lo e torná-lo real, mas ele também sabia como terminar projetos e nos
manter motivados e no caminho certo. Ele tinha essa capacidade de dizer: “Caras, caras, vocês
estão totalmente focados no lugar errado”. Trabalhando em Underworld II e System Shock com
ele, quando eu estava liderando projetos em tempo integral, foi bom ter Warren lá para dizer: “Ei
Machine Translated by Google

504 Capítulo 26: Entrevista: Doug Church

Warren, eis o que estou pensando, estou tentando fazer isso, isso e isso...” em nosso telefonema
semanal, ou uma vez por mês quando ele vinha para Boston. Sua capacidade de dizer: “Sim, Doug, eu
ouço todas essas coisas que você está dizendo, mas cinquenta por cento delas você nem deveria se
importar agora. E vinte e cinco por cento vai ficar bem, não importa como você vá; basta escolher algo.
Os outros vinte e cinco por cento são bastante assustadores; vamos precisar descobrir isso. E você
sabe que há esses outros vinte e cinco por cento dos quais você nem está falando e eu não sei por
quê. Para mim, essas são as coisas assustadoras.” Ele tinha essa capacidade de me ajudar e o resto
dos caras a redefinir, do ponto de vista geral de alguém que já fez isso antes e era realmente criativo,
mas que também entendia como fazer jogos. Foi uma grande, grande vitória.

Então tivemos muita sorte, entre Paul e Warren como nossos dois veterinários experientes. O
outro programador que não era da turma da escola era um ex-homem da Infocom que tinha feito uma
tonelada de programação de ferramentas, e ele apenas disse: “Ei pessoal, venham trabalhar e façam o
trabalho, e terminem”. Assim, tivemos um equilíbrio decente desde o início para aprender, de modo que
não apenas ficarmos obcecados e sermos universitários se debatendo para sempre e tentando ser
super criativos. Mas também tivemos o suficiente para nos empurrar para não apenas tentar escrever o
código o mais rápido possível e chamá-lo de pronto. Então, tivemos muita sorte com as pessoas que
tínhamos ao nosso redor para aprender, admirar e obter ideias.

Houve alguma preocupação da Origin de que a jogabilidade do Underworld fosse muito diferente
dos Ultimas anteriores?
Eu diria que, no primeiro ano,
eles realmente não achavam
que isso seria feito. Eles não
prestaram nenhuma atenção,
francamente. Tínhamos dois
produtores, um dos quais se
demitiu sem que ninguém nos
dissesse. Ligamos para a
central telefônica depois de
dois meses e perguntamos: “Ei,
faz tempo que não temos
notícias do nosso produtor”.
“Ah, ele não trabalha mais
aqui.” "Impressionante. Tenho Ultima Underworld II: Labirinto dos Mundos
certeza de que é uma boa
notícia para o nosso projeto.” E então o próximo produtor também não entendeu. Acho que tivemos
muita sorte de encontrar Warren que estava tipo “Meu Deus, simulação de jogo imersivo em 3D em
primeira pessoa dentro de casa! Isso é totalmente novo e incrível!” Warren realmente acreditava nisso.
Acho que tínhamos a vantagem de que nosso painel de inventário se parecia muito com um inventário
do Ultima , e em alguns níveis as coisas eram mais simples. Havia menos produtos e você colecionava
espadas e seus pontos aumentavam e você tinha algumas habilidades e, você sabe, rock and roll! Isso
é um pouco superficial, obviamente; era algo em que trabalhamos vinte horas por dia durante dois
anos. Paul tinha feito alguns jogos com eles, eles estavam ocupados fazendo seus jogos, e eles
acharam a demo legal, e “Oh, você pode se mover e é texturizado!” A primeira demo que viram não
tinha
Machine Translated by Google

Capítulo 26: Entrevista: Doug Church 505

iluminação ou qualquer coisa; era apenas uma textura de parede muito simples, algo que fizemos
em três semanas e meia ou algo assim, então não era exatamente o software mais avançado já
escrito. Eu acho que eles basicamente pensaram que nunca iria funcionar, nunca seria rápido o
suficiente ou nunca daria certo. E então, quando Warren pegou e ficou empolgado com isso, já
tínhamos a experiência de brincar lá.
Você pode se movimentar, pode lutar, pode balançar sua arma, e suas estatísticas se movem e
esse tipo de coisa. Nós lançamos algumas histórias e eles acreditaram nisso. E então eles disseram:
“OK, Warren, por que você não cuida disso?”
Tínhamos uma grande vantagem em que, embora estivéssemos tentando fazer um jogo híbrido
e tentando descobrir o que era um simulador de masmorra, tínhamos todo o Ultima-ness dele para
recorrer. Claro, estávamos inventando como se mover e como balançar sua espada e todas essas
coisas, mas no final do dia era um Ultima. Você fala, pega, solta, combina reagentes, usa runas.
Criamos esse sistema de feitiços com as peças porque funcionava melhor, mas mesmo lá usamos
as runas do Ultima . Eu era um grande fã do Ultima . A primeira vez que conheci Richard, que foi
um ano no projeto, foi incrível. Era como, uau, é Richard Garriott, rock and roll! Fiquei muito
empolgado quando recebi minha cópia beta do Ultima VII porque estávamos trabalhando em um
Ultima ao mesmo tempo.
Nós realmente achamos que Ultimas era legal em algum nível, e foi legal estar trabalhando nele.
Acho que eles poderiam dizer isso: “OK, esses caras estão tentando fazer a coisa certa”. E a
segunda história que trouxemos foi muito Ultima, e eles ficaram tipo “OK, esses caras querem fazer
um Ultima”. Uma vez que Warren se envolveu, eles obviamente sentiram que Warren poderia ajudar
a garantir que as coisas continuassem nos trilhos, e foi bem casual. Há uma razão pela qual é
chamado de “UW”, porque não era Ultima no início, era apenas Underworld. Fizemos muito trabalho
por conta própria, assumindo que era isso que ia ser, mas sabendo que tínhamos que provar nossa
mecânica. E então ei, lá estava...

Parece que o Ultima Underworld foi muito projetado em torno da tecnologia, e não o
contrário. Como funcionava o processo de design do jogo?
Todos nós jogamos Wizardry I. Não é como se não tivéssemos nada em mente. Eu joguei toneladas
de Bard's Tale 1 quando estava no ensino médio, e jogamos os primeiros jogos de masmorras. E
obviamente estávamos incrivelmente conscientes da tecnologia. Quando você está sentado lá
cronometrando todos os seus loops do assembler e tentando descobrir as coisas, aí está você,
certo? E não é como se fosse rápido o suficiente, mesmo com todas as nossas tentativas de torná-lo rápido.
A criação de jogos é muito diferente quando seus programadores são seus designers e você tem
um artista. É apenas uma coisa muito diferente. Você está consciente de tudo. Você executa o jogo
e aperta a tecla de atalho para alternar para o modo de editor e, em seguida, anexa a armadilha e,
ah, a armadilha realmente não tem o parâmetro que você deseja. Então você sai, muda o código,
muda o parâmetro, volta, muda a armadilha, volta para o jogo, ei, funcionou e assim por diante.
Porque com quem você vai falar sobre isso? Obviamente, nós três que fizemos a maior parte da
programação no segundo tempo conversávamos o tempo todo, mas mesmo assim, todos
construímos níveis, todos escrevemos conversas, todos trabalhamos no editor, todos trabalhamos
no jogo. É uma coisa muito diferente. Naquela época, uma pessoa poderia facilmente ter todo o
jogo em sua cabeça. Todas as disciplinas, todos os elementos, todos os conteúdos. Talvez não
facilmente, isso provavelmente é um pouco superficial, mas eles podem fazer isso. E então, cinco
anos depois, você provavelmente não poderia ter todo o jogo em sua cabeça, mas provavelmente
poderia ter uma disciplina inteira em sua cabeça, ou a história, ou como ela está estruturada. E hoje em dia,
Machine Translated by Google

506 Capítulo 26: Entrevista: Doug Church

líder, seu trabalho é fazer com que os oito ou dez gerentes vejam vagamente a mesma coisa.
Porque o que você precisa fazer é fazer com que essas oitenta pessoas ajam como se estivessem
vendo a mesma coisa. Isso é difícil, porque o fato de os humanos se comunicarem é meio mágico,
até onde eu sei. E quando você está falando sobre colaboração criativa, a colaboração criativa é
muito, muito difícil. Eu realmente acho que como líder de projeto hoje em dia seu trabalho é a
mente vulcana fundir sua equipe.

Como surgiu o System Shock ? Você teve um plano mais formalizado do que com Ultima
Underworld?

Provavelmente um pouco.
Under world II inicialmente
seria lançado em fevereiro,
mas depois todos tentamos
retirá-lo para o Natal. Então,
inevitavelmente, assinamos
no dia 30 de dezembro com
todos trabalhando ao longo
do tempo durante o Natal,
daquela maneira clássica e
genial de desenvolvimento de
jogos. Então nós enviamos
isso em janeiro, e eu fui para
Choque do Sistema
Origin no Texas por algumas
semanas para isso, enquanto
os caras ainda estavam em Boston. E, finalmente, os dois últimos caras em Boston e eu
pegávamos o telefone e nos certificamos de ter todo o novo código e o modem para frente e para
trás e todo aquele tipo de excitação que tínhamos naquela época, lendo as somas de verificação
hexadecimais de todos os arquivos no telefone para ter certeza de que estávamos construindo a
mesma coisa. Não há nada como, três da manhã, lendo duzentos conjuntos de números
hexadecimais. Incrível, totalmente incrível. Underworld estava com zero bugs por uma semana e
meia, Underworld II na verdade estava com quase zero bugs por um tempo, mas na verdade
havia um bug nele que não conseguimos pegar, então ficamos todos envergonhados por isso.
Naquela época, nas últimas semanas quase não havia bugs, você estava tentando ficar com zero
bugs por várias semanas seguidas sem novos bugs encontrados. Então você tinha uma quantidade
razoável de tempo, e você tentaria jogar seu jogo para quebrá-lo, mas realmente, com seu próprio
jogo, há apenas tantas horas que você pode passar um dia jogando antes de se esgotar
completamente. Então começamos a falar sobre fazer um jogo de simulação imersivo, mas tirando-
o do espaço da fantasia. Nós conversamos um pouco sobre ser moderno versus ir para a ficção
científica, mas o único problema em ser moderno é que vai gerar tantas perguntas: por que não
posso pegar o telefone, por que não posso entrar no trem, e assim por diante. Então conversamos
bastante e provavelmente fizemos três ou quatro designs de alto nível para jogos de ficção científica.

Você quer dizer você e Warren?


Principalmente Warren e eu, mas Paul Neurath em Boston junto com Austin Grossman, que foi
um dos escritores/designers de Underworld II. Então todos nós trocamos algumas ideias
Machine Translated by Google

Capítulo 26: Entrevista: Doug Church 507

ao redor, e acho que Paul veio por alguns dias, e então Paul e eu voltamos para Boston, e Paul,
Austin e eu trocamos algumas ideias e criamos algumas pequenas meta-configurações. A nave
espacial abandonada ou a base lunar abandonada. E, francamente, a coisa mais importante que saiu
de tudo isso foi Austin, Warren, Paul e eu escrevemos um monte de minutos de jogo. Apenas uma
espécie de “Aqui está a sensação de um minuto jogando este jogo”. Você sabe, “Você ouve o som de
uma câmera de segurança girando, e então o bipe dela pegando você como um alvo, então você se
esconde atrás da caixa e então ouve a porta se abrir, então você joga uma granada e sai correndo do
caminho. ...” Tínhamos alguns pequenos documentos como aquele que Austin e eu pegamos e
revisamos. E de muitas maneiras isso se tornou o design do jogo. Obviamente, colocamos uma
história real em torno disso e todo esse tipo de coisa. Então isso foi muito importante para o Shock.

Nós meio que queríamos fazer algo diferente com isso. Underworld foi projetado por uma captura
de tela que Doug Wike fez com Paul antes mesmo de Paul contratar qualquer programador. Doug foi
o artista que trabalhou nos jogos mais antigos de Paul e trabalhou na Origin. Doug foi o principal
artista em Underworld. Um cara chamado Carol Angell também fez um monte de trabalho na segunda
metade do projeto, mas Doug estava lá no início, e ele fez esta captura de tela, que era um layout de
tela e uma pequena animação de vinte quadros de um orc andando no corredor para você e você
balançando sua espada. Em algum nível, sempre que tínhamos uma pergunta de design no
Underworld, pegávamos aquela captura de tela e dizíamos: “Bem, acho que há um pequeno ícone de
'lábios' ali, acho que é assim que você fala. OK, é melhor escrever algum código.” E, obviamente,
tivemos que tomar muitas decisões de design reais sobre combate e mecânica de jogo e feitiços e
tudo isso, mas você ainda pode voltar para aquela captura de tela sobre como o jogo deveria ser. E
assim, para Shock , o minuto de jogo serviu a um propósito muito semelhante.

Em Underworld , tínhamos estatísticas, inventário, conversa e movimento, e em Shock ,


realmente queríamos unificar isso. Eu senti que Underworld era uma espécie de três jogos diferentes
que você jogava em paralelo. Havia o jogo baseado em estatísticas com os pontos de experiência, o
jogo de coleta e gerenciamento de inventário, o jogo de movimentação em 3D, e havia o jogo da
conversa, o jogo do ramo de conversa. E por mais que o mundo fosse muito low-fi, ainda era muito
mais hi-fi do que qualquer um dos personagens reais. Árvores de conversação ramificadas não
representam muito bem a interação humana. Pior ainda do que mover um mouse representa caminhar.
Então, para Shock , nós realmente queríamos nos livrar disso, e é por isso que Shock tem o modo de
tela cheia com o HUD. Tudo era uma sobreposição; o mapa automático era uma sobreposição, o
inventário era uma sobreposição e assim por diante.
Uma das razões pelas quais queríamos todo o áudio para as locuções era porque o
A ideia de matar todo mundo na estação e então fazer com que todas as pessoas só pudessem ser
acessadas por meio de seus registros de dados era que você poderia continuar jogando o jogo. Você
não teria que parar para conversar ou parar para ler ou parar para escolher, você estaria apenas se
movimentando e, se quisesse, poderia ouvir um registro da pessoa que estava lá e ela estaria
descrevendo uma cena que aconteceu nesta mesma sala em que você estava. Sentimos que
Underworld fez um bom trabalho de exploração. Você explorou os espaços, e as pessoas realmente
se lembraram dos espaços, falaram sobre eles, estiveram lá. Eles diziam: “Havia aquela sala onde
havia aquela luta entre os trolls e os cavaleiros e havia todo aquele sangue e foi aí que eu fiz isso”.
Eles tinham uma memória muito visual de sua exploração e tinham uma noção muito clara de explorar
os inventários e o que você poderia fazer e pegar. Então queríamos fazer o enredo e o desenvolvimento
da história de
Machine Translated by Google

508 Capítulo 26: Entrevista: Doug Church

System Shock também é uma exploração, e é por isso que está tudo nos logs e nos dados, então
está muito ligado ao seu movimento pelos espaços e pelo mundo. A versão em disquete tinha
apenas texto e nenhuma voz e nunca deveria ter sido lançada. Lutei contra isso e perdi. A versão
de voz é muito melhor porque você nunca precisa tirar os olhos do mundo: “Aqui estou eu, me
movendo e ouvindo todas essas coisas assustadoras”.

Portanto, não interrompe sua experiência de jogo.


Exatamente. Apenas parecia
muito mais integrado. Acho
que em Shock fizemos um
bom trabalho ao integrar tudo
em uma peça um pouco
melhor. O tom de todo o jogo
era um pouco mais consistente,
um pouco mais assustador e
solitário, e os sistemas eram
muito mais simples. Não havia
mais estatísticas. Em Under
world, havia todos esses
dados rolando fora da tela
basicamente, e eu sempre
achei isso meio bobo. Os
dados foram inventados como Choque do Sistema
uma forma de simular balançar
sua espada para ver se você acerta ou erra. Assim, cada um constrói jogos de computador onde
você se move em 3D e balança sua espada e acerta ou erra, e então, se acertar, rola alguns dados
para simular o balanço de uma espada para decidir se acerta ou erra. Como alguém pode entender
a menos que você imprima os números?
É por isso que acho que a maioria dos jogos que realmente tentam ser RPGs hard-core realmente
imprimem “Você tirou um 17!” Em Warhammer , quando você consegue um aumento de 5% e na
próxima vez que você rola seu ataque, você o faz em 3%, você está todo animado porque você
sabe que esse aumento de 5% é o motivo pelo qual você acerta. Em um jogo de computador você
não tem absolutamente nenhuma ideia. E então nós realmente queríamos nos livrar de todas
aquelas coisas super-opacas, “Eu não tenho ideia do que está acontecendo”. Queríamos fazê-lo
para que você possa assistir e jogar e tudo está acontecendo. Então essa foi realmente a força
motriz de Shock. E, como eu disse, aqueles minutos de gameplay descrevendo essa experiência
tensa, com o computador te procurando com sistemas de segurança e ciborgues. Tudo deu
terrivelmente errado e você está tentando descobrir. Esses dois ou três pequenos documentos foram as coisas a
Machine Translated by Google

Capítulo 26: Entrevista: Doug Church 509

É interessante que você tenha usado a técnica do minuto do jogo, já que ela estabelece
apenas uma maneira pela qual os eventos podem ocorrer em um determinado local. Com
um jogo que tenta ser tão não linear e orientado para a escolha do jogador quanto System
Shock, como você garante que os minutos do jogo não levem a uma experiência muito linear?
Eu acho que você tem duas coisas que você pode fazer. Uma é, você faz alguns deles, para
ilustrar algumas possibilidades diferentes, não necessariamente para a mesma sala. Na verdade,
no projeto em que estou trabalhando agora, uma das coisas que estamos fazendo é pegar um
cenário específico e estamos fazendo dois ou três walk-throughs dele, especificamente por esse
motivo. Mas, mesmo naquela época, acho que a principal coisa que faríamos é escrevê-lo para
que seu personagem verificasse as outras opções de alguma forma. Seu minuto de jogo diz: “Ela
pensou em correr para a porta, mas percebeu que seria uma luta difícil. Em vez disso...” E você
insinua os sistemas e insinua os tipos de coisas que importam. E então você conta com a criação
de uma cultura de desenvolvimento que é toda sobre “O que mais eu poderia fazer?” não “Vamos
implementar isso”. Mas acho que é um bom ponto. Nós somos um meio não-linear - pelo menos
eu acho que os melhores exemplos de nós são geralmente não-lineares - e ainda que eu tenha
certeza de que o hipertexto é a coisa mais maravilhosa que existe, realmente não é a solução. Um
meio linear também não é a solução, então o que você faz para expressar a jogabilidade em um
mundo baseado em sistemas? A razão pela qual é interessante é porque é uma simulação e é
aberta, mas é difícil escrever essa simulação em um arquivo doc. Então, muito disso está
expressando possibilidades e o que o jogador decidiu fazer e deixando muito claro que eles tinham
escolhas. E muito disso está fazendo diferentes exemplos para expressar diferentes tipos de coisas.
Mas sim, é fácil fazer errado, como tantas coisas.

Parece que você projetou o System Shock em torno de como você poderia contar uma
história melhor do que em Ultima Underworld. Melhorar sua narrativa foi um dos seus
principais objetivos?
Acho que obviamente sempre
nos importamos com a história
– estávamos definitivamente
interessados em possibilidades
de fantasia/sci-fi. Em algum
nível, acho que tropeçamos
em um bom vilão, no fato de
que o vilão poderia falar com
você de qualquer lugar e
preparar essas emboscadas
e realmente afetar seu jogo.
Uma coisa que funcionou
muito bem que não
entendemos no início, mas
que aprendemos a tirar Choque do Sistema
vantagem no final foi que ter
o computador e a estação
como inimigos significava que em algum nível você poderia interagir com seu nemesis com
bastante regularidade e com bastante frequência de maneiras não finais. Você tinha um inimigo
recorrente, consistente e palpável, que importava para você porque
Machine Translated by Google

510 Capítulo 26: Entrevista: Doug Church

ela pode trancar portas ou sabotar você. E isso ajudou muito a história. A narração foi boa, especialmente
quando você realmente tinha áudio em vez de texto, para os logs, porque você poderia colocar Foley e todas
essas coisas, e acho que isso é uma grande parte do que faz o jogo funcionar. Eu não acho que a versão em
disquete funcione tão bem, porque ao invés de apenas ler o texto você está ouvindo as explosões ao fundo e
o desespero na voz de alguém. Há muito texto nesse jogo - não é curto na história. Mas mesmo assim, não é
como se todos os cômodos em que você entra estivessem nessa conversa interminável pela qual você tem
que andar de um lado para o outro. Fomos forçados a contar essa história e reduzi-la em pedaços pequenos.
E há alguns que são muito longos; não pegamos todos eles. Mas os pedaços pequenos significavam que
tínhamos que torná-los um pouco mais digeríveis. E não é por isso que fizemos logs, não fizemos logs para
dizer “Ei, vamos ter todos esses pequenos pedaços de história para que você não fique sobrecarregado, mas
sinta que está realmente juntando o mistério e tudo se une e podemos ter um ótimo Foley para fazer parecer
mais emocional e blá blá blá.” Mas no final do dia foi isso que aconteceu. E isso foi uma grande ajuda. Eu não
acho que a história em si seja tão incrível ou espetacularmente ultrajante. Quer dizer, tudo bem, mas não acho
que se você escrevesse o romance, ele sairia voando das prateleiras.

É a forma como foi contado.

Eu acho que os pedaços pequenos mais o Foley e o ambiente mais o inimigo penetrante contínuo. Mesmo
quando você não estava interagindo com Shodan, você via uma câmera de segurança que tinha que tirar.
Todas essas pequenas ações se tornam parte da história em algum sentido. E o fato de você estar explorando
a história ao invés de ter a força da história alimentada, eu acho que foi uma grande ajuda também. O fato de
não ser “Você tem que falar comigo agora”.
Em vez disso, você pega este registro, mas talvez não o leia imediatamente ou talvez queira pensar em algo
para poder voltar e trazer o registro novamente e explorá-lo.
É tudo fumaça e espelhos, mas acho que faz o jogador se sentir mais central. E acho que isso faz com que as
pessoas se apropriem mais dele e sintam que é mais deles.

Parece que o System Shock se esforçou para misturar diferentes gêneros de jogos ainda mais do que
Ultima Underworld. Isso foi intencional?

Com toda a honestidade, acho que nenhum de nós realmente pensou muito sobre essas coisas, o que sempre
nos colocou em apuros. Mas acho que em algum nível, foi “Ei, vamos fazer este jogo”. Obviamente, para nós,
dissemos: “Ei, Underworld foi divertido, mas toda essa conversa foi meio chata e essas estatísticas pareciam
estar distraindo você e todo esse número e detalhes. Não podemos simplificar um pouco isso? Não podemos
torná-lo um pouco mais de ação e um pouco mais imediato?” E basicamente foi isso. Eu não acho que
estávamos pensando especificamente, “Ei, vamos fazer um RPG de ação” ou qualquer outra coisa. Acho que
foi mais uma evolução de Underworld do que qualquer outra coisa.

Desde o primeiro Underworld, Wolfenstein 3D foi lançado e se tornou um grande sucesso com uma
experiência muito mais simples e orientada para a ação. Vocês tentaram deliberadamente evitar a
jogabilidade de tiro visceral que eles tinham?

Não, acho que estávamos apenas fazendo nossas próprias coisas, francamente. Nós conhecíamos os caras
da id e obviamente o material deles era incrível - todos nós éramos fãs no sentido de que pensávamos que era
Machine Translated by Google

Capítulo 26: Entrevista: Doug Church 511

legal. Mas no momento em que Wolf saiu, estávamos praticamente prontos com Underworld , então
não era como se estivéssemos olhando para eles para obter ideias, por si só. Eles estavam meio que
fazendo as coisas deles e nós estávamos meio que fazendo as nossas coisas. Não sei se eles
respeitavam nossas coisas ou gostavam; nós certamente respeitamos e gostamos de suas coisas.
Mas nós não estávamos tipo, “mais disso!” Nós certamente conversamos sobre como era melhor,
mais rápido e mais limpo do que Under world, muito mais do que falamos sobre qualquer outro jogo
que foi lançado. Essa foi provavelmente uma das nossas fraquezas na época, que éramos bastante
introvertidos e praticamente fazendo nossas próprias coisas em quase tudo o que estávamos fazendo.
Estávamos fazendo Terra Nova, que obviamente era um jogo híbrido estranho. E estávamos fazendo
Flight Unlimited, que em certo sentido era um jogo híbrido estranho; simulador de vôo comercial sem
tiro, mas não grande. Estávamos meio que fazendo nossas próprias coisas.

Então você tentou evitar se comparar com o que mais estava acontecendo nos jogos?

Não é que não jogamos e gostamos de outros jogos. Nós fizemos. E certamente pensamos sobre o
que fazíamos e não gostávamos neles, e certamente conversamos muito sobre jogos. Mas não me
lembro de estar em reuniões e as pessoas dizerem: “Faça mais parecido com essa outra coisa”.
Estávamos meio que fazendo o jogo que achamos que deveríamos fazer. E, para o bem ou para o
mal, isso era basicamente uma referência aos jogos que já tínhamos feito. E obviamente estávamos
vendo todas as coisas de Origin que estavam em desenvolvimento, e fomos influenciados por aquela
estética de RPG/história que Chris [Roberts], Richard e Warren estavam construindo lá embaixo.

System Shock, como Ultima Underworld antes dele, era uma experiência de jogo bastante não
linear. Esse foi um dos seus principais objetivos de design?
Acho que tanto no Under
world quanto no Shock, não
queríamos construir jogos em
que você limpasse todos os
quadrados neste nível e depois
passasse para o próximo nível.
Underworld tinha muitas coisas
que o cortariam e você tinha
que voltar mais tarde, ou pelo
menos você deveria voltar
mais tarde. Por exemplo, agora
que você atingiu o nível sete,
você terá que voltar para áreas
que antes não conseguia.
Ambos os jogos tiveram seus
quatro ou cinco principais
Choque do Sistema
checkpoints, mas sempre
acreditamos que a escolha do jogador era bastante central para o que o tornava divertido para as
pessoas. E essa coisa centrada no jogador era o que você lembra. Você se lembra da coisinha
inteligente que você fez mais do que se lembra de alguns
Machine Translated by Google

512 Capítulo 26: Entrevista: Doug Church

cinemática. Para nós, dar aos jogadores a capacidade, mesmo que eles não pensem nisso como tal,
de seguir seu próprio caminho é onde eles estarão mais propensos a fazer algo de que se lembrem e
se importem. Em Shock nós certamente tentamos construir alguns sistemas como upgrades ou
câmeras de segurança onde você tinha bastante liberdade em que ordem você fazia e como você
fazia, onde não era apenas “Vá fazer essa sequência de quatro coisas. ” Era “Bem, haverá doze
câmeras aqui e você tem que tirar oito delas. Entender." Nós demos a você a opção de “Bem, isso
parece uma bagunça” ou “Eu não quero lutar com esse cara. OK, talvez eu possa encontrar outra
maneira...”
Acho que essa era a nossa filosofia de design. Nós éramos muito baseados no estado, ao invés
de baseados em eventos. Não fizemos um trabalho muito bom naqueles primeiros jogos, mas
tentamos fazer o máximo de coisas baseadas no estado que pudemos. Essas câmeras são um bom
exemplo. Não era uma questão de dizer: “Se você destruiu essas oito câmeras nesta ordem, faça
isso”. Foi muito mais um caso de “Quando estamos neste estado, acontece o seguinte”. E dessa forma
você dá ao jogador a capacidade de entrar nesse estado da maneira que quiser. Obviamente, naquela
época, com nossa física incrivelmente corretiva e assim por diante, havia uma quantidade limitada
disso que podíamos fazer e, obviamente, à medida que obtemos mundos onde você pode fazer mais
coisas e mais interações que se tornam mais poderosas. Mas mesmo naquela época estávamos
pensando nisso dessa maneira, tanto quanto podíamos, pelo menos.

System Shock parecia ser um dos primeiros jogos desse tipo a usar física, mesmo em uma
forma bastante primitiva.
Acho que vimos isso em Underworld, onde tínhamos essa física incrivelmente corretiva, mas as
pessoas ainda se divertiam jogando coisas e quicando a superbola e tentando acertar alvos com
coisas. E dissemos: “Ei, vamos fazer mais disso porque os mundos têm física”. Em algum nível, ainda
é apenas um simulador de masmorra, e ainda estamos tentando evoluir essa ideia. Eu realmente acho
que System Shock é apenas a evolução um tanto óbvia de Underworld. Reescrevemos tudo para 32
bits com Watcom, em oposição ao material antigo de 16 bits, e isso nos deu mais poder e mais
possibilidades. Mas filosoficamente foi um refinamento e uma focalização da coisa anterior.

Sempre me pareceu um passo bastante significativo.


Acho que certamente estávamos tentando refinar e focar. Isso foi o que achamos que tínhamos feito
bem, que era principalmente essa ideia de exploração, e o quanto os jogadores gostavam de fazer
suas próprias coisas e se lembravam de espaços, lugares e histórias que contamos.
Algumas das melhores coisas que eu acho em Underworld foram onde não havia diálogo. A história
foi toda contada através do que estava na tela. Muitas pessoas na época se lembravam da batalha
troll/cavaleiro. Havia uma sala onde montamos um monte de detritos e decalques e objetos para fazer
parecer que houve uma grande luta: crânios, espadas quebradas e outras coisas foram deixadas por
todo o lugar. E você poderia conversar com testadores ou pessoas em feiras que jogaram o jogo ou
qualquer outra coisa, e eles diriam: “Cara, houve aquela grande luta!”
E eles contavam sobre a luta entre os trolls e os cavaleiros, embora nunca tivéssemos dito nada sobre
isso, porque eles tinham visto. Então, realmente pensamos que a exploração e o contexto visual eram
muito importantes para as pessoas. Então em Shock nós realmente tentamos focar nisso, fazer o que
pudéssemos para encontrar outras maneiras de deixar as pessoas explorarem, e não fazer tanto onde
nós tentamos dizer a elas ou forçá-las. eu pensei nisso
Machine Translated by Google

Capítulo 26: Entrevista: Doug Church 513

funcionou muito bem. Obviamente, há coisas que mudariam em retrospecto, como qualquer
coisa que se faça, mas acho que fizemos um trabalho decente de foco. Ainda há muito mais
foco para fazer.

Sempre achei a ideia de ter o modo ciberespaço separado no System Shock muito
interessante. Quais foram as motivações por trás de adicionar isso?
Achamos que se encaixava
do ponto de vista conceitual:
você é um hacker, não
deveria hackear alguma
coisa? Achamos que seria
divertido lançar um modo de
movimento diferente que
fosse mais livre, mais ação.
Em retrospecto, provavelmente
deveríamos ter cortado ou
passado mais tempo nisso.
Há algumas coisas divertidas
nele, mas não é tão polido
quanto deveria ser. Mas
mesmo assim foi legal porque
pelo menos reforçou a ideia
Choque do Sistema
de que você era o hacker, de
um jeito totalmente aleatório, arcade-y, quebrado. Mas pelo menos sugeriu que você é outra
coisa que não um cara com uma arma. Como eu disse, estávamos bem focados na introdução.
Estávamos olhando para nós mesmos e dissemos: “Ah, claro que deveríamos ter o ciberespaço.
Somos um jogo cyberpunk, temos que ter ciberespaço. Bem, o que podemos fazer sem muito
tempo? E se fizermos essa loucura?” Lá fomos nós...

Embora os jogos Looking Glass tenham se saído muito bem comercialmente, eles nunca
foram grandes sucessos como os jogos id lançados na mesma época, apesar de usar
uma tecnologia igualmente impressionante. A empresa alguma vez ficou aflita com isso?

Não sei se angustiado... Em geral, acho que estávamos fazendo coisas tecnicamente mais
agressivas. Certamente não quero dizer em nenhum sentido que éramos tecnicamente melhores
porque é difícil imaginar como alguém escreveria um motor que fosse mais eficiente ou poderoso
do que um dos motores de Carmack. E John é um cara incrivelmente brilhante e talentoso. Mas
se você olhar para Wolfenstein, eram paredes, sem iluminação, sem pisos e tetos, sem olhar
para cima e para baixo, tudo plano, ponto final, enquanto Underworld tinha declives, iluminação,
texturas de piso e teto, saltos e pouca física coisas, e assim por diante. Agora, isso o torna um
jogo melhor? Claro que não. Não tem nada a ver se o jogo é bom ou não. Acho que estávamos
tentando fazer um pouco mais do que as máquinas provavelmente estavam prontas para fazer
ou mesmo para o que estávamos prontos. Acho que éramos bons programadores, mas quem
sabe, talvez outra pessoa pudesse ter feito isso muito mais rápido do que nós. O fato de que,
em geral, a maioria das pessoas chegou a isso alguns anos depois
Machine Translated by Google

514 Capítulo 26: Entrevista: Doug Church

quando as máquinas realmente podiam fazer isso, provavelmente eram elas sendo um pouco mais
espertas sobre o mercado, e nós sendo um pouco mais fracos. Mas, A, estávamos tentando fazer
um pouco mais do que podíamos lidar e alcançar um público maior, e B, estávamos nesses jogos
que eram um pouco mais complicados e exigiam um pouco mais de investimento. Isso é apenas
uma coisa diferente. Mesmo se estivéssemos usando tecnologia literalmente idêntica, acho que é
mais fácil expressar o que estava acontecendo em Wolfenstein ou Doom. É mais fácil dizer: “Ei,
aqui está o que você está fazendo: você tem essa arma e precisa se manter vivo com todas essas
coisas malucas vindo atrás de você. Vá em frente. É realmente assustador, é muito rápido, parece ótimo.”
Impressionante. Eles fizeram um ótimo trabalho. Éramos um produto mais específico, apenas éramos.

Então vender mais cópias não era uma grande preocupação?


Houve alguma discussão
sobre isso: “Nossa, com
certeza seria bom se
estivéssemos ganhando
mais dinheiro e vendendo
mais cópias para que
pudéssemos fazer jogos
loucos do tipo que
queremos, em vez de ter
que nos preocupar com
vai vender mais.”
Ei, eu adoraria se o público
estivesse mais interessado
no que eu gosto de fazer
Ultima Underworld II: Labirinto dos Mundos
e um pouco menos em
coisas um pouco mais
diretas. Mas eu entendo totalmente que eles gostam de coisas simples. Não tenho nenhum direito
divino de alguém me dar milhões de dólares para fazer um jogo do que eu quiser fazer. Se o
mercado quisesse mais Submundos, eles os teriam comprado. Em algum nível fundamental, todos
têm uma carteira e votam com ela.

Já se falou em tornar seus jogos mais parecidos com os jogos de id para fazê-los vender
melhor?

id estava fazendo um ótimo trabalho nesse jogo. E mais poder para eles. Eu acho que você quer
fazer coisas que se conectem com o mercado e você quer fazer coisas que as pessoas gostem e
você quer fazer coisas que sejam vistas. Mas você também quer fazer coisas em que realmente
acredita e que deseja fazer pessoalmente. Ei, se você vai trabalhar vinte horas por dia e não
receber muito dinheiro, é melhor fazer algo que goste. E, eu amo Mario 64, e Deus sabe que
provavelmente não sou talentoso o suficiente para construí-lo. Mas mesmo que eu fosse, não faria
isso porque amo o jogo e adoro jogá-lo, mas não tenho interesse em construí-lo. E estávamos
construindo os jogos que nos interessavam; tivemos esse luxo.
Não tivemos um sucesso espetacular e uma grande vitória, mas tivemos sucesso suficiente para
fazer mais. E em algum nível, pelo menos para mim, com certeza eu adoraria ter um enorme,
enorme sucesso e ser capaz de levar cinco anos e fazer dez jogos indie e fazer o que diabos eu
Machine Translated by Google

Capítulo 26: Entrevista: Doug Church 515

quer. Mas se eu fizer outro jogo que acho interessante, é muito difícil reclamar. As pessoas
certamente discutiram isso, não é como se não tivéssemos conhecimento disso. E cada
muitas vezes alguém entrava e dizia: “Por que não fazemos Doom com isso?” Mas
como uma equipe, acho que estávamos bem nas coisas que estávamos fazendo.

O projeto Flight Unlimited parecia ser um grande desvio do que


Looking Glass vinha fazendo até aquele momento.
Quando Shock terminou, Flight e Terra Nova estavam em desenvolvimento. A maior parte do choque
equipe acabou no Flight por um tempo para ajudá-lo a enviar e então eles se mudaram para a Terra
Nova e o que mais estava acontecendo na época. Looking Glass estava passando por isso
período de tentar fazer um monte de coisas ao mesmo tempo e meio que se excedendo e sendo um
pouco ambicioso demais e um pouco arrogante. A empresa estava tentando se estabelecer como um
editora em uma época em que isso era muito, muito difícil de fazer. Todas as outras editoras de
médio porte estavam quase falindo ou sendo compradas, enquanto tentávamos
ramificar em novos gêneros e fazer mais coisas e iniciar um selo afiliado e auto-publicar
Vôo e todas essas outras loucuras. Ninguém na cadeia de gestão da empresa
realmente prestei atenção ao System Shock porque Flight seria o primeiro
produto auto-publicado e justo o suficiente. Do ponto de vista da empresa, a Flight foi a
produto que tinha que ser o hit, porque era o título auto-publicado. Ned e Paul tinham
fundiu-se para se tornar a Blue Sky Research, que se tornou a Looking Glass, e Ned obviamente
gostava de simuladores de vôo, tendo trabalhado em Chuck Yeager. E Seamus
[Blackley] obviamente gostava de toda a coisa do simulador de vôo. O foco da empresa
foi a tentativa de autopublicar e sair da esteira da espera por avanços e
ter a chance de obter alguma solidez por trás das coisas para que se possa tomar decisões voltadas
para o futuro, em vez de se concentrar apenas no curto prazo. Obviamente não funcionou, mas é fácil
criticar em retrospecto, dessa maneira retrospectiva. Acho que houve muita clareza
em alguns dos erros, mas alguns dos erros foram bastante honestos e bastante
razoável. Você olha para eles e diz: “Bem, sim, posso ver por que eles fizeram isso”.

Como surgiu o projeto Thief ?

Tivemos um monte de
idéias de alto conceito sobre
design de jogos que, em
prática, muito poucos de fato
aconteceram na final
jogos. Tivemos muito
pensamentos sobre ter
facções diferentes. Como eu
discutido, sentimos que
caráter e conversação eram
algo que
foi difícil, para dizer o mínimo.
Então nós tínhamos concebido
facções de pessoas no Ladrão
Machine Translated by Google

516 Capítulo 26: Entrevista: Doug Church

world sendo um contraste melhor para o jogador porque você pode interagir com um grupo de uma
maneira um pouco mais icônica e abstrata do que com um indivíduo. Porque alguém pode vir e dizer:
“Eu falo por essas pessoas e achamos que você é um cara mau” ou qualquer outra coisa. E eles
podem fazer isso de uma maneira um pouco menos pessoal e direta e, portanto, exigem um pouco
menos da IA e do mecanismo de conversação. Era essa ideia de ter facções com as quais você
poderia se aliar ou se opor ou fazer coisas para ou não.
A outra grande ideia era que essas mesmas facções o ajudariam fora da tela, porque não
queríamos ter companheiros de equipe reais. Nós não queríamos escrever IA que você teria que
prestar atenção e se preocupar se eles pularam o abismo quando você saltou o abismo e todo esse
tipo de bagunça que você tem quando você coloca um segundo personagem em um ambiente
realmente interativo. para um avião grande e gordo onde você apenas luta. Então, as ideias iniciais
foram nesse sentido, onde montamos alguns mundos de jogo onde havia muitas facções diferentes e
você interage principalmente com elas e elas têm muitas oportunidades de ajudar. Você veria a
evidência de sua ajuda, como uma flecha vindo de fora da tela ou algo assim, mas não teríamos que
realmente fazer todo o trabalho de IA necessário para fazer aliados reais. Então, tivemos alguns
designs nesse sentido. Além disso, a maioria dos designs que estávamos tentando fazer era um pouco
mais interessante, um pouco menos padrão.

Você quer dizer em termos de ficção do jogo?


Em termos de ficção e estrutura. Tínhamos uma proposta de zumbis pós-Guerra Fria chamada Better
Red than Undead na qual você estava lutando contra zumbis em uma era comunista da Guerra Fria e
correndo por aí e tendo diferentes grupos – espiões comunistas e governo comunista e governo
ocidental e todos esses diferentes grupos de espionagem. Enquanto isso, os zumbis estavam tentando
dominar todo mundo, então você tinha que escolher com quais grupos iria se aliar e ir contra, enquanto
todos tinham esse inimigo comum dos zumbis. Mas é claro que ninguém se dá bem, então você tinha
que jogar esse jogo delicado de colocar todos do seu lado ou pessoas suficientes do seu lado para
fazer o trabalho.
E então tivemos essa ficção arthuriana reversa onde você era Mordred e seu conselheiro era
Morgan le Fey, que era uma boa pessoa. Lancelot era esse idiota malvado e Merlin era um cara de
marketing que viajava no tempo do futuro. Todos os Cavaleiros da Távola Redonda usavam camisetas
com logotipos e números, e o Santo Graal era essa coisa falsa que eles achavam que não existia,
mas eles estavam usando isso como uma forma de continuar a oprimir as massas e tirar todo o seu
dinheiro e tratar eles mal. A desculpa era que eles precisavam de todo o dinheiro para encontrar o
Santo Graal e eles simplesmente ficariam sentados e dariam festas. Então você como o Cavaleiro
Negro teve que invadir Camelot. E Guinevere era essa lésbica que te ajudaria traindo Lancelot porque
ela realmente o odiava e todo esse tipo de coisa. Na verdade, nosso departamento de marketing não
estava muito interessado nisso.
Não muito surpreendente, suponho. Mas tínhamos um monte de ideias aleatórias com as quais
estávamos brincando e fizemos storyboards, configuração inicial e outras coisas.

Mas eles ainda eram simulação imersiva, jogos em primeira pessoa?


Sim Sim. Mais uma vez, em Better Red havia todos esses grupos de espiões e em Dark Camelot
havia todos esses diferentes grupos de párias com quem você poderia trabalhar para tentar entrar em
Camelot e bagunçar as coisas. Mas quando começamos a trabalhar em alguns dos Dark
Machine Translated by Google

Capítulo 26: Entrevista: Doug Church 517

Coisas de Camelot , A, nós estávamos tendo desafios infinitos tentando convencer alguém de que era
comercializável, e B, as missões em que tínhamos a melhor definição e os melhores detalhes eram
todas as invasões em Camelot, encontrar alguém, obter uma pista , roubando alguma coisa, tanto faz.
À medida que trabalhávamos mais nessa direção, e essas continuaram a ser as missões que
poderíamos explicar melhor para outras pessoas, começou a seguir esse caminho.
Com a coisa da facção, nunca conseguimos o que precisávamos para realmente ter tempo para fazer
um protótipo. A coisa sobre isso é que requer muita mecânica de jogo até começar a funcionar,
enquanto o modelo básico de furtividade era algo que você poderia ter a ideia básica de ter o guarda
olhando para o outro lado e você passando rapidamente. Então, Paul estava pressionando por um
tempo que o lado do ladrão era a parte realmente interessante e por que não você apenas faz um jogo
de ladrão. E como as coisas ficaram mais caóticas e mais coisas estavam acontecendo e estávamos
tendo mais problemas com a forma de comercializar as coisas, continuamos focando na parte do
ladrão. Passamos por várias fases diferentes de reorganização da estrutura do projeto e muitos de
nós fomos sugados para fazer algum outro trabalho de projeto em Flight e outras coisas, e havia todo
esse caos. Dissemos: “OK, bem, temos que fazer isso e realmente nos concentrar e fazer um plano”.
Então colocamos Greg [LoPiccolo] no comando do projeto e concordamos em chamá-lo de Thief e
focar muito mais. Foi quando passamos de muitas brincadeiras e explorações para “Vamos fazer esse
jogo de ladrão”.

Parece que na época não havia muitos outros jogos furtivos.


Não que soubéssemos, pelo menos. Logo antes de embarcarmos, Tenchu foi lançado no Japão, e
acho que foi lançado nos Estados Unidos logo depois. Então nós certamente olhamos para Tenchu
quando ele foi lançado, mas a essa altura nosso jogo foi feito principalmente além de ajustes, e eles
eram muito mais um jogo de arcade de ação. Eles eram muito mais sobre matar pessoas de maneira
ninja legal. Tenchu era um jogo legal, mas era um foco diferente do nosso jogo.

É interessante para mim que você tenha considerado Thief o conceito de jogo mais financiável,
mesmo que sua mecânica de jogo fosse em muitos aspectos totalmente nova e original.

Acho que era mais que acreditávamos nisso. Quero dizer, a Eidos nunca acreditou nisso e até o final
nos disse para colocar mais monstros nos níveis e ter mais luta e exploração e menos furtividade e
não tenho certeza se houve um ponto em que eles entenderam. Quero dizer, os trailers que a Eidos
fez para Thief eram todos cenas com pessoas atirando flechas de fogo em pessoas que os atacavam.
Então você pode deduzir disso o quão bem eles entenderam ou acreditaram na ideia.

Mesmo assim eles financiaram...


Certamente. Se eles não tivessem feito isso, não teríamos feito o jogo. Muito grato por isso. Não tenho
certeza se chegamos a um ponto em que eles disseram: “Ah, sim, isso vai funcionar”. Eu acho que
eles pelo menos tinham “OK, estamos vendendo esse ladrão cínico anti-herói, talvez possamos fazer
isso”, de uma forma que vender Camelot reverso ou qualquer outra coisa simplesmente não era
atraente para ninguém.
Machine Translated by Google

518 Capítulo 26: Entrevista: Doug Church

Como você convenceu as pessoas internamente de que Thief era promissor?


Temos alguns muito cedo
protótipos que foram
super, super-áspero e
apenas pequenos pedaços desse código

foram usados no transporte


jogos. Mas isso foi apenas
caras em patrulha, percebendo
você ou não, e você se
esquiva do caminho. E nós
fez um monte de missão
textos para o escuro
Coisas de Camelot , não que nós
usei-os no real
jogo, mas pensamos,
sim, isso seria meio
legal. Você se esgueiraria e faria Ladrão

isso e esse cara faria


isso, e no final você pode fazer isso acontecer. Acho que tivemos uma massa crítica de pequenos
elementos legais. Dito isto, foi só quando lançamos que tudo se juntou
em algo que funcionasse de uma maneira que os jogadores realmente quisessem jogar como
oposto à maneira intelectualmente “isso poderia funcionar”. A essa altura tínhamos o hábito de puxar
jogos que eram muitos elementos diferentes juntos para que você tivesse que ligar os pontos
em sua mente até perto do fim, que não é exatamente como a indústria gosta de trabalhar
dias.

Teria sido melhor ser mais coeso antes?

Bem, certamente teria sido ótimo ser mais coeso antes, embora eu não esteja
certeza do que teríamos que sacrificar para fazer isso. Obviamente, hoje em dia na indústria
tentamos trabalhar muito mais cedo, mas acho que isso significa que é mais difícil aceitar
muitos riscos. Mais ao ponto, é muito mais difícil fazer jogos que exigem muitos sistemas. E de certa
forma isso é bom porque jogos supercomplicados raramente funcionam. Mas
se você fizer certo, acho que você pode ter muitos sistemas que funcionam juntos de maneira muito
elegante e transparente, mas esse é o tipo de coisa que é muito difícil de mostrar agora
porque lhe dizem: "Tudo bem, bem, antes de fazermos qualquer desenvolvimento real, precisamos
de um protótipo que funcione", e isso significa que você só poderá fazer algumas coisas novas
em um momento construído sobre o que você fez por último. Acho que isso torna muito difícil fazer
algo tão simples quanto Thief, que é um jogo incrivelmente focado, mas ainda requer luz
e sombras que funcionam, e detecção de sombras que funciona, e IA que pode entender
sombras e um sistema de fala para que as IAs possam se comunicar com você sobre as sombras.
Não é ciência de foguetes, mas é um monte de coisas. Como eu disse, nós hackeamos juntos alguns
coisas no início para nos dar uma ideia de que, OK, isso provavelmente poderia funcionar, mas eu não estou
certeza de que alguma vez convenceria um editor de que ia funcionar; obviamente, geralmente não
convenceu a Eidos. Convenceu-os o suficiente para financiá-lo, e isso é ótimo, mas
Eu não tenho certeza de que isso seria verdade mais. Acho que as coisas que usávamos naquela época seriam
Machine Translated by Google

Capítulo 26: Entrevista: Doug Church 519

difícil de usar como prova agora. E talvez isso signifique que você deve ter um ano de pré-
produção com uma pequena equipe onde você escreve toneladas de coisas, mas a maioria dos
editores não está pensando assim no momento. É mais, pegue um motor, adicione alguns recursos
e então você está seguro e pode seguir em frente. E isso é certamente mais estável. Acho que
você quer muito disso, mas certamente não quer que todos os seus produtos sejam assim.

Além do lado do editor, com um jogo verdadeiramente inovador, como você convence a
equipe de desenvolvimento de que o jogo vai funcionar e como você os mantém no caminho
certo com a visão?
Sim, isso é super difícil. Parte disso é que você precisa ter uma equipe que esteja confortável com
o grau de ambiguidade. Há algumas pessoas que se sentem confortáveis nesse ambiente e outras
que não. E não é bom ou ruim em ambos os casos; é apenas como as pessoas são. Mas acho que
é uma grande parte disso, se você tem pessoas que dizem: “OK, isso parece interessante. Não
tenho certeza se entendi, mas acho que entendi muito bem, então vou começar a tentar descobrir.”
Ou se você tem pessoas que dizem: “Eu simplesmente não estou vendo isso, e vou ter dificuldade
em construí-lo ou trabalhar até que eu realmente entenda”. Então, acho que a atitude das pessoas
que você tem é uma grande parte disso, e acho que é aí que minutos de jogabilidade e storyboards
e tentar descrever a experiência são tão importantes; maneiras de comunicar o que você está
tentando construir antes de construí-lo. Para Thief , tivemos uma enorme vantagem porque no final
do dia poderíamos dizer, bem, isso está tornando o personagem mais ladrão? Hmm, parece que
isso o torna mais forte e musculoso, provavelmente não precisa disso. Hmm, isso parece torná-lo
mais legal e furtivo, vamos fazer isso. Nem todos os jogos que tentam inovar têm um foco tão fácil,
mas acho que isso foi uma parte crucial do Thief. Você sempre pode dizer “O que estou digitando
vai deixá-lo mais furtivo?”

Você usou minutos de jogo no projeto?


Sim, definitivamente fizemos
um pouco disso em Thief. Não
tanto, eu acho, porque fizemos
algumas no começo e então
ficou bem claro que, OK, nós
queremos essa ideia de
guardas tentando encontrar
você, mas não se você estiver
escondido nas sombras e não
se você estão se esgueirando
atrás das pessoas e batendo
na cabeça delas. Mais uma
vez, a ideia de Thief é muito
mais transparente do que a
ideia de System Shock. O
nome System Shock não diz Ladrão

como é a jogabilidade,
enquanto Thief sim. Agora, isso certamente deixa você com um
Machine Translated by Google

520 Capítulo 26: Entrevista: Doug Church

muitos detalhes para trabalhar e muito role-playing onde, agora se eu atirasse a flecha de
corda no teto e subisse, o que o guarda teria que fazer para reagir e esse tipo de coisa.
Havia menos necessidade de definir uma direção geral de alto conceito em Thief porque o
alto conceito era muito claro. E assim Thief era muito mais sobre mecânica e sistemas e
ajustes e quais parâmetros você precisa ajustar, e como você fará isso para que o guarda
possa detectá-lo e não parecer estúpido, mas não detectá-lo tão bem que você nunca ganhe,
e assim por diante. Enquanto nos outros jogos era mais sobre definir os objetivos de alto
conceito, não apenas os objetivos de baixo nível.

Para um jogo como Thief, como você equilibra o lado de sistemas puros do jogo com
scripts específicos?
O objetivo é certamente minimizar os scripts em algo como Thief, porque não apenas os
scripts levam uma eternidade, mas também significa que você provavelmente terá situações
em que a IA reage de maneira diferente em lugares diferentes, que é a sentença de morte
para um jogo assim porque o jogador não pode planejar ou entender e então nada pode ser
repetido e então o jogador fica louco. Então, em Thief , havia alguns lugares que tinham
scripts pesados, mas tinham mais a ver com eventos de história: “Quando isso acontecer,
você terá que fazer essas quatro IAs virem aqui porque esse evento acontece em termos de
história. ” Portanto, há alguns desses scripts, mas não muito. Passamos um tempo onde
tínhamos alguns sistemas de script bastante sofisticados, mas era bastante complicado e
realmente ninguém além dos programadores o usava. E então Tom Leonard, que era nosso
principal cara de IA, pegou os elementos-chave do material de script que você queria fazer
com as IAs e construiu essa interface pseudo-script que era essa caixa de diálogo do
Windows tipo Mad Lib, onde você poderia dizer: “Oh , nesse tipo de mensagem ou nesse
tipo de evento, faça esse tipo de coisa e vá até esse objeto ou descubra o que está do outro
lado desse link e vá até lá ou tente pegar essa coisa.” E assim que Tom fez isso, os designers
estavam fazendo muito mais improvisação e muito mais “Oh, eu quero que essa IA específica
quando esse alarme disparar vá aqui e depois diga isso”. Então eles roteirizaram muito da
reação a grandes eventos. Dito isso, o jogo minuto a minuto era quase todo baseado em
sistemas, onde os designers principais iriam e decidiriam como o cone de visão funciona e
quão sensível o cara era e qual a probabilidade de ele lutar ou correr para pedir ajuda ou
qualquer outra coisa. Os designers colocariam alguns waypoints e diriam: “Bem, você deve
ir para a cozinha, e então você deve ir para o corredor do andar de cima, e então ficar ao
redor da escada por alguns minutos e depois voltar para a cozinha” ou qualquer outra coisa. .
Mas todo o movimento real, detecção e giro e todos os detalhes da IA e quando eles
detectaram você e o que eles fizeram quando o fizeram foram basicamente sistemas de sentido e código

Você precisou impor uma regra com a equipe de design sobre quanto ou pouco script?

Acho que todos entenderam muito bem. Na maioria das vezes, o roteiro era apenas para as
coisas da história, como eu disse. Acho que todos tiveram a ideia de que seria sistêmico só
porque estava claro que grande parte do jogo dependeria de você ter uma noção visual de
como a IA se comportava para que você pudesse iludi-los. E todos sabiam que isso
significava que eles tinham que ser bastante repetíveis e baseados em sistemas. E para os
designers era muito mais sobre a construção de espaços onde você tinha boas linhas de visão
Machine Translated by Google

Capítulo 26: Entrevista: Doug Church 521

onde você pode ver o caminho da IA. Muito desse jogo se resume a como você consegue momentos de
fechamento e como você consegue escopo.

O que você quer dizer com momentos de encerramento?

Na maioria dos jogos, você está matando todo mundo, então você tem bons momentos de encerramento
quando vence cada batalha, enquanto em Thief você passa pelas pessoas. O que significa que todos esses
encontros são abertos. É como se todas as frases começassem, mas não terminassem. Então, muito tempo
foi gasto em como você consegue o encerramento desses encontros que realmente não tiveram um
encerramento. E muito disso tinha a ver com a construção de espaços onde o jogador pode realmente ver o
que está acontecendo. Se ficar muito claustrofóbico, o jogador não tem a menor ideia. Em muitos dos níveis
iniciais, as IAs estavam nesses caminhos incrivelmente interessantes e complexos que pareciam ótimos no
mapa aéreo, mas quando você estava jogando parecia que poderia ser aleatório. Porque você simplesmente
não fazia ideia do que estava acontecendo: um cara aparecia e depois ia embora e então ele aparecia em
outro lugar e você se esquecia de esconder um corpo, mas não tinha idéia se alguém iria encontrá-lo. Como
o jogador só tinha uma noção muito local do que estava acontecendo, tivemos que mudar o escopo dos
comportamentos da IA para que também fossem muito locais. Caso contrário, parecia apenas aleatoriedade.
E muito do desafio dos designers se resumia a como você constrói esses espaços que podem rodar no
motor rápido o suficiente, que certamente tinha todo um conjunto de restrições sobre tamanho e assim por
diante, mas ao mesmo tempo grande o suficiente com linha de visão suficiente ou iconografia clara o
suficiente. Você tinha que ser capaz de dizer: “Oh, este é o corredor principal e parece com aquele outro
corredor principal, então aposto que o guarda está nesta patrulha rotativa por este corredor. Ok, eu entendi.
É melhor eu esconder o corpo no corredor. Maneiras para os designers tornarem possível para o jogador
fazer planos racionais, uma vez que o jogador não poderia abrir um radar ou mudar para a visão do olho de
Deus e dizer: “Ah, entendo”.

Como manter aquela imersão em primeira pessoa de “Aqui estou, o que vai acontecer” sem torná-la tão
opaca que você pode se debater aleatoriamente e torcer para vencer.

Assim como em seus jogos anteriores, ter ambientes bastante não lineares era um dos seus principais
objetivos de design?

Sim, definitivamente. Não há


dúvida de que sempre buscamos
maximizar a escolha do jogador
o máximo possível e acho que
em Underworld , em particular,
vimos muitas pessoas fazerem
coisas que não esperávamos ou
serem inteligentes de maneiras
que não esperávamos. Ou
apenas observando onde alguns
sistemas se juntariam de
maneiras interessantes. Você
sabe, “eu sou

Ladrão
Machine Translated by Google

522 Capítulo 26: Entrevista: Doug Church

sendo perseguido por um cara e eu corro para uma porta trancada e agora eu tenho que arrombar a
fechadura, mas o cara está atrás de mim tentando atirar em mim e eu finalmente atravesso a porta
trancada quando estou prestes a morrer, mas, oh meu deus , há inimigos aqui, então eu pulo na água
e tento nadar para longe, mas...” Apenas essas pequenas sequências que não foram roteirizadas ou
planejadas de forma alguma, eram apenas jogadores no espaço improvisando. E assim em Thief,
embora obviamente