Parte 1

Machine Translated by Google
Design de jogo:
Teoria e prática
Segunda edição
Ricardo Rouse III

Ilustrações de
Steve Ogden
Prefácio por
Noah Falstein
Personagem Atomic Sam desenhado por Richard Rouse III e Steve Ogden
Dados de Catalogação na Publicação da Biblioteca do Congresso
ROSA, Ricardo.
Design de jogos: teoria e prática / por Richard Rouse III ; ilustrações de Steve Ogden.—2ª
ed. pág. cm.
Inclui referências bibliográficas e índice.

ISBN 1-55622-912-7 (pbk.)
1. Jogos de computador—Programação. I. Título.
QA76.76.C672R69 2004 794.8'1526
—dc22 2004015102
CIP
© 2005, Wordware Publishing, Inc.
Todos os direitos reservados
Avenida Los Rios 2320

Plano, Texas 75074
Nenhuma parte deste livro pode ser reproduzida de qualquer forma ou por
qualquer meio sem permissão por escrito da Wordware Publishing, Inc.
Impresso nos Estados Unidos da América
ISBN 1-55622-912-7
10 9 8 7 6 5 4 3 2
0406
Todos os nomes de marcas e nomes de produtos mencionados neste livro são marcas comerciais ou marcas de serviço de suas
respectivas empresas. Qualquer omissão ou uso indevido (de qualquer tipo) de marcas de serviço ou marcas registradas não deve
ser considerado como intenção de infringir a propriedade de terceiros. A editora reconhece e respeita todas as marcas utilizadas
por empresas, fabricantes e desenvolvedores como forma de distinguir seus produtos.
Este livro é vendido como está, sem garantia de qualquer tipo, expressa ou implícita, respeitando o conteúdo deste livro e
quaisquer discos ou programas que possam acompanhá-lo, incluindo, mas não se limitando a garantias implícitas de qualidade,
desempenho, comercialização, ou aptidão para qualquer finalidade específica. Nem a Wordware Publishing, Inc. nem seus
revendedores ou distribuidores serão responsáveis perante o comprador ou qualquer outra pessoa ou entidade com relação a
qualquer responsabilidade, perda ou dano causado ou alegadamente causado direta ou indiretamente por este livro.
Todas as consultas para compras em volume deste livro devem ser endereçadas à Wordware
Publishing, Inc., no endereço acima. As consultas por telefone podem ser feitas pelos telefones:
(972) 423-0090
Avisos de direitos autorais

Documento e imagens do projeto Atomic Sam ™ e ©1999-2004 Richard Rouse III. Personagem Atomic Sam
desenhado por Richard Rouse III e Steve Ogden. Todos os direitos reservados. Usado com gentil permissão.
O documento de design do sofrimento ©2004 Midway Home Entertainment. Todos os direitos reservados.
Usado com gentil permissão.
Partes do Capítulo 18, “Entrevista: Jordan Mechner”, apareceram originalmente na revista Inside Mac Games .
Imagens de Duke Nukem 3D e Max Payne ® e © 2004 3D Realms Entertainment. Todos os direitos reservados.
Imagens da versão 3D do Centipede ® e © 2000 Atari Interactive, Inc. Todos os direitos reservados. Usado
com gentil permissão. Embora o jogo seja referido como “Centipede 3D” neste livro para diferenciá-lo do jogo
mais antigo, seu nome próprio é simplesmente “Centipede”.
Imagens de Super Breakout, Asteroids, Centipede, Millipede e Tempest® ou ™ e © 2000 Atari Interactive, Inc.
Todos os direitos reservados. Usado com gentil permissão.
Imagens de WarCraft, WarCraft II, WarCraft III, StarCraft e Diablo II ® ou ™ e © 2004 Bliz zard Entertainment.
Imagens de Hodj 'n' Podj e The Space Bar © 2000 Boffo Games. Todos os direitos reservados. Usado com
gentil permissão.
Imagens de Pathways into Darkness, Marathon, Marathon 2, Marathon Infinity, Myth: The Fallen Lords e Halo
® ou ™ e © 2000 Bungie Softwarepermissão.
Products Corporation. Todos os direitos reservados. Usado com gentil
Imagens de Balance of Power, Trust and Betrayal: The Legacy of Siboot, Balance of Power II: The 1990
Edition, Guns & Butter, Balance of the Planet e Erasmatron ® or ™ e © 2000 Chris Crawford. Todos
reservados.
os direitos
Imagens de Myst ® e © 1993 Cyan, Inc. Todos os direitos reservados. Usado com gentil permissão.
Imagens de Battlefield 1942 ™ e © 2004 Digital Illusions CE. Todos os direitos reservados. Usado com gentil
permissão.
Imagens de Tomb Raider, Tomb Raider II, Thief, Thief II, Thief: Deadly Shadows e Deus Ex™ e © 2004 Eidos
Interactive. Todos os direitos reservados. Usado com gentil permissão. ® ou
Imagens de Ultima Online © 2004 Electronic Arts Inc. Ultima e Ultima Online são marcas comerciais ou marcas
registradas da Electronic Arts Inc. nos EUA e/ou em outros países. Todos os direitos reservados. Usado com
gentil permissão.
Imagens de Unreal, Unreal Tournament e Unreal Tournament 2004 ® ou ™ e © 2000 Epic Games. Todos os
direitos reservados. Usado com gentil permissão.
Imagens de Gettysburg de Sid Meier! e Alpha Centauri ™ de Sid Meier e © 2000 Firaxis Games. Todos os
Imagens de Doom, Doom II, Quake II e Quake III Arena ® e © 2000 id Software. Todos os direitos reservados.
iii
Imagens de Spellcasting 101 © 1990 Legend Entertainment Company, Spellcasting 201 © 1991 Legend
Entertainment Company e Superhero League of Hoboken © 1994 Legend Entertainment Company. Todos
os direitos reservados. Usado com a gentil permissão da Infogrames, Inc.
Imagens de Maniac Mansion, Loom e Grim Fandango ® ou ™ e © 2000 LucasArts Entertainment Company,
LLC. Todos os direitos reservados. Usado com autorização gentil.
Imagens de SimCity, SimEarth, SimAnt, SimCity 2000, SimCopter, SimCity 3000, The Sims e The Sims
Online ® e © 2004 Maxis, Inc. Todos os direitos reservados. Usado com gentil permissão.
Imagens de Karateka, Prince of Persia e The Last Express ® ou ™ e © 2004 Jordan Mechner. Todos os
Imagens de Prince of Persia: The Sands of Time ® e © 2004 Jordan Mechner/Ubisoft Entertainment. Todos
os direitos reservados. Usado com gentil permissão.
Imagens do F-15 Strike Fighter, Pirates!, F-19 Stealth Fighter, Covert Action, Railroad Tycoon, Civilization e
Civilization II ® ou ™ e © 2000 Microprose, Inc. Todos os direitos reservados. Usado com gentil permissão.
Imagens de Gauntlet®, Gauntlet II®, Xybots™, San Francisco Rush: The Rock - Alcatraz Edition™, San
Francisco Rush: Extreme Racing®, San Francisco Rush 2049™ e Gauntlet Legends® © 2000 Midway
Games West, Inc. Todos os direitos reservados. Usado com gentil permissão.
Imagens de Defender®, Robotron: 2048®, Joust® e Sinistar® © 2000 Midway Amusement Games, LLC.
Imagens da Smash TV®, Dr. Muto™ e The Suffering™ © 2004 Midway Amusement Games, LLC. Todos os
Imagens de Dark Age of Camelot™ e © 2004 Mythic Entertainment, Inc. Todos os direitos reservados.
Imagens de Super Mario Bros., Super Mario 64, The Legend of Zelda: Ocarina of Time, Super Mario
Sunshine, Metroid Prime e Mario Kart: Double Dash ® e © 2004 Nintendo of America. Todos os direitos
reservados. Usado com gentil permissão.
Imagens de Oddworld: Abe's Oddysee® e © 1995-2000 Oddworld Inhabitants, Inc. Todos os direitos
reservados. ® designam marcas registradas de Oddworld Inhabitants. Todos os direitos reservados. Usado
com gentil permissão.
Imagens de Odyssey: The Legend of Nemesis™ e © 2000 Richard Rouse III. Todos os direitos reservados.
Imagens de Damage Incorporated™ e © 2000 Richard Rouse III e MacSoft. Todos os direitos reservados.
Imagens do Riot Engine Level Editor © 2000 Surreal Software, Inc. Todos os direitos reservados.
Imagens de The Next Tetris™ e © 1999 Elorg, sublicenciado para Hasbro Interactive, Inc. pela The Tetris
Company. Tetris © 1987 Elorg. Conceito e design originais de Alexey Pajitnov. The Next Tetris™ licenciado
para The Tetris Company e sublicenciado para Hasbro Interactive, Inc. Todos os direitos reservados. Usado
com gentil permissão.
4
Dedicação
Em memória de Jaime.
v
Agradecimentos
Obrigado a Steve Ogden por voltar ao Atomic Sam e dar vida ao garotinho mais uma
vez.
Agradeço a Noah Falstein, James Hague, Damion Schubert, Ian Parberry e Mar
garet Rogers por examinarem meu trabalho e me fornecerem feedback e apoio
inestimáveis, que melhoraram tremendamente este livro.
Obrigado também a Tom Hall, Katherine Isbister, Darius Kazemi e Michael Eilers por
seus comentários sobre este livro e como ele pode ser melhorado na segunda vez.
Obrigado a Doug Church, Chris Crawford, Ed Logg, Jordan Mechner, Sid Meier,
Steve Meretzky e Will Wright por se submeterem graciosamente ao meu questionamento
quase interminável.
Obrigado a Wes Beckwith, Beth Kohler, Martha McCuller, Alan McCuller, Denise
McEvoy, Tim McEvoy e a todos da Wordware por tornarem este livro mais uma vez uma
realidade.
Por sua ajuda com este livro, obrigado a Jim Hill, Steve Crane, Ken Fedesna, George
Gomez, Rob Gustafson, Reilly Brennan, Robin Hunicke, Matt Bertz, Scott Miller, Jenny
Huldschner, Tyrone Miller, Carol Quito, Rannie Yoo, Loretta Stevens , Jason Wonacott,
Doug Zartman, Benson Russell, John Scott Lewinski, Ari Feldman, Laura J.
Mixon-Gould, Jeff Buccelatto, Jayson Hill, Laura Pokrifka, Josh Moore, Lisa Sokulski,
Dan Harnett, Steffan Levine, Susan Wooley, Chris Brandkamp, Kelley Gilmore, Lindsay
Riehl, Patrick Buechner, Greg Rizzer, Lori Mezoff, Jenna Mitchell, Ericka Shawcross,
Maryanne Lataif, Bryce Baer, Bob Bates, James Conner, Lisa Tensfeldt, Paula Cook,
Donald Knapp e Diana Fuentes.
Obrigado a Jamil Moledina, Jennifer Olsen, Alex Dunne e todos da Game Devel
oper/Gamasutra, Gordon Cameron, Tuncer Deniz, Bart Farkas, Andy Eddy, Brian
Moriarty, Scott McCloud, Ed Magnin, Bernd Kreimeier, Andrew Rollings, George
Broussard, Jason Della Rocca, Dave Astle, Tom Russo, Kevin Toyama, Greg Orlando,
George Jones, Owain Bennallack, Matthew Percival, Dishad Husain, Julie Perkins, Angie
Cox e todos da Gamer.tv, Jon Goodwin, Christopher Erhardt, Jonathan Kay, Neil Morton,
Stephen Granade, Jeff Vogel, Laura Heon, Kaarin Lemstrom-Sheedy & MassMOCA, Troy
Dunniway, Clay Heaton, Rich Carlson, Iikka Keranen, Curt Feldman e todos na E3, Alan
Patmore, Nick Radovich e todos em Surreal, David Zucker e todos na Midway, Mark
Bullock, a equipe do Leaping Lizard, Brian Rice, Lee Waggoner, Pat Alphonso, Peter
Tamte, Nate Birkholtz, Al Schilling, Cindy Swanson e todos na MacSoft, Alex Seropian,
Jason Jones, Jim McNally, Jeff O'Connor , Ira Harmon, Gordon Marsh, Glenn Fabry,
Derek Ri ggs e Chuck Schuldiner.
Agradecimentos especiais a Richard e Regina Rouse, Dave Rouse, Linda Rouse,
Grayson Starner, Margaret Rogers e o clã Rogers, June Oshiro e Matt Bockol, Ben
Young, Alain, Annalisa e Alexandria Roy, Katie e Eric Pidkameny, Gail Jabbour, Amy &
Jason Schigelone, Rafael & Belinda Brown, Eloise Pasachoff, Kristin Kane e Christian &
Logan Bell.
vi
Sobre o autor
Richard Rouse III é Diretor de Design da Surreal Software, um estúdio de entretenimento
doméstico Midway. Mais recentemente, ele foi líder de projeto, designer-chefe e escritor do
título de terror de ação The Suffering. Rouse desenvolve jogos profissionalmente há mais de
uma década, durante a qual trabalhou em jogos para PC, Macintosh, Sega Dreamcast, Sony
PlayStation, PlayStation 2 e Microsoft Xbox. Além de The Suffering, seus créditos incluem
Drakan: The Ancients' Gates, Centipede 3D, Damage Incor porated e Odyssey: The Legend of
Nemesis. Rouse escreveu sobre design de jogos para publicações como Game Developer,
SIGGRAPH Computer Graphics, Develop, Gamasutra, MyVideoGames.com e Inside Mac
Games, e falou sobre desenvolvimento de jogos várias vezes na Electronic Entertainment Expo.
Seu feedback
Seu feedback para este livro, incluindo correções, comentários ou divagações meramente
amigáveis, é encorajado. Por favor, envie-os para o autor em gdtp@paranoidproductions.com.
Você também encontrará a página da web deste livro, que será usada para rastrear correções,
atualizações e outros itens de interesse, em www.paranoidproductions.com/gamedesign. Vejo
você lá.
Sobre o Artista
Steve Ogden vem escrevendo no papel desde sempre e trabalhando na indústria de jogos por
quase tanto tempo. Ele conheceu Richard Rouse III uma vida atrás, enquanto eles trabalhavam
juntos no Centipede 3D da Hasbro. Mais tarde, os dois homens inventaram Atomic Sam como
um personagem para ilustrar um livro sobre princípios de design de jogos, o precursor do livro
que você agora tem em suas mãos. Ogden desenhou as fotos para esse livro enquanto
trabalhava na Cyan em realMYST e URU. Ele agora está feliz por estar de volta às colinas
verdes de casa no país de caça de Maryland, trabalhando na Firaxis. Foi enquanto terminava
o trabalho em Piratas de Sid Meier! e começando a trabalhar em Civilization IV que ele foi
solicitado mais uma vez a rabiscar algumas ilustrações de Atomic Sam para esta nova edição,
incluindo uma nova capa colorida brilhante! Dizer que ele aproveitou a chance é ceder ao
eufemismo. Ogden acha Sam um sujeito divertido e seu universo intrigante, e se pergunta em
voz alta se Atomic Sam um dia se tornará um jogo real, não apenas um personagem de um livro sobre
vii
Resumo do conteúdo
Capítulo 1 O que os jogadores querem .......................1
Capítulo 2 Entrevista: Sid Meier. . . 20. . . . . . . . . . . . . . . . . . .
Capítulo 3 Fazendo um brainstorming de uma ideia de jogo: jogabilidade, tecnologia,
e História. . . . . . . . ....... . . . . . . . . . . . 40
Capítulo 4 Análise do Jogo: Centopeia . ...... . . . . . . . . . . . 57
Capítulo 5 Foco. . . . . . . . . . . ....... . . . . . . . . . . . 69
Capítulo 6 Entrevista: Ed Logg. . . . ....... . . . . . . . . . . . 87
Capítulo 7 Os Elementos da Jogabilidade . . . . . . . . . . . . . . . . . 115
Capítulo 8 Análise do jogo: Tetris . . . . . . . . . . . . . . . . . . . . 141
Capítulo 9 Inteligência Artificial. . . . ....... . . . . . . . . . . 151
Capítulo 10 Entrevista: Steve Meretzky. . . . . . . . . . . . . . . . . 172
Capítulo 11 Narrativas. . . . . . . . ...... . . . . . . . . . . . 202
Capítulo 12 Análise do Jogo: Tear . . . . . . . . . . . . . . . . . . . 227
Capítulo 13 Multijogador . . . . . . ....... . . . . . . . . . . . 237
Capítulo 14 Entrevista: Chris Crawford. . . . . . . . . . . . . . . . . 257
Capítulo 15 Fazendo a jogabilidade funcionar . . . . . . . . . . . . . . 281
Capítulo 16 Análise do Jogo: Mito: Os Lordes Caídos . . . . . . . . . . . 296
Capítulo 17 Documentação de desenvolvimento de jogos . . . . . . . . . . . . 306
Capítulo 18 Entrevista: Jordan Mechner. . . . . . . . . . . . . . . . . 320
Capítulo 19 O Documento de Design . . . . . . . . . . . . . . . . . . . 355
Capítulo 20 Análise do Jogo: The Sims . . . . . . . . . . . . . . . . . . 382
Capítulo 21 Projetando Ferramentas de Projeto. . . . . . . . . . . . . . . . . . . 392
Capítulo 22 Entrevista: Will Wright. . ...... . . . . . . . . . . . 408
Capítulo 23 Projeto de Nível . . . . . . . . . . . . . . . . . . . . . . . . 449
Capítulo 24 Análise do jogo: Grand Theft Auto III . . . . . . . . . . . . 475
Capítulo 25 Teste de jogo . . . . . . . . . . . . . . . . . . . . . . . . . 483
Capítulo 26 Entrevista: Doug Church. . . . . . . . . . . . . . . . . . 500
Conclusão. . . . . . . . . . . . . ....... . . . . . . . . . . . 532
Apêndice A Documento de Projeto de Amostra: Atomic Sam. . . . . . . . . . . 535
Apêndice B Documento de Projeto de Amostra: O Sofrimento . . . . . . . . . . 579
Glossário. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
Bibliografia Selecionada. . . . . . . . . . . . . . . . . . . . . . . . . . 672
Índice. . . . . . . . . . . . . . . ....... . . . . . . . . . . . . 677
viii
Conteúdo
Prefácio . . . . . .. . .. xvi
....... . . ..... . . ....... . .
Introdução à segunda edição ......... xvii
Introdução . ....... . . ....... . . ....... ....... . xx
Capítulo 1 O Que os Jogadores Querem .......................1

Por que os jogadores jogam? ..............................2
Os Jogadores Querem um Desafio..............................2
Jogadores Querem Socializar ..............................3
Os jogadores querem uma experiência solitária dinâmica ...............5
Os jogadores querem o direito de se gabar ....................... 5
Os jogadores querem uma experiência emocional ..................6
Os Jogadores Querem Explorar ....................... 6
Os jogadores querem fantasiar ......................... 7
Os jogadores querem interagir ..............................8
O que os jogadores esperam? .......................... 8
Os jogadores esperam um mundo consistente ..................8
Os jogadores esperam entender os limites do mundo do jogo ........9
Os jogadores esperam que soluções razoáveis funcionem. . . .. .. .. .. .. . 10
. .
Os jogadores esperam direção. . . . . . . 10 . . . . . . . . ...... . .
Os jogadores esperam realizar uma tarefa de forma incremental. . . . . 11 . . . . . .
Os jogadores esperam ser imersos. 12. . . . . . . ....... . . ....
Os jogadores esperam alguns contratempos. . . . . . . 14 . . . . . . . . . . . ....
.
Os jogadores esperam uma chance justa. 14 . . . . . . . . . . . . . . . . . ....
Os jogadores esperam não precisar se repetir. . . . . . . . . 15 . .
Os jogadores esperam não ficar irremediavelmente presos. . . .. .. .. .. .. . 16
Os jogadores esperam fazer, não assistir. . . . . ..... .. .. .17
. . ..
Os jogadores não sabem o que querem, mas sabem quando
Está faltando . . . . . . . . . . ....... . . ....... . . . . . . 18
Uma lista interminável. . . . . . . ....... . . ....... . . . . . . 19
Capítulo 2 Entrevista: Sid Meier. . . . . . . . . . . . . . . . . . . . 20
Capítulo 3 Fazendo um brainstorming de uma ideia de jogo: jogabilidade, tecnologia,

e História. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Pontos de Partida. 41 . . ....... . . ....... ....... . . ....
Começando com a jogabilidade. . . . 42. . . . . . . . . . . ....... ....
Começando pela Tecnologia. . ... .. ....43 ..... ....... . .
Começando com História. . . . . ... .. .. .. 45 ..... ....... . .
Trabalhando com Limitações. . . . . .. .. ....47 ... . . ....... . .
Odisseia: A Lenda de Nêmesis. . . . . . . . . 48 . . ....... . .
Dano Incorporado. . . . . . . . . 49. . . . . . . . . ....... . .
ix
Conteúdo
Centopeia 3D. . . . . . . . . ....... . . ..... . . . . . . . . 50

O sofrimento . . . . . . . . . ....... . . ..... . . . . . . . . 51
Abrace suas limitações. . . . ....... . . ....... . . . . . . 52
Tecnologia Estabelecida. . . . . . . . . . . . . ....... . . . . . . 53
O Caso dos Muitos Cogumelos. . . . . . . ..... . . . . . . . . 54
O Tempo Atribuído. . . . . . . ....... . . ..... . . . . . . . . 55
Se você optar por não decidir, você ainda fez uma escolha. . . . . . . . 56
Capítulo 4 Análise do Jogo: Centopeia . . . . . . . . . . . . . . . . 57

Características clássicas do jogo de arcade. . . . . . . . . . ....... . . . . . . . . 59
Entrada. . . . . . . . . . . . . . . . ....... ....... . . . . . . . . 62
Interconectividade. . . . . . . . ....... ....... . . . . . . . . 63
Escalada de Tensão. . . . . . . . . . . . . . . ....... . . . . . . . . 65
Uma pessoa, um jogo. . . . . . ....... ....... . . . . . . . . 67
Capítulo 5 Foco. . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Estabelecendo o Foco. . . . . . . . . . . . . . . ....... . . . . . . . . 70
Um Exemplo: Turbilhão de Carnaval de Inverno. . ....... . . . . . . . . 72
A Função do Foco. . . ..... . . ....... . . . . . . . . 74
Mantendo o foco. . . . . . . . ..... . . ....... . . . . . . . . 77
Concretizando o foco. . . . ....... . . ..... . . . . . . . . 78
Mudando o foco. . . . . . . . ..... . . ....... . . . . . . . . 79
Sub-Focos. . . ....... . . ..... . . ....... . . . . . . . . 82
Usando o foco. . . . . . . . . . . . ..... . . ....... . . . . . . . . 85
Capítulo 6 Entrevista: Ed Logg. . . . . . . . . . . . . . . . . . . . 87
Capítulo 7 Os Elementos da Jogabilidade . . . . . . . . . . . . . . . 115

Soluções únicas. . . . . . . . . . .. . .116
....... . . .......
Sistemas Antecipatórios versus Sistemas Complexos . . .. ... .. .116
. .... . .
. . .
Emergência. . . . . . . 117. . . . . . . . . . . . . . . . . . . . . .
Não-linearidade . . . . . . . 119. . . . . . . . . . . ..... . .
Tipos de não linearidade. . . . . . . . . .
119 . . . . . . . . .
. .
Implementação. . . . . . 121 . . . . . . . .. . . ....... ......
.
O Propósito da Não Linearidade . . . . . . . . . . 123 . . . . . . . . . .
. . . . . .
Modelando a Realidade. . . . . . . . . . . . . 125. . . . . . . . . . . .
Ensinando o jogador. . . . . . . .. . .. .. 127
..... . . ..... . .
Tutoriais. . . .. .. .. .. 128
.... . . ....... . . ..... . .
Entrada/Saída .. . . . . . . 131 . . . ....... . . ..... . .
Controles e Entrada. . . . . .. .. . .. .. .131
.... . . ..... . .
Saída e feedback do mundo do jogo . . . . . ... . . . .136 ...
Elementos básicos . . . . . . . .. . . .. .. .. 140
.... . . ..... . .
Capítulo 8 Análise do jogo: Tetris . . . . . . . . . . . . . . . . . . 141

Jogo de quebra-cabeça ou jogo de ação? . . . . . . . . ....... . . ...... 142
Tetris como um jogo de arcade clássico. . . . . . . . . ....... . . . . . . 144
A tecnologia . . . . . . . . . ....... . . . . . . . . . . . . . . . 146
x
Conteúdo
Inteligência artificial . . . . . . ....... . . ....... . . . . . . 147

Escalada de Tensão. . . . . . . . . . . . . . . . . ....... . . . . . . 148
Simplicidade e Simetria. . . . . . . . . . . . . ....... . . . . . . 149
Quinze anos depois, quem publicaria Tetris? . . ..... . . . . . . . . 150
Capítulo 9 Inteligência Artificial. . . . . . . . . . . . . . . . . . . 151

Objetivos do jogo AI. . . . .153
.... . . ....... . . ....... . .
Desafie o jogador. . . . . . . .154 . ....... . . ....... . .
Não Faça Coisas Idiotas. . .. .. ....156 ..... . . ....... . .
Seja imprevisível. . . . . . . . ..157 ....... . . ....... . .
Auxiliar na Contação de Histórias. ... ... .. ... .159
.... . . ....... . .
Crie um mundo vivo. . . . . .. 162 . ....... . . ....... . .
O Campo de Jogo Inclinado. . . . . . 162 . . . . . . . . . . . ....... . .
Quão real é muito real? . . . ... . 163 ...... . . ....... . .
Agentes de IA e seu ambiente. . . . . . . . . . 164 . . ....... . .
Quão bom é bom o suficiente? . . . . . . 167 . . . . . . . . . ....... . .
. .
Scripts. . . . . . . . 168 . . . . . . . . . . . . . . . . ....... . .
. . .
Estupidez Artificial. . . . . 171 . . . . . . . . . . . . . ....... . .
Capítulo 10 Entrevista: Steve Meretzky. . . . . . . . . . . . . . . 172
Capítulo 11 Narrativas . . . . . . . . . . . . . . . . . . . . . . . 202

História do designer versus história do jogador . .. .. .. .. ... .. .. 203. .
Lugares para contar histórias. . .. ... .. .. .. .. ..206
.. . . .......
. . .......
Fora do Jogo. . . . . . . . . . . . . 207 . . .......
No jogo. . . 212 . . . . . . . . . ....... . . ....... ......
Materiais Externos. . . . . . .. .. . .. .216 ..... . . .......
Armadilhas da Escrita Linear. . .. . .. .. .. .. ... .217
.. . . .......
Personalidade do personagem do jogador. . . . . ... .. . .. .. 218
..... . .
.......
Histórias de jogos. 222 . . ....... . . ....... ......
Não-linearidade. . . . . . . . . ... . . .223 .... . . .......
Trabalhando com a jogabilidade. 224 ....... ....... . . ......
O sonho. . . . . . .. .. .. 225
.... . . ....... . . .......
Capítulo 12 Análise do Jogo: Tear. . . . . . . . . . . . . . . . . . 227

Mecânica de jogo focada. . . . ....... . . ..... . . . . . . . . 228
Interface de usuário . . . . . . . . . . ....... . . ..... . . . . . . . . 230
O Sistema de Rascunhos. . . . . . . . . . . . . . . . ..... . . . . . . . . 231
Dificuldade. . . . . . . . . . . . . ....... . . ..... . . . . . . . . 233
História . . . . . . . . . . . . . . . ....... . . ..... . . . . . . . . 233
Loom como um jogo de aventura. . ....... . . ....... . . . . . . 235
Capítulo 13 Multijogador. . . . . . . . . . . . . . . . . . . . . . . 237

Motivações. . ....... . . ....... . . . . . . . . . . . . . . . 238
Os formulários . . . . . . . . . . . . ....... . . . . . . . . . . . . . . . 239
Multijogador de sistema único . . . . . . . . ....... . . . . . . . . 239
Multijogador Online. . . . . . . . . . . . . . . . . . . . . ...... 241
XI
Conteúdo
Considerações de projeto. . . . . . . .....

. . ....... . . . . . . 242
Jogando com os pontos fortes. . . . . . . .....
. . ....... . . . . . . 244
Proteja os novatos. . . . . . . . . .....
. . ....... . . . . . . 246
Socialização. . ....... . . .....
. . ....... . . . . . . 248
Questões de Desenvolvimento. . . . . . . . . .....
. . ....... . . . . . . 251
Teste de jogo e feedback do usuário. . . . . . . . ....... . . . . . . 253
Um Mundo Próprio. . . . . . . . ..... . . ....... . . . . . . 256
Capítulo 14 Entrevista: Chris Crawford. . . . . . . . . . . . . . . 257
Capítulo 15 Fazendo a jogabilidade funcionar . . . . . . . . . . . . 281

O Processo Orgânico. . . . . . . . . . . . . . . ....... . . . . . . 283
Demais e antes da hora . . . . . . . . . . . . . . ....... . . . . . . 283
Mantenha simples . . . . . . . . . . . . . . . . . ....... . . . . . . 285
Construindo o Jogo. . . . . . . . . . . . . . . . . ....... . . . . . . 286
Tecnologia essencial . . . . . . . . . . . . . . . . ....... . . . . . . 286
Etapas Incrementais. . . . . . . . . . . . . . . ....... . . . . . . 287
Uma Área Totalmente Funcional. . . . . . . . . . ....... . . . . . . . . 288
Passando por mudanças . . . . . . . . . . . . . . . . . . . . . . . . . 290
Programação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Quando é divertido? . . . . . . . . . . . . . . . . . . ....... . . . . . . 293
Capítulo 16 Análise do Jogo: Mito: Os Lordes Caídos . . . . . . . . 296

Uso da Tecnologia. . . . . . . . . . . . . . . . . ....... . . . . . . 297
Foco do jogo. . . . ..... . . ....... . . ....... . . . . . . 300
Narrativa . . . . ..... . . ....... . . ....... . . . . . . 301
Jogos Hard-Core. . . . . . . ....... . . ....... . . . . . . 302
Multijogador. . . . . . . . . . . . . . . . . . . . ....... . . . . . . 303
Um Todo Coeso. . . . . . . . . . . . . . . . . ....... . . . . . . 304
Capítulo 17 Documentação de desenvolvimento de jogos . . . . . . . . . . 306

. . .......
Documente seu jogo. . . . . . . . . . 308 . . .......
Documento de conceito, documento de proposta ou proposta . . . . . . . . . . . 308
Analise competitiva. . . . . ....... . . ....... . . . . . . 309
Documento de projeto. . . . . . . . . . . . . . . ....... . . . . . . 309
Fluxogramas. . . . . . . . . . ....... . . ....... . . . . . . 311
Bíblia de histórias. . . . . . . . . . ....... . . ....... . . . . . . 311
Roteiro . . . . . . . . . . . . . ....... . . ....... . . . . . . 313
Arte Bíblia. . . . . . . . . . . ....... . . ....... . . . . . . 315
O minuto do jogo. . . . . . ....... . . ....... . . . . . . 316
Storyboards. . . . . . . . . . ....... . . ....... . . . . . . 317
Documento de Projeto Técnico. . . . . . . . . . . . . . . . . . . . . . . 317
Cronogramas e Documentos Comerciais/Marketing . . . . . . . . . . . 318 .
Nenhuma documentação padrão. . . . . . . . ....... . . . . . . . . 319
Os Benefícios da Documentação. . . . . . . . ....... . . . . . . . . 319
xii
Conteúdo
Capítulo 18 Entrevista: Jordan Mechner. . . . . . . . . . . . . . . 320
Capítulo 19 O Documento de Design . . . . . . . . . . . . . . . . . 355

O Estilo de Escrita. . . . . . . . .. . .. . 357.... . . ....... . .
As Seções. . . . . . .. 359....... . . ....... ....... . .
Índice. . . . . . . . . . . 360 . . ..... . . ....... . .
Introdução/Visão Geral ou Resumo Executivo. . . . . . . .. . . . 360
Mecânica do Jogo. . . . . . . . . . . .361
. ..... . . ....... . .
Inteligência artificial . . . . . .. . ....366 ... . . ....... . .
Elementos do Jogo: Personagens, Itens e Objetos/Mecanismos . . . . 369
Visão geral da história. . . . .. . .. .. .. .. .. ..371. . . . . . . . . . .
Progressão do jogo. . . . . .. . .. . . .371 .. . . ....... . .
Menus do Sistema. . . . . .. . .. .. .. .. .. .373. . . . . . . . . . .
.
A opinião de um homem. . . . . . . . . . 373. . . . . . . . . . . . . . . . .
Documentos de projeto inauspiciosos. . . . . . . . . . . . 374 .
. . . . . . . .
O Documento Especial Wafer-Thin ou Ellipsis . . . . . . .. . .. . . 374
O tomo da história de fundo.. . .. .. .. ..... .375. . . . . . . . . . .
O Documento Exagerado. . 376 . . . . . . . . . ....... . . .....
O documento Pie-in-the-Sky. . . . . . . . . . . . 377 . . . . . . . . .
O Documento Fossilizado. . .. . . . . 378 ... ....... . .
Uma Questão de Peso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Obtendo-o lido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
A documentação é apenas o começo. . . . . . . . . . . . . . . . . . . 380
Capítulo 20 Análise do Jogo: The Sims . . . . . . . . . . . . . . . . 382

Abdicando da autoria. . . . . . . ... . .383 ..... . . ..... . .
Assunto Familiar. . . . . . . 384. . . . . . . . . . . ....... . .
Experimentação Segura. . . . . .. . .. .. .. .386 ... . . ..... . .
Profundidade e Foco. . . . . . . .. . .. .. .. .. .386
.. . . ..... . .
Interface. . . ... . .. .. 387
..... . . ....... . . ..... . .
Comportamento controlado versus autônomo. . . . . . . .. 389
. .......
Uma lição a ser aprendida. . . . . . . .. 390
. ....... ....... . .
Capítulo 21 Projetando Ferramentas de Projeto. . . . . . . . . . . . . . . . . 392

Funcionalidade Desejada. . . . .. . .. .. .. .. .394 .. . . .......
Visualizando o Nível . . . . . ... . . .394 .... . . .......
A grande imagem. . . . . . . .. . ......396 .... . . .......
Pulando no jogo. . . . . . . . .397 . ....... . . .......
.
Editando o mundo. . . . . . . . . 399 . . . . . . . . . . .......
Linguagens de Script e Comportamentos de Objetos . .. . .. .. .. .. .. 400. .
Nós contra eles. . . . . . . . . . . .. . 403
....... . . .......
A melhor das intenções. . . . . . . .. 405
. ....... . . .......
Um editor de jogos para todas as estações. . . . ... .. . . . 406. . . . . . . . .
xiii
Conteúdo
Capítulo 22 Entrevista: Will Wright. . . . . . . . . . . . . . . . . 408
Capítulo 23 Projeto de Nível . . . . . . . . . . . . . . . . . . . . . . 449

Níveis em diferentes jogos. . . ....... . . ....... . . . . . . 450
Separação de Nível. . . . . . . . . . . . . . . . ....... . . . . . . 451
Ordem de nível. . . . . . . . . . ....... . . ....... . . . . . . 453
Os componentes de um nível. . . . . . . . . . . . . . . . . . . . . . . . . 454
Açao . . . . . . ....... ....... . . ....... . . . . . . 455
Exploração . . . . . . . . . . ....... . . ....... . . . . . . 456
Resolução de quebra-cabeças. . . . . . . . ....... . . ....... . . . . . . 457
Narrativa . . . ....... ....... . . ....... . . . . . . 458
Estética. . . ....... ....... . . ....... . . . . . . 459
Equilibrando o fluxo . . . . . . . . ....... . . ....... . . . . . . 460
de todos os níveis. . . . . . . . . . . . ....... . . ....... . . . . . . 460
Elementos de Bons Níveis. . . . . . . . . . . . . ....... . . . . . . 463
Os jogadores não podem ficar presos. . . . . . . . . . . . . . . . . . . . . . . . 463
Sub-objetivos. . . . . . . . . . . ....... . . ....... . . . . . . 463
Marcos. . . ..... . . ....... . . ....... . . . . . . 464
Caminho crítico. . . . . . . . . . ....... . . ....... . . . . . . 465
Retrocesso limitado. . . . . . . . . . . . . . . . . . . . . . . . . . 465
Sucesso pela primeira vez. . . . ....... . . ....... . . . . . . 465
Áreas navegáveis claramente marcadas. . . . . . . . . . . . . . . . . . . . 466
Escolhas . . . . . . . . . . . . . . . . . . . . . ....... . . . . . . 466
Uma lista pessoal. . . . . . . . ....... . . ....... . . . . . . 466
O processo . . . . ..... . . ....... . . ....... . . . . . . 467
Etapa 1. Preliminar. . . . . . . . . . . . . . . ....... . . . . . . 467
Etapa 2. Esboço Conceitual e Esboçado . . . . . . . . . . . . . . . . 468
Etapa 3. Arquitetura Base/Bloqueio . . . . . . . . . . . . . . . . . . 469
Etapa 4. Refinar a arquitetura até que seja divertida . . . . . . . . . . . . . . . 469
Etapa 5. Jogabilidade básica. . . . . . . . . . . . . ....... . . . . . . 470
Etapa 6. Refinar a jogabilidade até que seja divertido. . . . . . . . . . . . . . . . . 471
Etapa 7. Refinar a Estética . . . . . . . . . . . ....... . . . . . . 471
Etapa 8. Teste de jogo . . . . . . . . . . . . . . . ....... . . . . . . 472
Variações de Processo. . . . . . ....... . . ....... . . . . . . 472
Quem faz o design de níveis? . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Colaboração. . . . ..... . . ....... . . ....... . . . . . . 474
Capítulo 24 Análise do Jogo: Grand Theft Auto III . . . . . . . . . . 475

Mundo de jogo crível. . . . . . . . . 476. . . . . . . . . ....... . .
. . . . . . .
Uma Cidade Viva. . . . . . . . 477 . . . . . . . . . . . . . . . . . .
Ações e Consequências . . 480 . . . . . . . . . . . . . . . . .......
. . . .
Narrativa . . . . . . . 481. . . . . . . . . . . . . . . . . . . . . .
Capítulo 25 Teste de jogo . . . . . . . . . . . . . . . . . . . . . . . 483

Encontrando os testadores certos. ... .. .. .. .. .. . 484. . . . . . . . . . .
Quem deve testar. . . . . . . . . . . .485 .. . . ....... . .
xiv
Conteúdo
Quem não deve testar. . . . . ....... . . ....... . . . . . . 487

Quando Testar. . . . . . . . . . . ....... . . ....... . . . . . . 489
Como Testar. . . . . . . . . . . ....... . . ....... . . . . . . 491
Testes guiados e não guiados. . ....... . . ....... . . . . . . 492
Balanceamento. . . . . . . . . . . . . ....... . . ....... . . . . . . 493
Seu jogo é muito difícil. . . ..... . . ....... . . . . . . . . 495
A Visão Artística. . . . . . . ....... . . ....... . . . . . . 497
Capítulo 26 Entrevista: Doug Church. . . . . . . . . . . . . . . . 500
Conclusão. . . . . . . . . . . . . . . . . . . . . . . . . . 532
Arte . . . . . . . . . ........532
... . . ....... . . .......
O médio . . . . . . . . 533 ..... . . ....... . . .......
O Motivo. . . . . . . . 534 ..... . . ....... . . .......
Apêndice A Documento de Projeto de Amostra: Atomic . . . . . . . . 535

Sam I. Visão Geral. . . .. . . . . . . ....... ....... . . . . . . . . 539
II. Mecânica do Jogo. . . . . . . ..... . . ....... . . . . . . . . 540
III. Inteligência artificial . . . . ..... . . ....... . . . . . . . . 555
4. Elementos do jogo. . . . . . . ..... . . ....... . . . . . . . . 561
V. Visão geral da história. . . . . . . . . . . . . . . ....... . . . . . . . . 571
VI. Progressão do jogo. . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
VII. Bibliografia . . . . . . . . ..... . . ....... . . . . . . . . 578
Apêndice B Documento de Projeto de Amostra: O Sofrimento. . . . . . . . 579

Seção I: Introdução. . . . . . ..... . . ....... . . . . . . . . 587
Seção II: Mecânica do Jogo . . ....... ....... . . . . . . . . 588
Visão geral dos controles. . . . . . . . . . . . . ....... . . . . . . . . 616
Seção III: Recursos . . . . . . ..... . . ....... . . . . . . . . 617
Seção IV: NPCs . . . . . . . . ..... . . ....... . . . . . . . . 622
Seção V: História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Seção VI: Fluxo de jogo . . . . . . ..... . . ....... . . . . . . . . 638
Seção VIII: Menus . . . . . . . ..... . . ....... . . . . . . . . 651
Glossário. . . . . . . . . . . . . . . . . . . . . . . . . . . 655
Bibliografia Selecionada. . . . . . . . . . . . . . . . . . . . 672

Índice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
xv
Prefácio
Apenas alguns anos atrás, livros sobre design de jogos de computador eram tão raros nas
prateleiras de livros quanto gravatas de seda no guarda-roupa de um programador de jogos.
Então, por volta da virada do milênio, um fio de novos livros começou a aparecer. Uma das
primeiras que me chamou a atenção foi a primeira edição deste livro, Game Design: Theory &
Practice de Richard Rouse III. Observei que Richard tem créditos de design em jogos publicados
e os insights duramente conquistados que transmite, bem como as habilidades descritivas para
articular esses insights. Também apreciei a verdade literal do título do livro; ele abrange as
teorias subjacentes ao design de jogos, ao mesmo tempo em que fornece orientação prática
sobre como colocar essas teorias em uso. Mas meus capítulos favoritos do livro foram as
entrevistas. Richard convenceu uma impressionante variedade de designers de jogos talentosos
e influentes a responder suas perguntas completas e perspicazes. Então, quando Richard me
pediu para revisar e comentar sobre esta última revisão de seu livro e escrever uma introdução, eu agarrei a
O design de jogos ainda é um ofício jovem, mas está amadurecendo rapidamente.
Certamente não mais em sua infância, os jogos de computador e vídeo existem há mais de 30
anos e, apesar de uma generosa ajuda da Síndrome de Peter Pan, eles alcançaram pelo menos
uma adolescência virtual. Isso significa que os designers de jogos se formaram nos estágios de
tentativa e erro dos primeiros anos e aprenderam o que funciona e o que não funciona. Por sua
vez, isso resultou em uma base de conhecimento compartilhada crescente de princípios
universais de design de jogos. Meu próprio quarto de século de experiência em desenvolvimento
de jogos e pesquisa sobre as regras subjacentes do bom design de jogos indicaram que é
possível identificar e ensinar as regras que influenciaram todos os jogos de sucesso por
décadas, e este livro é um valioso colaborador. a esse corpo de conhecimento.
Mas os videogames da era Pong têm uma semelhança bastante tênue com as
extravagâncias multimilionárias dos dias atuais, e muitas das habilidades necessárias para
projetar um jogo também mudaram e amadureceram. Além disso, os jogos apresentam uma
faceta muito variada para o mundo. Superficialmente, jogos como Centipede ou Tetris são muito
diferentes de The Sims ou Civilization. Portanto, é impressionante que este livro consiga
identificar muitas qualidades que são comuns a todos os bons jogos e as habilidades necessárias
para criar documentos de design para eles, ao mesmo tempo em que faz um trabalho confiável
ao abranger elementos específicos de certos tipos de jogos, como narrativa, scripts, IA e design
multijogador. Os capítulos de análise de jogos dissecam e avaliam as qualidades internas dos
jogos e, assim, fornecem informações tanto sobre os jogos destacados quanto sobre o próprio
processo de análise. E as entrevistas aprofundam tanto o conhecimento compartilhado de
designers renomados quanto suas peculiaridades individuais e histórias únicas.
Resumindo, achei este livro notável por revelar o alcance do processo criativo de design
de jogos, bem como simplesmente divertido de ler. E eu espero que você também!
Noah Falstein
Greenbrae, CA
xvi
Introdução ao segundo
Edição
Já se passaram quatro anos desde o lançamento da primeira edição do livro que você agora tem
em suas mãos. É interessante refletir sobre o que mudou na indústria durante o intervalo, ou, mais
especificamente, o que não mudou. De muitas maneiras, vimos uma continuação das tendências
que estavam em andamento quando este livro foi escrito pela primeira vez. Os jogos continuam a
ficar maiores e mais bonitos, mas não necessariamente mais divertidos.
As licenças tornaram-se mais prevalentes do que nunca, seja na forma de um filme ou apenas com
uma personalidade quase famosa ligada a um projeto. A linha entre um jogo de computador e um
jogo de console tornou-se cada vez mais tênue, com os maiores jogos normalmente sendo
lançados em ambos, alguns com o mesmo nome, mas em formas diferentes, mas a maioria
fornecendo quase exatamente a mesma experiência. Em geral, títulos ousadamente originais
tornaram-se menos e mais distantes entre si.
Muita coisa aconteceu comigo desde a primeira edição e, quando apropriado, integrei essa
experiência nesta revisão. O jogo em que eu estava trabalhando durante a escrita da primeira
edição, um western chamado Gunslinger, morreu debaixo de mim.
Embora tivesse vários problemas, acabou sendo vítima da natureza cada vez mais avessa ao risco
do setor. Depois disso, consegui trabalhar bastante em Drakan: The Ancients' Gates e depois
desenvolvi The Suffering desde a concepção até a localização. Novos exemplos da prática de
desenvolvimento de jogos em The Suffering são integrados ao longo dos capítulos desta edição.
Além disso, além do documento Atomic Sam que apareceu no livro original, o documento de design
completo para The Suffering foi incluído como apêndice. Espero sinceramente que este documento
de design seja de particular interesse para os leitores, pois foi usado para um título que realmente
foi enviado.
Desde o lançamento do primeiro livro, dois jogos alcançaram um sucesso popular maior do
que qualquer um poderia prever. Esses jogos são The Sims (que foi analisado na primeira edição)
e Grand Theft Auto III (que é analisado nesta nova edição). Nesse meio tempo, todos os designers
de jogos entrevistados na edição original concluíram novos trabalhos na indústria, com cinco dos
seis lançamentos de novos jogos, enquanto Chris Crawford lançou dois livros. Para esta edição,
tive a sorte de conversar mais uma vez com a maioria desses designers para atualizar suas
entrevistas para refletir suas realizações mais recentes (com a notável exceção de Sid Meier, que
até o momento está tentando enviar a nova versão do Piratas!). Além disso, a segunda edição me
deu a oportunidade de fazer uma entrevista em profundidade com um designer de jogos que citei
extensivamente no primeiro livro, Doug Church. Church é um dos designers mais progressistas
que trabalham hoje, e espero que ler seus pensamentos seja uma inspiração para qualquer
designer.
Além de acrescentar mais exemplos dos jogos dos últimos quatro anos, para a segunda
edição eu queria melhorar o que o livro fez bem da primeira vez, enquanto preenchia
xvii
Introdução à segunda edição
algumas das lacunas. Os jogos multijogador tornaram-se significativamente mais prevalentes desde
a primeira edição e foram lamentavelmente sub-representados no livro anterior; agora o jogo multi-
jogador é o assunto de um capítulo inteiro. Embora os capítulos de narrativa e inteligência artificial
estejam entre os mais expandidos do livro, todos os capítulos foram revisados e atualizados
significativamente. Até a bibliografia e o glossário foram reformulados e ampliados.
Ao trabalhar na segunda edição de Game Design: Theory & Practice, revisei muito do feedback
que recebi da primeira edição e fiz o meu melhor para abordar algumas das preocupações levantadas.
No entanto, posso dizer que as opiniões aqui contidas ainda são distintamente minhas e representam
minhas opiniões pessoais sobre o desenvolvimento de jogos.
Muitas vezes meus pensamentos se alinham com a sabedoria comumente aceita na indústria, mas
outras vezes você descobrirá que discordo do que todo mundo parece estar fazendo. Quem está certo?
Ninguém está certo, por si só. Na criação da arte não há absolutos fáceis. Como designer de jogos,
você precisa equilibrar a sabedoria predominante com o que sente em seu coração. Se você sempre
toma decisões com base na opinião popular ou no sabor do momento, sempre fará jogos medianos e
previsíveis. Como designer de jogos, você deve pegar o que digo neste livro, refletir sobre isso e
decidir onde você está e como deseja prosseguir em seus próprios projetos. É minha sincera
esperança que suas visões de design de jogos acabem substancialmente diferentes das minhas, para
que quando você faça um jogo e eu façamos um jogo, não acabemos com exatamente a mesma
experiência de jogador. A variedade, afinal, não é apenas o tempero da vida, é a vida.
Um dos comentários mais frequentes que ouvi sobre a primeira edição do livro foi que parecia
datado. Eu argumentaria que não estava datado, apenas que tentou olhar para o desenvolvimento do
jogo ao longo de toda a história do meio, não apenas os três anos anteriores à publicação do livro. O
livro continha exemplos e discussão de jogos atuais proporcionais aos jogos clássicos. De fato, se eu
tivesse focado mais no que era atual na indústria quando o escrevi, o livro poderia parecer relevante
em seu lançamento, mas dentro de alguns anos teria sido terrivelmente datado. Se olharmos para a
primeira edição hoje, quatro anos depois de ter sido lançada, veremos que ela é quase tão relevante
hoje quanto era naquela época. Assim, ao fazer uma nova edição, me esforcei menos para “atualizar”
o livro e mais para expandir o que já estava fazendo. Sim, incluí referências a jogos mais recentes, já
que muitos jogos novos e excelentes foram lançados desde que o livro foi publicado pela primeira
vez, mas mantive o mesmo número de discussões sobre os clássicos das últimas três décadas.
Qualquer um que tenha trabalhado comigo sabe que, no calor do desenvolvimento de jogos, é
provável que eu me inspire em um jogo feito em 1983 ou em um jogo feito em 2003. Eu diria que para
ser um grande designer de jogos, você precisam entender o passado tão bem quanto o presente.
Como designer de jogos, se você não consegue ver o valor e as lições a serem aprendidas de um
jogo clássico feito em 1983, então você tem um longo caminho a percorrer antes de realmente
entender nosso meio.
Na verdade, sempre vi este livro como uma espécie de lição de história para desenvolvedores e
entusiastas de jogos. Além dos capítulos de análise de jogos, isso aparece especialmente nas
entrevistas, que espero que os leitores gostem tanto pelo que nos contam sobre a história do jogo
quanto por suas percepções específicas sobre o desenvolvimento de jogos. Se um leitor vir neste
livro uma referência a um jogo com o qual não está familiarizado, espero que procure esse título para
jogá-lo. Quase todos os jogos que eu
xviii
Introdução à segunda edição
me refiro neste livro são títulos que considero valer o tempo de qualquer um para jogar. Dito isto,
um grande problema para os historiadores e desenvolvedores de jogos é que realmente jogar um
jogo de vinte ou até dez anos atrás pode ser bastante difícil. Se você é um aspirante a cineasta,
rastrear quase todos os clássicos do cinema que remontam a cem anos é bastante fácil. Não é
assim com jogos de computador e vídeo. Os emuladores fizeram muito para ajudar nisso, mas
muitos jogos que são bastante conhecidos e respeitados são praticamente impossíveis de jogar
para a maioria das pessoas porque os sistemas em que trabalhavam não funcionam mais, porque
os próprios jogos estão esgotados, ou ambos. Acredito que nossa capacidade de crescer como
indústria é diretamente proporcional à nossa capacidade de entender nosso passado: se não
podemos entendê-lo porque não podemos jogá-lo, nossa evolução pode ser atrofiada.
Ao longo deste livro, discuto o que acredito que um designer de jogos deve considerar ao
desenvolver um jogo. Descobri que uma maneira de melhorar sua metodologia de design de jogos
é escrever um livro sobre isso. Embora eu possa não recomendar essa técnica a todos (afinal, as
livrarias só podem ter tantos volumes diferentes sobre o assunto), posso testemunhar que pode
ser bastante útil tirar o nariz da pedra de amolar de vez em quando e pense em jogos e seu
desenvolvimento um passo ou dois longe do processo diário de fazer isso acontecer. Devo advertir
que um efeito colateral infeliz de escrever um livro é ter seus colegas de trabalho apontando para
você sempre que você não está seguindo uma das técnicas que defendeu na impressão. E é aí
que reside o problema fundamental: não importa o quanto você pense em design de jogos ou
tente fazer tudo da melhor maneira possível, no final das contas, jogos de computador modernos
ainda são incrivelmente difíceis de criar. Certamente não pretendo ter todas as respostas, mas
minha esperança é que este livro torne as coisas um pouco mais fáceis, não apenas para mim,
mas para você também.
Ricardo Rouse III

Seattle, Washington
xix
Introdução
Minha lembrança mais antiga de jogar um jogo de computador foi quando me deparei com um
Space Invaders de meia altura em um pequeno restaurante mexicano na minha cidade natal. Eu
tinha talvez seis anos, e Space Invaders era certamente a coisa mais maravilhosa que eu já tinha
visto, pelo menos ao lado de LegoLand. Eu tinha ouvido falar de jogos de arcade, mas este foi o
primeiro que eu consegui jogar. Space Invaders, eu sabia, era melhor do que a televisão, porque
eu podia controlar a pequena nave na parte inferior da tela usando o joystick e atirar nos alienígenas
eu mesmo em vez de ver outra pessoa fazendo isso. Eu estava apaixonado. A ironia dessa história
é que, na época, não consegui compreender que tinha que colocar moedas no jogo para fazê-lo
funcionar. O jogo estava rodando no modo “atrair” como os jogos de arcade, e minha mente jovem
pensou que eu estava controlando o jogo com o joystick quando na verdade não estava controlando nada.
Mas a ideia ainda era alucinante.
Este livro é sobre o desenvolvimento de jogos de computador originais que esperamos ter o
mesmo efeito alucinante nos jogadores que Space Invaders teve no meu jovem cérebro. Este livro
trata desse processo de desenvolvimento do ponto de vista do designer de jogos.
Muitos livros foram escritos sobre a programação de jogos de computador, mas posso me lembrar
de minha frustração por não conseguir encontrar um livro como este quando eu era um aspirante
a designer de jogos. De certa forma, escrevi este livro para mim mesmo, para a pessoa que era há
uma década. Espero que outras pessoas interessadas em projetar jogos achem este livro
informativo. Na minha humilde opinião, é o designer de jogos que tem o papel mais interessante
na criação de um jogo de computador. É o design do jogo que dita a forma e o formato da
jogabilidade do jogo, e esse é o fator que diferencia nosso meio artístico de todos os outros.
O que é jogabilidade?
Eu ouço você perguntando: “Mas o que é jogabilidade?” Muitas pessoas pensam que sabem o que
é jogabilidade e, de fato, existem muitas definições razoáveis para isso. Mas tenho uma definição
que abrange todos os usos do termo que você encontrará neste livro. A jogabilidade é o componente
dos jogos de computador que não se encontra em nenhuma outra forma de arte: a interatividade.
A jogabilidade de um jogo é o grau e a natureza da interatividade que o jogo inclui, ou seja, como
os jogadores são capazes de interagir com o mundo do jogo e como esse mundo do jogo reage às
escolhas que os jogadores fazem. Em um jogo de ação como Centipede, a jogabilidade é mover a
nave atiradora pelo quadrante inferior da tela e atirar nos inimigos que atacam implacavelmente.
Em SimCity, a jogabilidade é traçar uma cidade e observar os cidadãos que passam a habitá-la.
Em Doom, a jogabilidade é rodar em um mundo 3D em alta velocidade e atirar em seus habitantes
extremamente hostis, juntando algumas chaves pelo caminho. Em San Francisco Rush, a
jogabilidade é guiar um carro por pistas implausíveis enquanto disputa posições com outros pilotos.
Em StarCraft, a jogabilidade é manobrar unidades ao redor de um mapa, encontrar recursos e
explorá-los, construir forças e, finalmente, enfrentar um combate de igual para igual.
xx
Introdução
inimigo equipado. E em Civilization, a jogabilidade é explorar o mundo, construir uma sociedade

do zero, descobrir novas tecnologias e interagir com os outros habitantes do mundo.
Embora alguns possam discordar de mim, a jogabilidade não inclui como o mundo do jogo é
representado graficamente ou qual mecanismo de jogo é usado para renderizar esse mundo. Nem
inclui o cenário ou enredo desse mundo de jogo. Essas considerações estéticas e de conteúdo
são elementos que os jogos de computador podem compartilhar com outras mídias; eles
certamente não são o que diferencia os jogos dessas outras mídias. A jogabilidade, lembre-se, é
o que torna nossa forma de arte única.
O que é design de jogos?

O que, então, é design de jogos? Tendo definido o que exatamente quero dizer quando me refiro
à jogabilidade, a noção de design do jogo é facilmente explicada: o design do jogo é o que
determina a forma da jogabilidade. O design do jogo determina quais escolhas os jogadores
poderão fazer no mundo do jogo e quais ramificações essas escolhas terão no resto do jogo. O
design do jogo determina quais critérios de vitória ou derrota o jogo pode incluir, como o usuário
poderá controlar o jogo e quais informações o jogo comunicará a ele, e estabelece o quão difícil
será o jogo. Em suma, o design do jogo determina cada detalhe de como a jogabilidade funcionará.
Quem é um designer de jogos?

A essa altura, deve ser óbvio o que um designer de jogos faz: ele determina qual é a natureza da
jogabilidade criando o design do jogo. Os termos “designer de jogos” e “design de jogos” têm sido
usados em uma variedade tão ampla de contextos por tanto tempo que seus significados se
tornaram diluídos e difíceis de definir. Alguns parecem se referir ao design de jogos como sinônimo
de desenvolvimento de jogos. Essas pessoas se referem a qualquer pessoa que trabalhe em um
jogo de computador, seja artista, programador ou produtor, como designer de jogos. Prefiro uma
definição mais específica, como esbocei acima: o game designer é a pessoa que projeta o jogo,
que assim estabelece a forma e a natureza da jogabilidade.
É importante observar algumas tarefas nas quais o designer de jogos pode estar envolvido.
O designer de jogos pode fazer alguns esboços conceituais ou criar alguns dos recursos de arte
usados no jogo, mas ele não precisa fazê-lo. Um designer de jogos pode escrever o script contendo
todos os diálogos falados pelos personagens do jogo, mas ele não precisa fazê-lo. Um designer
de jogos pode contribuir para a programação do jogo ou até mesmo ser o programador principal,
mas não é obrigado a fazê-lo. O game designer pode projetar parte ou todo o próprio mundo do
jogo, construindo os níveis do jogo (se o projeto em questão tiver níveis a serem construídos), mas
ele não precisa fazê-lo. O designer de jogos pode estar cuidando do projeto do ponto de vista de
gerenciamento e produção, observando atentamente os membros da equipe para ver se todos
estão executando suas tarefas de maneira eficaz e eficiente, mas ele não precisa fazê-lo. Tudo o
que alguém precisa fazer para ser justificadamente chamado de designer do jogo é estabelecer a
forma do jogo.
xxi
Introdução
jogabilidade. De fato, muitos designers de jogos realizam uma ampla variedade de tarefas em um
projeto, mas sua preocupação central deve sempre ser o design do jogo e a jogabilidade.
O que há neste livro?

Este livro contém uma variedade de informações sobre design de jogos, abrangendo tantos
aspectos quanto possível. Claro, nenhum livro pode ser o trabalho definitivo em uma forma de
arte particular. O que este livro certamente não é um livro sobre programação de jogos de computador.
Há uma grande quantidade de livros disponíveis para ensinar o leitor a programar e, como
discutirei mais adiante neste livro, saber programar pode ser um grande trunfo para o design de jogos.
No entanto, não é um componente necessário para projetar um jogo; muitos bons designers não
sabem programar.
Os capítulos deste livro estão divididos em três categorias. Primeiro estão os treze capítulos
principais, que discutem vários aspectos do desenvolvimento de um jogo de computador, desde
estabelecer o foco do jogo, documentar o design do jogo, estabelecer o modo de contar histórias
do jogo e testar o produto quase final. Esses capítulos discutem a teoria por trás do design de
jogos e o que um designer deve buscar para criar o melhor jogo possível. Os capítulos também
incluem discussões sobre a realidade do desenvolvimento de jogos, usando exemplos de minha
própria experiência, para aprofundar a prática real do design de jogos.
Há seis capítulos de análise incluídos neste livro, abrangendo seis excelentes jogos em seis
gêneros diferentes. Uma das habilidades mais importantes que um designer de jogos deve ter é a
capacidade de analisar os jogos que ele gosta para entender o que esses jogos fazem bem. Ao
entender esses outros jogos, o designer pode tentar replicar essas mesmas qualidades em seus
próprios projetos. Isso não quer dizer que bons designers de jogos simplesmente copiem o
trabalho de outros designers de jogos. Compreender as razões pelas quais outros jogos são bem-
sucedidos trará ao designer uma compreensão mais completa do design de jogos como um todo.
Todo designer de jogos deve pegar os jogos que considera mais atraentes e tentar examinar o
que os faz funcionar. Os exemplos que incluo neste livro, Centipede, Tetris, Loom, Myth: The
Fallen Lords, The Sims e Grand Theft Auto III, são todos jogos únicos. E embora um determinado
projeto em que você está trabalhando possa não ser semelhante a nenhum desses jogos, muito
pode ser aprendido analisando jogos de qualquer tipo.
Os designers de tiro em primeira pessoa tiveram grande sucesso em revitalizar seu gênero ao
olhar para jogos de aventura. Certamente, os designers de jogos de RPG aprenderam muito
recentemente com os designers de jogos de arcade. Grand Theft Auto III melhorou em relação
aos seus antecessores, tirando proveito de jogos de corrida. Combinar técnicas de outros gêneros
é a melhor maneira de avançar no gênero em que você está trabalhando e criar algo
verdadeiramente original.
Este livro também inclui um grupo de entrevistas com sete dos designers de jogos mais
respeitados da curta história da indústria que projetaram alguns dos melhores jogos já lançados.
São entrevistas longas que vão mais fundo do que as entrevistas curtas do tipo press kit que
encontramos na Internet ou na maioria das revistas.
Em cada entrevista o sujeito discute os melhores títulos de sua carreira e por que acredita que se
saíram tão bem. Os designers também falam longamente sobre suas próprias técnicas para
desenvolver jogos. Ao longo da minha própria carreira no desenvolvimento de jogos, eu
xxii
Introdução
Achei entrevistas com outros designers de jogos de computador extremamente úteis para aprender
como aperfeiçoar meu ofício. Há muitas informações a serem extraídas desses capítulos, idéias
que podem ajudar qualquer designer de jogos, independentemente de quão experiente ele possa
ser.
No final do livro você encontrará um glossário. Embora esteja longe de ser uma lista
completa da terminologia de design de jogos, ela cobre muitos dos termos mais esotéricos que
uso no livro, como um dos meus favoritos pessoais, “substituto”. Todo designer de jogos tem um
conjunto de jargões que usa para se referir a vários aspectos de seu ofício, e esse jargão
raramente é o mesmo de um designer para outro. Se nada mais, o glossário deve ajudá-lo a
entender meu próprio jargão. Por exemplo, ele lhe dirá a diferença entre jogabilidade e mecânica
de jogo. Além disso, os leitores que podem achar o conteúdo deste livro para assumir muito
conhecimento podem achar o glossário útil para descobrir o que é um jogo RTS e quais são os
dois significados diferentes para FPS. Muitas vezes, as discussões sobre design de jogos podem
se transformar em questões de semântica, sem que dois lados signifiquem exatamente a mesma
coisa quando se referem ao “motor” de um jogo. Espero que o glossário ajude os leitores a evitar
esse problema com este livro.
Para quem é este livro

Este livro é para qualquer pessoa que queira entender melhor o processo de desenvolvimento de
jogos de computador do ponto de vista estritamente do design de jogos. Como afirmei
anteriormente, existem muitos livros disponíveis para ensiná-lo a programar, ou como usar o
Photoshop e o 3D Studio MAX. Este livro não fará nenhuma dessas coisas. Em vez disso, ele se
concentra no tópico mais evasivo do design de jogos e em como você pode garantir que seu título
tenha a melhor jogabilidade possível. Embora a programação e a arte sólidas sejam centrais para
o sucesso de um jogo, nenhuma quantidade de gráficos chamativos ou codificação de ponta
compensará um design de jogo sem brilho. No final, é a jogabilidade que fará ou quebrará um projeto.
Escrevi este livro de forma a abranger projetos de diferentes escopos e tamanhos. Não
importa se o jogo em que você está trabalhando é destinado a lançamento comercial, se você
espera algum dia lançá-lo como shareware, ou se você está apenas fazendo um jogo para você e
seus amigos jogarem; este livro deve ser útil para um designer de jogos que trabalha em qualquer
uma dessas circunstâncias. Além disso, não importa se você está trabalhando no jogo com uma
grande equipe, com apenas alguns cúmplices, ou indo completamente sozinho. No livro, muitas
vezes faço referência à “equipe” do seu projeto. Quando me refiro a “sua equipe de programação”,
posso estar me referindo a uma equipe de dez programadores experientes comandando salários
enormes e ultrapassando os limites da tecnologia 3D em tempo real, ou posso estar me referindo
apenas a você, codificando todos os aspectos do jogo você mesmo. Quando me refiro a “sua
equipe de teste de jogo”, posso estar me referindo a uma equipe de teste experiente e totalmente
profissional de quinze pessoas que se orgulhará de dar ao seu jogo uma revisão completa, ou
posso estar me referindo a seus primos Bob e Judith que, como você, gosta de jogos e adoraria
jogar o que você fez. Bons jogos certamente nem sempre vêm das maiores equipes. Mesmo hoje,
quando orçamentos multimilionários são a norma, os melhores jogos ainda muitas vezes resultam
da visão e determinação de um único indivíduo, e ele nem sempre precisa se cercar de uma
equipe enorme para ver essa visão até a conclusão.
xxiii
Introdução
Muitos lugares neste livro fazem referência a você liderando o projeto no qual você está
trabalhando. Claro, nem todo designer pode estar na posição de liderança em todos os
projetos, e mesmo se você for o líder, muitas vezes você se encontrará sem a palavra final
absoluta sobre o que acontece no jogo. A este respeito, este livro é escrito a partir de um
ponto de vista um tanto idealista. Mas, independentemente de quanta autoridade você
realmente tem sobre a direção do projeto, o ponto importante é sempre saber o que você faria
com o projeto se pudesse fazer o que quisesse. Então você deve fazer campanha nessa
direção com as outras pessoas da equipe. Se você for persuasivo o suficiente e se estiver, de
fato, correto em seus instintos, terá uma boa chance de convencê-los a fazer do seu jeito. Os
projetos geralmente não são liderados por pessoas com mais antiguidade ou que têm o título
certo em seu cartão de visita; os projetos são liderados por pessoas que “aparecem” para a
tarefa, que se preocupam com seus projetos e estão comprometidas com eles, e que estão
dispostas a dedicar tempo e esforço para tornar o jogo o melhor possível.
A teoria e a prática
Cada meio tem uma voz única com a qual pode falar, e é responsabilidade do usuário de um
meio encontrar essa voz. Os jogos de computador têm uma voz que acredito firmemente ser
tão forte quanto a disponível em qualquer outra mídia. Os jogos de computador são uma
forma relativamente jovem quando comparados com a palavra impressa, a música, as artes
visuais ou o teatro, e acho que isso atualmente funciona contra a probabilidade de os jogos
de computador realmente encontrarem sua voz mais poderosa. Este livro é uma tentativa de
ajudar os leitores a encontrar essa voz em seus próprios projetos. Isso pode vir tanto na forma
mais teórica de questionar por que os jogadores jogam, mas também na forma totalmente
mais prática de como trabalhar de forma mais eficaz com os testadores. Para ter alguma
chance de produzir um grande jogo, o designer de jogos deve entender tanto os aspectos
teóricos quanto as necessidades práticas do design de jogos.
xxiv
Capítulo 1
O que os jogadores querem
“Mas quando penso mais sobre isso, a maior razão pela qual se tornou tão popular é
que o Sr. Tajiri, o principal desenvolvedor e criador de Pokémon, não iniciou este projeto
com um senso de negócios. Em outras palavras, ele não pretendia fazer algo que se
tornaria muito popular. Ele só queria fazer algo que ele queria jogar. Não havia nenhum
senso de negócios incluído, apenas seu amor envolvido na criação. De alguma forma,
o que ele queria criar para si mesmo foi apreciado por outros neste país e é
compartilhado por pessoas de outros países. ...E esse é o ponto: não fazer algo vender,
algo muito popular, mas amar algo, e fazer algo que nós, criadores, possamos amar. É
o sentimento central que devemos ter ao fazer jogos.”
— Shigeru Miyamoto, falando sobre a criação de Pokémon
fora de um jogo é uma questão que todos os designers de jogos devem considerar se quiserem
Pode parecer
fazer uma jogos.
grandes pergunta simples
Para demais
complicar paramais
ainda ser feita, mas determinar
as coisas, entender oo que
que os jogadores em
é agradável querem
uma experiência de jogo não é um conhecimento que pode ser ensinado; em algum nível, deve ser
um sentido inato que um designer possui. Os designers devem ter a capacidade de avaliar se algo
é divertido para eles, combinado com a capacidade de ouvir as opiniões dos outros. Frank Capra,
um dos diretores de cinema mais populares da era de ouro de Hollywood, costumava dizer que
estava simplesmente fazendo filmes que agradavam ao seu próprio gosto e que era uma sorte que
fossem apreciados por tantas outras pessoas. Da mesma forma, não se pode simplesmente olhar
para o problema de “o que os jogadores querem” puramente a partir de uma visão orientada para o mercado
1
2 Capítulo 1: O que os jogadores querem
ponto de vista e declarar: "Eu não entendo, mas se eles quiserem, eu vou dar a eles." Para fazer um
ótimo jogo, você deve primeiro achar divertido, e esperamos que isso possa ser usado para construir
algo que atraia os outros também. Mas no final, a faísca deve vir de dentro.
Os designers de jogos passam muito tempo se preocupando com o que os jogadores estão
procurando em um jogo de computador. O que eles podem colocar em seu jogo de computador que
não tenha sido feito antes e que irá excitar os jogadores? Muitas vezes, os designers de jogos estão
tão desprovidos de uma ideia do que será divertido e do que os jogadores querem que, em vez disso,
incluem apenas ideias de jogabilidade que foram tentadas antes, repetindo o que era popular entre os
jogadores no ano passado. Certamente, se os jogadores gostaram no ano passado, vão gostar este
ano. Mas é aí que está o problema. Os jogadores geralmente não querem comprar um jogo que seja
apenas um clone de outro jogo, um jogo “novo” que apenas oferece ideias antigas e não traz nada de original para a
No entanto, jogos de sucesso podem ser úteis, não para clonagem, mas para análise. Como designers
de jogos, podemos olhar para os jogos que foram lançados anteriormente, que gostamos nos últimos
anos, e tentar determinar um conjunto de diretrizes que expliquem o que nos levou a experimentar
esses jogos em primeiro lugar e por que eles manteve nosso interesse quando começamos a tocá-los.
Por que os jogadores jogam?

A primeira pergunta que devemos considerar é: por que os jogadores jogam? Por que eles escolhem
ligar o computador ou console e rodar o Halo em vez de visitar o museu de arte ou ir ver um filme? O
que há de único nos jogos de computador em relação a outras mídias de entretenimento humano? O
que os jogos oferecem que outras atividades não oferecem? É entendendo o que é atraente nos jogos
que outras mídias não oferecem que podemos tentar enfatizar as diferenças que separam nossa forma
de arte das outras. Para ter sucesso, nossos jogos precisam pegar essas diferenças e jogá-las,
explorando-as para tornar a melhor experiência de jogo possível.
Os jogadores querem um desafio Muitos

jogadores gostam de jogar porque oferecem um desafio. Isso fornece um dos principais fatores de
motivação para jogos caseiros para um jogador, onde as motivações sociais ou de direitos de se gabar
são menos problemáticas. Os jogos podem entreter os jogadores ao longo do tempo, de forma diferente
a cada vez que jogam, enquanto envolvem suas mentes de uma maneira totalmente diferente de um
livro, filme ou outra forma de arte. Da mesma forma que alguém pode brincar com um cubo de Rubik
ou um quebra-cabeça de aço “remover o anel”, os jogos forçam os jogadores a pensar ativamente, a
tentar soluções diferentes para os problemas, a entender um determinado mecanismo de jogo.
Quando uma pessoa enfrenta um desafio e depois o supera, essa pessoa aprendeu alguma coisa.
Não importa se esse desafio está em um livro de matemática ou em um jogo de computador. Jogos
desafiadores podem ser experiências de aprendizado. Os jogadores aprenderão com os jogos, mesmo
que esse aprendizado seja limitado ao contexto do jogo, como navegar pela floresta, sobreviver a uma
batalha particularmente peluda ou convencer o duque de que suas intenções com sua filha são
honrosas. Nos melhores jogos, os jogadores aprenderão lições por meio de jogabilidade que podem
ser aplicadas a outros aspectos de sua vida, mesmo que não percebam. Isso pode significar que eles
podem aplicar métodos de resolução de problemas aos seus
Capítulo 1: O que os jogadores querem 3
trabalham, usam suas habilidades espaciais aprimoradas para organizar melhor seus móveis, ou
talvez até aprendam mais empatia por meio de role-playing. Muitos jogadores prosperam e anseiam
pelos desafios que os jogos oferecem e são enriquecidos pelo aprendizado que se segue.
Os jogadores querem socializar Tenho

um amigo que afirma que os jogos são anti-sociais. Isso é, obviamente, absurdo, já que quase
todos os jogos que não são de computador exigem um grupo social para funcionar. Os jogos
surgiram como uma atividade comunitária há muitos milênios atrás do desejo de ter uma atividade
desafiadora na qual um grupo de amigos e familiares pudesse se envolver. Os designers de jogos
de computador precisam lembrar que a origem dos jogos está ligada a uma experiência social e
que esse componente comum é central para seu apelo.
Para a maioria das pessoas, a principal razão pela qual eles jogam é ter uma experiência
social com seus amigos ou familiares. Não estou falando de jogos de computador aqui, mas sim de
jogos de tabuleiro e cartas como xadrez, Monopólio, bridge, Scrabble, Diplomacia ou The Settlers
of Catan. As pessoas gostam de jogar esses jogos porque gostam de passar tempo com seus
amigos e querem se envolver em uma atividade compartilhada que seja mais social do que ir ao
cinema ou assistir TV. É verdade que muitas pessoas também gostam de jogar jogos de cartas de
paciência, mas há muito mais jogos para vários jogadores do que para um jogador. Isso ocorre
porque as pessoas desfrutam de uma experiência de jogo social.
Mas como isso se aplica aos jogos de computador? Se considerarmos todos os jogos de
computador já criados, a maioria deles são apenas experiências para um jogador. Mas é claro que
existem muitos jogos multijogador, que vão desde os “death-matches” encontrados em Doom e sua
legião de imitadores, ao clássico jogo MULE de wheeling and dealing, aos mundos persistentes
encontrados em MUDs (Multi User Dungeons) ou seus equivalentes comerciais, jogos massivamente
para vários jogadores, como Ultima Online e EverQuest. É revelador sobre a popularidade dos
jogos multijogador que desde o início dos jogos havia jogos multijogador, variando de Pong a alguns
dos primeiros jogos desenvolvidos em mainframes universitários que eventualmente evoluíram para
MUDs.
Muitos jogos multiplayer no estilo death-match são basicamente adaptações de jogos single
player em encarnações multiplayer, como Doom, Half-Life e Halo.
Esses jogos normalmente fornecem um jogo para um jogador, além de um jogo para vários
jogadores, ambos jogados com quase o mesmo conjunto de regras e mecânicas de jogo. Mas
mesmo nesses jogos de um jogador que se tornaram vários jogadores, os jogadores gostam de
socializar enquanto jogam. Qualquer um que já jogou um desses jogos em uma LAN em uma sala
com um monte de amigos pode testemunhar isso. Esses festivais de LAN geralmente são ricos em
conversas, enquanto os jogadores gritam uns para os outros, se gabando de seu “frag” mais recente
ou proclamando o quão perto eles chegaram de serem mortos. Jogos como Unreal Tournament
também podem ser jogados pela Internet, onde a experiência é um pouco menos social, pois os
jogadores podem estar a quilômetros de distância e, portanto, só podem se comunicar pelo
computador. De fato, muitos entusiastas de death-match ou Counter-Strike são conhecidos por usar
seus sistemas de telefone de escritório para permitir que jogadores que não estão no mesmo prédio
ou mesmo no mesmo estado conversem livremente entre si enquanto jogam. Aqueles que não
estão tão bem equipados ainda tentam se comunicar digitando mensagens no computador.
Infelizmente, a natureza de alta intensidade e ação rápida desses jogos não deixa aos jogadores
muito tempo para digitar mensagens para seus oponentes, se eles esperam sobreviver por muito tempo. Ma
Os jogos
multijogador no
estilo death-match
são adaptações de
experiências de tiro
para um jogador.
Halo vem com modos
single-player e multi-player.
os jogos ainda fornecem a funcionalidade de bate-papo, e os jogadores, quando estão em um

canto seguro, depois de morrerem, ou entre os jogos, podem enviar mensagens de conversação
uns aos outros. Em pontos mais agitados do jogo, as mensagens são curtas e digitadas
rapidamente, consistindo em apenas algumas letras. O fato de os jogadores ainda tentarem
conversar uns com os outros nesses jogos de alta velocidade é uma prova do desejo dos jogadores de socializ
Uma categoria separada de jogos multijogador é o que veio a ser chamado de “universo de
tenda persistente” ou jogos “massivamente multijogador”. Esses jogos tendem a ser mais no estilo
de RPGs, onde os jogadores vagam por “mundos virtuais” e encontram e interagem com os outros
personagens desses mundos, personagens que são controlados por outros jogadores. Esses
jogos tendem a ser jogados em grandes redes, como a Internet, em vez de LANs, e, como
resultado, os jogadores só socializam uns com os outros através do que digitam no computador.
Como esses jogos são consideravelmente mais lentos do que os jogos de death-match, há uma
oportunidade muito maior para os jogadores conversarem uns com os outros enquanto jogam. Os
MUDs foram a primeira encarnação popular desse estilo de jogo e foram jogados principalmente
por estudantes universitários a partir do final dos anos 80. Na época, esses alunos eram o principal
grupo de pessoas com amplo tempo livre que tinha acesso à Internet. Esses jogos são apenas de
texto e fornecem a seus jogadores missões a serem cumpridas principalmente em cenários de
fantasia. As missões, no entanto, ficam em segundo plano na socialização e no role-playing, com
os jogadores passando a maior parte do tempo conversando com outros jogadores. Muitas
pessoas são atraídas para jogar esses jogos como uma forma de interagir com seus amigos,
apesar de esses amigos serem pessoas que conheceram online e que nunca viram pessoalmente.
De fato, os mundos persistentes, os MUDs em particular, atraem uma legião de jogadores que
não estão interessados em jogar nenhum jogo de computador para um jogador. Essas pessoas
jogam jogos para conhecer e conversar com outras pessoas. Os jogos são apenas uma atividade
atraente em que essas pessoas podem se envolver enquanto socializam.
À medida que os jogos para vários jogadores se tornaram cada vez mais comuns, muitos
desenvolvedores de jogos foram rápidos em apontar suas vantagens em termos de IA competitiva.
Os oponentes humanos são muito mais imprevisíveis e desafiadores do que qualquer IA que possa
ser razoavelmente criada para a maioria dos jogos. Isso, eles sugeriram, é o motivo pelo qual as
pessoas são atraídas por jogos multijogador. Embora isso possa ser verdade, a maior vantagem
desses jogos multijogador é que eles transformam os jogos de computador em experiências
verdadeiramente sociais, o que é um dos maiores fatores de motivação para as pessoas jogarem.
Os jogadores querem uma experiência solitária dinâmica

Talvez eu tenha confundido o leitor dizendo primeiro que os jogadores querem se socializar
e depois sugerindo que os jogadores querem uma experiência solitária. É claro que os
dois não acontecem ao mesmo tempo; alguns jogadores estão procurando uma experiência
social, enquanto outros estão procurando algo dinâmico em que possam se envolver sozinhos.
Às vezes os amigos não estão disponíveis para jogar, ou os jogadores estão cansados de seus
amigos, ou simplesmente estão cansados de ter que conversar com outras pessoas o tempo todo.
Semelhante à diferença entre ir ao cinema com um público e alugar um vídeo sozinho em casa, a
natureza anti-social dos jogos single-player atrai muitas pessoas que já estão fartas dos outros
membros da raça humana.
Mas os jogos são distintos de outras experiências solitárias, como ler um livro ou assistir a um
vídeo, pois fornecem aos jogadores algo com o qual interagir, uma experiência que reage a eles
como um humano reagiria, ou pelo menos de maneira semelhante às reações de um humano. Os
jogadores estão sempre no controle e podem começar e parar de jogar a qualquer momento. Assim,
o jogo de computador “finge” a parte interessante da interação humana sem todos os aborrecimentos
potenciais. Desta forma, as pessoas podem recorrer aos jogos de computador para uma experiência
dinâmica e interativa, mas não social.
Os jogadores querem o direito de se gabar

Especialmente em jogos multijogador, os jogadores jogam para ganhar respeito. Ser capaz de
destruir todos os seus amigos no Unreal Tournament irá forçá-los a ter um respeito relutante por
você: “Bob não é muito bom nas aulas de álgebra, mas ele com certeza pode me aniquilar em uma
partida mortal.” Mesmo em jogos single-player, os jogadores conversam com seus amigos sobre
como terminaram um jogo ou sobre como são bons em outro. Os jogadores vão se gabar de como
jogaram o jogo inteiro na dificuldade mais difícil em apenas algumas horas. Se olharmos para os
jogos de arcade antigos e novos, a tabela de alta pontuação e a capacidade de inserir o nome no
jogo, mesmo que apenas três letras, fornece um tremendo incentivo para as pessoas jogarem um
jogo repetidamente. Os jogadores que podem não ter muito do que se gabar em suas vidas comuns,
que podem não ser muito coordenados fisicamente nos esportes ou eruditos o suficiente para se
sair bem na escola, podem ir ao fliperama e mostrar a todos os seus amigos suas iniciais na
Centopeia jogos. Os fóruns de jogos estão cheios de pessoas se gabando de como venceram o
novo jogo X em apenas cinco horas, e depois se orgulham de dar conselhos para aqueles que não
chegaram tão longe. Mesmo sem contar a ninguém, os jogadores podem sentir uma tremenda
sensação de auto-satisfação quando vencem um jogo específico. Quando os jogadores são
vitoriosos em um jogo desafiador, eles percebem que podem fazer algo bem, provavelmente melhor
do que a maioria das pessoas, o que os faz se sentir melhor consigo mesmos.
Os jogadores querem uma experiência emocional Assim

como acontece com outras formas de entretenimento, os jogadores podem estar buscando alguma
forma de recompensa emocional quando jogam um jogo de computador. Isso pode ser tão simples
quanto a adrenalina e a tensão de um jogo de ação rápida como Doom. Pode ser a grande
satisfação de ter construído uma grande metrópole em SimCity. Ou pode ser consideravelmente
mais complexo, como o sentimento de perda dos jogadores quando seu companheiro robô
amigável se sacrifica por eles em Planetfall de Steve Meretzky. As emoções que os jogos são
capazes de evocar nos jogadores são muito mais fortes do que as que podem ser experimentadas
em outras mídias onde a experiência é menos imersiva e consideravelmente menos pessoal.
Infelizmente, os alcances emocionais de muitos jogos são limitados a excitação/tensão durante
um conflito, desespero por repetidos fracassos em uma determinada tarefa e, em seguida, euforia
e sensação de realização quando os jogadores finalmente conseguem. Pode parecer estranho
que os jogadores joguem um jogo para se sentirem desesperados, mas muitas pessoas gostam
de assistir a peças que são tragédias ou filmes que têm finais tristes, ou ouvir música que é
totalmente deprimente. As pessoas querem sentir algo quando interagem com a arte, e isso não
precisa necessariamente ser um sentimento positivo e feliz. Talvez o senso de catarse que as
pessoas obtêm com essas obras faça com que valha a pena experimentá-las. Muitos jogos de
arcade clássicos, como Centipede ou Space Invaders, são invencíveis. Não importa o que os
jogadores façam, até mesmo o jogo os vencerá. Esses jogos são, em certo sentido, lições de
derrota – tragédias toda vez que os jogadores os jogam. No entanto, os jogadores continuam bombeando em s
É por isso que os sentimentos de desesperança dos jogadores quando um jogo os supera repetidamente
não devem ser ignorados. Os jogadores estão sentindo algo, e no mais alto nível esse é o objetivo de
toda arte.
O alcance emocional não é algo que os jogos de computador exploraram tanto quanto
poderiam. O exemplo de Planetfall que citei acima é um dos poucos exemplos em jogos de
computador de jogadores se apegando a um personagem em um jogo, apenas para matá-lo mais
tarde. Muitos desenvolvedores têm medo de tornar um jogo muito triste. Mas no caso de Planetfall,
a trágica reviravolta da história desse jogo foi explorada por todo o pathos que valeu a pena pelo
designer Steve Meretzky. É um momento de tragédia que ficou na memória de muitos jogadores.
Os designers de jogos seriam sábios se concentrassem em expandir a experiência emocional em
jogos além da emoção e da realização, para um território emocional mais inexplorado e inexplorado.
Os jogadores querem explorar Uma

das principais forças motivadoras que impulsionam os jogadores através de muitos jogos baseados
em níveis é o desejo de explorar novos espaços e ver novos ambientes. Qualquer um que tenha
jogado um jogo baseado em progressão como Super Mario 64 ou Morrowind conhece a sensação
de chegar a um nível novo e diferente e querer apenas olhar ao redor por alguns momentos antes
de assumir os objetivos em mãos. E a exploração do jogo não se limita à exploração espacial. Há
a exploração de diferentes escolhas estratégicas em um jogo como Civilization, diferentes tipos
de recursos para manipular e combinar em um jogo como Magic: The Gathering e a exploração
das personalidades dos personagens que você conhece em RPGs como Wasteland ou Fallout .
Embora a exploração não seja completamente parte integrante de uma experiência de jogo pura,
a investigação de um mundo fantástico em seus próprios termos pode ser uma experiência rica
na qual os jogos se destacam de uma maneira que nenhuma outra mídia pode.
Os jogadores querem fantasiar Um

componente importante da popularidade das formas de arte de contar histórias é o elemento de fantasia.
Quer se considere romances, filmes ou histórias em quadrinhos, muitas pessoas experimentam essas
obras para “fugir” de suas próprias vidas “mundanas” e escapar para um mundo completamente
diferente, cheio de personagens que se envolvem em atividades emocionantes e interessantes,
viagens para locais exóticos e conhecer outras pessoas fascinantes. Certamente nem todos os
trabalhos de narrativa retratam protagonistas emocionantes e glamorosos, mas certamente há um
grande segmento de trabalhos rotulados como “escapistas”. Alguns críticos ridicularizam essas obras
de arte escapistas e, de fato, muitos livros, filmes e quadrinhos muito bons lidam com cenários e
tópicos mais realistas com grande efeito. O fato é, no entanto, que muitas pessoas querem ser
transportadas para um mundo mais glamoroso que o seu.
Os jogos de computador, então, têm o potencial de ser uma forma ainda mais imersiva de
escapismo. Nos jogos, os jogadores têm a chance de realmente ser alguém mais emocionante, de
controlar um aventureiro de ficção pulp, um espadachim ousado ou um herói de ópera espacial.
Enquanto em livros ou filmes o público pode apenas assistir enquanto os personagens levam vidas
emocionantes, em um jogo de computador bem projetado, os jogadores terão a chance de viver essas
vidas. Melhor ainda, essas vidas de fantasia não são sobrecarregadas com os eventos mundanos da
vida. Na maioria dos jogos, os jogadores não precisam se preocupar em comer, dormir um pouco ou
ir ao banheiro. Assim, um jogo pode criar uma vida de fantasia sem os detalhes tediosos. E, mais
importante, o nível de imersão na fantasia é elevado em relação a outras formas de arte por causa da
natureza interativa dos jogos.
Outra parte do elemento de realização de fantasia dos jogos de computador é permitir que os
jogadores se envolvam em comportamentos socialmente inaceitáveis em um ambiente seguro. Muitos
jogos populares permitiram aos jogadores fingir que são criminosos ou assassinos. Driver é um bom
exemplo disso. Embora a história de fundo explique que o personagem do jogador está na verdade
interpretando um policial disfarçado, os jogadores fingem que são criminosos que devem fugir da
polícia em elaboradas perseguições de carro. Há uma emoção diabólica em ultrapassar os carros da
polícia, especialmente para quem já foi parado pela polícia. Embora a maioria dos jogadores nunca
consideraria participar de perseguições de carro na vida real, há algo tentador e atraente em se
envolver em atividades tabus. O enorme sucesso popular da série Grand Theft Auto é outra prova do
desejo dos jogadores de quebrar as regras da sociedade durante o jogo. Os jogos de computador
fornecem um bom meio para os jogadores explorarem os lados de sua personalidade que mantêm
submersos em suas vidas diárias.
Os jogadores também podem fantasiar sobre eventos da história. Se o jogador pudesse ter sido
Napoleão, Waterloo teria sido diferente? Se o jogador fosse um barão ferroviário no século XX, ele
seria capaz de criar um poderoso império financeiro?
Toda uma linha de jogos históricos, de jogos de guerra a simulações econômicas, permite que os
jogadores explorem eventos na história e vejam como fazer escolhas diferentes daquelas feitas pelas
figuras históricas envolvidas resultará em resultados totalmente diferentes. Enquanto muitas pessoas
passam o tempo pensando no passado, imaginando como os eventos poderiam ter acontecido de
forma diferente se decisões alternativas tivessem sido tomadas, os jogos podem dar aos jogadores a
chance de realmente descobrir como a história poderia ter sido diferente.
Mesmo sem os elementos de excitação e glamour, mesmo que a vida de outra pessoa não seja
tão excitante, pode ser interessante passar o tempo como essa pessoa. Bons jogos de computador
podem fornecer aos jogadores a oportunidade de ver
o mundo através dos olhos de outra pessoa. Como milhões de jogadores podem atestar, é divertido
encenar e é divertido fantasiar.
Os Jogadores Querem Interagir No

início desta discussão sobre o que os jogadores querem, sugeri que era importante criar uma
experiência que os jogadores escolhessem em vez de uma das muitas outras opções de
entretenimento apresentadas a eles, como assistir televisão, ler um livro , ou ir a um concerto.
O único fio comum que atravessa todos os “desejos” que mencionei acima é o que nossa
forma de arte pode fazer melhor do que qualquer outra: fornecer uma experiência interativa.
Embora possamos ter inveja do orçamento de efeitos especiais de um filme, da capacidade
de um romance de contar uma narrativa envolvente ou do poder emotivo de uma grande peça
musical, nenhuma outra forma permite que o público seja a força orientadora da experiência
que está tendo. . Os jogos encontraram seus maiores sucessos quando aproveitaram a
natureza interativa da experiência e forneceram ao nosso público algo que eles não podem
obter em nenhum outro lugar. Os designers de jogos precisam ter isso em mente
constantemente enquanto desenvolvem seus jogos, se quiserem ter alguma chance de ganhar a atenção
O que os jogadores esperam?

Uma vez que os jogadores decidiram que querem jogar um determinado jogo por causa de um
fator motivador ou outro, eles terão expectativas para o jogo em si. Além do jogo não travar e
parecer razoavelmente bonito, os jogadores têm certas expectativas de jogabilidade e, se elas não
forem atendidas, logo ficarão frustrados e encontrarão outro jogo para jogar.
É trabalho do designer de jogos garantir que o jogo atenda a essas expectativas. De fato, a
frustração do jogador é o inimigo de todo designer de jogos, e é importante que os designers de
jogos façam todo o possível para eliminá-la. Então, uma vez que a jogabilidade começa, como os
designers de jogos minimizam a frustração do jogador? Exatamente o que os jogadores esperam?
Os jogadores esperam um mundo consistente À

medida que os jogadores jogam, eles entendem quais ações podem realizar no mundo e
quais resultados essas ações produzirão. Poucas coisas são mais frustrantes do que quando
os jogadores antecipam certo resultado de uma ação e então o jogo, sem nenhuma razão
perceptível, produz um resultado diferente. Pior ainda é quando as consequências das ações
dos jogadores são tão imprevisíveis que os jogadores não conseguem estabelecer qualquer
tipo de expectativa. Não ter nenhuma expectativa do que acontecerá se uma determinada
manobra for tentada apenas frustrará e confundirá os jogadores, que logo encontrarão um
jogo diferente e mais consistente para jogar. É a consistência das ações e seus resultados
que devem ser mantidos, pois um mundo imprevisível é frustrante para se viver.
Os jogos de luta são um exemplo particularmente apropriado da importância de prever os
resultados das ações. Os jogadores não querem que uma manobra funcione algumas vezes e
falhe outras vezes, sem uma razão aparente para os diferentes resultados. Por exemplo, em Soul
Calibur, se os jogadores errarem um ataque, deve ser porque seu oponente pulou, bloqueou,
estava muito longe ou algum outro motivo que os jogadores possam perceber. É importante
enfatizar a percepção dos jogadores sobre o motivo do fracasso da jogada. Pode ser que a lógica
interna do jogo, neste caso o sistema de colisão, saiba por que o ataque falhou, mas é tão ruim
quanto não ter razão se os jogadores não puderem reconhecer facilmente por que
a manobra falhou. Além disso, se apenas jogadores experientes puderem entender por que sua
ação falhou, muitos novatos ficarão frustrados ao serem derrotados sem motivo que possam
entender. Se um golpe de espada falhar em uma situação que se assemelhe a outra situação em
que o mesmo golpe foi bem-sucedido, os jogadores levantarão as mãos em frustração.
Jogos de pinball são outro exemplo interessante. Claro, um jogo de pinball é um mundo de
jogo completamente previsível, uma vez que é baseado na física do mundo real. Jogadores
experientes de pinball sabem disso e usarão isso a seu favor. Mas surge um problema com os novatos.
Jogadores inexperientes muitas vezes não conseguem ver o que “fizeram de errado” quando a
bola vai direto entre suas nadadeiras ou rola por uma das calhas laterais. Esses jogadores
amaldiçoam o jogo de pinball como um “jogo de sorte” e não querem mais jogar. Claro, o fato de
que jogadores de diferentes níveis de habilidade terão níveis radicalmente diferentes de sucesso
em um determinado jogo de pinball prova que não é apenas um jogo de sorte. Mas apenas
aqueles jogadores que permanecem no jogo através de inúmeras falhas iniciais descobrirão isso.
Não estou sugerindo que os jogos de pinball devam ser abandonados ou radicalmente
simplificados, mas uma de suas deficiências é que alienam novos jogadores que não conseguem
ver as conexões entre suas ações e o resultado do jogo.
Os jogadores esperam entender os limites do mundo do jogo Ao jogar um

jogo, os jogadores querem entender quais ações são possíveis e quais não são. Eles
não precisam ver imediatamente quais ações são necessárias para uma determinada
situação, mas devem entender quais ações são possíveis de realizar e quais estão
fora do escopo do espaço de jogo do jogo.
Em Doom II,
o jogador não espera
poder iniciar uma
conversa com os
monstros que está
atacando.
Por exemplo, em Doom, os jogadores intuitivamente descobrirão que não serão capazes de
manter uma discussão com os demônios que estão lutando. Os jogadores nem vão querer iniciar
uma conversa com um demônio durante a qual eles sugerem a rendição como o melhor curso de
ação. Os jogadores entendem que essa discussão interpessoal está fora do escopo do jogo.
Suponha que Doom tenha incluído um monstro no final do jogo, um
inimigo que só poderia ser derrotado se os jogadores fossem amigáveis com ele, conquistando-o
com sua conversa espirituosa. Os jogadores ficariam frustrados, pois entenderam, ao jogar os
níveis que levaram a esse nível, que em Doom tudo o que é necessário para a vitória é explodir
tudo o que se move, evitando ser atingido. Falar está completamente fora do escopo do jogo.
Claro, um monstro tagarela em Doom é um exemplo extremo de um jogo com limites

imprevisíveis, mas muitos jogos quebram esse princípio de design. Esses jogos fazem com que os
jogadores executem ações e completem níveis usando um certo tipo de mecanismo de jogo e,
posteriormente, insiram quebra-cabeças que só podem ser resolvidos usando um mecanismo
totalmente novo. O problema é que os jogadores foram ensinados a jogar de uma certa maneira e,
de repente, o jogo exige que os jogadores façam algo completamente diferente. Uma vez que os
jogadores entendem todos os mecanismos de jogabilidade que um jogo usa, eles não querem que
mecanismos novos e não intuitivos sejam introduzidos aleatoriamente.
Os jogadores esperam que soluções razoáveis funcionem Uma

vez que os jogadores passaram algum tempo jogando, eles passam a entender os limites
do mundo do jogo. Eles resolveram vários quebra-cabeças e viram que tipos de soluções
valerão a pena. Mais tarde no jogo, então, quando confrontados com um novo quebra-
cabeça, os jogadores verão o que consideram uma solução perfeitamente razoável. Se
eles tentarem essa solução e não funcionar sem uma boa razão, eles ficarão frustrados e
se sentirão enganados pelo jogo.
Esse tipo de dificuldade no design de jogos é particularmente verdadeiro em jogos que tentam
modelar o mundo real em algum grau. No mundo real, quase sempre existem várias maneiras de
atingir um determinado objetivo. Portanto, um jogo de computador ambientado no mundo real
também deve tentar permitir que soluções razoáveis e lógicas para um problema resultem em
sucesso. É claro que um designer sempre fornece pelo menos uma solução para um quebra-
cabeça, e essa solução pode ser perfeitamente razoável. Mas pode haver outras soluções
igualmente razoáveis e, a menos que o designer garanta que essas soluções funcionem bem, os
jogadores descobrirão e tentarão essas soluções alternativas que não funcionam e ficarão irritados
quando não funcionarem. É tarefa do designer de jogos antecipar o que os jogadores tentarão
fazer no mundo do jogo e, em seguida, certificar-se de que algo razoável aconteça quando os
jogadores tentarem essa ação.
Jogadores Esperam Direção Bons

jogos são sobre deixar os jogadores fazerem o que quiserem, até certo ponto. Os
jogadores querem criar suas próprias histórias de sucesso, seus próprios métodos para
derrotar o jogo, algo que seja exclusivamente deles. Mas, ao mesmo tempo, os jogadores
precisam ter alguma ideia do que devem realizar neste jogo. Não ter direção é muito
parecido com a vida real, e os jogadores já têm uma vida real. Como discuti, muitos
jogadores provavelmente estão jogando o jogo para fugir de suas vidas reais, para
fantasiar e escapar. Eles geralmente não jogam para simular a vida real em seu computador.
Assim, os jogadores querem ter alguma ideia de qual é o seu objetivo e receber algumas
sugestões de como podem atingir esse objetivo. Com um objetivo, mas sem ideia de como alcançá-
lo, os jogadores inevitavelmente se debaterão, tentarão tudo o que puderem pensar e ficarão
frustrados quando as manobras que tentarem não os aproximarem de seu objetivo. De
Claro, sem uma idéia de qual é seu objetivo, os jogadores são deixados vagando sem rumo, talvez
apreciando o cenário e maravilhando-se com o mundo do jogo imersivo. No entanto, sem algo para
fazer nesse mundo de jogo, ele falhou como jogo. Se os jogadores não sabem qual é o seu
objetivo, o objetivo pode também não existir.
O SimCity 3000 é o
terceiro de uma série de
“brinquedos de software” de
simulação de cidades, que
permitem aos usuários jogar
sem lhes dar um objetivo específico.
O exemplo clássico do jogo sem gols é SimCity. Na verdade, Will Wright, o criador do jogo, o
chama de “brinquedo de software” em vez de um jogo. SimCity é como um brinquedo com o qual
os jogadores podem fazer o que quiserem, sem nunca serem informados explicitamente de que
falharam ou tiveram sucesso. De certa forma, SimCity é como um conjunto de Legos, onde os
jogadores podem construir o que quiserem apenas pela emoção da criação. O truque, no entanto,
é que SimCity é um simulador de cidade, no qual os jogadores podem configurar uma cidade como
quiserem. Mas como o jogo simula a realidade (construir e administrar uma cidade), e os jogadores
sabem o que é considerado “sucesso” na realidade (uma cidade em expansão cheia de estádios
encantadores, bibliotecas palacianas e cidadãos felizes), eles naturalmente tenderão a impor suas
próprias regras para o sucesso no jogo. Eles se esforçarão para tornar sua ideia de cidade perfeita
e manter seus cidadãos felizes e sua economia dinâmica. De forma sutil, os jogadores são
direcionados por sua própria experiência com a realidade. Se SimCity fosse uma simulação de um
sistema que os jogadores não conheciam, certamente teria sido menos popular. De fato, os jogos
de Wright que são baseados em conceitos com os quais os usuários médios estão consideravelmente
menos familiarizados (como SimAnt e especialmente SimEarth) encontraram um sucesso
consideravelmente menos popular. Embora SimCity não tenha um objetivo explicitamente, a própria
natureza do jogo e sua base em uma realidade amplamente compreendida incentiva os jogadores
a criar seus próprios objetivos. E assim, o que começa como um brinquedo torna-se um jogo, e
assim os jogadores são compelidos a continuar jogando.
Os jogadores esperam realizar uma tarefa de forma incremental Uma vez

que os jogadores entendem qual é seu objetivo no mundo do jogo, eles gostam de saber que
estão no caminho certo para atingir esse objetivo. A melhor maneira de fazer isso é fornecer
vários sub-objetivos ao longo do caminho, que são comunicados aos jogadores da mesma forma que
claramente como o objetivo principal. Os jogadores são recompensados por atingir esses sub-objetivos
assim como são para o objetivo principal, mas com uma recompensa proporcionalmente menor. É claro que
se pode levar isso a qualquer nível de detalhe, com os sub-objetivos tendo sub-sub-objetivos e assim por
diante, tanto quanto for necessário para indicar aos jogadores que eles estão no caminho certo.
Claro, nem todo objetivo precisa ser comunicado aos jogadores via texto. Por exemplo, em um jogo
de tiro baseado em história como Call of Duty, existem macro-objetivos que são comunicados via texto aos
jogadores na tela de “objetivos da missão”. Há uma média de quatro objetivos em qualquer nível. Além
disso, porém, o jogo está repleto de sub-objetivos (como “limpar os ninhos de metralhadoras”) que os
jogadores intuitivamente descobrem ao longo do caminho. Para atingir esses objetivos, os jogadores são
recompensados pelo diálogo de congratulações de seus companheiros soldados, a saúde e a munição que
poderão coletar dos soldados alemães caídos e a capacidade de acessar uma nova área do nível. Se
levarmos a um nível verdadeiramente micro, cada inimigo que os jogadores devem matar pode ser
considerado um mini-objetivo com recompensas tangíveis, como ver o inimigo cair morto, o fato de ele parar
de ser uma ameaça para os jogadores e o poder dos jogadores. capacidade de coletar seu armamento.
Jogos de plataforma, como Ratchet & Clank , são particularmente bons em fornecer micro-objetivos
incrementais, com todos os milhares de parafusos que os jogadores podem pegar ao longo do jogo, cada
um ajudando-os um pouco em direção ao objetivo maior de comprar a super arma para usar contra o inimigo
gigante. Todos os grandes jogos de plataforma usam essas recompensas incrementais para puxar os
jogadores através de seus níveis.
Sem fornecer feedback desse tipo (por menor que seja), especialmente se os passos necessários para
obter um objetivo forem particularmente longos e complicados, os jogadores podem estar no caminho certo
e não perceber isso. Quando não há reforço positivo para mantê-los nessa pista, é provável que os
jogadores fiquem frustrados e tentem outra coisa. E quando eles não conseguem descobrir a solução para
um obstáculo em particular, eles ficam frustrados, param de jogar e contam a todos os seus amigos o tempo
miserável que eles tiveram jogando o seu jogo.
Os jogadores esperam ser imersos Um

diretor de um musical que eu já participei ficaria furioso quando atores esperando
nos bastidores esbarravam nas cortinas. Ela sugeriu que, uma vez que o público
veja as cortinas se movendo, sua concentração é tirada dos atores no palco e sua
suspensão de descrença é quebrada. Eles são lembrados de que é apenas uma
peça que estão assistindo, nada real, e que há pessoas empurrando as cortinas que
cercam toda essa farsa. Talvez exagerando um pouco, esse diretor sugeriu que toda
a Broadway entraria em colapso se as cortinas fossem vistas tremendo.
Mas ela tinha um ponto, e é um ponto que pode ser aplicado diretamente aos jogos de computador.
Uma vez que os jogadores entram em um jogo, eles estão progredindo através de vários desafios, eles têm
uma boa compreensão dos controles do jogo e estão interpretando uma fantasia.
Eles se esqueceram de que estão jogando um jogo, assim como um público de cinema pode perceber que
está em um teatro ou o leitor de um livro pode ficar completamente varrido pela vida dos personagens da
história. Comumente referido como a “suspensão da descrença”, este é o ponto em que uma obra de arte
pode ser mais afetada pelo público. Uma vez que sua descrença é suspensa, os jogadores não querem ser
tirados de sua experiência. Para começar, um jogo nunca deve travar, pois essa seria a interrupção mais
chocante possível. Além disso, a menor falha no jogo pode tirar os jogadores imediatamente
sua imersão em transe. Se um personagem que deveria estar andando no chão começar a andar
no ar sem motivo reconhecível, os jogadores perceberão que é um bug e sua suspensão de
descrença será perdida. Se os jogadores chegarem a um quebra-cabeça, descobrirem uma
solução perfeitamente razoável para ele, e essa solução não funcionar, os jogadores serão
novamente lembrados de que estão “apenas” jogando um jogo de computador. Se a GUI do jogo
não for projetada para ser fácil de ler, transparente e estilisticamente consistente com o resto da
arte do mundo do jogo, ela se destacará e arruinará sua imersão. Todas essas armadilhas e
menos outras prejudicam a sensação de imersão dos jogadores, e quanto mais os jogadores são
rudemente despertados de sua fantasia no mundo do jogo, mais difícil é re-mergulhá-los nele.
Lembre-se que muitos jogadores querem jogar para realizar fantasias. É muito difícil realizar uma
fantasia quando as idiossincrasias do jogo continuam lembrando aos jogadores que é apenas um
jogo.
Apesar de toda a sua

fama, Mario não tem
uma personalidade
muito distinta. Ele é
retratado aqui em Super
Mario 64.
Outro componente importante da imersão do jogador é o personagem que os jogadores estão

controlando no jogo. Quase todos os jogos são sobre role-playing até certo ponto. E se os
personagens que os jogadores estão controlando, seu substituto no mundo do jogo, não é alguém
que eles gostam ou podem se ver como sendo, sua imersão será interrompida. Por exemplo, no
jogo de ação/aventura em terceira pessoa Super Mario 64, os jogadores são apresentados a um
personagem para controlar, Mario, que não tem uma personalidade muito distinta.
Mario tem um visual bastante único em seu traje de pseudo-encanador, mas ele nunca fala muito
e age como uma espécie de lousa em branco na qual os jogadores podem impor sua própria
personalidade. Por outro lado, alguns jogos de aventura estrelaram personagens que agiam como
pirralhos mimados, e os jogadores têm que assistir enquanto seu personagem diz coisas irritantes
e idiotas repetidamente. Cada vez que o personagem diz algo que os jogadores nunca diriam se
tivessem escolha, eles são lembrados de que estão jogando um jogo e que não estão realmente
no controle de seu personagem tanto quanto gostariam.
Para que os jogadores se tornem verdadeiramente imersos, eles devem se ver como seu substituto
no mundo do jogo.
Os jogadores esperam alguns contratempos

Os jogadores tendem a não gostar de jogos que podem ser jogados até o fim da primeira
vez. Se o jogo é tão pouco desafiador que os jogadores podem atravessá-lo na primeira
tentativa, pode não ser um jogo. Se eles quisessem algo tão simples, poderiam ter assistido
a um filme. Lembre-se de que os jogadores são atraídos para jogar porque querem um
desafio. E um desafio implica necessariamente que os jogadores não terão sucesso no
início, e que muitas tentativas devem ser feitas para superar os obstáculos antes que eles
sejam finalmente bem-sucedidos. Uma vitória que é alcançada com muita facilidade é uma
vitória vazia. Não é diferente de ganhar uma briga com alguém com metade do seu tamanho.
É importante entender que os jogadores querem contratempos por causa de suas próprias
deficiências, não por causa das idiossincrasias do jogo que estão jogando. Quando os jogadores
falham, eles devem ver o que deveriam ter feito e devem reconhecer instantaneamente por que o
que eles estavam tentando não funcionou. Se os jogadores sentirem que o jogo os derrotou por
meio de algum “truque” ou “tiro barato”, eles ficarão frustrados com o jogo. Os jogadores precisam
se culpar apenas por não terem sucesso, mas ao mesmo tempo o jogo deve ser desafiador o
suficiente para que eles não tenham sucesso imediatamente.
Também é uma boa ideia deixar os jogadores ganharem um pouco no início do jogo. Isso
atrairá os jogadores para o jogo, fazendo-os pensar: “isso não é tão difícil”. Os jogadores podem
até desenvolver um sentimento de superioridade em relação ao jogo. Então a dificuldade deve
aumentar ou “acelerar” para que os jogadores comecem a falhar. A essa altura os jogadores já
estão envolvidos no jogo, têm tempo investido nele e vão querer continuar jogando, para superar
o obstáculo que agora os derrotou. Se os jogadores forem derrotados muito cedo no jogo, eles
podem decidir que é muito difícil para eles ou não entender que tipo de recompensas receberão
se continuarem jogando. Se um jogo permite que os jogadores ganhem no início, eles saberão
que o sucesso é possível e agradável e se esforçarão para superar o que os superou.
Os jogadores esperam uma chance justa

Os jogadores não querem ser apresentados a um obstáculo que só pode ser superado por
tentativa e erro, onde um erro resulta na morte de seu personagem ou no fim do jogo. Os
jogadores podem descobrir a maneira correta de superar o obstáculo por tentativa e erro,
mas deve haver alguma maneira de descobrir um caminho de sucesso na primeira tentativa.
Assim, estendendo esta regra para todo o jogo, jogadores novatos extremamente
observadores e habilidosos devem ser capazes de progredir por todo o jogo sem morrer.
Pode ser que nenhum jogador seja tão habilidoso em sua primeira vez jogando e, como
discutimos, idealmente o designer quer que os jogadores tenham muitos contratempos
antes de completar o jogo. No entanto, deve ser teoricamente possível para os jogadores
passarem na primeira tentativa sem morrer. Se os jogadores continuarem morrendo de
cada tentativa de tiro no escuro em torno de um obstáculo, eles perceberão que, devido ao
design míope, não havia uma maneira real de evitar todas essas mortes. Eles ficarão
frustrados, amaldiçoarão o jogo e logo não perderão mais tempo com isso.
Os jogadores esperam não precisar se repetir Uma vez que os jogadores

tenham alcançado um objetivo em um jogo, eles não querem ter que repetir sua realização. Se
o designer criou um quebra-cabeça extremamente desafiador, que ainda é difícil de completar
mesmo depois que os jogadores o resolveram uma vez, ele não deve ser usado em demasia.
Por exemplo, o mesmo quebra-cabeça dolorosamente difícil não deve aparecer de uma forma
idêntica ou mesmo ligeiramente diferente em vários níveis de uma ação/aventura, a menos que
derrotar o quebra-cabeça seja muito divertido e as recompensas sejam significativamente
diferentes cada vez que o quebra-cabeça é concluído . Se não for muito divertido de fazer, e os
jogadores tiverem que continuar resolvendo ao longo do jogo, eles ficarão frustrados e odiarão
os designers do jogo por sua falta de criatividade em não apresentar novos desafios.
É claro que muitos jogos são construídos com base no princípio de os jogadores se repetirem, ou
pelo menos repetirem suas ações de maneiras sutilmente variadas. Jogos de esportes como NFL Blitz e
jogos de corrida como Project Gotham Racing são sobre cobrir o mesmo terreno repetidamente, embora
os desafios apresentados em qualquer um desses jogos sejam exclusivos para esse jogo. Jogos de
arcade clássicos como Centipede e Defender oferecem aproximadamente a mesma quantidade de
repetição. Tetrisis talvez seja o rei da jogabilidade repetitiva, mas os jogadores parecem nunca se cansar
de seu desafio. O componente-chave desses jogos que torna sua repetição aceitável é que esses jogos
são construídos puramente sobre sua mecânica de jogo e o prazer que os jogadores obtêm de várias
permutações deles. Em jogos em que a exploração é uma parte fundamental da diversão dos jogadores
e nos quais os desafios apresentados em qualquer jogo específico são bastante estáticos e imutáveis,
os jogadores não desejam se repetir indevidamente. Nesses jogos, depois de explorar um mundo de
jogo uma vez, as explorações subsequentes são significativamente menos interessantes. Embora toda
vez que os jogadores se envolvam em um jogo de Tetris, Defender, Project Gotham Racing ou NFL Blitz ,
o jogo é único, toda vez que os jogadores jogam The Legend of Zelda: The Wind Waker, Doom ou
Baldur's Gate, os desafios apresentados são aproximadamente os mesmos . Portanto, os jogadores não
se importam com a repetição nos primeiros jogos, enquanto eles rapidamente ficarão frustrados quando
forçados a se repetir nos últimos.
A falta de vontade dos jogadores de se repetir é o motivo pelo qual os jogos salvos foram criados.
Com os jogos salvos, uma vez que os jogadores concluíram uma tarefa particularmente árdua, eles
podem fazer backup de seu progresso para que possam restaurar essa posição quando morrerem mais tarde.
Os jogadores devem ter a oportunidade de salvar seu trabalho depois que um desafio enorme e
complicado foi finalmente superado. Permitir que os jogadores salvem seu jogo evita que eles tenham
que se repetir.
Alguns jogos até salvam automaticamente os jogos dos jogadores nessa posição recém-conquistada,
um processo às vezes conhecido como salvar pontos de verificação. Este método é um pouco superior,
pois muitas vezes os jogadores, tendo sucesso em uma tarefa árdua, terão acesso a uma nova e
emocionante área de jogo, uma que eles imediatamente desejarão explorar e interagir. Muitas vezes, em
sua excitação, eles se esquecem de economizar. Então, quando eles forem derrotados na nova área, o
jogo os jogará de volta ao último jogo salvo, que eles fizeram antes do obstáculo desafiador. Agora os
jogadores têm que passar pelo obstáculo desafiador mais uma vez. No entanto, se os designers do jogo
reconhecerem que o obstáculo é difícil de passar, eles podem fazer com que o jogo salve automaticamente
a posição dos jogadores, para que quando os jogadores morrerem na nova área, eles possam começar
a jogar na nova área. Imediatamente. De fato, o salvamento automático oferece aos jogadores uma
experiência mais imersiva: toda vez que os jogadores acessam uma tela de salvamento ou
menu, eles são lembrados de que estão jogando. Se os jogadores puderem jogar um jogo sem
precisar salvar explicitamente seu progresso, sua experiência será muito mais transparente e
imersiva.
No entanto, é importante notar que os salvamentos automáticos não devem ser usados como
substitutos para salvamentos solicitados pelo jogador, mas devem funcionar em conjunto com eles.
Desta forma, os jogadores que estão acostumados a salvar seus jogos poderão fazê-lo sempre
que julgarem apropriado, enquanto os jogadores que muitas vezes se esquecem de salvar poderão
jogar todo o jogo sem precisar pressionar a tecla salvar. Muitos desenvolvedores estão preocupados
que permitir que os jogadores salvem em qualquer lugar remove um elemento-chave de tensão
para o jogador. De fato, se os jogadores puderem economizar após cada pequeno passo
incremental que derem, o jogo será significativamente menos desafiador. No entanto, é importante
lembrar duas coisas fundamentais. Em primeiro lugar, se os jogadores realmente querem arruinar
sua experiência economizando constantemente, devemos permitir que eles façam isso, porque os
jogos devem ser sobre capacitar os jogadores a fazer o que quiserem. Em segundo lugar, ao não
permitir que os jogadores salvem quando quiserem, eles serão forçados a fazer coisas ridículas,
como deixar o sistema de jogo ligado durante a noite porque um dos pais ou cônjuge exigiu que a
hora de dormir chegou, mas eles não querem perder seu progresso. Se os jogos devem ser o meio
mais interativo, os designers de jogos precisam garantir que sejam pelo menos tão interativos
quanto um DVD player ou um livro e, assim, permitir que os jogadores parem a atividade e salvem
seu progresso em qualquer ponto que desejarem.
Os jogadores esperam não ficar irremediavelmente presos Não deve

haver nenhum momento durante um jogo em que os jogadores sejam incapazes de ganhar de alguma
forma, independentemente de quão improvável possa ser. Muitos jogos de aventura mais antigos
gostavam de quebrar essa regra fundamental. Muitas vezes, nesses jogos, se os jogadores não
conseguissem realizar uma determinada ação em um momento específico ou não conseguissem
recuperar um pequeno item de um local no início do jogo, eles não conseguiriam completá-lo. O
problema era que os jogadores não necessariamente perceberiam isso até que muitas horas de jogo
infrutífero tivessem passado. O jogo dos jogadores estava essencialmente acabado, mas eles ainda
estavam jogando. Nada é mais frustrante do que jogar um jogo que não pode ser vencido.
Como exemplo, os jogos modernos de exploração do mundo 3D, seja Metroid Prime ou Super
Mario Sunshine, precisam se preocupar com a possibilidade de os jogadores ficarem
irremediavelmente presos no mundo 3D. Muitas vezes, esse estilo de jogo oferece buracos ou
abismos nos quais os jogadores podem cair sem morrer. É vital sempre fornecer saídas desses
abismos, como escadas de fuga ou plataformas que permitem aos jogadores voltar ao jogo. O
método de sair do poço pode ser extremamente difícil, o que é bom, mas pelo menos deve ser
possível. Qual é o sentido de os jogadores caírem em um poço do qual não podem escapar? Se
eles são incapazes de escapar, o substituto do mundo do jogo dos jogadores precisa ser morto por
algo no poço, seja instantaneamente no impacto (digamos que o chão do poço esteja eletrificado)
ou muito em breve (o poço está inundando com lava, o que mata jogadores dentro de dez segundos
de sua queda). Sob nenhuma circunstância os jogadores devem ser deixados vivos, presos em
uma situação da qual não possam continuar com seu jogo.
Uma das principais críticas contra Civilization, um jogo excelente, é que seus finais podem
durar muito tempo. Quando dois países permanecem e um está irremediavelmente muito atrás do
outro, o jogo pode tender a se estender além do ponto de
Os designers de
nível para jogos de
ação/aventura em 3D,
como Metroid Prime,
precisam criar mapas
que impeçam o
jogador de ficar
permanentemente
preso atrás de uma
peça de arquitetura.
interesse enquanto o poder dominante persegue e massacra a oposição. De fato, o país menos
avançado não está tecnicamente sem esperança. Os jogadores ainda podem vir de trás e
ganhar o jogo; não é completamente impossível. Os jogadores não estão presos no mesmo grau
que os jogadores presos no poço sem saída, mas os jogadores estão tão atrás que pode ser
impossível; a sorte que eles precisariam ter e os erros que o poder dominante teria que cometer
são bastante surpreendentes. A solução para isso talvez seja permitir que a IA descubra quando
está irremediavelmente dominada e se render, assim como os jogadores que estão
irremediavelmente muito atrasados farão o mesmo ao desistir e iniciar um novo jogo.
Os jogadores esperam fazer, não assistir Por um

tempo, a indústria ficou muito empolgada com a perspectiva de “filmes interativos”.
Durante esse período, as cutscenes de jogos de computador ficaram cada vez mais longas.
Atores de cinema um pouco famosos começaram a estrelar as cut-scenes, e os orçamentos
dispararam. Os jogos tornaram-se cada vez menos interativos, cada vez menos parecidos com
os jogos. Então – surpresa, surpresa – os jogadores não gostaram desses tipos de jogos. Eles
não conseguiram comprá-los. As empresas faliram, e todos na indústria coçaram a cabeça
imaginando o que havia dado errado. Claro que os jogadores sabiam, e os designers de jogos
logo conseguiram descobrir o que estava errado. O problema era que os jogadores queriam
fazer; eles não queriam assistir. E eles ainda sentem o mesmo.
Eu não sou totalmente contra cutscenes; eles podem ser ferramentas muito úteis para
comunicar a história de um jogo, ou para transmitir aos jogadores informações que eles
precisarão para ter sucesso na próxima seção do jogo. Dito isso, acredito que as cut-scenes
devem ser reduzidas e minimizadas ao menor comprimento necessário para dar uma ideia da
narrativa do jogo, se houver, e configurar a próxima sequência de jogabilidade. Cut-scenes com
mais de um minuto de duração, especialmente aquelas que não fornecem informações essenciais
para completar a próxima sequência de jogo, devem ser evitadas. Não importa se a cena é texto
rolando na parte de trás da tela, vídeo em movimento completo com atores ao vivo, animação
cel ou feito usando o mecanismo de jogo, toda essa interrupção na jogabilidade não deve
demorar mais de um minuto. Se houver
jogabilidade envolvida de alguma forma, como os jogadores planejando a colocação de tropas para
a próxima missão, então não é realmente uma cena e pode ser tão longa quanto necessário. E
certamente, se a cena contém informações críticas para a jogabilidade, o designer vai querer deixar
os jogadores repetirem a cena quantas vezes quiserem.
A qualidade da cena também não importa. Houve muitos jogos com a “atuação” mais atroz já
testemunhada, geralmente realizada pelo produtor assistente e pelo testador principal. Houve jogos
com qualidade de Hollywood ou melhor produção e conteúdo. Mas no final, se o jogo for bom, os
jogadores vão querer voltar a jogar e pular a cena.
Em suma, a razão pela qual as pessoas jogam é porque elas querem algo diferente do que um
filme, livro, programa de rádio ou história em quadrinhos pode oferecer. Eles querem interagir. Não
incluí entre as razões pelas quais as pessoas jogam “porque a biblioteca está fechada” ou “porque
a TV está piscando”. Os jogadores querem um jogo, e os designers de jogos devem dar a eles.
Os jogadores não sabem o que querem, mas sabem

quando está faltando Um dos maiores erros que um
designer pode cometer no início do desenvolvimento é ter um grupo de foco com
um grupo de jogadores e perguntar o que eles querem ver em um novo jogo.
Pode-se ver isso como um argumento contra os grupos focais, mas esse não é exatamente o ponto.
Ter playtesters é uma parte muito importante do desenvolvimento de jogos. Por playtesters, quero
dizer pessoas que não procuram bugs em seu jogo, mas sim analisam a jogabilidade e fornecem
feedback construtivo sobre isso. Um designer deve ter muitas pessoas jogando seu jogo, uma vez
que está em um estágio de desenvolvimento em que a maioria da jogabilidade pode ser julgada.
Isso pode incluir o uso de grupos focais para obter feedback inestimável sobre onde o jogo é muito
desafiador ou confuso, mas apenas quando o jogo estiver pronto para eles jogarem.
Por outro lado, ter um grupo focal de jogadores antes de um jogo ser criado apenas para
“trocar ideias” é praticamente inútil. Os jogadores são bons, é claro, em julgar se um jogo que estão
jogando é divertido ou não. Eles podem não ser capazes de explicar de uma maneira útil o que
exatamente eles gostam ou não gostam em um jogo em particular, mas eles certamente sabem
quando estão se divertindo, se estão tendo suas fantasias realizadas, se estão sendo desafiados
adequadamente ou se um jogo os deixa excitados. Quando o jogo não está sendo divertido, os
jogadores poderão apontar isso para você, mas relativamente poucos serão capazes de dizer o que
fazer para corrigir o problema. Além disso, só porque os jogadores desfrutam de uma ampla
variedade de jogos finalizados não significa que eles estejam qualificados para criticar ideias de
jogos brutos. Da mesma forma, as ideias de jogos que eles apresentam não são boas. É rara a
pessoa que pode discutir a ideia de um jogo de computador e determinar se é provável que o jogo
final seja divertido ou não. Pessoas com essas habilidades são as mais adequadas para se tornarem
designers de jogos. Nem todos os jogadores têm essas habilidades, então, quando perguntados
sobre que tipo de jogo eles podem estar interessados em jogar, os jogadores podem não saber
realmente o que querem. Mas, como eu disse, eles certamente informarão quando estiver faltando
no produto final.
Uma lista interminável

Claro, essa exploração do que os jogadores querem poderia encher um livro inteiro.
Encorajo os leitores, sejam aspirantes a designers de jogos ou aqueles que já tiveram
vários jogos publicados, a criar suas próprias listas do que eles acham que os jogadores
querem. Pense no que o frustra enquanto joga um jogo e quais partes de um determinado
jogo lhe dão maior satisfação. Em seguida, tente determinar por que você reage a uma
mecânica de jogo dessa maneira. O que fez certo e o que fez errado? Isso permitirá que
você estabeleça sua própria lista de regras, que você pode aplicar aos seus próprios
designs. Essas regras farão parte do que torna seus jogos exclusivamente seus. Sem o
feedback dos testadores, muitas vezes é difícil determinar se o seu jogo é divertido e
atraente ou não. Mas com um conjunto de regras que você pode aplicar sistematicamente
ao seu design, você pode descobrir se alguém vai gostar do jogo completo.
Capítulo 2
Entrevista:
Sid Méier
Sid Meier é certamente o mais famoso e respeitado designer de jogos de

computador ocidental, e merecidamente. Em seus quase vinte anos de
desenvolvimento de jogos, ele cobriu todos os tipos de designs de jogos e todos
os tipos de assunto. Ele co-fundou a Microprose e inicialmente se concentrou em
simuladores de voo, culminando em seu clássico F-15 Strike Eagle e F-19 Stealth
Fighter. Subseqüentemente, ele mudou para o estilo de jogo pelo qual é mais
conhecido hoje, desenvolvendo clássicos como Pirates!, Railroad Tycoon, Covert
Action e Civilization, sendo este último um dos designs de jogos mais
universalmente admirados na história da a forma. No final dos anos 90, Meier
fundou uma nova empresa, a Firaxis, onde criou o verdadeiramente único jogo de
guerra RTS Gettysburg! Mais recentemente, ele continuou a assumir novos
gêneros de jogo com o divertido gerenciador de cursos SimGolf. O que mais
chama a atenção na retrospectiva de seus jogos é o nível consistente de qualidade
e o fato de quase nunca se repetir, sempre preferindo assumir algo novo e
diferente para seus projetos pessoais. Se alguém tem uma compreensão sólida
do que torna um jogo uma experiência atraente, é Sid Meier.
20
Capítulo 2: Entrevista: Sid Meier 21
Seus primeiros jogos publicados foram simuladores de voo. Eventualmente, você passou a
fazer o que agora é conhecido - jogos de estratégia. O que o levou de um gênero para o
outro?
Não foi um plano deliberado.
Acho que sempre tentei
escrever jogos sobre tópicos
que achava interessantes.
Há apenas um monte de
tópicos diferentes, eu acho.
Muitas coisas sobre as quais
escrevi dez jogos são coisas
pelas quais, quando criança,
me interessei, ou encontrei
um livro legal sobre a Guerra
Civil, ou aviões, ou qualquer
outra coisa. Acho que a outra Caça furtivo F-19
coisa que impulsionou isso
um pouco foi a tecnologia. Que em certos momentos a tecnologia está pronta para fazer um bom
trabalho com esse ou aquele tipo de jogo. Ou o mercado está pronto para um jogo de estratégia,
por exemplo, ou um jogo que você queria fazer há algum tempo, mas achou que não era a hora
certa. A mudança, especificamente de simuladores de voo para estratégia, ocorreu por dois motivos,
eu acho. Um, eu tinha acabado de terminar o F-19 Stealth Fighter, que incluía todas as ideias que
eu tinha até aquele momento sobre simulação de voo. Qualquer coisa que eu fizesse depois disso
seriam gráficos melhores ou mais sons ou mais cenários ou qualquer outra coisa, mas eu não
sentia que tinha muitas idéias novas naquele momento sobre simulação de vôo. Tudo o que eu
achava legal em um simulador de vôo tinha ido para aquele jogo. E a outra coisa foi que eu passei
algum tempo jogando SimCity e um jogo chamado Empire que me fez pensar sobre estratégia em
um grande sentido, um jogo que realmente tinha uma quantidade significativa de escopo e tempo e
muitas decisões interessantes para ser feito. A combinação desses dois fatores me levou a fazer
primeiro Railroad Tycoon e depois Civilization depois disso, como uma espécie de série de jogos
de estratégia.
Acho perigoso pensar primeiro em termos de gênero e depois de tópico. Como, digamos, “Eu
quero fazer um jogo de estratégia em tempo real. OK. O que é um tema legal?” Acho que, pelo
menos para mim, é mais interessante dizer: “Quero fazer um jogo sobre ferrovias. OK, agora qual
é a maneira mais interessante de dar vida a isso? É em tempo real, ou é baseado em turnos, ou é
”
em primeira pessoa. . . primeiro descobrir qual é o seu tópico e, em seguida, encontrar maneiras
Para
interessantes e um gênero apropriado para trazê-lo à vida, em vez de fazer o contrário e dizer: “OK,
eu quero fazer um jogo de tiro em primeira pessoa; o que ainda não foi feito?” Se você abordá-lo
do ponto de vista do gênero, basicamente está dizendo: “Estou tentando me encaixar em um
molde”. E acho que a maioria dos grandes jogos não começou desse ponto de vista. Eles
começaram com a ideia de que “Aqui está um tópico muito legal. E a propósito, provavelmente
funcionaria muito bem como um jogo de estratégia em tempo real com um pouco disso nele.”
22 Capítulo 2: Entrevista: Sid Meier
Então, quando você apresenta suas ideias para novos jogos, você começa com o
cenário do jogo em vez de com um gênero de jogabilidade.
Acho que um bom exemplo
disso são os Piratas! A ideia
era fazer um jogo pirata, e
então foi, “OK, não há
realmente um gênero por aí
que se encaixe no que eu
acho legal sobre piratas. O
filme de piratas, com a vela,
a luta de espadas, a parada
de ping em diferentes
cidades e todo esse tipo de
coisa, realmente não se
encaixa em um gênero.”
Então, escolhemos Piratas!
diferentes partes de coisas
diferentes, como uma sequência de navegação em tempo real e um sistema de aventura
baseado em menu para ir à cidade e, em seguida, uma luta de espadas em uma sequência
de ação. Então, escolhemos estilos diferentes para as diferentes partes do jogo conforme
achamos apropriado, em vez de dizer: “Vamos fazer um jogo em tempo real, ou baseado em
turnos, ou em primeira pessoa, ou qualquer outra coisa. ” e então fazer a ideia dos piratas se encaixar niss
Eu acho interessante que os Piratas! foi projetado com todos esses minijogos, mas
você não usou muito subjogos discretos desde então. Você não gostou da forma como
os mini-jogos se juntaram?
Bem, acho que funcionou muito bem em Piratas! Não funciona para todas as situações. Uma
das regras do design de jogos que aprendi ao longo dos anos é que é melhor ter um grande
jogo do que dois bons jogos. E, a menos que você seja cuidadoso, muitos subjogos podem
perder o jogador. Em outras palavras, se você tem um bom mini-jogo, então o jogador ficará
absorvido nele. E quando eles terminarem com isso, eles podem ter perdido o fio da meada
de sua história, ou se algum jogo for muito cativante, pode atrapalhar o fluxo de sua história.
Francamente, os mini-jogos de Pirates! eram simples o suficiente para que você não perdesse
a noção de onde estava ou qual era seu objetivo ou o que estava tentando fazer. Mas eu
escrevi um jogo alguns anos depois chamado Covert Action que tinha minijogos mais intensos.
Você entrava em um prédio, ia de sala em sala, jogava granadas e atirava em pessoas e abria
cofres e todo esse tipo de coisa e provavelmente passaria dez minutos correndo por este
prédio tentando encontra mais pistas e, quando sai, diz a si mesmo: “OK, qual era a missão
em que eu estava, o que eu estava tentando fazer aqui?” Então, isso é um exemplo para mim
da maneira errada de ter minijogos dentro de uma história geral.
Eu li que Covert Action foi um dos seus favoritos entre os jogos que você projetou.
Eu gostei, mas tinha aquele

problema particular em que
as mini sequências individuais
eram um pouco envolventes
demais e tiravam você do
caso geral. A ideia era que
havia esse enredo se
formando e você tinha que ir
de cidade em cidade e de
lugar em lugar encontrando
essas pistas que lhe diriam
pedaço por pedaço qual era
o enredo geral e encontrar
as pessoas que estavam Ação Encoberta
envolvidas. Achei a ideia
legal, diferente. Se eu tivesse que fazer tudo de novo, provavelmente faria algumas mudanças.
Havia uma sequência de quebra de código e decifração de circuitos, e havia alguns quebra-
cabeças legais nela. Eu pensei que no geral havia muitas ideias legais, mas o todo provavelmente
não era tão bom quanto as partes individuais. Eu provavelmente faria algumas coisas diferentes
agora.
Então a Covert Action parece ter uma origem parecida com Pirates! Você começou com “Eu
quero fazer um jogo de espionagem secreta...”
Certo, quais são as coisas legais sobre isso. E, infelizmente, a tecnologia chegou ao ponto em
que eu poderia fazer cada parte individual com mais detalhes e isso para mim prejudicou a
compreensão geral do jogo.
Em Piratas! e Covert Action, o jogador pode ver seu personagem no jogo, e o jogador está
realmente interpretando um personagem. Por outro lado, em Railroad Tycoon, Civilization
ou Gettysburg!, o jogador não tem realmente um personagem para interpretar. Estou
curioso sobre essa mudança no design do seu jogo, onde o jogador costumava ser um
personagem específico e agora é mais uma figura divina.
É bom ser Deus. Acho que é mais uma questão de escala do que uma escolha específica de
design de jogo. É divertido ver a si mesmo, e mesmo em um jogo como Civilization você vê seu
palácio, você tende a ver coisas sobre você. Mas a outra coisa é que um pirata parece legal,
enquanto um barão ferroviário não parece especialmente legal. Por que se dar ao trabalho de
colocá-lo na tela? Eu nunca pensei muito sobre isso, mas acho que provavelmente é mais uma
coisa de escala. Se você está passando por centenas e milhares de anos, e você é um personagem
semi-deus fazendo muitas coisas diferentes, é menos interessante como você realmente se parece
do que se você for um personagem individual muito legal.
Então, como você começou a trabalhar no Railroad Tycoon?

Bem, na verdade começou
como um jogo de modelo
ferroviário sem nenhum dos
aspectos econômicos e ainda
mais do baixo nível de
funcionamento dos trens.
Você realmente mudaria os
interruptores e manipularia
os sinais no protótipo original.
Ele meio que cresceu a partir
disso com uma boa
quantidade de inspiração de
1830, um jogo de tabuleiro
Avalon Hill projetado por
Bruce Shelley, com quem
trabalhei em Railroad Tycoon.
Magnata Ferroviário
Então, isso inspirou muito o
lado econômico, os aspectos do mercado de ações do jogo. À medida que adicionamos isso,
sentimos que tínhamos muito alcance, muito no jogo, que ir desde acionar os interruptores até
administrar o mercado de ações era demais. Também queríamos ter a marcha da tecnologia com
os motores mais novos ao longo do tempo, até os motores a diesel.
Portanto, havia muito microgerenciamento envolvido quando você tinha que fazer todas as coisas
de ferrovias de baixo nível. Então, aumentamos um nível em que todas as coisas que precisavam
acontecer rotineiramente eram feitas automaticamente para você em termos de comutação e
sinalização. Mas se você quisesse, e tivesse um expresso ou uma carga especial ou algo assim,
você poderia entrar lá e manipulá-los se realmente quisesse ter certeza de que o trem chegaria a
tempo, ou uma ponte estava fora e você tinha que parar Os trens. Mas a origem disso foi como um
jogo de ferromodelismo e adicionamos alguns dos elementos mais estratégicos ao longo do tempo.
Foi realmente a inspiração para Civilization de várias maneiras, em termos de combinar

alguns sistemas diferentes e interessantes que interagiam continuamente. O econômico, o
operacional, o mercado de ações, todos interessantes por si só, mas quando eles começaram a
interagir um com o outro foi que a verdadeira mágica começou a acontecer. Ao contrário de Piratas!
e Covert Action, onde você tinha subjogos individuais que monopolizam o computador. Quando
você estava lutando com espadas, nada mais estava acontecendo. Aqui você tinha subjogos que
estavam acontecendo simultaneamente e interagindo uns com os outros e nós realmente achamos
que funcionou bem tanto no Railroad Tycoon quanto mais tarde no Civilization, onde tivemos
considerações militares, políticas e econômicas acontecendo ao mesmo tempo.
Então, de certa forma, você ainda está usando subjogos; eles simplesmente estão em jogo
o tempo todo.
Não é episódico da maneira que Pirates! foi. Sempre que você está tomando uma decisão, você
está realmente considerando todos esses aspectos ao mesmo tempo. Isso é parte do que
torna Civilization interessante. Você tem esses sistemas individuais bastante simples; o sistema
militar, o sistema econômico, o sistema de produção são todos muito fáceis de entender por
conta própria. Mas uma vez que você começa a trocá-los, fica mais complexo: “Tenho a
oportunidade de construir algo aqui. Meus militares realmente precisam de outra carruagem,
mas as pessoas estão exigindo um templo. . . ” Então
essas coisas estão sempre em jogo e acho que isso torna o jogo realmente interessante.
Em Railroad Tycoon você tem uma simulação econômica muito interessante, mas ao
mesmo tempo o jogador se diverte construindo uma ferrovia, como uma criança faria.
Você acha que isso contribuiu para o sucesso do jogo?
Na verdade começou aí.
E foi realmente o primeiro
jogo que eu fiz onde você
tinha essa mudança
dramática, dramática do
estado no início do jogo
para o estado no final do
jogo. Onde, no início do
jogo, você não tinha
basicamente nada, ou duas
estações e um pequeno
pedaço de trilho, e no final
do jogo você podia olhar
para essa enorme teia de
trens e dizer: “Eu fiz isso”.
E, novamente, esse foi um
Magnata Ferroviário
conceito que levamos para
Civilization, a ideia de que
você começaria com um único colono e um pouco de terra que você conhecia e, no final do
jogo, você criaria essa história enorme sobre o evolução da civilização e você poderia olhar
para trás e dizer: “Fui eu, eu fiz isso”. O estado do jogo mudou tão drasticamente do início ao
fim, havia uma sensação de ter chegado a algum lugar. Ao contrário de um jogo como Pirates!
ou todos os jogos anteriores em que você conseguiu uma pontuação ou fez algo, mas não
havia essa sensação real de que o mundo era completamente diferente. Acho que isso deve
muito ao SimCity, provavelmente, como o primeiro jogo que realmente fez um bom trabalho em
criar esse sentimento.
Você se inspirou no jogo de tabuleiro Avalon Hill Civilization quando fez sua versão para
computador?
Nós jogamos, eu estava familiarizado com isso, mas foi realmente menos inspirador do que,
por exemplo, Empire ou SimCity. Principalmente, eu acho, por causa das limitações dos jogos
de tabuleiro. Havia algumas ideias legais lá, mas muitas das coisas legais em Civ., a exploração,
a operação simultânea desses diferentes sistemas, são muito difíceis de fazer em um jogo de
tabuleiro. Então, havia algumas ideias legais no jogo, e nós gostamos do nome.
[risos] Mas em termos de ideias reais, elas provavelmente eram mais de outras fontes do
que o jogo de tabuleiro Civilization .
Muitos de seus jogos parecem ser inspirados em parte em jogos de tabuleiro. Mas,
como você acabou de dizer, Civilization nunca funcionaria como um jogo de tabuleiro.
Como você pega uma ideia que gostou em um jogo de tabuleiro e a transfere para algo
que realmente é um jogo de computador em vez de apenas uma tradução direta?
Antes de haver computadores, eu jogava muitos jogos de tabuleiro e gostava de jogos de
Avalon Hill, etc. Acho que eles forneceram muitas ideias iniciais para jogos. Muitas vezes
eles são um bom modelo do que é importante, do que é interessante e do que não é sobre
um tópico. Mas uma vez que você entra em mecânica e interface e esse tipo de coisa,
realmente começa a haver uma diferença bastante significativa entre jogos de tabuleiro e
jogos de computador. Há muito material de pesquisa interessante às vezes em jogos de
tabuleiro. Muitas vezes são interessantes porque “precisamos de algumas tecnologias” ou
“precisamos pensar em quais unidades”, etc. Há esse tipo de sobreposição em termos de
peças básicas, às vezes. Mas como eles são usados e assim por diante, essas coisas são
bem diferentes entre jogos de tabuleiro e jogos de computador. Eu diria que os jogos de
tabuleiro fornecem uma revisão interessante de tópicos disponíveis e tópicos interessantes.
Mas uma vez que entra no jogo em si, há uma grande diferença entre jogos de computador e jogos de tab
Uma das coisas mais notáveis sobre Civilization é sua qualidade viciante. Eu queria
saber se isso aconteceu por sorte ou se você planejou desde o início.
Nós realmente não
imaginamos isso.
Pretendemos que todos os
nossos jogos sejam
divertidos de jogar e
esperamos que sejam
viciantes até certo ponto.
Mas Civilization tinha um
vício mágico que realmente
não projetamos, que
realmente não prevíamos.
Acho que qualquer jogo em
que tudo se encaixa de uma
maneira muito legal terá
essa qualidade. Eu acho
que é realmente o resultado
Civilização
de quão bem as peças se
encaixam e como eu acho que escolhemos uma boa escala, um bom nível de complexidade,
um bom número de coisas para fazer. Acho que tomamos algumas decisões sábias ao
projetar esse jogo. E a soma de todas essas decisões é a dependência. E acho que foi um
bom tema. Muitas coisas estavam certas naquele jogo, e tudo isso se juntou para criar essa
qualidade viciante. Não foi algo que projetamos, mas era algo que estávamos cientes.
Mais ou menos na metade do processo, percebemos que, uau, esse jogo é realmente muito divertido
de jogar. Foi uma descoberta agradável para nós.
Então você não tem nenhum conselho sobre como outros designers podem tentar alcançar
essa dependência em seus próprios jogos?
Acho que em retrospectiva sabemos, ou achamos que sabemos, por que o jogo é viciante, ou temos
nossas teorias. Uma coisa é o que chamamos de “decisões interessantes”. Para nós, isso significa
que você é apresentado a um fluxo de pontos de decisão em que as decisões não são tão complexas
que você está basicamente escolhendo aleatoriamente em uma lista de opções. Uma decisão muito
complexa é aquela em que você diz: “Ah, eu tenho essas três opções. Sim, eu poderia passar cinco
minutos analisando a situação, mas eu realmente quero continuar com o jogo, então vou escolher B
porque parece bom.” E no outro extremo estão as decisões muito simples: “É óbvio que devo escolher
A, porque é claramente melhor do que todas as outras opções”. Em Civ. tentamos apresentar-lhe
escolhas que sejam fáceis de entender, mas em uma determinada situação você pode escolher A,
em uma situação ligeiramente diferente B é uma boa escolha, em outra situação C é uma boa escolha.
Então você está realmente dizendo: “Aqui estão as três tecnologias que posso usar em seguida”. E
você diz a si mesmo: “Bem, agora estou prestes a entrar em conflito com aqueles romanos ruins.
Então eu realmente preciso dessa tecnologia que me dê a próxima unidade militar legal. Mas, bem,
essa criação de mapas parece meio interessante. Da próxima vez, posso levar isso porque quero
explorar um pouco.” Então, se você pode criar decisões em que o jogador está sempre dizendo: “Da
próxima vez, vou tentar essa, porque parece interessante também”, isso cria toda essa ideia de que
há essa riqueza lá que você está apenas arranhando o superfície desta época.
A qualidade viciante, eu acho, também se deve ao fato de que você tem várias coisas
acontecendo ou em processo ao mesmo tempo. Por um lado, você tem sua próxima tecnologia
produzindo por aí. Seus cientistas estão trabalhando nisso. E esta cidade está fazendo aquele primeiro
tanque que você está esperando. Aqui está uma unidade vagando pelo próximo continente, e logo ele
encontrará algo interessante. Você tem coisas diferentes pelas quais está ansioso no jogo, e nunca
há um momento em que tudo esteja pronto. Nunca há um estado de redefinição. Há sempre duas ou
três coisas acontecendo no jogo que você está ansioso para ver quando elas terminam. Portanto,
nunca há um bom momento para parar de jogar. Eu acho que isso realmente ajuda o fenômeno “você
nunca pode parar de jogar o jogo”.
Eu conheço Gettysburg! não foi seu primeiro jogo em tempo real, mas parece ter sido em parte
inspirado pelos grandes jogos RTS de sucesso como Command & Conquer e WarCraft.
Acho que a tecnologia chegou ao ponto em que você podia ter um monte de carinhas correndo por aí
fazendo coisas na tela em tempo real. E o que você chama de “tempo real”, é um termo meio estranho
porque sempre fizemos jogos em tempo real, mas não pensamos neles como em tempo real porque
parecia uma coisa natural. Mas acho que quando baseado em turnos se tornou seu próprio gênero,
tivemos que fazer uma distinção. Acho Gettys burg! é um jogo que eu queria fazer há muito tempo,
mas a tecnologia não se prestava a ser capaz de fazê-lo até recentemente. Finalmente chegamos ao
ponto em que poderíamos ter um monte de caras marchando pela tela em um campo de batalha de
aparência realista,
carregando seus mosquetes, atirando e girando em diferentes formações e fazendo todo aquele
tipo de coisa que eu tinha visualizado como o que era legal em uma batalha da Guerra Civil.
Chegou o momento em que isso era factível.
Parece que é preciso o que WarCraft e os outros jogos RTS mais simples fizeram bem, mas
depois adiciona um nível mais profundo de simulação, onde você tem bônus de flanco e
outros recursos mais tradicionais de jogos de guerra. Era seu objetivo pegar um jogo de
guerra mais complexo e mesclá-lo com o formato RTS de ritmo acelerado?
Novamente, a ideia era fazer
um jogo de batalha de
Gettysburg, e então o gênero
de “tempo real” fez mais
sentido. Sempre tive a
sensação de jogar qualquer
outro jogo de tabuleiro que
algo estava faltando. A
sensação que tenho ao ler
as histórias, as histórias das
batalhas, não é capturada
em um jogo de tabuleiro ou
em nenhum dos jogos que
joguei sobre Gettysburg. A
pressão do tempo, a sensação
de confusão, o sentido
dessas diferentes formações, Gettysburg!
etc., não faziam sentido
algum até que você realmente tivesse que tomar as decisões por conta própria. E então, de
repente, você percebe: “Cara, não foi tão fácil fazer aquela manobra óbvia que teria vencido a
batalha se eles tivessem tentado” ou “Agora eu entendo por que eles se alinharam nessas
formações isso parecia muito estúpido para mim antes.” Muitas coisas começaram a fazer sentido
quando a batalha ganhou vida. E essa era a ideia, incluir táticas suficientes da Guerra Civil, como
flanqueamento, moral e coisas assim, para realmente capturar o sabor de uma batalha da Guerra
Civil sem sobrecarregar o jogador com conceitos de jogos de guerra hard-core. Ao representar os
principais fatores que influenciaram a batalha ou que influenciaram as táticas, você poderia
naturalmente aprender a ser um comandante. Você não teria que seguir um conjunto de regras,
mas você perceberia que, “Oh, se eu der algum apoio a esses caras, eles serão soldados
melhores, e se eu puder entrar no flanco, então é uma ataque." E você passa por um processo de
aprendizado em vez de ser ensinado a ser um bom general. Você aprende isso ao longo do
caminho. Essa era a intenção.
Eu estava me perguntando sobre o método “clique e arraste” que você fez o jogador usar
para direcionar suas tropas para algum lugar. É muito diferente do que outros jogos RTS
empregam. Você o usou porque achou que era um sistema melhor, mesmo não sendo o
padrão?
Não tenho certeza se faria isso da mesma maneira hoje. Eu acho que clicar e arrastar fez um certo
sentido, especialmente porque enquanto você arrastava estávamos mostrando com a seta
coisas interessantes sobre o caminho que você tomaria. Eu também sou um grande fã de interfaces
padrão, então se eu tivesse que fazer isso hoje, eu provavelmente tentaria usar mais a interface
RTS padrão. Acho que na época em que estávamos fazendo isso, era muito cedo.
WarCraft foi lançado, mas não acho que StarCraft tenha sido lançado, e Age of Empires foi lançado
quase ao mesmo tempo. Portanto, o padrão de interface não havia se unido quando fizemos isso.
Acho que, em reconhecimento a isso, demos ao jogador a opção de usar o botão direito/esquerdo
de fazer as coisas também. Mas se eu tivesse que fazer isso hoje, provavelmente tornaria o
método RTS padrão o padrão e tornaria a opção clicar e arrastar.
Ao contrário de Railroad Tycoon ou Civilization, Gettysburg! tem cenários distintos: você

joga por um tempo e então a batalha termina, você recebe um novo briefing e suas tropas
são reiniciadas. Por que você optou por esse estilo de progressão de jogo?
Bem, eu fiz isso porque a
estúpida Batalha de Get
tysburg tinha muitas unidades!
[risos] Eu teria preferido uma
batalha completa no tipo de
nível que o jogo real acabou
sendo.
Basicamente, para tornar o

jogo divertido, descobri que
você precisa ter algo entre
dez e vinte e cinco unidades
discretas que você possa
mover. Infelizmente, toda a
batalha teve setenta ou
oitenta regimentos, então
Gettysburg!
estaria totalmente fora de
controle. Nós tentamos por um tempo realmente falsificar a escala e dizer: “Você realmente
receberá brigadas, mas elas agirão como regimentos e então você poderá lutar toda a batalha”.
Mas não parecia certo distorcer a escala dessa maneira. Então, chegamos ao ponto em que era:
“OK, as batalhas mais divertidas e interessantes são dessa escala. E isso realmente significa que
é uma parte da batalha. E temos que aceitar isso, viver com isso e tirar o melhor disso”. E acho
que o sistema de cenários foi uma tentativa de fazer isso.
Eu acho que em um mundo ideal eu poderia ter escolhido a Batalha de Hunter's Run ou algo
onde houvesse apenas três brigadas e tudo fosse capturável em um único cenário. Mas ninguém
vai comprar The Battle of Hunter's Run; todos eles querem Gettys burg! Portanto, é uma parte
infeliz da história que tenha acontecido uma batalha tão grande.
E, acho que funcionou muito bem. Mas eu entendo quando as pessoas dizem: “Bem, eu realmente
quero toda a batalha”. E tentamos dar isso a eles e mostrar a eles que eles realmente não queriam
isso neste sistema. Foi um caso em que a história e a realidade não criaram provavelmente a
situação ideal para o sistema de jogo que tínhamos. Mas era nossa sensação que, ao invés de dar
a você toda a batalha e esmagá-lo com oitenta unidades, ou tentar jogar alguns jogos bastante
complicados para colocar toda a batalha nessa escala,
pensamos que o sistema de cenários era o melhor compromisso na tentativa de torná-lo

jogável, mas também historicamente realista. E eu acho que há alguns cenários legais lá.
Provavelmente inclina-se um pouco mais para a pessoa interessada na Guerra Civil, mas nem
todos podem ser Civilização.
Então você ainda está trabalhando em seu jogo com tema de dinossauro. Quais são seus
objetivos com esse projeto?
Bem, o objetivo do jogo é realmente o mesmo de todos os jogos em que trabalhei: descobrir
qual é a parte realmente legal, a parte única, a parte interessante deste tópico, e encontrar uma
maneira de transformar isso em um jogo de computador. Eu pensei que os dinossauros eram
legais por muito tempo, e acho que é um tópico que precisa ser motizado por computador. Eu
tento adotar a abordagem de colocar no jogo um monte de coisas que são cientificamente
verdadeiras ou historicamente precisas, mas isso não é ser educacional, é deixar o jogador usar
seu próprio conhecimento ao jogar o jogo. A maioria das pessoas sabe algo sobre dinossauros,
ou alguma coisa sobre história, e se eles podem aplicar esse conhecimento ao jogo, então isso
o torna muito mais interessante e faz com que eles se sintam bem consigo mesmos. Não é
porque eles lêem o manual que eles são bons no jogo, é por causa do que eles sabem. Eles
percebem que é legal ter pólvora e a roda e coisas assim.
Então, no mesmo sentido, as pessoas sabem que o T. rex é o pior dinossauro. Então,
usamos coisas no jogo para torná-lo valioso para conhecer alguns fatos básicos sobre qualquer
que seja o tópico. Tentamos colocar essa quantidade de realismo e precisão no jogo. E, em
seguida, torná-lo divertido em cima disso. Da mesma forma que um filme lhe dá toda a diversão
e as sequências de ação e todas as partes importantes de uma história e depois salta
rapidamente sobre as coisas chatas. Acho que o jogo tem a mesma responsabilidade, levar
você aos pontos-chave de decisão e depois passar para a próxima coisa interessante. Estamos
tentando fazer a mesma abordagem com o jogo dos dinossauros, para trazê-los à vida, para
descobrir o que é legal e único sobre eles enquanto cortamos todas as partes chatas. Estamos
realmente em uma fase de “resolver isso” e não temos muito a dizer sobre as especificidades
disso; Espero que em alguns meses possamos falar um pouco mais sobre como isso vai acabar.
[Desde que esta entrevista foi realizada, Meier abandonou o jogo dos dinossauros, optando por
desenvolver o SimGolf.]
Relativamente falando, você faz jogos de computador há muito tempo, desde o início dos
anos 80. Eu queria saber como você pensou que a indústria mudou ao longo desse tempo.
Acho que houve uma melhoria geral e geral na qualidade dos jogos. Eu acho que existem
alguns grandes jogos por aí agora. Eu gosto de StarCraft, Age of Empires, Diablo, The Sims
achei muito interessante, e RollerCoaster Tycoon foi uma piada, muito divertido. Então eu acho
que esses jogos se comparam muito favoravelmente a qualquer coisa que já foi feita. Eu acho
que eles são jogos melhores do que estávamos fazendo cinco ou dez anos atrás. Eu acho que
você certamente pode ver a melhoria na apresentação, gráficos, vídeo e todo esse tipo de coisa.
O núcleo dos jogos, o design do jogo, acho que é um processo evolutivo bastante lento. Eu
acho que em termos de design de jogos, jogos como Pirates! e SimCity e Civilization realmente
se destacam. Eu acho que eles são designs muito fortes, até hoje. Eu acho que eles não foram
eclipsados pelo que está acontecendo agora. Então eu acho que em termos de design de jogo,
a regra que diz que as coisas ficam duas vezes melhores a cada ano, os processadores ficam duas
vezes mais rápidos, etc., acho que isso não se aplica. Acho que o design do jogo é um processo
evolutivo bastante gradual, onde construímos o que aconteceu antes e o tornamos um pouco melhor,
um pouco mais interessante. De vez em quando um novo gênero aparece para abrir nossos olhos para
algumas novas possibilidades. Acho que isso vai continuar, mas é interessante para mim que um
computador de três anos esteja completamente obsoleto, mas um jogo de três anos ainda pode ser muito diverti
Desde que você consiga rodar…

Certo, contanto que você tenha aquele computador de três anos para executá-lo. Há um ritmo diferente,
eu acho. A tecnologia se move em um ritmo muito rápido, e a evolução do design de jogos se move em
um ritmo muito mais lento.
Você acha que a evolução do design de jogos desacelerou desde os primeiros dias da indústria?
Não vejo uma mudança significativa. Acho que um fenômeno é que só lembramos dos bons jogos do
passado. O passado parece ter todos os tipos de grandes jogos, e o presente parece ter alguns
grandes jogos e muita porcaria. E eu acho que havia muita porcaria naqueles dias também, tudo se
desvaneceu. Eu acho que há um grande trabalho de design de jogos acontecendo hoje. Antes havia
muito mais território inexplorado, e isso nos deu a oportunidade de ser um pouco mais inovadores. Mas
com tecnologia online e coisas assim, isso abre muitas novas áreas para ser inovador. Portanto, não
vejo uma diferença substancial entre a quantidade de bom trabalho que está sendo feito hoje e o que
estava acontecendo anos atrás.
Você trabalhou em pequenos estúdios de desenvolvimento, Microprose nos primeiros dias e

Firaxis, bem como em um grande, Microprose nos últimos dias. Você acha que um ambiente é
melhor para promover a criação de bons jogos?
Estou pessoalmente muito mais confortável no ambiente pequeno. Isso pode ser mais um sentimento
pessoal do que qualquer tipo de regra sobre onde os bons jogos acontecem. Acho que a tendência
certamente tem sido para grupos maiores, equipes maiores, maiores maiores. E pode ser assim que as
coisas são. Se há algo que me faz sentir um pouco velho, é o fato de não me sentir tão confortável no
ambiente de grandes grupos como claramente alguns dos outros desenvolvedores. Acho que alguns
dos desenvolvedores mais jovens que cresceram nesse modo estão muito mais confortáveis com os
grandes projetos. Eu estava em Los Angeles para o show da E3, e o vencedor do prêmio Hall of Fame
foi Hironobu Sakaguchi, que projetou o Final Fan tasy, que é um jogo enorme, massivo, massivo. Me
assustaria totalmente abordar algo tão grande. Mas há designers que apenas prosperam com isso.
Acho que é uma preferência pessoal dos designers, e acho que desde que comecei na época em que
não havia uma equipe gigantesca que me sinto confortável nesse modo menor, enquanto outros
designers preferem os projetos maiores. Principalmente é uma preferência pessoal.
Desde que você começou no desenvolvimento de jogos, as equipes de desenvolvimento

cresceram de uma ou duas pessoas para um número padrão de vinte ou mais. Você acha que
isso tornou os jogos menos pessoais?
Acho que sim, mas ainda hoje existem jogos que têm esse toque pessoal. E acho que esses são os
bons jogos. Acho que muitos dos jogos que não são tão divertidos são aqueles que têm essa sensação
de “desenhado por comitê, programado por uma horda”.
E, sim, eles parecem bons, e são uma reminiscência de talvez um ou dois outros jogos que foram bons.
Mas eles não têm essa faísca pessoal. Para mim, RollerCoaster Tycoon é um bom exemplo de jogo
pessoal. Realmente parece que alguém achou isso legal. Ninguém disse: “Isso é bobo” ou “Isso é
estúpido”. Muitas das ideias são muito inteligentes, mas se você a apresentasse a um comitê, eles
diriam: “Ah, realmente, as pessoas não vão pensar que isso é bobagem?” E mesmo Final Fantasy,
apesar de sua enorme equipe, é realmente o produto da visão de uma pessoa. E se você pode manter
isso em uma grande equipe, isso é ótimo. Mas acho que fica cada vez mais difícil quanto maior a equipe
é manter essa visão pessoal viva e não ser enfraquecida pela abordagem do comitê.
Você ainda atua como programador líder e designer líder em seus projetos.
Você é mais feliz preenchendo os dois papéis?
Não consigo imaginar trabalhar de outra forma. É muito mais eficiente para mim ter uma ideia e apenas
digitá-la no computador do que tentar explicá-la para outra pessoa e ver o que acontece. Então,
novamente, é meu estilo pessoal, mas para mim é a maneira mais eficiente de fazer algo.
Na maioria dos projetos modernos de outras empresas, você tem uma pessoa que é o designer-
chefe e uma pessoa que é o programador-chefe, e ambas estão muito ocupadas. Parece que ao
desempenhar os dois papéis você ficaria completamente sobrecarregado.
Bem, acho que eles provavelmente passam metade do tempo conversando um com o outro, o que é
algo que não preciso fazer. Eu veria uma certa eficiência em eliminar todas essas reuniões. Mas
certamente funciona nos dois sentidos. Qualquer uma das maneiras pode funcionar, mas minha
preferência pessoal é pela abordagem de designer/programador.
Agora que você está trabalhando em uma equipe maior, como você comunica sua visão de
design de jogo para o resto da equipe e os deixa entusiasmados com o projeto?
Nossa principal ferramenta é o protótipo. Em nosso desenvolvimento, uma das vantagens de ser um
programador/designer é que em uma ou duas semanas podemos montar algo que parece um jogo. Isso
dá às pessoas a ideia do que o jogo vai ser, como vai funcionar, os parâmetros gerais dele. Novamente,
se estamos trabalhando em um tópico histórico ou científico, a maioria das pessoas já está no meio do
caminho, eles sabem algo sobre o tópico. E então apenas falando, dizendo que aqui está o tipo de jogo
que eu quero fazer, e aqui estão as três ou quatro coisas muito legais que vão acontecer no jogo que
serão as recompensas. Juntar essas coisas, acho que dá às pessoas uma boa ideia de qual direção
estamos seguindo. Nesse ponto, você quer que as pessoas não entendam tudo, mas descubram onde
elas se encaixam e possam contribuir com suas próprias coisas que
espero que você nem tenha pensado, em termos de arte legal ou sons legais ou ideias legais.
De certa forma, você não quer que seja tão completo que pareça feito, porque você quer que as
pessoas sintam que podem fazer suas próprias contribuições acima e além do que você já
pensou.
Então, se alguém tiver algumas ideias legais para adicionar ao design do seu jogo, você
ficará feliz em incorporá-las, mesmo que não tenha sido sua.
Fico feliz em roubá-los e afirmar que foram minhas ideias anos depois. [risada]
Com seu sistema de prototipagem, você já experimentou um jogo e ele simplesmente não
funcionou como você esperava?
Sim, eu tenho um grupo inteiro de diretórios no meu disco rígido que se enquadram nessa
categoria. E muitos dos jogos que se tornaram produtos começaram em uma direção muito diferente.
A civilização, por exemplo, originalmente era muito mais parecida com SimCity, muito mais
zonear este território para fazendas, e colocar uma cidade aqui e vê-la crescer. Inicialmente, era
muito mais uma abordagem de ficar para trás e assistir à evolução; ele só se tornou baseado em
turnos depois de alguns meses. Eu mencionei que Railroad Tycoon começou como um jogo de
ferrovia modelo. Muitas vezes os protótipos terão que ser radicalmente modificados para
funcionar. Essa é toda a ideia do protótipo: dar a você uma ideia rapidamente se a ideia funciona,
se não funciona e quais são os principais problemas. Ele permite que você se concentre primeiro
nos grandes problemas e, com sorte, os resolva.
Seus jogos parecem muito fáceis de pegar e aprender a jogar. Mas, ao mesmo tempo, eles
têm uma jogabilidade muito profunda e interessante. Como você consegue realizar os
dois?
A parte fácil de jogar é muito

bem compreendida. Acho
que as convenções de
interface e, novamente,
voltar à ideia de um tópico
familiar ajuda as pessoas a
entrarem no assunto porque
sabem um pouco do que
devem fazer. Você quer dar
aos jogadores muito feedback
positivo no início do jogo
para dar a eles a ideia de
que estão no caminho certo.
Em Civilization, rapidamente
as pessoas adicionam algo
ao seu palácio, e você obtém
Civilização
um marco populacional, e
sua primeira cidade é formada. Você quer dar aos jogadores, especialmente nos estágios iniciais,
a ideia de que eles estão no caminho certo, que tudo o que eles fazem, o computador reconhece,
reconhece e pensa que é
realmente legal. Isso coloca os jogadores no jogo.

Em termos de profundidade, é porque jogamos os jogos. A outra vantagem da prototipagem
é que se você tem um jogo que leva dois anos para ser escrito, você passa um ano e onze meses
jogando o jogo. Você fica muito entediado com o início do jogo depois de um tempo. Em certo
sentido, você está colocando essa profundidade no jogo para se manter interessado em escrever
este jogo. Se há vinte ou quarenta horas de jogo em um cenário, é porque jogamos esses cenários
por vinte ou quarenta horas e descobrimos que, depois de cerca de vinte horas, ele fica um pouco
magro. Temos que entrar com uma coisa nova e tornar esse problema um pouco mais interessante,
um pouco mais complexo nesse ponto. Então, muito da profundidade vem do fato de que jogamos
o jogo intensamente por longos períodos de tempo.
Você acha que a prototipagem também facilita o balanceamento?

Jogar o protótipo realmente facilita o balanceamento. Também ajuda muito a escrever a IA se você
já jogou o jogo o suficiente para realmente entender o que são boas estratégias, estratégias ruins e
estratégias interessantes. Ter jogado o jogo um pouco ajuda a escrever a IA, é bom para a
profundidade. O perigo é que você perca de vista o jogador iniciante. É por isso que voltamos aos
testes de jogo no final do desenvolvimento do jogo. E dizemos: “Aqui está o que achamos que é o
jogo, tente jogá-lo”. E invariavelmente descobrimos que eles não podem jogar. Tem muita coisa
legal aí. Então dizemos: “Tudo bem, onde você está ficando preso?” Estamos essencialmente
incapazes de ver o jogo sob essa luz. Mas você precisa ter a profundidade e a facilidade de entrada.
Ambos são importantes.
Todos os seus jogos são baseados na história ou em eventos da vida real, ao contrário de
muitos jogos que têm cenários de fantasia ou ficção científica. Isso é porque você gosta de
criar um mundo de jogo com o qual o jogador já está um pouco familiarizado?
Eu acho isso importante. Acrescenta muito quando você pode aplicar seu próprio conhecimento a
um jogo. Acho que isso faz você se sentir melhor consigo mesmo, e acho que isso é uma coisa
positiva. Eu acho que também me dá muito mais para trabalhar em termos de uma situação histórica
ou realista. Eu provavelmente cresci em uma época também em que havia menos Terra Média,
fantasia, Guerra nas Estrelas, etc. As crianças hoje em dia pensam que essas coisas são tão reais
quanto a história. Naves espaciais, mágicos e magos são tão reais para muitas crianças quanto
aviões, submarinos e coisas assim. É meio que uma coisa evolucionária, mas no meu crescimento
eram coisas como aviões, submarinos, a Guerra Civil e o Império Romano que eram coisas
interessantes e legais, e eu tento traduzir essas coisas em jogos.
Estou curioso sobre como você equilibra o realismo histórico com a jogabilidade.
Gettysburg! parece ser um caso em que você teve que dividir a jogabilidade em cenários
para mantê-la historicamente precisa e divertida.
Essa foi uma das poucas vezes em que realmente cedemos à realidade histórica. Em geral, nossa
regra é se você entrar em conflito entre diversão e história, você vai com a diversão. Você pode
justificar qualquer decisão do jogo em algum lugar da história. Nossas decisões são feitas quase
exclusivamente para o benefício, espero, da jogabilidade em oposição à precisão histórica. Em
Gettysburg! chegamos a uma situação que simplesmente não conseguíamos fingir, embora tentássemos. Nós
tentamos o máximo que

podíamos para falsificar essa
situação. Em muitas outras
situações chegamos a uma
ideia que achamos que vai
funcionar bem para o jogo e
então encontramos o precedente
histórico ou uma explicação
historicamente para justificá-la.
Em nenhum sentido nós
tentamos ser servilmente
precisos porque, basicamente,
estamos tentando criar uma
situação que é fluida onde você
não está apenas seguindo o
caminho da história, você está
Gettysburg!
criando sua própria história.
Mesmo que as peças sejam realistas, você pode tirá-las em uma direção completamente diferente que
nunca aconteceu. Certamente, parte da diversão de Civilization é que os zulus podem dominar o mundo,
ou os mongóis. Qualquer um pode dominar o mundo; não são necessariamente os americanos que vão
ganhar no final.
Não somos escravos da história.
Pelo menos desde seus dias de desenvolvimento de simuladores de vôo, seus jogos não estão
realmente na vanguarda da tecnologia em termos de gráficos. Foi uma decisão consciente de sua
parte?
Como eu disse, em nosso processo de prototipagem, as coisas mudam quase até o último minuto. A
maioria das tecnologias de ponta são coisas que precisam ser pesquisadas desde o primeiro dia e são
investimentos gigantescos em tecnologia. E como estamos em um modo em que as coisas mudam
constantemente, é praticamente impossível mesclar essas duas abordagens. O projeto de pesquisa não
pode começar realmente a menos que você saiba exatamente o que quer, ou praticamente o que quer.
E geralmente não sabemos disso no início.
E não estamos dispostos a nos colocar nessa camisa de força em termos de design de jogo.
E eu acho que muitas vezes é isso que é. Se você está comprometido com um ponto de vista 3D em
primeira pessoa onde você pode ver uma certa quantidade, e você descobre que para tornar seu jogo
divertido você realmente precisa ver mais, você realmente precisa obter mais contexto para sua
localização ou qualquer outra coisa, você está meio ferrado nesse ponto.
Muitas vezes há um conflito também entre a funcionalidade dos gráficos e a linha de amor dos
gráficos. Um jogo que parece bom, mas não fornece as informações que você precisa para jogar ou não
oferece clareza, acho que essa é a troca errada. Tentamos fazer jogos que achamos bons. Mas em
qualquer bom jogo os ótimos gráficos estão acontecendo na sua imaginação e não na tela. Se lhe
dissermos que as pessoas declararam “nós amamos o dia do rei” em uma determinada cidade, se você
realmente gosta do jogo, isso é muito mais significativo e você cria uma imagem muito mais emocionante
em sua mente do que qualquer outra coisa. nós poderíamos mostrar-lhe na tela. E vice-versa, se você
não estiver no jogo, então qualquer coisa que vier na tela você vai desmontar de qualquer maneira.
Nosso objetivo é
envolvê-lo no próprio jogo e fazer com que você crie suas próprias imagens mentais muito legais com
base em algumas sugestões que damos na tela.
Você foi um dos primeiros designers de jogos a colocar seu nome acima do título na caixa.
Fiquei curioso como isso aconteceu.
Bem, a maneira como isso

aconteceu remonta aos
Piratas! Esse foi o primeiro
jogo que teve meu nome nele.
Naquela época, eu trabalhava
na Microprose e meu parceiro
era Bill Stealey, que fazia o
lado comercial/marketing das
coisas enquanto eu fazia o
desenvolvimento/criativo. E o
jogo anterior antes de Pirates!
era um dos jogos de simulador
de vôo, e eu disse a Bill:
“Bem, vou trabalhar neste Águia de Ataque F-15
jogo sobre piratas”. E ele
disse: “Piratas? Espere um minuto, não há aviões em piratas. Espere um minuto, você não pode
fazer isso.” “Bem, eu acho que vai ser um jogo legal.” E ele respondeu: “Bem, quem vai comprar um
jogo de piratas?
Talvez se colocarmos seu nome nele, eles saberão que gostaram do F-15 ou qualquer outra coisa, e
talvez experimentem. OK." Havia uma preocupação real de que esse jogo de piratas fosse lançado,
mas ninguém vai se interessar, porque quem quer um jogo de piratas? As pessoas querem
simuladores de voo. Então era para dizer: “Claro, você quer um simulador de voo, mas talvez você
queira experimentar este jogo de piratas porque foi escrito pelo cara que escreveu o simulador de
voo que você está jogando”. Eu acho que foi branding de uma forma muito grosseira, inicial. Foi
porque estávamos fazendo essa grande mudança no tipo de jogo em que eu estava trabalhando e
para tentar manter essa conexão entre os jogos.
Então não era o seu desejo de fama?

[risos] Não, não. Ainda hoje, a fama não é uma coisa de jogo de computador. Eu acho que está bom.
Ainda é um negócio bastante não orientado para a personalidade. Acho que as pessoas se lembram
de grandes jogos e sabem até certo ponto quem está envolvido. Mas não há um culto a Robin
Williams ou, você sabe, estrelas de cinema que realmente têm um culto à personalidade. Eu acho
que está bom. Uma vez que tenhamos a ideia de que podemos nos safar de qualquer coisa só porque
somos quem somos, isso não é uma coisa boa.
Mas esse tipo de confiança levou ao Pirates!, não é? [risos]

Bem, foi um bom jogo. Se não fosse um bom jogo, essa estratégia não teria funcionado.
Muitos de seus jogos tiveram sequências de um tipo ou de outro, mas você nunca foi o
designer-chefe de um deles. Por que é isso?
Eu acho que eles são uma coisa boa de se fazer em geral, especialmente se eles forem bem
feitos. Raramente volto a um tópico principalmente porque ainda não fiquei sem ideias, então
prefiro fazer um jogo de dinossauro do que voltar para um título mais antigo. Eu não tenho muita
energia para me envolver muito nas sequências. Alguns deles acabam bem, alguns deles não tão
bem. Ao contrário de deixar o assunto desaparecer, acho que fazer uma sequência é muitas vezes
uma boa ideia. Em um mundo ideal, eu gostaria de estar envolvido em tudo, mas não posso fazer
isso. Então, eu tendo a estar mais interessado em estar envolvido em um novo produto do que em
uma sequência. É certamente gratificante que as pessoas queiram outro Magnata Ferroviário ou
Civilização, etc. Eu acho isso ótimo. Estou feliz que isso possa ser feito. No Civilization III, como
está sendo feito dentro da Firaxis, posso participar mais diretamente nisso, o que acho bom. Eu
gostaria de ter feito Railroad Tycoon II e fazer um novo Pirates!, etc, se eu tivesse uma quantidade
infinita de tempo. Mas simplesmente não é viável.
Eu ouço muitas pessoas falando sobre contar histórias em jogos. Normalmente, por contar
histórias, eles querem dizer usar cutscenes ou árvores de diálogo ramificadas ou dispositivos como
Seus jogos nunca se preocuparam muito com esse lado da narrativa.
Para mim, um jogo de
Civilization é uma história
épica. Acho que o tipo de
história que me interessa é
sobre o jogador e não tanto
sobre o designer. Há
jogadores que se sentem
mais à vontade em situações
em que estão tomando
pequenas decisões e o
designer está tomando as
grandes decisões. Mas acho
que os jogos são mais
interessantes quando o
jogador toma as grandes
decisões e o designer toma
Civilização
as pequenas. Eu acho que,
em certo sentido, os jogos são sobre contar histórias. Eles têm uma história criada mais pelo
jogador e menos pelo designer, na minha cabeça. Acho que em Civilization há histórias fantásticas
em todos os jogos, mas não no sentido mais tradicional de uma história. Temos, entre nossas
regras de game design, as três categorias de jogos. Há jogos em que o designer se diverte, jogos
em que o computador se diverte e jogos em que o jogador se diverte. E achamos que devemos
escrever jogos em que o jogador esteja se divertindo. E eu acho que uma história pode tender a
chegar ao ponto em que o designer está se divertindo ou pelo menos se divertindo muito, e o
jogador é deixado para arrumar algumas decisões ao longo do caminho, mas está realmente sendo
tomada para um passeio. E isso não é necessariamente ruim, mas nossa filosofia é tentar dar
o jogador tanto da tomada de decisão quanto possível.
Embora Gettysburg! tinha uma opção multi-jogador, em geral seus jogos são apenas para um
jogador há muito tempo. O que você acha da popularidade emergente dos jogos multijogador?
Acho que no futuro eu gostaria de entrar mais no modo multijogador, talvez até mesmo em um jogo
que seja principalmente multijogador. Mas eu ainda gosto essencialmente de jogos single-player,
então não tenho certeza exatamente quando ou como isso vai acontecer. Os jogos multijogador
online são provavelmente o único desenvolvimento revolucionário em nossa tecnologia que vimos
desde que comecei a escrever jogos de computador. Todo o resto foi praticamente evolutivo.
Melhores gráficos, melhor velocidade, mais memória, etc. Mas o multiplayer online foi uma mudança
revolucionária nas ferramentas que tínhamos para fazer jogos. Estou interessado em fazer algo nesse
sentido, mas não tenho certeza do que seria agora.
Em uma antiga entrevista para a revista Next Generation , você disse: “Os jogos vão dominar o
mundo. Vai demorar um pouco, mas há algo inerentemente mais envolvente nos jogos de
computador do que em qualquer outra forma de entretenimento.” Os jogos de tabuleiro
certamente existem há muito tempo, mas ainda não dominaram o mundo. Eu me perguntei o
que há nos jogos de computador que você acha tão atraente.
Sim, acho que mantenho essa afirmação. Acho que é o elemento de interatividade que os torna
únicos. Eles interagem pessoalmente com você como jogador, ao contrário de filmes, televisão ou
música, que não o fazem. Há esse fenômeno de assistir televisão e usar o controle remoto para
tentar desesperadamente torná-lo uma experiência interativa, passando de um canal para outro...
[risos] Mas a interatividade dos jogos de computador é o que o diferencia e o torna tão poderoso.
Agora, ainda estamos aprendendo a usar essa ferramenta e de muitas outras maneiras não somos
tão bons quanto a televisão, filmes etc.
Mas acho que à medida que aprendemos a usar as vantagens que temos, elas se tornam vantagens
mais poderosas do que as vantagens de outras mídias de entretenimento.
Acho que os jogos de tabuleiro são meio interativos, mas exigem outros jogadores. O computador
traz muito poder à equação que os jogos de tabuleiro não aproveitam. Se alguma coisa, o advento
da Internet e o jogo multi-jogador, combinado com a interatividade, me parece uma combinação
realmente poderosa. Acho que à medida que aprendemos a usar esse elemento de nossa tecnologia
também, os jogos podem ser muito, muito atraentes. A pergunta que surge é se as pessoas querem
jogos que sejam tão interessantes para jogar? Havia todo o fenômeno Deer Hunter , e havia Slingo e
coisas assim e ainda estou trabalhando para integrar isso ao meu modelo de mundo, e não consegui
fazer isso totalmente. Mas o que isso me diz é que há uma gama mais ampla de jogadores em
potencial do que estou realmente familiarizado. E parte do nosso processo de aprendizado será
integrá-los na maneira como projetamos jogos e na maneira como criamos jogos. Mas ainda acho
que vamos dominar o mundo.
Sid Meier Gameografia

Hellcat Ace, 1982 NATO
Commander, 1983 Spitfire
Ace, 1984 Solo Flight,
1984 F-15 Strike Eagle,
1985 Decision in the
Desert, 1985 Conflict in
Vietnam, 1985 Crusade in
Europe, 1985 Silent Service,
1986 Gunship, 1986
Pirates !, 1987 F-19 Stealth
Fighter, 1988 Railroad
Tycoon, 1990 Covert Action,
1990 Civilization, 1991
Colonization, 1994 (Consultor)
Civilization II, 1996 (Consultor)

Gettysburg!, 1997
Alpha Centauri, 1999 (Consultor)
Civilization III, 2001 (Consultor)
SimGolf, 2002
Capítulo 3
Brainstorming um
Ideia de jogo:
Jogabilidade,
Tecnologia, e
História
“Sabe qual é a pergunta mais idiota número um que me fazem quando estou dando uma
palestra em uma grande universidade? Sempre me perguntam 'De onde você tira suas
ideias?' Há cerca de quarenta anos venho puxando a corrente deles quando respondo
'Schenectady'. Eles me encaram e eu digo: 'Sim, Schenectady, em Nova York.
Tem esse serviço de ideias, veja, e toda semana eu mando vinte e cinco dólares para eles,
e toda semana eles me mandam um pacote de seis ideias recém-escolhidas.'”
— Harlan Ellison
40
Capítulo 3: Brainstorming de uma ideia de jogo 41
a partir de. Certamente, se você é um romancista com problemas para ter ideias,
Harlan Ellison
pode serpode zombar
hora de da ideia
se perguntar deescolheu
se você tentar explicar
a profissãode onde
certa. vêm as
Da mesma ideias
forma,
um bom designer de jogos, a qualquer momento, será capaz de apresentar nada menos que cinco
ideias sólidas que gostaria de tentar transformar em um jogo de computador. Não faltam ideias no
mundo dos jogos. Aspirantes a designers de jogos geralmente pensam que podem vender sua
ideia para uma empresa de desenvolvimento. Eles parecem ter a impressão de que os
desenvolvedores de jogos estão apenas sentados esperando que uma ideia quente apareça para
que possam gastar vários milhões de dólares para torná-la realidade. Pelo contrário, vender uma
ideia de jogo para uma empresa é tão raro que deve ser considerado uma impossibilidade. Quase
todo o desafio no desenvolvimento de jogos não é ter uma boa ideia, mas seguir adiante e ser
capaz de criar um jogo atraente em torno dessa ideia. É isso que o restante deste livro procura
explorar.
Na arena do design de jogos de computador, o processo de criar uma ideia de jogo
que funcione é complicado por vários fatores com os quais os autores de ficção não
precisam se preocupar. Em parte, isso ocorre porque as idéias de jogos de computador
podem vir de três áreas distintas e não relacionadas da forma: jogabilidade, tecnologia e
história. Essas diferentes origens estão interligadas de maneiras interessantes, com a
origem da ideia do jogo limitando o que se poderá realizar nas outras duas áreas. Portanto,
quando um designer de jogos começa a pensar no jogo que espera fazer – pensando em
termos de jogabilidade, tecnologia ou história – é importante que ele considere como essa
ideia inicial afetará todos os aspectos do jogo final.
Pontos de partida
Talvez um exemplo rápido esteja em ordem. Digamos que um designer de jogos sinta a necessidade
de criar um jogo baseado em histórias específicas da mitologia grega. Isso seria a partir de uma
história. Imediatamente, isso limita o tipo de jogabilidade que ela fará. As chances são de que um
jogo de estratégia no estilo Civilization tenha sido lançado, já que esse tipo de jogo realmente não
tem nada a ver com as histórias clássicas de Zeus, Heracles, Ares e assim por diante. Um jogo de
estratégia em tempo real também está fora de questão, pois não é bom para contar histórias
envolvendo apenas alguns protagonistas. Um simulador de voo de última geração provavelmente
também não funcionará. O designer poderia, no entanto, persegui-lo por meio de um jogo de ação,
um jogo de RPG ou um jogo de aventura. Da mesma forma, a tecnologia é limitada. A fim de contar
a história dos deuses gregos, o designer precisará de alguma forma de comunicar muitas
informações sobre a história ao jogador. Assim, será necessário haver tecnologia no local que possa permit
Além disso, se o designer escolher a tecnologia a ser empregada pelo jogo neste
momento, isso terá um impacto ainda maior em que tipo de jogabilidade será possível.
Por exemplo, escolher um motor 2D isométrico será melhor para um RPG ou um jogo
de aventura em vez de um jogo de ação, a menos que alguém planeje ser
deliberadamente “retrô” e opte por uma ação-aventura 2D no espírito de Crusader: No
Remorse . Se uma tecnologia 3D for usada, para contar a história da mitologia grega
adequadamente, ela precisará suportar ambientes internos e externos, o que elimina
imediatamente muitos mecanismos de jogos 3D.
42 Capítulo 3: Brainstorming de uma ideia de jogo
Para cada decisão que o designer toma sobre o jogo que espera criar, ela precisa entender como isso limita
o que o jogo será. Se o designer tentar encaixar um tipo de jogabilidade em torno de um motor inadequado, o
jogo sofrerá no final. Tentar fazer um “god-sim” ao estilo Populous usando um motor 3D interno em primeira
pessoa no estilo Unreal é um grande erro. Assim como se alguém tentasse contar a história dos deuses gregos
através de um simulador de vôo, o jogo simplesmente não funcionava. Aqui reside a dificuldade com muitas ideias
de “alto conceito”, muitas vezes fruto da imaginação de especialistas em marketing que querem capturar mercados
díspares com um produto. Se as partes não funcionarem juntas, não importa quantos mercados o conceito
abranja – nenhum jogador estará interessado em jogar o jogo final.
Começando com a jogabilidade

Começar com a jogabilidade é um dos pontos de partida mais comuns para o desenvolvimento de jogos,
especialmente para projetos orientados por designers ou gerenciamento. Pensar em um estilo de jogo geralmente
é o núcleo mais fácil para alguém se agarrar, especialmente se essa jogabilidade for semelhante a um jogo
existente. “É um jogo de corrida!” “É um simulador de voo!”
“É uma ação/aventura em 3D como Super Mario 64!” “É um jogo de tiro em primeira pessoa como Halo!”
Muitas vezes, um desenvolvedor de jogos terá gostado de um jogo em um desses gêneros e desejará aplicar seu
próprio toque a ele. Com uma ideia geral para um jogo que seja interessante para ela, o designer vai querer
descobrir o que seu jogo em particular vai realizar em termos de jogabilidade. Que tipo de jogo de corrida será?
Que aspectos das corridas estamos tentando capturar para o jogador? Com uma ideia mais específica de que
tipo de jogabilidade ela deseja criar, o designer deve começar a pensar em como isso afetará a tecnologia que o
jogo exigirá e que tipo de história, se houver, o jogo poderá ter.
Dependendo do tipo de jogabilidade que você espera criar para o jogador, você precisa analisar que tipo de
tecnologia esse empreendimento exigirá. O jogo precisa de uma engine 3D, ou 2D será suficiente ou até mais
apropriado? Que tipo de visão o jogador terá do mundo do jogo? Será fixo ou dinâmico? A ação transcorre rápido
e furioso com um grande número de entidades se movendo na tela ao mesmo tempo? Os mundos do jogo são
grandes ou pequenos? Todas essas questões e muitas outras precisam ser analisadas para entender o que a
engine do jogo deve realizar para executar corretamente a ideia de jogabilidade. É claro que a tecnologia que
você escolhe empregar para o seu jogo deve realmente ser executada no sistema de destino, seja um PC,
console ou gabinete de arcade feito sob medida. Você também deve perguntar se a equipe de programação do
jogo está preparada para criar a tecnologia necessária. A viabilidade tecnológica pode acabar limitando o alcance
da sua jogabilidade. Pior ainda, a tecnologia existente da equipe de motores funcionará ou eles precisarão
descartá-la e começar do zero? Existe orçamento e tempo suficientes para descartá-lo e começar de novo? Se
você achar que precisa adaptar sua jogabilidade para combinar com a engine, você realmente não está
começando com a jogabilidade como a origem de sua ideia, mas sim com a tecnologia, como discutirei a seguir.
Se você está começando com um mecanismo de jogo que deve ser usado, é de seu interesse não combater essa
tecnologia com uma jogabilidade incompatível. Em vez disso, você deve tentar conceber uma jogabilidade que
seja adequada para esse mecanismo.
O tipo de jogabilidade que seu jogo empregará limita de maneira semelhante o tipo de história que pode ser
contada. Um RPG pode contar uma história muito mais complexa e envolvente do que um jogo de ação/aventura
e, por sua vez, uma ação/aventura pode contar uma história mais substancial do que um jogo de ação/aventura.
atirador de arcade. Certos tipos de histórias simplesmente não se encaixam em certos tipos de
jogabilidade, como a mitologia grega em um exemplo de simulador de vôo discutido anteriormente.
Da mesma forma, uma história romântica pode não se encaixar em um jogo de estratégia, e uma
história sobre diplomacia não se encaixaria tão bem em um jogo de tiro em primeira pessoa de
ação rápida. Já que você fez a escolha de criar seu estilo de jogo primeiro, você precisa se
perguntar que tipo de história é mais adequada para esse jogo e tentar contar essa história. Às
vezes, um designer terá uma história que deseja contar e um tipo de jogabilidade que deseja
explorar, e tentará fazer as duas coisas no mesmo jogo, mesmo que as duas não funcionem bem
juntas. Não tente remendar uma história inadequada, seja em termos de complexidade ou assunto,
em torno de uma jogabilidade inadequada para esse tipo de narrativa. Salve a história para uma
data posterior, quando estiver trabalhando em um título com jogabilidade que apoie melhor essa
história. E enquanto sua tecnologia é limitada pelo que sua equipe é capaz de realizar no tempo
alocado, a história é limitada apenas por sua própria capacidade de contá-la. Você deve escolher
a história mais adequada ao seu jogo e seguir em frente.
Começando pela tecnologia

Entrar em um projeto com grande parte da tecnologia do jogo já desenvolvida também é uma
ocorrência bastante comum. Se este não for o primeiro projeto da equipe de desenvolvimento
juntos em uma nova empresa, é provável que haja uma base tecnológica existente a partir da qual
o projeto deve ser construído. Mesmo que o projeto use um mecanismo “novo”, isso geralmente
significa apenas um mecanismo mais antigo atualizado e, como resultado, o estilo de jogo mais
adequado ao mecanismo não mudará significativamente. Mesmo que uma engine esteja sendo
escrita do zero para o projeto, é provável que o programador líder e sua equipe estejam melhor
equipados para criar um determinado tipo de engine, seja indoor ou outdoor, em tempo real ou pré-
renderizado, 3D ou 2D, com um sistema de física complexo para movimento de objetos ou algo
mais simples. Os programadores podem estar interessados em experimentar certos efeitos
especiais de iluminação ou renderização e criarão um mecanismo que se destaque nesses
objetivos. O designer é então apresentado a essa nova tecnologia e encarregado de criar um jogo
que explorará a tecnologia sofisticada com pleno efeito.
Outras vezes, é predeterminado que o projeto usará um mecanismo licenciado de alguma
outra fonte, seja de outro desenvolvedor de jogos ou de uma empresa apenas de tecnologia.
Embora alguns desses mecanismos licenciados estejam se tornando cada vez mais robustos e,
como resultado, possam permitir que um número bastante amplo de jogos seja feito com eles (o
RenderWare da Criterion é certamente um bom exemplo disso), muitos mecanismos licenciados
ainda são desenvolvidos com um gênero de jogo em mente, e nenhum motor está sem suas
limitações fundamentais. Às vezes, os líderes do projeto têm previsão suficiente para considerar o
tipo de jogo que desejam fazer primeiro e depois escolher um mecanismo adequado para isso. Às
vezes, o acordo de licenciamento do motor que parece oferecer o maior retorno possível será o
escolhido. Então, com uma escolha de mecanismo decidida, a equipe é encarregada de criar um
jogo e uma história que se encaixem bem usando essa tecnologia.
Assim como começar com um tipo de jogabilidade desejado determina que tipo de mecanismo
deve ser criado, começar com a tecnologia de conjunto exige que o designer do jogo considere
principalmente a jogabilidade que funcionará com esse tipo de tecnologia. Se o motor for 3D, o
designer precisará criar um jogo que se passe em um mundo 3D e usar esse mundo para criar
uma jogabilidade 3D interessante. Se o motor for apenas 2D, um jogo de tiro em primeira pessoa
está fora de questão. Se o motor tiver um sistema de física sofisticado, um jogo deve ser
projetado que faz uso da física para quebra-cabeças e movimento do jogador. É claro que o
designer não precisa usar todas as peças de tecnologia que um programador se sente compelido
a criar, mas é sempre melhor fazer com que sua jogabilidade funcione com o mecanismo em vez
de lutar contra ele. Muitas vezes, quando um projeto está usando um mecanismo de jogo licenciado,
essa tecnologia será escolhida com um certo tipo de jogabilidade em mente. O projetista precisa
considerar seriamente até que ponto deve se desviar dessa tecnologia inicial, pois certamente será
mais fácil fazer com que o mecanismo execute as tarefas para as quais foi projetado, em vez de
empurrá-lo em direções que seus programadores nunca imaginaram. Por exemplo, o motor Quake
frequentemente licenciado (em todas as suas várias encarnações) foi criado para lidar com um
jogo de ação rápida e perspectiva interna em primeira pessoa envolvendo muitos tiros. Embora
algumas equipes que licenciaram esse mecanismo tenham tentado empurrá-lo em direções
diferentes, um dos licenciados mais bem-sucedidos artisticamente até agora, a Valve, manteve
grande parte da jogabilidade padrão do Quake em que o mecanismo se destacou para o jogo Half-
Life. Certamente a Valve adicionou muito do seu próprio trabalho ao motor, tecnologia que era
necessária para fazer o tipo de jogo que eles queriam. Mas, ao mesmo tempo, eles não tentaram
fazer algo tolo, como definir seu jogo principalmente ao ar livre ou usar apenas combate corpo a
corpo, pelo menos não em seu primeiro título com a tecnologia. Quando a tecnologia é entregue a
um designer de jogos que é instruído a fazer um jogo com isso, faz mais sentido para o designer
abraçar as limitações dessa tecnologia e transformá-las em pontos fortes em seu jogo.
Os designers de
Half-Life usaram
inteligentemente a
jogabilidade de tiro em
primeira pessoa interna
estabelecida por Quake, a
engine licenciada para a criação do jogo.
Retratado aqui: Terremoto II.
A tecnologia também pode limitar que tipo de história pode ser contada. Sem um analisador
de linguagem sofisticado, será difícil contar uma história em que os jogadores precisem se
comunicar com os personagens digitando perguntas. Sem um motor que possa lidar razoavelmente
bem com ambientes externos, será difícil fazer um jogo sobre alpinismo. Sem inteligência artificial
robusta, será difícil fazer um bom jogo sobre diplomacia. Sem a tecnologia de streaming que
permite a reprodução de grandes sons, será difícil ter grandes quantidades de diálogo e, portanto,
difícil ter personagens cujos dialetos sejam importantes para a história. Sem a capacidade de ter
grandes
número de unidades móveis na tela ao mesmo tempo, será impossível contar uma história em que o
jogador deve participar de batalhas épicas e massivas entre exércitos. O designer de jogos precisa
considerar como a história será comunicada ao jogador através da engine que ele deve usar. Tentar
contar uma história com um mecanismo inadequado pode comprometer o jogo tanto quanto vincular
uma história específica a uma jogabilidade inadequada. Novamente usando o exemplo do Half-Life
mencionado acima, se a equipe da Valve tivesse tentado definir seu jogo no Vale da Morte e envolver
o jogador lutando contra gangues de vinte insetos gigantes de uma só vez, o mecanismo do Quake
teria parado nas máquinas do dia e o jogo teria sido miserável de jogar. No cenário do Vale da Morte,
a Valve poderia estar contando a história que eles queriam, mas ninguém se importaria, já que o
jogo teria sido miseravelmente lento e horrível. Para o bem maior do jogo, a história e a tecnologia
devem ser compatíveis entre si.
Outra coisa a ter sempre em mente ao considerar como sua tecnologia limitará sua jogabilidade
e história é como você pode trabalhar criativamente em torno de suas limitações.
Por exemplo, se você está tentando fazer um jogo sobre batalhas massivas com milhares de
unidades individuais, todas as unidades precisam ser representadas em 3D, ou uma representação
em 2D também funcionará? Ou talvez você nunca precise ter todas as unidades do mundo ao mesmo
tempo; você poderia contar a história de um conflito tão gigantesco do ponto de vista de um único
soldado naquela batalha, com atualizações entre missões que mostram o quadro maior.
Para um exemplo do meu próprio passado, meu malfadado jogo Gunslinger tentou capturar os mitos
e a narrativa do Velho Oeste. Tínhamos uma tecnologia que era perfeitamente adequada para
renderizar ambientes externos em 3D, então era um ajuste natural ao jogo.
Mas se tivéssemos apenas um motor 2D, não há nada para dizer que ainda não poderíamos ter feito
uma história sobre as lendas do Velho Oeste em um jogo 2D com uma visão de deus dos
procedimentos. Como designer de jogos, é possível ficar preso em uma rotina de como um jogo
“precisa ser feito” e esquecer o potencial de implementações alternativas que podem ser mais
adequadas para sua tecnologia.
Começando pela história

Finalmente, é certamente possível que o brainstorming para o seu jogo comece com um cenário que
você deseja empregar, uma história que deseja contar ou um conjunto de personagens que deseja
explorar. Este é provavelmente um ponto de partida menos comum do que tecnologia ou jogabilidade.
De fato, como muitos jogos não têm história alguma, o próprio conceito de um jogo que começa
com uma história pode parecer estranho. Ao mesmo tempo, não é inédito para um designer de jogos
pensar em uma história que deseja explorar e só então começar a explorar que tipo de tecnologia e
jogabilidade será mais adequada para contar essa história. Frequentemente, um cenário em particular
pode inspirar um designer de jogos, como o mundo aventureiro de Errol Flynn ou o mundo sombrio
e sombrio do crime de Sin City. Um designer pode não se importar muito com as especificidades do
enredo, mas pode ter um forte desejo de trabalhar em um mundo cheio de fanfarrões ou detetives
particulares sombrios. Para meus propósitos neste capítulo, considero que esses cenários
inspiradores se enquadram na definição de começar com a história.
Qualquer bom designer de jogos que pense em uma história ou cenário terá a tendência de
pensar em como isso se traduziria em um jogo, como o jogador pode interagir com essa história e
como a história pode se desenrolar de maneiras diferentes dependendo nas ações do jogador no
mundo do jogo. De fato, nem todas as histórias se traduzirão muito bem em
jogos, e pensar nas possibilidades de jogabilidade antecipadamente pode ajudá-lo a descartar

configurações que simplesmente não funcionarão nos jogos. Portanto, um designer pode não estar
pensando apenas na história, mas também na jogabilidade. Mas a história pode ser o ponto de partida,
a visão central a partir da qual todos os outros aspectos do jogo são determinados.
É claro que o tipo de história a ser contada terá um efeito dramático no tipo de jogabilidade que o
projeto precisará ter. Se o designer quiser contar a história de um grupo de amigos lutando em um
mundo fantástico cheio de criaturas hostis, um jogo de tiro em primeira pessoa com colegas de equipe
pode ser apropriado. Qualquer tipo de história que envolva o jogador conversando com uma grande
variedade de personagens e fazendo “missões” para esses personagens pode ser abordada com mais
mecânicas no estilo RPG. Contar a história da Batalha de Waterloo poderia ser perfeitamente abordado
em um projeto com jogo estratégico no estilo de jogo de guerra, com a jogabilidade ajustada para melhor
destacar os aspectos de Waterloo com os quais o designer está preocupado principalmente. O designer
quer que o jogador tenha uma visão geral do jogo? Nesse caso, deve-se usar uma jogabilidade que
permita o rastreamento de táticas e logística. Ou o designer quer contar a história mais do ponto de
vista dos soldados que tiveram que lutar naquela batalha? Então a jogabilidade que permitiria ao jogador
rastrear e manipular suas tropas unidade por unidade seria apropriada. Se as conversas com
personagens não-jogadores (NPCs) são uma parte importante da comunicação da história, o designer
precisará projetar mecânicas de jogo que permitam essas conversas, usando frases digitadas, opções
de diálogo ramificadas ou o que funcionar melhor. O designer precisa encontrar uma jogabilidade que
permita ao jogador experimentar os elementos mais importantes de qualquer história que ele esteja
tentando contar.
É claro que a tecnologia também terá que combinar com a história, principalmente para apoiar a
jogabilidade que o designer decidir ser mais adequada para contar essa história. Se as conversas são
uma parte importante da comunicação da história, a equipe de programação precisará desenvolver um
sistema de conversação. Se a exploração e descoberta do mundo são uma grande parte da história,
talvez um mecanismo 3D seja o mais adequado para a jogabilidade – um que permita que os jogadores
olhem para onde quiserem com a câmera do jogo. O designer pode achar que eventos especificamente
roteirizados são importantes para comunicar aspectos da história; os jogadores devem ser capazes de
observar eventos únicos que ocorrem em momentos específicos em diferentes partes do mundo. Nesse
caso, os programadores precisarão fornecer aos designers de nível a capacidade de implementar essas
cenas. A tecnologia é o meio de comunicação para os jogadores e, portanto, a história é diretamente
limitada pelo que a tecnologia é capaz de contar.
Maniac Mansion foi o

primeiro dos jogos de
aventura centrados na
história da LucasArts a
usar o sistema SCUMM.
Bons exemplos de design de jogo centrado na história ou pelo menos dominante na

história são alguns dos jogos de aventura criados pela Infocom e LucasArts. Todos os jogos de
aventura dessas empresas usavam mecânica e tecnologia de jogo muito padronizadas. Os
designers de jogos trabalharam com a tecnologia de criação de jogos de aventura proprietária
da empresa, seja a ferramenta de autoria de aventura de texto Infocom ou o sistema SCUMM
da LucasArts. Quando a designer de jogos entrou no projeto, seu processo de criação poderia
começar mais naturalmente com a criação de uma história que ela queria contar. Certamente a
história tinha que ser adequada ao formato do jogo de aventura e que pudesse ser implementada
usando o conjunto de ferramentas existente. E, claro, havia muito design de jogo ainda a ser
feito, em termos de quais seriam as ações e escolhas do jogador naquela história específica,
quais quebra-cabeças seriam encontrados e assim por diante. As ferramentas da Infocom e da
LucasArts eram de propósito geral o suficiente para permitir que o designer criasse uma ampla
gama de jogos, com uma boa quantidade de variação em termos de possibilidades de contar
histórias, mesmo que a mecânica principal tivesse que consistir em uma aventura de texto
centrada na digitação no caso da Infocom e uma aventura gráfica de apontar e clicar para
LucasArts. Assim, a principal motivação motriz dos designers de jogos na criação do jogo pode
ser contar uma história, com o design da mecânica do jogo e o desenvolvimento de tecnologia
muito menos preocupantes. Assim como os diretores de cinema são limitados pelo que podem
filmar com uma câmera e depois projetar em uma tela 2D de um determinado tamanho a 24
quadros por segundo, os designers de jogos de aventura da Infocom e da LucasArts foram
limitados pela mecânica da autoria do jogo de aventura. sistema que estavam usando. Como a
mecânica do meio estava firmemente estabelecida bem antes de o diretor de cinema e o
designer de jogos de aventura começarem seu projeto, eles foram liberados para pensar além
das porcas e parafusos da audiência ou da experiência de jogo do usuário.
Trabalhando com Limitações

Designers de jogos experientes já entendem as limitações impostas à criação de jogos pela
tecnologia, jogabilidade e história. Quando participam de sessões de brainstorming, esses
designers de jogos têm uma boa noção de como fazer certas escolhas sobre o jogo em questão
limitará sua criação mais adiante. Para cada decisão tomada sobre o jogo, muitas portas se
fecham. Quando decisões suficientes sobre a natureza do jogo tiverem sido tomadas, pode ser
que haja apenas um tipo de jogo que possa realizar tudo o que os designers desejam. O estágio
para a tomada de decisões importantes acabou, e agora tudo o que temos pela frente são os
milhares de pequenos problemas de implementação.
Para quatro dos jogos que completei – Odyssey: The Legend of Nemesis, Damage
Incorporated, Centipede 3D e The Suffering – comecei o desenvolvimento a partir de diferentes
pontos de partida. Coincidentemente, um jogo começou com história, outro com tecnologia, o
terceiro com jogabilidade e o final com uma combinação de cenário e jogabilidade.
Ao longo do desenvolvimento de cada jogo, fiz todos os esforços para lembrar de onde o jogo
estava vindo e o que esperava realizar. As origens e os objetivos limitaram todo o resto da
experiência, resultando em apenas um jogo aceitável que atingiu os objetivos que eu havia
estabelecido.
Odisseia: A Lenda de Nêmesis

Odyssey começou com uma história. Na verdade, eu herdei esse projeto em um ponto em que uma parte
significativa da tecnologia 2D e da mecânica dos jogos de RPG estavam em vigor. Alguma história
existia, mas não era de forma alguma completo, e eu não estava muito animado com isso. Como meu primeiro
projeto de jogo que provavelmente seria publicado, imediatamente comecei a trabalhar para reescrever a
história em algo em que eu estava pessoalmente investido. Durante anos estive
querendo entrar no desenvolvimento de jogos para contar histórias interativas e não lineares,
e então eu imediatamente comecei a escrever exatamente essa história, na qual o jogador seria presenteado
com escolhas morais além de apenas “matar ou não matar”. queria criar um jogo
em que as escolhas feitas pelos jogadores realmente mudariam o resultado da história
de forma significativa. Então eu avancei cegamente, com a história como minha única preocupação.
Níveis em Odyssey: The

Legend of Nemesis foram
projetado em torno do
história do jogo.
Felizmente, a tecnologia e a mecânica do jogo que estavam em vigor em geral

apoiou essa história que eu queria contar. Onde não o fizeram, mudei a mecânica do jogo conforme necessário.
Quando o NPC AI teve que funcionar de uma certa maneira para apoiar a história, eu
fez a IA funcionar dessa maneira. Quando as conversas forçadas se tornaram necessárias, onde um
NPC poderia caminhar até o jogador e iniciar uma conversa com ele em vez do
ao contrário, implementei a mecânica de jogo apropriada. Os níveis foram
projetado com nenhum outro objetivo além de apoiar a história. Desde que eu estava principalmente interessado
na história, os níveis do jogo não foram projetados com batalhas emocionantes em mente e as situações de
combate no jogo não eram tão atraentes quanto poderiam ter sido. O
constante conflito com criaturas estranhas e saqueadoras era algo que as pessoas esperavam em
um RPG e assim permaneceu, mas fiz o combate de tal forma que era muito secundário
para explorar a história. Isso acabou tornando o jogo quase mais uma aventura do que um RPG, mas para mim
tudo bem, já que era o que melhor sustentava a história.
Olhando para ele hoje, posso ver que o Odyssey tem muitas falhas. Mas eu não acho que
esses problemas surgiram porque era um jogo cujo desenvolvimento começou com uma história.
Esta pode ser uma maneira rara de começar o desenvolvimento de jogos, mas ainda pode ser um começo viável
ponto. Se eu tivesse um melhor senso de design de jogos na época, eu poderia ter levado
esforços para tornar o resto do jogo tão interessante quanto a história, sem nunca prejudicar
ou diminuir o impacto do conto épico do jogo.
Danos Incorporados
No caso da Damage Incorporated, a editora, MacSoft, obteve a licença para uma tecnologia
sofisticada (na época) que eles queriam usar para um jogo. Era a engine que a Bungie
Software havia criado para uso em Marathon e Marathon 2, dois jogos que eu gosto e admiro.
Em particular, Marathon 2 continua sendo um dos melhores jogos de tiro em primeira pessoa
já feitos, facilmente se mantendo contra seu contemporâneo para PC, Doom. O que faltava
em Marathon 2 em batalhas de ação rápida e a atmosfera de ameaça que Doom criou tão
bem, mais do que compensou com uma história atraente e complexa, design de nível superior
e um bom (embora simples) modelo de física. De fato, o Halo da Bungie se baseou nas
muitas inovações da Marathon , finalmente trazendo-as para um público mais amplo. Como
resultado de ter gostado tanto dos jogos Marathon , decidi fazer com que meu jogo adotasse
a tecnologia e a jogabilidade que Marathon havia estabelecido. Eu criaria meu jogo em torno
da tecnologia que havia sido licenciada e usaria essa tecnologia com o maior efeito possível.
A Damage Incorporated
(foto) teve suas origens
na tecnologia licenciada
Marathon .
Com um ponto de partida na tecnologia, criei uma jogabilidade e uma história que
poderia ter sucesso usando a tecnologia Marathon . Claro, adicionamos recursos à
jogabilidade e ao mecanismo. A principal adição à mecânica do jogo foi a capacidade do
jogador de ordenar companheiros de equipe ao redor do mundo do jogo, adicionando assim
um elemento de estratégia em tempo real à mistura. Adicionamos ao mecanismo vários
aprimoramentos que permitiram portas giratórias, objetos em movimento e outros efeitos
necessários para criar um mundo de jogo mais parecido com o mundo real. Eu ainda estava
preocupado com a história do jogo, embora não tanto quanto com Odyssey. Como conversar
com os NPCs não se encaixava muito na mecânica de jogo de Marathon , trabalhei com
personagens interessantes na experiência de jogo através dos companheiros de equipe do
jogador. Esses companheiros fuzileiros conversavam entre si enquanto o jogador os manobrava pelo
Uma das fraquezas do jogo era que no início do projeto eu não entendia completamente
as limitações do motor Marathon . Era mais adequado para criar ambientes internos, então as
áreas externas acabaram parecendo falsas, especialmente quando deveriam representar locais
da vida real na Terra. Modelar o exterior de um mundo alienígena no motor, como Marathon 2
havia feito, era uma coisa, mas criar ambientes que se parecessem com a floresta de Nebraska
era outra. Cerca de metade dos níveis em Damage Incorporated são definidos do lado de fora,
e nenhuma dessas áreas externas acabou parecendo muito boa. Se eu tivesse entendido
melhor a tecnologia, poderia ter projetado o jogo para se passar em mais ambientes internos,
explorando melhor o que o motor fazia bem.
Curiosamente, ao mesmo tempo em que eu estava usando o motor Marathon 2 para criar
a Dam age Incorporated, a MacSoft tinha outra equipe usando o mesmo motor para criar um
jogo chamado Prime Target. Os membros dessa equipe não gostaram tanto de Marathon 2
quanto eu, e queriam criar mais um shooter no estilo Doom, com combate mais rápido, simples
e intenso. Em vez de começar com a tecnologia e rodar com o tipo de jogabilidade que ela
lidava bem, eles começaram com um tipo de jogabilidade que queriam alcançar e modificaram
o motor para melhor suportar isso. Como resultado, a equipe Prime Target gastou muito mais
tempo modificando o mecanismo para atender às suas necessidades do que nós. Por outro
lado, eles foram sábios o suficiente para definir seu jogo principalmente em ambientes fechados,
um ambiente muito mais adequado à tecnologia. Por causa de nossas diferentes decisões
sobre como usar a tecnologia, Prime Target tornou-se um jogo significativamente diferente de
Marathon 2 ou Damage Incorporated. Não é um jogo melhor ou pior, apenas diferente. As
diferenças podem ser rastreadas até as origens da ideia para o jogo e a maneira como eles se
aproximaram usando um mecanismo licenciado.
Centipede 3D O
projeto Centipede 3D foi iniciado quando a editora, Hasbro Interactive, abordou o desenvolvedor
do jogo, Leaping Lizard Software, sobre o uso de sua tecnologia Raider para uma nova versão
do Centipede. A Hasbro havia encontrado recentemente sucesso com a modernização de
Frogger e queria fazer o mesmo com Centipede, os direitos que haviam comprado recentemente.
Os produtores da Hasbro viram uma prévia de Raider em uma revista e acharam que poderia
ser adequado ao projeto. A Hasbro tinha uma ideia muito definida sobre o tipo de jogabilidade
que eles queriam para o Centipede 3D: mecânica de jogo semelhante ao clássico Centipede ,
exceto em um mundo 3D. A equipe do Leaping Lizard concordou. Na época, poucos jogos
utilizavam uma jogabilidade simples e elegante no estilo arcade, e adaptá-lo para um mundo
3D seria um desafio único.
Para o desenvolvimento do Centipede 3D, a origem do desenvolvimento do jogo estava
na jogabilidade. Recriar a sensação do Centipede original estava na vanguarda das mentes de
todos durante o desenvolvimento do projeto. Quando a Hasbro partiu para encontrar uma
empresa com uma tecnologia capaz de lidar com o jogo, eles souberam procurar um motor que
pudesse lidar com áreas maiores e mais externas, porque esses eram os tipos de locais que
uma Centipede modernizada exigiria. Eles sabiam que não deveriam usar uma tecnologia no
estilo Quake para alcançar a jogabilidade que queriam. Leaping Lizard's Raider engine foi uma
boa combinação com a jogabilidade, mas não perfeita. Muito trabalho foi necessário para
modificá-lo para alcançar a capacidade de resposta de um jogo de arcade clássico. Raider
empregou um sistema de física que em geral não era necessário para Centipede 3D, e assim
A nova versão 3D do
Centipede foi baseada na
jogabilidade clássica de
“atirador de insetos”
encontrada no Centipede original.
a maior parte foi retirada. Assim, a tecnologia foi moldada para se adequar à jogabilidade
desejada.
A história do Centipede 3D foi a mais simples de todos os jogos em que trabalhei. Em
parte, isso ocorre porque uma das características de um jogo de arcade clássico é a falta de
uma narrativa real. Para jogos como Centipede, Pac-Man e Space Invaders, o cenário era
suficiente; todos os jogos necessários eram uma premissa básica através da qual a jogabilidade
poderia ocorrer. Além disso, todos que trabalhavam no projeto Centipede 3D perceberam que
era a jogabilidade simples e viciante que atrairia os jogadores para o Centipede 3D, não a história.
O estilo de jogo arcade clássico simplesmente não exigia isso. O principal efeito do enredo
escasso foi fornecer uma configuração e afetar a aparência do jogo, explicar por que o jogador
está voando em torno de centopéias e cogumelos, e por que os mundos do jogo mudam de
aparência a cada poucos níveis. Assim como o Centipede original usou o cenário de um jardim
e insetos para justificar a jogabilidade do jogo, o remake também. No final, Centipede 3D era
tudo sobre a jogabilidade.
O sofrimento
Meu jogo mais recente, The Suffering, teve suas origens em uma combinação de cenário e
jogabilidade. A editora do jogo, Midway, sugeriu ao desenvolvedor do jogo, Surreal Software,
que eles queriam um jogo de ação, de preferência um atirador, ambientado em um ambiente de terror.
Surreal estava animado com a perspectiva de trabalhar em um espaço de terror, mas não
éramos grandes fãs da mecânica de jogo que até então dominava o gênero. Jogos como
Resident Evil e Silent Hill, embora muito bons, dependiam de assustar o jogador limitando sua
capacidade de olhar o ambiente com a câmera, tendo controles desajeitados e sem resposta,
limitando estritamente a munição disponível e usando protagonistas centrais bastante fracos.
Isso teve o efeito de distanciar os jogadores do jogo, forçando-os a pensar sobre a câmera e os
controles, e fazendo-os perceber que definitivamente não estavam jogando. Em suma, esses
jogos não eram tão imersivos quanto poderiam ter sido, e sendo grandes fãs de jogos de tiro
em primeira pessoa, sabíamos que a imersão era fundamental para realmente assustar alguém.
Tornando o jogo mais
de um shooter nos trouxe uma experiência mais orientada para a ação e aumentou o potencial
de imersão do jogo.
The Suffering surgiu com

a ideia de combinar a
jogabilidade de tiro com
um cenário de terror
distintamente perturbador.
Portanto, nossas origens estavam realmente em uma combinação de jogabilidade e horror,

com ambos dependentes um do outro. Foi apenas através da combinação desses dois
elementos que nos diferenciaríamos entre os muitos jogos disponíveis para PlayStation 2 e
Xbox. Certamente, havia muitos jogos de tiro no mercado e também muitos jogos de terror,
mas nenhum jogo que combinasse os dois. Sem considerar o cenário e a jogabilidade
simultaneamente desde o início, nosso design de jogo não teria evoluído para um jogo que
atingisse o que queríamos.
Embora The Suffering tenha sido construído com base na tecnologia existente que Surreal
usou mais recentemente para Drakan: The Ancients' Gates, esse mecanismo era
significativamente mais forte em ambientes externos e, portanto, era inadequado para os
espaços confinados escuros e sombrios de um jogo de terror. Desde o início do jogo, sabíamos
que queríamos incluir ambientes externos também para adicionar a variedade necessária ao
jogo, mas também sabíamos que teríamos que retrabalhar nossa tecnologia significativamente
para realizar nossas ambições de ação/terror. Assim, nossa tecnologia foi significativamente
retrabalhada para usar portais que nos permitiram incluir espaços internos complexos e
detalhados além dos externos. Como nosso principal ponto de partida para o projeto era a
jogabilidade e o cenário, nossa tecnologia foi forçada a mudar e se adaptar.
Abrace suas limitações

De muitas maneiras, desenvolver um jogo é entender suas limitações e então transformar
essas limitações em vantagens. Neste capítulo, discuti como o designer deve entender de onde
vem sua ideia de jogo: jogabilidade, história ou tecnologia. Com esse entendimento, o designer
deve reconhecer como isso limita os outros atributos do jogo – como uma certa jogabilidade
exige um certo tipo de história e tecnologia, como uma história requer uma tecnologia e
jogabilidade específicas e como
a tecnologia se prestará a tipos específicos de jogos e histórias. Um projetista pode considerar esses requisitos
como limitações, enquanto um projetista mais positivo pode
considerá-los como simples restrições. De fato, muitas pessoas fazem seu melhor trabalho quando
operando dentro de restrições; ter opções ilimitadas pode ser bastante intimidante e confuso. É trabalho do
designer estabelecer quais restrições o projeto tem, encontrar as
peças perfeitas que se encaixam dentro dessas limitações e, finalmente, fazem com que todas as peças se encaixem
em um jogo convincente.
Na verdade, é um caso muito raro para um designer ser capaz de pensar em qualquer jogo que ele
deseja e, em seguida, buscar a implementação perfeita dessa ideia. Em quase todos os casos,
a designer é limitada pela situação que lhe é apresentada. As limitações podem
vem na forma da tecnologia disponível, da equipe com a qual ela tem que trabalhar, do orçamento
disponíveis para desenvolver o jogo, e o tempo permitido para sua criação. No entanto
o produtor é o principal responsável por garantir que o jogo esteja no prazo e no orçamento, o designer deve se
preocupar com todas as limitações que ele enfrenta se
espera criar um bom jogo na análise final.
Tecnologia estabelecida
Muitas vezes, um designer de uma empresa maior é obrigado a trabalhar com qualquer tecnologia que
empresa tem. Este pode ser um motor que sobrou de um jogo anterior, ou pode ser que
a equipe de programação só tem experiência trabalhando em 2D e, como resultado, a única tecnologia que eles
poderão desenvolver de forma viável em um prazo razoável será a 2D. Mesmo se
o projetista tiver a sorte de poder buscar uma tecnologia para licenciar um projeto, esse projetista ainda estará
limitado pela qualidade dos motores disponíveis para
licenciamento e a quantidade de dinheiro que ela tem para gastar. Os motores estão se tornando cada vez mais
versáteis e acessíveis, mas levará algum tempo até que possam ser usados para todos
tipos de jogos em todos os orçamentos.
Se o desenvolvedor é um lobo solitário, trabalhando sozinho como designer e programador em um
projeto, pode-se pensar que o designer pode fazer o que quiser. Claro que isso é
não é o caso, pois o designer será rapidamente limitado por suas próprias habilidades como programador
e pela quantidade de trabalho que ela pode realizar sozinha. Exceto em casos raros,
nenhum programador será capaz de criar uma tecnologia 3D completa para
rivalizar com o que pode ser construído pela grande equipe da Criterion ou John Carmack e seus coortes da id
Soft ware. Simplesmente, não é possível. Funcionando como o único programador e
designer em um projeto tem muitos benefícios, mas certamente limita o que se pode
concluir.
Mesmo que um programador seja capaz de criar a engine perfeita para seu jogo, e se for
simplesmente muito lento? Se um grande número de personagens totalmente articulados em tempo real ao ar livre
Ambiente 3D são necessários para sua jogabilidade e a tecnologia não é especificamente
construído para suportar isso, a taxa de quadros será lânguida. Adicione uma IA verdadeiramente sofisticada para
cada uma dessas criaturas e seu jogo diminuirá para 1 FPS, tornando-se, em
essência, uma apresentação de slides. Se ela deve fazer aquele jogo, o designer tem que esperar até o
o poder de processamento necessário está disponível, o que pode não acontecer nos próximos anos. Infelizmente,
sugerir que um projeto seja colocado em espera até que a tecnologia melhore geralmente
tem o resultado direto de fazer com que o editor pare de fazer pagamentos por marcos.
Claro, se um designer está realmente comprometido em fazer um determinado jogo, antes de dar
ela pode precisar ser mais inteligente em como ela implementa. Existem truques que podem
ser empregado para fazer com que um grande grupo de agentes de IA pareça estar trabalhando
independentemente quando na verdade estão usando um algoritmo de agrupamento relativamente
barato? Quão polidos os ambientes realmente precisam ser? Ou a grande questão: o jogo realmente
precisa ser 3D, ou uma implementação 2D será tão boa? Designers engenhosos e determinados
serão capazes de encontrar soluções inteligentes para o que a princípio parecem ser problemas
insolúveis.
O Caso dos Muitos Cogumelos

Ao trabalhar no Centipede 3D, estávamos constantemente preocupados com nossa taxa de quadros.
Lembre-se, para esse jogo, nossa principal preocupação era alcançar uma jogabilidade que estivesse
no espírito do clássico arcade original. Mas a jogabilidade de Centipede dependia da presença de
muitos cogumelos na tela ao mesmo tempo, com um número igualmente grande de outros insetos,
aracnídeos e artrópodes voando ao redor do mundo, ameaçando destruir a pequena nave “atiradora”
do jogador. Além disso, a jogabilidade exigia uma visão de cima para baixo, que forneceu uma área
de visão bastante grande do mundo do jogo para que o jogador pudesse ver as manobras dessas
criaturas mortais. O resultado final foi que poderia haver várias centenas de cogumelos de 24
polígonos, doze segmentos de centopéias de 40 polígonos e inúmeras outras criaturas na tela ao
mesmo tempo. Além disso, a Hasbro queria que o Centipede 3D fosse um título de mercado de
massa, então o requisito mínimo de sistema do produto foi predeterminado para ser um Pentium de
133 MHz sem aceleração gráfica de hardware. Além de tudo isso, a jogabilidade de ação rápida de
Centipede exigia uma taxa de quadros igualmente rápida para ser divertida.
Enquanto trabalhávamos no projeto, éramos constantemente confrontados com o problema de

aumentar a contagem de polígonos, com artistas sempre tentando raspar alguns polígonos do muito
usado modelo de cogumelo. A certa altura, um artista sugeriu que talvez se pudéssemos reduzir o
cogumelo a duas pirâmides uma sobre a outra, teríamos a representação mínima absoluta de um
cogumelo, usando apenas seis ou oito polígonos. De fato, foi sugerido que, se todos os modelos do
jogo fossem para uma representação minimalista, poderíamos usar a limitação de polígonos a nosso
favor, criando um mundo de jogo único cheio de objetos que pareciam ter sido criados por um cubista.
Certamente seria um visual único para um jogo, e se encaixaria muito bem com o mundo de jogo já
um tanto surreal do Centipede 3D. “Abrace suas limitações!” Eu proclamei no meio desta discussão,
não muito diferente de um cientista cansado poderia finalmente gritar: “Eureka!” Todos os presentes
acharam minha declaração muito engraçada, mas pensando nisso mais tarde, decidi que era bem
verdade para o desenvolvimento de jogos. Infelizmente, estávamos muito adiantados no
desenvolvimento para converter toda a nossa arte para a implementação minimalista que havíamos
pensado, sem mencionar os possíveis problemas de tentar vender à editora a ideia de um jogo
minimalista.
Mas, em geral, ainda acredito que os desenvolvedores de jogos precisam abraçar suas
limitações assim que as descobrirem. Quando apresentado a um motor que deve ser usado para um
projeto, por que se esforçar para projetar um jogo que não é adequado para essa tecnologia? O
design do seu jogo pode ser fabuloso e bem pensado, mas se a tecnologia que você deve usar não
for capaz de implementá-la bem, você ainda ficará com um jogo ruim no final. É melhor arquivar uma
ideia incompatível com sua tecnologia (você sempre pode voltar a ela mais tarde) e criar um design
mais adequado às ferramentas que você possui. Depois de identificar as limitações com as quais o
motor o sobrecarrega, é
melhor abraçar essas limitações em vez de combatê-las. Isso não quer dizer que um
O designer deve sempre projetar o jogo mais simples que possa imaginar ou que designs experimentais
sofisticados não devem ser tentados. Se um diretor de teatro astuto
sabe que um determinado ator está interessado em trabalhar com ela, ela escolherá a melhor peça para
mostrar as habilidades particulares desse ator. Da mesma forma, um designer deve considerar o que o
tecnologia se presta e usa isso como base para o jogo que ela projeta e o
história que ela se propõe a contar.
O tempo atribuído
Limitações que não discuti muito neste capítulo, mas que, no entanto, são
muito importantes no desenvolvimento de jogos são o orçamento e o cronograma com que um
designer pode ser apresentado. Embora estas sejam principalmente a preocupação e a responsabilidade
do produtor do projeto, o game designer precisa saber como esses fatores vão limitar
o projeto, assim como a tecnologia, jogabilidade ou história. Ao escolher a tecnologia a ser utilizada, o
projetista deve se perguntar: ela pode ser concluída no tempo
programado para o projeto? Pode ser concluído a tempo para implementação e balanceamento de nível?
O projeto sugerido prevê a criação de um número tão grande de
níveis complexos e comportamentos fortemente roteirizados que não podem ser concluídos em dezoito
meses por apenas um designer? Assim como a linha do tempo limitará a quantidade de tempo
que pode ser gasto no projeto, o orçamento afetará quantas pessoas podem estar trabalhando
no projeto durante esse período. Pode ser que, dado o dobro do orçamento, o jogo
projeto poderia ser facilmente concluído em um ano e meio, mas com apenas metade do orçamento o
designer precisará reduzir o design para chegar a algo viável. Novamente,
se o desenvolvimento estiver atrasado seis meses sem fim à vista e, como resultado, o editor desliga o
plugue, não importa o quão brilhante o design do seu jogo possa ter sido
em teoria. Ninguém poderá jogar o seu jogo porque você não considerou totalmente o
logística de sua implementação. E se você não alocar tempo suficiente para ajustar e
equilibrando a jogabilidade, seu editor pode exigir que você envie um jogo que considere
inacabado. O que poderia ter sido um grande jogo será ruim porque não houve
tempo suficiente para realmente terminá-lo.
Desenvolvedores Lone Wolf têm um pouco mais de facilidade em termos de restrições de tempo e
limitações orçamentárias. Se uma única pessoa está criando toda a arte, código e design do jogo,
e está desenvolvendo o jogo em seu próprio tempo sem depender da renda de seu desenvolvimento para
sobreviver, ela está muito mais livre para seguir onde quer que sua musa o leve
ela, enquanto ela gosta. Claro, ela ainda é limitada por seus próprios talentos, pela
qualidade da arte que ela pode criar, e pelos limites de suas habilidades de programação, mas pelo menos
estas são as únicas limitações. Ao criar arte, há muito a ser dito por não ser
em dívida com a pessoa que assina os cheques.
Se você optar por não decidir, você

Ainda Fiz Uma Escolha
Muitas vezes, produtores, programadores, artistas e designers não consideram as limitações da
ideia do jogo que planejam desenvolver. Seja a partir de noções de jogabilidade, sugestões de
tecnologia ou pensamentos sobre uma história, assim que uma ideia de jogo toma forma, ela
começa a limitar o que o jogo pode ser para ser bem-sucedido. Os desenvolvedores de jogos
precisam entender que nem todas as tecnologias funcionarão com todos os designs de jogos,
nem todos os designs com todas as histórias, nem mesmo todas as histórias com todas as tecnologias.
Muitas vezes, os desenvolvedores tentam pegar um monte de conceitos atraentes e tentar
colocá-los todos em um jogo. O programador líder pode estar interessado em desenvolver um
sistema de física do corpo humano de ponta. A principal designer de jogos pode ter querido
experimentar um jogo de estratégia em tempo real desde que jogou Age of Empires pela primeira vez.
O escritor do jogo pode pensar que há violência demais nos jogos de computador e, portanto,
quer escrever um conto de romance. Se a produtora for uma tola, ela pode até se emocionar
com o fato de os membros de sua equipe estarem tão empolgados com o que estão
desenvolvendo e que, combinando física, RTS e romance, o resultado será um jogo inovador.
Claro que qualquer um com um pouco de bom senso sabe que este jogo está fadado ao
fracasso. Sem uma visão consistente e unificada, nenhum jogo terá chance de lutar. Embora
cada membro da equipe possa ter um caso válido para perseguir sua ideia, se as ideias não
funcionarem juntas, em algum momento o grupo precisará escolher uma e seguir em frente. Se,
na sessão de brainstorming, a equipe decidir em qual ideia quer se concentrar, a equipe pode
trabalhar para tornar o jogo como um todo o melhor possível. Suponha que eles escolham a
física como sua força mais promissora. Então o designer pode refletir sobre isso e perceber que
um RTS provavelmente não é o ideal, mas um jogo com tema de circo pode ser um uso inventivo
do simulador de física do corpo humano. Pode incluir lançar artistas de canhões, fazer acrobatas
criarem pirâmides humanas e permitir que os jogadores realizem acrobacias complexas no
trapézio. A partir daí, o escritor poderia inventar uma história de amor sobre dois trapezistas cujo
relacionamento é testado pela chegada ao circo de um novo homem forte e deslumbrante, com
tudo chegando ao clímax durante um ato complexo de arame farpado onde a rede de segurança
foi foi removido. Este jogo tem uma chance de ser divertido de jogar porque todos os
componentes estão trabalhando juntos. No final, você não quer que seu jogo consista apenas
em uma excelente tecnologia ou uma história convincente ou um design de jogo brilhante. Se
nenhum desses componentes suportar um ao outro e você não tiver uma visão unificada, seu
jogo será tão ruim quanto se você estivesse trabalhando com uma história banal, um design de
jogo fino e uma tecnologia incompleta.
Capítulo 4
Análise do jogo:
Centopéia
Desenhado por Ed Logg com Donna Bailey
Lançado em 1981
da mesma forma que uma comédia de palhaçada silenciosa é uma forma de filme ou o hard-boiled
Pode-se pensar nopolicial
romance clássico jogoforma
é uma de arcade como uma
de literatura. forma
A forma de jogo
clássica de computador
de jogo no
de arcade caiu
em desuso entre as empresas de jogos comerciais assim que a tecnologia estava disponível
para ir além dela. No entanto, muitos desenvolvedores de jogos independentes ainda trabalham
em jogos de arcade clássicos para sua própria diversão ou para serem lançados como títulos
freeware ou shareware. Muitos desses trabalhos de amor são imitações de jogos de arcade
clássicos estabelecidos, mas muitos outros são experimentos interessantes em novas jogabilidades.
Permanece algo excepcionalmente atraente sobre a forma, e o fato de que não é
necessário ter um mecanismo 3D sofisticado para criar um jogo de arcade clássico
maravilhosamente divertido ajuda a tornar a forma atraente para trabalhar.
57
58 Capítulo 4: Análise do Jogo: Centopeia
Vale a pena mencionar que quando me refiro ao jogo de arcade clássico, não quero dizer que
todos os jogos de arcade clássicos são clássicos. Muitos deles são muito ruins. Como em qualquer
mídia, os antigos jogos de arcade que são lembrados e comentados décadas após seu lançamento
tendem a ser os melhores, criando assim a falsa impressão de uma “idade de ouro”.
Os jogos de arcade ruins caíram entre as rachaduras da história. O termo “jogo de arcade clássico”
refere-se à forma como um clássico, não aos jogos em si, assim como alguém pode se referir à
“música clássica”. Certamente o termo “jogo de arcade” não é limitativo o suficiente, já que isso
parece incluir todos os jogos encontrados em um arcade, incluindo jogos modernos de corrida, armas
e luta, nenhum dos quais eu considero parte da forma que sou. preocupado aqui.
A forma clássica de jogo de arcade teve seu auge comercial e criativo no final da década de
1970 até o início da década de 1980, quando as máquinas exibindo a forma se alinhavam nos fliperamas.
Olhando para os jogos como um todo, pode-se chegar a uma série de características que todos
compartilhavam. Alguns desses aspectos da forma podem ter sido alcançados por causa das
considerações comerciais das arcadas. O pensamento era fazer com que os jogadores entendessem
facilmente um jogo, para que ao final de seu primeiro jogo eles tivessem uma boa noção de como o
jogo funcionava e o que era necessário para o sucesso. Em segundo lugar, o jogo dos jogadores,
mesmo o jogo de um especialista, não poderia durar muito, já que qualquer jogador havia pago
apenas um quarto, e se o jogo ganhasse apenas um quarto em meia hora, não seria lucrativo. para
operar. Os fabricantes de jogos com moedas queriam que o tempo médio de jogo fosse de 2,5
minutos. Os jogadores precisavam ser sugados para repetir os jogos, para continuar jogando nos
quartos. Como resultado, de certa forma, os jogos de arcade tiveram que ser mais refinados do que
os jogos caseiros são hoje. Uma vez que os jogadores tenham comprado um jogo em casa, muitas
vezes por pelo menos cem vezes o custo de um único jogo de arcade, a venda é concluída. Se eles
não estiverem completamente desgostosos com o jogo, é improvável que o devolvam. Recursos como
tabelas de pontuação e recordes serviram apenas para aumentar a natureza viciante do jogo de
arcade e incentivar os jogadores a continuar gastando dinheiro.
Além disso, as restrições técnicas da época limitavam o que os jogos podiam fazer e, portanto,
influenciavam o que o jogo poderia realizar em termos de jogabilidade. Se os designers tivessem a
RAM e o poder de processamento para incluir mundos de jogo com rolagem completa que eram
muitas vezes o tamanho da tela, eles provavelmente teriam. Se os jogos pudessem reproduzir algum
tipo de vídeo full-motion, talvez os designers tivessem incorporado mais enredo nos jogos. Mas o fato
é que surgiu um gênero único de jogos de computador, e se as limitações comerciais e técnicas
moldaram a forma, que assim seja. Assim como os primeiros filmes tinham que trabalhar com as
limitações do silêncio e dos tempos de execução curtos, os designers de jogos de computador eram
limitados no que podiam criar e, mesmo assim, conseguiam criar jogos brilhantes. Muitas vezes, uma
série de restrições estritas força os artistas a concentrar sua criatividade de uma forma que leva a um
trabalho melhor do que se eles pudessem fazer o que quisessem.
Um ingrediente chave para muitos jogos de arcade clássicos era sua variação selvagem nos
estilos de jogo. Centipede, Missile Command, Pac-Man e Frogger são tão diferentes um do outro
quanto poderiam ser. Muitos jogos de arcade clássicos apresentavam variações de um tema:
Centipede, Space Invaders, Galaga e Tempest , todos giravam em torno da ideia de atirar em um
ataque descendente de inimigos. No entanto, as variações de jogabilidade que esses jogos adotaram
são muito mais radicais do que a pequena quantidade de variação encontrada nos jogos modernos,
que se contentam em clonar infinitamente já comprovados
Capítulo 4: Análise do Jogo: Centopeia 59
Tempest é um dos muitos

jogos de arcade clássicos
que se concentra em atirar
em inimigos que ficam cada
vez mais próximos. Tempest
é memorável por causa das
muitas reviravoltas
exclusivas incluídas.
gêneros de jogos. Apesar da grande variedade de jogabilidade que pode ser encontrada nos jogos de
arcade clássicos, ainda é possível olhar para esses jogos como um coletivo e vê-los como um
movimento artístico na breve história dos jogos de computador. Ao analisar as características
compartilhadas do formulário, os designers de jogos modernos podem aprender muito sobre como
podem tornar seus próprios jogos experiências mais atraentes para os jogadores.
Características do jogo de arcade clássico

• Jogo em tela única: Em um jogo de arcade clássico, a maior parte da jogabilidade ocorre em uma
única tela, com os jogadores manobrando seu substituto do mundo do jogo em torno dessa tela,
às vezes apenas em uma parte dessa tela. Isso foi feito, sem dúvida, em parte por causa de
limitações tecnológicas, mas também tem ramificações artísticas muito importantes no design do
jogo. Os jogadores, a qualquer momento, podem ver todo o mundo do jogo e podem tomar suas
decisões com pleno conhecimento do estado desse mundo do jogo. Obviamente, capacitar os
jogadores com esse tipo de informação afeta seriamente a jogabilidade. Muitos dos jogos na forma
clássica de jogo de arcade incluiriam mais de uma tela de jogabilidade, trocando os campos de
jogo ou modificando os existentes para criar “níveis” adicionais. Exemplos disso incluem Joust,
Pac-Man e Mario Bros. Embora esses jogos possam ter incluído mais de uma única tela em todo
o jogo, a qualquer momento o mundo do jogo ainda consistia em apenas uma tela. • Jogo Infinito:
Os jogadores podem jogar o jogo para sempre. Não há fim para o jogo e, portanto, também não
há como vencê-lo. Isso foi feito em parte para permitir que os jogadores se desafiassem, para ver
quanto tempo eles poderiam jogar em um único quarto. Os jogadores nunca podem dizer: “Eu venci
Asteroids” e, portanto, os jogadores sempre podem continuar jogando, continuar colocando
quartos. Ao mesmo tempo, ter um jogo invencível torna cada jogo uma derrota para os jogadores.
Todo jogo termina com a morte do jogador e, portanto, é uma espécie de tragédia. Ter um jogo
invencível também requer fazer um jogo que se torne continuamente mais desafiador, portanto,
um design de jogo com uma dificuldade contínua e infinita. Com o advento do mercado doméstico,
o jogo
os editores não queriam mais que os jogadores jogassem um único jogo para sempre. Em vez
disso, eles querem que os jogadores terminem os jogos que têm e comprem mais. Esta é uma
razão pela qual agora é raro ver um jogo com jogo infinito.
• Múltiplas Vidas: Normalmente, os jogos de arcade clássicos permitem aos jogadores um número
finito de tentativas, ou um número de “vidas”, antes que o jogo termine. Talvez derivados de
jogos de pinball, que durante décadas forneceram aos jogadores três ou cinco bolas, várias
vidas permitiram aos jogadores novatos a chance de aprender a mecânica do jogo antes
que o jogo terminasse. Dadas as chances adequadas de tentar descobrir como o jogo
funciona, é mais provável que os jogadores queiram jogar novamente se melhorarem de
uma vida para outra. A capacidade de ganhar vidas extras fornece outro incentivo de
recompensa para os jogadores e também configura um jogo em que morrer uma vez não é
necessariamente o fim do jogo, o que, por sua vez, incentiva os jogadores a correr riscos
que não poderiam de outra forma.
• Pontuação/High Scores: Quase todos os jogos de arcade clássicos incluíam um recurso de pontuação
através do qual os jogadores acumulavam pontos para realizar diferentes objetivos no jogo. Por
exemplo, em Centipede, os jogadores recebem 1 ponto por destruir um cogumelo, 10 pontos por
um segmento de centopéia, 100 pontos por uma cabeça de centopéia e 1000 pontos por um
escorpião. Outro componente clássico dos jogos de arcade com origem no mundo do pinball, a
pontuação permite que os jogadores verifiquem o quão bem eles se saíram no jogo, já que vencer
o jogo é impossível. A tabela de pontuação alta foi introduzida para permitir que os jogadores
insiram suas iniciais ao lado de sua pontuação, que seria classificada em uma tabela de
pontuações para que os jogadores pudessem ter um ponto de comparação para ver o quão bons
eles realmente eram. O jogo se lembraria da mesa enquanto ela permanecesse conectada, com
alguns jogos, como Centipede, até mesmo lembrando a lista de recordes ou parte dela uma vez
desconectada. A tabela de alta pontuação permitiu que os jogos de arcade clássicos explorassem
uma das principais motivações para jogar – “direito de se gabar”. Os jogadores poderiam apontar
seu nome na tabela de recordes para seus amigos como forma de provar sua coragem.
Os amigos podiam competir uns com os outros (quase todos os jogos incluíam modos de dois
jogadores, onde os jogadores desligavam o jogo) para ver quem conseguia a pontuação mais alta.
• Jogabilidade simples e fácil de aprender: os jogos de arcade clássicos eram fáceis para os jogadores
aprenderem, impossíveis (ou pelo menos muito difíceis) de dominar. Os jogadores poderiam ir até
um jogo de Centipede, jogar em seu quarto e, na terceira vida, ter uma boa ideia de como o jogo
funcionava e como eles poderiam jogar melhor. Por que os jogadores morriam sempre foi
completamente evidente para eles. Normalmente não havia “movimentos especiais” envolvendo
grandes combinações de botões que os jogadores tinham que aprender por tentativa e erro. Havia
poucos jogos com conceitos complicados como “saúde” ou “escudos” ou “power-ups”. Novamente,
considerações comerciais foram provavelmente um fator para tornar esses jogos simples de
aprender. Na época de sua introdução inicial, não havia um mercado estabelecido de jogadores
de jogos de computador e havia poucos fliperamas. Os jogos acabavam em pizzarias e bares,
onde qualquer pessoa comum podia ir até uma e experimentar. Esses jogadores novatos podem
se assustar se o jogo for muito complexo ou desconcertante. Claro, simples nem sempre significa
jogabilidade “limitada” ou “ruim”; também pode significar “elegante” e “refinado”.
• Sem história: os jogos de arcade clássicos quase universalmente evitaram a noção de tentar “contar
uma história” de qualquer tipo, assim como muitos jogos de arcade modernos continuam a fazer.
Os jogos sempre tiveram um cenário que os jogadores poderiam facilmente reconhecer e se
relacionar, muitos deles girando em torno de temas de ficção científica, embora outros se
interessassem por guerra, fantasia e esportes, entre outros. Muitos, como Pac-Man e Q*Bert,
criaram suas próprias configurações únicas, acompanhando a criatividade desenfreada
encontrada em sua jogabilidade. Os designers de jogos de arcade clássicos não se sentiram
obrigados a detalhar seus mundos de jogo, a inventar explicações sobre por que os jogadores
estavam atirando em um determinado alvo ou comendo um certo tipo de ponto, e os jogos não sofreram p
Mesmo que a ação em

Sinistar não tenha
ocorrido apenas em
uma tela, ainda é
considerado um
exemplo da forma
clássica de jogo de arcade.
Claro, alguns jogos quebraram algumas das regras acima da forma, mas ainda podem ser
considerados jogos de arcade clássicos. Por exemplo, Sinistar e Defender incluíam a rolagem de
mundos de jogo para os jogadores viajarem, com os jogadores incapazes de ver todos os aspectos
do mundo do jogo ao mesmo tempo. De fato, na primeira inspeção, Battlezone parece inteiramente o
estranho entre os primeiros jogos de arcade clássicos. No entanto, se olharmos para os traços acima,
descobriremos que apresentava jogo infinito, múltiplas vidas, pontuação, era fácil de aprender e quase
não tinha história. Todos esses três jogos incluíam mecânicas que, em geral, eram aderentes à forma
clássica dos jogos de arcade. Assim ainda podemos agrupá-los com jogos como Space Invaders e
Asteroids, que seguem todas as regras descritas acima.
Centipede, um dos jogos que definem a forma, segue todas as características do clássico jogo
de arcade listado acima. Embora não seja um jogo muito complexo para os padrões de hoje, a
maravilha de Centipede é como todos os diferentes elementos de jogabilidade trabalham juntos para
criar um jogo desafiador. É fácil aumentar a dificuldade de um jogo adicionando mais e mais inimigos,
mas Centipede naturalmente aumenta o desafio pela interação de seus poucos elementos para que o
jogo se torne mais difícil organicamente ao longo do tempo. Nada no Centipede está fora do lugar,
nada é inconsistente, nada está desequilibrado. Analisar Centipede é tentar entender como projetar o
jogo perfeito.
Entrada
Uma das grandes vantagens de trabalhar em um jogo para os fliperamas é que o designer tem
total controle sobre o tipo de dispositivo que os jogadores usarão para controlar o jogo. No PC, o
designer só pode contar com jogadores com teclado e mouse, e em um console, o designer deve
trabalhar com o controle padrão que acompanha aquele console em particular. O designer de
arcade (não obstante as restrições de orçamento) é capaz de escolher o melhor tipo de controle
para o jogo e fornecer aos jogadores esse sistema de controle.
O designer pode então criar o jogo em torno desses controles, equilibrando precisamente o jogo
para funcionar perfeitamente com esse método de entrada. Centipede faz isso habilmente,
fornecendo aos jogadores um dispositivo de controle analógico extremamente preciso na forma
de uma trackball. Isso é ideal para mover a nave de tiro do jogador na parte inferior da tela.
Os jogadores podem mover o navio rapidamente ou lentamente, qualquer que seja a situação.
Para muitos fãs do Centipede, o excelente controle é uma das primeiras coisas que eles lembram
do jogo.
O atirador do jogador em
Centipede é mais móvel
do que em Space
Invaders, pois pode se
mover para cima e para
baixo, além de se mover
para os lados. Na foto:
Centopeia.
O arremessador é extremamente responsivo à manipulação do trackball pelos jogadores,

com os jogadores sendo capazes de entender de maneira fácil e intuitiva a relação entre a
manipulação do trackball e o movimento do arremessador. Centipede sem dúvida foi inspirado por
outros jogos de arcade clássicos, como Space Invaders, que apresentam o substituto do mundo
do jogo dos jogadores travado na parte inferior da tela, permitido apenas mover para a esquerda
ou para a direita e atirar. Centipede leva essa expressão um passo adiante: os jogadores ainda
estão presos na parte inferior da tela, mas o atirador pode se mover dentro de um espaço vertical de seis linhas
Isso permite que os jogadores evitem inimigos que possam estar na linha de baixo. Ao mesmo
tempo, o atirador ainda só pode atirar para a frente, então os inimigos que ficam atrás do navio
não podem ser destruídos. Além do trackball, o único outro controle que os jogadores têm é um
botão para disparar a arma do tipo laser do atirador. O jogo permite uma taxa de tiro infinitamente
rápida, mas apenas um tiro pode estar na tela de cada vez, o que significa que os jogadores
precisam pensar além de apenas pressionar o botão de tiro constantemente. Se os jogadores
moverem o atirador diretamente abaixo de um cogumelo, eles podem segurar o botão de disparo e rapidament
atire no cogumelo quatro vezes, destruindo-o. Mas na parte superior da tela, onde os jogadores não
podem manobrar o navio, destruir um cogumelo leva muito mais tempo, já que os jogadores devem
esperar que cada tiro atinja o cogumelo antes que outro tiro possa ser disparado.
Atirar nos inimigos que se aproximam cria uma situação semelhante. Se o último tiro estiver no meio de
uma viagem para um alvo distante, os jogadores não poderão atirar novamente para eliminar um inimigo
que esteja bombardeando. Assim, quando os inimigos estão longe, eles são menos ameaçadores, mas
os jogadores têm dificuldade em matá-los. À medida que as criaturas se aproximam, os jogadores
podem matar os insetos com mais facilidade, mas a chance de morrer aumenta. Isso mantém o jogo
perfeitamente equilibrado e exige que os jogadores planejem suas tacadas com cuidado, um elemento
de design que adiciona mais profundidade à mecânica do jogo.
Interconexão
Um dos grandes pontos fortes do Centipede é o quão bem todos os diferentes elementos da jogabilidade
se encaixam. Considere os diferentes insetos inimigos que tentam matar os jogadores. A centopéia
desce do topo da tela até a área do jogador na parte inferior, movendo-se horizontalmente. A centopéia
aparece como uma centopéia solitária de doze segmentos ou como uma centopéia mais curta
acompanhada por várias cabeças únicas. No início de uma onda, o número de segmentos de centopéias
na tela sempre totaliza doze.
Em seguida é a aranha, que se move em um padrão diagonal, saltando pela parte inferior da tela,
entrando e saindo da área do jogador. Em seguida, vem a pulga, que cai verticalmente, direto para
baixo. Não há nada de terrivelmente sofisticado em nenhum dos padrões de movimento desses insetos.
De fato, a pulga e a centopéia, uma vez que aparecem no campo de jogo, seguem um padrão
completamente previsível à medida que se aproximam da área do jogador. A aranha tem uma natureza
mais aleatória em seu movimento em ziguezague, mas mesmo ela não faz nada para realmente
perseguir os jogadores. Portanto, uma vez que os jogadores tenham jogado o jogo apenas algumas
vezes, eles têm um conjunto completamente confiável de expectativas sobre como esses inimigos os
atacarão. Lutar contra qualquer uma dessas criaturas por si só forneceria muito pouco desafio para os
jogadores. No entanto, quando funcionam juntos, eles se combinam para criar situações desafiadoras
únicas para os jogadores. Com a falta de qualquer um desses adversários, o desafio do jogo seria
significativamente diminuído, se não removido completamente.
Cada um dos insetos no jogo também tem uma relação única com os cogumelos, que preenchem
o campo de jogo do jogo. A principal razão para a existência dos cogumelos é acelerar o progresso da
centopéia para a parte inferior da tela. Cada vez que um centi pede esbarra em um cogumelo, ele
desce para a próxima fileira abaixo, como se tivesse corrido para a beira do campo de jogo. Assim, uma
vez que a tela fique cheia de cogumelos, a centopéia chegará ao fundo do campo de jogo extremamente
rapidamente. Uma vez na parte inferior da tela, a centopéia se move para frente e para trás dentro da
área do jogador, representando um grande perigo para os jogadores. Portanto, cabe aos jogadores
fazer tudo o que puderem para destruir os cogumelos no campo de jogo, mesmo que os próprios
cogumelos não representem uma ameaça direta. Para complicar ainda mais, toda vez que os jogadores
atiram em um segmento da centopéia, ele deixa um cogumelo onde morreu. Assim, eliminar um
centipede de doze segmentos deixa um grande grupo de cogumelos com os quais os jogadores devem
lutar.
À medida que a pulga cai no fundo do campo de jogo, ela deixa um rastro de novos cogumelos
atrás de si, e a única maneira de os jogadores pará-la é matá-la. A pulga só vem para
Em Centipede, as pulgas
caem na parte inferior da
tela, deixando os cogumelos
para trás, enquanto as
aranhas comem os
cogumelos que bloqueiam
seu movimento.
o campo de jogo se menos de um certo número de cogumelos estiver na metade inferior da tela.
Dessa forma, se os jogadores destruírem todos os cogumelos mais próximos, a pulga sai
imediatamente para deitar mais. A aranha, a criatura que representa a maior ameaça aos jogadores,
tem o efeito colateral de comer cogumelos. Isso apresenta aos jogadores um dilema: atirar e matar
a aranha ou apenas tentar evitá-la para que ela possa tirar mais cogumelos? Finalmente, o
escorpião, uma criatura que viaja horizontalmente pela metade superior da tela e, portanto, nunca
pode colidir e matar os jogadores, envenena as salas de cogumelos sob as quais passa. Esses
cogumelos envenenados afetam a centopéia de maneira diferente quando esbarram neles. Em vez
de apenas descer para a próxima linha, a centopéia se moverá verticalmente para baixo até a parte
inferior da tela. Então, quando uma centopéia atinge um cogumelo envenenado, a centopéia se
torna uma ameaça muito mais grave do que era antes. Uma vez que um escorpião passou, os
jogadores agora devem gastar esforço tentando atirar em todos os cogumelos envenenados no
topo da tela ou estar preparados para explodir os centi pedes enquanto eles despencam
verticalmente em direção a eles.
Assim, podemos ver que cada uma das criaturas do jogo tem uma relação especial e única
com os cogumelos. É a interação dessas relações que cria o desafio para os jogadores. Quanto
mais cogumelos a pulga derrubar, mais cogumelos o escorpião terá que envenenar. A aranha pode
tirar cogumelos na parte inferior da tela, tirando-os do caminho dos jogadores, mas pode comer
tantos que a pulga começa a sair novamente. Se os jogadores matarem a centopéia muito perto
do topo da tela, ela deixará um aglomerado de cogumelos que são difíceis de destruir a tal distância
e que farão com que futuras centopéias cheguem ao fundo da tela em uma velocidade maior. No
entanto, se os jogadores esperarem até que a centopéia esteja na parte inferior da tela, é mais
provável que a centopéia os mate. Com os cogumelos quase funcionando como peças de quebra-
cabeça, Centipede se torna uma espécie de híbrido entre um jogo de tiro arcade e um jogo de
quebra-cabeça em tempo real.
De fato, alguns jogadores foram capazes de desenvolver estratégias especiais que funcionariam
para impedir que a pulga saísse, fazendo com que a centopéia chegasse ao fundo da tela menos
rapidamente e permitindo que os jogadores sobrevivessem por muito mais tempo. É a interação de
cada um dos adversários com esses cogumelos e entre si que cria um desafio único para os
jogadores.
Escalando a tensão
Uma grande parte do sucesso do Centipede é como ele aumenta a tensão ao longo do jogo. Na
verdade, o jogo cria picos e vales nos quais a tensão atinge um ápice e, com a morte do último
segmento da centopéia, relaxa por um momento enquanto o jogo muda para a próxima onda. Uma
pequena maneira pela qual o jogo aumenta a tensão ao longo de alguns segundos é através da pulga,
que é o único inimigo no jogo que os jogadores devem atirar duas vezes. Quando é atingido apenas
uma vez, sua velocidade aumenta drasticamente e os jogadores devem atirar novamente rapidamente
para evitar ser atingido. Para aquela breve explosão de velocidade, a tensão aumenta. Em termos da
própria centopéia, o jogo aumenta a tensão dividindo a centopéia cada vez que é baleada. Se os
jogadores atirarem no segmento do meio de uma centopéia de onze segmentos, ela se dividirá em
duas centopéias de cinco segmentos que se dirigem em direções opostas. Claro, os jogadores
diminuíram o número total de segmentos na tela em um, mas agora eles têm dois adversários para se
preocupar ao mesmo tempo. Como resultado, jogadores habilidosos acabarão indo para a cabeça ou
cauda da centopéia para evitar dividi-la.
A maior parte da tensão crescente do jogo ao longo de uma onda é derivada da abordagem da
centopéia em direção à parte inferior da tela e dos esforços frenéticos dos jogadores para matá-la antes
que ela chegue lá. Uma vez que uma cabeça de centopéia atinge a parte inferior da tela, um gerador
especial de cabeça de centopéia é ativado, que cospe cabeças de centopéia adicionais na área do
jogador. Se os jogadores não conseguirem matar a centopéia antes que ela atinja a parte inferior da
tela, o que já aumentou a tensão por sua própria aproximação, essa tensão é ainda maior com a
chegada dessas cabeças extras. E essas cabeças extras continuam chegando até que os jogadores
consigam matar todos os segmentos de centopéias restantes na tela. A taxa na qual essas cabeças
extras saem aumenta com o tempo, de modo que, se os jogadores demorarem para matá-las,
centopéias adicionais chegarão mais rápido, deixando os jogadores ainda mais frenéticos.
Uma vez que os jogadores matam o último segmento, o jogo vai para sua próxima onda, e o
centipede é regenerado a partir do topo da tela. Isso proporciona um alívio crucial para os jogadores,
um momento de descanso. Os jogadores sentirão uma grande adrenalina por terem finalmente
derrotado a centopéia, especialmente se o gerador extra de cabeça de centopéia tiver sido ativado.
Além disso, a centopéia recém-gerada a princípio parece mais fácil de matar, já que é gerada tão longe
da área do jogador.
Ao longo de todo o jogo, os cogumelos inevitavelmente tornam-se cada vez mais embalados no
campo de jogo. Quando houver mais cogumelos na parte inferior da tela, os jogadores se sentirão com
sorte se puderem limpar todos os cogumelos na metade inferior do campo de jogo. Eles não têm chance
de destruir os cogumelos em direção ao topo, já que os cogumelos inferiores bloqueiam seus tiros. Da
mesma forma, se o escorpião deixou algum cogumelo envenenado na parte superior da tela, os
jogadores não têm chance alguma de destruí-los e, como resultado, a centopéia bombardeia a parte
inferior da tela a cada onda. Longe de um jogo, o topo do campo de jogo torna-se uma parede sólida
de cogumelos. À medida que os cogumelos se tornam cada vez mais densos, a centopéia chega mais
rápido ao fundo da tela. Quando a centopéia pode chegar ao fundo da tela extremamente rapidamente,
o jogo é muito mais rápido, e os jogadores ficam muito mais em pânico por destruir a centopéia antes
que ela atinja a parte inferior da tela.
Essa densidade aumentada de cogumelos tem o efeito de aumentar a tensão não apenas dentro de um
Ao longo de um
jogo de Centipede,
os cogumelos ficam
cada vez mais
compactados no campo de jogo.
onda como o gerador de cabeça de centopéia extra fez, mas também de onda em onda, já que os
cogumelos nunca desaparecem a menos que os jogadores atirem neles.
Centipede também equilibra seus monstros para se tornarem cada vez mais difíceis à medida que
a pontuação dos jogadores aumenta. E como a pontuação nunca pode diminuir, a tensão aumenta ao
longo do jogo. A mais óbvia é a aranha, cuja velocidade aproximadamente dobra quando a pontuação
atinge 5.000 (1.000 se o operador do jogo definiu o jogo como “difícil”).
A aranha também manobra em uma área cada vez menor da parte inferior da tela à medida que a
pontuação fica muito alta, eventualmente movendo apenas uma linha para fora da área de seis linhas do
jogador. Com a aranha assim restringida, é mais provável que ela atinja os jogadores e menos provável
que os jogadores consigam atirar nela. Lembre-se de que a pulga cai da parte superior da tela com base
na quantidade de cogumelos na metade inferior da tela. Quando os jogadores iniciam o jogo, se houver
menos de cinco cogumelos naquela área, a pulga cairá, caindo mais ao fazê-lo. À medida que a
pontuação aumenta, no entanto, aumenta também a quantidade de cogumelos necessária para evitar o
aparecimento da pulga. Agora os jogadores devem deixar mais e mais cogumelos nesse espaço para
evitar que a pulga saia e entulhe o topo da tela com cogumelos.
No início de cada onda, o jogo sempre gera um total de doze segmentos de centopéias e cabeças
na parte superior da tela. Isso significa que, se um centípede de doze segmentos aparecer na parte
superior da tela, será a única centopéia. Se uma centopéia de sete segmentos aparecer, então cinco
outras cabeças de centopéia aparecerão também, totalizando assim o número mágico de doze. Quanto
mais centopéias aparecem, mais desafiador é para os jogadores atirar em todas elas, e mais provável é
que uma delas se esgueire para a parte inferior da tela. O jogo começa liberando uma única centopéia
de doze segmentos. Na onda seguinte, uma centopeia lenta de onze segmentos aparece junto com uma
cabeça. Na onda seguinte, uma combinação rápida de onze segmentos e uma cabeça chega. Em
seguida, aparecem dez segmentos lentos e duas cabeças. A cada onda há um número maior de
centopéias individuais para os jogadores acompanharem e uma maior escalada de tensão. O jogo gira
em torno de uma vez que doze cabeças individuais são geradas e, em seguida, torna-se mais difícil
apenas gerando centopéias rápidas.
A morte do jogador também proporciona uma breve pausa na tensão. Quando a nave do
jogador é destruída, a onda recomeça e, portanto, a centopéia retorna ao topo da tela. Antes
disso, no entanto, todos os cogumelos na tela são redefinidos. Isso significa que todos os
cogumelos parcialmente destruídos são devolvidos ao seu estado não danificado e todos os
cogumelos envenenados pelo escorpião são devolvidos ao seu estado não envenenado.
Muitas ondas no jogo, o aumento da densidade de cogumelos torna quase impossível atirar em
cogumelos envenenados, e com esses cogumelos envenenados no lugar, os jogadores são
bombardeados por centopéias que se lançam em direção a eles em cada onda. Assim, os
jogadores ficam quase aliviados quando seu atirador é destruído e todos os cogumelos
envenenados são removidos da parte superior da tela. Isso faz com que o jogo fique muito mais
relaxado, pelo menos por um tempo.
A jogabilidade
frenética de Centipede
mantém o jogador tenso
na maior parte do
tempo, embora forneça
algumas pausas na ação
durante as quais o jogador pode relaxar.
Centipede é maravilhoso em criar e manter uma situação tensa para os jogadores,

enquanto ainda fornece breves “períodos de respiração” dentro da ação. Os designers de jogos
modernos, que estão sempre preocupados em aumentar a dificuldade dos jogadores, podem
aprender muito analisando como o Centipede mantém os jogadores constantemente alertas
sem nunca sobrecarregá-los injustamente.
Uma pessoa, um jogo Muitos podem zombar
da Centipede quase vinte e cinco anos após sua criação. Não há dúvida de que é uma realização
tecnicamente menos surpreendente do que as obras mais modernas, e aqueles que não o
examinam de perto provavelmente o descartam como mais uma diversão leve em vez de um
jogo sério. Mas o que Centipede faz, ele faz com tanta facilidade, apresentando mecânica de
jogo tão precisa e perfeitamente equilibrada e jogabilidade tão excepcionalmente atraente, que
é realmente uma maravilha do design de jogos de computador. É preciso lembrar que o
Centipede foi criado nos dias do sistema one-person-one-game, quando a equipe de
desenvolvimento de um jogo consistia principalmente de uma pessoa, neste caso Ed Logg. Ao
ter uma pessoa no controle total de um projeto, onde um único talentoso
indivíduo entende completamente cada nuance do jogo, o produto final é muito

mais propensos a sair com clareza de visão e brilhantismo de execução. Claro,
uma pessoa pode criar um jogo terrível tão facilmente quanto uma grande equipe, mas deve-se
perguntar se o desenvolvedor do lobo solitário não tem uma chance melhor de criar o jogo perfeito.
jogos.
capítulo 5
Foco
“Sinta o fluxo… Tornar-se um com o fluxo é realizar o propósito.”

— Warrel Dane
assemelha-se à guerra do que à criação da arte. Muitos diriam que uma quantidade decente
Desenvolver um jogo
de conflito por
pode doisà anos
levar grandecom
arte,uma equipe de em
especialmente vinte pessoas
formas normalmente
colaborativas, como mais
os
modernos jogos de computador comerciais. Um jogo mais forte pode surgir das cinzas de membros
da equipe discutindo sobre a melhor maneira de implementar algum aspecto da jogabilidade. Se o
jogo simplesmente ficar desfocado como resultado dessas disputas, é improvável que um bom
jogo surja. Ao longo das muitas batalhas que você deve lutar, escaramuças que você deve suportar
e derrotas que você deve superar no decorrer do desenvolvimento de um jogo, com conflitos
potencialmente surgindo com outros membros da equipe ou de dentro de você, é muito fácil perder
o controle de por que você estava criando o jogo em primeiro lugar. É possível que em algum
momento o jogo em que você está trabalhando tenha cativado sua imaginação? Houve alguma
visão que você teve de por que este jogo seria divertido, atraente e único? É possível que em
algum momento você realmente tenha gostado de jogos de computador?
69
70 Capítulo 5: Foco
Às vezes, no meio de um projeto, é fácil se desviar - desviado por obstáculos tecnológicos

que são lançados em seu caminho, desviado por altercações entre membros da equipe ou desviado
quando seu editor lhe diz que os recursos A, B e C simplesmente precisam ser mudado. É nessas
conjunturas que você duvida que seu jogo será divertido, ou se será concluído. Esses períodos de
dúvida são os que separam os bons designers de jogos daqueles que são meramente passáveis.
Bons designers de jogos serão capazes de superar essas dificuldades e permanecer no caminho,
lembrando-se de seu foco.
A técnica que exploro neste capítulo certamente não é uma que todos os designers de jogos
usam, mas acho que todos os designers de jogos poderiam se beneficiar. Muitos designers podem
usar a técnica, mas não percebem ou têm um nome diferente para ela. Outros podem ter métodos
totalmente diferentes para garantir que seu jogo seja um todo divertido e consistente. Você não
pode esperar ir até qualquer designer de jogos e dizer: “Qual é o seu foco para o seu projeto
atual?” e espero que eles produzam uma resposta de acordo com o método que exploro neste
capítulo. Mas se você começar a ser rigoroso em manter o foco em seus projetos, acho que verá
resultados muito positivos na qualidade final de seus jogos.
Estabelecendo o foco
O foco de um jogo é a ideia do designer do que é mais importante em um jogo. Neste capítulo,
encorajo os designers a escreverem seu foco em um parágrafo curto, já que colocá-lo por escrito
muitas vezes pode esclarecer e solidificar os pensamentos de um designer. Além disso, tê-lo em
forma física abre espaço para discussão com a equipe de desenvolvimento.
No entanto, é a ideia do foco que é de suma importância. De certa forma, o foco de um jogo é
semelhante à “declaração de missão” de uma corporação, assumindo que tais declarações de
missão são realmente significativas e usadas para orientar todas as decisões de uma corporação.
Como designer de jogos, você deve começar a se preocupar com o foco do seu jogo desde o
início do projeto. Quando o projeto está em sua infância, antes que o trabalho no documento de
design tenha começado e o projeto exista principalmente como uma ideia em sua cabeça, você
deve se fazer uma série de perguntas sobre o jogo que você está imaginando: • O que há sobre
este jogo que é mais convincente? • O que este jogo está tentando realizar? • Que tipo de
experiência o jogador terá? • Que tipo de emoções o jogo está tentando evocar no jogador? • O
que o jogador deve tirar do jogo? • Como este jogo é único? O que o diferencia de outros jogos? •
Que tipo de controle o jogador terá sobre o mundo do jogo?
Ao analisar essas questões, você deve ser capaz de determinar a natureza central do jogo
que está planejando criar. Se você tiver problemas para responder a essas perguntas, agora é a
hora de pensar no jogo até que as respostas a essas perguntas se tornem óbvias. Agora – antes
que haja mais alguém trabalhando no projeto, antes que a “taxa de queima” esteja sendo gasta e
aumentando o orçamento do jogo, antes que o departamento de marketing comece a tentar
influenciar o conteúdo e a direção do jogo – é a hora de focar. Somente
Capítulo 5: Foco 71
estabelecendo firmemente a visão do jogo desde o início, você terá alguma chance de vê-lo
realizado.
Se você não tiver muita dificuldade em adivinhar as respostas para essas perguntas, você
pode ter escrito uma página inteira ou mais delineando os pontos de diferenciação do jogo.
Mas uma página é demais. O foco que buscamos precisa ser sucinto – algumas frases, no máximo
um parágrafo curto. Alguns chegam a dizer que deve ser uma única frase, embora eu pessoalmente
prefira algo um pouco mais longo do que isso. O mais importante é que seja algo que você possa
ler rapidamente para seus colegas sem que seus olhos fiquem vidrados. Você deve tomar todas
as notas que tiver em resposta a essas perguntas e reduzi-las até que sejam curtas o suficiente
para preencher apenas algumas frases, um parágrafo de tamanho médio. Mantenha apenas suas
ideias mais atraentes. Você não precisa listar todos os recursos do jogo, ou mesmo tudo o que ele
faz de forma diferente de outros jogos. Mantenha apenas o que é mais importante para sua visão
do jogo, apenas aqueles pontos que, se você os tirasse, enfraqueceriam irreparavelmente o jogo.
Você não precisa incluir o cenário fictício do seu jogo se isso não for inerente ao foco real do
projeto. Pode não importar se o seu jogo tem um cenário de fantasia, ficção científica ou ficção
policial dos anos 1920, se o que realmente está no centro do seu jogo é explorar as relações entre
personagens em uma situação estressante ou as sutilezas da guerra de cerco. Se a configuração
não for vital para o que você deseja fazer com o jogo, deixe-a de fora. É claro que sua principal
motivação para trabalhar em um projeto pode estar irremediavelmente entrelaçada com o cenário.
Se você realmente começou com um cenário que queria explorar em um jogo, como super-heróis
fantasiados em uma cidade pequena da América, e sua visão da jogabilidade se formou em torno
da ideia desses personagens em um determinado ambiente, então você vai querer incluir isso em
seu foco. O foco é exclusivamente para os conceitos que são mais centrais para o jogo que você
espera desenvolver. Tudo o que deve permanecer em seu foco são os elementos sem os quais o
jogo não existiria mais.
Seu foco deve ser algo que o agarre visceralmente, agite sua criatividade e faça você se
sentir absolutamente entusiasmado. Se não for algo que o emocione, mesmo neste estágio inicial,
será difícil para você reunir entusiasmo quando seus prazos estiverem escorregando, seu
orçamento disparando, você ainda tem três níveis para criar e seu artista principal apenas partiu
para outra empresa. Chris Crawford tocou na ideia do foco de um jogo em seu livro, The Art of
Computer Game Design, enquanto discutia o que chamou de objetivo de um jogo: “Esta é sua
oportunidade de se expressar; escolha um objetivo no qual você acredite, um objetivo que expresse
seu senso estético, sua visão de mundo... Não importa qual seja seu objetivo, desde que seja
congruente com seus próprios interesses, crenças e paixões.” Se você não acredita no seu jogo,
não será o melhor jogo que você pode fazer.
Mesmo se você estiver trabalhando sob as restrições de uma licença, um editor dominador
ou um programador líder prima donna, faça suas próprias metas para o projeto. Se o jogo no qual
você foi designado para trabalhar não é um jogo no qual você está interessado, descubra uma
maneira de transformá-lo em algo que você possa se empolgar. Nenhuma situação é tão ruim que,
com tempo suficiente, você não possa fazer algo que considere pessoalmente atraente. Você quer
que seu foco seja algo pelo qual lutará intensamente até que o jogo finalmente seja lançado.
Grande parte deste capítulo foi escrito de uma forma que implica que você está no comando
de seu projeto, pelo menos do ponto de vista do design do jogo. É claro que isso pode não ser o
caso. Você pode ser um dos vários designers do projeto. Você pode até ser um dos sete e acabou
de ser contratado na semana passada, então está na parte inferior da escada de antiguidade. Isso
não o isenta de determinar qual é o foco do seu jogo e fazer todo o possível para mantê-lo nos
trilhos. Esperamos que o designer-chefe já tenha determinado quais são os objetivos do projeto e
deve ter incluído essas informações na introdução do documento de design. Se você não conseguir
encontrá-lo lá, você pode querer ir falar com seu líder. Pergunte a ele o que o projeto está
realmente tentando fazer, não de forma conflituosa, mas apenas para que você tenha uma boa
ideia de onde o projeto está indo e como sua contribuição para o jogo pode ser alinhada
adequadamente com essa direção.
Se o líder de design não tiver realmente um foco em mente, ele pode ser mantido por outro
membro da equipe, digamos, um programador principal ou um artista principal. No entanto, se
apesar de seus melhores esforços de pesquisa, o projeto parece não ter objetivos, talvez você
precise resolver o assunto com suas próprias mãos. Tente descobrir para onde o projeto parece
estar indo e comece a conversar com as pessoas sobre isso. Converse com outros designers,
artistas, programadores e produtores. Tente conversar com eles sobre o que é o jogo e tente fazer
com que todos concordem. As reuniões podem ser um bom lugar para fazer isso; quando todos
estão presentes, quaisquer conflitos entre diferentes perspectivas ou personalidades da equipe
podem ser encontrados e resolvidos. Você não precisa estar em uma posição de liderança para
manter seu projeto nos trilhos. Como designer em qualquer cargo em um projeto, é sua
responsabilidade que o jogo sempre tenha uma direção clara e que um jogo divertido surja no fim
do túnel.
Um Exemplo: Turbilhão de Carnaval de Inverno

Vamos supor que você tenha uma visão para um jogo envolvendo um carnaval de inverno. O que
há nos carnavais de inverno que te excita? São as esculturas de gelo? Pegar um bloco de gelo e
convertê-lo em um mamífero com tema de neve? Não? Talvez o que é realmente excitante para
você seja ir aos festivais de inverno, com sua combinação de arte congelada, patinação no gelo,
competições de bonecos de neve, esqui, lutas de bolas de neve e campeonatos de pesca no gelo.
Na verdade, você sempre se perguntou como eles mantinham esses festivais por tanto tempo,
mesmo com a ameaça de um clima mais quente constantemente surgindo no horizonte. Como o
componente do carnaval de inverno parece bastante central para sua ideia, você precisará incluí-
lo no foco. Portanto, seu foco pode começar com uma frase que explica isso: “A experiência do
jogador girará em torno de dirigir um carnaval de gelo, com o jogador responsável por manter uma
temporada o mais longa possível, apesar do clima não cooperativo”.
Agora, o que é fazer um carnaval de gelo que te prende? Você vê uma batalha implacável
contra os elementos, correndo contra a primavera para manter sua operação funcionando o maior
tempo possível. Algo sobre aproveitar o frio é excepcionalmente atraente para você.
Talvez você goste da sensação de correr na neve, sem estar no controle de quão rápido você
pode parar e os momentos de palhaçada que podem resultar. Esse apelo particular dos elementos
pode ser exclusivo para você e pode não ser o novo jogo mais promissor comercialmente, mas
neste estágio você está tentando capturar seus pensamentos pessoais sobre o jogo. Não
autocensure suas ideias até que seja absolutamente necessário. Por isso, inclua mais algumas
frases que sirvam para ilustrar o sentimento do seu jogo: “O jogo irá capturar a emoção de jogar
na neve, incluindo a física simples que torna isso divertido, através de um personagem central que
deve se movimentar em uma área um tanto perigosa. ambiente e manter vários monitores,
passeios e outros
atrações funcionando normalmente. A principal fonte de conflito do jogador será o próprio clima.
Por toda parte, o tom será leve e caprichoso.”
O que mais sobre o seu jogo do festival de inverno é uma parte central da sua visão? Você
quer simular realisticamente os ferimentos que alguém pode sofrer ao cair no gelo? Ir ao hospital
e esperar que seu substituto cure uma parte intrínseca do seu jogo? Na verdade, não; parece que,
embora esse recurso possa ser adicionado ao jogo, não é absolutamente essencial para sua visão.
De fato, tal nível de “simulação” pode prejudicar o tom leve e caprichoso. O jogo será em 3D ou
em 2D? Bem, na verdade, o jogo poderia funcionar em qualquer um. Para ser comercialmente
viável no mercado de hoje, provavelmente precisará ser 3D, mas isso não é central para sua visão.
Em seu foco, não inclua aspectos do seu jogo que são mais sobre conseguir o financiamento e a
publicação do projeto do que fazer o jogo que você quer fazer. Você pode se preocupar com
considerações comerciais mais tarde. Como eu disse antes, agora você está preocupado com sua
visão, e se você começar a comprometer sua visão antes do absolutamente necessário, no final
do dia você ficará cego. Portanto, você não precisa especificar 2D ou 3D. De fato, talvez você
tenha tudo o que precisa para o foco. Lembre-se, o foco não deve ser muito longo.
Agora é a hora de juntar suas duas frases em um parágrafo e nomear o jogo. Embora possa
parecer prematuro, nomear o jogo é realmente uma boa ideia neste momento. Você quer que
outros membros de sua equipe, o departamento de marketing e o pessoal de negócios comecem
a gostar do seu jogo o mais rápido possível, e ter um nome pelo qual possam se referir a ele é
bastante importante para esse processo. Eles podem realmente discutir isso seriamente como
“essa ideia de jogo que Richard teve”? Dar um nome ao seu jogo o torna real em vez de apenas
uma ideia, por mais ridículo que possa parecer.
Tente o seu melhor para criar um nome que você goste e que possa acabar sendo o nome
final do jogo. Muitas vezes, qualquer nome dado a um jogo no início acabará ficando com o jogo
para sempre. É especialmente importante não escolher um nome propositalmente idiota, já que
esse é o tipo mais provável de ficar. Por exemplo, digamos que você o chame de Rumba Egípcia.
Como sua equipe continua se referindo ao jogo como Rumba Egípcia, eles começarão a associar
seu jogo legal com esse título idiota, e seu título idiota começará a soar muito bem por associação.
Alguém trabalhando na equipe de arte pode começar a dar aos personagens um esquema de
cores egípcio. Os membros da equipe que estão trabalhando na história podem gastar muito tempo
tentando descobrir por que o jogo deve ser chamado de Rumba Egípcia e desenvolverão uma
linha de história especialmente inteligente em torno do nome. Se mais tarde você tentar mudar o
nome, eles ficarão tristes e possivelmente com raiva porque a história deles não faz mais sentido.
Até os “terninhos” começarão a gostar do seu título de Rumba Egípcia . Eles pensarão em como
podem capturar tanto o mercado de arqueólogos aventureiros quanto o mercado de dança cubana.
E logo, se você se lembrar, dirá que é hora de mudar o título do jogo, e todos dirão: “Por quê? Nós
gostamos de Rumba Egípcia!
É um grande nome!” E então você realmente ficará preso. Aí o público vai ver nas prateleiras e vai
pensar: “Que diabos é isso? Parece estúpido”, e passa rapidamente para jogos com títulos mais
razoáveis.
Então você finalmente escolhe Winter Carnival Whirlwind. Talvez um nome mais emocionante
apareça mais tarde, mas você pode viver com este. Agora, reúna as partes do seu foco em um
parágrafo e tente escrevê-lo de forma clara e sucinta. Consulte o seu jogo no tempo presente,
como se o seu jogo já existisse. “Redemoinho de Carnaval de Inverno
é um emocionante…” em vez de “Winter Carnival Whirlwind será um emocionante…”

Isso dá ao seu jogo uma existência mais concreta na mente de quem lê seu foco. Não é apenas
um jogo que pode acontecer em algum momento no futuro; já é um jogo, mesmo que apenas na
sua cabeça. Outra coisa a evitar é usar descrições genéricas que não fornecem ao leitor nenhuma
informação útil. Por exemplo, “Winter Carnival Whirlwind é um jogo divertido e de alta qualidade
que…” Claro que é para ser divertido. Alguém se propõe a criar um jogo chato ou de baixa
qualidade? Edite todas as seções do seu foco que não comuniquem informações importantes
sobre o seu jogo.
Juntando as partes do seu foco, você terminará com o seguinte: Winter Carnival
Whirlwind é um jogo híbrido de ação de personagens e gerenciamento de parques
temáticos rápido e furioso. A experiência do jogador gira em torno de dirigir um
carnaval de gelo, com o jogador responsável por manter a temporada o mais
longa possível, apesar do clima não cooperativo. O jogo captura a emoção de
jogar na neve, incluindo a física simples que torna isso divertido, através de um
personagem central que deve navegar em um ambiente um tanto perigoso e
manter vários sistemas funcionando sem problemas. A principal fonte de conflito
do jogador é o próprio clima. Winter Carnival Whirlwind tem um tom leve e
caprichoso por toda parte.
A função do foco
Tente evitar que seu foco se refira a outros jogos. Você quer que o foco descreva a essência do
seu jogo, e se o seu foco for, “Voltarr é como Tomb Raider, mas ambientado no extravagante
planeta Dongo e apresentando muitos tiroteios a laser intensos”, é difícil para alguém olhando
para o seu foco. entenda imediatamente quais partes de Tomb Raider você espera emular. Dê
uma olhada no próprio Tomb Raider e determine o que você acha que seu foco pode ter sido. Em
seguida, tome esse foco, remova quaisquer partes que não sejam necessárias para o seu jogo e
adicione quaisquer novas ideias que seu jogo incorporará.
É provável que sua ideia do que foi atraente em Tomb Raider seja diferente de
Seu jogo pode ser

semelhante a outro jogo
como Tomb Raider, mas
em seu foco você deseja
descrever o jogo em seus
próprios termos e evitar
fazer comparações com
outros jogos.
compreensão de outra pessoa. Quando os membros de sua equipe lêem: “É como Tomb
Raider”, eles provavelmente são lembrados de algum aspecto diferente da jogabilidade desse jogo
do que você é. Isso assumindo que eles jogaram Tomb Raider . Desde o foco
é projetado para orientar os membros de sua equipe, bem como você mesmo, ele precisa se comunicar
as mesmas ideias para todos que o lêem. Mesmo que o foco seja principalmente para seu próprio uso,
o processo de análise de Tomb Raider para determinar o que você deseja replicar
irá ajudá-lo a compreender melhor o seu próprio jogo. Você precisa ter um foco adequadamente
alinhado que possa se sustentar sozinho, sem exigir que a pessoa que está lendo
o foco entender quaisquer outros jogos em particular. Todas as informações relevantes que
importante para o seu foco deve estar contido no próprio foco, sem referências externas. Muitas vezes,
quando os designers decidem criar jogos “É como o Game X , mas com…”,
eles tendem a perder de vista o que tornou o jogo que estão imitando tão atraente no
primeiro lugar. Em seguida, eles passam a fazer seu próprio jogo pesado com recursos adicionados
que existem apenas para esconder o fato de que seu jogo é exatamente como o Jogo X. Removendo
referências a outros jogos do seu foco ajudarão a expor a verdadeira natureza do projeto que você
está realizando. Se você adicionar uma descrição suficiente revelando do que se trata
outro jogo que você está tentando capturar em seu novo design, pode ser bom deixar
a referência a esse jogo original, pois pode fornecer um ponto de partida útil para os leitores. Esta é
uma questão de preferência individual ao escrever seu foco, e eu pessoalmente
prefira deixar de fora outras referências de jogos de qualquer tipo, se possível.
Estabelecer um foco para o seu projeto não precisa limitar o escopo do seu jogo,
e não se destina a fazê-lo. Seu jogo ainda pode ser um jogo massivamente complexo com um
varredura épica. Na verdade, se apropriado, essa complexidade e profundidade provavelmente devem
ser mencionadas em seu foco, mas você ainda deve ser capaz de descrever o jogo em algumas frases
para comunicar sucintamente o que é mais importante sobre o seu empreendimento.
Seu jogo pode até incluir vários estilos de jogabilidade dentro do mesmo jogo. Suponha que seu
objetivo seja simular a vida de um pirata. Você pode querer incluir um
modo de exploração para navegar nos mares, um modo tático para envolver outro navio em
batalha, um modo de luta de espadas para lutar contra um capitão inimigo cara a cara, e até mesmo um
modo de negociação para vender espólio. (De fato, Sid Meier já fez este jogo; é
chamado Pirates!) Mas ter essa estrutura de jogo múltiplo não significa que o foco
ainda não poderia consistir em: “Este jogo recria as muitas facetas diferentes da vida de um pirata
através de vários modos de campanha diferentes, todos projetados para evocar o espírito de ser um
cruel. O jogador é capaz de explorar a natureza de ser um fora-da-lei, incluindo os riscos econômicos
e físicos envolvidos.” Se o seu jogo tiver vários modos separados,
seu foco deve se aplicar a todos os diferentes subjogos dentro do seu projeto.
Se você estiver trabalhando em um projeto sozinho ou com uma equipe pequena, pode achar
desnecessário escrever seu foco. Afinal, se você puder explicar isso para todos
quem precisa saber, qual é o sentido de escrevê-lo? Eu diria que escrevê-lo
para baixo é a chave para realmente entender a natureza do jogo que você está planejando
desenvolve. Há um mundo de diferença entre uma ideia que está rolando em seu
cabeça e um que está escrito no papel à sua frente. Quando está no papel, você pode
olhe para ele e certifique-se de que o que está digitado é realmente o cerne da sua ideia, e que aqueles
frases representam tudo o que é mais importante para você sobre o projeto. diferente
quando você descreve o projeto para alguém, no papel você não pode dizer: “Ah, sim, e
há esta parte, e este outro aspecto aqui, e eu realmente quero dizer isso quando digo
naquela." Se não estiver no papel, não faz parte do foco do jogo. Alguém que lê o foco no papel
deve ser capaz de entender sua visão sem maiores explicações. Acho que escrever o foco realmente
ajuda a esclarecer e solidificar o que o jogo está tentando alcançar.
Embora eu não soubesse

disso na época do
desenvolvimento do jogo, o
foco de Odyssey estava
centrado em contar uma
história específica.
Quando trabalhei no meu primeiro jogo, Odyssey, não tinha grandes planos para me concentrar.
Nem me sentei e deliberadamente pensei nisso. Por outro lado, lembro-me do objetivo principal que
gira em torno de uma história. Era a história de um personagem do tipo cientista louco, um poderoso
feiticeiro que realizava experimentos em infelizes criaturas humanóides. Estes não eram experimentos
biológicos, mas sim sociais - experimentos onde ele veria como esses humanos se tratariam quando
colocados em certas circunstâncias. Realmente, ele estava explorando o lado maligno de todas as
criaturas sencientes. Assim , o foco de Odyssey era explorar as maneiras más e cruéis de diferentes
grupos de pessoas se tratarem em certas situações e criar cenários onde os jogadores
testemunhassem isso em primeira mão e tivessem a chance de fazer uma mudança real em suas
vidas. A não linearidade e as múltiplas soluções também estavam na vanguarda da minha mente,
então decidi garantir que os jogadores fossem capazes de seguir táticas diferentes para resolver os
problemas que lhes eram apresentados, sem que nenhuma solução fosse designada como a “certa”.
1. E assim eu tive meu foco. Sem realmente pensar nisso em termos de foco ou visão, eu tinha
determinado o que queria fazer com o jogo, e consegui manter isso durante o projeto. Como eu
estava basicamente desenvolvendo o projeto sozinho, não tive que comunicar esse foco a mais
ninguém e, se precisasse, duvido que pudesse fazê-lo sem uma reflexão considerável. Embora eu
soubesse na minha cabeça o que eu queria no jogo, na época eu não conseguia definir meus
objetivos em termos que outra pessoa pudesse entender. Agora, olhando para trás, posso chegar
ao seguinte: Em Odyssey, o jogador explora uma rica história sobre a natureza maligna da
humanidade e vê em que circunstâncias os grupos se tratarão de maneiras moralmente repreensíveis.
Este é um simples jogo de RPG/ aventura.
Embora o combate de espada e feitiçaria esteja envolvido, ele nunca ultrapassa o

enredo. O enredo permite múltiplas soluções e não-linearidade sempre que

possível, com o jogador capaz de efetuar mudanças reais entre os NPCs que
encontra no jogo.
Mantendo o foco Uma vez que

você tenha o foco no papel e possa lê-lo e dizer com confiança: “Sim, certamente, é isso
que eu estou buscando”, é hora de compartilhá-lo com os outros membros de sua equipe.
É importante que você faça com que todos em sua equipe “se inscrevam” em seu foco.
Você quer que eles reconheçam que, sim, essa é a direção que a equipe está tomando e
concordem que eles veem um jogo atraente saindo disso no final. Se ninguém em sua
equipe acha que seu foco é muito cativante e, apesar de seus melhores esforços para
fazer campanha, ninguém consegue se empolgar com isso, você pode chegar a uma de duas conc
Primeiro, talvez sua ideia de jogo não seja tão boa. Por mais difícil que seja admitir, pode ser que
sua declaração de foco e possivelmente o jogo que ela descreve simplesmente não sejam originais
ou atraentes. Se a ideia em sua cabeça ainda é emocionante para você, talvez você não capturou
o foco correto corretamente no papel. Você deve voltar e tentar descobrir o que no jogo o excita,
mas não encontrou em seu foco.
Se você persistir em pensar que seu jogo é atraente e que seu foco reflete adequadamente o
motivo, pode ser que as pessoas de sua equipe não estejam empolgadas com ele porque não
estiveram envolvidas em criá-lo. Ao trabalhar em um ambiente de equipe, é importante incluir as
pessoas nas primeiras sessões de brainstorming para que elas possam sentir que contribuíram
para o nascimento da ideia. Mesmo que nem todas as ideias acabem sendo usadas, se você ouvir
honestamente as pessoas e usar não apenas suas próprias ideias, mas as melhores ideias,
independentemente de sua fonte, você terminará com uma equipe mais feliz que respeita sua
liderança. No final, todos os projetos podem se beneficiar de uma visão central forte que é mantida
por uma única pessoa, mas isso não significa que você precisa se trancar em uma sala para ser
“brilhante” sozinho. Costuma-se dizer que os melhores designers líderes em grandes projetos
atuam principalmente como filtros, absorvendo ideias de todas as fontes e moldando-as para se
encaixarem em uma visão única e unificada. Pode ser que o foco que você criou seja bastante
forte e produza um ótimo jogo, mas vender para as pessoas será mais complicado se elas sentirem
que foram desnecessariamente excluídas de sua criação.
Também pode ser que a equipe montada seja simplesmente a errada para desenvolver o
jogo que você criou. Nem toda equipe pode desenvolver todo tipo de jogo. Uma equipe que faz
jogos esportivos há anos, gosta de trabalhar em jogos esportivos e sabe como tornar um jogo
esportivo divertido provavelmente não é a melhor equipe a ser recrutada para criar sua simulação
econômica do século XIX. Se você tiver a opção de encontrar um novo time para o seu jogo,
provavelmente deveria. Caso contrário, talvez seja necessário ter uma ideia que a maioria de sua
equipe achará atraente. É importante que todos em sua equipe vejam o valor em sua ideia focada.
Devido à natureza colaborativa dos jogos de computador modernos e de alto orçamento, é
praticamente impossível criar um bom jogo se você não tiver a maioria de sua equipe animada
para trabalhar nele.
Se você estiver trabalhando em um projeto em grande parte sozinho, com outras pessoas
contribuindo significativamente menos para o jogo do que você, talvez não precise vender seu
foco. De fato, jogos criados por designers/programadores/artistas de lobos solitários podem estar
entre os jogos de computador mais focados. Uma vez que uma pessoa está criando a grande maioria dos
conteúdo do jogo, ele é capaz de exercer controle absoluto sobre cada nuance. O desenvolvimento
de jogos solo normalmente não é algo em que se possa ganhar a vida hoje em dia, mas conheço
alguns que o gerenciam. É claro que o fato de um jogo ter sido criado em grande parte por um
indivíduo não garante que o jogo seja focado. Se esse indivíduo estiver disperso e desfocado, as
chances são boas de que o jogo também não seja muito focado. Mesmo que ele seja uma pessoa
mais sã e organizada, se ele não acompanhar o foco de seu jogo ao longo do projeto, seu jogo
pode acabar sendo tão desfocado quanto o jogo mais descoordenado, com orçamento excessivo
e cinquenta desenvolvedores .
Se você estiver trabalhando como designer em um jogo com uma equipe, é essencial garantir
que as outras pessoas em seu projeto, sejam artistas, programadores ou produtores, entendam a
natureza do foco do jogo. Sem um foco forte para guiar suas ações, programadores e artistas
podem ter um mal-entendido sobre o que o jogo deve realizar e podem estar pensando em algum
outro tipo de jogo enquanto trabalham no seu.
Sem culpa própria, o trabalho deles pode se desviar do que precisa acontecer para que seu jogo
se torne realidade, e você será forçado a dizer: “Não, isso não se encaixa, refaça”. Se a equipe
tem um foco a seguir, um foco com o qual eles se comprometeram, é muito menos provável que
eles criem um trabalho inadequado para o seu jogo. Ter um foco forte não o impede de ficar de
olho no trabalho dos artistas e programadores, é claro, mas evitará o trabalho de redirecioná-los
com muita frequência.
Esgotando o foco
Uma vez que a equipe esteja entusiasmada com o projeto, tenha assinado o foco e tenha uma
compreensão clara do que o jogo deve ser, você pode prosseguir para aprofundar sua ideia por
meio de um documento de design completo. Você pode até querer colocar seu foco no início do
seu documento, como uma espécie de resumo da natureza do jogo que as pessoas podem ler
rapidamente. (A natureza e a criação de documentos de design são exploradas mais detalhadamente
no Capítulo 19, “O Documento de Design”). jogabilidade e precisamente como essa jogabilidade
funcionará. Você também estará esboçando o fluxo do jogo, como será o mundo do jogo e que tipo
de entidades o jogador encontrará. É claro que, enquanto você estiver trabalhando no documento
de design, haverá inúmeros pontos nos quais você terá que se esforçar para encontrar a solução
correta para um determinado problema. O sistema de controle deve usar o método A ou o método
B? Em que tipo de ambientes o jogador estará interagindo? Que tipo de desafios os inimigos
apresentam? Um foco adequadamente projetado permitirá que você o consulte para responder a
muitas das perguntas que encontrar durante o processo de design. À medida que esses elementos
do jogo são desenvolvidos, você deve consultar continuamente seu foco para ver se as adições
que você está fazendo correspondem a esse foco. Através do foco, você pode considerar
cuidadosamente se está adicionando uma jogabilidade que leva o jogo em uma nova direção. É
importante identificar quais adições ao seu jogo fazem com que ele se desvie do foco e, em
seguida, alterar ou eliminar esses elementos errôneos.
Você quer evitar que seu jogo fique muito cheio de recursos, componentes que podem ser
“legais” de alguma forma, mas que não suportam o foco principal do jogo ou que distraem a
atenção do jogador. Usando seu foco como uma ferramenta, você pode evitar essa expansão
excessiva cortando o joio no design do seu jogo para deixar apenas a jogabilidade principal
pelo qual você estava lutando. Muitas das ideias que você ou membros de sua equipe têm podem
ser bons conceitos, mas se não se encaixam no jogo em que você está trabalhando atualmente,
não vale a pena explorar ou implementar. No entanto, não jogue fora essas ideias incompatíveis.
Anote-os em seu caderno para a próxima vez que estiver trabalhando em um design de jogo. Se
forem boas ideias, provavelmente haverá algum jogo com o qual funcionarão bem. Se forem ideias
muito boas, você pode até querer criar um jogo inteiro em torno delas. Mas para o projeto atual,
referindo-se ao seu foco, você deve ser capaz de determinar se esses recursos extras e
interessantes estão ajudando ou prejudicando seu jogo como um todo.
Assim que o documento de design estiver concluído e outros elementos de pré-produção

estiverem concluídos, a produção completa poderá começar em seu jogo. Sua equipe de
programadores, artistas e outros funcionários começará a tentar implementar o que você se propôs
a realizar em seu documento de design. À medida que o projeto avança, haverá inúmeras vezes
em que surgem perguntas. Seu documento de design não cobrirá tudo o que é necessário para
tornar o jogo jogável; não é possível. Surgirão dúvidas sobre como implementar um recurso, além
de novas ideias sobre como melhorar o jogo.
Para cada um deles, novamente, você deve consultar seu foco para esclarecer a direção de sua
equipe. A implementação que está sendo sugerida vai manter o jogo nos trilhos com o foco ou vai
distrair o foco principal do jogo? A distração vai ser muito divertida? Usar sua declaração de foco
com sabedoria ao longo do projeto manterá o jogo no rumo certo e resultará em um produto final
melhor por causa disso. Os jogadores saberão a diferença entre um jogo devidamente focado e
um que não o é, mesmo que não comuniquem seus sentimentos em tantas palavras. Eles vão
jogar e desfrutar de um jogo focado e rapidamente deixarão de lado um que está desfocado.
Mudando o foco
É claro que, seja enquanto estiver trabalhando em seu documento de design ou quando o jogo
estiver em plena produção, pode ficar aparente que os objetivos do seu jogo precisam mudar. Isso
pode acontecer por uma variedade de razões. Você pode vir a ver deficiências ou falhas em seu
foco original. Por meio do ato de criar seu jogo, você pode reconhecer uma experiência mais
atraente que o jogo pode fornecer e que está fora do escopo do seu foco original. Dependendo de
onde você está no desenvolvimento do projeto, você pode querer mudar seu foco. Isso é
particularmente fácil quando você ainda está na fase de pré-produção e o documento de design
ainda não está completo. Na verdade, você deve esperar que seu foco mude várias vezes, se não
diariamente, enquanto estiver trabalhando no documento de design. Não há nada como tentar
anotar todas as informações importantes sobre seu jogo para expor falhas e falhas em seu conceito
original.
Mesmo além do documento de design, quando você está trabalhando no primeiro nível do
seu jogo, você pode começar a ver fraquezas em seu design, buracos que você não havia previsto
quando estava apenas trabalhando com uma ideia de jogabilidade em sua cabeça, em vez de um
jogo jogável. na tela à sua frente. Neste ponto, fazer mudanças no foco ainda não é catastroficamente
prejudicial à sua agenda e não envolverá muito trabalho.
Melhor corrigir problemas no jogo e seu foco agora do que ficar preso a eles pelo resto do projeto
e acabar com um jogo inferior.
Ao mudar o foco, você deve ter o mesmo cuidado que teve quando o criou inicialmente.
Certifique-se de que o foco represente totalmente sua nova visão para o projeto. É claro que, se
seu foco mudar radicalmente, você precisará informar a equipe sobre a mudança e garantir que
todos concordem com ela. Lembre-se, a equipe precisa estar por trás do projeto para que ele tenha
sucesso, e se você mudar o foco de tal forma que a equipe não esteja mais interessada em
trabalhar no projeto, você precisa repensar essa mudança ou repensar sua equipe .
Por qualquer motivo ou de qualquer maneira que você possa mudar seu foco, é importante
examinar quais partes do jogo já podem existir e ver até que ponto elas divergem de seu novo
foco. Examine o documento de design e realinhe-o de acordo com seus novos objetivos. Considere
qualquer mecânica de jogo que possa estar em vigor e veja se ela é suficiente para manter o novo
foco. Examine quaisquer níveis que possam existir (espero que não muitos tenham sido criados
neste momento) e veja se eles se encaixam no novo foco. Seja em documentação, código, design
de nível ou arte, qualquer coisa que não se encaixe precisará ser retrabalhada para que o novo
foco seja devidamente suportado.
Se muitos ativos precisarem ser retrabalhados, ou se estiver muito perto da data de envio
para alterá-los, ou se não houver financiamento suficiente disponível para alterá-los, talvez seja
necessário repensar a mudança de direção. É realmente necessário? Muitas vezes, depois de
trabalhar em um projeto por um longo tempo, você pode querer mudar seu jogo apenas para mantê-
lo interessante para você. O que parecia divertido para você um ano atrás pode parecer chato
agora, não porque fundamentalmente não seja divertido, mas porque você esteve enterrado no
projeto por muito tempo. Evite mudar as coisas só porque você está cansado delas, pois seus
jogadores, vendo pela primeira vez, vão achar fantástico e jogar fora todo o bom trabalho do seu
time seria uma tragédia.
No entanto, mesmo no final do projeto, você pode descobrir que seu jogo realmente não é o
que você esperava, e é necessário um novo foco para corrigi-lo. Neste ponto, você precisa passar
para um modo de controle de danos. Você pode tornar a mudança de direção menos drástica
enquanto ainda resolve os problemas, de modo que os ativos antigos ainda possam ser usados?
A pior decisão que você pode tomar é criar quaisquer novos ativos que o jogo precise seguindo um
novo foco, enquanto os ativos antigos ainda seguem o foco inferior que você adotou anteriormente.
Em vez de focar o jogo, seus dois focos acabarão criando um jogo com uma personalidade dividida,
totalmente desfocada. Esforce-se ao máximo para elaborar um plano de reorientação para o seu
projeto que não o coloque acima do orçamento ou do cronograma, se forem preocupações
prementes (como quase sempre são). Perceber que seu projeto não é tão bom quanto poderia ser,
mas não ter tempo ou dinheiro para corrigi-lo adequadamente é uma posição difícil. Encontrar a
melhor solução em situações tão difíceis pode ser extremamente desafiador e frustrante.
Quando trabalhei no Centipede 3D, acabamos mudando nosso foco logo no início do projeto.
Isso resultou em uma quantidade de trabalho que precisava ser refeita, mas também levou a um
jogo significativamente mais forte no final. Centipede 3D foi um caso especial, pois era um remake
de um jogo clássico e muito amado, o Atari Centipede original, criado por Ed Logg. Ao fazer um
remake ou uma sequência, faz sentido dar uma olhada no jogo original em que você está
trabalhando e obter uma compreensão clara, por si mesmo, de qual era o foco. Isso é necessário
para que você tenha uma boa ideia do que exatamente você está refazendo. Claro que eu não
estava presente quando Logg estava fazendo o Centipede original em 1979 e 1980, mas posso
tentar adivinhar qual poderia ter sido o foco dele:
Centipede é um jogo de tiro de ação rápida envolvendo uma variedade de

adversários que o jogador deve matar para evitar ser morto por eles. Os inimigos
se movem em padrões completamente previsíveis e predeterminados, mas a
combinação do movimento dessas criaturas e outros objetos no mundo do jogo
cria uma experiência desafiadora para o jogador. O jogador pode tentar mudar o
mundo do jogo para tornar os movimentos dos adversários menos ameaçadores,
e o jogador pode ver todo o mundo do jogo de uma só vez. O jogo continua até
que o jogador morra um número específico de vezes, com pontos acumulados
para representar o quão bem o jogador se saiu naquele jogo em particular; não
há Centopeia vencedora ou finalizadora.
Esse foco é provavelmente muito longo e detalhado para ser um foco de jogo adequado, mas é
difícil para mim ler a mente de Ed Logg para saber quais eram suas principais preocupações ao
fazer Cen tipede. Então eu incluí todas as partes cruciais do jogo que eu posso encontrar. Claro, o
foco que ele usou pode não ter nenhuma relação com o acima, se ele usou um foco.
O foco da versão
3D do Centipede era
criar um jogo que
capturasse a jogabilidade
de arcade do Centipede
original em um ambiente
tridimensional baseado
em níveis.
Quando o desenvolvimento do Centipede 3D começou inicialmente, a ideia era pegar apenas

os personagens mais básicos do Centipede - o navio de tiro do jogador, as centopéias, aranhas,
pulgas e cogumelos - e fazê-los interagir em um mundo 3D. A decisão de mover o jogo para 3D já
era uma conclusão precipitada quando começamos a trabalhar no projeto. Foi uma escolha cuja
adequação era certamente discutível, dada a mecânica fundamental do original. De fato, desde a
concepção até as primeiras versões do jogo, não foi dada muita atenção à mecânica do jogo e aos
comportamentos do original. Os elementos do Centipede original estavam sendo usados mais para
estética do que qualquer outra coisa. Quando nosso protótipo de jogo inicial não ficou muito
divertido, decidimos tentar emular mais da jogabilidade do jogo original na nova versão 3D, sempre
que possível imitando e atualizando o que o Centipede de 1981 fez em um mundo 3D baseado em
níveis. À medida que começamos a buscar nosso novo foco, descobrimos que quanto mais
emulamos o clássico, mais divertido o novo jogo se tornava. Embora não tenha sido escrito na
época, pode-se dizer que nosso foco foi o seguinte:
Centipede 3D é um remake do jogo de arcade Centipede, e tenta pegar o que o

jogo original fez bem e transplantá-lo para um ambiente 3D. O Centipede original
apresentava combate de tiro rápido em ondas, com as manobras habilidosas do
jogador da nave sendo a chave para o sucesso e com inimigos que se moviam
em padrões completamente previsíveis.
Em vez de estar em um nível para todo o jogo como Centipede estava, Centi
pede 3D leva o jogador através de uma progressão de níveis. O novo jogo
também adota certas normas de jogabilidade dos jogos de console modernos,
como níveis rejogáveis, objetivos de bônus e navegação de obstáculos. As
partes de ação e combate do Centipede 3D, no entanto, serão extremamente
reminiscentes do jogo original, empregando IA idêntica sempre que possível e,
assim, mantendo a sensação de jogabilidade do original.
Com nosso novo foco, os recursos do jogo que desenvolvemos até agora foram reformulados e
vários níveis tiveram que ser descartados, enquanto outros foram significativamente reformulados.
Uma pequena quantidade de codificação que havia sido feita teve que ser modificada, mas
felizmente nenhuma mudança na arte foi necessária. Ao todo, nossa reorientação resultou em
alguma perda de trabalho. No entanto, no final, esse trabalho perdido valeu a pena porque o
Centipede 3D final tinha um estilo de jogo consistente e focado. E como resultado direto, foi divertido jogar.
É importante notar que nosso foco para Centipede 3D não era um foco autônomo como
defendi anteriormente neste capítulo. O foco para Centipede 3D refere-se a outro jogo, o Centipede
original e, portanto, não se sustenta completamente sozinho. Claro, Centipede 3D é um remake e,
como tal, faz sentido referir-se ao jogo que o projeto segue. Para um remake ou uma sequência, o
jogo que você está fazendo tem uma relação direta com o outro jogo ao qual você se refere no
foco, e grande parte do fato de o jogo ser considerado um sucesso ou não dependerá de quão
bem ele segue. seu antecessor. Como tal, ao longo do desenvolvimento do jogo, os membros da
equipe devem se perguntar como seu trabalho se relaciona com o jogo original e se o que eles
estão tentando realizar em termos de jogabilidade é um sucessor lógico e digno. Uma vez que esta
é uma preocupação tão central, ela pertence ao foco. Ao trabalhar em uma sequência ou remake,
toda a sua equipe deve ter jogado o jogo original e, portanto, pode-se esperar que o entenda
razoavelmente bem. Observe, no entanto, que o foco do Centipede 3D inclui uma breve descrição
do apelo principal do Centipede original, para que o foco possa se sustentar melhor do que se as
preocupações centrais do jogo clássico fossem assumidas. Se o foco deve se referir a outro jogo,
é importante garantir que todos os envolvidos no projeto também entendam o foco desse outro
jogo.
Sub-Focos
Pode ser vantajoso levar a técnica de foco para outro nível, incluindo sub-focos. Embora não seja
absolutamente necessário, isso permitirá que você comece a desenvolver sua ideia de jogo,
mantendo o foco geral. Um sub-foco é distinto do foco principal e deve ser designado como tal
quando apresentado ao lado do foco principal. Você pode ver um sub-foco como um conceito que
apoia seu foco principal e que ajudará seu jogo a atingir esse foco central. Um sub-foco sozinho
não pode ser usado para projetar um jogo. Ele serve principalmente para apoiar seu objetivo
principal, para separar outros objetivos pelos quais seu jogo se esforçará na tentativa de atingir o
foco central.
Para um exemplo de uso de sub-focos, retornarei ao exemplo do vento Winter Carnival Whirl .
Como você deve se lembrar, você criou um foco para um jogo que coloca os jogadores no comando
de um carnaval de inverno. Agora que você tem o foco central do Winter Carnival Whirlwind , você
pode considerar quais outros objetivos o jogo pode ter. Em que outros aspectos do jogo a equipe
de desenvolvimento deve se concentrar para garantir que nossa visão de jogabilidade seja
implementada da melhor maneira possível?
Agora pode ser a hora de explorar que tipo de jogador você está pensando que vai querer
jogar o seu jogo. Você está atraindo mais o público de jogos hard-core ou pessoas que talvez não
joguem jogos de computador com tanta frequência? Isso terá um efeito direto em muitos aspectos
do jogo, incluindo qual nível de simulação precisará ser criado (os jogadores hard-core exigirão
uma experiência de jogo mais envolvente e complexa), bem como o sistema de controle que o jogo
terá. (jogadores hard-core podem tolerar um esquema de controle mais obtuso e complicado se
isso proporcionar uma experiência de jogo mais profunda no final, enquanto os jogadores mais
casuais precisarão de algo que possam aprender rapidamente).
Talvez tenha sido seu desejo há muito tempo fazer um jogo que todos os seus amigos não-
jogadores pudessem desfrutar. Assim, você decide que quer ir para a multidão de jogos mais casuais.
Isso significa que você pode criar um sub-foco explicando o que você fará para direcionar o jogo
para esse público: “Winter Carnival Whirlwind atrai jogadores mais casuais”. Faz sentido explicar
exatamente o que você quer dizer ao tornar o jogo atraente para jogadores casuais. Provavelmente
o maior problema é o controle; você quer que o Winter Carnival Whirlwind permita que as pessoas
entrem e joguem o jogo rapidamente, sem confundi-las com muitas teclas para lembrar de controlar
o personagem principal. Seu foco pode ser: “O jogo fornece o esquema de controle mais simples
possível, com um jogador precisando usar um pequeno número de teclas fáceis de lembrar para
jogar o jogo com sucesso. Jogadores novatos podem descobrir como jogar o jogo sem ler o manual
ou jogar o tutorial, embora uma missão de treinamento seja fornecida.” Observe que você realmente
não deseja entrar em quais são os controles neste momento. Salve isso para o documento de
design. Aqui você está apenas trabalhando em seus objetivos para o jogo, não tanto nos detalhes
de como eles serão implementados. Você também pode querer dizer algo sobre o nível de
dificuldade do jogo. Se você está visando jogadores casuais, provavelmente desejará tornar o jogo
mais fácil do que seria se fosse mais voltado para o mercado hard-core. Você pode querer
especificar que o jogo será executado em vários níveis de dificuldade: “Winter Carnival Whirlwind
tem uma dificuldade geral relativamente baixa, com o jogador capaz de especificar níveis de
dificuldade no jogo. Mesmo os jogadores pouco habilidosos e fracos poderão jogar o jogo até a
conclusão no nível de dificuldade mais fácil, com tentativas suficientes.”
Pode fazer sentido falar sobre que tipo de motor e gráficos seu jogo terá em um dos sub-
focos. Discutimos anteriormente se o jogo deveria ser 2D ou 3D, mas decidimos que esse aspecto
não era central para nossa visão do jogo. Por isso, foi deixado de fora do foco principal. Pode, no
entanto, se encaixar bem como um sub-foco, algo que ajudará a definir ainda mais como o
desenvolvimento do jogo realizará a visão inicial.
Agora pode ser um bom momento para explicar o estilo visual do jogo da melhor maneira possível,
para dar à sua equipe de arte uma ideia de qual direção eles devem seguir, bem como à sua
equipe de programação que tipo de tecnologia seu jogo precisará suportar . Além disso, você pode
querer considerar nosso sub-foco anterior aqui. Ele afirma que este jogo deve atrair o público de
jogos casuais e que o jogo deve ser bastante fácil
jogar. Assim, você desejará que suas declarações sobre os gráficos do jogo suportem isso se
apropriado. “Winter Carnival Whirlwind apresenta um ambiente visualmente exuberante e de alto contraste.
Apesar de ser ambientado em um ambiente de neve e gelo um tanto monocromático,
efeitos especulares serão usados para diferenciar claramente os diferentes tipos de gelo. O jogador
personagem junto com os patronos do carnaval de inverno serão coloridos em seus
equipamentos para o frio, a fim de afastá-los do ambiente e torná-los mais fáceis
ver." Você pode decidir que deseja buscar uma tecnologia de mecanismo 3D que lide bem com a física,
pois isso pode ajudar a capturar melhor a natureza fora de controle de correr em
neve e gelo, e como a natureza do mercado exige um jogo 3D. Como parte de
o mecanismo 3D, talvez uma visão em terceira pessoa com zoom variável seja a que funcionará melhor
para permitir que o jogador controle seu gerente de carnaval atormentado enquanto fica de olho em todos
as atrações. Portanto, sua declaração de foco pode incluir: “O jogo usa um mecanismo 3D
que permite ao jogador ampliar e reduzir facilmente os eventos micro ou macro
lugar no carnaval de inverno, com tecnologia capaz de renderizar todo o carnaval de uma só vez quando
necessário.”
Claro, pode haver vários outros sub-focos para o Winter Carnival Whirl wind, cobrindo tudo, desde a
mecânica de jogo até que tipo de enredo o
jogo terá, quanto tempo um jogo médio deve durar. Tente sempre evitar colocar
detalhes demais, no entanto. Isso é para o documento de design. Aqui você está apenas configurando
a direção do projeto, não realmente implementando-o. Mas para os propósitos do nosso exemplo, temos
sub-focos suficientes agora, deixando-nos com um foco e sub-focos que parecem
como isso:
Winter Carnival Whirlwind é uma ação e tema de personagem rápido e furioso

jogo híbrido de gerenciamento de parques. A experiência do jogador gira em torno de dirigir
um carnaval de gelo, com o jogador responsável por manter uma temporada o mais longa
possível, apesar do clima não cooperativo. O jogo captura a emoção
de brincar na neve, incluindo a física simples que torna isso divertido, através de um
personagem central que deve navegar em um ambiente um tanto perigoso e
manter vários sistemas operando sem problemas. A principal fonte de conflito do jogador é
o próprio clima. Winter Carnival Whirlwind tem um tom leve e caprichoso
por todo.
Público
Winter Carnival Whirlwind atrai jogadores mais casuais. O jogo

fornece o esquema de controle mais simples possível, com um jogador precisando usar
um pequeno número de teclas facilmente lembradas para jogar o jogo com sucesso.
Jogadores novatos podem descobrir como jogar o jogo sem ler o
manual ou jogando o tutorial, embora uma missão de treinamento seja fornecida.
Winter Carnival Whirlwind tem uma dificuldade geral relativamente baixa, com o
jogador capaz de especificar níveis de dificuldade no jogo. Mesmo marginalmente qualificados,
jogadores pobres serão capazes de jogar o jogo até o fim no nível de dificuldade mais
fácil, com tentativas suficientes.
Visuais
Winter Carnival Whirlwind apresenta um ambiente visualmente exuberante e de alto

contraste. Apesar de ser ambientado em uma neve e gelo um tanto monocromáticos
ambiente, efeitos especulares serão usados para diferenciar claramente diferentes
tipos de gelo. O personagem do jogador junto com os patronos do carnaval de inverno

serão coloridos em seus equipamentos de clima frio para ativá-los
do meio ambiente. O jogo usa um motor 3D que permite a
player para ampliar e reduzir facilmente os eventos micro ou macro que ocorrem
no carnaval de inverno, com a tecnologia capaz de renderizar todo o
carnaval de uma vez quando necessário.
Observe como os sub-focos são destacados por títulos separados do foco principal.
Desta forma, os leitores do foco podem ver facilmente o foco principal e mais importante e
como os sub-focos entram em detalhes sobre partes específicas do jogo.
Como você está trabalhando em seus sub-focos, é importante sempre certificar-se de que
eles combinam com seu foco primário, bem como com quaisquer outros sub-focos que você possa ter. Por
Por exemplo, faz sentido que o sub-foco Visuals fale sobre o jogo fornecendo um
mundo do jogo que é simples de entender visualmente, já que o sub-foco Audience fala
sobre como tornar o jogo fácil de pegar e entrar. Se você já está contradizendo
você mesmo na escrita do seu foco, você terá muita dificuldade em escrever um
documento de design completo que faz algum sentido. Mantendo todos os componentes do seu
No entanto, os focos que se apoiam mutuamente não devem ser um problema, uma vez que os focos
devidamente escritos devem ser curtos, concisos e fáceis de entender.
Usando o foco
É importante perceber que sua declaração de foco não é uma ferramenta de marketing. Não foi criado
para vender seu jogo aos executivos. Não é escrito com a esperança de imprimi-lo em
no verso da caixa ou mostrando aos responsáveis pelas compras para grandes varejistas. Ele é escrito
em primeiro lugar como uma ferramenta de desenvolvimento para sua equipe. Escrevendo um
declaração que estabelece claramente os objetivos do seu jogo será difícil o suficiente sem
também tentando criar algo que funcione para o pessoal de marketing. Mesmo assim, você
pode ser capaz de tirar o seu foco e transformá-lo em algo para obter o seu marketing
departamento animado com o seu jogo. Se gerar um número significativo de vendas é um
dos itens em sua agenda (vamos presumir que não é sua principal motivação para trabalhar em jogos,
pois certamente existem carreiras mais lucrativas para seguir), então ter o
as pessoas de marketing ficam empolgadas com o seu jogo quando tentam vendê-lo é quase tão
importante como deixar os programadores animados durante o desenvolvimento do jogo. Pessoas de
marketing tentarão vender jogos em que acreditam e que acham legais
conceitos, e uma versão modificada e adaptada de sua declaração de foco pode servir para
explique rapidamente a eles o que é tão emocionante sobre sua ideia. É claro que o pessoal de marketing
também adora descrições comparativas, como: “Basicamente, o jogo Bejeweled encontra
Max Payne.” Assim, você pode querer fazer algumas comparações diretas que coloquem
seu jogo no contexto de jogos populares conhecidos, jogos que os especialistas em marketing já sabem
vender. Claro, você pode usar o conteúdo do seu foco para
respaldar tais comparações superficiais e fazer o pessoal do marketing entender por que
seu jogo é único e atrairá os jogadores. Com esse conhecimento em mãos, espero
eles podem fazer uma campanha publicitária que seja uma representação apropriada do seu jogo e
não é algo que você vai se envergonhar quando vir nas revistas.
Independentemente de quais outros aplicativos você possa encontrar para ele,

lembre-se sempre de que anotou seu foco para ajudar no desenvolvimento do seu jogo.
Muitos designers de jogos não têm foco quando estão trabalhando em um jogo, e isso
fica evidente. Alguns o temem porque não querem ficar “trancados” em nenhuma ideia.
Tal apreensão é infundada, pois você tem a liberdade de mudar seu foco sempre que quiser.
De fato, sem anotá-lo, você pode nem perceber que uma mudança de curso se justifica.
Claro, é possível fazer um bom jogo sem realmente ter a menor ideia do que é o seu
jogo. Também é possível ganhar na loteria. Quando sua vida, reputação e a qualidade
do seu jogo final estão em jogo, no entanto, você quer algo mais do que sorte para
determinar se o seu jogo funciona ou não. Usar um foco é uma ferramenta que o ajudará
a criar um jogo sólido, divertido e atraente.
Capítulo 6
Entrevista: Ed Logg
Asteróides, Centopéia e Manopla. Se alguma vez houve um histórico impressionante

para um designer de jogos, é isso. Adicione alguns clássicos menos conhecidos,
como Super Breakout, Millipede, Gauntlet II e Xybots, e você terá uma carreira
verdadeiramente inigualável. Ed Logg projetou e desenvolveu todos esses títulos
na Atari no auge dos arcades. Antes do colapso do mercado de moedas, Logg já
havia mudado para trabalhar no desenvolvimento de jogos domésticos, adaptando
jogos populares de arcade da Atari, como a série San Francisco Rush , para
consoles. Posteriormente, Logg assumiu um jogo original em casa pela primeira
vez, servindo como programador principal no exclusivo jogo de plataformas Dr.
Muto. Hoje Logg voltou às suas raízes, trabalhando em jogos para celulares.
Olhando para eles, os jogos de arcade clássicos parecem bastante simples, mas
é essa simplicidade que obrigou seus designers a refiná-los até a perfeição. Os
clássicos jogos de moedas da Logg continuam sendo alguns dos melhores jogos
de computador já feitos, e os insights que os designers podem obter ao estudá-los são enorm
Como foi trabalhar na Atari no final dos anos 70 e início dos anos 80?
Éramos jovens e cheios de energia. Imagino que seja muito semelhante à atmosfera da maioria
das start-ups da Internet atualmente. Éramos um grupo relativamente pequeno na Divisão de
Jogos Operados por Moedas. Isso permitiu que todos conhecessem todos os outros. Ideias e
brincadeiras fluíam livremente. Como estávamos trabalhando em uma nova mídia, poderíamos
fazer qualquer coisa e seria “novo”. Mesmo jogos como Lunar Lander, feito por Rich Moore, que
havia sido feito originalmente anos antes, eram novos para o nosso público.
87
88 Capítulo 6: Entrevista: Ed Logg
De onde veio a maioria das ideias para os jogos?

As ideias vieram de muitas fontes.
Por exemplo, Owen Rubin, outro
engenheiro da Atari, me disse que
Nolan Bushnell havia sugerido a
ele uma extensão do Breakout.
Peguei a ideia dele e adicionei
muitas das minhas para criar o
Super Breakout, meu primeiro
sucesso comercial.
A ideia de Asteroids veio de Lyle
Rains, que era responsável pela
engenharia na época. Ele teve a
ideia de um jogo anterior de
moedas. Xybots veio de um
desafio de Doug Snyder,
Asteróides
engenheiro de hardware da Atari.
Queríamos fazer um jogo multi-jogador do tipo Castle Wolfenstein, mas não tínhamos hardware de
“mapa de bits”. Então eu criei um algoritmo baseado em carimbos de 8 por 8 e ele fez o hardware.
Centipede veio de uma lista de ideias de brainstorming. A Atari saía do local todos os anos para
pensar em novas ideias. Uma dessas ideias foi “Bug Shooter”, que foi usado como ponto de partida
para Centipede.
A gerência tinha revisões onde eles entravam e jogavam o jogo e davam feedback. Às vezes,
o consenso era negativo e um jogo podia ser morto. Na maioria das vezes, continuaria até que
pudesse ser “testado em campo”. Isso significava que cabia aos jogadores determinar quanto e
por quanto tempo o jogo ganhava. No entanto, às vezes, boas sugestões vieram dessas avaliações.
A mais importante de todas foi uma sugestão de Dan Van Elderen, responsável pela engenharia.
Ele me perguntou por que não podíamos atirar nos cogumelos em Centipede. Sim, os cogumelos
eram originalmente estáticos. Foi sua sugestão que levou ao avanço que tornou este jogo divertido.
Você estava animado para entrar no desenvolvimento de jogos na Atari?

Na verdade, eu fazia jogos há muitos anos, enquanto estava no ensino médio, em Berkeley nos
anos 60, e também no meu primeiro emprego na Control Data Corp. computadores.
Eu construí um computador doméstico um ou dois anos antes de ingressar na Atari, apenas

para criar e jogar. Eu tinha ido a um Pizza Time Theatre e jogado Pong e Breakout, então eu
estava bem ciente do negócio de moedas. Eu também tinha jogado e me inspirei muito em um
protótipo do Atari VCS (2600) em uma festa de Natal em 1977. Então a mudança de emprego me
pareceu natural. Na época, achei ótimo eles me pagarem para criar e jogar.
Capítulo 6: Entrevista: Ed Logg 89
Dirt Bike foi seu primeiro jogo para a Atari, mas entendo que não chegou à produção. Que
tipo de jogo era?
Este jogo foi iniciado por Dennis Koble, que fez muitos títulos de consumo. Era um jogo semelhante
ao Sprint , exceto que você dirigia uma bicicleta suja e o controle era um conjunto de guidão que
poderia ser usado para dirigir a bicicleta em vez de um volante.
Testamos o jogo em campo e ele ganhou dinheiro suficiente para torná-lo bom o suficiente
para não matar, mas não bom o suficiente para entrar em produção. No entanto, eu fiz Super
Breakout ao mesmo tempo em que estava trabalhando em Dirt Bike. Ninguém na Atari havia
trabalhado em dois jogos ao mesmo tempo antes. Super Breakout ganhou uma grande quantia de
dinheiro, e isso provavelmente levou à decisão de não construir a Dirt Bike. Não fiquei desapontado
considerando o sucesso do Super Breakout.
Qual foi a gênese do Super Breakout?

A ideia original incluía seis variações de Breakout. Eu imaginei três jogos lançados com duas
variações em cada jogo. No entanto, no jogo real, havia um favorito geral: Progressive Breakout.
No final, colocamos três variações em um jogo: Progressive, Double e Cavity Breakout. As
variações que não o fizeram eram mais orientadas verticalmente e eu tive que concordar que não
eram tão divertidas.
Você teve muita liberdade criativa em Super Breakout, ou ficou limitado por ser uma
sequência de um sucesso anterior?
Para mim, Super Breakout não foi uma sequência.
Lembre-se, o jogo original não foi feito em software.
O código teve que ser criado do zero e a jogabilidade era
completamente diferente do original, embora usássemos
os mesmos controles.
Foi-me dada liberdade porque estava a fazer o título
sem qualquer sanção oficial. Não era a última vez que eu
faria isso, também. Os jogos podiam ser feitos em pouco
tempo naqueles dias, o que significava que você podia
fazer algo divertido antes que alguém percebesse que
você estava fazendo algo diferente.
Talvez eu devesse explicar como estávamos
desenvolvendo jogos naquela época. Tínhamos um
computador digital principal que tinha o montador cruzado
para nossos jogos baseados em 6502. Tínhamos várias Super Breakout
garotas que inseriam nossas páginas manuscritas em
nossos programas e nos devolviam uma impressão de computador e uma fita de papel. Sim, você
ouviu direito. Em seguida, alimentamos a fita de papel através do nosso sistema de desenvolvimento
na RAM substituindo a ROM do jogo na PCB. Depuramos isso usando ferramentas primitivas e um
analisador de hardware e escrevíamos nossas alterações na impressão em papel. Como esse
processo deixou um tempo entre a sessão de depuração e a próxima versão, usei esse tempo
para desenvolver um segundo jogo. Eu apenas trocaria os gráficos PROM (sim, nós mesmos
criamos os gráficos à mão) e colocaria a nova fita de papel.
É realmente surpreendente que você tenha desenvolvido um jogo usando métodos tão
primitivos. Como você conseguiu ajustar seu jogo com tanto tempo entre as versões?
Bem, na verdade, eu era muito bom em apenas corrigir a RAM com novas instruções, então era fácil
ver o que pequenas mudanças faziam no jogo. Também tínhamos um analisador HP que poderíamos
usar para capturar em muitas condições, o que nos permitiu encontrar muitos bugs que muitos sistemas
de desenvolvimento não conseguem fazer hoje. Na verdade, era possível fazer alguma nova codificação
enquanto você esperava que suas últimas alterações fossem feitas, então menos tempo foi perdido do
que você pensa.
Mas você certamente concorda que as ferramentas de desenvolvimento modernas tornaram o

desenvolvimento de jogos mais fácil?
Existem várias questões aqui. Primeiro, naquela época sabíamos tudo sobre o hardware do tar get, o
que tornava mais fácil ver o que estava errado. Hoje, o hardware de destino geralmente está escondido
de nós e existem várias camadas de software, o que pode dificultar a depuração ou fazer o que
realmente queremos. Então, nesse sentido, é muito mais difícil agora. Além disso, essas camadas
modernas de software ou hardware geralmente não são documentadas, documentadas incorretamente
ou apenas atrapalham. Em segundo lugar, o hardware ficou muito complexo com as interações entre
os muitos bytes causando todo tipo de problema. Terceiro, os processadores se tornaram muito
complexos, causando todo tipo de pesadelo de depuração, especialmente ao lidar com os caches.
Quarto, hoje existem muitos programadores trabalhando em um jogo e é fácil atrapalhar um de seus
colegas de trabalho.
Surpreendentemente, o ambiente de desenvolvimento não ficou mais rápido nos últimos anos,
apesar dos grandes aumentos no poder de computação e na RAM. Como exemplo, alguns dos meus
arquivos no meu Mac IIci de 25 MHz com 6 MB de RAM compilam e vinculam ao mesmo tempo ou
mais rápido do que arquivos em um PC de 550 MHz sob NT com 512 MB de RAM. Mesmo o mesmo
projeto no meu Indy de 150 MHz é construído mais rápido do que no meu PC de 550 MHz. Eu acredito
firmemente que todo desenvolvedor de ferramentas deve ter o sistema mais lento possível para usar
para desenvolver seu software! Caso contrário, estamos condenados a continuar a correr mais rápido
a cada nova atualização.
As ferramentas modernas são muito melhores do que o método antigo, é difícil imaginar como eu
poderia ter feito tão bem, mas você não deve esquecer quanto tempo é gasto aprendendo cada nova
ferramenta de software, processador e sistema operacional hoje em dia. Além disso, a quantidade de
tempo perdido perseguindo bugs em novos sistemas porque não entendi algum outro hardware ou
software é muito grande. Mas eu não gostaria de voltar às ferramentas antigas a menos que os
processadores, hardware, software, conceitos de jogo e tamanhos de equipe fossem muito mais
simples.
Eu nunca vi seu próximo jogo, Video Pinball. Como jogou?

Simulou pinball usando um espelho meio prateado com um monitor abaixo do espelho e os gráficos
para o campo de jogo acima do espelho. O monitor mostrava as nadadeiras e a bola, o que dava a
impressão de que a bola branca estava no campo de jogo. O campo de jogo realmente tinha LEDs
controlados pelo programa que simulava alvos iluminados. Além disso, o painel de controle era
articulado, o que permitia ao jogador “cutucar” o gabinete para dar um pouco de inglês à bola. Eu não
pensei neste jogo. Acho que foi ideia do Dave Stubben.
Como você esperava convencer os jogadores a jogar Video Pinball em vez do jogo real?
Eu não acreditava que o Video Pinball seria bem sucedido e eu estava fazendo essa pergunta exata.
No entanto, havia lugares em que os videogames podiam ir que um grande jogo de pinball não
podia. No final, o jogo rendeu mais do que eu esperava e foi um sucesso comercial. Devo dizer que
estava errado em minhas primeiras impressões, e isso não acontece com frequência.
Foi difícil trabalhar em um projeto que você não achou que seria divertido? O jogo final
acabou sendo divertido?
A jogabilidade foi divertida, mas não se compara a um jogo de pinball real. Fiquei surpreso que
vendeu tão bem. Sim, foi difícil trabalhar em uma ideia que eu não achava que funcionaria bem. Mas
eu era jovem e motivado... O que mais posso dizer?
De onde veio a ideia de Asteroids ?
Lyle Rains havia me sugerido a

ideia de um jogo em que o jogador
pudesse atirar em asteróides
porque havia um jogo anterior com
um asteróide indestrutível que os
jogadores continuavam atirando
em vez de perseguir o objetivo
pretendido. Eu disse a Lyle que
precisaríamos de um disco para
forçar o jogador a atirar nos
asteróides em vez de perder
tempo. Eu também sugeri quebrar
as pedras em pedaços para dar
aos jogadores alguma estratégia
em vez de apenas atirar nas
Asteróides
pedras maiores primeiro.
Lyle me deu a ideia. As pessoas muitas vezes atribuem o sucesso a um ou outro de nós. Eu
provavelmente não teria tido a ideia por conta própria, e se outra pessoa tivesse feito o jogo,
provavelmente teria sido totalmente diferente. Então, na verdade, nós dois deveríamos receber
crédito por essa ideia. Pensando bem, sem o hardware vetorial, Asteroids também não teria sido um
sucesso. Portanto, há muitas pessoas e eventos que levaram ao seu sucesso. Estou muito feliz por
ter estado lá naquele momento e lugar.
O jogo mudou muito pouco no desenvolvimento da ideia original. Fiz dois pires, um burro e um
inteligente. Fiz uma mudança fundamental perto do final do projeto que teve implicações de longo
alcance. Originalmente, o disco dispararia assim que o jogador entrasse na tela. Os jogadores
reclamaram – e eu concordei – isso parecia injusto. Muitas vezes, o disco não era visível apenas na
borda e, se começasse próximo ao seu navio, você não tinha defesa. Então eu adicionei um atraso
antes de seu primeiro tiro. Isso, é claro, levou à estratégia de “espreitar”. Durante o teste, eu
realmente tentei me esconder em um ponto e
decidiu que não ia funcionar, o que mostra o quão bem o designer de jogos pode jogar seu próprio jogo.
Você ficou surpreso com o sucesso de Asteroids ?
Não me surpreendi com seu sucesso. Parecia um jogo divertido quando eu jogava na minha mente. Mesmo
depois das primeiras semanas, as pessoas vinham e perguntavam quando poderiam jogar. Isso foi um
sinal de que seu jogo foi divertido!
Mesmo quando testamos o jogo pela primeira vez, vi um jogador iniciar um jogo e morrer três vezes
em 20 segundos. Ele começou a colocar mais um quarto.
Isso me diz que o jogador sentiu que foi sua culpa que ele morreu e ele estava convencido de que poderia
fazer melhor. Este é um dos principais objetivos que um designer de jogos tenta alcançar e ficou claro para
mim que Asteroids tinha “isso”.
Lá atrás, você mencionou que jogou o jogo “em sua mente”. Você acha que essa é uma técnica
eficaz para prever se um jogo será divertido ou não?
É uma habilidade que acho que

funciona bem para mim. Também
faço o papel de advogado do diabo
com minhas ideias. Eu me pergunto:
“O que pode dar errado?” ou “Os
jogadores ficarão confusos com o
que estou apresentando?” Acho que
alguns designers muitas vezes são
tão casados com suas ideias que
não aceitam o conceito de que talvez
simplesmente não funcione. Eu não
posso te dizer o número de ótimas
ideias que eu tive que eu “executei”
em minha mente que acabaram
sendo más ideias.
eu sou um dos poucos Asteróides
designers que eu já conheci que realmente matou muitos de seus próprios jogos. Acho que essa é uma
boa característica. Por que perder mais um ano para dois se a jogabilidade não funciona como você
esperava?
Você trabalhou na sequência, Asteroids Deluxe?
Eu não fiz Asteroids Deluxe. Foi feito por Dave Shepperd. Fui promovido nessa época para um cargo de
supervisor. Acredito que também estava liderando o projeto de futebol de quatro jogadores .
Então eu estava ocupado. Eu não tenho nenhum problema em fazer sequências se esse for o melhor curso
de ação. Eu tinha algumas ideias novas, então eu queria fazer Millipede. Gauntlet II foi uma escolha lógica,
pois Bob Flanagan, meu co-programador, e eu conhecíamos o código e esse foi o melhor conceito de jogo
que criamos.
Depois de Asteroids você não fez outro jogo baseado em vetores. Você não gostou de trabalhar
com o hardware?
Na verdade, eu adorava o hardware vetorial porque me permitia colocar gráficos de alta resolução de
1024 por 768. No entanto, a indústria estava apenas mudando para monitores coloridos na época. Dave
Theurer fez Tempest como um jogo de vetor de cores, mas a máscara de cores nos monitores coloridos
não permitia alta resolução. Além disso, não era possível preencher a tela com cores em jogos baseados
em vetores, de modo que o meio morreu com o avanço dos jogos de cores.
Asteroids não foi o primeiro jogo da Atari a ter uma tabela de recordes?
Na verdade, Asteroids não foi o primeiro jogo; havia outro jogo que o usava antes. Achei que a ideia era
uma ótima maneira de preservar sua pontuação e identidade para o mundo ver. Então eu adicionei a
Asteroids. Eu vejo isso como preenchendo o papel do grafite. Agora é o padrão, é claro, e a indústria
adicionou RAM ou EEROM com bateria para salvá-lo permanentemente.
Nessa época você criou o cartucho Othello para o Atari 2600. Entendo que você estudou IA
enquanto estava em Stanford. O projeto Othello surgiu do seu interesse em IA?
Não, na verdade, os asteróides mostraram mais influência da minha experiência em Stanford. Enquanto
eu estava no Stanford AI Lab, joguei Space War em suas máquinas PDP. Eu também joguei uma versão
com moedas na cafeteria do Student Forum. Na minha cabeça, este foi o primeiro videogame. Pong
certamente foi o primeiro videogame comercial. De qualquer forma, o design da nave espacial em
Asteroids era uma cópia da nave original da Guerra Espacial .
Eu tinha jogado Otelo como um jogo de tabuleiro e fiquei intrigado com as possíveis estratégias.
Então eu trabalhei neste jogo em casa e desenvolvi uma ideia de que o jogo poderia ser jogado por
correspondência de padrões sem qualquer IA. Em outras palavras, o computador não antecipa suas
respostas a nenhum de seus movimentos, que era a abordagem padrão da IA na época. Então, realmente,
o jogo Othello que eu fiz não tinha IA. Foi bom o suficiente para o jogador iniciante e médio. Não era um
jogo avançado de forma alguma. Além disso, o 2600 tinha apenas 128 bytes de RAM, então não havia
muito espaço para olhar para frente.
Na verdade, Carol Shaw fez a parte mais difícil ao me fornecer o kernel que desenhou as peças em
um tabuleiro de xadrez. O 2600 era extremamente difícil de fazer qualquer coisa complexa. Destinava-se
a fazer jogos no estilo Pong. Você gastou todos os ciclos de contagem de vídeo ativos para desenhar a
tela. Isso deixou Vblank para fazer qualquer pensamento ou outro trabalho. Havia memória RAM limitada
para que nada complexo pudesse ser salvo na memória RAM. Otelo tinha 2.048 bytes. A maior parte
disso era o kernel. Então, muitas vezes eu passava um tempo tentando eliminar alguns bytes para
adicionar algo novo.
Centipede foi seu próximo jogo?

Não, como mencionei, eu era supervisor na época. Eu era o líder do projeto de futebol de quatro
jogadores e um kit para atualizar as jogadas no jogo de futebol original .
Em Centipede, pensei na ideia dos segmentos da centopéia e na forma como as pernas se moviam.
Não acredito que tenha sido mencionado na ideia original do brainstorming “Bug Shooter”. Na verdade,
ninguém nunca deu um passo à frente para reivindicar “Bug Shooter” como sua ideia.
Talvez fosse devido ao produto final ser muito diferente da ideia original.
Eu havia designado uma nova programadora, Donna Bailey, para fazer a programação no Centipede.
No meio do projeto, deixei de ser supervisor (não gostava do trabalho e me afastou de fazer jogos) e
passei um tempo trabalhando no Centipede.
Então Bailey foi muito importante para o desenvolvimento do jogo?

Eu acho que ela fez cerca de metade da programação. O design do jogo foi deixado para mim porque
ela estava trabalhando em seu primeiro projeto.
Parece que Centipede atrai mais as mulheres do que a maioria dos jogos de arcade. Você acha
que Bailey teve algo a ver com isso?
Eu gostaria de saber a resposta para essa pergunta.
Alguém poderia apontar que nenhum outro jogo que
fiz atrai tanto as mulheres quanto o Centipede.
Muitas teorias foram sugeridas. Uma é que foi

criado por uma mulher. Outra é que destruir insetos se
encaixa bem com a psique de uma mulher. Acredito
que este jogo atrai as mulheres porque não é
tendencioso de gênero como jogos de luta ou RPGs
ou jogos de esportes. Outros exemplos como Pac-Man
e Tetris são notáveis.
Eu sei que Centipede se encaixa no critério
básico para um jogo que agrada a um público amplo.
Tem um visual novo e atraente (para que os jogadores
Centopéia
experimentem), um objetivo óbvio (atirar em qualquer
coisa), regras claras, um conjunto fácil de controles, uma sensação de realização (mate a centopéia
inteira antes que ele o pegue), estratégias dinâmicas abundam (prender a centopéia e matar aranhas
ou a estratégia blob ou canalizar a centopéia ou simplesmente jogar direto), aleatoriedade suficiente
para tornar o jogo diferente a cada vez, um objetivo para mantê-lo (uma nova vida a cada 12.000
pontos) , uma sensação clara de melhorar com mais jogo e uma sensação de que qualquer morte foi
culpa do jogador.
Então você mencionou que Centipede surgiu de uma ideia de brainstorming. Como funcionou
o processo de brainstorming na Atari?
As ideias do brainstorming vieram de qualquer pessoa da empresa. Eles geralmente se reuniam
semanas antes da reunião real, que acontecia fora do local, longe da Atari. Muitas vezes as ideias
eram apenas um tema. A maioria dos envios tinha uma espécie de esboço ou arte para dar ao leitor
um pouco mais de informação. Ocasionalmente, uma descrição completa do jogo era enviada,
explicando o hardware, controles, arte e jogabilidade.
Durante a sessão de brainstorming, cada ideia seria apresentada e, em seguida, seriam feitas
sugestões para melhorá-la. Além disso, o marketing daria um resumo do que estava vendendo e do
estado da indústria. Também nos dividimos em grupos menores para discutir um tipo específico de
jogo ou falar sobre jogos específicos. No final, nos encontraríamos novamente para apresentar
quaisquer ideias adicionais dessas reuniões menores e
votar nas ideias populares. Eu diria que obteríamos a maioria de programadores e designers,
mas havia um número significativo de ideias de artistas e outros na empresa. Descobri que
muitas das ideias precisavam de muito trabalho, então não era incomum que a ideia original do
brainstorming sofresse uma grande reformulação.
A Atari Games Corp., agora Midway Games West, ainda usa esse processo todos os anos.
Mas, honestamente, muitos dos jogos recentes de moedas são apenas remakes de jogos mais
antigos. Por exemplo, mais versões de Rush ou Cruisin'. O motivo geralmente é direcionado ao
mercado: esses são os jogos que se saíram bem no passado e a empresa geralmente não quer
arriscar uma chance em um novo tema.
Como Centipede mudou ao longo do desenvolvimento do jogo?

Mencionei que Dan Van Elderen perguntou por que
o jogador não podia atirar em cogumelos. Percebi
cedo que precisaria de alguns meios para criar
novos cogumelos. Isso levou um a ser deixado
quando um segmento de centopéia foi baleado. Eu
também criei a pulga que deixou um rastro deles
quando ele caiu para criar mais aleatoriedade no
padrão. Em outras palavras, eu não queria que o
jogador criasse o único padrão de cogumelos. A
aranha sempre foi planejada para ser meu “disco
de asteróides ” que mantinha o jogador em
movimento; a aranha também teve que comer
cogumelos para manter a área do jogador um pouco
livre de cogumelos. O escorpião foi adicionado para
Centopéia
adicionar uma aleatoriedade ao padrão da centopéia
e criar uma sensação de pânico quando os segmentos viessem correndo para a parte inferior da tela.
Você tenta criar jogos que permitem que diferentes jogadores usem estratégias
diferentes para ter sucesso?
Eu me esforço para dar aos jogadores o máximo de liberdade para criar o maior número possível de estratégias.
Então, de certa forma, sim, acho que encorajo os jogadores a experimentar e tentar estratégias
diferentes. Eu tento garantir que nenhum deles funcione o tempo todo ou torne o jogo muito
fácil. Mas eu quero deixar o jogador com a impressão de que se ele fosse um pouco melhor,
ele conseguiria.
Por que você escolheu usar o trackball para Centipede?

Acredito que usamos o trackball desde o início. Eu tinha experiência com o trackball no futebol,
mas queria algo que não fosse tão pesado e físico para se movimentar.
Foi assim que surgiu o trackball Centipede . O trackball, assim como o mouse do computador,
fornece um meio para inserir direção arbitrária e velocidade. Nenhum outro controlador chega
perto. Foi o vencedor claro para a controlabilidade do jogador.
Na minha opinião, Centipede é um dos jogos mais equilibrados de todos os tempos.

Houve muita experimentação para alcançar tal equilíbrio?
Eu não usaria o termo experimentação neste caso porque nada foi tentado e descartado. Havia
um gafanhoto que pretendíamos adicionar para pular no jogador, mas a aranha foi suficiente
para forçar o jogador a se mover, de modo que o gafanhoto nunca foi tentado. Claro, você
ainda pode ver os gráficos do gafanhoto se observar os gráficos de autoteste.
Certamente houve muita afinação. O momento e a velocidade de quando as coisas

aconteceram certamente mudaram ao longo do projeto. O equilíbrio vem das regras inerentes
ao jogo e da arte de saber quando deixar o jogo em paz e quando mudar alguma coisa. Esta
arte é algo que algumas pessoas têm e outras não. Não posso defini-lo a não ser usar o termo
“senso de jogo”.
Você teve liberdade para fazer o que quisesse por Millipede?

Com meu histórico anterior, tive mais liberdade do
que qualquer outra pessoa. Algo que a maioria das
pessoas não entende é que metade dos jogos que
comecei não chegou à produção. Ninguém nunca
ouve falar dos fracassos. Alguns dos jogos eu
realmente me matei. Isso é algo que acredito que
ninguém mais na Atari fez. Claro, existem alguns
que eu tentei matar, mas não foi permitido que
acabou morrendo. Hoje em dia, você provavelmente
os veria no mercado consumidor de qualquer
maneira apenas para recuperar parte do custo de
desenvolvimento. Mas no mercado de moedas não
há chance de vender qualquer coisa que não seja
um vencedor claro.
Milípede
O Millipede permitiu que os jogadores começassem mais longe no jogo, com 45.000
pontos, por exemplo. Isso foi um esforço para encurtar os jogos dos jogadores experientes?
Era uma forma de aumentar a caixa de dinheiro. Permitiu que os bons jogadores começassem com uma pontuação
mais alta, onde a jogabilidade estava em um nível de dificuldade que provavelmente estava um pouco acima do seu
nível de habilidade. Isso muitas vezes significava tempos de jogo mais curtos, mas permitiria pontuações mais altas.
Em certo sentido, eu estava fazendo isso por razões de marketing. Esta não foi a primeira vez para Millipede.
Tempest tinha esse recurso em 1981.
Eu particularmente gosto do “crescimento” dos cogumelos extras em Millipede. Isso foi

feito usando um algoritmo de “vida”?
Sim, é baseado no jogo da vida onde dois ou três vizinhos criariam um novo cogumelo e
qualquer coisa mais ou menos mataria o cogumelo. Isso tem uma história interessante. Mark
Cerny perguntou por que eu não fiz um algoritmo de vida nos cogumelos. Eu disse a ele que
estava ocupado, mas se ele quisesse adicioná-lo ao jogo, ele poderia. Claro, Mark, sendo o
cara esperto que é, olhou para o meu código e rapidamente criou esse recurso. Ele também
adicionou o modo de atração para demonstrar todas as criaturas.
Durante o período Asteroids to Millipede , quase todos os seus jogos estavam sendo portados
para uma ampla variedade de sistemas: o 2600, o Apple II e assim por diante. Como você se
sentiu com essas conversões?
Era um bom negócio para a empresa, então fazia
sentido para os negócios. Claro que sempre me deu
orgulho ver meu jogo em muitos lugares novos. Eu
tive algumas preocupações sobre várias das portas.
Entendo as limitações de alguns dos sistemas, mas
queria ter certeza de que a empresa lançasse a
melhor conversão possível. Em muitos casos, eu
estava envolvido em garantir que ele tivesse todos os
recursos, mas infelizmente não com frequência
suficiente.
Algumas das conversões fizeram melhorias que
não eram possíveis no mercado de moedas. Por
exemplo, em Gauntlet , eles criaram um modo de
missão com uma quantidade limitada de saúde.
Milípede
Isso não seria possível no coin-op, onde o objetivo é
obter mais dinheiro adicionado regularmente. Outro exemplo seria observar o número de variações
do Pong incluídas no cartucho do Atari 2600. Faz sentido agregar valor a um título de consumidor.
Maze Invaders foi o próximo jogo em que você trabalhou depois do Millipede? Eu sei que
nunca entrou em produção.
Era um jogo de quebra-cabeça fofo. Eu não estava triste por não ter conseguido; não ganhou o
suficiente no teste de campo. Meu filho adorou o jogo e ainda tenho um dos dois protótipos na
minha garagem. A outra foi comprada por um operador no Texas, acredito. Ele amou tanto o jogo
que convenceu a Atari a vendê-lo.
Acredito que mencionei anteriormente que quase metade dos meus jogos não chegou à
produção. Havia engenheiros que tinham uma porcentagem maior, Dave Theurer em particular.
Mas houve outros que nunca tiveram um jogo em produção.
O nome Maze Invaders sugere talvez algo inspirado no Pac-Man.

Foi isso?
Sim, de certa forma. Era um jogo de labirinto, mas o labirinto mudava dinamicamente. O personagem
principal era muito parecido com o Pac-Man ; ele era fofo. Houve algumas partes que achei
frustrantes, como quando o labirinto me bloqueava temporariamente. Não consegui resolver esse
aspecto frustrante, provavelmente por isso falhou.
Eu soube que em 1983 você também trabalhou em um jogo de disco laser Road Runner . Foi
baseado no personagem de desenho animado da Warner Bros.?
Sim, foi baseado no Road Runner criado por Chuck Jones. O jogador fez o papel do Road Runner
que tentaria fazer com que Wile E. Coyote fosse vítima de alguma armadilha. Pedi à Time Warner
que me enviasse todos os desenhos de Road Runner. Assisti a todos e selecionei os melhores
curtas para serem incluídos em um disco laser. Então, quando você conseguiu
destruindo Wile E., o jogo cortaria a ação para uma cena semelhante de um desenho animado onde
Wile E. encontrou seu destino habitual.
Eu sempre amei o Road Runner e pensei que poderia trazê-lo para um videogame.
Quando comecei, tive uma visão de algo único. O jogo certamente atendeu a esse critério, mas não
foi tão divertido quanto eu esperava. Eu certamente estou gostando de ver todos os desenhos antigos
e conhecer Chuck Jones, mas…
Então o jogo foi morto?

Os jogos de disco laser estavam falhando no mundo das moedas por causa de problemas de
confiabilidade. O jogo realmente rendeu o suficiente para garantir juros, mas não como um jogo de
disco laser. Então, quando eles me pediram para portá-lo em seu novo hardware “System I”, eu
recusei, dizendo que tinha outra ideia que queria seguir. Estou feliz que eles me deixaram seguir essa
nova ideia porque essa ideia se tornou o Gauntlet. Road Runner foi convertido para o System I e, na
verdade, foi lançado.
O Gauntlet seguiu sua visão inicial de perto ou mudou muito no desenvolvimento?
Voltei recentemente e olhei para o

documento original de design do
jogo e fiquei surpreso com a
proximidade dos gráficos e da
jogabilidade com o produto final.
Claro, o que mudou durante o

desenvolvimento foi o hardware.
Criei um algoritmo que me permitiria
lidar com 1.000 objetos sem
sobrecarregar o processador ou
diminuir a taxa de quadros.
Perguntei a Pat McCarthy, o
engenheiro elétrico, se ele poderia
estender o hardware existente e Manopla
ele encontrou uma maneira de

fazer isso que me permitiria exibir todos os objetos que eu precisava. No final, foram emitidas cinco
patentes para o Gauntlet.
Devido ao tamanho do PCB e às restrições no tamanho do PCB para kits japoneses, decidimos
usar um PCB de quatro camadas para o Gauntlet. A Atari nunca havia colocado um quadro assim nem
usado traços tão pequenos quanto exigimos. Mas no final abrimos o caminho para todos os futuros
PCBs da Atari. Então, além do sucesso do jogo na indústria, Gauntlet também deu um salto gigante
na forma como fizemos engenharia e fabricação na Atari.
Para minha memória dos fliperamas em 1985, Gauntlet parecia ser um dos primeiros jogos de
ação a permitir que quatro jogadores jogassem ao mesmo tempo.
Este foi o primeiro jogo multijogador que permitia que os jogadores terminassem ou saíssem a
qualquer momento e a rolagem da tela fosse controlada por suas ações. Este não foi o primeiro jogo a
tem vários jogadores. O tanque 8 permitia oito jogadores em um monitor. Mas todos os jogadores
tiveram que começar ao mesmo tempo. A ideia de usar quatro jogadores foi projetada no Gauntlet
desde o início. Eu suspeito que foi devido ao fato de que eu só podia colocar quatro jogadores em
torno de um monitor vertical.
Acredito que Gauntlet foi o primeiro jogo que permitiu ao jogador comprar a hora que quisesse.
Eu não queria que os jogadores esperassem, como no Tanque 8, para que todos ganhassem moedas
ao mesmo tempo. A única solução era fazer com que os jogadores entrassem e saíssem à vontade.
A saúde sempre foi planejada desde o início. Acredito que essa ideia veio de Dungeons & Dragons,
que era muito popular na época. Então era lógico que o dinheiro apenas comprava mais saúde. Como
é desejo de todo designer de moedas que os jogadores coloquem o máximo de dinheiro que puderem
em seu jogo, não vi razão para não fazer com que os jogadores apenas aumentassem sua saúde com
cada moeda. Em retrospectiva, essa é uma ideia maravilhosa, porque perder a saúde em 2000 não
foi tão doloroso psicologicamente quanto inserir outra moeda.
Além disso, os jogadores não precisariam enfiar a mão no bolso para encontrar outra moeda para
inserir antes que seu personagem fosse perdido.
De onde veio a ideia de ter o jogo dizendo coisas como “Red Warrior precisa de comida, mal”
veio?
Eu não lembro. Desconfio que não foi ideia minha. Pode ter vindo do meu co-programador Bob
Flanagan ou de outra pessoa da Atari. De qualquer forma, tínhamos uma grande lista de frases que
queríamos que o “Dungeon Master” dissesse para provocar o jogador. Existem várias frases que
parecem ficar na mente de todos. Meu favorito é “o Mago (eu) parece estar comendo toda a comida
ultimamente”.
Muitos pensam que a Valquíria foi a mais poderosa das quatro personagens.
Na verdade, o Hulk ou o Mago poderiam ser usados para jogar para sempre. Isso foi demonstrado
pela primeira vez por jogadores no Japão jogando um jogo de um jogador. Isso foi corrigido mais
tarde, reduzindo a quantidade de comida nos níveis subsequentes se o jogador não tivesse perdido
saúde suficiente durante o último nível. A Valquíria foi projetada para ser o mais equilibrado dos
personagens, mas poder de tiro, velocidade de tiro e força provaram ser mais importantes do que outros atribut
É por isso que o Hulk e o Mago pareciam ser os mais poderosos. Claro, era divertido jogar com o Elfo
para muitos jogadores, porque você sempre conseguia mais comida ou tesouro do que os outros
jogadores.
Gauntlet II permitiu que quatro jogadores jogassem Valquírias, ou Elfos, ou qualquer

combinação que eles quisessem. Isso significava que as classes de personagens tinham que
ser mais iguais do que no primeiro jogo?
Não, na verdade fizemos muito pouco que me lembro para equalizar os personagens. Esse recurso
foi adicionado porque alguns jogadores queriam jogar com um personagem em particular e eu não
queria que eles esperassem até que a posição desejada fosse aberta. Então, em essência, eliminei
outro motivo para não entrar no jogo imediatamente.
O Xybots foi seu próximo projeto depois do Gauntlet II?

Bob Flanagan e eu começamos outro jogo, que eu rapidamente matei depois que a jogabilidade inicial
acabou sendo menos divertida do que eu esperava.
Xybots, como mencionei

anteriormente, começou como
uma ideia para fazer Castle
Wolfenstein. Comecei o jogo
como um Gauntlet III de tela
dividida para dois jogadores. No
meio do caminho, o marketing
disse que queria algo diferente do
que Gaunt deixou. Então eu mudei
os personagens e inimigos para
serem mais parecidos com o
Major Havoc. Ainda me arrependo
de ter mudado o tema e gostaria
de ter mantido meu conceito original de jogo.
Manopla II
Foi um grande desafio de engenharia criar o visual 3D do jogo?

Desenvolvi um algoritmo muito interessante para fazer a rotação 3D usando apenas carimbos de
8 por 8 pixels, como os chamamos. Eu não sei como explicar como isso funcionou sem obter
meus esboços originais para demonstrá-lo visualmente. Eu poderia ter feito o jogador girar de
outra forma que não em incrementos de 90 graus, mas tornou a jogabilidade mais simples permitir
apenas rotações de 90 graus.
Se bem me lembro, o jogo tinha controles interessantes e únicos.

O controlador era muito original
porque fornecia o joystick padrão
de oito direções, bem como um
botão na parte superior que podia
girar para a esquerda ou para a
direita para indicar uma rotação.
Esse controle tornou o jogo mais
difícil, que muitas vezes é o beijo
da morte no mercado de moedas.
Como em qualquer jogo 3D, os
jogadores não conseguiam
visualizar facilmente onde
estavam, apesar do mapa
disponível para eles. Além disso,
era possível levar um tiro nas
Xybots
costas, o que aumentava o fator de frustração.
Como você se envolveu trabalhando no Atari Tetris?

Joguei uma versão de Tetris e fiquei rapidamente viciado. Pedi ao nosso consultor jurídico, Dennis
Wood, para obter os direitos. Como eu tinha acabado de trabalhar na engenharia reversa do
Nintendo Family Computer, que logo se tornou o Nintendo Entertainment System nos EUA, decidi
criar uma versão no FC e NES e vendê-la através da Tengen, que foi
A editora de consumo da Atari. Dennis Wood obteve os direitos e mostramos Tetris primeiro na
Consumer Electronics Show de junho. Foi decidido melhorar o jogo, então refiz o visual e o lançamos
na CES seguinte em janeiro.
Devo salientar que eu estava trabalhando em outro jogo na época em que estava fazendo isso,
então não pude dedicar todo o meu tempo ao projeto Tetris . Foi esse fato que me fez precisar entregar
Tetristo Greg Rivera e Norm Avellar para o mercado de moedas. Consegui que meu código original
fosse executado no hardware de moedas antes de voltar ao meu projeto. É por isso que meu nome
aparece nos créditos da versão coin-op.
O que você gostou tanto no Tetris?

Era tão viciante que eu sabia que tínhamos que tê-lo. Em retrospectiva, eu poderia explicar por que
esse jogo funcionou tão bem, mas não tenho certeza de que isso provaria alguma coisa. Além disso, a
verdadeira questão é “Por que não pensei nessa ideia?”
Tengen Tetris foi seu único projeto de NES?

Eu tinha Centipede e Millipede rodando no FC antes do processo com a Atari Corp. resultar na decisão
de que eles possuíam os direitos de todos os nossos jogos antes da venda do Atari para Tramiel pela
Time Warner. Então tivemos que largar o trabalho que fiz. Então, meu trabalho anterior tornou o Tetris
muito fácil de fazer no NES. Eu também adicionei o recurso simultâneo de dois jogadores, o que tornou
este jogo melhor do que todas as outras versões. Mais tarde, você veria as versões do Tengen sendo
vendidas por US$ 150 ou mais.
Por que o Tengen Tetris acabou sendo retirado de circulação?

Você pode ler várias versões da história, mas suspeito que a linha de fundo é que o húngaro que tinha
os direitos fez um trabalho ruim ao cobrir todas as bases. Os russos aceitaram dinheiro da Nintendo
quando a Nintendo criou uma nova categoria de direitos. Apesar do fato de termos os direitos dos
sistemas de computador, a Nintendo alegou que seu Family Computer não era um computador, embora
eles vendessem o Basic, um teclado e outros serviços no Japão, como qualquer outro computador.
Certamente fiquei desapontado ao ver meu trabalho perdido.
Por que você quis trabalhar nas conversões do jogo de outra pessoa?
Tal como acontece com muitos dos meus jogos, esta foi a melhor ideia que tive na altura. No entanto,
neste caso, porque gostei muito, foi uma decisão fácil. Qual a melhor maneira de jogar o jogo que você
tanto gosta e garantir que ele saia do jeito que você gosta?
O que você trabalhou em seguida?

Acabei matando o jogo em que estava trabalhando durante o “Tetris Affair”. Acredito que Steel Talons
foi meu próximo projeto. Eu queria fazer um jogo de tiro/voo 3D Red Baron, mas o marketing achava
que os aviões da Primeira Guerra Mundial não eram legais o suficiente para os adolescentes, que
eram o principal público-alvo das moedas. O marketing queria jatos e eu achei uma ideia estúpida
porque quem quer ver pontos à distância atirando um no outro. Eu queria algo perto onde você pudesse
ver os detalhes do inimigo que você está atirando. Helicópteros eram a escolha lógica.
O Steel Talons não era um simulador de helicóptero bastante autêntico?
Os Garras de Aço tinham todos os controles normais de um helicóptero: um leme, um coletivo para controlar a
altura e um manche para virar. Claro que pilotar um helicóptero é difícil sem alguma assistência, então eu tinha
assistência de computador como helicópteros militares reais. Eu adicionei controle coletivo automático para que
o jogador mantivesse o vôo nivelado e qualquer pouso fosse suave. Também aumentaria a altura se o solo
estivesse inclinado na frente da altura.
O modo “real” apenas desativou este código de ajuda e aumentou a aceleração do jogador para compensar.
Esta foi uma característica única e a Atari recebeu uma patente sobre essa ideia.
O jogo tinha outro recurso interessante que nunca havia sido usado em um videogame antes. Instalamos
um batedor de pinball, muitas vezes usado para indicar um jogo grátis, sob o assento. Isso foi usado sempre
que o helicóptero do jogador foi atingido por fogo inimigo. Durante o primeiro teste de campo, a tensão para este
batedor foi maior do que deveria e os primeiros jogadores a usá-lo quase pularam de seus assentos quando ele
disparou. O barulho podia ser ouvido em toda a arcada.
O primeiro teste de campo também introduziu um novo problema que nunca tivemos antes. Saí para
verificar as coleções e tentei remover a caixa de moedas. Se você já viu Garras de Aço, verá que a caixa de
moedas está localizada em um ângulo estranho, exigindo que o operador levante a caixa com os braços
totalmente estendidos. Não é a posição mais fácil para levantar qualquer peso. Bem, de volta à história. Tentei
levantar a caixa, mas não consegui movê-la. Achei que estava travado. Logo descobri que a caixa estava tão
cheia e tão pesada que era quase impossível removê-la. Isso levou a estranhas instruções no manual pedindo
aos operadores para esvaziar a caixa de moedas a cada dois dias.
Em Steel Talons, você não trabalhou com o criador de Battlezone , Ed Rotberg?
Sim eu fiz. Ele estava na Atari durante os dias dourados de Battlezone, Asteroids, etc. Ele deixou a Atari para
fazer uma start-up chamada Sente, antes de retornar à Atari alguns anos depois. Ele tinha acabado de trabalhar
em um jogo do tipo Tube Chase usando o mesmo hardware 3D que Steel Talons usava. Este hardware era uma
versão de custo reduzido dos PCBs Hard Drive . Então foi natural para Ed trabalhar comigo neste projeto. Outra
característica interessante deste jogo foi o nevoeiro. A equipe original do Hard Drive não acreditou em mim
quando eu disse a eles que eu poderia adicionar neblina ao mundo. Ainda estou orgulhoso desse efeito e eles
ficaram surpresos que funcionou.
Como surgiu o projeto Space Lords ?
Eu queria continuar minhas ideias de jogo multijogador que comecei no Gauntlet e depois continuei em Xybots
e Steel Talons. Então eu escolhi um ambiente espacial 3D com até quatro gabinetes interligados. Cada gabinete
tinha dois monitores semelhantes ao Cyberball. Tentei manter o custo baixo usando o hardware “growth motion
object” da Atari, que era muito mais barato do que o hardware 3D usado no Steel Talons. Ele não podia desenhar
polígonos 3D, mas podia aumentar ou diminuir texturas planas.
Eu entendo que os Senhores do Espaço não se saíram muito bem financeiramente.
Os Senhores do Espaço tinham alguns padrões de ganhos estranhos. Em alguns fliperamas, ele ganhava mais
de US$ 1.000 por semana por dois gabinetes duplos. Mas em alguns pequenos fliperamas ele ganhava apenas
US$ 75 como um único gabinete. O resultado final é que tivemos dificuldade em vendê-lo por causa de seu custo
e o número limitado de locais em que poderia ser vendido. Foi definitivamente difícil fazer um jogo de moedas
usando o conceito de um jogador por monitor. Embora eu tenha adicionado um segundo jogador como artilheiro
pela metade do preço, muitos acharam que não era tão divertido quanto ser o piloto.
E Space Lords saiu bem na época em que os jogos de luta estavam decolando.
Os jogos de luta dificultavam a venda de Space Lords porque geralmente eram “kits”, que vendiam muito mais
barato do que um grande vertical dedicado. Street Fighter II teve ótimos ganhos e continuou a ganhar um bom
dinheiro por muito tempo.
Na verdade, desde o início dos anos 90, a maioria dos jogos de arcade está em um dos poucos gêneros
limitados. O que você acha de muitos dos jogos de arcade que saem hoje em dia?
Você está certo, o mercado de moedas parece estar todo dirigindo, lutando e atirando com um título esportivo
ocasional, como golfe. Há razões para isso. Dirigir tem apelo universal e costuma render por longos períodos. Por
isso, muitas vezes é o tema de jogo mais aceito.
Além disso, a maioria das unidades domésticas não possui volantes e pedais de acelerador ou dá a sensação de
estar dentro de um carro. Então você não pode ter essa experiência em casa. Os jogos de luta agora são difíceis
de vender nos fliperamas, e acredito que isso ocorra porque você pode obter a mesma experiência nos consoles
mais avançados. Na época, eles eram baratos e ganhavam muito dinheiro. Os jogos de tiro ainda são viáveis
porque as armas não são o controlador padrão em consoles ou PCs. Portanto, a única maneira de um jogador ter
essa experiência é no fliperama.
Portanto, a conclusão é que a maioria dos jogos de arcade hoje em dia não são exclusivos e se encaixam
em categorias muito limitadas. Eu não acho que os fliperamas estão completamente mortos, mas eles não são os
lugares de destino que costumavam ser.
Os Senhores do Espaço acabaram sendo seu último jogo de moedas?
Eu estava trabalhando em um jogo de tiro antes de sair da Atari. Esse jogo morreu, mas a arma foi usada mais
tarde na Área 51. Juntei - me à Electronic Arts que estava tentando iniciar seu próprio grupo de moedas. Minha
intenção era começar a fazer jogos de consumo. Mas a EA tinha alguns velhos amigos da Atari e eu decidi me
juntar a eles. Eu tinha feito um jogo de quebra-cabeça, que eu matei, e estava trabalhando em um jogo de tiro
quando eles decidiram sair do mercado de moedas. Então eu estava ainda mais determinado a entrar no negócio
de jogos de consumo.
Como você começou a fazer programação N64?
Eu estava procurando um projeto para trabalhar, então entrei em contato com muitas empresas para ver o que
elas tinham a oferecer. Eu estava planejando trabalhar com outro programador da EA, mas ele decidiu se juntar a
alguns amigos para iniciar uma nova empresa. A Atari queria que o Wayne Gretzky 3D Hockey fosse feito no N64
e eu estava ansioso para fazer algo nessa plataforma.
Isso ocorreu em parte porque o jogo prometia ser melhor que o PSX, mas também porque parecia que poderíamos
ser o primeiro título de hóquei disponível. Então me juntei a um grupo na Atari e começamos a trabalhar no Wayne
Gretzky 3D Hockey. Isso acabou sendo mais trabalhoso do que eu esperava, em parte devido ao estado dos
sistemas de desenvolvimento N64, mas também devido ao fato de que o coin-op não seria feito até pouco antes
do lançamento.
Como você mencionou, muito do apelo de jogar um jogo de arcade como San Francisco
cisco Rush parece estar sentado na cadeira, tendo a alavanca de câmbio, o volante, o
feedback de força e assim por diante. Como você tenta capturar isso para o N64, que não tem
nenhuma dessas sutilezas?
Você está certo. A casa não tem o
ambiente dos armários de
fliperama, mas podemos fazer
coisas nos jogos caseiros que
nunca poderíamos fazer no fliperama.
Podemos fornecer mais opções
para o jogador, mais pistas para
aprender e mais coisas para
descobrir.
Eu tento manter o jogo básico
igual, mas sempre tento agregar
valor ao produto.
Isso é uma coisa que deixei claro
quando entrei na Atari. A Atari
queria que eu fizesse apenas uma
porta reta. Isso sempre funcionou San Francisco Rush: Extreme Racing para Nintendo 64
para eles no passado. Não acreditei
que isso funcionaria e disse a eles que adicionaria “coisas” adicionais. Por exemplo, em Gretzky ,
adicionamos uma pista em tamanho real, uma nova IA, replay instantâneo, mais jogadores,
temporadas completas etc. Em geral, os jogos caseiros exigem muito mais trabalho. Também
acredito que podemos fazer jogos diferentes para o mercado doméstico que nunca poderíamos fazer
no arcade. Então, para mim, isso abre novas possibilidades.
As peças de arcade devem ser fáceis de aprender com regras que sejam óbvias e forneçam
entretenimento que dure noventa segundos. O mercado doméstico não está vinculado a essas regras.
Em vez disso, você deve fornecer mais vida ao seu produto. Muitas vezes, isso significa que o
jogador leva mais tempo para “terminar” o jogo. Mesmo quando o jogador terminou, deve haver
razões pelas quais ele vai querer voltar para fazer tudo de novo.
Você gosta dos desafios de engenharia de fazer conversões em casa?

Na verdade, gosto do “estilo antigo” de tentar fazer com que tudo se encaixe. Também gosto de
adicionar truques para obter a taxa de quadros o mais alta possível. Foi muito interessante colocar
todo o SF Rush em 8 MB, que inclui cerca de 3 MB de áudio e todos os gráficos.
Como surgiu o projeto Dr. Muto ?

Não tenho certeza de todos os detalhes, mas acredito que o conceito básico veio do nosso produtor,
Scot Amos. Fiquei muito intrigado com a ideia de jogar como um cientista maluco, então achei que
a ideia do jogo era boa.
Na verdade, há uma história interessante que acompanha isso. Quando propusemos o jogo ao
comitê de gestão, a principal reclamação deles era que ninguém gostaria de interpretar um cientista
maluco. Para provar seu ponto de vista, eles queriam fazer uma pesquisa de marketing para ver se
um cientista maluco era uma boa escolha. Claro, a equipe de engenharia pensou que isso
foi perda de tempo. Imagine se eles

perguntasse a alguém se um ouriço
roxo ou um encanador italiano seria
um bom personagem principal.
Claro, a resposta veio de que o
cientista maluco não era uma boa
ideia porque eles não tinham
nenhum ponto de referência sobre
como ele seria usado. Nesse meio
tempo, fizemos uma pequena
demonstração com algumas salas
para mostrar nosso mecanismo de
renderização, aparência básica,
morphing e um pouco de humor
básico. Quando a gerência viu isso,
eles sabiam exatamente o que Dr. Muto
tínhamos em mente e tivemos uma
decisão unânime de seguir em frente com o projeto.
Eu sempre pensei que o Dr. Muto era bastante único para um jogo de plataforma, pois seu
personagem principal era mais velho e não particularmente fofo ou peludo. De onde surgiu o
desejo de ter um personagem tão diferente?
Os conceitos de design de personagens vieram de nosso artista principal, Steve Caterson, a quem
chamamos de Scat. Nós definitivamente queríamos fazer algo diferente do que todo mundo estava fazendo.
Ter um cientista louco fofo e confuso simplesmente não parecia certo. Além disso, queríamos parecer
diferentes de todos os outros.
Dr. Muto foi o primeiro jogo que você desenvolveu para o mercado doméstico que não era uma
adaptação de um jogo existente. Como o desenvolvimento foi diferente de suas experiências
anteriores?
Este jogo era tão diferente de qualquer outro jogo que eu tentei fazer. O mercado, claro, mudou,
exigindo melhor renderização, efeitos especiais e filmes. Mas o ponto mais importante era que este era
um jogo de plataforma e os padrões para este tipo de jogo são realmente muito altos. Precisávamos
corresponder a qualquer coisa que estivesse atualmente no mercado ou planejada para estar no
mercado.
O outro ponto mais significativo é o grande número de pessoas, o custo e o tempo necessário
para fazer este projeto. O Dr. Muto foi de longe o maior projeto do qual já participei. Havia mais de vinte
e cinco pessoas na equipe, mais um grupo de ferramentas e pessoal de produção de vídeo. O design
do jogo por si só era ordens de magnitude maior do que qualquer outra coisa com a qual já estive
associado.
Para o Dr. Muto você era apenas o programador líder e não o designer líder, correto?
O designer-chefe, Mark Simon, entrou mais tarde no projeto, por volta de abril de 2002, acredito. Este
foi seu primeiro projeto em grande escala onde ele foi designer-chefe, e acho que ele
estava um pouco acima de sua cabeça neste. Eu também não teria feito uma boa escolha como designer principal
porque esse tipo de jogo era um território desconhecido para mim. Além disso, eu gosto de programar e não poderia
fazer nada a não ser desenhar como designer. Mesmo assim, eu teria que ter vários outros me ajudando no layout
dos níveis, afinação, etc. Mas eu nem estava liderando todos os programadores porque havia um grupo de ferramentas
fazendo o mecanismo de renderização e todo o trabalho para garantir que o jogo rodasse no Xbox e no GameCube
também. Scot Amos, nosso produtor, atuou como líder do projeto. Ele era muito bom em motivar as pessoas e ainda
melhor em impulsionar nosso produto com entusiasmo - muito melhor do que eu poderia fazer.
Ele fez um trabalho maravilhoso.

Mas havia coisas que eu teria feito
diferente. Eu certamente teria empurrado
nossa ideia original para um chute lateral.
Ela se chamava Eyesore. Dr. Muto
Ela deveria adicionar sex appeal e humor para complementar nosso desastrado cientista maluco.
Por que você acha que o Dr. Muto não se saiu melhor comercialmente?
Eu gostaria de ter uma boa resposta para isso. Receio que simplesmente não obtivemos massa crítica no mercado.
Muitos jogos de plataforma foram lançados no Natal de 2002 e nós enfrentamos alguns produtos muito bem feitos e
bem anunciados. A indústria afirma que os jogos de plataforma não se saíram tão bem em 2002 quanto nos anos
anteriores. No entanto, acredito que o motivo tenha a ver com o jogo Grand Theft Auto. Porque este jogo teve vendas
tão grandes, naturalmente tirou as vendas de outros jogos. Eu afirmo que este jogo é realmente um jogo de plataforma,
atirador e um jogo de direção, tudo em um. Se você colocar este jogo na categoria de plataforma, verá que os jogos
de plataforma realmente se saíram muito bem.
No que você está trabalhando nesses dias?
Estou fazendo jogos de celular para uma start-up chamada GenPlay Games. Há vários de nós da Midway Games
West (originalmente Atari Games Corp.) trabalhando juntos agora. Acabei de terminar meu segundo jogo, que será
lançado em breve na Verizon e Sprint.
Eu gosto da indústria de jogos para celular, pois os jogos são menores e mais parecidos com arcade. Com isso
quero dizer que o público está procurando uma experiência de jogo mais casual. Também gosto do fato de poder
voltar a fazer programação e design de jogos sem gerenciar outros programadores. É claro que esta indústria mudará
à medida que os telefones celulares se tornarem mais poderosos. Os chips 3D já estão a caminho dos telefones
celulares. Não demorará muito para vermos os mais recentes jogos de console rodando em telefones celulares. A
comercialização de jogos já está chegando ao estágio em que licenças ou algum reconhecimento de nome são
necessários para chamar a atenção das operadoras e jogadores.
Você está envolvido no desenvolvimento de jogos há quase vinte e cinco anos.

Como você explica sua longevidade?
A longevidade vem de fazer o que eu gosto. Trabalhar em jogos requer algo que muitas pessoas não
têm. Muitos não conseguem suportar a pressão constante para se apresentar, as longas horas e o
pensamento de que o “bebê” em que estão trabalhando pode ser morto após dezoito meses de trabalho
duro. Outros são programadores ou artistas que encontraram coisas mais interessantes para fazer.
Devo admitir que muitas vezes pensei em fazer outra coisa. Eu simplesmente não encontrei nada
que eu queira fazer mais do que o que estou fazendo agora. Isso pode mudar ou posso me ver jogando
até me aposentar.
Como você se sentiu com o fechamento dos antigos escritórios da Atari?

Isso é como me perguntar como me sinto com a morte de um velho e querido amigo. Eu estava muito
triste. Fomos o único projeto na Midway a chegar no prazo, mas no final fomos todos dispensados. Um
desperdício de tecnologia e as pessoas realmente ótimas que tínhamos trabalhando juntos.
Na memória recente, Asteroids, Centipede e Gauntlet foram todos refeitos. Como você se sente
sobre os remakes?
Muitos estão fadados ao fracasso,
assim como a maioria das ideias de
jogos. Gaunt let foi um bom caso de
remake que funcionou muito bem.
Arkanoid foi um remake de Breakout
que funcionou muito bem. Então
remakes podem funcionar, mas é
difícil.
O verdadeiro fracasso vem da
comparação da jogabilidade com o
original. Por exemplo, fazer uma
versão 3D do Centi pede torna a
jogabilidade mais difícil porque a
informação 3D não é tão fácil para
o jogador processar. Lembre-se, os
Lendas da Manopla
designers tiveram vinte anos para
jogar esses jogos antigos e criar uma nova reviravolta para criar um novo grande jogo. O fato de ainda
não terem feito isso parece indicar que é improvável. Não impossível, mas improvável.
Qual dos seus jogos você gostaria de refazer?

Se eu tivesse a resposta para isso, e se eu acreditasse que era a melhor ideia que eu tinha, eu estaria
trabalhando nisso. Além disso, se eu te contasse, outra pessoa estaria fazendo isso agora, não estaria?
Em outras palavras, não tenho ideia de como pegar alguns clássicos antigos e torná-los novos e
interessantes no mercado atual.
Como a indústria de desenvolvimento de jogos mudou ao longo dos anos?
A indústria de jogos definitivamente mudou, mas ainda é uma indústria de videogames. Os videogames não
eram uma indústria de US$ 7 bilhões quando comecei. Com os grandes negócios vem muito dinheiro e isso
invariavelmente traz consigo o controle sobre como ele é gasto. Portanto, há definitivamente mais política no
nível corporativo. A interferência da gestão vem da necessidade de controlar os custos, mas o verdadeiro
motivo, acredito, se deve à evolução dos próprios jogos. Com isso quero dizer, poderíamos projetar e
programar um jogo em três meses nos primeiros anos. Em três meses você não gastou dinheiro suficiente
para eles interferirem. Os jogos evoluíram ao ponto em que você não pode fazer um jogo com apenas uma
pessoa em um período de tempo realista. São necessários vários programadores, vários artistas, um
especialista em áudio e alguém para gerenciar o projeto por um período de doze a vinte e quatro meses. O
mercado de consoles também mudou. Você não precisava gastar US $ 1 bilhão para lançar um novo console
nos primeiros dias, mas custa muito agora. Assim, com a evolução, surgem períodos mais longos para
desenvolvimento e custos mais altos para produzir um produto.
Com os custos mais altos vem mais dinheiro e, portanto, mais controle (ou seja, interferência) sobre como
ele é gasto.
Ao trabalhar em jogos caseiros, o que você mudou na forma como projeta seus jogos em relação ao
seu trabalho no modo coin-op?
Isso depende do tipo de jogo. Por exemplo, não basta ter um jogo de corrida com uma dúzia de carros e um
número semelhante de pistas. Agora esperaríamos ver um grande número de carros licenciados, talvez
motoristas ou pistas licenciados, ou melhor ainda, uma licença de filme. Claro que esperamos gráficos e
efeitos especiais ainda melhores do que antes. Mas tirando esse ponto, a ideia básica é adicionar jogabilidade
suficiente para que a compra de um jogo de console valha a pena. Lembre-se, os jogadores podem alugar o
jogo na locadora. Se a jogabilidade for muito curta ou não atender às suas expectativas ou não merecer
replays, você pode ter certeza de que o jogo não venderá bem.
Agora que estou no assunto, fiquei realmente desapontado ao ver que quase noventa por cento dos
cem melhores jogos são licenças ou sequências. É a preocupação mais esmagadora para qualquer novo
jogo. É triste pensar que o design de jogos não pode prosseguir sem alguma ligação com um filme ou algum
outro título facilmente reconhecível.
Você sente falta de fazer designs de jogos de arcade mais simples e clássicos?
Sim, sinto falta dos designs de jogos antigos, e é por isso que estou feliz por estar trabalhando em jogos
para celular. Os mundos 2D são muito mais fáceis para o jogador entender. Também gosto da ideia de criar
um jogo com um conjunto fixo de regras e aleatoriedade suficiente para que o jogador possa criar diferentes
estilos de jogo e suas próprias estratégias.
Não tenho certeza se conseguiria vender um jogo com um “design antigo” para o mercado de consoles.
Os jogadores têm expectativas diferentes agora. Eles esperariam designs 3D ou jogos na Internet ou texturas
de alta resolução e filmes pré-renderizados ou personagens altamente desenvolvidos... pouco de jogo zzz.”
Para constar, muitos dos designs antigos foram baseados em ideias de jogos anteriores. Lembre-se,
Asteroids veio de um jogo anterior com um pouco de Space War , embora muitos pensassem nisso como
um design original.
Para a maioria de seus projetos originais, você atuou como designer e programador principal.
Você gosta de trabalhar em ambas as capacidades?
Trabalhar como designer de jogos e programador é uma boa ideia se você conseguir. Há muito poucas
pessoas que são boas em ambos. Portanto, não é uma estratégia que eu recomendo hoje. Por exemplo,
para os jogos complexos de vários personagens e níveis de hoje, não sou um designer tão bom quanto
seria em outros estilos de jogos. Então, eu estaria disposto a ceder esse papel para outra pessoa.
O programador tem que implementar o design e se as ideias do designer não forem bem
comunicadas, então o jogo é programado de forma diferente do que o designer esperava. Eu acredito
que muitas vezes é o programador que pode fazer ou quebrar a “sensação” de um jogo.
Parece que você perdeu um ponto. Também fui líder de projeto em muitos projetos.
Este é um papel em que sou muito bom, mas não recebo nenhum reconhecimento. Meus projetos estão
quase sempre no prazo e, se houver problemas, a gerência geralmente é informada com bastante
antecedência. Ninguém fora da Atari provavelmente está ciente disso. Infelizmente, não gosto dessa
função, então tento passar o mínimo de tempo possível gerenciando um projeto.
Você até atuou como artista em seus primeiros jogos, não foi?
No início foi uma boa ideia.
Não há razão para treinar um artista
para criar uma pedra em papel
quadriculado e me fornecer as
coordenadas para que eu possa
inseri-las no meu jogo. Quando
havia tão pouco em termos de
gráficos ou áudio necessários, não
faz sentido ter outra pessoa
especializada fazendo isso. Hoje, é
uma questão totalmente diferente.
Hoje é absolutamente necessário.
Asteróides
Você sente que algum de seus jogos é subestimado?

Como designer de jogos, não, não sinto que tenha nenhum jogo que tenha sido subestimado. Se o
design do jogo funcionar, então a jogabilidade é divertida e o jogo vende. Como programador, sim,
provavelmente existem algumas ideias de jogos, algoritmos ou velocidade de programação que são
subestimados. Muitos truques de programação eu faço para diversão pessoal, então não estou
procurando por reconhecimento externo.
Nos primeiros dias, você estava bastante limitado pela tecnologia disponível para você.
As limitações da tecnologia estimularam a criatividade?
Sim, eu teria que concordar. Foram muitas as vezes que passei pensando em como fazer algo em um
determinado hardware e isso virou um jogo. Xybots foi certamente um dos
aqueles jogos. No Gauntlet , criamos um novo hardware para tornar a jogabilidade possível.
Você acha que a tecnologia de jogos está se estabilizando ao ponto em que os jogos futuros
serão menos sobre renderização de ponta e mais sobre novas ideias de jogos?
Como mencionei anteriormente, as forças de marketing conduzirão os jogos mais do que a

tecnologia do ponto de vista de obter financiamento para começar. Como os jogos ficaram muito
mais caros e demoram tanto, suspeito que a tecnologia e as novas ideias de jogos ficarão em
segundo plano. Isso não quer dizer que não haverá ainda mais melhoria na qualidade do vídeo e
do áudio. Posso garantir que a tecnologia será usada para ajudar a vender o jogo no final e será
um fator para os jogadores. Também posso garantir que novas ideias serão testadas, mas duvido
que qualquer grande estúdio deposite as esperanças na tecnologia ou na ideia do jogo por si só.
De certa forma, concordo que a tecnologia de jogos está se nivelando, por assim dizer. Com
isso quero dizer que se o número de polígonos que podem ser desenhados aumentar em dez, eu
não esperaria ver muita melhoria na qualidade do vídeo. Sim, você pode adicionar mapeamento de
colisão ou shaders por pixel, mas a TV básica tem apenas alguns pixels e cobrir a tela com mais
de um polígono por pixel não melhorará a qualidade do vídeo final.
Ao trabalhar com um design de jogo original, por onde você começa?

Primeiro, tento criar o jogo e, em seguida, observo todos os aspectos do jogo. Do ponto de vista
do mercado: vai vender, é o momento certo, requisitos de licenciamento, concorrência, etc. Do
ponto de vista do jogador: o que torna este jogo divertido e o que é único que o torna interessante.
Do lado do desenvolvimento: o que será necessário para fazer este jogo em termos de pessoas e
equipamentos e será divertido fazê-lo. As próprias ideias vêm de quase todas as fontes possíveis.
Eu mencionei como alguns vêm de jogos anteriores, ideias de brainstorming, desafios técnicos e
sugestões de outras pessoas.
Então, depois de ter sua ideia, você começa a codificar imediatamente ou passa muito
tempo pensando nisso antes do tempo?
Com os grandes orçamentos e grandes equipes nos dias de hoje, é necessário fazer um documento
de design de jogo e um documento de design técnico antes que o jogo vá muito longe no
desenvolvimento. No entanto, tento começar a trabalhar em algum aspecto crítico enquanto os
documentos de projeto estão sendo elaborados. Eu acredito que é extremamente importante
trabalhar no aspecto do jogo que vai fazer ou quebrar o conceito. Os filmes front-end, enredo, telas
front-end e back-end podem esperar até que a jogabilidade seja comprovada. Às vezes, essa fase
de prototipagem é rápida, mas muitas vezes pode levar vários meses.
Depois de provar o conceito de jogabilidade em um protótipo, como o resto do

desenvolvimento progride?
Os jogos passam por quatro fases para mim. A alta no início de um projeto de fazer algo novo e a
sensação de que este será realmente um grande jogo. O projeto muitas vezes dá saltos gigantescos
em curtos períodos. A parte do meio do projeto é mundana. O conceito foi comprovado, mas muitas
vezes há muito trabalho a fazer e o jogo não
parecem mudar muito por todo o seu esforço. A terceira fase é muitas vezes cheia de pânico e
estresse. Esta é a parte antes do lançamento, quando você quer apenas que o projeto termine. A
quarta fase é de satisfação após o lançamento do jogo.
Com os projetos longos atuais, muitas vezes sinto que estou obtendo retornos decrescentes
pelo meu esforço, então estou feliz por ter o jogo terminado. No meu caso, quase tudo que eu planejei
para o meu jogo foi implementado, então estou feliz em dizer que está feito. Exceto por encontrar
aqueles irritantes bugs de última hora…
Então, depois que o protótipo está funcional, você não gosta muito do processo de
desenvolvimento?
Sim, eu diria que a maior parte do jogo é feita depois que o conceito principal do jogo foi comprovado.
No entanto, muitas vezes há partes que provam ser recompensadoras durante o longo desenvolvimento
antes que o jogo termine. Mas depois de fazer tantos jogos nos últimos trinta anos, trabalhar, digamos,
na interface do usuário não me deixa muito animado.
Não, eu gostaria de fazer um protótipo e deixar para outra pessoa terminar. Mas sinto que ainda
tenho a visão para a jogabilidade e não acredito que outra pessoa ou grupo continuaria a jogabilidade
como eu imagino. Então, no final, eu sentiria que o jogo não era o que eu esperava, não era mais
meu. Sempre tive a sensação de que, se tivesse trabalhado até o fim, o jogo seria melhor do que
qualquer outra pessoa poderia ter feito. Acho que me sentiria diferente se não tivesse tido o sucesso
que tive.
Você acha que grupos focais ou testes de jogo realizam para jogos caseiros o que os testes
de campo realizam para operações com moedas?
Os testes de campo serviram como um meio para garantir que o software e o hardware estivessem
livres de bugs, mas esse era um benefício secundário - essa não era a verdadeira razão pela qual
isso foi feito. Testes de campo para jogos com moedas dão uma boa ideia de como o jogo se compara
a outros jogos atuais. É fácil prever a partir dos ganhos e do preço de venda o quão bem ele vai
vender. Grupos de foco raramente deram qualquer indicação clara de quão bem o jogo venderia tanto
no mercado de moedas quanto no mercado consumidor.
Para os jogos de consumo,
não acredito que exista um
equivalente ou
direto.
grupoO playtesting
de foco dá
uma ideia de quão bem o jogo será
percebido, mas no caso do Dr.
Muto as classificações não se
traduziram nas vendas esperadas.
Acredito que a razão é que quando
um jogador vai a um fliperama ele
pode esperar ver apenas alguns
jogos novos. Portanto, é provável
que seu jogo seja visto. No mercado
consumidor atual existem inúmeros
títulos e é
Dr. Muto
não é fácil encontrar os novos jogos. Em muitos casos, sua loja de jogos local pode nem mesmo vender
o jogo porque reduziu o número de jogos que colocarão nas prateleiras. Ainda mais importante, os
jogos de moedas têm uma amostra de jogabilidade, que os jogadores podem vislumbrar para ver se
lhes interessa. O melhor que você vai conseguir na loja do consumidor são algumas capturas de tela
na caixa. Eu sei que isso não é realmente preciso porque esperamos ver o tempo da TV para jogos de
consumidor, mas você precisa ser um dos melhores jogos para garantir esse tipo de dinheiro de
marketing e nem todos os jogos o fazem.
Para o Dr. Muto este ponto era bastante discutível por outra razão. A data de término foi
selecionada para a equipe. Fomos informados de quando seria lançado, então cortamos muitos dos
recursos e jogabilidade que gostaríamos de ver. Mais importante, os testes com jogadores não tinham
utilidade porque se eles sugerissem uma mudança, não haveria tempo para adicioná-la ou mudar o jogo.
Que papel você acha que a IA desempenha nos jogos?

Nos jogos antigos, a IA não tinha envolvimento. Muitas vezes, o inimigo seguiria um conjunto fixo de
regras com alguma aleatoriedade, se necessário. Hoje em dia é uma questão totalmente diferente. Está
se tornando muito importante para os jogos modernos. Algumas pessoas recomendaram que, quando
apropriado, cada projeto tenha uma pessoa especialmente treinada dedicada a fazer a IA do jogo. E
para alguns jogos, eu concordaria.
Por que você acha que os jogos exigem IA mais sofisticada agora?
Acredito que o tema e a jogabilidade da maioria dos novos jogos exigem mais IA. Os jogos de simulação,
os atiradores, etc., todos tentam dar a verdadeira sensação de vida inteligente competindo contra você.
Se os jogos não tentam imitar a vida real, então um conjunto de regras pode funcionar bem.
Quão importante você acha que é tornar a IA em um jogo “real”? Ou seja, fornecer à IA apenas
as informações que o jogador teria na posição de agente da IA?
Não é necessário, mas pode levar a uma IA inimiga mais crível, então eu recomendaria em alguns
casos. Por exemplo, em Steel Talons, os artilheiros inimigos não se virariam ou atirariam até que
pudessem vê-lo visualmente. Se houvesse uma colina no caminho ou você estivesse abraçando o chão
no final de seu alcance, eles não o viam. Este é um caso em que foi necessário.
Ultimamente, muita atenção está sendo dada à combinação de jogos e histórias. Muitos jogos
de arcade, talvez como parte de sua natureza, quase não têm história. O que você acha de contar
uma história dentro de um jogo?
Eu nunca fui alto em histórias. Eu sinto que é absolutamente necessário que o jogador entenda o tema:
cenário, ambiente e objetivos. Às vezes, as histórias ajudam a tornar os objetivos mais fáceis de
entender. Alguns jogos são feitos como um filme, então uma história faz muito sentido: o jogador sente
que é o personagem principal que está controlando. Em um jogo de moedas, uma história não faz
sentido a menos que seja mostrada no modo de atração. Não queremos que o jogador perca seu tempo
assistindo a algo quando poderia estar jogando ou colocando mais dinheiro.
Você mencionou antes que queria especificamente fazer jogos para o mercado doméstico.
Por que foi isso?
Eu queria fazer jogos caseiros em vez de jogos com moedas porque vi mais oportunidades de
fazer algo novo no mercado doméstico.
Você não vê nenhum futuro para os jogos de arcade com moedas?

Suspeito que os jogos de moedas
nos fliperamas tenderão a passeios
de simulação mais baratos
(movimento físico ou ambiente
abrangente), assim como você vê
agora. Eles fornecem algo que
você não pode obter em casa e
são mais baratos que os passeios
na Disneylândia. Acredito que o
mercado de fliperama já existe. O
mercado de rua com moedas
sempre precisará ser barato.
Então eu vejo uma plataforma de
consumidor em uma caixa de
moedas ou PCBs baratos com
A versão arcade do San Francisco Rush 2049
jogos simples que não exigem
longos tempos de desenvolvimento.
O mercado consumidor já domina a indústria de moedas. Não tenho os números, mas fica
claro para mim olhando os números de vendas dos jogos de sucesso e os dólares que eles
representam. É triste ver as mudanças na indústria de moedas. Estou muito feliz por ter feito parte
da indústria. Eu sinto que definitivamente estava no lugar certo na hora certa.
Ed Logg Gameografia
Super Breakout, 1978
Vídeo Pinball, 1979
Asteróides, 1979
Otelo (para Atari 2600), 1979
Futebol (conversão de quatro jogadores), 1979
Centopeia, 1981
Milípede, 1982
Manopla, 1985
Manopla II, 1986
Xybots, 1987
Tetris (conversão para NES), 1988
Garras de Aço, 1991
Senhores do Espaço, 1992
Wayne Gretzky 3D Hockey (conversão para N64), 1996
San Francisco Rush (conversão para N64), 1997
San Francisco Rush 2 (conversão para N64), 1999
San Francisco Rush 2049 (conversão para N64
e Dreamcast), 2000 Dr.
Muto, 2002 GenPlay Stack'um,
2004 GenPlay Pool Pro Online,
2004
Capítulo 7
Os Elementos de
Jogabilidade
“Acabamos com um jogo que eu não sabia como ganhar. Eu não sabia quais
eram as melhores estratégias ou táticas, apesar de ter desenhado todos os
sistemas do jogo. Isso é o que faz um bom jogo de estratégia.”
— Julian Gollop, falando sobre seu jogo X-Com: UFO Defense
Claro, não há uma resposta definitiva para essa pergunta. Mesmo assim, como um
Quais são os elementos
designer de de design
jogos, do jogo que
espera-se que você
compõem
saibaum jogo realmente
intuitivamente bom? De
a resposta.
Compreender o design de jogos, como acontece com qualquer forma de arte, é muito mais um
entendimento internalizado, uma reação “instintiva”, um “sentimento” que você pode ter. Pode ser
que você não consiga formar essa resposta em palavras, mas você precisará entender quais
aspectos de um jogo são fortes e quais são fracos, e como o último pode ser substituído por mais do
anterior. A experiência desempenha um papel importante na compreensão do que torna um jogo
divertido, tanto como designer de jogos quanto como jogador de jogos.
Ao longo de meus anos jogando e criando jogos, encontrei minhas próprias respostas sobre o
que torna um jogo ótimo e, neste capítulo, discuto algumas dessas qualidades. Alguns desses
tópicos podem parecer bastante distintos um do outro, mas, na minha opinião, todos desempenham
um papel crucial na criação de um bom jogo. Certamente não posso esperar listar todo o conhecimento que
115
116 Capítulo 7: Os Elementos da Jogabilidade
já que, como mencionei, muito do meu entendimento é mais parecido com um “sexto sentido” do que
qualquer coisa que eu poderia esperar escrever. Mas as ideias contidas neste capítulo devem
fornecer uma base sólida.
Soluções únicas
Para mim, um dos momentos mais emocionantes de ser um designer de jogos é quando ouço alguém
falando sobre jogar um dos meus jogos, e eles explicam uma tática de sucesso para uma determinada
situação que eu nunca havia considerado. Isso pode ser uma solução para um quebra-cabeça
específico, uma nova estratégia para incapacitar inimigos desafiadores ou um método para manobrar
um desfiladeiro perigoso. Eu vejo os jogos que desenvolvo como criando situações nas quais os
jogadores podem utilizar sua própria criatividade para ter sucesso. Quando a criatividade dos
jogadores pode levá-los a soluções que eu não tinha imaginado, isso me mostra que os jogadores e
eu estamos compartilhando a criação de sua experiência, em vez de eu ditar tudo. E quando os
jogadores e eu compartilhamos a autoria, sinto que meu jogo está fazendo seu trabalho.
Sistemas Antecipativos versus Sistemas Complexos
Bons designers tentarão adivinhar o que os jogadores tentarão fazer e garantir que seu jogo
responda bem a essas ações. Por exemplo, pegue um RPG que apresenta um quebra-cabeça que
envolve colocar pesos em uma série de placas de pressão. (Tendo colocado tal quebra-cabeça em
um jogo meu, gostaria de implorar aos designers de jogos que sejam um pouco mais criativos do que
isso, já que placas de pressão são certamente um dos dispositivos de quebra-cabeça mais exagerados.
Mas eu discordo.) Suponha que o projetista deixe uma pilha conspícua de rochas algumas salas
acima do quebra-cabeça da placa de pressão. A solução óbvia para o quebra-cabeça é usar essas
pedras nas placas de pressão para alcançar os resultados desejados. Mas e se os jogadores
tentarem soltar suas várias armas nas placas? Esta é uma solução perfeitamente válida que deve
funcionar igualmente bem, desde que os jogadores tenham armas com os pesos apropriados.
E se os jogadores tiverem o feitiço Summon Minor Threat, que lhes permite invocar uma variedade
de pequenos monstros diferentes? Se os jogadores convocarem esses monstros para as placas de
pressão, eles também podem fazer o truque.
Agora o designer, tendo pensado no quebra-cabeça completamente, pode fazer com que o
programador adicione um código onde o jogo reage corretamente se pedras, armas ou monstros
estiverem nas placas. Esta é a escola antecipatória do design de jogos, onde o designer pensa no
que os jogadores podem fazer e conecta o jogo para funcionar bem com essas ações. Concordo que
esta tática é certamente melhor do que permitir apenas uma solução. No entanto, e se os jogadores
pensarem em algum outro peso que possam colocar nas placas de pressão? E se os jogadores
usarem seu feitiço Berkshire Blizzard nas placas de pressão, fazendo com que neve caia sobre elas?
Neve suficiente poderia se acumular nas placas para ter um peso significativo.
No entanto, se o jogo foi programado apenas para pedras, armas ou monstros, o jogo não reagirá
adequadamente. Os jogadores terão pensado em uma solução perfeitamente razoável e o jogo não
a reconhecerá.
Em vez de hardwiring, no entanto, e se o designer fizesse com que o programador criasse um
sistema em que cada objeto do jogo tivesse um peso associado a ele? Isso inclui rochas, armas,
monstros, efeitos climáticos, sangue e quaisquer outros objetos dinâmicos encontrados no mundo do
jogo. Se o programador fizesse as placas de pressão simplesmente medirem o peso de todos os
objetos em cima delas, independentemente de suas
Capítulo 7: Os Elementos da Jogabilidade 117
type, essa solução global funcionaria para todos os objetos. Se cada objeto fosse configurado com
um peso razoável, não importaria quais objetos os jogadores tentassem colocar nas placas de
pressão, pois todos funcionariam automaticamente.
Este último método é menos uma técnica antecipatória de design de jogos; é mais holístico e
baseado em sistemas em sua abordagem. Ele se baseia mais na criação de sistemas confiáveis e
consistentes com os quais seu jogo funcionará. Com esses sistemas instalados, o jogo se torna
mais uma simulação e menos um quebra-cabeça codificado. Um jogo não precisa ser um simulador
de voo ou um jogo no estilo SimCity para incluir algum nível de simulação; na verdade, quase
todos os jogos incluem algum grau de simulação, por mais grosseiro que seja. Quanto mais os
designers reconhecem o valor da simulação sobre a codificação rígida e enfatizam esses sistemas
complexos e interconectados em seus jogos, mais profundos eles se tornam. Em um jogo com
uma abordagem mais baseada em simulação, contendo um quebra-cabeça como a placa de
pressão descrita acima, o designer e o programador apresentam uma série de condições de
sucesso para esse quebra-cabeça. Em vez de “o quebra-cabeça é resolvido se os jogadores
usarem pedras, armas ou monstros para compensar as placas”, a regra é “o quebra-cabeça é
resolvido quando as placas são compensadas pelo peso correto sendo colocado em cima delas”.
Certamente o exemplo desse quebra-cabeça é simples, mas as mesmas técnicas podem ser
aplicadas a sistemas muito mais sofisticados e interessantes que geram uma ampla variedade de
estilos de jogo bem-sucedidos.
Emergência
Os jogos Civilization são
alguns dos melhores
exemplos de jogabilidade
complexa emergindo de
vários sistemas consistentes
executados em paralelo.
Retratado aqui: Civilização
II.
É o desenvolvimento de vários sistemas robustos e lógicos que levam a soluções únicas para os
jogadores para as situações do jogo. Pode-se descrever essas soluções como “emergentes” do
design de sistemas do jogo, um chavão popular nos círculos de design de jogos. Estabelecer um
universo de jogo que funcione de acordo com regras lógicas que os jogadores possam facilmente
entender e usar a seu favor permite que esses mesmos jogadores encontrem suas próprias
soluções para os problemas que o jogo apresenta. Nada é mais recompensador para os jogadores
do que inventar algum método obtuso e não óbvio para resolver um
quebra-cabeça ou uma situação de combate e, em seguida, fazê-lo realmente funcionar. Quanto

mais complexos os sistemas funcionam corretamente e simultaneamente uns com os outros, mais
interessantes e variadas se tornam as soluções para as situações. Considere o jogo Civilization, com
seus inúmeros sistemas rodando em paralelo. Esses sistemas trabalham juntos para criar algumas
das jogabilidades mais atraentes já gravadas em disco.
Ao mesmo tempo, muitos designers temem que os jogadores descubram estratégias emergentes
que podem usar como exploits: táticas que permitirão que os jogadores terminem um jogo com muita
facilidade, pulando o ping muito da diversão. Com seu projeto de sistemas complexos, Civilization
era o principal candidato para exploração de jogadores. No jogo original, os jogadores eram capazes
de explorar uma estratégia de corrida em que nunca construiriam cidades de tamanho maior que
dois, permanecendo na forma mais primitiva de governo, rapidamente varrendo o mundo e vencendo
o jogo prematuramente. Essa estratégia foi tão eficaz que foi claramente a melhor estratégia a ser
usada e permitiu que os jogadores perdessem 90% do jogo. Sid Meier acabou corrigindo o jogo para
aumentar a infelicidade dos cidadãos quando essa estratégia foi usada, consertando o exploit. Nesse
caso, a tática emergente revelou um atalho no jogo que precisava ser consertado.
Outro exemplo desse tipo de estratégia emergente que pode ser considerado um exploit pode
ser encontrado no Centipede original. Qualquer um que já jogou o jogo sabe que o acúmulo de
cogumelos é um dos maiores impedimentos para um jogo longo, e muitos jogadores entendem a
importância de manter o campo de jogo o mais claro possível. À medida que os devotos do jogo
bombeavam trimestre após trimestre no jogo, eles começaram a notar alguns padrões. Primeiro, eles
reconheceram que a pulga é responsável por soltar a maioria dos cogumelos problemáticos, embora
segmentos de centopéias destruídos também os deixem cair. Segundo, eles viram que a pulga não
sai na primeira onda do jogo. Terceiro, observou-se que a pulga é desencadeada pela ausência de
cogumelos na metade inferior da tela. Assim foi desenvolvida a famosa estratégia “blob”, que o
designer do jogo, Ed Logg, nunca antecipou. Para usar a estratégia blob, os jogadores eliminariam
todos os cogumelos do tabuleiro na primeira onda e permitiriam que os cogumelos sobrevivessem
apenas no quadrante inferior direito da tela. Se, através da destruição cuidadosa da centopéia, os
jogadores permitirem que apenas cogumelos sejam criados naquela seção da tela, a pulga nunca
sairá, tornando o jogo muito mais simples. Esta é uma solução emergente para obter uma pontuação
alta no Centipede, da qual os jogadores sem dúvida se sentiram muito orgulhosos quando foram
descobertos. Era uma tática que Logg, como criador do jogo, nem sabia que existia para ser
encontrada. Ao contrário da estratégia de rush da Civilization descrita acima, a estratégia blob era
tão difícil de executar que não era realmente uma façanha, apenas uma tática alternativa que exigia
muita habilidade do jogador.
Embora alguns designers fiquem angustiados sempre que uma estratégia inesperada surge em seu
jogo, é importante olhar para a tática dada e determinar se ela arruina a experiência do jogador ou
se é uma técnica igualmente ou até mais divertida do que a que o designer havia planejado. Se tais
estratégias emergentes não quebrarem completamente o jogo, elas precisam ser vistas como um
benefício para a profundidade do jogo e o resultado direto de um bom design de jogo.
Não-linearidade
Não-linearidade é outra palavra da moda na indústria de jogos, mas, assim como o surgimento, há
muito valor no conceito. A não-linearidade é o que é uma jogabilidade interessante, e muitos
desenvolvedores de jogos esquecem isso no calor da produção. A não-linearidade dá significado à
interatividade e, sem a não-linearidade, os desenvolvedores de jogos podem estar trabalhando em
filmes. Quanto mais partes do seu jogo você puder tornar não lineares, melhor será o seu jogo.
Infelizmente, por outro lado, quanto mais não linearidade seu jogo tiver, mais demorado e difícil
será desenvolver.
Em geral, quando alguém diz que algo é linear, quer dizer que segue uma linha.
Uma linha é uma série de pontos conectados no espaço bi ou tridimensional, onde se pode
encontrar qualquer ponto nessa linha usando uma equação específica, como, em um caso 2D, y =
mx + b. Em termos leigos, isso significa que uma linha deve ser reta. Se considerarmos quaisquer
dois pontos nessa linha, digamos A e B, há apenas uma maneira de navegar nessa linha de A a B.
Não há escolhas a serem feitas; deve-se simplesmente navegar por todos os pontos entre A e B.
Fora do mundo da matemática, podemos considerar a leitura de um livro como uma experiência
linear. Se alguém estiver lendo um livro de 323 páginas e não pular páginas ou capítulos, só há
uma maneira de ler o livro: começando na página 1 e lendo todas as páginas até a página 323.
Os jogos, no entanto, são obras não lineares. No jogo de xadrez, existem várias maneiras de
capturar o rei do oponente, para passar do estado inicial predeterminado do jogo até sua conclusão.
De fato, há um grande número de maneiras diferentes de ser vitorioso no xadrez, e essa variedade
é o que mantém o jogo interessante. Essas escolhas tornam o xadrez não linear. Suponha que o
tabuleiro de xadrez fosse unidimensional em vez de dois, as peças de cada jogador só pudessem
se mover em uma direção e cada jogador tivesse apenas uma peça.
Esta versão do xadrez é linear, pois não há escolhas significativas para os jogadores fazerem e o
resultado de cada jogo é completamente predeterminado. E, como resultado, não seria divertido
jogar.
Tipos de não linearidade

Então, quando dizemos que queremos que nossos jogos sejam não lineares, queremos dizer que
queremos que eles forneçam escolhas para os jogadores fazerem, caminhos diferentes que eles
podem seguir para ir do ponto A ao ponto B, do início ao fim do jogo. Podemos dizer isso de várias
maneiras: em termos da história do jogo, em termos de como os jogadores resolvem os desafios
do jogo, em termos da ordem em que os jogadores enfrentam os desafios e em quais desafios os
jogadores escolhem se envolver. Todos esses componentes podem contribuir para tornar um jogo
não linear, e quanto mais não linearidade o desenvolvedor criar, mais única será a experiência de
cada jogador. Além disso, os diferentes componentes não lineares podem interagir uns com os
outros para tornar o todo muito maior do que a soma de suas partes. • Narrativa: discuto a narrativa
não linear com mais detalhes no Capítulo 11, “Narrativa”. É claro que uma história não linear está
necessariamente ligada a uma jogabilidade não linear, e ninguém se incomodaria em tentar
fazer uma história não linear se o próprio jogo oferecesse aos jogadores muito pouco em
termos de decisões significativas. Contar histórias é talvez uma das partes mais negligenciadas
dos jogos em termos de não linearidade, com
muitos desenvolvedores permitem uma jogabilidade não linear enquanto restringem seus jogos a
uma história completamente linear.
• Soluções Múltiplas: Eu discuti acima como um jogo bem projetado permitirá que os
jogadores criem suas próprias soluções para os desafios que o jogo apresenta.
Nem todo jogador resolverá uma situação da mesma maneira e, como essas soluções alternativas
são razoáveis, quase qualquer desafio deve ter várias maneiras de superá-lo. Ter várias soluções
para os desafios individuais dentro de um jogo é uma grande parte da não-linearidade; ele permite
que os jogadores tenham vários caminhos para chegar do ponto A (sendo apresentado ao desafio)
e do ponto B (resolvendo o desafio). • Ordem: Além de poder descobrir as soluções para os
desafios de maneiras únicas, os jogadores apreciarão a capacidade de escolher a ordem em que
realizam os desafios. Muitos jogos de aventura cometeram o erro de serem excessivamente lineares ao
permitir que os jogadores acessem apenas um quebra-cabeça por vez. Para tentar um segundo
quebra-cabeça, os jogadores devem completar o primeiro. Essa é uma maneira linear de pensar,
que se mostra especialmente frustrante quando os jogadores ficam presos em um quebra-cabeça
específico e, devido à natureza linear do jogo, não podem fazer mais nada até que o quebra-
cabeça seja resolvido. Dar aos jogadores escolhas de quebra-cabeças diferentes para resolver
permite que eles deixem de lado um quebra-cabeça problemático e trabalhem em outro por um
tempo. Depois de completar o segundo quebra-cabeça, os jogadores podem retornar ao primeiro
atualizado e revitalizado e, assim, ter mais chances de resolvê-lo.
• Seleção: Outra maneira de tornar um jogo não linear é permitir que os jogadores
escolham quais desafios querem superar. Digamos que entre o ponto A e o ponto B
de um jogo há uma série de três desafios, X, Y e Z, que não dependem da ordem, ou
seja, os jogadores podem fazer esses desafios na ordem que quiserem. E se, uma
vez que os jogadores superem o desafio X, eles não precisem voltar e resolver o
desafio Y ou Z, eles podem simplesmente passar para o ponto B no jogo, talvez
nunca retornando a Y ou Z? O mesmo é verdade se os jogadores inicialmente
escolherem atacar Y ou Z em vez de X. Qualquer uma das opções permitirá que os
jogadores prossigam. A vantagem é que se os jogadores acharem o desafio X
insuperável, eles podem tentar o desafio Y ou Z. Isso diminui muito a chance de os
jogadores ficarem permanentemente presos. Não é necessário que Y seja mais fácil
que X; o simples fato de ser diferente pode permitir aos jogadores uma chance melhor
de passar por isso, dependendo de seus pontos fortes. Outros jogadores podem
achar X mais fácil do que Y ou Z, mas dar aos jogadores uma escolha de quais
desafios eles enfrentam permite que eles explorem suas próprias habilidades
pessoais para passar pelo jogo. Claro, depois de completar o desafio X, os jogadores
ainda podem ter a opção de voltar e completar os desafios Y e Z, talvez apenas por
diversão ou porque superar esses desafios de alguma forma melhora suas chances
no futuro. Talvez completar Y e Z dê ao personagem do jogador maior experiência
ou riqueza geral. Esse tipo de não-linearidade também pode ser usado para adicionar missões se
Esses desafios não são estritamente necessários para os jogadores chegarem ao final do jogo,
embora possam torná-lo um pouco mais fácil ou apenas fornecer uma diversão interessante ao
longo do caminho. Seja qual for o caso, esses desafios opcionais fornecem um grau extra de não
linearidade, personalizando ainda mais as experiências dos jogadores.
Implementação
Odyssey é um jogo
extremamente não linear,
permitindo que o jogador
resolva quebra-cabeças na
ordem que escolher e
selecione quais missões
ele quer continuar. O jogo
quase sempre fornece mais
de uma solução para
qualquer quebra-cabeça.
Meu primeiro jogo, Odyssey: The Legend of Nemesis, é sem dúvida o design de jogo
mais implacável e menos linear que já fiz, e inclui exemplos de todos os tipos de não
linearidade descritos acima. Odyssey é um RPG e acontece em um arquipélago que inclui
sete ilhas principais para os jogadores explorarem. Embora os jogadores sejam obrigados a
completar pelo menos uma missão na primeira ilha antes de passar para o resto do jogo,
existem duas missões, cada uma com várias soluções que os jogadores podem escolher. De
fato, jogadores inteligentes podem pular as missões completamente se descobrirem como
roubar um determinado cidadão. (Na verdade, esse foi um comportamento emergente que
eu não havia previsto, mas que felizmente fazia sentido e não inviabilizou o jogo significativamente.)
A partir daí, os jogadores podem se mover livremente pelas próximas cinco ilhas, escolhendo
quais desejam explorar e quais preferem apenas passar. De fato, tudo o que é necessário
para os jogadores alcançarem a sétima ilha e o fim do jogo é a navegação bem-sucedida de
cada ilha, matando os monstros que estiverem em seu caminho. Claro, matar essas criaturas
é significativamente mais fácil se os jogadores receberem as recompensas por completar as
missões. Mas se os jogadores assim o desejarem, eles podem pular todo o meio do jogo.
Claro, poucos jogadores fizeram isso, preferindo explorar as diferentes missões e situações
que encontram lá. Quase todas essas missões têm várias maneiras de os jogadores resolvê-
las, com suas ações tendo um impacto direto em como cada uma das mini-histórias da ilha
se resolve. Finalmente, o jogo em si tem múltiplos finais para os jogadores explorarem, finais
que se adequam aos diferentes objetivos gerais que os jogadores podem ter: sobrevivência,
vingança ou uma espécie de justiça e harmonia. Embora o jogo tenha uma história muito
definida, fico feliz em dizer que duvido muito que dois jogadores tenham experimentado
exatamente da mesma maneira.
No geral, meu jogo The Suffering foi significativamente menos não linear do que
Odyssey, mas ainda apliquei muitas das mesmas técnicas de narrativa não linear para dar
profundidade à história do jogo. O Sofrimento torna a experiência de cada jogador única por
meio de seu sistema de moralidade, que avalia como o jogo está sendo jogado e então determina
o passado do personagem do jogador e muda a forma como os personagens no presente falam com ele.
Como um jogo de terror, o enredo foi mantido um tanto vago de propósito, com os jogadores precisando
preencher muitas das lacunas. Além disso, cada jogador provavelmente teria uma subseção diferente da
história geral, já que grande parte da história está contida em áreas laterais opcionais. De fato, os
jogadores que jogam o jogo a toda velocidade perderão muito do enredo, enquanto aqueles que jogam
normalmente provavelmente verão cerca de metade do que há para ser encontrado. Isso significa que
há muitas maneiras diferentes de experimentar a história e os jogadores terão impressões diferentes
dependendo de como jogam. De fato, durante o desenvolvimento, houve muita preocupação com os
jogadores perdendo muito do jogo ao executá-lo rapidamente, já que existem relativamente poucos
gargalos para bloquear a progressão. No final, porém, por meio de testes de jogabilidade e do feedback
que recebemos após o lançamento do jogo, percebemos que quase todos os jogadores explorarão o
jogo mais do que o necessário apenas porque estão interessados nele. Da mesma forma, os jogadores
lutarão contra criaturas que não precisam estritamente. É importante lembrar que os jogadores querem
jogar um jogo para se divertir, e apenas os mais masoquistas arruinarão deliberadamente sua experiência
de jogo. Assim, você não precisa se preocupar tanto com as façanhas do jogo quanto garantir que o jogo
seja divertido se jogado por jogadores cooperativos.
No lado do quebra-cabeça, The Suffering é um pouco menos bem-sucedido em termos de não

linearidade: muitos dos quebra-cabeças têm várias soluções, mas um número igual não.
Embora a maioria dos objetivos tenha sido planejada para ter várias maneiras de completá-los, tivemos
várias situações em que uma solução envolveria uma recompensa empolgante, enquanto a outra não.
Nossos produtores estavam preocupados que os jogadores perderiam muito ao escolher a solução
alternativa e, assim, acabamos cortando algumas das alternativas menos empolgantes. Isso leva a uma
regra prática importante: se você quiser ter várias soluções ou caminhos, todos eles devem ser
igualmente atraentes para que os jogadores não se sintam enganados por terem escolhido o caminho
muito menos espetacular. Outra falha de não-linearidade em The Suffering envolveu um nível específico
que foi inicialmente projetado para ser extremamente não-linear. Neste nível, havia originalmente três
caminhos separados que levavam ao final do nível.
Através de nossos testes de jogabilidade, descobrimos que os jogadores estavam extremamente
confusos com os três caminhos, com quase todos os jogadores voltando ao início do nível e depois
confusos sobre onde estavam. É certo que esse problema em particular foi devido ao design de nível
ruim, mas este é um caso em que a não linearidade acabou prejudicando a experiência do jogador, e
acabamos retrabalhando o fluxo de nível no jogo final.
A não-linearidade é uma ferramenta extremamente poderosa para se usar no design de um jogo, e
as descrições acima dos tipos de não-linearidade que um designer pode empregar podem parecer óbvias
para o leitor. O que é surpreendente, então, é quantos jogos falham em fornecer qualquer não-linearidade
substancial para os jogadores, em vez disso, insistem que os jogadores joguem o jogo em uma única
linha do ponto A ao ponto B. Uma razão para isso é que criar todos esses elementos não lineares podem
consumir bastante tempo. Considere que entre o ponto A e B, temos os desafios mencionados X, Y e Z,
mas os jogadores só precisam superar um desses desafios para progredir. Os jogadores podem então
continuar jogando até o final do jogo sem nunca terem interagido com o desafio Y ou Z. Como um jogo
não linear, essa é a prerrogativa dos jogadores. O problema surge quando um contador de custos analisa
o jogo e tenta descobrir onde o orçamento do jogo pode ser reduzido. Bem, obviamente, se Y e Z não
são estritamente necessários, por que se preocupar em tê-los? Por que gastar muito dinheiro em
programação, arte e design necessários para obter Y
Trabalhar a não-
linearidade significativa
em The Suffering provou
ser bastante desafiador.
e Z trabalhando quando há uma chance de que os jogadores nunca os vejam? Infelizmente, os

contadores muitas vezes não estão em contato com os pontos mais delicados do design do jogo,
e quando você diz: “Mas a não linearidade é o que torna este jogo ótimo!” é provável que eles o
considerem “irracional” ou “difícil”.
A não linearidade também é muitas vezes difícil de obter de uma perspectiva de design,
certamente mais difícil do que a simples linearidade. Esta pode ser outra razão pela qual tantos
designers evitam na primeira oportunidade. Projetar vários obstáculos diferentes o suficiente para
oferecer variedade aos jogadores e aplicar aproximadamente o mesmo desafio não é uma tarefa
fácil. No exemplo dos desafios X, Y e Z, se Z for significativamente mais fácil do que X ou Y, é bem
provável que ninguém se preocupe com X ou Y. De certa forma, um jogo com escolhas mal
projetadas para os jogadores é quase tão linear como um jogo sem nenhuma escolha. A não-
linearidade que seu jogo oferece deve ser significativa e útil para os jogadores ou é um desperdício.
Designers que pensam demais em suas próprias habilidades de design também podem evitar a
não linearidade em seus designs porque querem que os jogadores experimentem cada elemento
do jogo que decidirem incluir. “Por que gastar tanto tempo em partes do jogo que nem todos
verão?” dizem esses designers um tanto egoístas, perdendo completamente o ponto. Se um
número suficiente de pessoas jogar o seu jogo, algumas pessoas certamente verão o que você
criou, e cada um dos jogadores terá uma experiência um pouco diferente por causa disso. Assim
como um grande romance terá várias camadas em sua história e diferentes significados que
diferentes leitores irão tirar, ainda mais um jogo deve permitir que os jogadores encontrem seu
próprio caminho no mundo do jogo e os capacitem a criar sua própria experiência única.
O Propósito da Não Linearidade

É importante sempre lembrar que a não-linearidade está incluída no jogo para fornecer aos
jogadores alguma autoria significativa na maneira como eles jogam o jogo. Se eles forem forçados
a permanecer em uma linha específica para ir do início ao fim do jogo, o jogo parecerá limitado.
Os desafios nessa linha podem ser brilhantemente concebidos, mas se
os jogadores não têm escolha a não ser enfrentá-los em ordem, um por um, a diversão que eles
proporcionam será muito diminuída.
A não linearidade é ótima para fornecer aos jogadores um motivo para jogar novamente.
Repetir um jogo onde os jogadores já superaram todos os desafios não é muito divertido. Ao repetir
um jogo mais não linear, no entanto, os jogadores poderão se afastar dos desafios que tiveram na
última vez em que jogaram e, em vez disso, enfrentar os outros ramos do jogo. No entanto, é
importante notar que a replayability não é a principal motivação para incluir a não linearidade em
seus designs de jogos. Ouvi alguns designers de jogos reclamarem que a replayability é desnecessária,
já que muitos jogadores nunca conseguem terminar os jogos que começam a jogar. Então, se eles
nunca terminam, por que adicionar replayability? Esses designers não percebem que o verdadeiro
objetivo da não linearidade é conceder aos jogadores uma sensação de liberdade no mundo do jogo,
permitir que os jogadores tenham uma experiência de jogo única, contar sua própria história. Se os
jogadores quiserem repetir o jogo novamente, tudo bem, mas o objetivo principal da não linearidade
é entregar algum grau de autoria aos jogadores.
Além disso, a afirmação de que os jogadores raramente terminam os jogos e, portanto, os jogos
não precisam ser não lineares é uma profecia auto-realizável. A razão pela qual os jogadores não
terminam os jogos é porque eles ficam presos em um momento específico do jogo. Este pode ser um
monstro-chefe que é muito difícil, um quebra-cabeça que é muito confuso ou simplesmente não
consegue encontrar a saída de uma determinada área. Se o jogo fosse mais não linear, no entanto,
os jogadores teriam muito menos chance de ficar presos em qualquer ponto do jogo, uma vez que a
variedade de caminhos disponíveis aumentaria a probabilidade de que os talentos únicos dos
jogadores fossem suficientes para que eles o fizessem. com sucesso através de um dos caminhos.
Em uma palestra da Game Developers Conference intitulada “A Grand Unified Game Theory”,
Noah Falstein sugeriu que quando a não-linearidade permite que os jogadores enfrentem uma série
de desafios obrigatórios na ordem que desejarem, completar um desafio deve tornar os outros mais
fáceis para os jogadores realizarem. No caso de uma coleção de quebra-cabeças, isso pode ser feito
fornecendo aos jogadores uma dica sobre os outros quebra-cabeças assim que um estiver concluído.
No caso de uma coleção de batalhas de algum tipo, isso pode ser feito fornecendo aos jogadores
armas adicionais para sobreviver às outras batalhas. Seja qual for o caso, o uso dessa técnica
aumenta a chance de os jogadores serem capazes de superar os desafios em mãos e continuar com
o jogo.
Uma nota de cautela: todos os designers devem entender que não-linearidade não é ter
jogadores vagando pelo mundo do jogo sem rumo. Se o jogo for não linear a ponto de os jogadores
não terem ideia do que devem tentar realizar ou como podem fazê-lo, a não linearidade pode ter ido
longe demais. Muitas vezes, os designers de jogos falam sobre seus jogos em desenvolvimento
fazendo declarações como “Em nosso mundo de jogo, os jogadores podem fazer o que quiserem;
não há restrições. O jogo é completamente não linear!” Tal jogo provavelmente seria completamente
irritante também. É claro que, no momento em que esses jogos “completamente não lineares” foram
lançados, a maior parte da não linearidade foi retirada e os jogadores ficaram resolvendo quebra-
cabeças em um trilho. Em algum lugar entre os jogos “on a rail” e a liberdade total, há um meio-termo
ideal, onde os jogadores ficam com uma sensação de liberdade acompanhada por uma sensação de
orientação.
Modelando a Realidade
O desejo de modelar a realidade em jogos de computador é aquele que tem impulsionado o
desenvolvimento de jogos por vários anos. Quanto mais reais tornarmos os jogos, dizem os
proponentes, mais atraentes e imersivos os jogadores os acharão. Mas isso é sempre assim?
O que um maior grau de realidade acrescentaria a um jogo como Tetris ou Centipede? Certamente
eles não poderiam ser muito mais imersivos do que já são. Considere um jogo como Age of Empires,
que já é modelado na realidade. Adicionar mais realidade a ele tornaria mais divertido? Na verdade,
é exatamente o oposto: adicionar um modelo econômico ou sistema de combate mais realista
diminuiria os pontos fortes do jogo como um jogo de macroestratégia e possivelmente tornaria o
jogo mais irritante do que divertido.
O problema de modelar a realidade nos jogos ocorre quando os títulos ficam atolados na
realidade a ponto de se assemelharem à vida real um pouco mais do que os jogadores realmente
desejam. Alfred Hitchcock descreveu os filmes como “A vida com os pedaços sem graça cortados”.
De fato, os jogos podem ser vistos como modelar a vida ou algum aspecto da vida, deixando de
fora as partes tediosas e chatas. Se o designer, na tentativa de alcançar um maior grau de realidade,
decidir incluir muitos detalhes desnecessários e sem graça, o jogo provavelmente se tornará tedioso
de jogar. Meu exemplo favorito disso é o uso de comida em RPGs. Muitos RPGs dos anos 80
estavam perpetuamente em busca de se tornarem mais reais do que outros RPGs, aumentando a
aposta a cada novo jogo lançado. Uma maneira de os designers tentarem fazer isso foi adicionar
uma simulação básica de fome e exigir que os jogadores se lembrem de alimentar os membros do
grupo periodicamente, para que não morram de fome. Aqui estava um “pedaço maçante” que não
precisava ser incluído, especialmente porque comer refeições programadas regularmente não é a
primeira coisa que vem à mente das pessoas quando pensam em se aventurar em mundos fantásticos.
Usar a realidade como base para o seu jogo tem suas vantagens, no entanto. Em primeiro
lugar, ele fornece aos jogadores um mundo com o qual eles estão instantaneamente familiarizados,
um mundo no qual eles têm alguma ideia de quais ações são razoáveis e quais estão fora de questão.
Seja em Civilization, SimCity, Deadline ou Grand Theft Auto, um cenário realista executado
corretamente dá aos jogadores uma “entrada” instantânea no seu mundo de jogo. Eles entendem
ou pelo menos pensam que entendem como funciona e o que podem fazer para ter sucesso nisso.
Os jogadores podem começar a jogar e instantaneamente ter uma ideia do que devem realizar.
Um jogo mais abstrato como Centipede ou Tetris, por outro lado, tem objetivos tão abstratos que os
jogadores devem ser ensinados sobre o que devem fazer, seja lendo as instruções ou
experimentando o mundo do jogo.
Além das vantagens de jogabilidade, em termos de história e cenário, colocar seu jogo em um
cenário do mundo real pode ser muito mais significativo para os jogadores, permitindo que as ações
que ocorrem no mundo do jogo ressoem com eles mais profundamente do que se o seu jogo foram
ambientados em mundos abstratos. The Sims funciona em parte por causa de sua jogabilidade e
simulação bem equilibradas, mas também por causa de sua configuração do mundo real que
permite aos jogadores sentir que suas ações têm um significado real para as pessoas simuladas
que estão guiando. Meu jogo Damage Incorporated, embora tenha uma premissa um tanto
implausível, foi ambientado no mundo real e lidou com questões do mundo real que tornaram as
missões e seus resultados mais relevantes para os jogadores do que se o jogo tivesse sido ambientado no e
Da mesma forma, The Suffering, apesar de ter criaturas sobrenaturais surgindo de todos os cantos
e recantos, foi ambientado em um ambiente de prisão crível povoado por reconhecíveis
Ter um ambiente crível

e reconhecível foi uma
grande parte do apelo
do The Suffering .
e personagens plausíveis. Assim, foi capaz de lidar com temas pesados e sérios de uma forma mais
ressonante do que se o jogo tivesse ocorrido em algum submundo demoníaco.
Uma possível desvantagem de ter um mundo realista é que, como o jogo imita uma realidade
com a qual os jogadores estão familiarizados, os jogadores esperam que certos elementos do mundo
do jogo funcionem de certas maneiras e serão muito rápidos em perceber quando algo falhar. Por
exemplo, muitos dos primeiros jogos de tiro em primeira pessoa, como Doom e Marathon, não
permitiam que o personagem do jogador saltasse. Os mundos desses jogos de tiro em primeira
pessoa eram mais “realistas” do que aqueles que os jogadores estavam acostumados a encontrar em
jogos de computador, tão reais que as expectativas dos jogadores aumentaram e muitos foram rápidos
em reclamar que não podiam pular nem mesmo obstáculos na altura da cintura. . Assim, a próxima
geração de títulos FPS adicionou a capacidade de pular, depois agachar, depois olhar para cima e
para baixo, e assim por diante, tornando os jogos ainda mais complicados com cada elemento de realidade adicion
Agora, como os mundos possíveis com os motores RT3D parecem mais reais do que nunca, os
jogadores estão constantemente fazendo perguntas como “Por que não posso deitar no chão? Posso
fazer isso na vida real; por que não no jogo?” De fato, muitos dos atiradores em primeira pessoa mais
complexos adicionaram esse mesmo recurso. Alguns diriam que, certamente para jogadores iniciantes,
esses jogos FPS se tornaram muito complexos como resultado de sua tentativa de modelar a realidade.
Trazer um certo nível de realidade aumenta as expectativas dos jogadores de uma forma que o
mundo totalmente abstrato de uma Centopéia ou Tetris nunca faz. Os jogadores nunca questionam
suas capacidades nesses mundos porque os limites eram completamente arbitrários em primeiro lugar.
Ao mesmo tempo, os jogadores são específicos sobre o tipo de melhorias baseadas na realidade
que desejam em seus jogos. Por exemplo, se os jogos FPS adicionassem uma modelagem mais
realista do movimento do jogador, os jogadores ficariam irados. Se de repente você fosse capaz de
tropeçar em obstáculos baixos ou sempre cair de joelhos ao cair de mais de um metro e meio, a
experiência de correr pelo mundo do jogo seria consideravelmente mais agravante. Essas são as
partes tediosas do movimento do mundo real e, portanto, podem e devem ser ignoradas. No final, a
maioria dos jogadores só quer mais realismo se isso significar que eles podem fazer coisas mais
interessantes e divertidas, não se isso tornar sua experiência de jogo mais frustrante.
Então, existe uma resposta definitiva se você deve ou não modelar a realidade em seu jogo?
Claro que não, assim como não há respostas fáceis em todo o design de jogos, e não há respostas
fáceis na arte. Como designer de jogos, você deve encontrar o equilíbrio entre realidade e
abstração, pesando o que seu jogo precisa do ponto de vista da jogabilidade com o que sua história
e cenário exigem e com o que seu mecanismo pode lidar de forma razoável. O que é vital lembrar,
e o que muitos designers muitas vezes esquecem, é que mais realidade nem sempre é uma coisa
boa. Ao mesmo tempo, dizer que a realidade não importa e que a diversão é tudo e tudo pode
impedir você de criar um mundo que ressoe com seu público.
Ensinando o jogador
Tentar modelar a realidade pode ser uma maneira de dar aos jogadores uma vantagem ao entrar
no seu mundo de jogo; através de suas próprias experiências de vida, os jogadores saberão até
certo ponto o que esperar do seu mundo de jogo. No entanto, mesmo com o jogo mais realista, os
jogadores precisarão de tempo para aprender a jogar seu jogo, e essa experiência de aprendizado
geralmente é um momento crucial na experiência geral de um jogador. Os primeiros minutos que
os jogadores passam com o seu jogo geralmente fazem a diferença entre continuar jogando ou
não. Sempre que os jogadores contam aos amigos sobre o seu jogo, eles geralmente se lembram
daqueles primeiros minutos e dizem: “Bem, foi um pouco estranho se acostumar” ou, de preferência,
“Foi ótimo. Eu pulei direto no jogo e encontrei todas essas coisas interessantes.”
No passado, muitos jogos de computador contavam com manuais para ensinar os jogadores
a jogá-los. Com alguns títulos, os jogadores literalmente não tinham quase nenhuma chance de
sucesso no jogo sem primeiro ler uma grande parte do manual. Hoje, muitos jogos tentam fugir
dessa dependência da capacidade de leitura dos jogadores, percebendo que muitas vezes a última
coisa que os jogadores querem fazer quando acabam de comprar um novo jogo é sentar e ler um
extenso manual de instruções. Os jogadores definitivamente têm um forte desejo de simplesmente
pegar o controle e começar a jogar. Agora que tantos jogos permitem que os jogadores façam
exatamente isso, a importância de permitir que os jogadores “pulem direto” aumentou. Se o seu
jogo for muito difícil de controlar no primeiro minuto, é provável que os jogadores o abandonem e
tentem outra coisa.
Isso não significa que seu jogo deva ser emburrado ou simplificado, apenas que você deve
introduzir a complexidade do seu mundo de jogo gradualmente através da jogabilidade em vez de
através do manual. Por exemplo, a princípio, seu jogo deve começar exigindo que os jogadores
executem apenas as ações mais simples. Digamos que você esteja criando um jogo de ação/
aventura sobre o ombro em terceira pessoa semelhante a Tomb Raider. Faz mais sentido primeiro
ensinar aos jogadores como mover o personagem do jogador corretamente no chão. Então, depois
que os jogadores tiverem a chance de se acostumar com os controles de movimento horizontal,
você pode introduzir uma seção onde o personagem do jogador tem que pular para atravessar um
desfiladeiro ou escalar um penhasco. Depois disso, você pode querer introduzir alguns desafios de
combate simples, onde os jogadores aprenderão como usar as armas de seus personagens.
É importante que durante a introdução desses controles os jogadores estejam em um

ambiente seguro que gere aprendizado. Se os jogadores já têm que se preocupar em morrer a
cada passo e o jogo geralmente não perdoa os erros dos jogadores, as chances são boas de que
os jogadores fiquem frustrados rapidamente. A designer Sheri Graner Ray estudou
Prince of Persia ensinou

cuidadosamente ao jogador
o que esperar de armadilhas,
como pisos em colapso e
pontas afiadas.
como os jogadores preferem aprender um novo jogo e descobriu que alguns jogadores, geralmente homens,
preferem experimentar e experimentar cada mecânica de jogo à medida que são introduzidas.
Assim, permitir que os jogadores experimentem novas mecânicas em um espaço seguro é muito importante.
Half-Life fez isso particularmente bem, com uma introdução ao jogo que forneceu um ambiente seguro e
interessante e permitiu que os jogadores se acostumassem aos controles sem ameaçá-los imediatamente.
O Prince of Persia original foi outro jogo particularmente bom em introduzir desafios aos jogadores de uma
maneira que os ensinava através do exemplo, em vez de puni-los. Por exemplo, quando os jogadores
encontram um andar separatista pela primeira vez em Prince of Persia, cair nele não é letal. Da mesma
forma, os picos são introduzidos de tal forma que os jogadores provavelmente os notarão e serão capazes
de sobreviver a eles. Encontros subsequentes com picos não serão tão indulgentes, mas até então os
jogadores aprenderam sobre a ameaça que representam para seu personagem no mundo do jogo e, se
forem inteligentes, serão capazes de sobreviver a eles.
Durante esse período de aprendizado no jogo, é importante recompensar os jogadores até pelas
realizações mais simples. Isso faz com que os jogadores sintam que, de fato, estão no caminho certo com o
jogo e os incentiva a continuar jogando. É verdade que os jogadores não querem que seus jogos sejam
muito simples e pouco desafiadores, mas puni-los por erros desde o início do jogo não é a maneira correta
de produzir esse desafio.
A chave é dar aos jogadores o sucesso desde o início, atraí-los para o jogo, fazê-los pensar que sabem do
que se trata o jogo e que são melhores do que ele. “Ha-ha, este jogo é fácil! Eu mando!" eles podem dizer.
E então, quando o jogo se tornar subitamente mais desafiador, os jogadores já terão sido atraídos para o
jogo e estarão muito mais propensos a ver o desafio como um desafio razoável, que eles certamente podem
superar. Afinal, este jogo é fácil, certo?
Tutoriais
Recentemente, muitos jogos complexos começaram a apresentar os jogadores ao mundo dos jogos através
de um nível de tutorial que existe fora do próprio mundo do jogo. Os jogadores podem acessar este mundo
tutorial através do menu principal como uma alternativa para iniciar um jogo “real”.
Esses níveis de tutorial geralmente são uma boa ideia e certamente são uma melhoria em relação ao ensino
dos jogadores sobre o jogo no manual. Os níveis do tutorial fazem uma das coisas
Deus Ex integrou seu

treinamento na ficção
do jogo de uma forma
muito crível.
que os computadores fazem melhor: proporcionar uma experiência de aprendizagem interativa.

Esses níveis tendem a levar os jogadores pela mão pela mecânica do jogo, ensinando-lhes o
que eles precisarão saber pouco a pouco. Sheri Graner Ray descobriu que alguns jogadores,
geralmente mulheres, tendem a preferir ser conduzidos pelo jogo por um tempo até pegar o
jeito, e os níveis de tutorial estruturados são perfeitos para isso. O único problema com os
níveis de tutorial é que eles raramente são muito divertidos de jogar e, como resultado, muitos
jogadores os ignoram e vão direto para o jogo real. Além do aprendizado dos controles,
geralmente há pouco interesse neles. Há um sentimento entre os jogadores de que o nível
tutorial não faz parte do jogo “real”, e muitos jogadores querem começar a jogar este jogo “real”
o mais rápido possível. Se o designer incluir um nível de tutorial porque deseja tornar seu jogo
difícil desde o início e evitar ensinar os jogadores a jogar durante o jogo, os jogadores que
pularem o tutorial ficarão frustrados. Os níveis de tutorial são bons para jogadores que querem
esse tipo de prelúdio educacional para o jogo, mas não devem substituir o início do jogo em si
como um tutorial bem disfarçado e fácil de jogar. Mais uma vez, Half-Life forneceu um nível de
tutorial que ensinou aos jogadores sobre o mundo do jogo, mas o tutorial funcionou em conjunto
com o início do próprio jogo, que era bastante fácil de jogar e tinha uma curva de aprendizado
amigável. Claro, tornar o nível do tutorial o mais divertido possível ajuda muito os jogadores a
realmente jogá-lo. Deus Ex fez algumas melhorias nessa frente, estabelecendo o tutorial
firmemente na ficção do mundo do jogo e, em seguida, fazendo o treinamento inesperadamente
funcionar mal no final, de repente empurrando os jogadores para uma situação ameaçadora.
Halo pegou esse mesmo conceito e o executou de maneira particularmente elegante, sem fazer
com que o nível parecesse um nível de tutorial. Os jogadores ficaram presos em um estado
estranho apenas por um breve período no início, enquanto se acostumavam a usar o esquema
de controle de dois controles analógicos. Então, de repente, a nave espacial em que o
personagem do jogador está é invadida por alienígenas hostis. O primeiro nível que os
jogadores jogam os apresenta às mecânicas do jogo, um por um, em uma área que parece
perigosa, mas na verdade é bastante segura.
Aqui estava um nível de treinamento completamente camuflado no mundo do jogo que era
muito divertido de jogar.
Títulos de console
como The Legend of
Zelda: Ocarina of
Time são bons para
ensinar o jogador a
controlar o jogo.
Normalmente, esses níveis de tutorial incluem instruções que explicam quais teclas ou
botões os jogadores devem pressionar para obter determinados efeitos. Muitas vezes, o texto
na tela aparece, às vezes acompanhado por narrações que dizem aos jogadores para “Pressione
a barra de espaço para disparar sua arma primária” ou “Pressione e segure o X azul para um
super salto”. Halo, novamente, teve uma implementação muito boa de texto de ajuda não
intrusivo que apareceu durante o jogo. A chave com essa ajuda automática no jogo é que você
quer que os jogadores que não precisam dela possam ignorá-la com bastante facilidade (ou até
mesmo ter a opção de desativá-la completamente), enquanto ela precisa aparecer e ficar por
perto tempo suficiente para aqueles que precisam para vê-lo. Você precisa ter certeza de que
os jogadores iniciantes não perderão e terão a chance de aplicá-lo antes que ele desapareça.
Um texto de ajuda bem implementado pode ser uma grande vantagem para tornar um jogo
complexo mais fácil de entender. Além disso, no entanto, jogos como Spyro the Dragon e The
Legend of Zelda: Ocarina of Time chegam ao ponto de ter personagens reais do jogo dizendo
ao personagem do jogador quais são os controles do jogo. No jogo anterior, o dragão ancião
amigável diz: “Spyro, pressione e segure o botão azul para planar”. Eu acho que isso vai longe
demais e quebra totalmente a suspensão de descrença do jogador. Os personagens do jogo
não devem saber nada sobre o jogador e certamente nada sobre um controle de PlayStation.
No entanto, acho que é útil lembrar os jogadores dos controles do jogo enquanto eles estão
jogando através de telas de GUI mais removidas e dublagens de personagens que não são do
jogo. Muitos jogos modernos incluem controles tão sofisticados que provavelmente alienam os
jogadores não-hard-core, e é uma boa ideia lembrar aos jogadores novatos o que eles precisam
fazer para executar um determinado movimento.
Eu diria que, em retrospecto, a maioria dos meus jogos tem sido muito difícil, e certamente
muito difícil para os jogadores entrarem. A exceção a isso é The Suffering, que de longe fez o
melhor trabalho ao introduzir mecânicas aos jogadores gradualmente ao longo do primeiro nível.
Na verdade, ele foi projetado especificamente para fazer isso desde o início do desenvolvimento.
Embora os jogadores tenham a impressão de que os monstros estão fervilhando por todo o
nível, matando tudo o que encontram, na verdade é impossível morrer nos primeiros 10 a 15
minutos do jogo. Isso dá aos jogadores um lugar seguro para aprender os controles. Durante
este período seguro e durante todo o primeiro nível, um texto de ajuda discreto aparece na tela
para ajudar os jogadores a aprender as diferentes ações que podem executar. No entanto, o sofrimento
maior falha foi não aumentar a dificuldade ao longo do jogo, tornando o jogo muito fácil no geral.
Mas isso é menos uma questão de treinamento e mais um problema de equilíbrio. Em termos de
treinamento, um jogo que errou na direção oposta é Odyssey, meu RPG baseado em turnos. Nele
os jogadores começam náufragos em uma ilha, sem armas ou posses de qualquer tipo. Eu queria
que os jogadores ficassem assustados imediatamente e precisassem encontrar um lugar seguro
para se esconder em uma caverna próxima. Eu consegui isso fazendo com que alguns monstros
começassem a atacar na direção dos jogadores alguns turnos depois que o personagem do
jogador chegasse à praia. Os jogadores não tinham chance de derrotar essas criaturas por conta
própria e precisavam entrar na caverna próxima para sobreviver. Originalmente, eu tinha a caverna
escondida na floresta, dificultando a localização dos jogadores e, assim, tornando o jogo ainda
mais implacável. Felizmente, meus playtesters me convenceram de que a introdução era muito
difícil, e eu movi a caverna para um lugar aberto onde os jogadores pudessem vê-la facilmente.
No entanto, o problema permaneceu que, antes que os jogadores tivessem a chance de se
familiarizar com os controles, eles foram atacados por monstros estranhos, sem nenhuma ideia
real do que deveriam fazer sobre isso. Muitas vezes me pergunto quantos jogadores ficaram
assustados com essa introdução excessivamente desafiadora e nunca jogaram o resto do jogo como resul
Entrada/ Saída Os
sistemas de entrada e saída do seu jogo são dois dos principais fatores que determinam
quão íngreme é a curva de aprendizado do seu jogo e se os jogadores acharão intuitivo
jogar. Usando os sistemas de entrada/saída que você projeta, os jogadores devem ser
capazes de controlar e entender o jogo sem esforço. Projetar esses sistemas é um dos
aspectos mais difíceis do design de jogos, pois, se forem bem projetados, os jogadores nem
saberão que estão lá. Mas se eles forem mal projetados, os jogadores ficarão facilmente
frustrados, reclamando que os controles do jogo os impedem de fazer o que eles realmente
querem fazer no jogo. Projetar sistemas de entrada e saída é uma arte “invisível”, pois o
objetivo de sua criação é que eles sejam transparentes para os jogadores. Isso às vezes
pode levar os designers a não considerarem completamente a melhor forma de fazer o I/O
funcionar em seus jogos, um erro que você deve evitar se quiser que seus jogos sejam divertidos de
Controles e Entrada
Nada é mais frustrante para os jogadores do que saber exatamente o que eles querem que seu
personagem do mundo do jogo faça, mas ser incapaz de fazê-lo fazer isso porque os controles
não permitem. Uma boa jogabilidade nunca é tentar descobrir os próprios controles; embora você
possa querer quebra-cabeças em seu mundo de jogo, seu esquema de controle não deve ser um
quebra-cabeça que os jogadores precisam descobrir. Os controles são a interface dos jogadores
entre o mundo real e o mundo do jogo. Para que os jogadores experimentem a verdadeira imersão
no jogo, eles devem ser capazes de manipular o mundo do jogo quase tão intuitivamente quanto
manipulam o mundo real. Toda vez que os jogadores têm que pensar: “Agora, que botão eu tenho
que pressionar para fazer isso?” essa imersão é destruída.
Embora os controles de muitos jogos de computador pareçam estar ficando cada vez mais
complexos, particularmente aqueles para jogos de ação em 3D, há muito a ser dito para manter
seus controles simples. De fato, muito do sucesso de jogos como Diablo, Command & Conquer e
The Sims pode ser atribuído ao fato de que os jogadores podem jogar esses jogos com uma mão,
controlando tudo apenas com o mouse. O mouse é extremamente
Os controles
extremamente
simples da série Diablo
os tornam alguns dos
jogos mais fáceis de
aprender disponíveis.
Retratado aqui: Diablo II.
poderoso dispositivo de entrada quando usado corretamente. Seu grande ponto forte é que é um dispositivo
de controle com o qual a maioria dos usuários de computador não-jogadores já estão familiarizados. Isso
torna os jogos apenas com mouse muito fáceis de entrar, pois minimizam o tempo que o usuário deve
gastar aprendendo os controles.
Uma grande parte do design de uma boa interface baseada em mouse é fazer um sistema que não
pareça tão estéril e comercial quanto o gerenciador de arquivos do Windows, mas que mantenha sua
facilidade de uso. Tornar a interface atraente é principalmente uma questão de arte bem concebida, mas
torná-la atraente sem perder nada de sua intuitividade e funcionalidade pode ser bastante desafiador.
Sempre que um artista sugere fazer um botão parecer de uma determinada maneira, o designer deve
considerar se o novo design tira a capacidade do jogador de entender como esse botão funciona. Muitas
vezes, você pode emprestar ícones claramente entendidos de outras interfaces, seja de outros jogos ou
de dispositivos do mundo real, como videocassetes ou CD players. Por exemplo, todos sabem como é um
símbolo de “avanço rápido” em um dispositivo de áudio, e usá-lo adequadamente em seu jogo significará
que os jogadores saberão instantaneamente o que um determinado botão faz. Criar botões em seu jogo
que os jogadores possam entender intuitivamente e que também pareçam atraentes é igual a criatividade
e teste de jogo. Se a maioria das pessoas testando seu jogo disser que seus botões não são óbvios e
confusos, eles quase definitivamente são, e você precisa retornar à prancheta.
Um erro comum de design de jogos é tentar incluir demais. Isso se aplica a todos os aspectos da
jogabilidade, mas particularmente aos controles, onde às vezes o clichê “menos é mais” realmente vale.
Toda vez que você adiciona um novo botão ou chave ao seu jogo, você deve se perguntar se a
complexidade que você acabou de adicionar aos controles do jogo vale a funcionalidade que ele permite.
Ao projetar um jogo para PC, a tentação é particularmente grande, pois o teclado fornece mais teclas do
que qualquer jogo precisaria usar.
Infelizmente, alguns jogos tentaram usar quase todos eles, vinculando algumas funções exclusivas a
praticamente todas as teclas. Controles de teclado complexos favorecem jogadores experientes enquanto
alienam os novatos, levando a um número radicalmente reduzido de pessoas que podem gostar do seu
jogo. Devido ao número limitado de botões que eles fornecem, os pads de controle do console são muito
mais limitantes no que permitirão ao designer configurar.
Ao contrário de muitos outros designers, particularmente aqueles que estão mudando do PC para
o console, muitas vezes sinto que essa limitação é boa. Pads de controle forçam o designer a
refinar seus controles, cortar tudo o que é estranho e combinar todas as ações do mundo do jogo
que os jogadores podem realizar em apenas alguns controles focados. Isso leva diretamente a
jogos que são mais fáceis de aprender a jogar. De fato, muitos dos jogos de console mais acessíveis
nem usam todos os botões do controle. Por causa do enorme teclado à sua disposição, os designers
de jogos para PC não são forçados a focar os controles de seus jogos da mesma maneira, e acho
que seus jogos podem sofrer por isso. Como mencionei acima, alguns dos jogos de PC mais
populares conseguiram espremer todos os seus controles principais no mouse.
Grande parte da crescente complexidade dos controles do jogo pode ser atribuída ao crescente
domínio dos jogos RT3D. Esses jogos, ao tentar incluir a habilidade do substituto do mundo de jogo
do jogador se mover para frente e para trás, para cima e para baixo, para a esquerda e para a
direita, virar para a esquerda e para a direita, e arremessar para cima e para baixo, já usaram um
grande número de controles enquanto permite apenas que os jogadores se movam no mundo do
jogo e não façam mais nada. De muitas maneiras, a maneira perfeita de controlar de forma simples
e intuitiva um personagem com total liberdade no espaço 3D ainda está sendo explorada. É por
isso que, por algum tempo, muito poucos dos jogos 3D de sucesso lançados permitiram aos
jogadores total liberdade para controlar seu personagem. Com o sucesso do console de jogos
complexos de tiro em primeira pessoa, como Halo e Medal of Honor: Frontlines, os jogadores
parecem ter se acostumado com as complexidades de se mover livremente e olhar ao redor em um ambient
No entanto, para permitir aos jogadores uma chance de luta, os jogos 3D mais populares, como
The Legend of Zelda: The Wind Waker, Max Payne, Grand Theft Auto III e Tomb Raider, continuam
a restringir o movimento do personagem do jogador a um plano terrestre. .
StarCraft oferece ao
jogador uma interface
muito elegante que lhe
permite dar ordens às
suas unidades usando
uma variedade de técnicas.
Uma técnica que pode ser usada para tornar seus controles intuitivos para uma variedade de
jogadores é incluir várias maneiras de obter o mesmo efeito. Por exemplo, se olharmos para a
interface usada pelo jogo RTS StarCraft, os jogadores podem controlar suas unidades clicando com
o botão esquerdo para selecionar a unidade, clicando no botão da ação que desejam que a unidade
execute e depois -clicando em um local no mundo onde eles querem que o
unidade para realizar essa ação. Os jogadores também podem clicar com o botão esquerdo na
unidade para selecioná-la e, em seguida, clicar imediatamente com o botão direito no mundo do
jogo, fazendo com que a unidade faça a ação mais lógica para o local em que os jogadores clicaram,
seja movendo-se para aquele ponto ou atacando o unidade lá. Além disso, StarCraft também permite
que os jogadores acessem as diferentes ações de uma unidade por meio de uma tecla de atalho
em vez de clicar no botão. Isso tem o efeito colateral agradável de manter a interface simples o
suficiente para os jogadores iniciantes, já que tudo é apontar e clicar, enquanto os jogadores
experientes podem gastar seu tempo memorizando teclas de atalho para melhorar seu jogo. Em
muitos jogos de ação de console, diferentes, mas toneladas no controle, executarão a mesma ação.
Uma escolha comum a ser feita, particularmente nos jogos de PlayStation, é permitir que os
jogadores controlem o movimento do personagem através do direcional esquerdo ou através do
controle analógico esquerdo. Crash Bandicoot, por exemplo, permite que os jogadores se movam
com o direcional ou o analógico, e também permite que os jogadores acessem a capacidade de
Crash de deslizar pressionando um botão de gatilho ou um dos botões na parte superior do controle.
Fornecer várias maneiras para os jogadores alcançarem uma única ação no mundo do jogo ajuda a
garantir que um determinado jogador goste de usar uma das maneiras que você forneceu.
Há muito espaço para criatividade no design de jogos, mas o design de controle não é uma das
melhores áreas para exercitar seus impulsos criativos. Seu jogo deve ser criativo em sua jogabilidade,
enredo e outros conteúdos, mas não necessariamente em seus controles. Alguns dos jogos de
maior sucesso adotaram esquemas de controle com os quais os jogadores já estavam familiarizados
de outros jogos e os aplicaram a conteúdo novo e atraente. Às vezes, o esquema de controle
estabelecido pode ser fraco, mas muitas vezes não é fraco o suficiente para justificar a mudança em
uma direção inteiramente nova com seu próprio sistema de controle. Como designer, você deve
pesar o que é ganho através de um esquema de controle marginalmente superior com o que é
perdido por causa da confusão do jogador. Por exemplo, o belo jogo RTS de Sid Meier, Gettysburg!
incluído como seu método padrão para ordenar tropas em torno de um sistema de “clique e arraste”
em vez do sistema estabelecido de “clique e clique” encontrado em outros jogos. Seu sistema era
bastante criativo e, na verdade, pode ter sido uma maneira melhor de controlar o jogo do que os
paradigmas estabelecidos. No entanto, não foi muito melhor que superasse a confusão que os
jogadores experimentaram ao tentar jogar o jogo pela primeira vez, fato que ele admite na entrevista
incluída no Capítulo 2 deste livro. Os jogos de console são particularmente bons em fornecer
esquemas de controle uniformes, com os fãs de jogos de um gênero específico capazes de pegar e
começar imediatamente a jogar quase qualquer jogo disponível no gênero, mesmo que nunca o
tenham visto antes.
Durante o desenvolvimento de um jogo, à medida que você joga o jogo repetidamente, é muito
fácil se acostumar com controles ruins. Embora os controles possam ser mal definidos ou contra-
intuitivos, como designer de um jogo trabalhando em um projeto por vários anos, você pode ter
usado tanto os controles que eles se tornaram uma segunda natureza. No entanto, assim que os
outros jogarem pela primeira vez, eles ficarão rapidamente frustrados com esses controles e
provavelmente pararão de jogar como resultado. De fato, quando executei Drakan: The Ancients'
Gates alguns anos depois de lançado, fiquei imediatamente surpreso com o quão bizarros e
desorientadores eram os controles, particularmente a capacidade de olhar para a esquerda e para
a direita no analógico direito do PS2. Outros membros da equipe que mostrei ficaram igualmente
chocados. “Nós enviamos assim?” eles disseram incrédulos. Ao longo de três anos desenvolvendo
o jogo, nos familiarizamos com as esquisitices do jogo e os controles pareciam fantásticos. Com
alguma distância
entre nós e o jogo, pudemos ver seus problemas de controle gritantes.

Idealmente, uma fase de teste de jogo adequada incluirá muitos jogadores jogando o jogo pela
primeira vez, e testemunhar sua reação inicial aos controles é crucial para entender como seus
controles realmente são intuitivos. Não pense: “Ah, ela vai se acostumar” ou “Que idiota! Esses
controles são óbvios; por que ela não pode ver isso!” ou “Bem, eu gosto deles do jeito que são”.
Em vez disso, pense: “Por que meus controles são ruins e o que posso fazer para corrigi-los?”
Projetar controles que os jogadores acharão intuitivos pode ser bastante desafiador,
especialmente com uma variedade de configurações de controle para diferentes jogos,
principalmente no mercado de PCs. Por exemplo, quando o gênero FPS estava se estabelecendo
pela primeira vez, era difícil determinar quais deveriam ser os controles “padrão” para um FPS, já
que os últimos três jogos FPS bem-sucedidos empregavam esquemas de controle exclusivos.
Felizmente, com o tempo, os controles se tornaram padronizados e agora os fãs de tiroteio podem
facilmente pular em quase qualquer FPS que encontrarem. Quase todos os jogos de ação para PC
lançados na última década permitem que os jogadores configurem os controles da maneira que
desejarem, e isso é uma necessidade absoluta para qualquer jogo de PC que exija que os
jogadores manipulem um grande número de botões. Dito isto, muitos jogadores nunca encontram
ou usam as telas de configuração de controle, seja pelo desejo de começar a jogar o jogo
imediatamente ou por uma falta geral de conhecimento com o computador. Muitos, muitos
jogadores ficarão jogando com quaisquer que sejam as teclas padrão, e é por isso que é trabalho
do designer garantir que essas configurações padrão sejam tão jogáveis quanto possível. Aqui,
seguir o padrão estabelecido pela maioria dos outros jogos é muito importante. Você nunca deve
usar um conjunto estranho ou confuso de controles padrão para o seu jogo simplesmente porque
o programador responsável gosta dessa forma ou a equipe se acostumou a eles. Certifique-se
sempre de que os controles padrão sejam o mais intuitivos possível e, se isso envolver uma imitação desca
Quando a tentativa
de ter controles únicos
não funcionou como
planejado, The Suffering
foi alterado para emular
sistemas de controle de
outros jogos.
Fazer um jogo em um gênero estabelecido é uma coisa, mas quando se trata de desenvolver
um jogo que tenta fazer algo substancialmente novo com as ações que os jogadores podem
realizar, não há como evitar gastar muito tempo nos controles. Depois de obtê-los para que você
goste deles, você deve colocá-los na frente dos jogadores para ver como eles funcionam na prática
em vez da teoria. Experimentar novos estilos de controle é um esforço nobre,
mas você precisará ter certeza de que os jogadores realmente os preferem aos métodos mais
tradicionais. E à medida que você coleta o feedback deles, a iteração de longo prazo é quase
inevitável. Um exemplo disso aconteceu no meu jogo The Suffering. O jogo era um shooter e
queríamos torná-lo o mais amigável possível para os consoles, e assim tomamos Devil May Cry
como fonte de inspiração. Ao mesmo tempo, queríamos que os jogadores tivessem a liberdade de
se mover pelo ambiente e posicionar e orientar suas câmeras como em jogos de tiro em primeira
pessoa ou, especificamente, Syphon Filter e nosso próprio Drakan: The Ancients' Gates. Por isso,
desenvolvemos um sistema de mira híbrido que proporcionava aos jogadores movimentos intuitivos
pelo mundo com um único polegar, mas depois permitia o simples direcionamento dos inimigos.
Passamos muito tempo desenvolvendo este sistema e iterando nele, e sentimos que tínhamos
feito um bom trabalho. Então começamos a ouvir reclamações de colegas desenvolvedores para
quem mostramos o jogo que os controles pareciam estranhos. Quando finalmente colocamos o
jogo na frente dos jogadores, seu feedback quase universalmente mencionou os controles como o
que eles menos gostaram no jogo. Tentamos ajustá-lo um pouco mais, mostramos a mais alguns
jogadores e descobrimos que os controles ainda pareciam estranhos. Neste ponto, estávamos
bastante avançados no desenvolvimento e percebemos que o esquema de controle inovador que
tentamos simplesmente não estava funcionando. Como era o sistema de controle com o qual
estávamos tendo problemas, decidimos que fazia mais sentido imitar alguns esquemas de controle
existentes. Queríamos algo poderoso com o qual sabíamos que os jogadores estariam
familiarizados, então copiamos o esquema de dois analógicos que a maioria dos outros shooters
de console atuais, incluindo Max Payne e Halo, estavam usando. Nesse ponto estávamos imitando
em vez de inovar, mas quando colocamos o jogo na frente dos jogadores novamente com nosso
novo esquema de controle, quase todos elogiaram a qualidade de nossos controles e depois
puderam focar suas reclamações em outros aspectos do jogo .
Particularmente em jogos de ação, quando seus controles são perfeitos, a parede que separa
os jogadores do mundo do jogo desaparecerá e eles começarão a sentir que realmente são o
personagem do mundo do jogo. Este é o sinal final de um jogo imersivo, e alcançar esse efeito é
impossível sem controles fortes. Em um jogo onde esse nível de imersão é possível, os controles
devem ser completamente invisíveis para os jogadores. Isso pode ser frustrante para um designer.
Por que trabalhar tanto em algo que, se implementado perfeitamente, será completamente invisível?
O designer deve perceber que é a transparência dos controles que permite aos jogadores aproveitar
o resto do que o jogo tem a oferecer.
Saída e feedback do mundo do jogo

Embora a capacidade do jogador de controlar intuitivamente o mundo do jogo possa ser a chave
para um jogo bem-sucedido, a saída de informações vitais sobre esse mundo do jogo para os
jogadores é igualmente importante. Os jogos de computador contêm vários sistemas complexos,
geralmente realizando mais cálculos do que um ser humano jamais seria capaz de rastrear. Na
verdade, essa é a área onde os jogos de computador se destacam. Condensar essa enorme
quantidade de dados em sua forma mais instrutiva e comunicar essa informação aos jogadores é
a chave para um sistema de saída bem projetado.
Considere um jogo de estratégia em que os jogadores têm várias unidades espalhadas por
todo um grande mapa. O mapa é tão grande que apenas uma pequena parte dele pode caber na
tela de uma só vez. Se um grupo de unidades dos jogadores estiver fora da tela e for atacado, mas
os jogadores não forem informados disso pelo jogo, os jogadores ficarão irritados. Considere um
RPG onde cada membro do grupo dos jogadores precisa ser alimentado regularmente, mas o jogo não
fornece nenhuma maneira clara de comunicar facilmente a fome de seus personagens. Então, se um
dos membros do grupo de repente desmaiar de fome, os jogadores ficarão frustrados, e com razão. Por
que os jogadores teriam que adivinhar ou cavar para obter essas informações críticas do jogo? Em um
jogo de ação, se os jogadores tiverem que matar um inimigo atirando em um local específico de seu
corpo, digamos, seu olho, eles precisam receber feedback positivo quando acertarem um golpe com
sucesso. Talvez o inimigo recue de dor ou grite de agonia quando um ataque o danifica. Se os jogadores
não recebem esse feedback, como eles podem saber que estão no caminho certo? É claro que todos
os jogos de computador ocultam uma certa quantidade de informações dos jogadores e não podem
comunicar aos jogadores todas as informações que eles têm sobre o mundo do jogo.
Mas eles devem comunicar o que é razoável e importante para os jogadores saberem e comunicar
esses dados de forma eficaz.
Quase todos os jogos apresentam aos jogadores uma visão do mundo do jogo como a parte
central de seu sistema de saída. Através desta visão, os jogadores veem o objeto que estão controlando
no momento e sua localização e estado no mundo do jogo. Seu jogo deve tentar comunicar o máximo
de informações possível por meio dessa visualização. Considere um jogo de ação 3D em terceira
pessoa. Certamente os jogadores veem o ambiente e a posição de seu substituto no mundo do jogo,
mas e a condição do personagem do jogador? Talvez à medida que sua saúde caia, as animações do
personagem mudem para mancar ou mancar em vez de se mover normalmente. Da mesma forma, a
força da armadura atual pode ser representada por mudanças de textura nesse personagem, com a
armadura parecendo cada vez mais deteriorada à medida que sofre dano e se aproxima da destruição.
O jogo pode representar a arma atual do personagem mostrando aquela arma equipada no personagem.
Se os jogadores tiverem um feitiço de proteção atualmente em vigor em seu personagem, talvez o
personagem deva emitir um certo brilho para comunicar isso facilmente. Embora o designer também
queira incluir esses dados em algum tipo de exibição de heads-up (HUD), comunicá-los através da visão
principal do mundo do jogo o torna muito mais transparente e fácil de entender para os jogadores.
O que a visão do mundo do jogo não pode representar normalmente está contido em algum tipo
de GUI, que geralmente faz fronteira com a visão do mundo do jogo ou é sobreposta a ela como um HUD.
Essa GUI pode ser simples, como a exibição de alta pontuação e vidas restantes no Centi pede, a
pequena exibição de saúde de poções na parte inferior da tela no Prince of Persia original ou a exibição
de pontuação/movimentos em quase todos os jogos da Infocom . Para jogos mais complicados, a GUI
também é mais complexa, como as barras de botões usadas em qualquer um dos jogos Sim da Maxis ,
a elaborada exibição de status no System Shock original ou os extensos dados de grupo fornecidos em
muitos RPGs, como o Bard's Jogos de contos . Muitas GUIs em jogos mais antigos foram criadas para
bloquear uma grande parte da tela. Isso não foi por causa de qualquer tipo de decisão de design, mas
sim porque o mecanismo do jogo não foi rápido o suficiente para processar a tela cheia do mundo do
jogo. À medida que a tecnologia do motor melhorou, os jogos tentaram fazer com que a visão do mundo
do jogo ocupasse a maior parte da tela, com a GUI minimizada o máximo possível.
Alguns jogos tentam funcionar sem qualquer GUI. Crash Bandicoot, por exemplo, só exibe as vidas
restantes da GUI se os jogadores pressionarem um botão para trazê-lo para a tela; caso contrário, uma
visão completamente desobstruída do mundo é exibida.
Outro exemplo é Oddworld: Abe's Oddysee. O diretor do jogo, Lorne Lanning, sentiu
Oddworld: O
Oddysee de Abe eliminou
completamente uma GUI
no jogo, dando ao jogador
uma visão desobstruída
do mundo do jogo.
fortemente que qualquer tipo de GUI distanciaria os jogadores do mundo do jogo. Como
resultado, a saúde de Abe é comunicada aos jogadores através da forma como ele anima. Como
o jogo concede aos jogadores vidas infinitas, não havia necessidade de uma exibição de vidas
restantes que tantos jogos de plataforma de console da época incluíam como seu único elemento HUD.
Certamente, como a tecnologia permitiu, a tendência tem sido se afastar o máximo possível dos
HUDs na tela, permitindo que a visão do mundo do jogo tome conta da tela. As vantagens da
imersão adquirida por uma GUI minimizada são óbvias e, se o mundo do jogo puder comunicar
efetivamente todas as informações que os jogadores precisam para jogar, às vezes não há
razão para usar uma GUI.
Por outro lado, é importante não ir muito longe na busca para eliminar uma GUI.
Em geral, um HUD pequeno e discreto é uma convenção de jogo com a qual os jogadores se
acostumaram e, portanto, dificilmente serão incomodados. Embora não ter HUD tenha
funcionado muito bem nos jogos Oddworld , The Getaway é um jogo divertido que sofreu por
causa da decisão do desenvolvedor de evitar um HUD. Dirigir por Londres era desnecessariamente
difícil porque, em vez de ter um mapa HUD, os jogadores eram forçados a navegar até seu
destino fazendo curvas com base nas dicas dos sinais de direção piscantes em seu carro. Este
era um sistema particularmente imperfeito e irritante ao navegar pelas ruas labirínticas de
Londres. Da mesma forma, o jogo não tem medidor de saúde, e os jogadores são obrigados a
usar uma mudança de textura de jogador consideravelmente menos precisa e bastante sutil
para descobrir o estado de saúde de seu personagem. Dada a mecânica de tiro e direção do
jogo, deixar de fora o HUD prejudicou a jogabilidade muito além da imersão que foi conquistada.
A parte mais importante de projetar uma GUI é tentar mantê-la o mais visual possível.
Em jogos de ação de ritmo acelerado em particular, a GUI é projetada para comunicar
informações aos jogadores muito rapidamente, seja a saúde atual dos jogadores, munição
disponível ou monstros próximos (através de algum tipo de radar). Se alguma coisa, a
ascendência da interface gráfica do usuário como o modo dominante de controlar um
computador, primeiro através do Macintosh e posteriormente através do Windows, mostra que
a maioria das pessoas pensa visualmente em vez de em números ou palavras. Como resultado,
um HUD gráfico bem projetado em seu jogo será mais fácil para os jogadores olharem e entenderem do que
contém muitos números ou palavras. Isso explica a superioridade da barra de integridade sobre um
número ou porcentagem de integridade. Os artistas também vão gostar de um HUD gráfico, já que uma
barra de saúde pode parecer muito mais atraente do que um número grande e feio. Embora alguma
quantidade de precisão seja perdida com uma barra de saúde menos precisa, os jogadores estão
dispostos a sacrificar isso porque a barra é muito mais fácil de ler rapidamente.
A cabeça na parte
inferior da tela em Doom
é um elemento de
interface bem projetado
porque comunica
visualmente a saúde
atual do jogador.
Um elemento de jogo particularmente bem desenhado é a “cabeça” usada em Doom e Quake.

Este rosto, que aparece no centro da parte inferior da tela, representa a saúde aproximada dos
jogadores de forma totalmente visual. O rosto começa saudável e rosnando, pronto para enfrentar o
mundo. À medida que os jogadores progridem e perdem saúde, a cabeça começa a parecer machucada
e ensanguentada, eventualmente parecendo quase morta quando os jogadores estão quase sem saúde.
A qualquer momento durante o jogo, os jogadores podem olhar para a cabeça e instantaneamente ter
uma noção de quanta saúde eles ainda têm. Se a saúde tivesse sido representada por um número, teria
sido muito mais difícil para os jogadores compreenderem seu nível de saúde atual apenas olhando para
ele. A diferença de tempo pode ser de milissegundos, mas em um jogo de ação rápida, essa pode ser a
diferença entre a vida e a morte.
É claro que a representação visual dos dados também pode ter um efeito colateral negativo se
essa representação for muito obtusa para os jogadores entenderem facilmente. Por exemplo, em
WarCraft, os botões para as diferentes ações que uma unidade pode realizar são todos representados
por ícones, o que eu geralmente encorajaria. No entanto, alguns dos botões podem ser um pouco
difíceis de descobrir no início. Felizmente, o jogo também exibe texto na parte inferior da tela quando o
cursor do mouse dos jogadores passa sobre um botão específico, comunicando o que esse botão fará
se for clicado. O que teria sido ainda melhor é se os ícones nos botões fossem um pouco mais óbvios.
É certo que representar uma ação do mundo real como “guarda” através de um ícone de 32 x 32 pode
ser um grande desafio. A GUI do seu jogo precisa equilibrar a superioridade da representação visual
com a clareza do texto, possivelmente usando uma combinação de ambos conforme necessário.
A saída de áudio como dispositivo de comunicação com os jogadores é algo que muitas vezes é
subutilizado nos jogos. Nem todas as informações sobre o mundo do jogo precisam ser comunicadas
aos jogadores por meio de estímulos visuais. Por exemplo, no The Sims, os jogadores têm uma boa
noção se seu personagem está gostando de uma determinada conversa com base em
o tom de voz dos participantes. No Command & Conquer, os jogadores sabem que uma unidade
recebeu uma ordem específica por meio de uma dica de áudio fornecida por essa unidade: “Vou
começar logo!” Da mesma forma, quando unidades fora da tela estão sendo atacadas, o jogo comunica
isso aos jogadores dizendo “Unidade atacada” ou “Unidade perdida”. As pistas de áudio podem fornecer
um excelente complemento às informações na tela ou podem funcionar de maneira bastante eficaz
como a única maneira de comunicar informações críticas.
Um bom sistema de saída para um jogo é poderoso e intuitivo. Ele permite que os jogadores
entrem direto no jogo e entendam o que está acontecendo no mundo do jogo, mas também fornece aos
jogadores experientes todas as informações de que precisam para jogar o jogo de forma eficaz. Com o
tempo, os dados que o jogo comunica aos jogadores devem se tornar transparentes, assim como os
controles dos jogadores devem se tornar invisíveis quando os jogadores estiverem familiarizados com
eles. Os jogadores não deveriam ter que pensar em entender o estado do mundo; eles devem apenas
recuperar o que precisam olhando rapidamente para a tela e, em seguida, ser capazes de reagir a ela
com a mesma rapidez por meio de controles intuitivos e responsivos.
Como afirmei antes, é importante não ser muito criativo no desenvolvimento de seus sistemas de
entrada/saída. Os paradigmas dominantes de outros jogos costumam ser dominantes por uma razão:
eles funcionam. A expressão de que “bons artistas emprestam, mas grandes artistas roubam” não é
mais verdadeira do que no design de I/O em jogos.
Elementos básicos
Neste capítulo, discuti apenas alguns dos elementos de uma boa jogabilidade: soluções únicas, não
linearidade, modelagem da realidade, ensino dos jogadores e entrada/saída. Eu sinto que cada um
desses componentes merece uma reflexão séria quando você se propõe a desenvolver um jogo.
Claro, isso está longe de ser uma lista completa, e como você trabalha como designer de jogos, você
acumulará sua própria lista pessoal de elementos que você acha que contribuem para uma boa
jogabilidade. Ninguém pode dizer com certeza quais são os elementos de um bom design de jogo.
Cada designer de jogos deve decidir isso por si mesmo. Essa preferência pessoal faz parte do que faz
com que cada jogo tenha a marca distinta de seu autor e confere aos melhores jogos a individualidade
que os torna grandes.
Capítulo 8
Análise do jogo:
Tetris
Projetado por Alexey Pajitnov
Lançado em 1987
quando um jogo se torna tão popular quanto o Tetris , com versões para cada sistema
Poucos milhões
jogos sãoimagináveis
tão universalmente respeitados
e incontáveis empelos desenvolvedores
vendas, de jogosde
os profissionais quanto
jogosTetris.
começamFrequentemente
a
reclamar sobre o quão ruim é o jogo. Myst é um bom exemplo disso. Em seu lançamento, o título
recebeu elogios quase universais da imprensa de jogos por ser um divertido jogo de aventura em
um mundo lindamente concebido. Os próprios desenvolvedores de jogos, embora não tão
entusiasmados, ainda achavam que era um bom jogo. Vários milhões de cópias depois, com anos
passados nas paradas de best-sellers, a mesma imprensa de jogos encontrou motivos para
começar a odiar o jogo e sua incrível popularidade contínua. Os desenvolvedores de jogos são
particularmente barulhentos ao expressar sua antipatia pelo jogo. O jogo está pior agora? Não, claro que n
141
142 Capítulo 8: Análise do jogo: Tetris
profissionais de jogos, imprensa e desenvolvedores, se ressentem do jogo por suas vendas? Parece que sim.
Mas este não é o caso do Tetris. Tetris conquistou o mundo em termos de popularidade, mas é difícil
encontrar alguém com um comentário negativo sobre o jogo.
O que há no Tetris que torna o jogo imune a críticas? Parece que alguma coisa sobre a simplicidade do jogo
e a clareza da visão do design fazem até o desenvolvedor de jogos mais cínico admitir a grandeza do jogo. Ao
contrário do que aconteceu com Myst, quando Tetris foi lançado pela primeira vez, a maior parte da imprensa
de jogos se debruçou sobre as origens do jogo na Rússia e parecia desapontada, ou pelo menos desanimada,
com a jogabilidade do título. O jogo era tão simples, sua tecnologia tão carente de deslumbramento que,
talvez, a imprensa se viu incapaz de escrever com entusiasmo sobre o jogo – pelo menos no início. Agora que
o jogo é um clássico indiscutível, qualquer crítico de jogos ficará feliz em falar sobre as centenas de horas que
ele passou felizmente perdido no jogo.
A jogabilidade em Tetris é extremamente descomplicada. O mundo do jogo é uma caixa 2D alta e

retangular. Os blocos aparecem na parte superior da caixa. Os blocos são compostos de quatro quadrados
dispostos em todos os padrões possíveis, onde todos os quadrados compartilham pelo menos um lado com
outro quadrado. Os blocos então caem lentamente para o fundo da caixa, e os jogadores podem mover esses
blocos para a esquerda e para a direita, ou girar a peça em incrementos de 90 graus. Quando o bloco atinge
uma obstrução, seja no fundo da caixa ou em outra peça, o bloco para de se mover, os jogadores perdem o
controle do bloco e outra peça que os jogadores podem controlar agora aparece na parte superior da tela.
Quando os blocos na parte inferior da tela formam uma linha horizontal ao longo do retângulo, essa linha de
quadrados desaparece e quaisquer quadrados acima dessa linha descem uma linha. O jogo dos jogadores
termina quando as linhas incompletas dos blocos preenchem o retângulo do mundo do jogo e as peças
subsequentes são impedidas de entrar no campo de jogo.
Jogo de quebra-cabeça ou jogo de ação?

Tetris é muitas vezes referido como um jogo de quebra-cabeça, e por boas razões. Tetris tem elementos
obviamente que lembram um quebra-cabeça, com os jogadores precisando descobrir como os blocos se
encaixam melhor. Desta forma, o jogo é semelhante a um quebra-cabeça de ângulo reto, ou qualquer outro
quebra-cabeça “organizar essas formas geométricas neste pequeno espaço”. Uma comparação ainda melhor
seria o jogo tradicional pentomino, do qual Alexey Pajitnov, designer de Tetris , supostamente se inspirou. No
pentomino, deve-se pegar doze peças de formas diferentes, cada uma composta de cinco quadrados, e
encaixá-las em uma caixa quadrada. Pode-se ver as semelhanças, mas ao mesmo tempo Tetris transforma o
jogo em algo totalmente diferente, algo totalmente mais desafiador e atraente.
Pajitnov poderia ter feito uma adaptação direta do pentomino para o computador com a mesma facilidade,
como muitos outros desenvolvedores fizeram para quebra-cabeças ou quebra-cabeças do tipo “número
deslizante”. Este pode ter sido um programa divertido, embora talvez não tão divertido quanto o próprio jogo,
já que parte da diversão do pentomino é a natureza tátil de manipular os blocos. Mas ao pegar o quebra-
cabeça e transformá-lo em um jogo que só poderia acontecer no computador, Pajitnov acabou criando um
novo jogo único e muito mais divertido que o original.
Muitas vezes, quando membros da intelligentsia de jogos de computador se referem a um jogo como
sendo um jogo de quebra-cabeça, eles o fazem com escárnio. Para eles, um jogo de quebra-cabeça é aquele que
Capítulo 8: Análise do jogo: Tetris 143
Tetris equilibra
cuidadosamente elementos
de ação e quebra-cabeça
para criar uma experiência
de jogo única. Retratado
aqui, e ao longo deste
capítulo: modo clássico em
The Next Tetris.
apresenta uma série de quebra-cabeças estáticos para os jogadores, quebra-cabeças que nunca
mudam e nunca reagem às ações dos jogadores. Eles argumentam que um jogo deve fornecer uma
reação às ações dos jogadores e um oponente para os jogadores competirem. Portanto, diriam os
críticos, esses chamados “jogos de quebra-cabeça” não são realmente jogos, mas apenas quebra-
cabeças. Além disso, muitas vezes os quebra-cabeças encontrados nesses jogos têm apenas uma
solução, limitando ainda mais a experiência interativa dos jogadores. Exemplos incluem quase todos
os jogos de aventura, como Zork, Myst ou mesmo Grim Fandango, jogos que, embora forneçam aos
jogadores um mundo para explorar e quebra-cabeças desafiadores para completar, não fazem nada
para criar uma experiência única para os jogadores.
Mas Tetrisis nunca foi criticado por essa falha porque combina de forma brilhante a mecânica de
um jogo de quebra-cabeça com a mecânica de um jogo de ação para criar uma experiência de jogo
verdadeiramente atraente. Assim, todos que jogam Tetris, cada vez que jogam, têm uma experiência
única. Uma mecânica de jogo de ação que Tetris usa é a sensação de uma ameaça cada vez mais
próxima que os jogadores precisam enfrentar em um período limitado de tempo. Assim como a maior
parte da ficção gira em torno da tensão dramática, os jogos também, e Tetris não é exceção. Em
Centipede , essa ameaça é o artrópode descendo do topo da tela. Em Tetris é o bloco caindo de cima.
Se os jogadores não se moverem e girarem, bem como determinarem um posicionamento ideal para
a peça antes que ela atinja a parte inferior da tela, ela pode ficar presa em um local que impede que
as linhas inferiores sejam concluídas e os jogadores aproximam uma ou mais linhas para terminar seu
jogo. À medida que o jogo avança, a velocidade com que esses blocos caem do topo da tela aumenta,
aumentando assim o desafio para os jogadores e aumentando a dificuldade ao longo do jogo.
Outra semelhança entre Tetris e jogos de ação que o distingue ainda mais de outros jogos de
quebra-cabeça é a variedade de situações de jogo que Tetris pode criar: cada jogo jogado é único. A
mecânica do jogo configura um número infinitamente grande de jogos únicos, com cada movimento
que os jogadores decidem fazer influenciando o resto do jogo. A forma como uma peça é posicionada
nos blocos já na parte inferior da tela impacta diretamente onde a próxima peça pode ser colocada.
Os jogadores devem preencher os quatro quarteirões
slot com apenas dois blocos de uma peça em forma de “L” de cabeça para baixo? Ou eles deveriam
aguentar, esperando por aquela peça em forma de “eu” desesperadamente necessária? O “L” não
preencherá completamente o slot, mas ninguém sabe quanto tempo levará até que a peça “I” chegue.
Em outros casos, os jogadores podem ter várias posições diferentes para colocar uma peça e devem
pensar no futuro, descobrindo se colocarem uma peça em um determinado slot, que tipo de slots
deixarão disponíveis para peças posteriores. Os jogadores constantemente precisam considerar onde
os blocos futuros poderão ou não se encaixar. Os jogadores podem aprender a reconhecer certas
configurações de peças, mas cada jogo é tão único que nenhum jogador pode estar completamente
preparado para os desafios que podem enfrentar.
Tetris como um jogo de arcade clássico
Apesar de ter sido

desenvolvido anos após os
jogos de arcade clássicos
terem saído de moda, a
jogabilidade de Tetris
incorpora muitos dos
princípios de design desse gênero de jogos.
Há muitas indicações de que Tetris é um exemplo do que chamo de forma de “jogo de arcade
clássico”. Isso ocorre apesar do fato de que ele não foi originalmente concebido para jogabilidade nos
arcades (embora sua popularidade desenfreada eventualmente tenha levado à sua chegada lá), e
que foi criado anos após a forma clássica de jogo de arcade ter parado de ser usada por
desenvolvedores profissionais de jogos de arcade. . Examinando a lista de qualidades clássicas de
jogos de arcade descritas na análise Centipede no Capítulo 4, podemos ver como Tetris se encaixa
nos princípios orientadores da forma. • Single Screen Play: Claro, Tetris ocorre em apenas uma tela.
Os jogadores podem ver todo o mundo do jogo de uma só vez e tomar decisões informadas sobre o
que querem fazer com uma determinada peça com base nisso. Não há nenhum componente de
exploração no jogo, nenhuma maneira de realmente surpreender os jogadores (além de qual
peça aparece a seguir), então os jogadores têm todas as informações necessárias para serem
bem-sucedidos no jogo e não têm nada para culpar a não ser eles mesmos pelo fracasso.
• Jogo Infinito: Tetris permite que os jogadores continuem jogando até que, por suas próprias más
decisões, os blocos cheguem ao topo da caixa. Todo jogo termina em derrota, e ninguém pode
realmente dizer que “venceu” o jogo. Os jogadores sempre podem encontrar maneiras de
melhorar sua habilidade de jogar Tetris . Esta é uma diferença crucial entre Tetris e um quebra-
cabeça tradicional. Uma vez que os jogadores tenham resolvido um quebra-cabeça, se eles se
lembrarem de como o fizeram da primeira vez, o quebra-cabeça não apresentará mais nenhum
desafio para eles. As pessoas geralmente não gostam de fazer quebra-cabeças várias vezes,
enquanto um jogo bem projetado pode ser repetido para sempre. Tetris é apenas um desses
jogos. • Múltiplas Vidas: Ao contrário da maioria dos jogos de arcade clássicos, a implementação
original do Tetris oferece apenas uma vida aos jogadores. Quando os blocos atingem o topo da
caixa, o jogo dos jogadores termina. O design do jogo, no entanto, permite que os jogadores
vejam que estão indo mal sem derrotá-los instantaneamente. À medida que os blocos se
empilham na parte inferior do retângulo, os jogadores veem os erros que estão cometendo e
têm tempo para descobrir como alinhar melhor os blocos antes que o jogo termine. Portanto,
embora o Tetris não ofereça aos jogadores várias vidas, ele dá a eles a chance de aprender o
jogo bem o suficiente para alcançar alguns sucessos menores antes de forçá-los a recomeçar. •
Pontuação/Pontuações mais altas: Tetris usa um modelo para dar uma pontuação aos jogadores e
registrá-la em uma tabela de pontuação, que é retirada diretamente do sistema usado em jogos
como Asteroids ou Galaga. De fato, como o jogo não pode ser derrotado, é a possibilidade de
alcançar uma pontuação mais alta que pode se tornar o verdadeiro ímpeto dos jogadores para
jogar novamente.
• Jogabilidade simples e fácil de aprender: Tetris realmente se destaca em quão simples e óbvias
são suas mecânicas de jogo. Os jogadores realmente só precisam de três botões para jogar o
jogo com sucesso, e todos eles se traduzem em resultados óbvios na tela. Isso significa que
praticamente qualquer pessoa, independentemente de quão familiarizada com os jogos de
computador, pode ir até o jogo e começar a jogá-lo imediatamente. No entanto, os jogadores
nunca serão capazes de dominar completamente o jogo devido à dificuldade crescente do jogo
e ao potencial para jogos infinitamente longos.
• Sem história: Tetris tem ainda menos história do que a maioria dos jogos de arcade clássicos, e é o
caso mais citado por pessoas que querem salientar que os jogos não precisam de histórias para
serem atraentes para os jogadores. O único tipo de cenário que Tetris tem é sua origem na
Rússia, que tem sido usada para vários efeitos estéticos nas diferentes encarnações do jogo. A
primeira versão para PC do jogo, publicada pela Spectrum Holobyte, incluía cenários por trás da
jogabilidade que envolviam diferentes cenas da vida russa, e a música soava vagamente eslava
na origem. Mas uma vez que as pessoas aprenderam o que era um ótimo jogo Tetris , as
implementações subsequentes do jogo, como a do Nintendo GameBoy, não tinham tema russo
para elas e não tinham cenário ou história. O jogo não sofreu nem um pouco por essa falta de
história.
De fato, a total falta de cenário de Tetris pode ser algo que o separa dos jogos de arcade
clássicos, que tentaram se basear em algum tipo de mundo de fantasia, seja no espaço sideral
em Galaga, insetos em um jardim em Centipede , ou fantasmas descolados perseguindo um
homenzinho amarelo no Pac-Man.
Tetris não tem essas pretensões e, portanto, se destaca.
A tecnologia
Outra semelhança entre Tetris e jogos de arcade clássicos é que nenhum desses jogos dependia
de sua tecnologia para impressionar os jogadores. Para os CAGs, os gráficos que as máquinas de
fliperama no início dos anos 80 podiam produzir eram tão sem brilho em comparação com o que os
jogadores encontrariam em outras mídias, como filmes ou televisão, que os jogadores tiveram que
ser atraídos por outra coisa. Como resultado, a jogabilidade tinha que ser verdadeiramente cativante
para que esses jogos sobrevivessem. Apesar do fato de que gráficos muito mais sofisticados
estavam disponíveis no momento em que Tetris foi lançado no Ocidente no final dos anos 80, o jogo
não precisava de gráficos mais sofisticados e manteve uma implementação 2D muito simples. A
jogabilidade de Tetris é tão forte que não importa quão tecnologicamente simples sua implementação
possa ser, o jogo ainda é muito divertido.
A implementação do Tetris é tão simples que muitos aspirantes a programadores de jogos
começam fazendo um clone do Tetris . De fato, várias empresas tentaram adicionar efeitos gráficos
sofisticados ao jogo, inclusive tornando-o 3D. A primeira delas foi provavelmente Welltris, uma
espécie de sequência de Tetris, projetada por Pajitnov. Em Welltris, um “poço” 3D toma o lugar da
caixa de Tetris . Peças no estilo Tetris (embora nem sempre de quatro blocos) caem ao longo dos
lados do poço e devem ser alinhadas em fileiras na parte inferior. A jogabilidade era consideravelmente
mais complexa sem ser particularmente mais divertida ou desafiadora. Como resultado, os jogadores
não se interessaram e voltaram à simplicidade do original. Muitas imitações subsequentes de Tetris
tentaram fazer “melhorias” no original, seja por meio de efeitos extravagantes ou peças especiais
de vários tipos. Nenhuma dessas tentativas foi particularmente bem-sucedida e os jogadores
continuaram a querer retornar ao original.
As tentativas de adicionar sofisticação tecnológica ao Tetris falharam, não apenas

comercialmente, mas também artisticamente. A tecnologia aprimorada adicionada a esses produtos
falsificados foi realmente prejudicial ao design original do jogo, poluindo sua pureza e fazendo com
que o jogo perdesse sua elegância e diversão no processo. Claro, a moral da história é que a
tecnologia aprimorada não é necessariamente benéfica para um determinado jogo, e os designers
de jogos devem ser cautelosos quando os efeitos do mecanismo de explosão começam a atrapalhar
o que torna o jogo divertido em primeiro lugar. .
Embora o Tetris possa não precisar de muito em termos de tecnologia de computador para
funcionar, vale ressaltar que não poderia haver Tetris sem um computador. Tetris não é um jogo
adaptado de uma caneta e papel ou um jogo de tabuleiro, mas sim algo que só pode existir em um
mundo cuidadosamente controlado e governado por um computador. Como mencionado
anteriormente, diz-se que Pajitnov se inspirou no jogo de quebra-cabeças não-computador
pentomino. Ao adaptá-lo ao computador, Pajitnov o transformou em uma forma que só poderia
existir em um computador. A descida das peças da parte superior da tela em uma taxa constante, a
maneira como elas podem interagir com as peças já na parte inferior da tela e a maneira aleatória
pela qual as peças ficam disponíveis para os jogadores são todas operações apenas de um
computador. programa poderia fornecer enquanto ainda permite uma experiência divertida para os
jogadores. Essas são todas as tarefas que o computador executa habilmente, e foi brilhante da
parte de Pajitnov pensar em adicioná-las ao seu jogo.
Inteligência artificial
Tetris tem uma inteligência
artificial muito limitada que
escolhe aleatoriamente os
blocos que caem no campo
de jogo. Apesar de sua
simplicidade, essa IA
oferece o desafio perfeito
para o jogador.
Tudo o que o jogo tem em termos de IA é o gerador de números aleatórios que escolhe a
próxima peça para entrar no campo de jogo. No entanto, a mecânica do jogo é tal que esse
número aleatório é suficiente para mudar completamente cada jogo, apresentando aos
jogadores desafios únicos após cada peça ser descartada. Como a aleatoriedade garante que
os jogadores nunca saibam qual será a próxima peça, eles são forçados a jogar a peça de
uma maneira ideal para qualquer uma das sete peças que vier a seguir. (Muitas encarnações
do Tetris incluem um recurso “próximo”, que mostra aos jogadores a próxima peça que entrará
no campo de jogo, um recurso que torna o jogo um pouco mais fácil. Mesmo usando isso, os
jogadores ainda não sabem qual será a próxima peça, portanto, eles ainda estão apenas
fazendo um palpite sobre onde colocar o bloco que está caindo.) Se a jogabilidade é sobre
oposição, significando um oponente fornecendo um desafio ao qual os jogadores devem reagir,
e se em jogos de computador solitários o oponente é o computador, então o fato de um gerador
de números aleatórios fornecer todo o desafio no Tetris demonstra um ponto importante. A IA
que os jogadores enfrentam só precisa ser tão inteligente quanto a mecânica do jogo exige.
Uma IA precisa apresentar aos jogadores uma situação que os desafie, e realmente não
importa como a IA estabelece esse desafio. Pode ser tão complicado quanto a IA para um
jogo de estratégia profundo como Civilization, ou pode ser tão simples quanto o selecionador
de peças aleatório encontrado no Tetris. O que importa é que a IA combine com a mecânica
do jogo para desafiar suficientemente os jogadores.
A natureza aleatória em que as peças chegam ao topo da tela pode sugerir ao leitor que
o sucesso no Tetris é apenas sorte. Se as peças que os jogadores recebem são aleatórias,
como as pontuações de diferentes jogadores podem ser comparadas umas com as outras? O
ponto chave a perceber aqui é que, com o tempo, a aleatoriedade das peças se equilibra.
Assim como os dados rolam em um jogo de tabuleiro ao longo do jogo, as peças aleatórias
passadas aos jogadores no Tetris acabam funcionando como se não fossem aleatórias. Como
existem apenas sete tipos de peças, nenhuma com mais de quatro blocos, e como os
jogadores (pelo menos inicialmente) têm um grande espaço para manipulá-las, a aleatoriedade impede
tornando-se previsível enquanto ainda torna o jogo de um jogador comparável ao de outro.

Ao longo de um jogo, os jogadores receberão algumas centenas de peças. O número de vezes que os
jogadores obtêm apenas a peça que estavam procurando é igualado pelas vezes que eles não obtêm a
peça que desejam. Pode ser que os jogadores não consigam exatamente a peça certa na hora certa e
que, como a caixa já está cheia de peças, o jogo termine como resultado.
No entanto, para chegar a uma situação em que não pudessem usar qualquer peça que lhes fosse dada,
os jogadores já cometeram vários erros. No final, o selecionador de peças aleatório encontrado no Tetris
oferece um desafio justo e consistente para todos os jogadores.
Escalando a tensão
Tetris é muito implacável na forma como aumenta a tensão ao longo do jogo. Ao contrário de um jogo
como Centipede, os jogadores de Tetris não têm alívio quando uma onda termina, nem têm a capacidade
de “começar de novo” quando perdem uma vida. No Tetris , os jogadores “morrem” quando a caixa se
enche de peças que não conseguem fazer fileiras completas e o jogo termina, ponto final.
Isso significa que os jogadores devem estar constantemente em guarda, considerando constantemente
o que fazer com uma peça antes que ela atinja a parte inferior da tela. Mesmo um jogo de ritmo acelerado
como Doom oferece aos jogadores muitas pausas da ação. Nesse jogo de tiro em primeira pessoa, há
cantos seguros para se esconder e salas onde, uma vez eliminadas todas as ameaças, os jogadores
podem esperar indefinidamente sem serem ameaçados.
Tetris nunca desiste e constantemente confronta os jogadores com um novo desafio que deve ser
enfrentado.
O único alívio que os jogadores encontram no Tetris é quando eles “lutam de volta” de uma situação
complicada. Digamos que os jogadores deixaram cair alguns blocos em locais ruins, bloqueando assim
as linhas incompletas abaixo. Agora o jogo está mais difícil porque eles têm menos espaço e tempo para
manipular suas peças antes que elas parem na parte inferior da tela.
A tensão do jogo aumentou como resultado dos erros dos jogadores. Os jogadores podem, através da
colocação cuidadosa das peças subsequentes, apagar os tijolos mal colocados e, finalmente, completar
as linhas abaixo. Agora a tensão do jogo diminuiu e os jogadores estão de volta onde estavam, com mais
espaço e tempo para manipular as peças que caem.
Os jogadores sentem uma sensação de realização e alívio. Eles são capazes de relaxar momentaneamente,
sabendo que têm uma “lousa limpa” para trabalhar mais uma vez. Claro, isso só dura até que outros
erros sejam cometidos, e então a tensão do jogo aumenta mais uma vez.
Aumentando ainda mais a tensão do jogo é a aceleração da velocidade com que as peças caem ao
longo do jogo. Quando a pontuação dos jogadores aumenta acima de certos valores específicos, as
peças do jogo começam a se mover mais rapidamente, o que torna o jogo mais estressante para os
jogadores. Como as peças caem no tabuleiro mais rapidamente, os jogadores têm menos tempo para
descobrir a melhor posição para uma determinada peça e também menos tempo para manipular a peça
para essa posição. Na velocidade mais rápida do jogo, a maioria dos jogadores será incapaz de colocar
uma peça em um local ideal, e com uma peça no lugar errado o jogo só fica mais difícil. Pouco antes de
a velocidade aumentar, os jogadores podem começar a sentir que dominaram o jogo e podem jogar Tetris
indefinidamente. Mas quando a velocidade aumenta, qualquer tipo de ritmo que os músicos tenham
estabelecido é descartado. Agora os jogadores precisam fazer tudo o que faziam antes, só que mais
rápido.
Quando os jogadores começam a cometer erros no Tetris, esses erros aumentam, tornando o jogo
cada vez mais difícil de jogar. Como os jogadores não conseguem completar as linhas na parte inferior da
tela, eles têm cada vez menos espaço para manipular suas peças. Quando os jogadores acidentalmente
deixam cair uma peça no local errado, essa peça pode impedir que as linhas abaixo sejam concluídas e
tornará mais difícil manobrar as peças subsequentes em torno daquela peça mal colocada. Quando os
jogadores tentam esperar por uma peça em forma de “I” para preencher uma coluna estreita de espaços
vazios, os jogadores terão que continuar colocando outras peças em locais talvez menos que perfeitos até
que essa peça chegue aleatoriamente. De todas essas maneiras, o Tetris penaliza os jogadores por falhas.
Em vez de dar aos jogadores a chance de recuperar o atraso como alguns jogos de computador fazem,
Tetris apenas os pune, tornando ainda mais difícil voltar atrás de erros cometidos anteriormente. Outras
questões complicadas são os pontos de bônus que os jogadores recebem por remover quatro linhas de
uma só vez com uma peça “I”. Com essa tática, o jogo tenta os jogadores a assumir riscos que podem
acabar com o jogo.
Simplicidade e Simetria
Todas as peças do Tetris
são compostas por quatro
quadrados, cada um dos
quais compartilha pelo
menos um lado com outro
quadrado. Isso dá ao jogo
uma consistência e
equilíbrio inerentes.
Tetris, como já foi discutido, é um jogo muito simples. Grande parte de seu sucesso se deve à sua
simplicidade e ao fato de ser tão fácil de aprender ao mesmo tempo em que é tão implacavelmente desafiador.
Os jogadores não precisam aprender nenhum movimento especial para jogar o jogo. Há um número muito
pequeno de teclas usadas pelo jogo, e essas teclas produzem resultados muito óbvios na tela. É interessante
olhar para as peças usadas no Tetris. Eles são todos compostos por quatro quadrados, e, de fato, os sete
tipos diferentes de peças usadas no jogo representam todas as combinações possíveis de quatro quadrados,
onde cada quadrado deve compartilhar um lado com outro quadrado de seu grupo. Como os jogadores
podem girar as peças para a orientação que quiserem, existem apenas sete combinações verdadeiramente
únicas de quadrados possíveis.
Foi relatado que Pajitnov, ao criar Tetris, originalmente considerou usar peças compostas por cinco
quadrados combinados em doze peças únicas. De fato, o jogo de pentominó do qual Pajitnov se inspirou
usava doze peças de cinco quadrados. Pajitnov logo percebeu que eram muitas peças diferentes para ter
que manipular no final do cenário de alta pressão do Tetris , onde os jogadores têm um tempo limitado para
encontrar um ajuste perfeito para uma determinada peça. Certamente um jogo usando peças de
cinco quadrados poderia ter sido desafiador à sua maneira, e talvez uma velocidade de queda mais
lenta e um campo de jogo maior pudessem compensar a complexidade adicional das peças maiores.
Mas teria sido Tetris? Não. Teria sido tão divertido e viciante quanto Tetris? Provavelmente não. Em
algum ponto, um nível de complexidade começa a sufocar a natureza central de um jogo e confunde
os jogadores em vez de desafiá-los. Usar cinco em vez de quatro casas arruinou a simplicidade que
Pajitnov buscava e, como resultado, ele reduziu o número de casas que uma peça poderia ter. Da
mesma forma, se ele tivesse usado apenas três quadrados, o jogo teria sido muito simples. Parece
que Tetris segue habilmente o ditado de que tudo deve ser o mais simples possível, mas não mais
simples.
Na verdade, existem treze combinações únicas de cinco quadrados possíveis, onde cada
quadrado compartilha um lado com outro quadrado. Assim, parece que o jogo de pentominó original,
com seus doze blocos, não usava um conjunto completo de peças. Eu nunca tentei pentomino,
então não tenho ideia de quão divertido esse quebra-cabeça pode ser. Parte do que torna o Tetris
tão elegante é a completude de suas peças. Todas as permutações possíveis de quatro quadrados
com quadrados compartilhando lados são usadas no jogo. Remova qualquer uma das peças do
Tetris e o equilíbrio do jogo sofrerá. Ao jogar, os jogadores se deparam com situações que clamam
por certas peças. Certos arranjos dos blocos na parte inferior da tela deixam buracos que só podem
ser perfeitamente preenchidos por uma peça específica de Tetris . Parte do que dá ao Tetris seu
equilíbrio é o fato de que Pajitnov foi sábio o suficiente para incluir cada peça possível, fornecendo
assim uma peça para cada tipo de lacuna. A completude e simetria natural das peças disponíveis
para os jogadores de Tetris é um componente crucial de seu equilíbrio.
Quinze anos depois, quem publicaria Tetris?

Deve-se perguntar, se Tetris fosse criado hoje, qual editora estaria disposta a publicá-lo.
Originalmente , Tetris era vendido como “o jogo da Rússia” e apresentava arte e música de natureza
semelhante, quase como um gesto para nossos novos amigos no que era então a URSS
Se Tetris tivesse sido inventado por uma criança em uma garagem em Iowa, é de se perguntar se
algum dia teria sido publicado. (Gostaria de ser otimista e pensar que ele seria capaz de codificá-lo,
lançá-lo como shareware ou para o mercado de jogos casuais na Internet, e a fama do jogo ainda
estaria assegurada.) Tetris é o máximo em jogabilidade de baixa tecnologia, e muitos editores de
jogos simplesmente se recusam a publicar jogos que não utilizam o que há de mais moderno em
magia de computação gráfica. Afinal, onde eles encontrarão as belas capturas de tela da parte de
trás da caixa? O jogo carece de qualquer tipo de história ou mesmo cenário, outra necessidade
absoluta para o pessoal do marketing. Que tipo de texto eles escreverão em seus anúncios? De
fato, é uma prova da brilhante jogabilidade de Tetris que não pode ser adequadamente descrito em
qualquer quantidade de palavras, muito menos em uma frase cativante.
Mesmo olhando para uma captura de tela estática de Tetris é uma experiência completamente
desinteressante, que não pode esperar comunicar a arte sublime do jogo. A jogabilidade é um
assunto indescritível para manipuladores da palavra escrita; deve ser experimentado para ser compreendido.
Capítulo 9
Artificial
Inteligência
“Eu basicamente assistia ao jogo até ver a IA fazer algo estúpido, então
tentava corrigir isso e repetir ad infinitum. Durante um período longo o
suficiente que produziu uma IA muito boa. Sempre tentei ensinar à IA as
mesmas estratégias de sucesso que uso ao jogar um jogo.”
— Brian Reynolds, falando sobre a criação da inteligência artificial
para seus jogos Civilization II e Alpha Centauri
Texto:% s. Em um contexto acadêmico, a inteligência artificial às vezes é definida

A inteligência
comoartificial pode que
um sistema significar uma variedade
pode passar de forma de coisasno
confiável diferentes em diferentes
que é chamado de testecon
de
Turing. No teste de Turing, os humanos são apresentados a terminais de computador nos quais
podem digitar várias frases e podem ver as respostas impressas na tela. Se os usuários
acreditarem que as respostas foram fornecidas por um ser humano, mesmo que na verdade
tenham sido fornecidas pelo computador, então esse computador teria passado no teste de
Turing e poderia dizer que possui inteligência artificial.
151
152 Capítulo 9: Inteligência Artificial
Pode-se aplicar um teste semelhante aos jogos de computador. Se alguém está jogando
um jogo de Unreal Tournament e não pode dizer se o oponente contra quem está jogando é
um oponente humano ou um 'bot, então pode-se dizer que o jogo passa em uma versão limitada
do teste de Turing e, portanto, possui algum tipo de artificial inteligência. No entanto, na prática,
mesmo que o jogo tenha falhado nesse teste, as pessoas diriam que o jogo tem inteligência
artificial, mas não uma inteligência artificial realmente boa. Quando os desenvolvedores de
jogos falam sobre inteligência artificial, eles não se referem à capacidade do computador de
enganar os jogadores e fazê-los pensar que estão jogando contra oponentes humanos reais.
Em vez disso, os desenvolvedores de jogos se referem a qualquer código usado para controlar
os oponentes que os jogadores lutam como inteligência artificial. Na pesquisa de IA, o objetivo
final é simular a mente humana. Em um jogo, o objetivo final é garantir que a experiência do
jogo seja divertida. Como o jogo reage às ações dos jogadores é determinado pela IA do jogo
e, portanto, a qualidade da IA determina o quão divertido e desafiador o jogo é. As reações do
jogo podem ser completamente aleatórias ou completamente lógicas; em ambos os casos, o
código que controla essas reações é chamado de inteligência artificial do jogo.
Se um jogador joga um
jogo de Unreal
Tournament e não pode
dizer se o oponente é um
'bot ou um humano, a
inteligência artificial do
'bot passou no teste de Turing.
Considere um jogo como Centipede. A IA para este jogo é completamente previsível, com
os vários insetos se movendo em padrões predeterminados, com uma pequena quantidade de
aleatoriedade. Algumas pessoas diriam que o jogo realmente não tem IA.
De fato, os comportamentos das criaturas no jogo são extremamente simples de implementar.
Mas, ao mesmo tempo, o jogo oferece um grande desafio para o jogador.
A parte difícil de criar a IA para um jogo como Centipede está inteiramente no design dos
comportamentos dessas criaturas e em criar os padrões de movimento que fornecerão um
desafio interessante para o jogador. A IA é mais design do que implementação. Tetris, talvez,
seja um exemplo ainda mais extremo. A única IA que se pode dizer que o jogo tem é o gerador
de números aleatórios que determina qual peça cairá no campo de jogo em seguida. No
entanto , o Tetrisis foi projetado de tal forma que esta é a única IA que o jogo precisa.
O leitor pode estar se perguntando por que estou falando sobre IA de jogos em um livro
sobre design de jogos. Certamente a IA é uma tarefa de programação, e como este livro não é
sobre programação, a discussão sobre IA contida neste capítulo pode parecer fora de lugar. Mas
Capítulo 9: Inteligência Artificial 153
determinar o que a IA fará e realmente programar esse comportamento são duas tarefas bastante distintas. O
primeiro envolve principalmente a criatividade e o segundo consiste em muito trabalho duro. O designer de um
jogo deve estar intimamente preocupado em garantir que o comportamento da IA do jogo seja o mais bem
concebido possível e execute as ações com maior probabilidade de fornecer aos jogadores uma experiência
de jogo desafiadora e atraente. Parte de projetar um bom jogo é projetar uma boa IA para esse jogo, e um
designer que apenas deixa a criação da IA para os programadores esperar que eles sejam bons designers de
IA. Se não forem, o jogo provavelmente não será muito divertido de jogar. Tal como acontece com muitos dos
programadores em uma equipe de desenvolvimento, o programador de IA precisa ter um bom senso de design
de jogo para que a IA final seja suficientemente desafiadora, interessante e divertida para o jogador. Quanto
mais o designer trabalha com o programador de IA, maior a probabilidade de os dois estarem na mesma página
em termos do que a IA precisa realizar.
Se um jogo de computador é como um teatro improvisado, onde os jogadores se tornam diretores do

personagem principal ou grupo de personagens, então todos os outros atores da peça são controlados pela
inteligência artificial. Como designer do jogo, você deseja direcionar esses atores controlados por IA para criar
a experiência mais estimulante possível para o jogador.
Esses agentes de IA não são apenas os oponentes que os jogadores podem enfrentar, mas também quaisquer
personagens com os quais os jogadores interagem. Como se comportará uma cidade cheia de pessoas? Como
eles reagirão às ações dos jogadores? Projetar a IA é uma grande parte do projeto de um jogo.
Objetivos da IA do jogo
O sucesso do The
Sims depende
completamente da
força de sua inteligência artificial.
Os jogadores têm expectativas diferentes da IA que encontram em diferentes tipos de jogos.

Os jogadores não esperam muito da IA em um jogo de arcade como Centipede ou em um jogo de quebra-
cabeça como Tetris. Como discuti, esses jogos oferecem muitos desafios aos jogadores enquanto usam vários
oponentes simplórios ou totalmente estúpidos. Em um jogo de guerra como o Close Combat, no entanto, os
jogadores esperam muito mais da inteligência das forças adversárias. Em um RPG, os jogadores esperam
entrar em uma simulação de um mundo vivo, onde
personagens se movem em uma cidade mais ou menos “realisticamente”. Em um jogo como The Sims, a IA é
mais ou menos o jogo; com IA fraca o jogo simplesmente não valeria a pena jogar.
Portanto, jogos diferentes provocam expectativas diferentes nos jogadores de quão inteligentes os agentes
de IA nesses jogos precisam ser. No entanto, ainda podemos construir uma lista geral de objetivos para qualquer
IA de jogo de computador, objetivos que mudam em importância à medida que os objetivos de design de um
determinado jogo variam.
Desafie o jogador
Fornecer um desafio razoável para os jogadores deve ser o objetivo principal da IA em qualquer jogo de
computador. Sem estabelecer um adversário digno de algum tipo, um jogo se torna incontestável e, portanto,
muito fácil de derrotar. Pior ainda, um jogo que não oferece nenhum desafio dinâmico deixa de ser um jogo
inteiramente e se torna mais um quebra-cabeça ou um filme interativo.
Em um jogo de arcade
clássico como Robotron: 2084,
o desafio vem do grande número
de oponentes que o jogador deve lutar.
Em um jogo de arcade clássico como Robotron: 2084 ou em um jogo de tiro em primeira pessoa como
Doom, o desafio vem principalmente de jogadores sendo dominados por adversários e pelas poderosas
habilidades que esses adversários têm. Por exemplo, no meu exemplo frequentemente usado de Cen tipede, os
insetos podem matar os jogadores ao tocá-los, enquanto os jogadores devem atirar nas criaturas para matá-los.
Isso coloca os jogadores em desvantagem. O fato de haver vários insetos atacando os jogadores ao mesmo
tempo não ajuda em nada. Como resultado, a IA para essas criaturas pode ser bastante simples e previsível,
mas os jogadores ainda são desafiados por elas.
O mesmo desequilíbrio vale em Doom, onde os jogadores podem ficar sem munição, mas seus inimigos
nunca, onde os jogadores são muito mais indefesos no escuro enquanto os inimigos podem detectar jogadores
tão facilmente quanto à luz, e onde geralmente os inimigos, como criaturas voadoras, podem ir onde os jogadores
não podem. O fato de que as criaturas superam em muito o personagem do jogador também tende a compensar
a realidade de que nenhuma das criaturas é muito inteligente. A IA em Doom tem que parecer mais sofisticada
do que os insetos Centipede porque o mundo Doom parece mais real do que o mundo Centipede , como discutirei
em breve. O fato é que principalmente a IA oferece um desafio para
jogadores por serem mais poderosos e numerosos do que o personagem do jogador.

Criar uma IA desafiadora para um jogo de estratégia em tempo real como StarCraft é uma
proposta totalmente mais difícil. A expectativa em jogos desse tipo é que os jogadores estejam
competindo com adversários equivalentes a eles em força. Em seu jogo médio de estratégia em
tempo real, ambos os lados têm um grande número de tropas para manipular e a capacidade de
construir mais conforme necessário. Ambos os lados geralmente precisam extrair algum tipo de
recurso e usá-lo para construir mais estruturas ou tropas. Basicamente, a IA em um RTS precisa
fazer tudo o que os jogadores fazem e parecer inteligente ao fazê-lo. Muitas vezes, a IA tem uma
vantagem por poder ver o nível inteiro enquanto os jogadores não podem, e possivelmente ter um
número maior de unidades iniciais, um método mais fácil para obter mais ou um conjunto maior de
recursos para extrair. No entanto, criar um desafio para os jogadores em um jogo RTS é bastante
difícil, pois exige que a IA coordene o movimento das unidades além do nível de unidade individual,
fazendo com que as unidades pareçam trabalhar de forma colaborativa, como os jogadores as
usariam.
Desenvolver
uma IA desafiadora
para um jogo de
estratégia baseado em
turnos como Alpha
Centauri pode ser
bastante difícil, pois o
jogador deve estar
lutando contra oponentes
com aproximadamente
as mesmas forças e fraquezas que ele
As dificuldades apresentadas na criação de uma IA desafiadora para um jogo RTS só são

ampliadas em um jogo de estratégia baseado em turnos como Alpha Centauri. Aqui, a IA deve
operar exatamente como os jogadores. É claro que os jogos de estratégia baseados em turnos são
alguns dos jogos mais intensos disponíveis, de modo que apenas amplifica o problema de criar uma
IA adversária convincente. Além disso, o computador não se beneficia tanto de seu poder de
processamento extremamente rápido; como o jogo é baseado em turnos, os jogadores têm o tempo
que quiserem para pensar em um movimento. A natureza analítica do computador lhe dá uma
vantagem em lembrar o status exato de todas as unidades que ele tem sob seu comando, uma
habilidade na qual as mentes humanas são significativamente menos habilidosas. Muitas vezes, as
IAs de estratégia baseadas em turnos criam um desafio para os jogadores trapaceando de várias
maneiras sutis, embora eu certamente seja o último a acusar qualquer jogo em particular de fazê-lo.
No final das contas, certamente não tenho nenhum problema com essa tática, já que o objetivo final
é desafiar o jogador sem parecer muito injusto no processo.
Independentemente do tipo de jogo, a IA deve apresentar aos jogadores um desafio

interessante. Sem uma boa IA, um jogo pode se tornar semelhante a jogar xadrez com seu (muito)
irmão mais novo: um pouco inútil. A diferença é que, quando você joga xadrez com seu irmão mais
novo, espera ensiná-lo as nuances do jogo para que um dia ele se torne um bom jogador. Você
também pode gostar de socializar com ele, fazendo com que um jogo de xadrez sem sentido valha
a pena. Infelizmente, a IA do jogo de computador que você enfrenta não tem esperança de melhorar
e é lamentavelmente inadequada quando se trata de fornecer companheirismo. Para que uma IA de
jogo justifique sua existência, ela deve oferecer aos jogadores um desafio. Ao mesmo tempo, é
importante ter em mente que você não quer punir o jogador com muita severidade com a IA do seu
jogo. Entrando em um “Sou eu contra o jogador!” A mentalidade de quando você, como designer de
jogos ou programador de IA, segura todas as cartas é semelhante a derrotar seu irmãozinho no
xadrez toda vez que você o desafia para uma partida. Não é uma luta justa, e em breve seu irmão
ou jogadores em geral não vão querer mais jogar com você.
Não faça coisas idiotas

A IA para um jogo de computador não deve parecer excessivamente estúpida. Os jogadores adoram
rir da IA quando ela faz algo completamente imprudente. Nada quebra mais a suspensão de
descrença de um jogador do que quando um agente de IA não consegue contornar um pequeno
obstáculo, como um hidrante ou uma árvore, ou quando um agente corre de um penhasco para sua
destruição como um lemming. Para o jogador, é completamente óbvio o que a IA deve fazer em cada situação.
Mas o que pode parecer óbvio para os jogadores pode, na verdade, ser uma ação bastante complexa
para o agente realizar ou entender. No entanto, para que o jogo evite se tornar motivo de chacota, a
IA do jogo deve ter um domínio sólido do que parece óbvio para os jogadores humanos.
Ao lutar contra
alienígenas em um
jogo como Marathon 2, o
jogador reduziu as
expectativas de quão
inteligentes esses inimigos serão.
O número de coisas idiotas com as quais a IA será capaz de se safar tem uma relação direta
com o tipo de inteligência que a IA deve representar. Por exemplo, no meu jogo de tiro em primeira
pessoa Damage Incorporated, os jogadores deveriam estar quase
lutando exclusivamente contra oponentes humanos. Em Marathon 2, no entanto, os jogadores estão

lutando contra uma variedade de espécies alienígenas misturadas com alguns robôs. Os inimigos em
Marathon 2 são capazes de parecer estúpidos, pois são criaturas não humanas. Em Damage
Incorpoted, inversamente, já que os inimigos são todos humanos, eles devem parecer muito mais inteligentes.
Para outro exemplo, em Damage Incorporated, de acordo com a história do jogo e a aparência dos
níveis no jogo, a ação deve estar ocorrendo em um ambiente do mundo real. Por outro lado, Centipede
3D se passa em um mundo de fantasia caprichoso que tem apenas uma relação tangencial com o
mundo real. Portanto, enquanto os guardas em Damage Incorporated precisam parecer estar
rastreando jogadores como soldados humanos reais fariam, em Centipede 3D é menos absurdo que
as centopéias sejam incapazes de fazer um caminho direto para o personagem do jogador e, em vez
disso, tenham que ir e voltar entre cogumelos. A estupidez da IA é aceitável em relação ao tipo de
mundo que o jogo de computador deve representar.
Seja imprevisível Os
humanos são imprevisíveis. Isso é parte do que os torna bons oponentes em um jogo e uma
das principais razões pelas quais as pessoas gostam de jogar jogos com vários jogadores;
uma pessoa habilidosa será um desafio para lutar de uma forma que um computador nunca
faria. Uma grande parte disso é a imprevisibilidade de um oponente humano. O mesmo deve
ser verdade para os oponentes de IA em um jogo de computador. Quando o jogo chega ao
ponto em que os jogadores sentem com certeza que sabem exatamente o que as forças
inimigas vão fazer a qualquer momento, a diversão de jogar o jogo diminui rapidamente. Os
jogadores querem que a IA os surpreenda, para tentar derrotá-los de maneiras que eles não
previram. Certamente os jogos multijogador ainda têm a vantagem de incluir um componente
social, que é um fator importante para seu sucesso, e a IA em seu jogo nunca poderá ser
amiga dos jogadores da mesma maneira que outro humano. Como você não pode fornecer o
componente social dos jogos multijogador, você pode pelo menos se esforçar para fazer com
que os agentes de IA forneçam muito do mesmo desafio e imprevisibilidade que é fornecido por um op
Em toda arte, os espectadores querem ver algo que não foram capazes de antecipar, algo que
desafie suas expectativas. Quando, nos primeiros dez minutos, você sabe o final exato de um filme,
livro ou peça, grande parte da emoção de experimentar esse trabalho é removida. O mesmo vale para
jogos de computador. Claro, os jogos podem surpreender os jogadores com sua história
predeterminada, ou em que tipo de ambiente o próximo nível ocorrerá, ou como será o robô chefão.
Mas se a IA também puder contribuir para isso de forma imprevisível, o jogo ganha replayability. Os
jogadores continuarão jogando um jogo até que não seja mais um desafio, até que eles não
experimentem mais nada de novo ao jogar o jogo. Uma IA que possa continuar surpreendendo-os e,
assim, desafiá-los, ajudará a manter seu interesse alto.
A imprevisibilidade bem-sucedida pode assumir muitas formas diferentes nos jogos. Pode ser
tão simples quanto o número aleatório que determina qual peça cairá em seguida no Tetris.
Certamente este é um caso muito simples, e esperamos que muitos jogos possam fornecer
imprevisibilidade mais profunda do que isso. Mas, ao mesmo tempo, é preciso perceber que, para o
Tetris, é a quantidade perfeita de imprevisibilidade. Se os jogadores soubessem qual peça viria a
seguir, o jogo perderia muito de seu desafio. De fato, com o recurso “próximo” ativado (que exibe a
próxima peça a cair na lateral da tela), o jogo fica um pouco mais fácil. A aleatoriedade pura
geralmente é uma boa maneira de manter os jogadores
A única necessidade de AI
Tetris é um gerador de
números aleatórios. Retratado
aqui: modo clássico em The
Next Tetris.
interessados na IA, para fazê-los pensar: "O que ela está tentando fazer?" quando na verdade está
apenas sendo aleatório. A aleatoriedade no Tetris fornece a imprevisibilidade necessária para manter
os jogadores desafiados por horas.
Às vezes, os objetivos da IA dos jogos de computador podem ficar confusos e, na busca pelo
santo graal do realismo, um designer ou programador de IA pode acabar se tornando um oponente
muito chato para um jogo. Claro, o agente sempre toma uma decisão que “faz sentido” dada sua
situação atual; pode até mesmo tomar a decisão mais provável de vencer a batalha atual. Mas se
essa decisão lógica for completamente óbvia para o jogador, quão divertido será lutar contra essa
IA? Se toda vez que você entrar em uma sala em um jogo de tiro em primeira pessoa, o orc que você
encontrar vai girar, levantar sua clava acima de sua cabeça e atacar você enquanto balança
descontroladamente, a próxima vez que você jogar naquela sala a situação será muito menos
desafiador e interessante. E se às vezes o orc se assusta com a chegada repentina do jogador?
Então o orc pode fugir pelo corredor ou se esconder em um canto.
E se às vezes o orc decidir arremessar sua clava no personagem do jogador ao invés de tentar usá-
la como uma arma corpo a corpo? Isso certamente forneceria tempero suficiente para manter os
jogadores em alerta. Você deve se lembrar que cada ser humano é diferente e que muitos humanos
são conhecidos por agir irracionalmente por várias razões. Essa irracionalidade mantém a vida
interessante. Se os jogadores estão lutando contra humanos ou monstros/alienígenas semelhantes
a humanos em um jogo de computador, um pouco de irracionalidade resultará em fazer com que os
oponentes pareçam muito mais reais, críveis e interessantes de se engajar.
“Lógica difusa” é um método que designers e programadores de IA podem usar para manter os
agentes de IA imprevisíveis e interessantes. Essencialmente, a lógica fuzzy pega um sistema lógico
e insere alguma aleatoriedade nele. Na lógica fuzzy, quando a IA é apresentada a uma determinada
situação, ela tem vários cursos de ação que valem a pena escolher em vez de apenas um.
Digamos que os jogadores estejam a uma certa distância com uma certa arma enquanto o agente
de IA está em um certo nível de saúde e está equipado com um certo tipo de armamento. Pode haver
três coisas razoáveis para o agente fazer neste caso, e cada uma pode ter diferentes valores
numéricos ou “pesos” representando sua qualidade relativa. Digamos que correr para cima e atacar
o personagem do jogador faz muito sentido, então vale 5. Fazer uma exibição de ameaça em
para assustar o jogador faz um pouco de sentido, então vale 2. E talvez tentar circular ao redor do
personagem do jogador para desorientá-lo também seja plausível, então vale 3.
Usando esses pesos diferentes, o agente pode simplesmente escolher aleatoriamente um número
de 1 a 10 (o total dos pesos). Se menor ou igual a 5, o agente correrá e atacará. Se 6 ou 7, o agente
tentará assustar o jogador, e se 8 a 10, o agente fará o possível para desorientar o jogador. Os pesos
representam a chance de que a IA tome uma determinada decisão. Se a IA tiver planos diferentes o
suficiente à sua disposição, os jogadores nunca poderão saber exatamente o que a IA fará, tornando
a IA imprevisível. Na análise final, basear as decisões de IA na aleatoriedade faz com que o agente
pareça estar realizando um raciocínio complexo quando não está. Os jogadores nunca saberão que
a IA em questão acabou de escolher sua ação de um chapéu. Em vez disso, se a ação do agente
não parecer muito estúpida, os jogadores tentarão imaginar por que a IA pode ter escolhido fazer o
que fez e podem acabar pensando que o agente é bastante astuto quando na verdade é apenas
aleatório.
É claro que a imprevisibilidade de um agente de IA em um jogo não deve entrar em conflito
com os outros objetivos de IA que listei aqui. Se um agente está tão ocupado sendo imprevisível que
não pode montar um plano sólido de ataque contra o jogador, não será uma grande ameaça para os
jogadores e eles não serão desafiados. Idealmente, a imprevisibilidade aumenta o desafio que a IA
apresenta, em vez de ser um prejuízo. Se a IA escolher aleatoriamente fazer algo completamente
tolo quando o que estava fazendo estava prestes a levar à vitória, os jogadores não podem deixar
de se perguntar: “Por que a IA faria uma coisa tão estúpida?” Ao trabalhar nos comportamentos das
criaturas em um jogo, é sempre importante ficar de olho no quadro geral do que a IA está tentando
realizar.
Ajudar a contar histórias
A IA do jogo pode ser usada para aprofundar a história de um jogo. Por exemplo, em um RPG, os
jogadores podem viajar para uma certa cidade que abriga vários moradores medrosos que temem a
chegada de forasteiros. Se os jogadores apenas observarem essas pessoas, eles podem ser vistos
navegando pela cidade, indo às lojas, restaurantes e fábricas, assim como as pessoas em uma
cidade real fariam. Isso define o cenário para a cidade e faz com que pareça real para os jogadores.
Mas sempre que os jogadores se aproximam dessas pessoas, eles se afastam, fugindo para áreas
seguras para evitar interagir com os jogadores. Por que é isso? O que isso diz sobre a cidade e as
pessoas que vivem lá? Por que eles estão com medo? O que os jogadores podem fazer para que as
pessoas da cidade confiem neles? Os jogadores querem saber as respostas para todas essas
perguntas e, como resultado, começarão a explorar a história do jogo. Os professores de inglês são
famosos por dizerem a seus alunos que é melhor mostrar do que contar. Isso é especialmente
verdadeiro em um meio visual, como jogos de computador. Em vez de apenas ver que os habitantes
da cidade têm medo de estranhos em uma cena, uma IA projetada adequadamente pode realmente
mostrar aos jogadores essas informações interessantes durante o jogo. E quando os jogadores são
capazes de interagir com esses personagens, seu envolvimento na história vai além de ser mostrado
para ser realmente ativo nela. Os jogadores são capazes de fazer parte da narrativa de uma forma
que nenhum outro meio torna possível.
Mesmo os adversários que os jogadores podem enfrentar em uma batalha podem ser ajustados
para ajudar no processo de contar histórias. Suponha que em um jogo de guerra os jogadores devam
lutar contra um general conhecido por ser compassivo com o bem-estar de suas tropas, talvez mais
do que o lógico em uma situação de combate. Os jogadores podem enviar alguns franco-atiradores
para pegar várias tropas da força adversária que estão servindo como guardas ao longo da fronteira
entre duas áreas contestadas. Se a IA para o general inimigo fosse projetada adequadamente, a lenta
drenagem de tropas dessa maneira começaria a enfurecê-lo. Uma vez enfurecido, o general tentaria
um ataque imprudente para se vingar das forças inimigas, colocando-o em desvantagem. Aqui,
novamente, um pouco da história do jogo foi contada através da IA.
Em Damage Incorporated, a IA
que os companheiros de equipe
do jogador exibem desempenha
um papel crucial em contar a
história do jogo.
No meu jogo Damage Incorporated, o jogador é um sargento do Corpo de Fuzileiros Navais dos
EUA encarregado de uma equipe de quatro homens. Juntamente com seus homens, os jogadores
passam por inúmeras missões contra uma variedade de oponentes fortemente armados. Os homens
cada um tem diferentes pontos fortes e fracos. Alguns são teimosos e atacarão bravamente em uma
luta. Alguns dos membros do esquadrão são mais cuidadosos ao disparar suas armas do que outros e,
como resultado, são menos propensos a acertar o personagem do jogador ou os outros companheiros de equipe.
Esses traços de personalidade são todos comunicados por meio da IA que esses colegas de equipe
usam. Antes de cada missão, os jogadores escolhem seu time a partir de uma seleção de treze
soldados diferentes, cada um com um dossiê que os jogadores podem ler. Os dossiês fornecem um
perfil psicológico de cada um dos companheiros de equipe, o que dá uma visão de suas personalidades.
Além disso, quando de fato em uma missão, os companheiros de equipe estão constantemente falando,
seja em resposta às ordens dos jogadores ou apenas para comentar uma determinada situação. Isso
dá mais informações sobre suas personalidades e como eles se comportarão no campo de batalha. Se
os jogadores lerem os dossiês e prestarem atenção às personalidades dos membros do elenco, eles
perceberão avisos de que alguns dos companheiros de equipe podem não estar completamente
equilibrados psicologicamente. Para alguns companheiros de equipe, se forem levados em muitas
missões, eles “quebrarão” ou ficarão “em estado de choque” e tentarão fugir da batalha. Outros
companheiros de equipe, se contratados para missões específicas com as quais não concordam
ideologicamente, se voltarão contra o sargento e seus homens. A IA, é claro, lida com essas situações
de “choque”, o que ajuda a contar a história desses personagens.
Uma área em que a IA é frequentemente evitada inteiramente pelos designers, mas onde pode
ser bastante útil é na narrativa dinâmica. Muitas vezes os designers criam uma história em torno de um
jogo em vez de integrar a história com a jogabilidade. Além disso, muitas vezes os designers querem
contar histórias estáticas nas quais um determinado personagem reagirá aos jogadores é
totalmente pré-determinado, independentemente das ações no mundo do jogo ou de como os
jogadores tratam esse personagem em particular. Embora os designers muitas vezes se esforcem
para manter as batalhas e sequências de ação tão dinâmicas e imprevisíveis quanto possível,
eles quase sempre querem manter as histórias exatamente as mesmas toda vez que os jogadores
as experimentam. Por que os jogadores não podem afetar o humor dos diferentes NPCs que
encontram? Talvez se os jogadores disserem todas as coisas certas e não fizerem perguntas
sobre assuntos delicados, o NPC se tornará amigável com o personagem do jogador. Talvez os
jogadores só consigam extrair informações cruciais de um personagem depois de se tornarem
seu amigo. Talvez as reputações dos jogadores os precedam, onde as ações que os jogadores
realizaram em outras partes do mundo impactam diretamente como esse NPC tratará o
personagem do jogador. Se os jogadores realizaram ações menos do que boas no início do jogo,
talvez os jogadores tenham que se redimir aos olhos de um personagem antes que possam prosseguir no
No meu jogo The Suffering, os jogadores determinam o final com base em como tratam os
personagens humanos amigáveis que encontram no jogo. Os jogadores têm a opção de ajudar
esses humanos controlados por IA, matá-los ou ignorá-los completamente. Eu deliberadamente
fiz dos personagens uma grande variedade de personalidades e fiz sua IA refletir esses traços.
Um personagem está extremamente assustado com as criaturas no mundo do jogo e, portanto,
passa a maior parte de seu tempo fugindo freneticamente delas. Mais tarde no jogo, os jogadores
encontram um agente penitenciário chamado Ernesto que odeia todos os presos, incluindo o
personagem do jogador, Torque. Quando eles se encontram pela primeira vez no mundo do jogo,
Ernesto imediatamente ameaça Torque, apontando sua metralhadora para ele, mas não
disparando. Se os jogadores atirarem em Ernesto no início deste encontro, Ernesto se tornará
imediatamente hostil a Torque. Se os jogadores esperarem, no entanto, Ernesto percebe que ele
e Torque devem trabalhar juntos para sobreviver contra os monstros. Agora, se Ernesto é baleado
por jogadores, ele não se torna imediatamente hostil, mas avisa Torque que ele precisa observar
o que está fazendo. Assim, a IA de Ernesto muda com base em como ele se sente em relação ao Torque.
Claro, se Torque atirar nele mais duas vezes, Ernesto ainda se tornará hostil; ele não é bobo. No
final, é vantajoso para os jogadores manter Ernesto por perto, pois sua IA está configurada
Em The Suffering, a IA
dos NPCs companheiros
mudou seu comportamento
com base nas ações do
personagem do jogador.
de tal forma que ele é o companheiro de combate mais eficaz no jogo, permitindo que ele ajude os
jogadores a despachar as inúmeras criaturas que continuam levantando suas cabeças feias.
Claro, há uma ampla gama de efeitos diferentes que podem ser alcançados usando a IA do
jogo para criar relacionamentos interpessoais interessantes. Infelizmente, isso é algo que tem sido
praticamente inexplorado em jogos comerciais até hoje. Em vez de contar histórias estáticas,
poderíamos contar histórias que, embora não totalmente geradas processualmente, eram sutilmente
diferentes dependendo de como os jogadores jogavam o jogo. Usar a IA para apimentar e variar a
história de jogo para jogo pode tornar muito mais difícil contar uma história, mas o que ela pode
adicionar à não linearidade e à rejogabilidade do jogo é enorme.
Crie um mundo vivo

Em muitos jogos, a IA faz mais do que apenas fornecer uma ameaça e um desafio ao jogador. Um
jogo pode até incluir agentes de IA com os quais os jogadores não interagem diretamente. A IA pode
ser usada para habitar o mundo vivo que o jogo cria. Um mundo de jogo pode ser infinitamente
detalhado em termos dos objetos que contém e como parece e soa, mas os jogadores estão
acostumados a um mundo real que também contém organismos vivos que pensam por si mesmos
e se comportam de maneiras interessantes. Portanto, criar um mundo de jogo estéril cheio de
objetos inanimados não será um espaço muito crível para o jogador. Não é preciso exagerar ao
encher o mundo do jogo com agentes complexos de IA de ambiente; um pouco pode percorrer um
longo caminho. Quer isso signifique alguns pássaros que voam pelo céu, insetos que rastejam no
chão ou humanos que cuidam de seus negócios diários, adicionar vida ambiente a um mundo pode
fazer muito para tornar o mundo do jogo mais real. o jogador. Os jogos Grand Theft Auto apresentam
cidades cheias de humanos vivendo suas vidas diárias, a maioria dos quais não são diretamente
necessários para a história principal. Esses pedestres fazem a cidade parecer mais real, e quanto
mais real for o mundo do jogo, mais provável é que os jogadores possam mergulhar nele.
Existe uma estreita conexão entre preencher o jogo com vida ambiente e usar a IA para contar
a história do jogo. Criar esses habitantes faz muito para estabelecer o cenário para o seu jogo, e o
cenário é uma parte fundamental para contar qualquer história. Mas a vida ambiente em um jogo vai
além de apenas estabelecer esse cenário; ajuda a fazer com que os jogadores se sintam menos
solitários no mundo do jogo. Quantas vezes você jogou um jogo em que sentiu como se estivesse
andando por um terreno baldio estéril, como se um exterminador tivesse passado anteriormente
para eliminar qualquer sinal de vida? Os jogadores adoram ver que o mundo tem vida ambiente
nele, criaturas que eles podem apenas olhar em vez de matar, e a profundidade que adiciona ao
mundo pode ser inestimável.
O campo de jogo inclinado

Muitas vezes, quando os programadores se reúnem para falar sobre IA para jogos de computador,
eles concentram suas discussões em como querem que seus agentes de IA estejam em pé de
igualdade com o jogador. Este foi certamente o caso nas mesas redondas de IA que participei nos
anos anteriores na Game Developers Conference. Esses especialistas em IA querem que seus
sistemas de IA saibam apenas o que os jogadores saberiam, vejam o que os jogadores podem ver
e assim por diante. Isso, eles sugerem, tornará o conflito entre a IA e os jogadores mais realista e,
portanto, mais interessante.
É claro que, há anos, os jogos dão aos agentes de IA vantagens injustas sobre o jogador.
Eles fizeram a IA ter mais pontos de vida do que o personagem do jogador. Eles superaram o
jogador em cem para um. Eles fizeram com que os agentes da IA tivessem um conhecimento
praticamente psíquico de todos os locais do mundo do jogo, o que lhes permite saber exatamente
onde o personagem do jogador está a qualquer segundo, certamente uma vantagem injusta.
Algumas IAs de jogos são conhecidas por trapacear. Certamente isso é injusto com o jogador,
dirão os programadores de IA. Eles proclamam que a IA deve estar em pé de igualdade com os
jogadores e deve triunfar apenas com sua inteligência.
Mas é realmente melhor colocar a IA e os jogadores em igualdade de condições? Em primeiro
lugar, é bem provável que isso leve a uma IA que não oferece um grande desafio para os
jogadores. O fato é que jogadores astutos serão capazes de superar até mesmo a IA de jogo mais
sofisticada sem tanta dificuldade. Tentar colocar jogadores e IA em igualdade de condições criará
um desafio muito maior para seus programadores de IA. Eles precisarão investir inúmeras horas a
mais no desenvolvimento de uma IA que tenha uma pequena chance de vencer os jogadores,
tempo que não pode ser gasto melhorando outras partes do jogo. No final, eles podem acabar com
uma IA que não oferece uma experiência de jogo cativante. Na pior das hipóteses, a IA está muito
ocupada sendo “real” para evitar realizar ações descaradamente estúpidas.
Uma grande parte do que leva os programadores de IA a tentarem igualdade de condições

para jogadores e agentes de IA são os próprios egos dos programadores. Esses programadores
se orgulham de seu trabalho e afirmam que podem criar uma IA capaz de desafiar os jogadores
sem precisar recorrer a números superiores, maior força ou qualquer tipo de trapaça. Os
programadores querem o direito de se gabar de poder dizer que sua IA é tão inteligente quanto um
humano. Muitas vezes, horas e horas são gastas tentando criar os algoritmos sofisticados
necessários para essa competição igual versus igual e, no final, algo precisa ser hackeado para
fazer o jogo realmente funcionar. O objetivo da IA do jogo é dar suporte ao jogo e aprimorar as
experiências dos jogadores, não servir como um banco de testes para técnicas de inteligência
artificial.
Além disso, há algo romântico para os jogadores quando eles conseguem derrotar um
oponente da IA, apesar do fato de que as forças da IA superam em muito as suas próprias forças,
estavam melhor armadas e equipadas e até tiveram o benefício do conhecimento presciente do
mapa. Assim como o herói de ação de Hollywood triunfa sobre inúmeros inimigos, os jogadores
querem superar as probabilidades aparentemente intransponíveis de suas próprias vitórias. Inclinar
a balança na vantagem da IA só torna a vitória final dos jogadores ainda mais doce. A menos,
claro, que o design acabe tornando o jogo muito difícil.
Quão real é muito real?

Outra armadilha potencial de programação de IA é criar uma IA que, embora realmente funcione
como uma pessoa “real”, acaba prejudicando a jogabilidade como resultado. Em termos das
histórias que contam e das configurações que empregam, os jogos são muitas vezes artifícios,
situações estritamente irreais que são configuradas especificamente porque são interessantes,
não porque são autênticas, e a IA deve apoiar isso.
Considere os filmes de James Bond. Esses filmes são como muitos jogos populares, pois
apresentam muita ação e situações emocionantes com menos foco no desenvolvimento de
personagens ou histórias significativas. Em quase todos os filmes, Bond é capturado em algum
momento e amarrado a um dispositivo de execução particularmente hediondo. Este dispositivo não mata
Bond instantaneamente, mas em vez disso emprega algum método mais lento, como um laser
queimando constantemente um buraco no meio da mesa à qual James está amarrado. Por que
o vilão não simplesmente atira em Bond? Ou simplesmente apontar o laser diretamente para
ele? Por que o vilão quase sempre sai antes que a execução tenha sido realmente concluída?
E por que o vilão revela a Bond todo o seu esquema louco para dominar o mundo antes de
colocar o dispositivo de execução em movimento? Nenhuma dessas escolhas é indicativa de
comportamento especialmente inteligente, mas é divertido de assistir e se encaixa no estilo
geral do filme. Ele entretém o público, que é o objetivo principal dos filmes de Bond. O realismo
é muito menos preocupante.
E assim é com os jogos. Se a IA inimiga é tão inteligente, certamente deve perceber que
não tem chance contra o jogador e deve se trancar em um bunker seguro, recusando-se a abrir
a porta para qualquer um. De fato, salvou sua própria vida fazendo isso, que é a decisão mais
inteligente possível. Mas o que isso fez com o jogo? Agora os jogadores estão presos, pois não
têm como chegar ao inimigo e continuar com o jogo.
Outro exemplo pode ser uma IA covarde que foge dos jogadores quando suficientemente ferida.
Isso é usado com grande efeito em muitos jogos. Mas e se o agente fosse mais rápido que o
personagem do jogador e melhor se esquivando para locais seguros? Quando bastante ferido,
o agente da IA começará a fugir da batalha, com os jogadores sem outra opção a não ser
persegui-lo. Se a IA for mais rápida e melhor na navegação, os jogadores terão dificuldade em
alcançá-la. O que pode ter sido um jogo de ação divertido agora se torna uma perseguição
tediosa com uma conclusão precipitada, já que o agente está mortalmente ferido e não tem
chance de recuperar sua saúde. E o que os jogadores de chefes de serpentes mortais devem
lutar? Com seu revestimento protetor de armadura, é impermeável aos ataques dos jogadores
e só pode ser danificado por um tiro quando sua boca está aberta. Portanto, a escolha
estritamente lógica pode ser sempre manter a boca fechada sempre que os jogadores tiverem
alguma chance de conseguir um arremesso. Esta é uma decisão que pode tomar muito
facilmente. Mas agora, é claro, os jogadores não têm chance alguma de vencer a batalha. Isso é divertido?
O ponto novamente é que a IA nunca deve ofuscar a jogabilidade e nunca deve distrair a
equipe de desenvolvimento do verdadeiro objetivo do projeto: fazer um jogo divertido e jogável.
Se a IA é realmente muito sofisticada, mas, como resultado, o jogo não pode ser jogado ou é
extremamente frustrante, os jogadores não vão comentar sobre a inteligência dos combatentes
do jogo. A IA e a jogabilidade estão intimamente ligadas para que uma tenha sucesso se a
outra falhar.
Agentes de IA e seu ambiente

A IA de jogos de computador não pode ser projetada ou desenvolvida no vácuo. Para que uma
IA de jogo funcione bem, ela precisa ser desenvolvida em estreita associação com a jogabilidade
do jogo e os ambientes em que essa jogabilidade ocorrerá. O simples fato é que nenhum
agente de IA será inteligente o suficiente para prevalecer em todas as situações. Embora uma
IA possa ser extremamente boa em espaços abertos, quando for jogada em um desfiladeiro
estreito, encontrará problemas que seu programador nunca antecipou. Se o programador de IA
criar uma IA que possa lidar com espaços confinados, é provável que não seja tão bem-
sucedido em campo aberto. O melhor que se pode esperar é que a IA tenha uma chance de
lutar em um tipo específico de situação de jogo. Se os níveis e a IA não forem desenvolvidos de forma síncr
então há pouca chance de que os oponentes que os jogadores enfrentam pareçam muito
inteligentes.
Isso cria problemas especiais em termos de como produzir melhor um jogo. O design de
níveis geralmente é uma das últimas tarefas a serem realizadas em um jogo, antes de entrar no
balanceamento final, depois nos testes e, finalmente, no envio. Da mesma forma, a IA geralmente
só é trabalhada depois que o mecanismo principal está firme no lugar, a maioria das mecânicas
para o movimento do jogador está totalmente funcional e muitas das outras tarefas de programação
mais críticas estão quase completas. Agora, se a mesma pessoa que está projetando os níveis
também está criando a IA inimiga, pode ser simples integrar o desenvolvimento dos dois, mas isso
é raro, se não inédito, no desenvolvimento de jogos modernos. Como resultado, você tem duas
equipes – os programadores e os designers de nível – trabalhando em paralelo. Infelizmente, o
caso usual é que cada um avança com seu trabalho sem considerar totalmente o outro. Os
designers de nível ainda não têm a IA, então eles não podem adaptar seus níveis para apoiá-la. É
exatamente o oposto do outro lado da equação: o programador ainda não tem os níveis, então é
difícil para ele fazer uma IA que funcione bem nesses níveis. A situação é um catch-22. Uma vez
que os níveis são feitos em termos de arquitetura, a IA é finalmente adicionada a eles, e então
acontece que um ou outro precisa ser radicalmente reformulado para que o jogo seja divertido. Na
pior das hipóteses, não há tempo para retrabalhar nem os níveis nem os comportamentos, e a
jogabilidade acaba sendo prejudicada.
Claro, os designers de nível protestarão que a IA deve ser projetada para se adequar aos
níveis que eles criam. E, da mesma forma, os programadores de IA reclamarão que os níveis
simplesmente devem ser reconcebidos para funcionar com a IA que desenvolveram. Como
trabalhei como designer de níveis e programador de IA, posso estar em uma posição especial para
arbitrar essa disputa. Na minha opinião, nenhuma das partes está totalmente certa, e é necessário
um pouco de dar e receber de cada lado. Eu recomendaria tentar fazer uma IA simples e jogável
primeiro. Não precisa ser livre de bugs ou funcionar perfeitamente em todas as situações. Se
funcionar razoavelmente bem em algumas situações, os designers de níveis podem começar a
criar níveis que facilitem o que a IA sabe fazer bem. À medida que os designers de nível tomam
essa direção, o programador de IA pode continuar trabalhando em sua IA, se livrando de quaisquer
bugs enquanto sempre fica de olho na forma que o mundo do jogo está tomando. O programador
de IA deve se comunicar com o designer de nível quando ele vê um problema surgindo em um
nível, como uma situação que a IA provavelmente não lidará bem. Ao mesmo tempo, o design dos
níveis pode dar ao programador de IA novas ideias sobre quais truques a IA pode realizar. Talvez
comecem a aparecer bordas no mundo do jogo que seriam locais ideais para atiradores de elite.
Ou talvez a estrutura da arquitetura do mundo do jogo seja adequada para movimentos coordenados
de equipe. Se o programador de IA puder adicionar funcionalidades aos seus algoritmos para
permitir que os agentes identifiquem esses locais e se comportem de acordo, a IA se tornará mais
forte como resultado. Ambos os lados da equação designer/programador devem estar prontos para
se comprometer. Muitas vezes, um designer pode ter que se comprometer para o bem do projeto,
modificando algo que ele pode gostar como está, mas que confunde horrivelmente a IA. Da mesma
forma, o programador pode precisar adicionar algum código de caso especial feio para acomodar
um problema que ocorre na maioria dos mapas que foram criados. O designer e o programador de
IA devem confiar um no outro de modo que, quando um deles diz ao outro que algo precisa mudar,
eles acreditam no outro e fazem acontecer.
Fazer com que os agentes

de IA da Damage Incorporated
funcionassem corretamente
exigia muitas mudanças nos
níveis.
Por exemplo, no meu jogo Damage Incorporated, os jogadores são responsáveis não apenas por controlar
seu próprio personagem, mas também por dirigir quatro companheiros de equipe em um ambiente 3D. Quando
eu estava trabalhando nesse jogo, um dos maiores desafios que encontrei foi fazer com que a IA do colega de
equipe funcionasse de uma maneira que parecesse inteligente para os jogadores. Felizmente, eu tinha uma
forma rudimentar dessa IA funcionando antes de qualquer level design real começar.
Dessa forma, percebi com antecedência que a IA do companheiro de equipe não seria inteligente o suficiente
para pular ou nadar para as áreas. Isso significava que os níveis tinham que ser projetados de acordo, ou os
companheiros de equipe não seriam capazes de chegar ao final de um nível com o personagem do jogador.
Além disso, os companheiros de equipe tiveram um desempenho ruim em espaços apertados e restritos, muitas
vezes se chocando ou bloqueando o progresso dos jogadores. Os níveis tiveram que ser feitos com grandes
áreas abertas para que os agentes de IA pudessem ter uma boa chance de um bom desempenho.
Mas mesmo com o conhecimento prévio da sofisticação da IA do jogo, uma vez que a Damage Incorporated
entrou nos testes, surgiram problemas infinitos com a IA. Os companheiros de equipe constantemente pareciam
ser capazes de ficar presos em pequenos espaços onde não deveriam entrar. A solução final acabou sendo
cerca de 25% de correções de código e 75% de retrabalho em partes dos níveis para eliminar os pequenos
recantos nos quais os agentes de IA se enfiavam. Havia inúmeras seções de níveis que eu queria que
parecessem de uma certa maneira, mas que precisavam ser descartadas porque a IA simplesmente não podia
funcionar nessas áreas. Fiquei triste ao ver essas seções desaparecerem, mas não tão triste quanto os jogadores
ficariam quando conseguiram prender um companheiro de equipe em uma fenda. A IA e os níveis tinham que
trabalhar juntos se o jogo final fosse divertido de jogar.
Em The Suffering, tive uma experiência muito mais suave fazendo com que personagens de IA amigáveis
navegassem pelo mundo do jogo, embora tenham surgido alguns problemas. Não estava originalmente no plano
que os personagens humanos pudessem subir escadas, abrir portas ou pular abismos. À medida que construímos
o mundo, percebemos que não havia como fazê-los navegar pelas escadas. Tínhamos relativamente poucos
cenários em que era necessário, mas não havia como removê-los facilmente ou fazer um script ou “poder” o
movimento da escada do agente de IA. Sem a capacidade de abrir e fechar portas, os agentes de IA
simplesmente pareciam muito burros quando você batia as portas na cara deles, então acabamos adicionando
isso também. Nós
tivemos alguns casos em que os NPCs precisariam pular pequenas lacunas, mas rapidamente
percebemos que não tínhamos o suficiente para justificar a programação envolvida em fazer os NPCs
pularem. Analisando as situações em que o salto era necessário, conseguimos facilmente retrabalhar
as áreas para eliminar alguns saltos. Os que não conseguimos remover, conseguimos resolver com
uma ação de salto roteirizada para os NPCs que podiam ser executados apenas nesses pontos. Isso
exigiu alguma depuração tediosa no lado do design, mas no final foi muito mais simples do que
implementar um comportamento de salto de propósito geral.
Quão bom é bom o suficiente?

Damage Incorporated e The Suffering sugerem outro ponto interessante sobre a sofisticação que será
exigida da IA em diferentes jogos. O que tornou o trabalho nesses jogos tão desafiador foi o fato de
que os jogadores contavam com a IA para realizar certas ações para eles. Na Damage Incorporated,
se os jogadores ordenassem que um companheiro de equipe se movesse para uma determinada
posição, eles esperavam que aquele trooper chegasse a essa posição e a defendesse. Se a IA não o
fizesse, os jogadores poderiam morrer como resultado e amaldiçoariam a IA por falhar com eles. Pior
ainda, se os jogadores ordenassem que a IA se mudasse para uma posição específica e o soldado
tivesse dificuldade em chegar lá, os jogadores ficariam frustrados, especialmente quando o caminho
apropriado para aquele local fosse completamente óbvio para os jogadores. Mas se um agente de IA
inimigo tivesse problemas para encontrar um caminho para um local, os jogadores nunca seriam mais
sábios. Se um oponente ficasse preso em um canto em raras ocasiões, os jogadores ficariam muito
felizes em explorar a estupidez do agente de IA, derrubando o inimigo preso com uma rajada de
metralhadora. No entanto, se um companheiro de equipe ficar preso em um canto, ele não poderá
seguir os jogadores até o final do nível. Como os jogadores não podiam terminar um nível a menos
que todo o seu time estivesse na “Zona de Extração” para aquele nível, os erros da IA acabariam com
os jogos dos jogadores prematuramente. Nada frustra mais os jogadores do que morrer por causa da
IA defeituosa do companheiro de equipe.
Em um jogo com
companheiros de
equipe, como a Damage
Incorporated, a falha dos
agentes de IA em trabalhar
como o jogador espera
impede seriamente a
capacidade do jogador de jogar o jogo.
Pode-se tirar algumas lições dos problemas que tive com a implementação da IA na Damage
Incorporated. A primeira é nunca fazer um jogo com companheiros de equipe em um
ambiente 3D complexo. Esta é uma lição que aparentemente perdi completamente, já que
posteriormente incluí companheiros em O Sofrimento. Felizmente, minha experiência com The
Suffering foi muito mais tranquila, em parte devido às lições que aprendi na primeira vez. A outra
conclusão é que a quantidade de sofisticação de IA que um jogo requer depende de quanto a falha
dessa IA afetará o jogador. Se a IA estragar e o jogo do jogador terminar como resultado, isso é
muito ruim. Se a IA comete erros e a única consequência é que o jogo do jogador fica um pouco
mais fácil, então é uma falha com a qual os jogadores provavelmente podem conviver, desde que
seja uma ocorrência bastante rara. Portanto, quando um designer está trabalhando em um sistema
de IA ou criticando o trabalho de um programador, ele deve sempre ter em mente o quão importante
é que o sistema funcione corretamente. É perfeitamente aceitável se apenas a equipe de
desenvolvimento souber da estupidez da IA enquanto os jogadores ignoram completamente suas
deficiências.
Seria bom tornar cada sistema em um jogo o mais inteligente possível, mas as realidades do
ciclo de produção ditam que há apenas um certo tempo que pode ser investido em qualquer parte
de um jogo. Raro é o caso de um programador ter terminado todo o trabalho necessário para um
jogo e ainda ter tempo de “polir” tudo o que gostaria. Como tal, gastar muito tempo em sistemas de
IA excessivamente sofisticados tirará diretamente o tempo de outras tarefas que precisam
desesperadamente de trabalho. O leitor notará que quando listei os atributos que a IA de um jogo
precisa ter, não listei “ser uma inteligência artificial respeitável e de qualidade acadêmica”. A IA de
um jogo só precisa ser boa o suficiente para desafiar os jogadores, sem parecer excessivamente
tola em suas ações.
Em sua fascinante palestra na Game Developers Conference “Quem enterrou Paul?” Brian
Moriarty discutiu o conceito de “constelação” nos jogos. Essa teoria é de particular relevância para
a IA de jogos. Em linhas gerais, a teoria é que os humanos, quando apresentados a alguns dados
aparentemente aleatórios, tentarão dar sentido a eles, colocá-los em ordem e tentar encontrar
significado onde pode, de fato, não haver nenhum. Para a IA do jogo, então, Moriarty sugeriu que
fazer com que sua IA execute ações aparentemente aleatórias fará com que os jogadores pensem
que a IA tem algum plano grandioso e inteligente. Os jogadores podem pensar algo como o
seguinte: “Por que aquele pelotão de tanques de repente invadiu aquela colina?
Não parece haver nenhuma razão para isso. Talvez eles saibam algo que eu não sei.
Talvez eles estejam se reagrupando com uma força que não consigo ver.” Os jogadores que não
são desenvolvedores de jogos terão a tendência de tentar acreditar que os agentes de IA de jogos
fazem escolhas inteligentes. Claro, há uma linha tênue. Se os jogadores virem um agente de IA
batendo inutilmente em uma parede, eles saberão que algo está errado. É importante lembrar que
os jogadores não querem encontrar bugs em seu jogo, e farão o possível para acreditar na
inteligência dos personagens que veem nele. Ao adotar algum comportamento aleatório, seus
agentes de IA podem parecer mais inteligentes do que realmente são.
Scripts É claro
que a IA do jogo não precisa pensar espontaneamente em todos os comportamentos que são
executados no jogo. Em alguns jogos, uma combinação de IA dinâmica com caminhos
predeterminados e comportamentos roteirizados pode criar a experiência mais emocionante
possível para o jogador. Normalmente, os comportamentos de script funcionam melhor em jogos
que têm locais predefinidos e onde os jogadores provavelmente não jogarão esses níveis
repetidamente. Nesses jogos, é provável que os jogadores entrem em uma determinada área de um determinad
o designer pode fazer suposições sobre qual plano de ataque fornecerá o desafio mais interessante
para o jogador.
Os jogos de tiro em primeira pessoa são um bom exemplo de um gênero de jogo que funciona
bem com comportamentos de IA com scripts. Half-Life foi um dos primeiros jogos a mostrar como
scripts complexos podem ser usados para criar oponentes muito divertidos de lutar. Esse jogo foi
amplamente elogiado na imprensa de jogos pela força de sua IA, enquanto, na verdade, grande
parte dessa inteligência percebida foi realizada usando caminhos de script para os quais os agentes
de IA se moveriam em situações específicas. Jogos RTS, como StarCraft , usaram scripts
extensivos em seus mapas de cenário para um jogador desde que existem. Nesses jogos, a IA
recebe instruções do script sobre o que fazer quando os jogadores finalmente chegam a um
determinado local ou depois de construir um certo número de unidades. Isso faz com que cada
nível apresente um desafio mais exclusivo para o jogador do que se todos os mapas fossem
executados com uma IA puramente de propósito geral.
Configurar comportamentos de script que são específicos para um nível é uma grande
preocupação do designer de nível. O designer de níveis já precisava se preocupar com onde os
oponentes deveriam ser colocados para criar o máximo efeito de jogabilidade. Mas com
comportamentos roteirizados, o designer precisa jogar repetidamente uma área para descobrir os
lugares mais diabólicos para a IA se esconder, para onde ela deve recuar quando estiver com
pouca saúde e como deve se reposicionar melhor para ter a maior chance de derrotar o jogador. .
Claro, o agente de IA não pode estar apenas em um caminho, pelo menos não se o jogador provavelmente
A IA ainda deve ser usada para permitir que o agente determine qual local ele deve tentar chegar
em qual situação. Além disso, a IA deve ser capaz de perceber quando os planos roteirizados não
estão funcionando e quando tentar um comportamento não roteirizado e mais geral. Pode-se
pensar que ter agentes de IA que usam comportamentos predeterminados e roteirizados não
produzirá a imprevisibilidade que discuti anteriormente. Alguém pode se perguntar como um
comportamento roteirizado pode ser tudo menos previsível. Por esse motivo, o comportamento
com script deve ser usado apenas para dar dicas ao agente de IA sobre onde podem ser bons
locais para se esconder e se esconder, não para especificar onde o agente deve sempre ir,
independentemente da situação. O agente ainda deve ser capaz de reagir às táticas do jogador
para evitar parecer muito tolo.
The Suffering usou muitas

ações de IA com script
para fazer os inimigos e
companheiros parecerem
mais inteligentes do que
realmente eram.
Dos jogos em que trabalhei, The Suffering confiou mais em comportamentos de IA com script
para fazer seus personagens parecerem inteligentes e criar uma experiência de jogo atraente para
o jogador. Esse script assumiu várias formas. Freqüentemente, usávamos alguns scripts leves para
introduzir uma criatura no ambiente. Por exemplo, quando o jogador passa por um gatilho no topo
de uma parede, então ativamos um número de criaturas para pular na parede e correr em direção
ao jogador. Depois que as criaturas pousassem na parede, elas seguiriam um caminho em direção
ao gatilho que o jogador acertou, saindo desse caminho assim que recebessem dano ou quando
detectassem o jogador como um alvo viável. Uma criatura particularmente astuta no início do jogo
foi roteirizada para arrancar uma porta de suas dobradiças (o que acontece em uma cena) e depois
correr para os vários cantos escuros da sala até que a criatura sofra dano ou um cronômetro se
esgote.
Isso dá a ilusão de brincar de gato e rato com o jogador. Isso só acontecia até que o jogador
conseguisse danificar a criatura, já que depois disso parecia tolice continuar provocando. Havia
vários lugares no jogo onde os jogadores podiam atacar NPCs com armas de longo alcance de uma
posição alta e inacessível, onde os NPCs baseados em combate corpo a corpo não conseguiam
retaliar. Infelizmente, as criaturas foram incapazes de descobrir isso por conta própria, então, sem
algum tipo de script, elas tendiam a tentar inutilmente navegar até a posição do jogador e acabavam
parecendo bastante estúpidas ao fazê-lo. Nessas situações, adicionamos scripts que alternariam os
NPCs entre um comportamento hostil e um comportamento de fuga, dependendo se o jogador
estava no local do atirador ou não.
Os companheiros humanos que o jogador encontra ao longo do jogo foram fortemente

roteirizados. Alguns desses personagens levam o jogador de um local para outro ao longo de um
nível específico. Esses destinos foram especificamente mapeados pelo designer de níveis com
antecedência. Às vezes, eles foram configurados para vigiar criaturas hostis enquanto se movem
para essas posições, enquanto outras vezes são configurados para se mover cegamente para um
local e só então se tornarem hostis a quaisquer ameaças que possam encontrar.
Normalmente, o agente de IA permaneceria hostil até que uma certa condição de sucesso fosse
atendida no ambiente, como todas as criaturas em uma área sendo mortas ou o jogador resolvendo
um quebra-cabeça específico. Só então eles seriam acionados para se mudar para o próximo
destino. Normalmente, apenas o ponto de destino específico é especificado pelo designer de nível,
com a IA descobrindo dinamicamente o melhor caminho para chegar a esse local com base em sua
posição atual. Esses NPCs amigáveis também tendiam a ser grandes conversadores e, portanto,
diziam diálogos específicos em diferentes pontos ao longo do nível, todos integrados aos
comportamentos mais ativos que eles executavam como parte de seus scripts.
Além de scripts baseados em eventos, The Suffering também usou muitos objetos “ajudantes”
de NPCs que foram configurados manualmente por designers de nível. Estes assumiram
principalmente duas formas: posições de fuga e posições de mira. Os NPCs saberiam usar o
primeiro quando precisassem fugir do combate em uma sala, e colocamos essas posições em
pequenos recantos, atrás de pilares e em outros lugares que pareceriam inteligentes para um NPC se esconder.
Antes de realmente usar uma dessas posições, o agente de IA precisaria analisar todos os locais
dentro de um determinado raio ao seu redor, escolhendo aquele onde seus inimigos não tinham
linha de visão para ele e onde, para chegar a essa posição , ele não precisaria passar muito perto
de nenhuma ameaça ativa. Mesmo quando a IA escolhia um local de fuga específico para usar, a
IA reavaliava continuamente sua decisão, potencialmente movendo-se para uma posição diferente
se um inimigo corresse muito perto de um determinado local e, assim, o tornasse significativamente
Menos desejável. As posições de mira usavam essencialmente o mesmo conceito, exceto que
esses ajudantes seriam colocados em locais onde a IA gostaria de ir para parecer inteligente
enquanto atira em um alvo; enquanto as posições de fuga seriam colocadas em bons locais para
se esconder, as posições de mira eram colocadas em cima de bordas, em junções em corredores
e outros locais onde a IA provavelmente estaria aberta e capaz de disparar em uma variedade de
alvos. Algumas posições de direcionamento estavam vinculadas a outras posições de
direcionamento em torno de uma parte específica da geometria de baixo nível que poderia ser
usada como cobertura. A IA sabia escolher uma posição de alvo de um grupo que faria parecer se
esconder atrás da mesa, pedra ou outro objeto baixo enquanto detonava seu alvo.
O Sofrimento combinou comportamentos dinâmicos de IA com scripts para criar agentes que
parecem muito mais inteligentes do que se fossem todos dinâmicos ou todos com script. É através
dessa combinação que conseguimos criar alguns dos cenários mais emocionantes do jogo, onde
os agentes de IA parecem ter batalhas dinâmicas uns com os outros, mas onde essas situações
foram realmente configuradas com muito cuidado pelo designer de níveis para otimizar efeito. O
truque é manter esse equilíbrio precário entre muito script e muito pouco para que o jogo ainda
seja divertido, desafiador e dinâmico, além de fornecer cenários complexos e memoráveis nos
quais os jogadores possam participar.
Estupidez Artificial
O fato de os jogos serem frequentemente referidos como não tendo inteligência artificial, mas sim
estupidez artificial é bastante revelador sobre a qualidade da IA presente em muitos jogos.
Certamente é verdade que a IA em quase todos os jogos não é algo que por si só seja
impressionante. No entanto, quando considerados em termos do que se pretende fazer – desafiar
o jogador – muitos dos melhores jogos realmente apresentam oponentes de computador bem
projetados. Embora os jogos para vários jogadores forneçam muitos caminhos para um design e
produção de jogabilidade interessantes, um grande segmento da população de jogadores ainda
deseja jogos para um jogador. Os jogos solitários proporcionam uma experiência única, e a IA do
jogo é crucial para tornar essa experiência o mais divertida possível. É responsabilidade do
designer conceber cuidadosamente essa inteligência artificial e garantir que aqueles que a
implementam tenham uma compreensão clara do que a IA deve fazer para desafiar e entreter com
sucesso o jogador.
Capítulo 10
Entrevista:
Steve Meretzky
No início da década de 1980, os jogos da Infocom eram bastante únicos – tanto

que a empresa preferiu chamá-los de algo totalmente diferente: ficção interativa.
Os títulos da Infocom eram totalmente separados e distintos dos clones e
derivados de jogos de arcade que tantas outras empresas de jogos de computador
estavam publicando na época. A ficção interativa da Infocom atraiu um grupo
totalmente diferente e mais sofisticado de jogadores de jogos de computador. O
conteúdo dos jogos foi surpreendentemente alfabetizado e feito profissionalmente,
com um nível consistente de qualidade que nunca foi igualado. Sua natureza
apenas de texto deu-lhes uma qualidade literária que lhes deu algum grau de
respeitabilidade, o suficiente para angariar uma crítica do jogo Deadline no New
York Times Book Review e a admissão de dois dos implementadores da Infocom,
Steve Meretzky e Dave Lebling, para os Escritores de Ficção Científica da América
como autores interativos. A Book Review certamente nunca revisou um jogo de
computador desde então, e a SFWA posteriormente mudou suas regras para
impedir a inclusão de mais autores interativos. Steve Meretzky continua sendo um
dos maiores talentos da Infocom, tendo trabalhado tanto em um dos jogos mais
vendidos da Infocom, O Guia do Mochileiro das Galáxias, quanto em um de seus
mais respeitados, A Mind Forever Voy. Desde o fim da Infocom, Meretzky
continuou a tradição literária em jogos de aventura - primeiro com uma série de títulos para a Leg
172
Capítulo 10: Entrevista: Steve Meretzky 173
e posteriormente com sua própria empresa, Boffo Games, que produziu o adorável The
Space Bar. Atualmente, Meretzky está envolvido com a empresa de jogos de Internet
WorldWinner.com. Ultimamente, os jogos de aventura caíram em desuso entre os editores,
o público de jogos ou alguma combinação de ambos. Não se pode deixar de se perguntar: o
que aconteceu com os fãs de jogos de aventura que fizeram da Infocom um sucesso tão
grande?
O que inicialmente o atraiu para os jogos de computador?

No final dos anos 70 e início dos anos 80, eu tinha bastante repulsa por jogos de computador e, na
verdade, por todas as coisas relacionadas a computador. Eu os considerava nerds e anti-sociais, e
parecia que sempre que a conversa se voltava para qualquer assunto relacionado a computadores,
o inglês saía pela janela. Muitas pessoas no meu dormitório estavam jogando o Zork original de
mainframe, já que estava sendo escrito no Laboratório de Ciência da Computação, e achei a
preocupação deles com o jogo bastante desagradável. Joguei um pouco de Maze Wars no Lab e
tive uma breve aventura com Space Invaders, mas foi só isso.
Até que, em 1981, meu colega de quarto Mike Dornbrook foi o primeiro e, na época, único
testador da Infocom. Ele começou a testar o Zork I em um Apple II em nossa mesa de jantar.
Quando ele não estava por perto, comecei a jogar um pouco e logo fiquei muito viciado. Zork II logo
seguiu Zork I em nossa sala de jantar “laboratório de teste”. Relatei todos os bugs que encontrei,
embora Mike estivesse sendo pago para encontrar bugs e eu não.
Então isso levou a um emprego na Infocom?

No MIT, me formei em Gerenciamento de Projetos de Construção, e foi esse o trabalho que fiz nos
primeiros dois anos depois que me formei em junho de 79. Era horrível: trabalho tedioso, pessoas
chatas, empresas longe de ser de ponta. Então, no outono de 1981, quando meu colega de quarto
Mike Dornbrook foi para a escola de negócios em Chicago, Marc Blank (VP de Desenvolvimento da
Infocom) precisava de um novo testador para seu próximo jogo de mistério, eventualmente chamado
Deadline. Como eu havia provado ser um testador capaz ao testar Zork I e II gratuitamente, ele me
contratou por hora como testador substituto para Mike. A essa altura, a Infocom ainda não tinha
escritório e apenas um ou dois funcionários em tempo integral. Continuei testando em casa no
Apple II.
Em janeiro de 1982, a Infocom mudou-se para um maravilhoso espaço de escritório na beira
da ponte Cam, e comecei a trabalhar fora do escritório, testando o Deadline e depois Zork III e o
primeiro esforço pós-Zork de Dave Lebling , Starcross. Em junho, comecei como empregado de
meio período, tendo sido apenas um contratado até então.
Mesmo neste ponto, eu realmente não tinha planos de me tornar um autor de jogos – eu
estava apenas me divertindo fazendo algo divertido para variar e esperando para descobrir o que
eu queria fazer com o resto da minha vida. Eu havia estudado redação no MIT e havia enviado
algumas histórias de ficção científica para várias revistas, mas não consegui publicar nada.
Então, como você conseguiu dar o salto de testador para autor? Você teve que provar a si
mesmo primeiro?
Em algum momento no final do verão de 82, Marc Blank me perguntou se eu estaria interessado
em escrever um jogo. Eu concordei imediatamente, pensando que, embora testar jogos fosse bastante
174 Capítulo 10: Entrevista: Steve Meretzky
um pouco divertido, escrevê-los provavelmente seria ainda mais divertido. Eu não tive que provar a
mim mesmo, por algumas razões. Primeiro, eu conhecia Marc há alguns anos no MIT; nós dois
estávamos envolvidos com a execução do programa de cinema do campus, então ele sabia que eu
era uma pessoa muito trabalhadora e criativa. Em segundo lugar, a Infocom ainda era pequena e
informal, praticamente sem burocracia envolvida em tais decisões. E terceiro, ao fazer sugestões
ao testar jogos, mostrei que entendia o jogo e o design do quebra-cabeça
processo.
Então, qual foi sua inspiração para Planetfall?

Meu principal interesse como leitor, e como escritor, era ficção científica, então era uma conclusão
precipitada que o jogo seria SF. E como a interação de personagens era o que o sistema de
desenvolvimento da Infocom era mais fraco, um ambiente como um planeta deserto parecia uma
boa ideia. Além disso, eu realmente não posso dizer.
Quais eram seus objetivos de design com o personagem Floyd?

A ideia de ter um único personagem não-jogador muito bem desenvolvido foi um foco de design
muito inicial de Planetfall. Os jogos da Infocom até aquele ponto geralmente tinham meia dúzia de
personagens cada, como o mago, o gênio, o dragão, a princesa e os gnomos em Zork II. Por causa
do grande número de tais personagens, todos eram bastante magros. Eu pensei que tendo apenas
um outro personagem (sem contar as aparições extremamente breves de Blather e do embaixador
alienígena durante a cena de abertura) eu seria capaz de tornar esse personagem mais interessante
e mais crível.
Não me lembro como cheguei a Floyd, embora “robô fofo” tenha sido uma decisão muito
precoce. Talvez a influência tenha sido a trilogia Star Wars , que era então entre Empire e Jedi. O
personagem de Willis, um alienígena fofo do livro de Robert Heinlein, Planeta Vermelho, pode ter
sido outra influência.
Você sempre planejou forçar o jogador a permitir que Floyd fosse morto para ganhar o jogo?
Não, essa decisão definitivamente veio no meio do processo de design/implementação do jogo.

Floyd estava se tornando um pouco mais bem-humorado do que originalmente concebido, e ele
também estava se tornando um personagem um pouco mais sentimental do que originalmente
concebido: esfregando a cabeça no seu ombro, ferindo seus sentimentos, descobrindo os restos
mortais de seu velho amigo. Lázaro, etc. Ficou claro que as pessoas ficariam muito apegadas a
ele, e em algum momento a ideia simplesmente clicou que eu poderia criar esse momento realmente
emocionante.
Além disso – e esta é uma influência relativamente pequena na decisão, mas ainda vale a
pena mencionar – na época a Electronic Arts estava apenas começando. Eles estavam veiculando
uma série de anúncios destinados a estabelecer seu grupo de designers de jogos como artistas.
Um dos anúncios citou um de seus designers dizendo algo como: “Quero criar um jogo de
computador que faça as pessoas chorarem”. Havia um pequeno toque de rivalidade ali, e eu só
queria derrotá-los no passe.
O Guia do Mochileiro das Galáxias foi uma adaptação de uma série e livro de rádio já muito
amado. Como você adaptou uma peça de ficção linear para uma forma interativa?
Na verdade, era bastante ideal para adaptação, porque era um enredo bastante episódico e porque
era um ambiente cheio de todos os tipos de ótimos personagens, locais, tecnologias etc., enquanto
o enredo não era tão importante. Foi um desafio, mas um bom desafio, não um mau desafio.
Como foi trabalhar com Douglas Adams?

No lado positivo, Douglas já era um fã da Infocom e tinha jogado vários de nossos jogos, então ele
entendia o que era um jogo de aventura e entendia as habilidades e limites do nosso sistema. Por
outro lado, ele nunca havia escrito de forma não linear antes, e esse é sempre um processo difícil de
entender. Além disso, fiquei um pouco impressionado por trabalhar com ele e não me afirmei o
suficiente no início do processo. Então, acho que você verá que o início do jogo é bastante linear,
incluindo a destruição da casa de Arthur e a cena a bordo da nave Vogon. Mais tarde, quando
Douglas ficou mais confortável com o design interativo e quando superei minha timidez, o jogo se
tornou um dos designs não lineares mais implacáveis que já fizemos.
Foi maravilhoso colaborar com Douglas, que faleceu em 2001 aos 49 anos de idade. Ele era
uma pessoa muito inteligente e criativa, e bem humorada também. Ele não é uma risada por minuto,
como você poderia esperar de sua escrita, mas mais irônico com muitas ótimas anedotas. Ele estava
constantemente inventando maneiras de esticar o meio de maneiras malucas que eu nunca teria
pensado por conta própria: ter o jogo mentir para você, ter um objeto de inventário como “sem chá”,
ter as palavras de um analisador falhando sejam as palavras que caíram por um buraco de minhoca
para iniciar a guerra interestelar, etc.
Quão uniformemente foi o trabalho dividido entre vocês dois?

O objetivo original era que fizéssemos o design juntos, Douglas escrevesse as passagens de texto
mais importantes e eu as preenchesse, e eu fizesse a implementação, ou seja, a programação de
alto nível usando o sistema de desenvolvimento da Infocom.
Douglas veio para Cambridge por uma semana quando começamos. Então trocávamos e-mails
diariamente, e isso foi em 1984, quando e-mails não LAN ainda eram bastante raros. Também
trocávamos telefonemas aproximadamente semanalmente.
No entanto, a única característica dominante de Douglas era que ele era o maior procrastinador
do mundo. Ele estava ficando cada vez mais atrasado em sua agenda e, ao mesmo tempo, seu
quarto livro do Mochileiro , Até mais e obrigado por todos os peixes, estava cerca de um ano atrasado
e ele não havia escrito uma palavra.
Então, seu agente o mandou para longe das distrações de Londres e o forçou a se esconder
em uma pousada rural na periferia oeste da Inglaterra. Então fui até lá para ficar nesta estalagem,
que era uma antiga propriedade baronial chamada Huntsham Court, que havia sido convertida em
uma estalagem deliciosa, e passei uma semana completando o projeto. Então voltei para os EUA e
implementei o jogo inteiro em cerca de três semanas intensas, bem a tempo de um verão abreviado
de testes. Douglas voltou em setembro para reescrever algumas partes do texto-chave, e isso foi
feito a tempo de uma tarde
Lançamento de outubro. O jogo rapidamente alcançou o primeiro lugar nas listas de best-sellers e
permaneceu lá por meses.
Eu vi o Hitchhiker ser referido como um jogo Infocom particularmente difícil. Era essa a sua
intenção?
Douglas e eu sentimos que os jogos de aventura estavam se tornando um pouco fáceis demais, que o
Zork original tinha sido muito mais difícil do que as ofertas mais recentes, e o quebra-cabeças obsessivo
24 horas por dia, 7 dias por semana, era o que tornava esses jogos tão viciantes. Então, podemos ter
exagerado e ido longe demais na outra direção. Certamente, a equipe de testes da Infocom estava
pedindo fortemente que o jogo fosse mais fácil.
Por outro lado, o quebra-cabeça mais difícil do jogo, o babel fish puzzle, tornou-se um clássico
reverenciado, e a Infocom até começou a vender camisetas dizendo: “I Got the Babel Fish”.
Portanto, é possível que, enquanto algumas pessoas se desanimaram com o nível de dificuldade,
outras se sentiram atraídas por ele. Meu sentimento era, e continua sendo, que as pessoas que acham
o jogo muito difícil podem obter dicas, enquanto as pessoas que acham o jogo muito fácil estão ferradas
porque não há como torná-lo mais difícil.
Outro fator que contribuiu para a dificuldade pode ter sido o cronograma abreviado de testes
para o jogo, pois um cronograma já agressivo foi agravado ainda mais pelo feitiço de procrastinação
de Douglas. Mais tempo no teste geralmente resulta em um jogo mais fácil, porque a tendência é que,
se mesmo um único testador achar um quebra-cabeça muito difícil, ele deve ser facilitado.
A Mind Forever Voyaging está quase perdendo o humor pelo qual você é tão conhecido em seus
outros títulos, mas acho que é um dos seus melhores trabalhos. Seu objetivo com esse projeto
era fazer um jogo mais sério?
Sim, em parte isso foi uma reação por ter acabado de completar um jogo puramente cômico (HHGTTG),
e em parte a sensação de que a ficção interativa era um meio tão atraente que realmente “tomava” a
vida de alguém por dias a fio, era uma maneira ideal divulgar uma mensagem política/social. Foi minha
tentativa de mudar o mundo, por assim dizer.
O objetivo não era apenas fazer um trabalho mais sério e que tivesse uma mensagem, mas também
criar um trabalho que se afastasse dos quebra-cabeças e confiasse mais em sua história.
A pretensão da existência do jogador no AMFV é muito interessante e uma mudança em relação

a outros jogos da Infocom. Você sentiu a necessidade de “quebrar o molde” com este título?
Não tenho certeza de qual foi a inspiração para o personagem principal de AMFV ser um computador
autoconsciente, embora eu possa me lembrar do momento em que a ideia me ocorreu, apenas sentado
à mesa da minha sala de jantar com um dos meus colegas de quarto, jantando . As diferenças de
navegação e interface pareciam apenas uma extensão natural dessa decisão inicial. “Quebrar o molde”
dessa forma não estava em minha mente tanto quanto “quebrar o molde” no conteúdo do jogo, como
mencionei anteriormente.
Você encontrou muita resistência dentro da Infocom para fazer o título, ou o sucesso
de seus jogos anteriores lhe deu a liberdade de fazer o que quisesse? Havia medo de
que o jogo fosse muito diferente?
Nenhuma resistência, e com certeza, o fato de meus jogos até agora terem sido críticos e
sucessos de mercado certamente ajudou. Mas a filosofia da Infocom na época era fazer uma
mistura de jogos voltados para nosso público principal - os jogos Zork e os jogos Enchanter ,
por exemplo - junto com mais alguns jogos experimentais destinados a empurrar o envelope
criativamente e tentar expandir o público para ficção interativa. Outro exemplo desta última
categoria foram os jogos de “nível júnior” como Seastalker e Wishbringer, que foram uma
tentativa de trazer ficção interativa para um público mais jovem.
Houve algumas pequenas preocupações de que o jogo fosse um pouco sem quebra-cabeças
e, de fato, reforçamos os quebra-cabeças na última seção – não na seção do epílogo, mas
onde Ryder vem e ocupa o complexo.
AMFV também empurrou o envelope na direção técnica, sendo o primeiro jogo da linha
“Interactive Fiction Plus”, exigindo 128K de memória em vez de apenas 64K. Também era
cerca de duas vezes maior do que qualquer outro jogo da Infocom até hoje.
Como você mencionou, as implicações morais do jogo são particularmente fortes.

Por que você não fez um jogo sério desde então?
Eu gostaria porque gostei muito de criar AMFV, e ainda sinto que os jogos de computador
podem ter tanto um componente artístico quanto livros, filmes, teatro, etc.
E eu recebi muito feedback ao longo dos anos de pessoas que foram impactadas pelo AMFV.
Algumas pessoas me mencionaram que entraram na indústria de jogos de computador por
causa do jogo.
Infelizmente, embora o AMFV tenha tido um impacto bastante significativo nas pessoas
que o jogaram, não houve tantas pessoas que o jogaram ou compraram em comparação com
outros jogos da Infocom: cerca de trinta mil. E o tipo de liberdade criativa que tive na Infocom
não existe desde então. Com os orçamentos de jogos chegando a sete dígitos, os editores
não estão interessados em nada que seja de alguma forma não comprovado ou experimental.
Alguns anos atrás, eu estava envolvido em um grupo que estava tentando montar um
jogo de aventura cujo objetivo, além do entretenimento, era expor a situação do Tibete
ocupado pelos chineses. Uma das pessoas envolvidas foi Bob Thurman, professor da
Universidade de Columbia que é um dos líderes do movimento Free Tibet.
Ele também é o pai de Uma Thurman, que estaria no jogo e teria trazido várias outras
celebridades de Hollywood. Não apenas atores, mas pessoas como Philip Glass para fazer a
trilha, etc. Havia até a possibilidade de uma participação especial do Dalai Lama. Mesmo com
todo esse valor de marquise, não conseguimos encontrar um editor que estivesse interessado.
Mas parece que obras sérias podem existir em outras mídias, ao lado de obras mais
“divertidas” ou “leves”. Por que você acha que esse não é o caso em jogos de
computador?
Acho que um problema é que a indústria de jogos tende a ser menos lucrativa do que outras
mídias. Ouvi dizer, por exemplo, que é muito raro um filme perder dinheiro depois que tudo é
dito e feito, incluindo distribuição estrangeira, vídeo e tudo mais. O vasto
a maioria dos jogos de computador perde dinheiro. Então eu acho que por mais difícil que seja no
cinema fazer algo que seja meio experimental ou um pouco diferente, é muito mais difícil na indústria
de jogos de computador. Os executivos do meu setor têm muito mais medo de fazer qualquer coisa
para quebrar as expectativas.
Acho que outra diferença é que há um caminho para os filmes mais artísticos e menos caros.
Realmente não existe um caminho semelhante como esse na indústria de jogos de computador.
Existem alguns sinais de que talvez algo possa estar se desenvolvendo na Internet. É muito
encorajador que a Game Developers Conference esteja organizando o Independent Games Festival,
e também estou encorajado pelo trabalho que está saindo da Garage Games em Oregon. Mas, na
maioria das vezes, não há nada como um Blair Witch Project ou um Crying Game que a indústria de
jogos de computador possa realmente apontar.
Então, acho que sem um caminho para esse tipo de jogo mais experimental, e com os editores
sendo ainda mais conservadores do que em outras indústrias, o ponto principal é que os editores
querem o “jogo seguro”. E os jogos seguros tendem a ser aqueles que não são sérios ou orientados
a mensagens.
Então você acha que a distribuição pela Internet pode levar à criação de obras mais sérias?
Bem, acho que isso pode acontecer se um canal de distribuição se unir, e a Internet parece ser a
melhor aposta para isso. E não é apenas distribuição, mas também do lado das relações públicas.
Todas as grandes revistas ignoram praticamente tudo, exceto os jogos das grandes editoras. Na
verdade, lembro-me de uma pequena sinopse, e acho que foi apenas na coluna de alguém. Não era
a revista revisando um jogo, mas apenas um dos colunistas mencionando que havia encontrado um
jogo de que gostava e que talvez tivesse três polegadas de coluna. E era esse jogo de baixíssimo
valor de produção que estava sendo distribuído pela Internet como shareware, e soava muito bem,
como o tipo de jogo que eu gostaria. Então fui em frente e baixei. E realmente se destacou como
uma verdadeira raridade para uma revista de jogos de computador ter qualquer menção a um jogo
desse tipo.
E certamente, além de ter a distribuição para algo assim, você também precisa ter algum
método para passar a palavra às pessoas. Você pode ter um sistema de distribuição perfeitamente
bom, e se ninguém o encontrar, e daí? Mas acho que se algo assim se fundir, haverá um caminho
para alguém fazer um jogo relativamente barato, algo que poderia ser feito em uma garagem, mas
que tem algo realmente interessante, que empurra o envelope de alguma outra forma do que valores
de produção realmente altos. Pode ser algo que crie um novo gênero, como um SimCity.
Como surgiram as Deusas de Couro de Fobos ?

Uma história bem engraçada. Quando a Infocom ainda era muito jovem e pequena, alguns meses
depois de se mudar para seus primeiros escritórios em Cambridge, foi decidido fazer uma pequena
festa de cerveja e pizza para nosso punhado de funcionários e consultores, o conselho de
administração, varejistas locais, e pessoas de empresas com as quais trabalhávamos, como nossa
agência de publicidade ou nosso depósito de produção. Foi uma reunião muito informal de apenas
algumas dúzias de pessoas, mas foi a primeira função social da Infocom, e Joel Berez, presidente
da Infocom, e Marc Blank foram extremamente hiperativos em vê-la sair perfeitamente.
A festa foi realizada na grande sala central do escritório da Infocom, que também funcionava como
sala de reuniões e a “microsala” onde tínhamos nosso único Apple II, nosso único
Atari 800, nosso TRS-80, etc. Uma parede inteira desta sala era um único quadro-negro enorme com
uma tabela manuscrita permanente de todos os números de versão em lançamento.
Algo assim:
TRS-80 TRS-80 maçã Atari IBM DEZ

Modelo 1 Modelo III II 800 computador PDP-11
Zork I 42 42 44 45 42 45
Zork II 17 17 17 19 17 17
Prazo final 31 31 29 30 33 33
Zork III 10 12 12 10 13 13
Starcross 28 29 30 28 28 31
Ou seja, toda vez que uma nova versão de um jogo era compilada internamente, era dado um
novo número de versão. Quando um determinado número de versão foi lançado em uma determinada máquina,
esse número seria escrito no quadro. Se o fornecimento de, digamos, Apple II Zork IIIs
acabasse, pediríamos mais com a última versão aprovada e esse número específico no quadro seria
atualizado.
Então, para voltar ao ponto desta história, pouco antes desta festa eu calmamente fui
ao tabuleiro e adicionou uma linha para um jogo chamado Leather Goddesses of Phobos. Foi apenas um
hack, e eu escolhi o nome como algo que seria um pouco embaraçoso, mas
não horrível. Acontece que Joel o viu antes que alguém chegasse e o apagou em pânico.
No entanto, o nome pegou, e por anos depois, sempre que alguém precisava conectar
o nome de um nome de jogo inexistente em uma frase, seria Leather Goddesses of
Fobos.
Então, em algum momento de 1985, tive a ideia de realmente fazer um jogo
aquele nome. Afinal, todo mundo adorava o nome e o adorava há anos. eu
trouxe isso como um projeto que seria um pouco atrevido, mas isso foi realmente mais uma decolagem
em — e carinhoso tributo a — SF pulp dos anos 30. A ideia foi imediatamente aceita por
Marc e os outros escritores de jogos, bem como por Mike Dornbrook, meu ex-colega de quarto, que
a essa altura havia se formado na escola de negócios e retornado à Infocom para liderar
marketing.
A alta administração levou mais tempo para convencer, principalmente nosso CEO sem humor, Al
Vezza, que estava realmente interessado apenas no lado de produtos de negócios da empresa e
achar qualquer jogo de mau gosto, mesmo sendo um grande sucesso e
estavam financiando o projeto de banco de dados. Na verdade, um ano depois, quando o LGOP estava quase pronto,
e a Infocom faliu pelo esforço de produtos de negócios, a Infocom estava na
processo de aquisição pela Activision. O presidente da Activision, Jim Levy (que entendia os jogos e o
desenvolvimento de jogos), estava sendo mostrado nos escritórios por Al Vezza.
LGOP surgiu, e Al disse rápida e nervosamente: “Claro, isso não é necessariamente
o último nome”. Jim rugiu: “O quê? Eu não chamaria de outra coisa!” Naturalmente isso
fez com que todos se sentissem muito melhor com a aquisição. Infelizmente, Jim foi demitido pelo
conselho de administração da Activision cerca de um ano depois disso.
Como você começou a trabalhar no Zork Zero?

Foi minha ideia fazer uma prequela do jogo, e todos adoraram a ideia de chamar essa prequela de Zork
Zero. Ele zombou de toda a síndrome da sequela que se apoderou e continua a dominar a indústria de
jogos de computador. Eu tinha escrito Sorcerer, o segundo jogo da trilogia Enchanter que pode ser
considerado não oficialmente como Zork V. Estava no mesmo universo de Zork, e como parte da escrita
do jogo eu compilei o primeiro compêndio da história de Zork , datas, lugares , personagens, etc.,
vasculhando os jogos Zork e o primeiro jogo Enchanter , e então tentando ligá-los todos juntos com uma
geografia e história abrangentes. Houve alguma resistência inicial a isso por parte dos autores originais,
mas rapidamente se tornou aparente o quão necessário – e mais tarde, quão popular – era um passo.
Então, eu era bastante versado no meio Zork quando Zork Zero começou a ser discutido. Na
verdade, acho seguro dizer que eu era mais especialista em detalhes relacionados ao Zork do que os
autores originais. Zork Zero estava na minha lista de futuros projetos em potencial há alguns anos, e
provavelmente teria sido meu jogo no ano em que fiz a sequência de Planetfall, Stationfall , exceto que
Brian Moriarty havia acabado de terminar um híbrido de RPG de aventura que tínhamos decidiu colocar
no universo Zork chamado Beyond Zork, e dois jogos Zork tão próximos não funcionariam.
Como um aparte, depois de terminar Stationfall, a decisão foi entre Zork Zero e uma ideia que eu
vinha mexendo há anos: um jogo de aventura ambientado no Titanic durante sua viagem inaugural. Mas
a administração da Infocom finalmente decidiu – e ouvi isso muitas vezes nos próximos anos enquanto
lancei este projeto para muitas editoras durante meus dias pós-Infocom – “as pessoas não estão
interessadas no Titanic”. Então, quando o filme de Cameron saiu e se tornou o filme mais popular de
todos os tempos, foi um momento agridoce para mim.
Quando veio a decisão de seguir em frente com o Zork Zero, a primeira coisa que fiz foi convocar
uma sessão de brainstorming com os “implementadores” originais, ou três em cada quatro, pelo menos.
Marc Blank (que há muito deixou a Infocom e se mudou para a costa oeste), Dave Lebling (ainda um
autor de jogos na Infocom) e Tim Anderson (ainda um programador de projetos especiais “cientista
sênior” da Infocom) estavam todos lá. O quarto autor original, Bruce Daniels, há muito se mudou. A única
coisa definida nesta sessão era que o jogo seria uma prequela e que terminaria “a oeste de uma casa
branca”. Esta sessão produziu a estrutura geral do jogo: o cenário do castelo de Dimwit, as razões para
a destruição da dinastia Flathead e a coleção de artefatos pertencentes a cada um dos doze Flatheads.
Zork Zero é um estranho híbrido de jogo: é quase todo texto, com apenas alguns recortes de
gráficos. Qual foi a ideia geral por trás do design?
Na época, a Infocom estava passando por algum estresse e busca de alma. Nossas vendas vinham
caindo há vários anos. Entrando no ciclo de produto de 1987, o pensamento da gerência da Infocom/
Activision era “Existem n mil fãs de jogos de aventura hardcore que comprarão qualquer jogo da Infocom,
não importa quantos nós lancemos. Portanto, o
A estratégia deve ser lançar o maior número possível de jogos.” Lançamos oito jogos durante
1987, enquanto em qualquer ano anterior nunca lançamos mais de cinco. E todos se saíram muito
mal. Assim, entrando no ciclo do produto de 1988, o pensamento era “Aventuras de texto são uma
raça em extinção; precisamos adicionar gráficos aos nossos jogos.”
Ao longo da existência da Infocom, sempre denegrimos as aventuras gráficas e, durante o
início e meados dos anos 80, isso era bastante correto. Enquanto os primeiros micros eram muito
bons em gráficos no estilo arcade, eles eram péssimos em desenhar imagens, como visto nas
aventuras gráficas daquele período. Mas então o Macintosh foi lançado, fornecendo gráficos em
preto e branco muito melhores do que os vistos até então, seguido pelo Amiga, que fez gráficos
em cores muito melhores do que qualquer um tinha visto antes. As placas gráficas IBM-PC também
estavam melhorando. Assim, os gráficos estavam começando a parecer razoáveis e dar a todo o
texto uma corrida pelo seu dinheiro. A Infocom demorou um pouco para chegar a essa verdade.
Assim, no final de 87 e início de 88, o sistema de desenvolvimento da Infocom estava sendo
completamente reformulado para lidar com a adição de gráficos. Ao mesmo tempo, os autores dos
jogos lutavam coletiva e individualmente com a questão de como usar gráficos em jogos.
Algumas pessoas decidiram usá-los apenas para ilustrar cenas ocasionais, da mesma forma que
um livro com ilustrações ocasionais pode usar imagens. Isto é o que Dave Lebling fez com sua
versão IF do Shogun.
Como o objetivo de Zork Zero era ser um clássico jogo de aventura baseado em quebra-
cabeças em esteróides, decidi que queria principalmente usar gráficos para situações baseadas
em quebra-cabeças, então criei cinco quebra-cabeças gráficos: um rebus, uma torre de Hanói, um
jogo de peg-jumping, um jogo de contagem de pedrinhas chamado nim e um jogo de cartas
chamado double fanucci. Mas eu não queria que o jogo parecesse apenas uma aventura de texto
antiquada o resto do tempo, então desenhei as três bordas decorativas diferentes: uma para fora,
uma para edifícios internos e uma para masmorras internas. Eu também dei um ícone a cada
quarto e, em seguida, usei esses ícones para os mapas gráficos na tela, que era um dispositivo mnemônico
Por fim, usei ilustrações gráficas da Enciclopédia Frobozzica, um livro da biblioteca que era
basicamente uma versão in-game do compêndio do universo Zork que comecei a compilar enquanto
trabalhava em Sorcerer.
Mas nenhum dos jogos gráficos vendeu melhor do que os jogos de texto do ano anterior, e
em meados de 1989 a Activision decidiu fechar a Infocom.
Eles não melhoraram as vendas?

Eu diria que durante o ano anterior, '87, todos os jogos venderam cerca de vinte mil. E os quatro
jogos gráficos que saíram no final de 88 e início de 89 também venderam em torno desses mesmos
números.
Então, por que você acha que foi isso? LucasArts e Sierra parecem ter tido bastante sucesso
com suas aventuras gráficas nessa época.
Sim, na época a Sierra vendia várias centenas de milhares de cópias de seus jogos. Mas
certamente não tanto Lucas. Lucas estava de fato bastante frustrado porque eles estavam lançando
jogos que eles achavam serem tecnicamente muito idênticos aos jogos da Sierra e em termos de
escrita e conteúdo eram realmente superiores a eles, e ainda vendendo apenas um quinto ou um
terço do número de cópias. E eu realmente não sei o que pensar sobre isso. Pode ser que Sierra
estivesse fazendo um bom trabalho produzindo jogos que eram muito bem
voltado para um público mediano, para o público mais amplo. E assim como muitos dos jogos da Infocom,
os jogos de Lucas tendiam a atrair um público um pouco mais sofisticado e, portanto, menor.
Então é por isso que você acha que os jogos gráficos da Infocom não decolaram?
Bem não. Eu acho que era muito mais que naquele ponto os jogos gráficos se tornaram bastante
sofisticados em termos de não serem apenas aventuras gráficas, mas aventuras gráficas animadas, como
os jogos Sierra e Lucas daquele período. E os jogos da Infocom não eram mais do que aventuras de texto
ilustradas. Mesmo que os gráficos tenham sido introduzidos, eu não acho que foi percebido como um novo
animal do que a Infocom vinha produzindo até aquele momento.
Então você acha que a Infocom poderia ter sido mais bem-sucedida usando gráficos se eles os
tivessem tornado mais integrantes do design dos jogos?
É difícil dizer o que poderia ter acontecido em 1987 se a Infocom tivesse dito: “Vamos sair e imitar
exatamente o motor de jogo de aventura Sierra do jeito que Lucas fez”. Por um lado, sempre me pareceu
que quem chega primeiro a um mercado é o dono. E acho que essa é outra razão pela qual Sierra realmente
dominou Lucas naquele momento.
Certamente houve muitas empresas que entraram, fizeram aventuras de texto, colocaram muito esforço
nisso e fizeram algumas aventuras de texto muito boas. Por exemplo, a Synapse Soft ware, em meados
dos anos 80, com seu mecanismo BTZ, fez alguns jogos muito bons. Mas eles praticamente não tiveram
vendas. É muito difícil enfrentar um líder de mercado, mesmo com jogos que são tão bons, porque é difícil
compensar essa vantagem. Por outro lado, Infocom certamente tinha um nome que era bastante sinônimo
de jogos de aventura, então se houvesse alguém que pudesse ter feito progresso contra a vantagem de
Sierra, provavelmente teria sido Infocom. Mas neste ponto é completamente acadêmico, obviamente.
Todos os jogos da Infocom correram praticamente do mesmo sistema de narrativa, usando

mecânicas de jogo quase idênticas de jogo para jogo. Você acha que essa tecnologia e design
compartilhados funcionaram bem?
Funcionou muito bem para a época. Isso nos permitiu colocar toda a nossa linha de jogos em funcionamento
em um novo computador poucas semanas após seu lançamento. Essa foi uma tremenda vantagem
comercial durante uma época em que o mercado estava fragmentado entre muitas plataformas diferentes
e plataformas novas e incompatíveis surgiam o tempo todo. Por exemplo, houve uma época em que havia
cerca de vinte e cinco jogos disponíveis para o Macintosh original, e quinze deles eram jogos da Infocom.
Isso irritou muito o pessoal do Mac na Apple, já que não usávamos o Mac GUI.
Além disso, o tipo de jogo que estávamos fazendo se prestava bem a um “olhar de linha”, tanto na
embalagem quanto nos próprios jogos. Isso deu a eles uma sensação literária: todos os jogos da Infocom
parecem semelhantes da mesma forma que todos os livros são semelhantes.
Mas ainda hoje, os motores são geralmente usados para vários jogos, principalmente se você incluir
pacotes de expansão. E mesmo que os produtos finais pareçam bastante semelhantes, a biblioteca Infocom
na verdade representa várias gerações do mecanismo ZIL.
Houve uma grande reformulação quando a linha “Interactive Fiction Plus” veio
junto, começando com AMFV, e depois outra grande reformulação por volta de 1987 com a
introdução de um analisador totalmente novo e muito mais poderoso. E então, é claro, houve uma
grande reformulação para a introdução de gráficos em 88.
Muito esforço foi colocado no analisador da Infocom, e ele foi bem respeitado como o melhor
do setor. Alguma vez ficou tão bom que você pensou que não poderia ficar melhor?
Certamente, na época do novo analisador do zero, por volta de 1987, pensei que tínhamos um
analisador que, embora pudesse ser melhorado, era tão bom quanto precisávamos para um
ambiente de jogo. Afinal, não estávamos tentando entender toda a linguagem natural, apenas frases
imperativas no presente. A única área em que eu gostaria de ver melhorias contínuas era na área
de conversar com NPCs. Mas o principal problema em fazer os NPCs parecerem mais profundos e
reais não era devido às limitações do analisador, era apenas a quantidade de trabalho necessária
para dar a um personagem respostas diferentes o suficiente para evitar que ele parecesse
“enlatado”, mesmo por um curto período. enquanto.
Eu pessoalmente amei e ainda amo a interface baseada em texto, tanto do ponto de vista do
jogador quanto do escritor do jogo. Mas eu não me importo de ler ou digitar, e algumas pessoas não
gostam de um ou de outro ou de ambos, e isso tende a limitar nosso público, especialmente porque
as alternativas sem leitura e sem digitação proliferaram. Mas acho que a interface de entrada
baseada em parser é de longe a mais poderosa e flexível, permitindo que o usuário pelo menos
tente qualquer coisa que possa pensar e permitindo que o escritor do jogo desenvolva todos os
tipos de quebra-cabeças que não ser possível com uma interface de apontar e clicar. Tantos jogos
de aventura de apontar e clicar se tornaram uma questão de simplesmente clicar em cada objeto à
vista em todas as combinações possíveis, em vez de pensar no quebra-cabeça.
O que você diz às críticas de que a interface do analisador muitas vezes se mostrou mais
frustrante do que intuitiva, e que embora o jogador possa saber o que quer fazer, ele ou ela
pode ter problemas para encontrar as palavras corretas para essa ação?
Eu acho que é simplesmente um analisador ruim. Lembro-me de jogar um jogo da Sierra onde havia
o que eu achava que era um cavalo na tela, e eu estava tentando fazer todo tipo de coisa com o
cavalo, e depois descobri que era um unicórnio. Naquela época, quando a resolução era tão
granulada, eu simplesmente não percebia o único pixel que indicava uma buzina.
Então, quando eu estava dizendo coisas como “Suba no cavalo”, não estava dizendo “Não há
cavalo aqui”, o que teria me alertado que talvez fosse um unicórnio. Em vez disso, estava
respondendo com “Você não pode fazer isso” ou algo muito menos útil. Então, para mim, a falha
não era que o jogo tivesse uma interface de analisador; a falha foi que o jogo não foi bem escrito
para começar ou bem testado.
Certamente, quando alguém se senta com o jogo Infocom mais polido, tende a haver,
dependendo da pessoa, um período de um minuto ou meia hora em que eles estão meio que se
debatendo e tentando pegar o jeito da sintaxe. Mas para a maioria das pessoas, uma vez que
passam por esse tipo inicial de confusão, um jogo de análise bem escrito não é particularmente
frustrante. Mesmo nos jogos posteriores da Infocom, estávamos começando a introduzir algumas
coisas que realmente visavam tornar essa experiência inicial menos difícil: tentar perceber o tipo de
coisas que os jogadores faziam enquanto estavam nesse modo e fazer sugestões para empurrá-los
na direção certa. O jogo tentaria pegar se eles
digitado em um tipo impróprio de uma frase, como fazer uma pergunta ou usar uma voz não
imperativa. Ele tentaria perceber se eles fizeram isso duas ou três vezes seguidas e depois apenas
dizer: “A maneira de falar com o jogo é” e, em seguida, dar alguns exemplos.
E acho que a coisa realmente crítica sobre a interface do analisador não tem nada a ver
com a digitação, é possível usar linguagem natural para suas entradas.
Você já se sentiu limitado pelo sistema de desenvolvimento da Infocom?

O sistema era extremamente poderoso e flexível, e podia crescer para atender a necessidade de um
determinado jogo com bastante facilidade. Uma pequena exceção foi qualquer mudança que exigisse
uma mudança no “intérprete”. Cada jogo vendido consistia no componente do jogo, que era
independente da máquina, e um interpretador, que era um programa específico da máquina que
permitia que o componente do jogo fosse executado naquele microcomputador específico. Como
havia vinte ou mais intérpretes (um para o Apple II, um para o Mac, um para o DEC Rainbow, um
para o NEC PC-800, etc.) mais de vinte programas. Portanto, isso só poderia ser feito raramente ou
quando fosse extremamente importante, como alterar a linha de status no Prazo para exibir o tempo
em vez de pontuação e movimentos.
Um limite mais rigoroso foi imposto pelo desejo de rodar na maior variedade possível de
máquinas, então sempre fomos limitados pelas capacidades das menores e mais fracas dessas
máquinas. Nos primeiros dias, a máquina limitante era o TRS-80 Modelo 1, cuja capacidade de drive
de disco limitava os primeiros jogos a um tamanho executável de 78K.
À medida que as máquinas mais antigas “caíram” da lista de suportes, esse limite aumentou
lentamente, mas mesmo quando escrevi HHGTTG, os jogos ainda estavam limitados a cerca de
110K. Geralmente, esse limite seria alcançado no meio do teste e, em seguida, cada adição ao jogo,
para corrigir um bug ou lidar com uma entrada razoável de um testador, exigiria pesquisas cada vez
mais dolorosas por algum texto - qualquer texto - para cortar ou condensar . Às vezes, essa era uma
boa disciplina, escrever um texto enxuto e direto ao ponto. Mas muitas vezes se tornou horrível e nos
fez sentir como se estivéssemos massacrando nossos próprios filhos. OK, isso é um pequeno exagero.
Como funcionou o processo de desenvolvimento na Infocom? Você foi bastante livre para
escolher quais jogos você fez?
Nos primeiros dias, as coisas eram bastante informais e as decisões eram tomadas por consenso
bastante informal. Nos últimos dias, principalmente após a aquisição pela Activision, as decisões
eram muito mais exigidas pela alta administração. Geralmente, a escolha de um jogo foi deixada para
o autor individual. Autores com mais histórico, como Dave Lebling e eu, tinham mais margem de
manobra do que um implementador novato. É claro que também havia considerações de marketing,
como o forte desejo de completar trilogias ou as oportunidades de trabalhar com uma propriedade
licenciada como a HHGTTG.
Uma coisa que foi padrão durante os mais de sete anos em que estive na Infocom foram os
“Almoços dos Implementadores” ou, abreviadamente, “Almoços dos Imps”. Eram almoços semanais
nos quais os criadores de jogos se reuniam para falar sobre os jogos em desenvolvimento,
compartilhar ideias, criticar o trabalho uns dos outros, etc. Foi provavelmente o par de horas mais
divertido da semana.
Não houve muita supervisão durante os primeiros meses de vida de um jogo, enquanto o
implementador estava trabalhando praticamente sozinho, exceto nos Almoços Imp, qualquer
brainstorming improvisado, ou pedidos de ajuda/conselhos. Mas uma vez que o jogo entrou em testes,
primeiro entre os outros escritores, depois com o grupo de testes interno e, finalmente, com os
“testadores beta” externos, o jogo ficou sob o microscópio por meses a fio. Durante esse período, bugs
e sugestões muitas vezes chegavam aos milhares.
Quão fluido e mutável foi o design de um jogo da Infocom?

Isso variou de implementador para implementador. Meu próprio estilo era fazer um pouco de design no
papel antes de começar, principalmente na criação da geografia e quaisquer documentos de “fundo do
universo”, como uma linha do tempo no caso de Sorcerer, ou as regras da linguagem do planeta
deserto em Planetfall . Mas, na maioria das vezes, eu simplesmente entrava e começava a codificar
com a maioria dos personagens e quebra-cabeças vivendo apenas na minha cabeça.
O sistema de desenvolvimento da Infocom foi fantástico, comparado aos sistemas gráficos com
os quais trabalhei desde aqueles dias, porque apenas o escritor do jogo trabalhando sozinho poderia
implementar uma seção inteira do jogo em apenas alguns dias e depois experimentá-lo e veja como
funcionou. Se tivesse que ser descartado porque não estava funcionando, não seria um grande
desperdício de tempo ou recursos. Isso permitiu muito voltar e reescrever grandes seções do jogo, o
que é inconcebível hoje em dia, onde tal decisão pode significar jogar fora cem mil dólares em gráficos.
Houve muitos testes nos títulos da Infocom?

Muitos testes. Como o sistema de desenvolvimento foi bastante estável durante a maior parte da vida
da Infocom, os testes foram capazes de se concentrar em bugs específicos do jogo e no conteúdo do
jogo. Idealmente, haveria cerca de duas semanas de testes “pré-alfa” onde os outros criadores de
jogos jogariam um jogo, seguidos por dois a três meses de testes alfa com nossos testadores internos,
seguidos por um mês de testes beta com alguns de uma dúzia de voluntários externos. Se o tempo
permitisse, havia também um mês de testes “gama”, que era exatamente como o teste beta, exceto
que a ideia era não mudar nada, a menos que um problema realmente grande fosse encontrado.
O teste de bugs específicos do jogo e do conteúdo do jogo foi bastante con atualmente, embora
mais pesado para o conteúdo durante os primeiros dias de teste e mais para os bugs nos últimos dias,
quando se tornou cada vez menos desejável fazer alterações significativas ao conteúdo do jogo.
O período de teste inicial foi provavelmente o momento mais divertido e emocionante no

desenvolvimento do jogo. Por um lado, depois de meses e meses trabalhando sozinho, sem ter
nenhuma ideia se um jogo era bom além de meus próprios instintos, de repente um monte de pessoas
está jogando o jogo, geralmente gostando e dando toneladas de comentários. É uma verdadeira
corrida. Além disso, tínhamos um recurso de script automático em que nossa rede fazia automaticamente
uma transcrição das sessões de cada jogador, que eu podia ler para ver o que todos estavam tentando
em cada ponto, então muitas vezes encontrava coisas que estavam erradas, mas quais testadores não
necessariamente percebeu que estavam errados. Ou eu encontraria coisas que eles tentaram que
eram tentativas razoáveis de resolver o quebra-cabeça em questão e tentaria recompensar tal tentativa
com uma resposta inteligente ou com uma dica, em vez de apenas uma mensagem padrão como:
“Você não pode colocar uma toalha de mesa nisso.”
Foi durante o período de testes que os jogos ficaram ótimos. Indo para o período de testes, o
jogo era mais como um esqueleto, e o período de testes, como um de nossos testadores
uma vez disse: “coloque carne nos ossos”. Muito humor, as respostas a entradas malucas, os sutis
graus de dificuldade, a eliminação de quebra-cabeças injustos - esses foram todos os produtos do
excelente grupo de testes da Infocom.
A embalagem dos jogos da Infocom era realmente única. Por que a empresa foi além do que
tantos outros editores de jogos fizeram?
Quando a Infocom começou, o padrão para embalagens de jogos de computador era algo semelhante
a uma bolsa Ziploc. Era apenas um saco plástico transparente com tampa Ziploc e um buraco para
pendurar em um pegboard nas lojas; a bolsa conteria um disquete e um manual muitas vezes fotocopiado
de baixo custo. Na verdade, as primeiras versões do Radio Shack do Zork estavam em um pacote assim.
A editora original do Zork I era uma empresa na Califórnia chamada Personal Soft ware. Na
verdade, o gerente de produto da linha Zork na Personal Software era Mitch Kapor, que fundou a Lotus.
Pouco depois de começarem a publicar o Zork, a Personal Software fez sucesso com um programa
chamado Visicalc, o primeiro software de negócios para computadores de sucesso. Eles mudaram seu
nome de Personal Software para Visicorp e decidiram que não queriam perder tempo lidando com jogos
e devolveram Zork à Infocom.
Em vez de encontrar uma nova editora, a Infocom decidiu ser sua própria editora e contratou uma
agência para projetar os pacotes. O resultado foram os pacotes “blister pack” para Zork I e Zork II, a
primeira vez que esses pacotes foram usados para jogos de computador. Este é o tipo de embalagem
em que um pedaço de plástico moldado transparente é colado em um verso de papelão, com o conteúdo
visível através do plástico transparente, neste caso o conteúdo é o manual Zork com o disco fora de
vista atrás dele.
Quando chegou a hora do design da embalagem do terceiro jogo da Infocom, Deadline, Marc Blank
foi à agência com uma série de livros esgotados da década de 1930, escritos por Dennis Wheatley. Com
nomes como Murder Off Miami e Who Killed Robert Prentiss?, os livros eram um portfólio de relatórios e
pistas, assim como um detetive de polícia receberia ao investigar um caso: entrevistas com testemunhas,
cartas datilografadas, notas manuscritas, passagens de trem, jornais recortes, um palito de fósforo usado
e muito mais. A ideia era que você fosse o detetive, e depois de vasculhar as evidências, você deveria
decidir quem era o assassino e como eles fizeram isso, e então abrir uma seção lacrada do livro e ver
se você estava certo.
Marc foi muito influenciado por esses livros na criação de Deadline – na verdade, o título original
de trabalho era Who Killed Marshall Robner? — e ele queria que a agência fosse muito influenciada por
eles na criação da embalagem do Deadline. Marc queria que o jogador se sentisse como um detetive
sendo colocado em um caso desde o momento em que abriu o pacote. Além disso, devido aos limites
estritos do tamanho do jogo, ter relatórios de laboratório e entrevistas com suspeitos no pacote liberou
espaço no jogo para conteúdo mais interativo. O pacote de Deadline que resultou lembra muito aqueles
livros de Dennis Wheatley, com uma foto da cena do crime, entrevistas, impressões digitais, análises de
laboratório de coisas como a xícara de chá encontrada perto do corpo e até um saco de pílulas rotulado
“Pílulas encontradas perto do corpo”. corpo."
Na verdade, esses eram SweetARTS de cor branca.
O pacote Prazo foi um grande sucesso, embora tenhamos cobrado $ 10 a mais por ele, $ 50 MSRP
em vez de $ 40 MSRP. Decidimos que uma ótima embalagem era divertida, agregava grande valor, era
uma ótima maneira de “aumentar o nível” e dificultar a entrada de novos concorrentes em nosso espaço
de mercado e, o mais importante, era uma maneira de desencorajar a pirataria de
nossos jogos. Era mais difícil e menos rentável precisar copiar um monte de elementos de pacote,
bem como o disquete. Além disso, porque os pacotes eram tão elegantes e tão essenciais para a
experiência de jogar o jogo, muitas pessoas não sentiriam que possuíam o jogo a menos que
possuíssem a embalagem original completa.
Os próximos jogos foram Zork III e Starcross. Zork III acabou de ir em um blister para combinar
com seus irmãos, mas Starcross foi colocado em um grande disco voador de plástico, junto com um
mapa de asteróides das proximidades de sua nave. Este pacote, embora problemático para algumas
lojas por causa de seu tamanho e forma, era fenomenalmente atraente e popular. Recentemente, uma
cópia ainda embrulhada de Starcross nesta embalagem original foi vendida por três mil dólares no eBay.
Meu pacote favorito de todos os que trabalhei foi o LGOP, com seu cartão de raspadinha e 3D
comic. A história em quadrinhos foi uma colaboração entre eu, um artista de quadrinhos, e um cara que
se especializou em traduzir desenhos convencionais de quadrinhos 2D em camadas 3D. Para o cartão
de raspadinha, consegui várias dezenas de amostras da empresa que fez os aromas. Cada um estava
em seu próprio cartão com o nome do perfume. Então, um por um, outros funcionários da Infocom
entraram, e eu os vendava e os deixava arranhar cada cheiro e tentar identificá-lo. Dessa forma,
consegui escolher os sete aromas mais reconhecíveis para a embalagem. Foi muito divertido ver que
pensamentos os vários cheiros provocavam nas pessoas, como a pessoa que estava cheirando o
cartão de naftalina e ficou com um sorriso bobo no rosto e disse: “O sótão da minha avó!”
Nós, os implementadores, tínhamos ampla liberdade na escolha dos elementos do pacote, desde
que nos mantivéssemos dentro dos parâmetros orçamentários. Mas o marketing muitas vezes também
tinha boas ideias, sugerindo que minha ideia para um livro no Zork Zero se tornasse um calendário e
sugerindo coisas como o assustador inseto de borracha no pacote Lurking Horror . Mas a maioria das
melhores ideias vieram dos escritores.
As melhores peças de embalagem foram aquelas que foram projetadas desde o início do jogo, em
vez de serem adicionadas como uma reflexão tardia quando o processo de embalagem começou no
meio do alfa. A maioria das outras empresas de jogos tinha proteção antipirataria em seus pacotes,
mas muitas vezes era completamente óbvio e destruidor de humor, como “Digite a sétima palavra na
página 91 do manual”. Com os melhores elementos do pacote da Infocom, você nunca percebeu que
estava envolvido em uma atividade antipirataria, porque os elementos do pacote estavam perfeitamente
interligados com a jogabilidade. E, é claro, nos ambientes de todos os textos de nossos jogos, os
elementos do pacote eram uma ótima maneira de adicionar um toque especial à experiência de jogo.
Parece ter havido uma clara diferença entre os jogos da Infocom e os jogos que o resto da
indústria oferecia, especialmente em termos de um nível consistente de qualidade. Por que você
acha que foi isso? Como essa qualidade foi mantida?
Em parte, foi a filosofia inicial da Infocom, e mesmo antes da Infocom, na criação do Zork, que era
pegar um jogo divertido, Adventure, mas fazê-lo melhor. Então sempre havia um forte desejo de ser o
melhor. Além disso, em parte porque as pessoas que compunham a Infocom eram apenas um grupo
de pessoas realmente inteligentes e talentosas. E em parte foi sorte.
Tivemos sucesso inicial, então quando criamos cada novo jogo podíamos investir muito tempo e
dinheiro nele, sabendo que suas vendas justificariam o investimento, enquanto muitas outras empresas
não podiam assumir esse nível de vendas e, portanto, não podiam arcar com o mesmo nível de
investimento.
Nosso ambiente de desenvolvimento sempre aprimorado, analisador, etc., foi uma grande razão
para o alto nível de qualidade. O talentoso grupo de testes e o tempo que agendamos para testes,
correção de bugs e melhorias gerais foram outro grande fator.
O nível de qualidade consistente da Infocom permitiu que ela resistisse ao “crash” de meados
dos anos 80 com bastante facilidade?
O crash de meados dos anos 80 começou com um crash no lado dos videogames e depois se
espalhou para o mercado de PCs. Muitas empresas tinham uma mistura de SKUs de videogame e
microcomputador, mas a Infocom estava inteiramente no mercado de PCs. Além disso, nossos jogos
eram o menos parecidos com videogames possível. Outra razão pela qual a queda de meados dos
anos 80 teve pouco efeito sobre as vendas de jogos da Infocom foi que estávamos em tantas
máquinas e podíamos entrar rapidamente em qualquer novo computador que fosse lançado. Por
exemplo, o Mac foi lançado no início de 1985, e nossos jogos foram extremamente bem-sucedidos
nos primeiros Macs. E, claro, a alta qualidade ajudou, porque durante qualquer queda são sempre os
produtos ruins que morrem primeiro.
Para mim, parece que os jogos da Infocom são os únicos títulos do início dos anos 80 que não
parecem nada datados. Por que você acha que é isso?
Bem, os gráficos dos jogos no início dos anos 80 parecem horríveis, mas o texto parece texto. Então
o tempo é mais gentil para aventuras de texto. E, como já falamos, os jogos eram de altíssima
qualidade, o que os ajuda a se manter ao longo do tempo. E, uma vez que você eliminou a
obsolescência técnica como um problema, dez a vinte anos não é muito tempo para um trabalho
criativo envelhecer bem ou não bem. Pense em livros, filmes, programas de TV, etc. do mesmo
período. Apenas alguns que eram incomumente atuais parecem datados hoje, e os jogos da Infocom
certamente não eram atuais, com talvez o AMFV como uma única exceção.
E certamente não é incomum que as pessoas continuem a desfrutar dos melhores trabalhos muito
depois de sua criação: I Love Lucy tem quarenta anos, E o Vento Levou tem sessenta anos, os filmes
de Charlie Chaplin e Buster Keaton têm oitenta anos, Alice no País das Maravilhas tem cento e
cinquenta anos, e as peças de Shakespeare têm quatrocentos anos.
A equipe da Infocom achava que as aventuras de texto seriam para sempre?
Nós certamente pensamos que eles iriam evoluir, de maneiras previsíveis e imprevisíveis. Embora
todos tivessem suas próprias ideias, eu diria que por volta de 1985 uma composição do pensamento
naquele momento seria algo assim: os gráficos melhorarão a ponto de valer a pena colocar em jogos
de aventura, haverá uma ênfase crescente em histórias sobre quebra-cabeças, jogos e mundos de
jogos ficarão maiores, haverá personagens mais realistas e críveis em jogos de aventura, muitas
pessoas que foram contadores de histórias de sucesso em outras mídias, como escritores de ficção e
autores de filmes, gravitarão em direção à aventura jogos como o meio de contar histórias do futuro.
Olhando para trás, apenas o primeiro desses pontos aconteceu.
Mas, apesar das mudanças previstas, acho que todos pensaram que os jogos de aventura
existiriam indefinidamente de alguma forma. Acho que ninguém pensou que até o final do século
todas as formas de jogos de aventura estariam virtualmente extintas como um tipo de jogo comercial.
É interessante que os livros pareçam coexistir ao lado da televisão e do cinema. Por que você
acha que as aventuras de texto não parecem fazer a mesma coisa?
Ainda existe um mercado bastante vigoroso para jogos de aventura de texto. Ainda tem gente
escrevendo e tocando, só não é um mercado econômico. As pessoas que os escrevem não estão
escrevendo para pagar, estão apenas escrevendo por prazer, e as pessoas que os interpretam não
estão pagando pela experiência. E acho que uma coisa semelhante entre escrever aventuras de
texto e escrever livros é que tende a ser uma operação de uma pessoa, supondo que você use um
sistema de escrita de aventura de texto existente. Uma pessoa sem muito treinamento especializado
pode sair e em poucos meses escrever um jogo de aventura de texto, assim como alguém com uma
máquina de escrever, processador de texto ou grande pilha de papel e uma caneta pode sair e
escrever romances.
Talvez seja apenas uma questão de escala, como você mencionou antes. O número total de
pessoas interessadas em jogar um jogo de computador é muito menor do que o número de
pessoas interessadas em outras mídias tradicionais e não interativas.
Eu acho que isso provavelmente é verdade, embora eu não saiba os números de imediato. Mas
imagino que um livro best-seller provavelmente não tenha muito mais do que um milhão de cópias
ou algo assim. Parece que me lembro que na época em que fizemos o jogo, um conjunto de livros
do Mochileiro havia vendido sete milhões de cópias, então talvez dois milhões cada? E certamente
o número de pessoas que assistem televisão é certamente dezenas de vezes maior do que isso.
A interface para a série Spellcasting foi interessante. Permitiu que os jogos funcionassem
exatamente como as aventuras de texto da Infocom, mas depois adicionou a capacidade de o
jogador usar apenas o mouse para jogar clicando na lista de verbos, substantivos e assim
por diante. Qual foi a ideia por trás dessa nova interface?
Essa interface veio do pessoal
da Legend, particularmente
Bob Bates, que começou a
trabalhar nessa interface para
seu jogo pós- Arthur Infocom
The Abyss, baseado no filme
ainda não lançado na época. O
jogo foi cancelado quando a
Infocom foi fechada pela
Activision, e quando a Legend
decidiu começar a publicar
seus próprios jogos de aventura,
Spellcasting 101: Feiticeiros pegam todas as garotas
eles continuaram desenvolvendo
essa interface.
O impulso para a interface não foi um sentimento particular de que esta era uma interface boa/
útil/amigável/inteligente para jogar jogos de aventura, mas sim uma sensação de que as aventuras
de texto estavam morrendo, que as pessoas queriam imagens na tela o tempo todo e que as pessoas
odiavam digitar. Nunca gostei tanto da interface. A parte gráfica da foto era bem legal, permitindo
que você se movesse apenas clicando duas vezes nas portas da foto, ou pegando coisas clicando
duas vezes nelas. Mas eu não me importei com o
menus por uma série de razões. Primeiro, eles eram muito mais complicados e demorados do
que apenas digitar entradas. Dois, eram brindes porque lhe davam uma lista de todos os verbos
possíveis e todos os objetos visíveis. Terceiro, eles deram muito trabalho extra na implementação
do jogo, para pouco benefício extra. E quatro, eles excluíram quaisquer quebra-cabeças que
envolvessem referências a objetos não visíveis.
Além disso, os jogos Spellcasting foram além de Zork Zero por terem gráficos completos.
Como resultado, você fez alguma alteração na maneira como escreveu e projetou seus
jogos?
Não muito. Acho que poderia pegar qualquer um dos meus jogos Infocom sem gráficos, pedir a
um artista para produzir gráficos para cada sala e adaptá-los ao mecanismo gráfico do Legend.
A interface orientada por menus seria mais problemática do que os gráficos. Por outro lado, todos
os jogos que fiz para o Legend tinham uma tecla de atalho que permitia desligar os gráficos e
jogá-los como uma pura aventura de texto à moda antiga. Portanto, os gráficos sempre foram
apenas um extra, não obrigatório.
Em termos de experiência geral de jogo, o que você acha que foi ganho e perdido pela
adição de gráficos às aventuras de texto?
Há a discussão interminável,
apaixonada e quase religiosa
sobre se as imagens que
criamos em nossa imaginação
com base em uma descrição
de texto são muito mais vívidas
do que qualquer coisa criada
mesmo em um monitor de
milhões de cores de alta
resolução. Meu próprio
sentimento é que provavelmente
existem algumas pessoas que
criam imagens melhores em Spellcasting 201: O Aparelho do Feiticeiro
sua imaginação, e algumas cuja imaginação é muito fraca. Ainda assim, a mudança resultou em
jogos de aventura movendo-se em uma direção um pouco mais baixa, menos literária.
Em segundo lugar, havia alguns quebra-cabeças impedidos por gráficos. Por exemplo,
quebra-cabeças que dependiam de descrever algo e deixar os jogadores descobrirem o que era
por exame e experimentação. Um exemplo de Zork I: o bote não inflado que não é chamado
assim, é chamado de “pilha de plástico”. Você tem que examiná-lo e encontrar a válvula e tentar
usar a bomba de ar, e só então você descobre que é uma jangada. Em um jogo gráfico, você
seria capaz de ver instantaneamente que era uma jangada não inflada.
Em terceiro lugar, e mais importante, os gráficos custam muito mais do que o texto. Como
Brian Moriarty coloca: “Em aventuras gráficas, você tem que mostrar tudo – e você não pode se
dar ao luxo de mostrar nada!” Como resultado, os jogos gráficos têm muito menos de tudo, mas
o mais importante, muito menos soluções alternativas para quebra-cabeças, rotas alternativas
através do jogo, respostas interessantes a tentativas razoáveis, mas incorretas de resolver um
quebra-cabeça, menos respostas humorísticas a ações etc. Em outras palavras, aventuras gráficas
têm muito menos “carne nos ossos” do que as aventuras de texto da Infocom. Você recebe muito mais
dessas respostas de baunilha enfurecedoras, como “Você não pode fazer isso” ou seu personagem/
avatar apenas dando de ombros para você.
Como surgiu a Superhero League of Hoboken ? Você queria abordar esse gênero por um tempo?
Bem, eu queria fazer um RPG há muitos

anos e, na época, no início dos anos
90, os RPGs geralmente vendiam mais
que os jogos de aventura. Isso foi antes
da “morte” dos RPGs que durou até o
lançamento de Diablo. Mas eu pensei
que o cenário de fantasia típico de
Tolkien e as armadilhas de RPGs
tinham sido feitas até a morte, e me
ocorreu que super-heróis era um
excelente gênero alternativo da Liga de
Super-heróis de Hoboken que
funcionava bem com a jogabilidade de
RPG, com superpoderes substituindo feitiços mágicos .
Eu originalmente planejei torná-lo um RPG completo, mas Legend nunca havia feito nada que não
fosse um jogo de aventura direto e, portanto, estava nervoso, então a única maneira de convencê-los
era torná-lo um híbrido de RPG/jogo de aventura.
É o único jogo de super-heróis que conheço que não foi terrível. Por que você acha que tão
poucos jogos de super-heróis foram feitos?
Eu acho que a escassez de jogos de super-heróis é principalmente uma questão legal / de licenciamento.
A maioria das empresas provavelmente sente que apenas um dos super-heróis conhecidos vale a pena
criar um jogo, e tais licenças são difíceis de obter. E mesmo que uma licença seja obtida, o custo de
obtê-la significa muito menos dinheiro no orçamento de desenvolvimento, e é por isso que todos os
jogos licenciados, não apenas os jogos de super-heróis, costumam ser tão medíocres. Eu consegui me
virar com conteúdo original na Superhero League porque era uma sátira. Acho que nunca conseguiria
convencer Legend a fazer um jogo de super-herói “heterossexual” no mesmo estilo e motor.
Superhero League é seu único RPG. O que fez você querer tentar um design de jogo em uma
direção mais de RPG?
Eu gostava e ainda gosto muito de jogar RPGs, e sempre tento fazer jogos que seriam jogos que eu
gostaria de jogar se outra pessoa os criasse. E sempre prefiro fazer algo que não fiz antes, seja um novo
gênero como foi o caso aqui ou um tema sério como AMFV ou adaptar um trabalho de outro meio como
Hitch hiker ou uma escala maior como Zork Zero. Claro, isso é apenas a minha preferência. Os editores
geralmente têm outras ideias!
O jogo parece fazer automaticamente muitas coisas para o jogador que outros RPGs
exigiriam que o jogador fizesse por si mesmo. Um dos seus objetivos de design era
tornar os elementos de RPG muito simples de gerenciar?
Por ser um híbrido de aventura/RPG, imaginamos que muitos dos jogadores seriam jogadores
de RPG que eram bastante inexperientes com aventuras, e muitos dos jogadores seriam
jogadores de aventura que eram bastante inexperientes com RPGs. Então eu tentei muito
fazer os quebra-cabeças bem diretos, e tentamos manter a interface o mais simples e amigável
possível, dada a natureza altamente detalhada das interações de RPG.
Superhero League of Hoboken parecia ser bastante popular. Eu estava me perguntando

por que você não fez outro RPG desde então.
Bem, na verdade não vendeu muito
bem. Acho que não vendeu mais
de vinte, vinte e cinco mil
exemplares. E foi certamente muito
decepcionante, porque gastei um
pouco mais de tempo nele,
certamente mais do que qualquer
outro jogo que fiz para o Legend.
E recebeu críticas muito boas, então
os números de vendas foram
bastante decepcionantes. Acho que
foi Accolade quem distribuiu isso,
mas na época a Legend não estava Liga de super-heróis de Hoboken
indo tão bem financeiramente, então eles não fizeram um grande trabalho no lado do
marketing. Como editor, mas não como distribuidor, seu trabalho era lidar com toda a
publicidade e relações públicas, e eles não podiam se dar ao luxo de fazer tanto em ambas as
frentes. E a Accolade como editora certamente não era uma editora tão forte quanto alguém
como um EA poderia ter sido.
E acho que algo que realmente prejudicou muito a Superhero League foi que o jogo
atrasou cerca de um ano em relação à data de lançamento original. Isso se deveu em parte
ao atraso dos jogos anteriores no pipeline do Legend à frente, e em parte devido ao fato de
que o jogo estava tentando fazer algumas coisas que não podiam ser feitas no sistema de
desenvolvimento do Legend, e isso exigia algum suporte extra. Eles contrataram um
programador para fazer isso, e ele meio que pirou e, portanto, teve que ser reescrito por recursos internos.
Então isso serviu para atrasar o jogo, e acabou saindo no meio de 95 em vez de no meio de
94. E era um jogo VGA normal. Então, nesse meio tempo, tudo se tornou Super VGA. Então,
quando saiu, parecia muito datado. Na verdade, eu me lembro de outro jogo que saiu na
mesma época foi Colonization. E lembro-me de jogar Colonization e ficar chocado com o quão
horrível parecia. Tenho certeza de que a experiência foi a mesma para quem viu Hoboken
pela primeira vez.
Então você gostaria de fazer outro RPG?

Certamente muitos dos projetos em que comecei a trabalhar na GameFX eram jogos de RPG,
mas é claro que nenhum deles se concretizou. com certeza gostei muito
trabalhando em Hoboken e eu gosto de jogar RPGs, então eu definitivamente não me importaria

de trabalhar em outro.
Hodj 'n' Podj foi certamente o seu jogo mais diferente até aquele momento. Você estava
tentando atrair um novo público com o jogo?
Bem, eu não estava realmente
tentando atrair um novo público.
Como em todos os meus designs, o
público era basicamente eu. Eu
sempre espero que haja um número
suficiente de outras pessoas com os
mesmos gostos que eu para tornar o jogo um
sucesso.
A ideia para Hodj 'n' Podj tinha
pelo menos cinco anos quando
finalmente se tornou um projeto real.
Eu originalmente concebi o jogo como
uma maneira de trazer de volta todos
aqueles jogos simples e divertidos
Hodj 'n' Podj
que praticamente desapareceram,
porque o público de jogos hard-core
que estava conduzindo as decisões de desenvolvimento não ficaria satisfeito com jogos tão
simples. Isso, é claro, foi antes que esses jogos clássicos se tornassem onipresentes em “pacotes
de jogos” de CD-ROM e, mais recentemente, na Internet.
Na época, eu senti que uma coleção de tais jogos precisaria de uma estrutura para juntá-los
para torná-los um pacote econômico aceitável, portanto, o jogo de tabuleiro abrangente e a história/
tema de fundo dos contos de fadas. É claro que, nesse meio tempo, muitas empresas lançaram
pacotes de jogos sem nenhum tema ou mecanismos de conexão, e se saíram muito bem com eles.
Ainda assim, estou muito feliz criativamente com a decisão de tornar os minijogos Hodj 'n' Podj
parte de uma estrutura maior.
Foi somente depois que o jogo estava em desenvolvimento que começamos a suspeitar que
ele atrairia um público de jogos muito diferente. Isso foi antes que a expressão “jogadores casuais”
realmente entrasse no vernáculo da indústria. Como testadores externos, amigos e familiares de
funcionários, etc., começaram a jogar as primeiras versões do jogo, ficamos surpresos ao achá-lo
atraente para pessoas que normalmente não gostam de jogos de computador.
Ficamos particularmente satisfeitos e surpresos ao descobrir o quanto as jogadoras gostaram.
E, finalmente, descobrimos que o jogo atraía outro nicho que ainda não havia sido identificado na
época, o “jogo em família”: ou seja, pais e filhos jogando juntos. E, graças aos difíceis mecanismos
de nivelamento, os pais podiam competir em um campo de jogo relativamente nivelado com as
crianças, sem ter que “minimizar” o nível de uma criança. Ainda é o único jogo que escrevi que
pude jogar por diversão, e ainda jogo com meus filhos de vez em quando.
Como surgiu o projeto The Space Bar e quais eram seus objetivos de design para o
projeto?
Essa é outra ideia que vinha se
formando há muito tempo. Acho
que a gênese foi na verdade por
volta de 1986 ou 1987, quando o
New York Times ameaçou
processar a Infocom por causa de
nosso boletim informativo para
clientes ser chamado de New Zork
Times. Nosso advogado descartou
completamente a ameaça, mas
quando a Activision começou a
negociar a compra da Infocom,
eles insistiram que todas essas
“nuvens” fossem removidas, e
A Barra de Espaço
assim fomos forçados a mudar o
nome do boletim informativo. Houve um concurso de nomes aberto aos clientes, além de
toneladas de discussões dentro da empresa, e a newsletter acabou sendo renomeada para
The Status Line. Mas, nesse meio tempo, sugeri The Space Bar e dar ao boletim informativo
a ficção contínua de que estava sendo escrito por habitantes de tal bar e preenchido com
personagens em andamento que eram “regulares” no bar. Não sei exatamente como, mas
em algum momento a ideia deu um salto da ideia do boletim informativo para a ideia do jogo.
O principal objetivo de design do projeto era criar um jogo de aventura que fosse
composto por muitos jogos de aventura menores: um romance é uma coleção de contos
como um jogo de aventura convencional seria para The Space Bar. Além de apenas um
desejo de tentar algo diferente, também senti (mais uma vez refletindo minhas próprias
necessidades e desejos no design do meu jogo) que as pessoas tinham cada vez menos
tempo e que iniciar um jogo de aventura exigia deixar de lado esse enorme quantidade de
tempo, muitas dezenas de horas. Mas se, em vez disso, você pudesse dizer a si mesmo:
“Vou jogar este 'capítulo' agora e deixar o resto para mais tarde”, seria mais fácil justificar
pegar e iniciar o jogo. Os objetivos secundários do design eram criar uma barra de
espaçoporto tão atraente quanto a do primeiro filme de Star Wars , criar uma atmosfera noir
ao estilo Bogart, ser realmente engraçada e provar que você poderia fazer uma aventura
gráfica que, como o Infocom jogos de texto, ainda poderia ter um monte de "carne nos
ossos". Tal como acontece com Hodj 'n' Podj, senti que apenas uma coleção de jogos
independentes era muito solto e exigia um fio de conexão, assim a meta-história envolvendo
a busca de Alias Node pelo metamorfo, Ni'Dopal. Empatia A telepatia era apenas um
dispositivo conveniente para conectar os “contos” à meta-história.
No início do projeto, a Rocket Science estava realmente interessada em “sinergias”
para “alavancar” seus projetos em outras mídias: filmes, figuras de ação, jogos de tabuleiro,
livros, etc. Eu sugeri que um grande projeto complementar para The Space Bar seria
encomendar uma antologia de contos de escritores de FC, com cada um selecionando um
dos personagens/raças que criamos para The Space Bar e escrevendo uma história original
sobre essa raça ou personagem. Assim, não seria uma “novelização” convencional do jogo,
mas uma interessante peça complementar. Mas, apesar de inicial
entusiasmo de sua parte e repetidos lembretes de nossa parte, a Rocket Science nunca fez nada
a respeito.
Corrija-me se estiver errado, mas parece que The Space Bar foi certamente o seu maior
projeto de orçamento. Você estava ansioso para trabalhar com valores de produção tão
pródigos?
Sim, era mais que o dobro do
orçamento de Hodj 'n' Podj, que era
meu maior orçamento até aquele
momento. Mas ainda era um
orçamento relativamente pequeno
comparado a outras aventuras
gráficas da época; Boffo era uma
operação bastante enxuta que
realmente rendeu muito dinheiro
para a Rocket Science, e o mesmo
vale para nosso subcontratado
principal de arte para o jogo, a Dub Media.
Mesmo que fosse um grande
orçamento, certamente não era
pródigo, porque nunca havia dinheiro A Barra de Espaço
suficiente para fazer tudo o que queríamos fazer, então estávamos sempre cortando custos.
Apenas um exemplo: o PDA de Alias deveria ser um rosto animado real, não apenas uma voz
desencarnada. Então, em termos do que queríamos fazer versus o que podíamos fazer, era na
verdade meu projeto mais apertado financeiramente. Este é o grande problema com aventuras
gráficas, como discutido anteriormente, e a principal razão pela qual o meio está basicamente
morto financeiramente neste momento.
Mas o projeto, embora extremamente estressante do ponto de vista orçamentário, ainda era
um grande momento. Trabalhar com Ron Cobb como artista conceitual foi uma das verdadeiras
emoções da minha carreira. A equipe do Space Bar foi a maior equipe que eu já dirigi, o que, é
claro, anda de mãos dadas com o maior orçamento, e é muito empolgante ter tantas pessoas
contribuindo porque quase todos contribuem além de suas áreas restritas de especialização /
responsabilidade. E eu senti que, apesar dos cantos cortados, atingimos substancialmente todos
os objetivos de design, o que foi bastante gratificante.
O que o levou a WorldWinner.com?

Após cerca de um ano de projetos cancelados na GameFX/THQ, eu estava querendo sair e
estava trabalhando com uma recrutadora, e ela me orientou para o WorldWinner. Os jogos
individuais lembrarão muito o tipo de jogos em Hodj 'n' Podj, que foi definitivamente uma das
principais atrações. Além disso, trabalhar em um ambiente online multijogador era uma grande
atração, porque eu nunca tinha feito isso antes.
Então você acha que a Internet oferece novas possibilidades para uma variedade maior
de jogos do que a disponível atualmente?
Sim, bem, eu definitivamente acho que sim em termos de fornecer uma saída para o tipo de
jogo mais pessoal ou mais experimental. Fora isso, por enquanto, certamente há pontos
negativos em termos de largura de banda. Com os jogos que estou fazendo agora, embora haja
coisas realmente interessantes e divertidas sobre eles, certamente é meio chato estar de volta
aos dias em que 100K é muito grande e, em alguns casos, muito grande. Eu tinha me afastado
disso quando chegamos aos dias do CD-ROM, onde o tamanho das coisas se tornou, na maioria
dos casos, completamente inconsequente, e agora, de repente, está de volta. Mas sim, no
geral, certamente há pontos positivos e negativos, mas no geral os pontos positivos são muito
promissores e as coisas negativas sobre isso, como há certos tipos de jogos que não podemos
fazer por causa da largura de banda - bem, as pessoas ainda podem fazer esses jogos pelos
canais normais e tradicionais.
Você acha escrever ou jogar mais divertido?

Jogando. Escrever jogos às vezes é muito divertido, às vezes muito penoso, e às vezes é
realmente brutalmente doloroso, como quando sua empresa fecha as portas.
Mas jogar é sempre divertido. Claro, as partes mais divertidas de fazer jogos são mais divertidas
do que as partes mais divertidas de jogar.
Tanta escrita em jogos é terrível. O que você acha importante ter em mente ao escrever
para um jogo?
Todos os tipos de escrita são diferentes, e há muitos excelentes escritores de romances que
não poderiam escrever um roteiro ou vice-versa. E escrever para jogos é pelo menos tão
diferente quanto esses dois. Claro, também há exceções. Ajuda a ser um jogador de jogo. Você
não esperaria que um romancista tivesse sucesso como roteirista se ele não tivesse visto nenhum filme!
Então, muito da escrita em jogos é ruim porque está sendo escrita como se fosse para outro
meio. Claro, parte da escrita é ruim só porque os escritores que fazem isso não são talentosos.
Assim como no design de jogos, programadores e produtores muitas vezes sentem
incorretamente que são capazes de escrever.
Uma coisa que torna a escrita nos jogos tão diferente é que muitas vezes ela vem em
pequenos pedaços desconectados, respostas de uma palavra ou uma frase a várias ações do
jogador. Há uma troca difícil entre manter esses trechos interessantes e mantê-los concisos.
Além disso, a escrita tem que ser tão meticulosamente trabalhada para fins de jogabilidade e
quebra-cabeças – dê apenas pistas suficientes, não muitas, não engane – que a qualidade da
escrita geralmente tem que ficar em segundo plano. E a natureza não linear dos jogos é outro
obstáculo para uma boa escrita. Se você não sabe se a Linha A ou a Linha B virá primeiro,
muitas vezes deve haver uma duplicação de informações, dando a impressão de ser desleixada
ou excessivamente prolixa. E, finalmente, há a questão da repetição. Em jogos de aventura,
muitas vezes você vê o mesmo pedaço de escrita repetidamente, com a familiaridade gerando
desprezo até mesmo por uma escrita muito boa.
Quão orgânico é o processo de design para seus jogos? O surgimento dos gráficos acabou
limitando o quanto você poderia mudar seu jogo?
Muito orgânico, mas você está certo, os jogos gráficos são muito mais limitantes em termos de
quanto o jogo pode mudar quando ultrapassa o estágio de design original. De todos os meus jogos,
AMFV foi provavelmente o que mais mudou à medida que a produção do jogo progredia.
Originalmente, era um jogo muito mais ambicioso, muito menos orientado para a história, quase um
“simulador do futuro” onde o jogador poderia definir parâmetros no presente e depois viajar n anos
no futuro para ver qual mundo resultaria daqueles decisões.
Eu também acho que o desenvolvimento funciona melhor quando o jogo cresce durante a
implementação, ao invés de mapear/traçar o jogo inteiro para um nível de detalhe bastante alto e
então iniciar a implementação. Essa é outra grande vantagem das aventuras de texto sobre as
aventuras gráficas. Isso me permite, em um jogo como LGOP ou Hoboken, encontrar e aprimorar
uma voz/estilo enquanto muito do jogo ainda está na prancheta, resultando em um trabalho melhor
e mais unificado.
Um grande problema para jogos de aventura parece ter sido a dificuldade. Por exemplo, se o
jogo for muito difícil, você provavelmente assustará novos jogadores. Mas se o jogo for muito
fácil, os jogadores hard-core irão descartar seu jogo. Você tem alguma ideia de qual seria a
solução para esse problema?
A dificuldade era um problema constante. Nossos jogos ficaram consistentemente mais fáceis, o
que não pareceu ajudar a atrair novos jogadores, e definitivamente pareceu afastar nossos fãs mais
ferrenhos. Livros de dicas e dicas posteriores no jogo foram definitivamente consideradas maneiras
de manter os jogos bastante difíceis sem desencorajar jogadores mais novos, menos sofisticados e
menos masoquistas. É uma solução muito boa, porque se o jogo for muito difícil, as dicas podem
ajudar a tornar o jogo uma boa experiência para um jogador mais fraco, mas se o jogo for muito
fácil, é praticamente arruinado para um jogador mais forte. Outra solução é ter vários níveis de
dificuldade, com mais pistas na história nos níveis mais fáceis, mas isso obviamente dá muito mais
trabalho para projetar, programar e equilibrar.
Uma reclamação frequente que se vê sobre jogos de aventura é que eles não têm muito valor
de repetição. Como designer, o que você faz para adicionar essa replayability, ou você não
considera isso um grande problema?
Sim, isso se tornou cada vez mais um grande problema, pois meus jogos competiam não tanto
contra outras aventuras e RPGs, mas contra jogos de estratégia como Civilization e jogos RTS
como WarCraft. Até certo ponto, você pode ter replayability em jogos de aventura. Por exemplo,
Suspended foi um jogo da Infocom extremamente rejogável, pois você se esforçou para terminar o
jogo com os níveis de baixas mais baixos possíveis. Mesmo com Zork I, lembro-me de um casal de
Nova Jersey que costumava nos escrever constantemente com novas maneiras de ganhar o jogo
em um número cada vez menor de movimentos. Soluções alternativas de quebra-cabeças e
respostas “carne nos ossos” a entradas malucas são outras maneiras de estender o tempo de jogo.
Mas, na maioria das vezes, é apenas uma questão de ter certeza de que leva trinta ou quarenta
horas para jogar o jogo, e esperar que isso seja suficiente para fazer uma pessoa gastar quarenta ou cinquen
Alguma vez você já quis esquecer os quebra-cabeças e ter um jogo focado principalmente na história? Você
parece ter feito um jogo de “todos os quebra-cabeças” com Hodj 'n' Podj.
Meu desejo, e acho que isso vale para a maioria dos escritores de jogos de aventura, é fazer mais história e menos
quebra-cabeça, mas quebra-cabeça é necessário para manter essa meta de tempo de jogo de trinta a quarenta horas.
De todos os meus jogos, AMFV foi certamente o mais na direção da história, e Zork Zero foi provavelmente o mais
na direção do quebra-cabeça. Eu certamente não concordo que Hodj 'n' Podj fosse só quebra-cabeças, já que o jogo
de tabuleiro certamente tem uma história de abertura e encerramento bem desenvolvida, e a jogabilidade preenche
um pouco mais entre esses suportes: príncipe resgata princesa, príncipe confronta irmão , etc.
Você já adicionou quebra-cabeças a um jogo apenas para torná-lo mais longo?
Eu definitivamente adicionei quebra-cabeças simplesmente para prolongar a jogabilidade. Eu diria que toda a terceira
seção do AMFV foi em parte isso, e em parte com medo de que o jogo fosse muito diferente e sem quebra-cabeças
e que as pessoas se rebelariam se pelo menos não houvesse alguns quebra-cabeças no jogo. Acho que Planetfall e
Stationfall foram definitivamente casos em que, à medida que o jogo entrava em testes, havia uma impressão de que
o jogo era muito fácil e rápido demais. Alguns mais precisavam ser colocados para evitar que as pessoas terminassem
o jogo em dez horas e sentissem que não tinham recebido o valor do seu dinheiro.
Você já teve medo de que algumas pessoas que possam gostar dos elementos da história dos jogos de
aventura se assustem com os quebra-cabeças realmente difíceis?
Bem, é uma espécie de enigma, porque parece que o que torna os jogos de aventura tão atraentes e obsessivos são
quebra-cabeças realmente difíceis que fazem você ficar acordado a noite toda, pensando neles mesmo quando você
não está sentado jogando o jogo. Então, quando você está longe do jogo, você está pensando sobre isso e, de
repente, “Oh meu Deus, o kum quat no galpão de feno a sete quartos, eu nunca tentei isso!” E você mal pode esperar
para correr para casa e inicializar o jogo para salvar e correr para pegar o kumquat, trazê-lo de volta e tentar o que
for. E talvez funcione e seja a melhor sensação, ou talvez não funcione e seja a pior sensação, ou talvez não
funcione, mas pelo menos lhe dá uma nova direção ou dica ou algo assim. E em um jogo sem quebra-cabeças ou
quebra-cabeças bem fáceis, você simplesmente não tem a mesma pressa. Mas, por outro lado, principalmente com
o passar do tempo, parecia que havia mais e mais pessoas jogando jogos de aventura que realmente não gostavam
de quebra-cabeças muito difíceis. É muito difícil satisfazer os dois públicos.
A tentativa de satisfazer as pessoas mais interessadas na experiência de jogo casual parecia, com o tempo, driblar o
público, porque resultava em uma experiência de jogo menos atraente.
Você também atuou como programador em todos os seus jogos?
Através de Hoboken, fiz tanto o design quanto a programação e, desde então, apenas o design. Eu certamente
prefiro evitar a programação, se possível; fazer isso sempre foi apenas um mal necessário. Claro, certamente tem
algumas grandes vantagens em termos de eficiência e comunicação cem por cento perfeita entre programador e
designer. Mas mesmo que eu adorasse programar, os jogos hoje em dia são muito complexos para um programador,
então eu nunca mais seria capaz de fazer todo o design e programação sozinho.
Em jogos de aventura e, em particular, aventuras de texto, limitar o que o jogador pode fazer é uma
parte importante do jogo. Os jogadores podem ficar frustrados ao ver “você não pode fazer isso” com
muita frequência. Quão duro você trabalha para eliminar esse problema?
Parte disso está limitando a geografia do jogo. A escolha original da configuração ajuda.
É por isso que tantos jogos se passam dentro de uma geografia com limites muito bem definidos como uma
caverna, castelo, ilha, zepelim, etc. É menos frustrante nem mesmo perceber um limite do que chegar a um
limite e ouvir “Não há nada de interessante nessa direção” ou “Você provavelmente morreria de sede se
tentasse atravessar aquele deserto”.
Parte disso é apenas arregaçar as mangas e colocar o maior número possível de respostas não padrão,
com base em suposições iniciais do que as pessoas tentarão, aumentadas por sugestões de testadores e
ainda mais ideias ao ler as transcrições das sessões de jogo dos testadores. A adição de tais respostas era
limitada apenas pelo tempo e, mais frequentemente, pelo espaço em disco. Essa também foi uma boa maneira
de colocar dicas; um jogador tenta algo que não é a “Resposta Certa”, mas que é uma “Coisa Razoável para
Tentar”. Eu faria da resposta uma explicação do fracasso, mas talvez uma pista do que tentar. Por exemplo:
>DÊ O SANDUÍCHE PARA O VELHO Ele parece cansado

demais para comer agora.
E parte disso é tornar as respostas padrão o mais flexíveis e divertidas possível. Por exemplo, no
Hitchhiker's, a resposta padrão para o verbo FILL era “Phil who?” Phil era o pseudônimo de Zaphod durante a
cena da festa. Para outro exemplo, no Zork I , a resposta padrão para muitas ações “impossíveis” foi escolhida
em uma tabela, dando a você uma variedade de respostas.
Então, em vez você obteria:

de: >TOMAR >TOMAR TODO
TODO o pão: Tomado. o pão: Tomado. faca: está
faca: está presa firmemente na bancada. bancada: presa firmemente na bancada. bancada: Que
Você não pode tomar isso! pia: Você não pode conceito! pia: Pense novamente. fogão: Não é
tomar isso! fogão: Você não pode tomar isso! provável. forno: Pense novamente.
forno: Você não pode tomar isso!
Você tem um ponto de partida específico ao criar um novo jogo?
Varia de jogo para jogo. AMFV começou com o tema/mensagem do jogo. Sorcerer começou com a complexa
viagem no tempo, o quebra-cabeça do autoconhecimento e foi construído a partir daí.
Expliquei anteriormente quais eram as ideias iniciais para Planetfall e The Space Bar. Geralmente, não faço
tudo de uma coisa antes de passar para a próxima. Eu não escrevo a história inteira, e então começo na
geografia, e então, quando isso acaba, começo a escrever alguns quebra-cabeças. Em vez disso, vou rascunhar
um enredo, depois projetar a parte central da geografia, começar a preenchê-la com personagens e quebra-
cabeças, refinar o enredo, adicionar uma nova cena com a geografia resultante, adicionar os dois quebra-
cabeças em que pensei enquanto isso, combine dois personagens em um único personagem, adicione mais
algumas salas àquela seção de Laboratório do jogo, adicione um novo quebra-cabeça para completar o jogo
final, descubra por que Esmeralda fugiu de casa em primeiro lugar , e assim por diante.
Por que você acha que os jogos de aventura são tão inviáveis comercialmente hoje em dia?
Simplesmente, o modelo de custo-receita para o jogo de aventura médio está tão longe de ser
lucrativo que quase nenhum editor os tocará, já que quase todas as decisões de publicação
atualmente estão sendo tomadas em uma base puramente comercial e não criativa. É apenas um
dos tipos de jogos mais caros de se fazer, e os n principais jogos de aventura vendem menos do
que os n principais jogos em quase todas as outras categorias.
Claro, pode-se argumentar que o jogo de aventura não está morto, mas simplesmente evoluiu
para jogos de ação/aventura, por exemplo, Tomb Raider, e jogos de plataforma, por exemplo,
Mario, Crash. Pessoalmente, não considero nenhum jogo que dependa de um grau relativamente
pequeno de coordenação mão-olho para se encaixar na conta de um jogo de aventura.
Suspeito que uma grande inovação técnica possa reviver o gênero, mas não sei se isso será
uma interface de reconhecimento de voz, NPCs à prova de Turing, ambientes 3D-surround-VR ou
o quê.
É particularmente angustiante quando um jogo bem orçado que todos concordam que é
bem feito não vende muito bem. Em particular, estou pensando em Grim Fandango.
Sim, Grim Fandango. Não sei os números exatos, mas não acho que tenha quebrado cem mil. E
essa foi a escolha unânime de todos para o jogo de aventura do ano. Foi um jogo maravilhoso. Eu
não achava que do ponto de vista do quebra-cabeça era tão bom, mas do ponto de vista da direção
de arte era provavelmente o melhor jogo de aventura que eu já tinha visto.
Parece estranho que os jogos de aventura costumavam estar entre os jogos mais vendidos,
e agora eles não vendem bem. Talvez meus números estejam errados...
Não, isso é realmente verdade. Na época dos jogos King's Quest do final dos anos 80 e início dos
anos 90, eles realmente eram o gênero mais vendido na época. E os jogos de aventura da Infocom,
de cerca de 83 a 85, também. Houve um momento em que tínhamos cinco dos dez jogos mais
vendidos de um determinado mês.
Então, o que aconteceu com os jogadores de jogos de aventura?

Bem, certamente existem gêneros que existem agora que nem existiam naquela época. E há
outros gêneros que podem ter existido na época, mas certamente surgiram de um jeito e tanto.
Então, pode ser que as pessoas que estavam jogando gostassem de uma experiência interativa,
mas estariam jogando o tipo de jogos que são populares hoje se pudessem. E em 1985 não havia
nada como um jogo de tiro em primeira pessoa, não havia nada como um jogo de estratégia em
tempo real.
Pode ser que ainda existam alguns jogadores de aventura por aí, mas simplesmente que a
massa crítica deles caiu um pouco a ponto de os que restaram não poderem mais suportar o
mesmo grau de jogo. Um jogo de aventura que custaria dois milhões de dólares para ser feito
agora exigiria dez vezes mais pessoas interessadas nele do que um jogo de aventura que poderia
ter custado duzentos mil dólares quinze anos atrás. E talvez o mercado tenha até dobrado desde
então, mas não subiu dez vezes. Portanto, caiu abaixo da massa crítica que tornaria esse tipo de
jogo economicamente viável.
O que o manteve interessado em jogos por tanto tempo? Você já pensou em escrever
um romance ou escrever para outras mídias não interativas?
Muitas vezes considerei escrever um romance ou roteiro, principalmente nos momentos mais
desencorajados da minha carreira de escritor de jogos: projetos cancelados, uma empresa
falindo, um jogo vendendo muito mal. Mas a escrita de jogos sempre pagou as contas, então
outros projetos de escrita teriam que ser uma coisa clandestina, e com pais e outros interesses
externos, simplesmente não há muito tempo livre para escrever sem pagar. Mas qualquer
frustração e infelicidade com a criação de jogos foi completamente do lado dos negócios; Eu
nunca achei o processo criativo de fazer jogos nada menos do que uma explosão. Ainda é um
meio em crescimento/desenvolvimento, por isso é muito empolgante ajudar a inventar uma
nova “forma de arte”. Como o salário na indústria é relativamente baixo, todos com quem você
trabalha tendem a ser realmente motivados e amar o que estão fazendo, e é apenas uma
maneira muito legal de ganhar a vida. Por exemplo, quantos pais podem dar camisetas a seus
filhos para um jogo de aventura WarCraft cancelado?
Steve Meretzky Gameografia

Planetfall, 1983 Sorcerer, 1984 The
Hitchhiker's Guide to the Galaxy,
1984 A Mind Forever Voyaging, 1985 Leather
Goddesses of Phobos, 1986 Stationfall, 1987
Zork Zero: The Revenge of Megaboz, 1988
Spellcasting 101: Sorcerers Get All the Girls,
1990 Spellcasting 201: The Sorcerer's
Appliance, 1991 Spellcasting 301: Spring Break, 1992
Leather Goddesses of Phobos II: Gas Pump Girls
Meet the Pulsating Inconvenience from Planet X, 1992
Superhero League of Hoboken, 1994 Hodj 'n' Podj, 1995
The Space Bar , 1997 Tile City, 2000 Word Cubes,
2001 Hangmania, 2002 Catch-21, 2002 SwapIt!, 2003
Blockwerx, 2004 Triv!, 2004
Capítulo 11
Narrativa
“O perigo para os designers é que eles ficam viciados em sua história, e eles
conseguem que a narrativa seja uma coisa do tipo narrativa linear. E quanto mais você
detalha a história, mais você remove a interatividade e mais você remove o jogador do
jogo. É como 'Oh, o resultado já foi determinado. Então, qual é o ponto?'”
— Eugene Jarvis
houve muitos jogos fabulosos que ofereceram muito pouco em termos de

Estritamente falando,
narrativa. os jogosTetris,
Considere de computador não precisam
que não tinha narrativa contar
alguma,histórias. Ao longo
ou Centipede e dos
SSX,anos
onde a única história encontrada está no cenário do jogo. Mas outros jogos, como Halo,
Command & Conquer e Thief, pegaram uma história e a fizeram funcionar como parte fundamental
202
Capítulo 11: Narrativa 203
da jogabilidade, criando contos tão ricos que os jogadores se vêem sugados para o mundo do
jogo mais do que se os jogos não tivessem história. E ainda outros jogos, como A Mind Forever
Voyaging, Myst, Ico e a série Ultima , tornaram a história uma parte tão integral do jogo que
dificilmente se pode imaginar de outra forma. Portanto, os jogos certamente não precisam de
histórias, mas parece que, quando empregadas adequadamente, as histórias podem tornar os
jogos muito mais fortes.
A história é tão central

para Myst que é difícil
imaginar o jogo sem
ela.
Na verdade, o sonho de histórias interativas foi o que me atraiu para o desenvolvimento de

jogos em primeiro lugar. Imagine todo o poder de uma história em um romance, com sua
capacidade de agarrar e cativar o leitor, fazê-lo se importar com os personagens da história,
mudar sua percepção do mundo e, em alguns casos especiais, mudar a forma como ela vive sua
vida. Agora imagine o quanto isso seria mais poderoso se, em vez de ler sobre as ações de
outros personagens, o leitor fosse o personagem principal da história e pudesse fazer escolhas
que afetariam a forma, a direção e o resultado da história. Esse leitor interativo podia ver as
ramificações de diferentes escolhas feitas em diferentes situações e, como eram suas próprias
escolhas que determinavam a natureza da história, o atrativo da história interativa seria muito
mais atraente do que uma história tradicional. A mente fica confusa com as possibilidades. Claro
que esse sonho ainda está muito distante, sem nenhum jogo disponível perto de alcançar esse
ideal. Mas fornece uma razão convincente para continuar experimentando, com a esperança de
um dia conseguir uma história verdadeiramente interativa.
História do designer versus história do jogador

Então, o que queremos dizer quando falamos sobre a história de um jogo? Muitos
desenvolvedores de jogos consideram a história de um jogo como uma série predeterminada de
eventos dramáticos, muito parecido com a história encontrada em um romance ou filme. Esses
eventos são estáticos e imutáveis, independentemente das ações dos jogadores no mundo do
jogo, e a história é normalmente transmitida aos jogadores entre as seções do jogo. Por exemplo,
em Command & Conquer, os jogadores são contados a história do conflito entre as forças GDI e
Nod através de cutscenes entre as diferentes missões. A história determina em parte onde as
missões acontecem e o que os jogadores têm que fazer nelas, mas normalmente quando os
jogadores completam um nível, a história pode prosseguir em apenas uma direção. Os únicos finais poten
204 Capítulo 11: Narrativa
história são sucesso e fracasso, com sucesso após os jogadores terem completado todas as
metas predeterminadas em todos os níveis, e o fracasso vindo em qualquer ponto em que os
jogadores deixem suas forças serem dominadas pela oposição. Alguns jogos permitem algumas
ramificações simples em suas histórias, mas cada ramificação ainda é predeterminada pelo
designer do jogo e, geralmente, as ramificações são bastante limitadas em escopo.
Mas há um tipo completamente diferente de história associada a um jogo. Se o que acabei
de descrever é a história do designer, podemos chamar esse outro tipo de história de história do
jogador. Voltando ao exemplo de Command & Conquer, cada vez que um jogador específico joga
o jogo, ela gera uma nova história única para ela. De fato, cada nível compõe uma mini-história
de como o jogador ganhou ou perdeu aquele nível. Por exemplo, digamos que o jogador começou
seu jogo no lado GDI, construindo um grande número de Minigun Infantry, Grenade Infantry e
Humm-Vees. Essas forças, no entanto, foram quase exterminadas por um ataque inicial de Nod,
durante o qual a infantaria de lança-chamas do inimigo provou ser demais para o jogador. O
jogador, no entanto, foi capaz de explorar uma veia de Tiberium que encontrou nas proximidades
e construir uma Usina de Energia Avançada e alguns racks de Barras. O jogador então se
concentrou em construir apenas Rocket Infantry e Mammoth Tanks. Quando a Nod Flamethrower
Infantry atacou, o jogador foi facilmente capaz de atropelá-los com seus tanques. Uma parte da
infantaria começou a recuar, e o jogador dirigiu seus tanques e a Infantaria de Foguetes para
segui-los de volta à sua base. Lá, a infantaria da GDI foi capaz de bombardear as estruturas Nod
à distância, com os tanques Mammoth eliminando qualquer resistência que encontrassem. Assim,
o jogador ganhou o nível. Esta é a história do jogador.
Agora, quando muitos designers de jogos falam sobre contar histórias em jogos, eles
provavelmente não estão falando sobre a história do jogador, como a contada acima. No entanto,
a história do jogador é a história mais importante a ser encontrada no jogo, pois é a história com
a qual o jogador estará mais envolvido e é a história em que as decisões do jogador têm mais
impacto. Esta é a história que eles compartilharão com seus amigos quando falarem sobre o
jogo. Embora a história possa não ser muito interessante para os outros, será extremamente
interessante para a pessoa que a conta, que a viveu. Na maioria dos casos, uma vez que os
jogadores tenham derrotado o nível usando táticas astutas, eles estarão muito menos interessados
na história do designer de vídeo em movimento completo (FMV) que surge entre os níveis,
explicando o próximo nível a ser jogado. Há certas vantagens em ter a história de um designer, é
claro. Ele pode conter personagens e situações interessantes e empregar dispositivos tradicionais
de contar histórias, como construir um clímax, criar tensão, prenúncio e assim por diante. A
história do designer pode agregar significado e relevância às ações que o jogador realiza no jogo.
Por exemplo, levar o Um Anel para a Montanha da Perdição para ser incinerado e levar seu lixo
para o incinerador são atividades aproximadamente equivalentes, exceto que no primeiro caso a
história dá significado e importância à ação, enquanto no segundo a banalidade da atividade a
torna completamente desinteressante. Infelizmente, o uso desses dispositivos é muitas vezes à
custa da natureza interativa da história. Por outro lado, dependendo de como um determinado
jogador joga o jogo, a história do jogador de Command & Conquer contada acima pode não ter
muito drama ou tensão narrativa e, como resultado, pode ser um pouco fraca como uma
experiência de narrativa.
O ideal para contar histórias interativas é fundir a história do designer e a história do jogador
em uma, para que os jogadores possam ter um impacto real em uma história enquanto a história
mantém suas qualidades dramáticas. Há dois bons exemplos do ideal interativo
experiência de contar histórias. O primeiro é um exemplo que Chris Crawford gosta de usar: o de
um pai contando uma história a um filho. O pai tem em mente uma história para contar, incluindo
quais personagens ela envolverá, quais surpresas ela conterá, aproximadamente como a história
se desenrolará e aproximadamente como ela terminará. Mas, à medida que a criança faz perguntas
sobre a história, os pais mudam a história de acordo. Os pais podem usar um livro como guia, mas
se desviarão desse guia conforme necessário. Por exemplo, a história pode começar assim:
“Enquanto a princesa vagava pela floresta escura, ela se assustou com muitas coisas diferentes
que viu, incluindo uma grande salamandra, uma caverna escura e uma velha cabana”. À medida
que o pai conta a história, a criança pode fazer perguntas. “De que cor era a salamandra?” “A
salamandra tinha um estranho tom de amarelo, uma cor que a princesa só tinha visto na mostarda
real temperada.” “E a caverna?” “De dentro da caverna veio um cheiro terrível, que lembra o cheiro
de enxofre queimando.” “Talvez haja um velho feiticeiro lá, fazendo poções. Ela entra na caverna?”
“Ela entrou na caverna, dando cada passo com cuidado para evitar tropeçar no escuro. E quando
ela foi mais fundo na caverna, ela começou a ver uma luz, e uma voz gritou: 'Quem é que entra na
minha caverna?' E quando ela se aproximou, a princesa viu um velho bruxo com vestes
esfarrapadas…” Pode não ter realmente havido um feiticeiro na história como os pais inicialmente
pretendiam contar, mas como a criança faz perguntas, em vez de responder “você não pode seguir
esse caminho” ou “não há nada de especial nisso” como um jogo de computador mal projetado
pode, o pai adapta a história à criança, adicionando detalhes e introduzindo novos personagens e
situações conforme necessário. O arco geral da história e seus principais protagonistas podem não
mudar muito, mas a criança teve um papel real em determinar o que exatamente acontece na
história.
Outro exemplo de narrativa verdadeiramente interativa é encontrado em muitos jogos de role-
playing de papel e caneta, como Dungeons & Dragons. Em um jogo de D&D, o Dungeon Master
(DM) lidera o jogo, guiando os outros jogadores pelo mundo do jogo e contando a eles a história
enquanto ela acontece. O Dungeon Master planeja com antecedência os locais que os jogadores
explorarão, tem alguma ideia de quais personagens os jogadores encontrarão em quais locais e
provavelmente sabe quais grandes conflitos serão apresentados.
Os jogadores, no entanto, estão no controle de quais partes do nível eles investigam e como eles
se comportam com os diferentes NPCs que podem encontrar. Por exemplo, o Mestre provavelmente
não tem um roteiro do que os diferentes NPCs vão dizer quando forem abordados.
Em vez disso, ela sabe como são suas personalidades e como elas provavelmente responderão.
Quando os jogadores fazem uma pergunta a um NPC, o Mestre é capaz de dar uma resposta
razoável na hora. Um mestre inteligente nunca terá que dizer: “O NPC não entende sua pergunta”.
Assim como na experiência de contar histórias entre pais e filhos, o Mestre será capaz de manter
os jogadores no caminho da história geral que ela quer contar, enquanto permite aos jogadores
uma quantidade considerável de liberdade em como essa história se desenrola e talvez até em
como ela se resolve. .
É claro que o problema em criar uma versão para computador de uma experiência interativa
de contar histórias como as descritas acima é que ambas exigem que um humano conte a história,
uma vez que um computador moderno nunca será capaz de desenvolver dinamicamente o
desenvolvimento da história. como um ser humano pode. Portanto, o melhor que um designer de
jogos pode fazer atualmente é tentar recriar uma experiência narrativa interativa, mas, em vez de
gerar dinamicamente a linha da história, antecipar todas as perguntas que os jogadores podem
fazer, lugares que podem ir e linhas de diálogo que eles podem fazer. pode querer dizer. Claro,
esta é uma tarefa sua, e não importa quanta antecipação o designer empregue, ela nunca
ser capaz de pensar em tudo que os jogadores podem tentar. No mínimo, o designer deve tentar
permitir diferentes estilos de jogo e níveis de investigação no mundo da história, em vez de
classificar os jogadores em uma maneira de jogar o jogo e explorar sua história. Se um designer
está interessado em contar histórias verdadeiramente interativas, é sua responsabilidade tornar
a história do designer flexível o suficiente para permitir que ela se torne também a história do jogador.
Lugares para contar histórias

Existem várias maneiras pelas quais um jogo pode contar uma história. Normalmente, os jogos
usam vários dispositivos diferentes de contar histórias para comunicar sua história, com jogos
diferentes dependendo mais de alguns dispositivos do que de outros. O tipo de história que você
espera contar, qual tecnologia você usará e a jogabilidade do seu jogo determinarão quais
dispositivos de narrativa funcionarão melhor para seu projeto.
A distinção mais simples que se pode fazer é em qual contexto a narrativa ocorre: • Fora do
jogo: é qualquer narrativa feita no computador enquanto o jogo está rodando, mas quando os
jogadores não estão realmente jogando o jogo. Isso inclui todas as cutscenes durante as quais
os jogadores perdem o controle de seu personagem, como as cut-scenes ou briefings de
missões que ocorrem entre os níveis em Command & Conquer ou breves seções não
interativas em Super Mario 64. • No jogo: logicamente, isso é o oposto do acima e cobre
qualquer narrativa que ocorra enquanto os jogadores estão realmente jogando o jogo. Isso
inclui a configuração do mundo do jogo, o comportamento dos oponentes dos jogadores,
quaisquer conversas dinâmicas que os jogadores possam ter e qualquer planejamento
interativo pré-missão que os jogadores possam fazer.
• Materiais Externos: Isso inclui qualquer narrativa feita completamente fora do

computador, como uma introdução escrita no manual ou qualquer parafernália
que possa vir com o jogo, como um mapa ou uma coleção de gemas.
Embora Max Payne tenha

usado a narrativa no jogo
através de suas
configurações e design de
missão, grande parte da
linha da história foi
efetivamente comunicada
através de cenas cortadas
não interativas e interlúdios
de quadrinhos.
Um determinado jogo pode usar apenas um ou todos os três tipos de narrativa acima.
Half-Life é um exemplo de um jogo que inclui apenas a narrativa no jogo; os jogadores nunca
perderam o controle de seu personagem do início ao fim do jogo. Os jogos da Infocom são
bons exemplos de jogos que usaram materiais internos e externos para contar suas histórias.
Além das conversas e descrições do mundo do jogo que os jogadores tinham no próprio jogo,
os jogos da Infocom sempre vinham com documentos e bugigangas extras, que serviam para
aprimorar o entendimento dos jogadores sobre o mundo do jogo, além de às vezes serem
exigidos para completar os quebra-cabeças do jogo.
Max Payne usou a narrativa do jogo através de suas configurações e design de combate,
enquanto grande parte da história foi comunicada através de cenas de corte não interativas e
páginas de quadrinhos. Tekken é um exemplo de jogo que conta sua história, por mais
insubstancial que seja, quase inteiramente por meio de cutscenes fora do jogo: um precede a
jogabilidade e o outro joga após os jogadores terem derrotado o jogo single-player usando um
personagem específico. Os cenários das várias arenas não têm nada a ver com o enredo, e
os próprios personagens também não exibem nada das personalidades descritas nas cenas,
embora seus estilos de luta geralmente se relacionem com suas nacionalidades. De fato, não
está claro por que os designers de Tekken se sentiram compelidos a incluir uma linha de
história. Talvez eles quisessem dar aos jogadores algo para recompensá-los por derrotar o
jogo, e uma cena era o único prêmio adequado que eles podiam imaginar.
Fora do jogo
A narrativa fora do jogo é talvez a forma mais prevalente atualmente nos jogos, e vem em
uma variedade de formas. Pode-se atribuir a popularidade da narrativa fora do jogo à sua
semelhança com a narrativa em outras mídias. Por exemplo, uma cena de corte é muitas
vezes como um filme e usa técnicas cinematográficas estabelecidas, enquanto um briefing de
texto para um nível não é diferente do que se pode ler em um romance. Esses são dois tipos
de mídia que existem há muito mais tempo do que os jogos de computador, e ambos têm uma
sintaxe estabelecida que lhes permite contar histórias de maneira muito eficaz. De certa
forma, é muito mais fácil contar uma história por meio desses métodos do que pela
jogabilidade. Mas, como designer, você deve se perguntar: as cut-scenes não interativas são
sobre o que os jogos deveriam ser? Se a sua jogabilidade for boa, os jogadores vão querer
voltar a jogar em vez de ficar sentados em longas cinemáticas. Os jogadores jogam jogos
para interagir. Se quisessem uma experiência mais passiva, teriam ido ao cinema ou comprado
um livro na biblioteca. A narrativa não interativa pode ter seu lugar nos jogos, mas os designers
precisam estar cientes de que ela deve complementar e não prejudicar uma experiência de jogo emoc
Como discuti, existem vários métodos diferentes que podem ser usados para contar uma
história fora do jogo. Os principais métodos são: • Cut-Scenes: O que é comumente chamado
de cut-scenes usa técnicas cinematográficas para comunicar uma narrativa aos jogadores.
Eles podem ocorrer em 2D ou 3D e geralmente envolvem cortes, panelas, a “regra de
180 graus” e outros dispositivos com os quais qualquer pessoa que assistiu a filmes ou
televisão estará familiarizada. Eles são em essência curtas-metragens intercalados com
a própria jogabilidade.
• Texto: Muitos jogos usam texto para descrever a história ou para dar aos jogadores objetivos
para a próxima missão. O texto pode preencher a tela inteira e depois passar para outro
tela conforme necessário, ou o texto pode rolar a uma velocidade lenta o suficiente para que os jogadores
tenham tempo de lê-lo.
• Imagens: Às vezes, os jogadores são apresentados a imagens simples que comunicam alguma parte da história.
Estas não se qualificam precisamente como cutscenes padrão, uma vez que não incluem cortes de câmera
ou outras técnicas cinematográficas, embora uma simples câmera panorâmica possa ser usada para varrer
uma imagem que não cabe na tela. A imagem pode ser um mapa de uma área, uma imagem “estabelecedora”
dos desafios que estão por vir, ou uma recapitulação daqueles que os jogadores acabaram de completar. As
imagens são frequentemente misturadas com texto, às vezes usando técnicas de quadrinhos, mas geralmente
sem balões de palavras (com a notável exceção de Max Payne). • Áudio: Às vezes, os jogadores recebem
instruções que são diálogos falados ou outro áudio. Isso geralmente ocorre quando o orçamento não existia
para criar o FMV para acompanhar o diálogo ou quando o diálogo é apresentado sobre outras informações que os
jogadores deveriam estar olhando, como mapas, dossiês ou uma lista de objetivos.
Um dos objetivos mais importantes ao trabalhar com cutscenes é estabelecer uma aparência visual
consistente entre as cut-scenes e a jogabilidade. Se possível, o mesmo motor deve ser usado para as cut-scenes e
para o resto do jogo.
Em meados dos anos 90, quando os jogos mudaram para o CD-ROM como meio de distribuição de escolha, pela
primeira vez os jogos foram capazes de incluir a reprodução de vídeo real, mesmo que esses filmes muitas vezes
não pudessem preencher a tela inteira. Assim surgiu o temido jogo FMV, como The 7th Guest. Normalmente, esses
jogos apresentavam longos clipes FMV com minijogos entre eles, resultando em produtos que eram mais filmes do
que jogos. Nesses jogos, a grande maioria do tempo dos jogadores foi gasto não realmente jogando o jogo, mas
assistindo a cenas totalmente não interativas, com essas seções cinematográficas geralmente amadoras e um
pouco piores do que se encontraria até mesmo no programa de TV mais barato. Isso serve para explicar por que o
gênero rapidamente caiu em desuso entre os jogadores. Outros jogos, como o já mencionado Command & Conquer
e Dark Forces, usavam seções FMV entre os níveis que compunham o jogo real. Esses jogos tiveram a sorte de
realmente incluir uma jogabilidade viável e atraente e, portanto, se destacaram como jogos, independentemente da
inclusão do FMV. No entanto, as seções FMV desses jogos foram criadas usando atores ao vivo em mundos que
não se pareciam em nada com os mundos em que a jogabilidade acontecia. Outros jogos, como MechWarrior 2 e
meu próprio Centipede 3D, usaram ambientes 3D pré-renderizados de polígonos super altos para lidar com essas
cenas, criando um ambiente que não se parecia em nada com os gerados pelos mecanismos 3D em tempo real
usados para a jogabilidade. O resultado é uma experiência visual desarticulada para os jogadores, algo que quebra
qualquer suspensão de descrença que os jogadores possam ter estabelecido. O uso de cut-scenes já é uma
experiência muito chocante para os jogadores; em um minuto os jogadores têm um papel ativo nos procedimentos,
no próximo eles têm que ser passivos, satisfeitos em sentar e assistir. Usar cenas que não se parecem em nada
com o mundo do jogo só agrava as coisas.
Muitos jogos incorporaram com sucesso cutscenes que usam os mesmos gráficos que os visuais do jogo,
voltando para jogos 2D como Pac-Man, Karateka e Maniac Mansion, até títulos RT3D modernos como The Legend
of Zelda: Ocarina do Tempo e os jogos Drakan . Nesses jogos, embora os jogadores possam perder o controle do
jogo brevemente, pelo menos eles têm uma experiência visual completamente perfeita. Os artistas podem reclamar
Cut-scenes em Karateka
são todas manipuladas
usando o motor do jogo,
resultando em uma
experiência visual perfeita para o jogado
que as cut-scenes não parecem tão boas; afinal, eles só podem brincar com o número de polígonos
que podem ser renderizados em tempo real. Mas o que pode ser perdido em termos de qualidade
visual é mais do que compensado pela consistência geral do jogo.
Outro aspecto estranho das cut-scenes em muitos jogos de computador é sua natureza não
interativa, o que indica a incapacidade do designer de entender as capacidades do computador
como um dispositivo interativo. Considere os espectadores de um filme ou peça de teatro, ou o
público nacional assistindo a um programa de televisão. O público dessas produções não consegue
interagir de forma alguma com os procedimentos: a performance acontece e depois acaba. Por
outro lado, alguém lendo um livro, assistindo a um vídeo ou ouvindo uma história pode experimentar
o meio na velocidade que quiser. As páginas podem ser relidas em um livro, as fitas de vídeo
podem ser rebobinadas ou adiantadas, e uma criança pode pedir aos pais que expliquem ou
releiam parte da história que ela não entendeu. A principal diferença aqui é que o público do
primeiro conjunto de mídias não interativas é um grande grupo de pessoas, enquanto o público do
último conjunto é uma única pessoa.
Considere o público de um jogo de computador. É um grupo ou um único indivíduo?
Obviamente, para jogos multi-jogador o público pode ser mais de um, mas jogos multi-jogador
quase nunca se preocupam com cutscenes de qualquer tipo. Não, os jogos de contar histórias que
exigem cutscenes são quase todos projetados como experiências para um jogador. Por que, então,
quando o texto rola no briefing da missão de um jogo, o usuário não consegue retroceder? Na
verdade, por que está rolando? Os computadores são excelentes ferramentas para dar aos
usuários controle sobre sua experiência e, como os jogadores geralmente estão jogando sozinhos,
quem se importaria se eles lessem o texto em sua própria velocidade, controlada por uma barra de
rolagem ou setas no teclado? Da mesma forma para cenas de corte: por que os usuários quase
nunca podem voltar para assistir a cena novamente? E se eles perderem uma parte da história que
desejam ouvir ou apenas quiserem aproveitar a apresentação novamente? Pior ainda, muitas
cutscenes não podem ser pausadas, apenas ignoradas. Pereça o pensamento de que alguém
pode realmente querer fazer uma pausa em algum momento durante uma longa cena. A prevalência
de cenas apenas puláveis leva a uma confusão angustiante entre os usuários de jogo para jogo,
pois eles se perguntam: “Se eu apertar o botão Iniciar, ele pausará a cena ou pulará?” Parece que
as seções fora do jogo de jogos de computador são menos fáceis de usar do que quase qualquer
outro meio de experiência solo. Parece provável que os designers de jogos possam ser
pensando que são diretores de cinema e, portanto, querem criar uma experiência de cinema,
apesar da natureza extremamente diferente do meio com o qual estão trabalhando.
O sistema de salvamento
inteligente do Last Express
permite que o jogador volte no
tempo do jogo para assistir
novamente a cenas cortadas
ou jogar partes do jogo
novamente.
Alguns jogos são inteligentes o suficiente para permitir que os usuários controlem a
reprodução de cutscenes. O Last Express , em particular, vem à mente, com seu exclusivo recurso
de salvar o jogo “ovo” que permite aos usuários voltar a qualquer ponto do jogo e experimentá-lo
novamente. O jogo se orgulhava de transpirar em tempo real ou próximo ao tempo real e, portanto,
os jogadores podiam voltar os ponteiros de um relógio para qualquer hora específica em que
estivessem interessados e o jogo os retornaria a esse ponto, um característica essencial para a
compreensão da complexa história do jogo. Vários jogos começaram a permitir que os jogadores
visualizem todos os seus vídeos pré-renderizados por meio de uma opção no menu principal, uma
vez que tenham visto os filmes durante o jogo normal. Isso permite que os jogadores reproduzam
facilmente partes dos vídeos que podem ter perdido na primeira vez. Meu próprio jogo, Damage
Incorporated , usava briefings de missão extremamente interativos para garantir que os jogadores
entendessem o que tinham que fazer em um nível.
Os jogadores podiam usar as teclas de seta para alternar entre documentos de texto e imagem.
Durante esses briefings de missão, também havia diálogos falados que complementavam o
material impresso na tela. Os jogadores podem pausar, retroceder e avançar esse diálogo falado
conforme desejado usando os controles do toca-fitas exibidos na parte inferior da tela. Dessa
forma, os jogadores podiam ler o texto na velocidade que quisessem e ouvir novamente as partes
do diálogo que podem ter perdido.
Infelizmente, a única interação com as cut-scenes que muitos jogos incluem é a capacidade
dos jogadores de ignorá-las completamente. Isso é essencial, já que muitos jogadores vão querer
pular as seções não interativas do jogo, como qualquer sessão de teste revelará. Forçar os
jogadores a assistir às cenas é uma limitação totalmente desnecessária que nenhum jogo deve
tentar impor. Como expliquei acima, melhor do que pular completamente é permitir que os
jogadores pulem para frente e para trás nas cutscenes conforme desejarem.
Se pararmos por um momento para considerar a natureza dos dispositivos fora do jogo para
contar histórias em jogos, ficaremos impressionados com o conceito estranho que é interromper o
experiência interativa com uma não interativa. Por exemplo, quando você vai ao cinema, os
funcionários do teatro param o filme, acendem as luzes e orientam o público a ler um livro que eles
distribuíram? Às vezes, o texto é mostrado na tela, mas nunca de uma forma que exija que o público
leia mais do que algumas palavras de cada vez.
Em vez disso, os filmes apresentam uma experiência de mídia consistente para o público. Os jogos,
por outro lado, ainda misturam mídia de maneiras aparentemente não naturais, forçando os usuários
que querem apenas jogar um jogo a ler um pouco de um livro ou assistir a um filme, e só então
começar a jogar. Certamente há uma maneira melhor de contar uma história, transmitir um enredo e
apresentar personagens de dentro do próprio jogo que é muito superior à narrativa fora do jogo, pelo
menos em termos de manter uma experiência fluida para os jogadores.
Por outro lado, o uso de cut-scenes em jogos tem sido tão prevalente que agora são uma
convenção de jogos aceita, e os jogadores passaram a esperá-los. Eles também evoluíram na forma
como são integrados à jogabilidade para serem muito melhores do que simplesmente colocados, e
foram usados em jogos sem arruinar completamente a experiência dos jogadores. De fato,
originalmente tentamos evitar cenas cortadas inteiramente no meu jogo The Suffering, mas
descobrimos que, como era principalmente um jogo de perspectiva em terceira pessoa, o jogador
geralmente estava muito longe para ver todos os elementos de uma cena de história complexa
claramente. . Isso ocorreu em parte porque não planejamos adequadamente nossas cenas para
funcionar bem de uma visão tão distante, o que não é uma tarefa fácil para uma equipe acostumada
a usar cenas cortadas e visões de câmera em close-up em tais eventos. Quando decidimos usar
cenas cortadas, optamos especificamente por mantê-las no mínimo absoluto e usá-las apenas para
momentos bastante assustadores e intensos ou eventos importantes de narrativa. No final, sinto que
o uso de cutscenes no jogo foi razoável e não prejudicou muito o jogo, e certamente nenhuma
imprensa ou fãs reclamaram disso. Mas até hoje não tenho certeza se foi a escolha certa. O que
ganhamos em ter cenas “mais legais” perdemos na imersão do jogador.
Embora The Suffering

tenha usado muitas
técnicas de narrativa no
jogo, também incluiu
cutscenes quando necessário.
Mas incluir cutscenes não destruirá completamente o seu jogo, e certamente muitos jogos que
eu amo usaram-nas. De fato, muitos meios de comunicação empregaram a suspensão igualmente
bizarra de convenções que quebram a descrença, como a total falta de
conversa normal em óperas, a capacidade de aprender o que um personagem está pensando em um

romance, ou uma câmera de filme aparentemente flutuando no ar acima de uma determinada cena em um filme.
Ao tentar adicionar a narrativa a um jogo para aumentar seu impacto emocional, é extremamente difícil
entrelaçar toda essa história no jogo em si sem nunca recorrer a técnicas fora do jogo, e tentar fazê-lo
quase certamente alterar o tipo de história que você é capaz de contar. Por exemplo, em The Suffering ,
queríamos que os personagens humanos que você encontrasse ao longo do jogo transmitissem informações
importantes ao jogador.
No entanto, no final, essa informação pode não ser muito importante, pois todas as cenas acontecem no
jogo quando o jogador tem a opção de matar os personagens a qualquer momento. Isso faz sentido, já que
o jogador está fortemente armado e, embora muitos jogos não permitam que você use suas armas em
NPCs amigáveis, achamos que essa era uma decisão ainda pior do que usar mais cutscenes. É claro que
havia algumas maneiras de ter personagens humanos que eram invulneráveis até depois de transmitirem
suas informações cruciais, como fazê-los falar por um sistema de PA, colocá-los atrás de um vidro à prova
de balas ou mantê-los longe de o jogador (onde poderia ser razoável que o jogador errasse se atirasse
neles). Estes, é claro, tinham suas próprias desvantagens, o que poderia fazer a história parecer bastante
complicada. De fato, uma vez que decidimos usar cutscenes, em alguns casos eles resolveram uma série
de dificuldades que tínhamos com elementos da história que o jogador poderia interromper, problemas
para os quais ainda não tínhamos encontrado uma resposta. Mas ainda tentamos manter o número de
cutscenes no mínimo absoluto.
Para contar histórias fora das cut-scenes, usamos vários personagens mortos-vivos e, portanto, invencíveis
para transmitir pontos-chave da trama. Isso funcionou para nós porque era um jogo de terror e se encaixava.
Se estivéssemos fazendo um jogo de crime como Grand Theft Auto III ou Vice City, provavelmente
precisaríamos recorrer a cutscenes para transmitir os principais componentes da história, que é exatamente
o que esses jogos fizeram. Eles também mantiveram suas cenas tão curtas e limitadas quanto possível
(com mais sucesso em Grand Theft Auto III do que em Vice City) e as implementaram de forma a minimizar
a interrupção da imersão do jogador no jogo. Embora não sejam ideais, as cut-scenes podem ser uma
ferramenta útil para contar histórias quando não são abusadas.
No jogo
Existem inúmeras técnicas poderosas para contar uma história durante o jogo. Half-Life foi universalmente
elogiado na imprensa de jogos pela força de sua história. No entanto, se olharmos para a história do jogo,
não é realmente tão atraente, talvez até banal.
Muitos outros jogos, até mesmo muitos outros jogos de tiro em primeira pessoa, continham histórias
igualmente convincentes. O que Half-Life fez bem, no entanto, foi contar sua história inteiramente de dentro
da jogabilidade. Os jogadores nunca perdem o controle de seu personagem, Gordon Freeman, mesmo que
ele esteja trancado em uma sala de observação, preso em um bonde ou jogado em um compactador de
lixo. A história é comunicada através de uma combinação de configurações de nível, cientistas tagarelas,
anúncios pelo sistema de PA e comportamentos roteirizados de NPCs. No final do jogo, os jogadores têm
a impressão de que a história foi excelente por causa da maneira convincente como foi contada.
Algumas das diferentes técnicas que se pode usar para contar uma história através do jogo são
as seguintes:
• Texto: Muita coisa pode ser comunicada aos jogadores através de textos espalhados pelo mundo
do jogo. Estes podem ser sinais explicando direções para locais, notas de alfinetes deixadas
por habitantes anteriores de uma determinada área, grafites na parede ou livros deixados para
os jogadores lerem.
• Configurações de nível: Quase todos os jogos usam essa técnica, independentemente de tentarem
contar uma história ou não. Considere o cenário do jardim de Centipede, o cenário infernal de
Doom, ou até mesmo o cenário imobiliário art déco do jogo de tabuleiro Monopoly. A pequena
história que esses jogos têm é contada inteiramente através do cenário, mas o cenário também
pode ser a chave para contar histórias de jogos mais complexas. A exploração do mundo do jogo
pelos jogadores pode levar a descobertas sobre o tipo de pessoas que habitam uma determinada
área, ou a habitaram em anos passados. Em vez de ler em uma cena que a terra está degradada
e decadente, os jogadores podem simplesmente ver essa verdade navegando no mundo do jogo.
Quando a barragem se rompe porque o senhor do mal quebrou sua promessa, os jogadores
podem ver isso pela água inundando o solo ao redor deles. O cenário é um exemplo perfeito de
mostrar uma história em vez de contá-la. • Diálogo: Diálogo com NPCs durante o jogo é outra
ferramenta extremamente poderosa que os designers podem usar para um ótimo efeito de narrativa.
Este diálogo pode ser falado durante o jogo através de conversas que os jogadores têm com
NPCs, onde os jogadores podem escolher a resposta de seu personagem ao diálogo do NPC,
seja por meio de uma múltipla escolha de respostas ou digitando sua própria resposta. O diálogo
também pode acontecer de forma não interativa durante o jogo com NPCs, amigáveis ou hostis,
falando com os jogadores durante o jogo e, assim, comunicando mais da história do jogo. O
diálogo também pode vir de terminais de computador, sistemas de PA ou toca-fitas, para citar
apenas alguns dispositivos plausíveis.
• Comportamentos dos NPCs: Claro, os NPCs não devem apenas conversar com o jogador; eles
devem realizar ações que respaldem a linha da história. Por exemplo, digamos que os
jogadores lutam contra duas raças diferentes de alienígenas no jogo e, de acordo com o
enredo, as duas raças se desprezam amargamente. Se os jogadores lutarem com os dois ao
mesmo tempo, eles devem ser capazes de enganá-los para lutarem entre si. Em uma vila
pacífica, se o personagem do jogador se aproximar dos NPCs com suas armas em punho,
talvez os NPCs fujam do jogador. Em uma cidade mais hostil, os NPCs podem sacar suas
próprias armas e ameaçar atacar o personagem do jogador se ele não resistir. Os NPCs
também podem se envolver em comportamentos roteirizados que comunicam aos jogadores
a natureza do mundo do jogo. Por exemplo, digamos que as pessoas de uma cidade vivam
com medo da força policial semelhante à da Gestapo. Conforme o personagem do jogador
entra, ele pode observar um morador da cidade recebendo uma surra dura e injusta de um membro da
Os jogos da Maratona usavam texto habilmente para comunicar sua história, sem nunca tirar os
jogadores do jogo. O jogo apresentava terminais de computador espalhados pelos níveis pelos quais
os jogadores navegavam. Os jogadores podem caminhar até um desses terminais e pressionar a tecla
“ação” para ativá-los. Então a visão dos jogadores do mundo do jogo seria substituída por uma visão
de perto do terminal. Os jogadores poderiam então usar as teclas de seta para alternar entre diferentes
telas de texto, o que revelava mais detalhes sobre o enredo e dizia aos jogadores qual era seu objetivo
para o atual.
nível. A grande coisa sobre esses terminais era que enquanto os jogadores os liam, embora não
pudessem mais ver o mundo do jogo, o mundo do jogo ainda estava muito ativo e os jogadores
podiam ser atacados por alienígenas ou afogados pela água subindo. Isso algumas vezes deu
certa urgência à leitura dos terminais, mantendo ativa a tensão do mundo do jogo dos jogadores.
Claro, os jogadores podiam controlar o texto virando para frente e para trás nas telas, relendo o
texto na velocidade que quisessem. O jogo subsequente da Bungie, Halo, extraiu muitos de seus
pontos fortes de ideias introduzidas pela primeira vez em Marathon. Halo também apresentou
uma excelente narrativa no jogo através dos companheiros de equipe que acompanham os
jogadores em várias missões, a IA do computador que fala com os jogadores através de suas
armaduras e eventos que acontecem no mundo do jogo. Infelizmente , Halo não incluiu nada tão
novo quanto os terminais de computador de Marathon , uma técnica dentro do jogo, mas em vez
disso apresentou cutscenes, uma técnica fora do jogo.
Os jogos Marathon
permitem que os
jogadores acessem
terminais de computador
espalhados pelos níveis,
onde podem ler mais
sobre a complexa história
do jogo. Na foto:
Maratona 2.
A Damage Incorporated usou uma combinação de comportamentos e diálogos de NPCs

para dar aos jogadores algum senso de caráter sobre os companheiros de equipe que os
acompanham nas várias missões do jogo. Os jogadores podiam escolher entre treze fuzileiros
navais diferentes os quatro que queriam acompanhá-los em uma determinada missão. Cada um
desses fuzileiros navais tinha uma personalidade distinta e comunicaria isso através do diálogo
que ele falava durante as próprias missões. Essa caixa de diálogo pode incluir a resposta a uma
diretiva dos jogadores, um comentário sobre a natureza da missão em si ou uma resposta à morte
particularmente eficaz de um inimigo pelos jogadores. Além disso, diferentes companheiros de
equipe podem reagir de maneira diferente ao serem levados em missões diferentes. Alguns dos
fuzileiros eram menos saudáveis mentalmente do que outros e, se assumidos em muitas missões,
ficariam “chocados” e correriam ao redor do nível aleatoriamente, murmurando coisas sem sentido
o tempo todo. Outros fuzileiros teriam objeções morais a algumas das missões para as quais a
equipe foi enviada. Como resultado, esses companheiros de equipe desonestos se rebelavam
contra os jogadores e seus outros companheiros de equipe em certas circunstâncias, gritando
sua desaprovação pela tarefa em mãos enquanto faziam uma fúria assassina. Assim, uma
combinação de diálogos e comportamentos de NPCs criou um grupo de companheiros de equipe
com personalidades reais, quase todas comunicadas durante o próprio jogo.
Uma das grandes preocupações que algumas pessoas têm com a narrativa no jogo é que os jogadores
pode perder um pouco da história. E se os jogadores não conseguirem ver a história sendo contada? Como
os jogadores nunca perdem o controle do jogo com a narrativa no jogo, isso torna possível
jogadores para evitar falar com personagens, testemunhar comportamentos de NPCs com scripts ou ler
sinais. É verdade que bloquear jogadores na frente de uma cena não interativa ou rolagem
o texto é uma maneira de garantir que eles vejam exatamente o que o designer quer que eles vejam.
Mas, como afirmei anteriormente, é preciso lembrar que os jogos são uma
forma, e o fato de os jogadores não experimentarem todos os elementos da história faz parte
da natureza da interatividade. Se os jogadores estão interessados em obter toda a história, é
sua responsabilidade de procurá-lo. Se os jogadores preferirem apenas carregar através do
jogo focando apenas na jogabilidade, essa é a escolha deles. De fato, ter diferentes camadas da história
que podem ser descobertas ao jogar o jogo uma segunda vez pode
ser um incentivo significativo para a repetição do jogo.
Em The Suffering , usamos várias técnicas de narrativa no jogo. Esses
incluíam métodos simples, como vozes que vinham do sistema de PA, chamadas telefônicas assombradas
que o jogador receberia, notas que você poderia pegar e ler à vontade,
cenas envolvendo criaturas sobrenaturais, e os jogadores companheiros humanos
conhecer enquanto exploravam o mundo do jogo. Todas essas técnicas ficaram por conta própria, sem
desencadear uma cena ou fazer qualquer outra coisa para quebrar a imersão do jogador. Um
dos nossos dispositivos de narrativa mais inovadores era o que chamamos de “flashes ambientais” no jogo.
Estas eram basicamente visões de eventos da história do jogo,
normalmente jogado em câmera lenta com vários efeitos de tela sobrepostos em cima deles, mas
com o jogador mantendo o controle do personagem principal e ainda tendo a liberdade de
olhar ao redor do ambiente. De fato, às vezes um flash ambiental seria definido
para acionar quando o jogador estava literalmente no meio das aparições, e
assim gostaria de girar a câmera em torno de si mesmo para ver tudo antes do
visão de repente chegou ao fim. Descobrimos que, tanto para os flashes ambientais quanto para
outras cenas roteirizadas no jogo, embora os jogadores possam perdê-las se acontecerem
desviar o olhar uma vez que a cena começasse, a maioria dos jogadores veria as cenas para
conclusão se eles foram orientados na direção correta quando as cenas começaram.
Assim, fazer com que as cenas tivessem uma boa chance de serem vistas era um desafio de design de
níveis em que tínhamos que colocá-las onde os jogadores naturalmente tendiam a olhar à medida que
correu através de um nível. Além disso, usamos gatilhos especiais que não eram apenas baseados em
a posição do jogador, mas também para onde ele estava olhando. Esses gatilhos só seriam ativados quando
o jogador tivesse uma certa parte do ambiente em um determinado lugar no
tela, garantindo ainda mais que o evento roteirizado seria visto como pretendíamos, tudo sem realmente
tirar o jogador do jogo. Finalmente, tivemos o cuidado de incluir
mais conteúdo de história no jogo do que você precisaria para entender o que estava acontecendo com o
enredo. Assim, se os jogadores vissem apenas 75 ou até 50 por cento dele, eles ainda
entender a história e desfrutar de sua experiência.
Quase todo mundo já teve um professor de inglês que enfatizou a importância de
mostrando em vez de contar na escrita criativa. Em vez de ser dito que as pessoas estão
ricos, os leitores devem ser capazes de ler a descrição do autor de uma área e a partir disso
deduzem que a região é povoada por um povo próspero. Para os jogos, contar histórias no jogo é o
equivalente a mostrar, enquanto as cenas fora do jogo e outros métodos
estão dizendo. Levando a ideia um passo adiante, Noah Falstein gosta de dizer que o
Embora The Suffering

tenha usado algumas
cutscenes, muita narrativa
foi feita usando técnicas
de narrativa no jogo.
O equivalente em jogos da regra “mostre, não conte” é “faça, não mostre”. Nos jogos, você quer manter
os jogadores ativamente envolvidos na história, “fazendo” ações em vez de serem “mostrados”. A narrativa
no jogo é uma parte fundamental disso. Além de manter a imersão dos jogadores no mundo do jogo, a
narrativa no jogo torna os jogadores participantes ativos da história do jogo, em vez de apenas piscar na
frente de seus olhos.
Materiais Externos
Muitos jogos usaram materiais externos para contar suas histórias. Isso foi particularmente verdadeiro na
década de 1980, quando o espaço em disco era severamente limitado e os designers não conseguiam
encaixar toda a história que queriam incluir em um único disquete de 400K ou menor. Alguns designers
usaram manuais para comunicar a história de fundo do jogo, escrevendo uma narrativa que levaria os
jogadores até o ponto em que eles começariam a jogar o jogo. Alguns jogos, como o clássico Wasteland,
até usavam livros de “parágrafos”, onde o jogo seria jogado por um tempo, e então, quando os jogadores
chegassem a um momento de narrativa, eles seriam instruídos “Agora leia o parágrafo 47”. Às vezes,
essa referência ao manual era usada como uma forma de proteção contra cópia, pois os jogadores não
podiam jogar o jogo sem ter uma cópia do manual.
Os jogos de arcade também usavam materiais externos. Freqüentemente, os nomes dos

personagens do jogo eram escritos na lateral do gabinete, em vez de dentro do jogo. Alguns gabinetes
até incluíam algumas frases explicando melhor o cenário do jogo e a missão em questão.
A arte apresentada nas laterais dos gabinetes de jogos de arcade usava gráficos superiores para
adicionar uma pequena quantidade de profundidade às escassas linhas de história que os jogos podem ter.
Hoje em dia, contar histórias em manuais e outros materiais é geralmente desaprovado, e com
razão. Certamente não somos mais apresentados às limitações tecnológicas que exigiam contar histórias
por meio de materiais externos. Além disso, muitas vezes as histórias contadas nos manuais não foram
escritas pelos designers do jogo ou mesmo com sua consulta. Portanto, essas histórias dificilmente
podem ser consideradas parte do jogo em si, mas sim a tentativa do departamento de marketing de criar
um mundo de jogo que eles pudessem divulgar na parte de trás da caixa. Às vezes, algumas peças de
texto que configuram a ação do jogo são
incluídos no manual do jogo, mas estes quase nunca são fundamentais para a compreensão do
jogador sobre o enredo do jogo. Eu certamente nunca usaria um manual para ser o único lugar para
transmitir a história em um dos meus próprios jogos, pois acredito que isso diminui a experiência
contínua de jogar o jogo no computador ou console. The Suffering incluiu algumas peças de história
de fundo no manual, mas estas eram puramente suplementares e aprimoravam a história do jogo para
os jogadores que as procuravam, sem prejudicar nada dos jogadores que não as procuravam.
Dito isto, alguns jogos usaram materiais externos de forma extremamente eficaz. Em particular,
os jogos da Infocom sempre incluíam materiais nas caixas que aumentavam a experiência de jogo dos
jogadores de maneira significativa. Muitas vezes, os jogos se referiam a esses materiais, dizendo algo
como “A revista que você encontra é a mesma que veio na embalagem do jogo”. Esses materiais eram
habitualmente preparados pelo ou em conjunto com o autor do jogo, tornando-os assim partes válidas
do próprio jogo. Para obter mais informações sobre como a Infocom usou seus materiais empacotados
para adicionar profundidade à história e suas motivações para fazê-lo, consulte a entrevista com o
autor da Infocom, Steve Meretzky, encontrada no Capítulo 10.
Armadilhas da Escrita Linear

Um dos principais problemas de história que muitos jogos de computador têm é que suas histórias são
escritas por pessoas que gostariam de estar escrevendo em um meio mais linear. Às vezes, roteiristas
ou romancistas clandestinos são contratados para trabalhar em projetos de jogos. Esses escritores
muitas vezes se sentem desapontados por ter que trabalhar em jogos e ver seu trabalho como algo
que fazem estritamente pelo dinheiro, ao mesmo tempo em que se vêem acima dos jogos como uma
forma de arte. Como resultado de seu treinamento em escrita linear e desgosto pela escrita interativa
em geral, esses escritores usam todas as técnicas de escrita linear que aperfeiçoaram ao longo dos
anos e tentam aplicá-las aos jogos, onde falham miseravelmente.
Às vezes, os próprios desenvolvedores de jogos secretamente ou não tão secretamente desejam

estar trabalhando em outro meio e fazem suas escolhas de escrita de histórias de acordo.
Afinal, desde que os jogos existem, o cinema tem sido um meio mais respeitado, popular e
financeiramente compensador para se trabalhar, com gigantescos cultos à personalidade cercando
atores, diretores e às vezes até escritores. Os designers de jogos podem ser sugados por esse fascínio
e ficar com inveja dos cineastas. Esses designers geralmente começam a enfatizar a natureza
cinematográfica de seus jogos, às vezes tentando negar que sejam jogos chamando-os de “filmes
interativos”. As cut-scenes cinematográficas dos jogos tornam-se cada vez mais longas, com o enredo
predeterminado dominando completamente a jogabilidade.
E de certa forma, os erros que os desenvolvedores de jogos cometem ao colocar a história em

seus jogos são perdoáveis devido à juventude do meio. Por exemplo, quando a tecnologia que
possibilitou a realização de filmes foi introduzida, muitos dos primeiros filmes que foram feitos eram
documentos de peças de teatro. Uma câmera foi colocada em posição fixa em um tripé e os atores
consideraram seu quadro como seu palco, como se estivessem trabalhando com uma plateia ao vivo.
Não havia cortes, panelas ou movimento de câmera de qualquer tipo, porque a linguagem do filme
ainda não havia sido inventada. Com o passar do tempo, no entanto, os cineastas aprenderam que
seus filmes poderiam ser mais do que transcrições diretas de peças de teatro, e eles poderiam, em vez disso,
aproveitar os pontos fortes de seu novo meio. De certa forma, os jogos ainda sofrem do mesmo
problema, onde mídias estabelecidas, filmes em particular, são tomadas e simplesmente jogadas
em jogos sem considerar como uma história pode ser melhor contada em uma linguagem adequada
à interatividade.
O que resulta desses escritores lineares frustrados são projetos que tentam ser tanto jogos
quanto filmes, geralmente com o resultado final que eles não fazem muito bem. Pegar um enredo
e adaptá-lo para funcionar em um jogo é como pegar um enredo que funciona em um romance e
adaptá-lo para funcionar em um filme. A força de um romance está em permitir que os leitores
realmente entrem na cabeça de seus protagonistas, leiam o que estão pensando. Em um filme,
muito do entendimento do público sobre um personagem vem da capacidade de ler os laços sutis
de expressão no rosto do ator. Quando um roteirista adapta um romance, ele precisa reimaginar
como isso poderia funcionar em um filme, substituindo o que funcionou bem no livro, mas não se
traduzirá bem na tela. Em comparação com romances ou filmes, os jogos precisam ser
significativamente mais ativos, com o personagem que o jogador está controlando tendo muito o
que fazer na história. Isso é especialmente verdade devido ao status atual do desenvolvimento do
jogo, onde fazer o diálogo com outros personagens divertido é quase impossível. Até que a
tecnologia avance ao ponto em que os jogos sejam capazes de simular conversas significativamente
melhor do que atualmente, as histórias dos jogos precisam se concentrar em ações que os jogos
fazem bem. Essa é uma das muitas razões pelas quais escrever histórias para jogos é
significativamente diferente do que para mídias não interativas. Além disso, escrever uma história
adequada a uma experiência interativa é extremamente difícil porque temos muito pouca experiência
com ela, certamente quando comparada com os séculos de experiência humana que foram
investidos na narrativa linear. Mas contar uma história adequada a um espaço jogável refletirá na
qualidade do seu jogo final. Há uma série de sintomas que surgem quando histórias inadequadas
são usadas, e reconhecer esses problemas à medida que eles surgem é crucial para evitar que
eles estraguem seu jogo.
O primeiro problema é forçar os jogadores a vivenciar a história em apenas um caminho
predeterminado. O escritor linear geralmente sente que há apenas uma maneira de o drama se
desenrolar, e se os jogadores tentarem fazer qualquer outra coisa, eles, ou pelo menos seu
personagem, devem ser mortos. O escritor linear não quer permitir que os jogadores descubram
diferentes maneiras de navegar pelo espaço da história quando há apenas um caminho que torna
a narrativa mais poderosa. O que o escritor linear não percebe é que os jogos permitem que os
jogadores encontrem seu próprio caminho através do mundo do jogo, mesmo que a história sofra
um pouco como resultado. O que o caminho pode perder em drama, ele compensa nos sentimentos
de propriedade dos jogadores. É a história do jogador em vez da história do designer.
Personalidade do personagem do jogador
Escritores lineares também tentam forçar o personagem do jogador a ter uma personalidade forte.
Existe uma tendência popular no design de jogos que diz que os jogadores querem ter personagens
principais com personalidades fortes para eles controlarem, principalmente em jogos de aventura e
ação. Mas se olharmos para as entradas mais populares desses gêneros, rapidamente
perceberemos que a personalidade do personagem do jogador é frequentemente reduzida ao
mínimo. Olhe para Mario em Super Mario 64 ou Super Mario Sunshine. Embora Mario tenha uma
aparência bastante distinta, qual é realmente sua personalidade? Na verdade, ele não tem um,
deixando-o indefinido o suficiente para que os jogadores imprimam sua própria personalidade nele.
E a Lara Croft em Tomb Raider? Novamente, uma aparência muito distinta, mas uma personalidade muito indefi
Apesar de ser talvez o

personagem de jogo de
computador mais famoso
que existe, Mario tem uma
personalidade relativamente
indefinida.
Na foto: Super Mario
Sunshine.
se olharmos para o Space Marine em Doom ou Gordon Freeman em Half-Life, não encontraremos
nenhuma personalidade.
A razão para isso é simples: quando os jogadores querem jogar, muitas vezes eles querem
jogar sozinhos. Se o personagem que eles estão controlando tem uma personalidade muito forte,
há um efeito de distanciamento, lembrando os jogadores de que o jogo é em grande parte
predeterminado e fazendo com que eles sintam que não estão realmente no controle do que acontece no jo
Particularmente frustrantes são os jogos de aventura que apresentam personagens de jogadores
fortemente caracterizados que continuam falando linhas de diálogo irritantes. Lembro-me de um
jogo de aventura em particular onde os jogadores tinham que controlar um pirralho mimado que
constantemente dizia coisas irritantes e idiotas para si mesmo e para os personagens que
encontrava. Quem iria querer controlar tal personagem? O diálogo para o personagem foi realmente
divertido e muito bem escrito, mas não para os jogadores que foram forçados a passar pelo jogo
usando esse personagem detestável como seu substituto no mundo do jogo. Parece que o escritor
do jogo se empolgou com essa caracterização interessante sem perceber o efeito prejudicial que
teria na experiência de jogo dos jogadores.
Claro que há uma série de jogos populares que tiveram sucesso com personagens principais
extremamente bem definidos. Duke Nukem 3D, os jogos Monkey Island com Guybrush Threepwood,
No One Lives Forever com Cate Archer, qualquer jogo com James Bond, os jogos Oddworld , Max
Payne e qualquer um dos jogos posteriores de Final Fantasy , todos continham personagens de
jogadores extremamente bem definidos. que tinha pilhas de diálogos em cutscenes e durante o
jogo. Quando os jogadores jogam esses jogos, eles estão definitivamente agindo como guia para
outro personagem, em vez de se tornarem o protagonista. Assim, esses jogos se concentram
menos na imersão e mais no entretenimento dos jogadores em um nível narrativo mais simples e
fazem isso muito bem. Nesses jogos, os jogadores sentem mais que estão jogando para
desbloquear uma história predeterminada, que as aventuras desses personagens fortes já são
conhecidas e que eles estão apenas descobrindo-as jogando o jogo. O jogo mais recente da série
Prince of Persia , The Sands of Time, definiu o personagem principal mais do que qualquer um dos
jogos anteriores da série, e levou o conceito de “jogador descobrindo uma história” um passo
adiante. No jogo, o personagem principal atua como narrador do jogo, e cada vez que o jogador
falha em cumprir um objetivo
o personagem do jogador é ouvido dizendo: "Não, não, não foi isso que aconteceu." Em termos de
história, esses jogos são realmente mais filmes interativos do que jogos. Eles enfatizam a história
do designer como a história definitiva e fazem pouco para promover a história do jogador. Esses
jogos provam ser bem-sucedidos porque contêm histórias de designers tão bem escritas e
apresentam uma jogabilidade extremamente boa misturada a ela.
Prince of Persia: The

Sands of Time apresentou
uma história de designer
muito bem escrita e forte,
tornando-a mais importante
do que a história do
jogador.
É interessante notar, no entanto, dois jogos que deliberadamente se esforçaram para ter
personagens principais que ficaram mudos e foram, portanto, mais icônicos: Grand Theft Auto III e
Jak & Daxter. O mais interessante é que para as sequências de ambos os jogos, ambos os seus
respectivos desenvolvedores decidiram fazer seus personagens principais falarem, diminuindo
assim o potencial de imersão do jogador. Grand Theft Auto III , é claro, foi um sucesso
massivamente popular e apresentou um personagem que nunca disse uma palavra durante o jogo.
O jogo ainda estava cheio de personagens bem escritos e interessantes que o jogador conheceu
enquanto se movia por um ambiente obscuro do submundo, mas o personagem principal foi
projetado especificamente para ter uma qualidade de homem comum e nunca falou. Através de
suas ações, ele exalava uma atitude dura e fria, mas sua falta de diálogo tornou mais fácil para os
jogadores se projetarem nele. No próximo jogo da série, Grand Theft Auto: Vice City, o jogo foi
melhorado em quase todos os aspectos com mecânicas de jogo mais rígidas, gráficos melhores,
música licenciada ressonante e um elenco de personagens coadjuvantes mais colorido e bem
escrito. Neste jogo, no entanto, o personagem principal fala bastante, tanto durante as cut-scenes
quanto ocasionalmente durante o jogo. Embora eu diga que o diálogo de cena funciona muito
melhor do que o diálogo do jogo, nenhum deles fez nada para melhorar a popularidade do jogo
com fãs ou críticos, e no geral o jogo se saiu tão bem quanto seu antecessor. (Isso pode ser
injusto, já que o primeiro era tão popular que seria muito difícil ser mais popular.) Um jogo que foi
um pouco menos de sucesso, embora ainda bastante popular, foi Jak & Daxter, que também
continha um personagem principal mudo. Comentando sobre o primeiro jogo, o co-fundador da
Naughty Dog, Jason Rubin, afirmou: “[Jak] também não fala muito, então você não sente que está
jogando Gex, e você não quer interpretar esse personagem – você não se sente desligado por
isso.” Quando o primeiro jogo não atendeu às expectativas, muitos elementos foram alterados para
a sequência, incluindo a adição de uma voz a Jak. Curiosamente, o jogo se mostrou um pouco
menos popular que o primeiro, tanto entre os fãs quanto com os críticos. Claro que há uma
infinidade de razões
por isso e dificilmente se pode atribuir apenas à decisão de fazer Jak falar, mas fazer essa
mudança não foi algo que foi visto como uma melhoria substancial para o
jogos.
Em The Suffering, a imersão foi um dos nossos principais objetivos de design, e ter o
personagem principal, Torque, sem falar foi uma grande parte disso. Em particular, o jogo
dependia do jogador determinar que tipo de pessoa Torque era e se ele era ou não culpado do
crime hediondo que o levou ao corredor da morte no início do jogo. Parecia estranho ter um jogo
em que você determinava a natureza moral do personagem principal, onde você não conseguia
se tornar esse personagem. Durante o desenvolvimento, houve uma discussão sobre tornar a
personalidade de Torque mais forte ao fazê-lo falar, mas no final decidimos que apoiar a
capacidade dos jogadores de se tornarem Torque era extremamente importante em termos de
jogadores se preocupando com a história do jogo. Se Torque tivesse sido mais fortemente
definido como um personagem, os jogadores teriam ficado com a sensação de que tudo sobre
ele já estava predeterminado e que eles não podiam controlar seu destino, ou que tudo o que
eles pudessem controlar era estritamente enlatado.
A busca por um personagem no qual os jogadores possam se projetar é algo muito mais
importante nos jogos, onde o jogador deve estar no controle do que acontece, do que em
qualquer outra mídia. No grande livro de Scott McCloud, Understanding Comics, ele passa um
capítulo discutindo a representação icônica de personagens em desenhos animados e como
isso permite que os leitores se projetem nos personagens muito mais do que em obras
fotorrealistas. Ao longo do livro, McCloud se desenha como narrador e apresentador e usa um
estilo muito abstrato e caricatural. Explicando essa escolha, ele afirma: “Por isso resolvi me
desenhar em um estilo tão simples... Sou apenas uma vozinha dentro da sua cabeça. Você me
dá vida lendo este livro e 'preenchendo' essa forma muito icônica (de desenho animado). Quem
eu sou é irrelevante. Eu sou apenas um pedacinho de você.” Quanto mais abstrata a noção do
personagem, mais o público poderá preencher as lacunas consigo mesmo. McCloud afirma que
é por isso que as imagens dos desenhos animados são tão difundidas em nossa cultura; as
pessoas podem se envolver muito mais com imagens icônicas do que com representações mais
detalhadas e, portanto, específicas da realidade. Da mesma forma, é por isso que personagens
abstratos são tão predominantes em jogos de computador.
Ter ou não um personagem central especificamente definido em seu jogo é uma decisão
pessoal e depende do que você está tentando realizar. Você pode contar uma história
convencional mais rica se você fizer com que o jogador controle um personagem muito distinto,
mas você pode atrair o jogador para o jogo muito mais se você mantiver o personagem principal
icônico e permitir que os jogadores sintam que são responsáveis por determinar o personagem
desse personagem. personalidade e destino. Pessoalmente, acredito que as vantagens de ter
jogadores se sentindo o herói superam as vantagens de ter um personagem forte. Lembre-se de
que seu jogo ainda pode ter personagens fantásticos e, de fato, sem personagens fortes, seu
jogo não terá muita história. Em vez de tentar imbuir o personagem principal com muita
personalidade, torne os NPCs que os jogadores encontram no jogo memoráveis e interessantes.
Se os jogadores acharem esses personagens irritantes, isso é aceitável; isso significa que eles
têm personalidade suficiente para que os jogadores se sintam fortes em relação a eles. Mas o
personagem dos jogadores deve ser suficientemente amorfo e não formado para que os
jogadores possam pensar nesse personagem da maneira que acharem melhor. E não tenha
medo, depois de passar quarenta ou mais horas com esse personagem, os jogadores terão suas própria
e dirige seu substituto no mundo do jogo. O personagem que eles criam em sua mente será aquele
de quem eles gostam e com quem eles vão querer continuar a jogar.
Histórias de jogos
Como discuti, ao escrever uma história para um jogo, é importante ficar longe das convenções da
mídia linear, como forçar os jogadores a seguir apenas uma narrativa e instilar muito caráter no
substituto do mundo do jogo dos jogadores. Além das armadilhas a serem evitadas ao criar a
história do jogo, o roteirista do jogo deve se preocupar menos com o enredo geral e mais com as
situações em que os jogadores se encontram e os personagens com os quais interagem. De fato,
muitos diretores de cinema estão cientes dessa técnica. Por exemplo, ao falar sobre seu filme
notoriamente confuso The Big Sleep, o diretor Howard Hawks disse: “Fazendo este filme percebi
que você realmente não precisa ter uma explicação para as coisas. Contanto que você faça boas
cenas, você tem uma boa imagem – realmente não importa se não for uma boa história.”
Joguei inúmeros jogos em que o enredo geral foi completamente perdido para mim; Eu
simplesmente não me importei em segui-lo. Muitas vezes, nesses jogos, gostei da jogabilidade,
das situações em que o jogo me colocou e dos personagens interessantes e divertidos que conheci lá.
Como os personagens e as situações eram interessantes, não importava muito se eu sabia quem
fazia o quê com quem e quando. Tudo o que eu sabia era que estava me divertindo jogando o jogo.
Muitas vezes, quando os jogos tentam me atingir na cabeça com seu enredo através de longas
cutscenes que entram em detalhes minuciosos sobre as razões para o estado do mundo do jogo e
as motivações do personagem para cada ação, torna-se tedioso. Lembre-se de que os jogadores
querem jogar. Se a história melhorar essa experiência, isso é bom, mas se a história começar a
atrapalhar a jogabilidade, isso é ruim. Falar demais da história também é uma falha comum de
escritores iniciantes. Leitores, espectadores e jogadores são capazes de descobrir muito mais do
que autores iniciantes lhes dão crédito. Faz sentido para a autora da história ter todas as
motivações do personagem descobertas em detalhes, com todas as nuances das diferentes
reviravoltas da trama detalhadas em seu caderno. De fato, ter uma rica história de fundo ou uma
bíblia de histórias pode ser uma maneira fantástica de garantir consistência e permitir que
alterações ou adições posteriores ainda se ajustem à ficção geral do jogo. Mas todos os elementos
desta história precisam ser incluídos no jogo? Não, o mais importante é que as peças apresentadas
aos jogadores sejam consistentes e possam ser usadas para montar a história completa. Os
jogadores não se importarão se cada último ponto da trama não for explicitamente explicado.
No Capítulo 9, “Inteligência Artificial”, falei sobre o conceito de “constelação” de Brian Moriarty

e como ele pode ajudar a criar uma IA mais interessante. A constelação é uma tendência natural
que os contadores de histórias de jogos também podem usar a seu favor. Moriarty descreveu a
constelação na mídia como a capacidade de um público preencher os buracos ou inconsistências
presentes em uma experiência de contar histórias, independentemente da forma que essa história
possa assumir. Por exemplo, se um contador de histórias apenas sugere a verdadeira aparência
de um inimigo maligno, a imagem conjurada na mente de um membro da platéia pode ser muito
mais assustadora do que o que o contador de histórias pode descrever para o público. Pode-se
também olhar para a base de fãs de um programa de TV como Star Trek. A menor insinuação de
um pouco de história pelos escritores do programa levará a especulações sem fim entre os
membros da platéia sobre quais são as implicações dessa dica sutil, e os fãs criarão suas próprias
explicação para o que isso pode significar. Esta pode ou não ser a explicação que o escritor pretendia
originalmente, mas o importante é que ela envolve o público na obra em um grau muito maior, mudando-
o de um modo passivo para um ativo. É claro que os jogos já são muito mais interativos do que a
televisão e, portanto, faz sentido que os contadores de histórias de jogos não contem ao público todos
os detalhes de uma trama. Isso envolverá os jogadores ainda mais no jogo, enquanto eles tentam
descobrir exatamente do que se trata a história. E acima de tudo, eles terão o prazer de evitar longas
cenas expositivas e voltar ao jogo.
Não-linearidade
Muito se fala em não linearidade nos jogos, e a narrativa em particular é uma área chave onde a não
linearidade pode ser usada para melhorar a experiência de jogo dos jogadores. Eu sinto que o objetivo
da narrativa do jogo é criar uma história na qual os jogadores sintam que podem desempenhar um papel
significativo que pode afetar o resultado. A não linearidade é uma ferramenta essencial para atingir esse
objetivo. De certa forma, a narrativa no jogo não é linear. A narrativa no jogo permite que os jogadores
conversem com alguns personagens e não com outros, escolham quais sinais ler e quais ignorar e
explorar o mundo do jogo para revelar sua relevância para o enredo, exploração sobre quais jogadores
ter controle. Com os jogadores habilitados a explorar o espaço da história à sua maneira, algum grau de
não linearidade é inevitavelmente criado. Isso certamente foi verdade em The Suffering e com Odyssey
antes dele, onde eu coloquei muita história nos jogos que muitos jogadores não necessariamente
encontrariam, tornando a exploração do espaço da história pelos jogadores um tanto não linear ou pelo
menos única para eles.
Grande parte da história

em The Suffering precisa
ser encontrada pela
exploração do jogador.
Uma maneira popular de adicionar não linearidade à experiência de contar histórias é por meio de
uma história ramificada. Com uma história ramificada, em vários pontos as decisões que os jogadores
tomam terão um efeito significativo em como a história progride. Isso pode significar que se os jogadores
conseguirem derrotar um certo adversário, a história irá progredir de forma diferente do que se os
jogadores não conseguirem matar aquele inimigo. No último caso, pode ser que os jogadores tenham
que matar aquele inimigo mais tarde, ou que o inimigo convoque uma força para ajudá-lo que os
jogadores terão que enfrentar. É claro que histórias ramificadas aumentam a quantidade de conteúdo
que precisará ser criado para um jogo, pelo menos em termos de design de jogo e diálogo, se não também em rec
Isso às vezes pode tornar essa técnica impopular entre os contadores de custos, que veem a
criação de tais ativos como dinheiro desperdiçado. O que eles não conseguem ver é que, se a
linha de história ramificada for implementada corretamente, a recompensa da jogabilidade será
tremenda, tornando o jogo mais popular e lucrativo.
Outra técnica que pode ser usada para injetar alguma não-linearidade na história do jogo é
permitir que os jogadores determinem a ordem em que os diferentes componentes da história
ocorrem. Suponha que haja três seções da história que você precisa contar. Talvez a ordem em
que os jogadores experimentam esses componentes não seja tão importante. Com um pouco de
trabalho extra, você pode dar aos jogadores a escolha de qual seção fazer primeiro, qual fazer em
segundo e qual fazer por último. Se pensarmos nisso em termos dos “capítulos” da história de um
jogo, muitas vezes os designers descobrem que, embora o primeiro e o último capítulo da narrativa
devam acontecer no início e no final do jogo, respectivamente, os outros capítulos do jogo podem
acontecer em qualquer ordem. É claro que podem surgir problemas com a dificuldade das seções,
já que, idealmente, os designers querem que a dificuldade de seus jogos aumente continuamente.
Isso, no entanto, é mais uma questão de design de jogos, e que designers inteligentes serão
capazes de resolver. Também apresenta problemas com a própria história, onde o escritor deve
manter esses enredos discretos para que possam ser experimentados em qualquer ordem e ainda
fazer sentido. Isso pode ter o efeito colateral negativo de que você não pode ter cada um desses
capítulos intercambiáveis da história construídos um sobre o outro da mesma maneira que você
faria em uma história completamente linear. Muitas vezes isso não é um problema, no entanto, e a
vantagem de ter jogadores criando sua própria experiência supera as desvantagens.
É claro que a narrativa não linear nos jogos anda de mãos dadas com a jogabilidade não
linear; dificilmente se pode imaginar um sem o outro. A não linearidade é mais explorada no
Capítulo 7, “Os Elementos da Jogabilidade”.
Trabalhando com a jogabilidade

Uma das partes mais importantes da criação de uma história para um jogo de computador é
combinar a história com a jogabilidade o máximo possível. Anteriormente, no Capítulo 3,
“Brainstorming de uma ideia de jogo”, discuti como o desenvolvimento de um jogo pode começar
com tecnologia, jogabilidade ou história/cenário. Se você está iniciando seu processo de
desenvolvimento de jogos com jogabilidade ou tecnologia, isso vai ditar diretamente que tipo de
história você pode contar. Se você tentar combater a jogabilidade ou a tecnologia com uma história
que não é adequada, ficará com uma história mal contada em um jogo mal executado. Existem
infinitas histórias a serem contadas e infinitas maneiras de contar uma determinada história. Seu
trabalho como designer de jogos é encontrar uma história e contar essa história que funcione com
o design e a tecnologia do jogo que você usará. É razoável alterar um pouco a jogabilidade para
apoiar a história que você está tentando contar. Deve haver uma troca justa entre os dois, mas no
final você precisará lembrar que é um jogo que você está desenvolvendo e que a jogabilidade
quase sempre deve ter precedência.
Para mim, as histórias parecem cair naturalmente da jogabilidade. Eu raramente penso em
uma história de forma independente e tento encaixá-la em alguma jogabilidade. Em vez disso, vejo
as restrições do mundo com o qual estarei trabalhando e começo a pensar no conteúdo mais
interessante possível para esse espaço. Não vejo essas restrições como uma limitação à minha
capacidade de contar uma história, mas mais como diretrizes ou mesmo fontes de inspiração. Por
exemplo, na Damage Incorporated, muito antes do jogo ter uma história, havia uma tecnologia e
um design de jogo em mente. Desde o design do jogo, centrado em jogadores controlando
A história de Damage
Incorporado foi criada
para se encaixar na
jogabilidade e na tecnologia.
companheiros de equipe em um ambiente FPS, surgiu a ideia dos diferentes companheiros de

equipe que acompanhariam os jogadores, e como cada um deles teria uma personalidade distinta.
Que tipo de homem estaria no Corpo de Fuzileiros Navais da década de 1990? Como eles
reagiriam a uma situação de combate? Qual seria a reação deles quando vissem seu comandante
morto? Estas foram as questões que acabaram por conduzir o desenvolvimento da história do
jogo. E essas questões surgiram diretamente das limitações impostas pelo design do jogo.
Da mesma forma, em The Suffering queríamos manter o jogador o mais imerso possível no
jogo e, portanto, queríamos ter um mundo de jogo contínuo onde o jogador percorresse cada
centímetro dele a pé. Também queríamos um espaço onde o jogador pudesse ser razoavelmente
limitado sem parecer artificial. Assim, definir o jogo em uma ilha relativamente pequena fazia
todo o sentido e funcionava como uma limitação física natural e crível para onde o jogador
poderia ir. Ao escrever a história, usei isso a meu favor, construindo o mito do jogo em torno de
seu cenário de ilha, a ponto de, do ponto de vista da história, o jogo ser inconcebível em qualquer
outro lugar. Da mesma forma, como estávamos construindo um jogo de ação, sabíamos que
teríamos que ter uma contagem de corpos bastante grande e, portanto, a ficção do jogo foi
escrita para suportar um suprimento infinito de criaturas horríveis surgindo de cavernas sob a
superfície da ilha. No final, as criaturas e a ilha parecem ser uma parte natural e apropriada da
história, mas originalmente eram decisões totalmente ditadas pela jogabilidade.
O sonho
Pode-se dizer que o objetivo da jogabilidade é permitir que diferentes estratégias do jogador
levem a tipos variáveis de sucesso, recompensar a experimentação e exploração do jogador e
capacitar os jogadores a fazer suas próprias escolhas. Todos esses fatores permitem que os
jogadores criem suas próprias histórias únicas ao jogar seu jogo. Se, além disso, você quiser
contar uma história mais predeterminada através do seu jogo, é importante fazer todo o possível
para que os jogadores sintam que é sua própria história única. Os jogadores devem sentir
propriedade sobre as ações em seu jogo e, portanto, propriedade da história que está sendo contada.
Pessoas de marketing e revisores de jogos gostam em parte de contar histórias em jogos porque
as histórias são muito mais facilmente compreendidas e discutidas do que os conceitos de design de jogos.
Escrever sobre a mecânica do jogo e o quão divertido é jogar um jogo é realmente difícil de fazer. Uma
história pode ser copiada facilmente para o verso da caixa ou para o texto de uma resenha e é muito
mais fácil de descrever do que a jogabilidade. Hoje em dia, os revisores de jogos ficarão frustrados se o
seu jogo não tiver muita história, independentemente de precisar ou não de uma. Jogos sem histórias
são considerados ultrapassados e arcaicos. Mas os revisores geralmente são sábios o suficiente para
reconhecer que a jogabilidade também é essencial, e os jogos que se concentram na história em
detrimento da jogabilidade tendem a ser criticados, e com razão. Infelizmente, o pessoal do marketing
realmente não se importará se sua história não for linear ou permitir que os jogadores façam a sua
própria história. De fato, os tipos de negócios vão adorar um personagem principal com uma personalidade
forte, pois será mais provável que leve a oportunidades de licenciamento para figuras de ação e shows
de desenhos animados nas manhãs de sábado. Não importa que a personalidade forte do personagem
possa afastar os jogadores do jogo.
Títulos como SimCity permitem

que os jogadores realmente
contem sua própria história,
com quase nenhuma orientação
do designer.
Mas, como designer de jogos, suas ambições devem ser maiores do que criar cópias divertidas ou
simplificar o trabalho dos revisores de jogos. Muitos grandes jogos dispensam inteiramente a narrativa
tradicional. Civilization e SimCity imediatamente vêm à mente como jogos indiscutivelmente ótimos que
permitem aos jogadores contar sua própria história, com o designer fornecendo apenas um ponto de
partida a partir do qual a história pode se desenrolar. Embora os jogos não exijam histórias pré-criadas,
uma história convincente pode dar significado às ações dos jogadores e fazer com que os jogadores
sintam que suas decisões são importantes. Além disso, uma história verdadeiramente interativa, onde a
narrativa pode mudar radicalmente dependendo das escolhas dos jogadores, mantendo a ressonância
emocional e o poder de uma história contada em um romance, é uma ideia muito atraente. É tão
convincente que é difícil imaginar qualquer designer de jogos verdadeiramente ambicioso que não
esperasse que um dia se tornasse realidade.
Capítulo 12
Análise do jogo:
Tear
Desenhado por Brian Moriarty
Lançado em 1990
jogo. Embora tivesse muitas semelhanças de jogabilidade com os jogos de

Para 1990, o ano
aventura em que
gráfica foihaviam
que lançado, Loom
sido era umanteriormente
lançados tipo decididamente
pela diferente
LucasArts,deLoom
adven.
se esforçou para reduzir o jogo de aventura à sua mecânica principal do ponto de vista
da narrativa e cortar tudo o que era estranho. Olhando no manual, descobre-se que os
autores do jogo estavam cientes de que estavam criando algo diferente, como indica o
seguinte trecho da seção “Sobre o Loom” : O Loom é diferente dos “jogos de aventura”
tradicionais em muitos aspectos. Seu objetivo é permitir que você participe do
desenrolar de uma fantasia rica e instigante. Não é um jogo de role-playing (embora
incorpore elementos de role-playing), nem uma coleção de quebra-cabeças. Seus
mistérios simples são projetados para envolver sua imaginação
227
228 Capítulo 12: Análise do Jogo: Tear
e atraí-lo mais para dentro da história, não para frustrá-lo ou aumentar a quantidade de
tempo que leva para terminar.
Mais adiante no manual há uma seção intitulada “Nossa filosofia de design de jogos”, que
contém uma declaração reimpressa em vários manuais de jogos de aventura da LucasArts da
época. Nele se encontram ainda mais referências de quão únicos eram os jogos Loom e LucasArts:
Acreditamos que você compra nossos jogos para se divertir, não para ser atingido na
cabeça toda vez que cometer um erro. Portanto, não paramos o jogo quando você enfia o
nariz em um lugar que não visitou antes. Ao contrário das aventuras convencionais de
computador, você não se verá acidentalmente saindo do caminho ou morrendo porque
pegou um objeto pontiagudo.
Achamos que você preferiria resolver os mistérios do jogo explorando e descobrindo,
não morrendo mil mortes. Também achamos que você quer gastar seu tempo envolvido na
história, não digitando sinônimos até tropeçar na palavra do computador para um determinado
objeto.
Lendo o acima, fica-se com a ideia de que talvez Loom tenha sido uma reação do autor do
jogo, Brian Moriarty, ao que ele viu em outros jogos de aventura como prejudicial à diversão dos
jogadores. Embora apenas a primeira declaração tenha sido escrita especificamente sobre Loom,
parece provável que ambos representassem com precisão os sentimentos de Moriarty sobre o
assunto. Loom iria manter os elementos de narrativa positiva dos jogos de aventura e remover
tudo o que entrava em conflito com o prazer dos jogadores pela história. Foi um sucesso
admirável, resultando em um jogo que parecia querer sinceramente que os jogadores
completassem sua história interessante.
Antes de vir para a LucasArts para trabalhar no Loom, Brian Moriarty trabalhou na Infocom
por vários anos, uma empresa conhecida pela qualidade e profundidade insuperáveis de suas
aventuras de texto. Lá ele criou duas aventuras de texto, Wishbringer e Trinity, e um híbrido de
aventura/role-playing somente de texto, Beyond Zork. Enquanto Wishbringer foi projetado desde
o início para ser um jogo fácil de jogar para iniciantes, Trinity e Beyond Zork eram jogos enormes
e terrivelmente difíceis de completar.
Loom, então, parece ser uma mudança de direção desses títulos, um retorno a um jogo que não
desafia os jogadores apenas por desafiá-los, mas inclui apenas os desafios que são críticos para
a história. Além disso, Loom foi o primeiro jogo de Moriarty a não envolver um analisador de texto,
um método de entrada que ele ficou muito feliz em eliminar, se alguém acredita que os sentimentos
expressos no manual são seus. Mais uma vez, a simplicidade de Loom parece ser uma reação à
complexidade desnecessária de jogos de aventura mais antigos, tanto em geral quanto os de
Moriarty. Em Loom, a história era o rei, e tudo o que estava em seu caminho foi removido.
Mecânica de jogo focada

Loom parece ser um exemplo perfeito de um jogo totalmente focado no que deseja realizar. Em
vez de tentar incluir todas as mecânicas de jogo que ele pudesse, parece que Moriarty pensou
muito sobre quais eram as mecânicas de jogo mínimas necessárias para contar sua história. Ele
então eliminou tudo o que realmente não acrescentava algo a essa história. Isso teve como
resultado uma grande simplificação
Capítulo 12: Análise do Jogo: Tear 229
A mecânica de jogo do
Loom está focada em contar
a história do jogo.
o jogo, ao mesmo tempo em que o torna consideravelmente mais elegante e fácil de navegar.
O jogo foi desenvolvido usando o SCUMM Story System, que a maioria dos jogos de aventura da
LucasArts usa de uma forma ou de outra. Creditado a Ron Gilbert e Aric Wilmunder, SCUMM significa
“Script Creation Utility for Maniac Mansion”, assim chamado em homenagem ao primeiro jogo a usar o
sistema. De fato, se olharmos para as outras aventuras da LucasArts, perceberemos que quase todas
têm muito mais em termos de mecânica de jogo e interface de usuário do que Loom. Tanto Maniac
Mansion (1987) quanto The Secret of Monkey Island (1990, mesmo ano de Loom) incluem inventários
para os jogadores manipularem, além de permitir que os jogadores cliquem em uma variedade de
verbos que podem ser usados em vários objetos do jogo. mundo dos jogos. Ambos os jogos foram
criados usando o sistema SCUMM, indicando que os sistemas de inventário e verbo estavam
prontamente disponíveis para Moriarty via SCUMM se ele quisesse usá-los. De fato, inventários e
verbos eram um elemento muito comum em quase todos os jogos de aventura lançados antes do Loom.
(Muitas aventuras lançadas desde Loom acabaram com verbos e inventários, mais notavelmente Myst
e seus muitos imitadores.) Então Moriarty estava fazendo uma tremenda ruptura tanto com o sistema
SCUMM quanto com a tradição quando deixou essas mecânicas de fora.
Incluir um inventário e verbos poderia ter acrescentado muita profundidade ao jogo se a história fosse
reconcebida para aproveitá-los. Mas do jeito que está, o jogo funciona perfeitamente sem eles.
Muitos outros jogos de aventura também apresentam árvores de diálogo ramificadas. Nesse tipo
de sistema, quando o personagem do jogador está conversando com outro personagem, os jogadores
são apresentados a uma lista de diferentes frases que seu personagem pode dizer. Os jogadores
podem então escolher entre essas escolhas e algum nível de interatividade é alcançado durante as conversas.
Mais uma vez, The Secret of Monkey Island apresentou exatamente esse sistema, usado pelo criador
do jogo, Ron Gilbert, para uma enorme recompensa na jogabilidade, particularmente nas sequências
clássicas de luta com espadas. Mas, assim como os verbos e o inventário, não há árvores de diálogo
ramificadas no Loom. Em vez disso, quando o personagem do jogador fala com alguém, os jogadores
apenas observam a conversa se desenrolar como uma cena não interativa, incapaz de
controlá-lo. Em um nível, isso parece remover um grau de interação do jogador com o jogo. Mas,
em última análise, os sistemas de árvore de conversação ramificados sempre contêm um número
finito de ramificações e, portanto, a maioria desses sistemas se transforma em jogadores
simplesmente clicando em cada uma das opções, uma por uma. (The Secret of Monkey Island é
um dos poucos exemplos de um jogo que realmente adiciona profundidade à jogabilidade com
conversas ramificadas.) Para Loom, Moriarty optou pelas conversas em cutscenes, já que elas
eram o sistema mais eficaz para transmitir sua história. Mais uma vez, Moriarty estava focado em
seu objetivo de contar histórias e não deixou nenhuma convenção de jogos de aventura ficar em seu caminho.
Interface de usuário
A interface no Loom é o epítome da simplicidade, exigindo que os jogadores usem apenas o
mouse e um único botão. Isso, é claro, torna o jogo muito fácil de aprender e jogar para qualquer
pessoa familiarizada com um sistema de apontar e clicar. Isso está em nítido contraste com muitos
outros jogos de aventura, particularmente as aventuras somente de texto que tiveram seu auge na
década de 1980, incluindo aquelas em que Moriarty trabalhou. Quase todos esses jogos incluem
um analisador de texto que, idealmente, permite que os jogadores insiram o que quiserem que
seu personagem faça usando linguagem natural. “Pegue o livro”, “Noroeste”, “Abra a porta com
chave vermelha” e “Olhe para a pintura” são exemplos de comandos comuns de tais aventuras de
texto. A limitação, infelizmente, era que muitos analisadores de texto não apresentavam um
conjunto completo de palavras no idioma inglês, nem podiam analisar corretamente frases
complexas. Na verdade, a Infocom, a empresa que publicou Wishbringer, Trinity e Beyond Zork,
de Moriarty, tinha de longe o melhor analisador de texto disponível. No entanto, o analisador ainda
pode ser um desafio de usar. Especialmente frustrante era quando os jogadores sabiam
exatamente o que precisavam fazer no jogo, mas não conseguiam encontrar as palavras corretas
para dizê-lo. Sem falar no fato de que, para o sistema funcionar, os jogadores precisam soletrar
tudo corretamente, tarefa na qual poucas pessoas se destacam. Na melhor das hipóteses, pode-
se familiarizar-se com as idiossincrasias de um analisador de texto ao longo do tempo, mas para
um iniciante o sentimento dominante era de frustração.
O Loom mantém sua

interface o mais simples
possível, fazendo com que o
jogador interaja com o mundo
do jogo usando apenas o mouse.
De fato, no trecho do manual incluído anteriormente, os antigos analisadores de texto são

ridicularizados. Parece que Moriarty estava pronto para passar para uma interface mais intuitiva e
fácil de aprender. Claro, um dos principais requisitos de qualquer interface é que seja fácil de
aprender. Os desafios que os jogadores enfrentam devem estar no próprio mundo do jogo, não
nos controles que eles precisam manipular para afetar esse mundo do jogo. Maniac Mansion já
havia usado uma interface inteiramente de apontar e clicar, e Loom emprestou muito da mecânica
desse jogo, pelo menos em termos de navegação no mundo. Os jogadores podiam mover seu
personagem, Bobbin Threadbare, pelo mundo simplesmente clicando no local para onde queriam
que ele fosse. Isso parece bastante óbvio para os jogadores modernos que viram inúmeros
sistemas de movimento de apontar e clicar em jogos que vão de Diablo a Grim Fandango e
Command & Conquer. Parte da beleza do sistema é sua obviedade; depois de vê-lo em ação, não
se pode imaginar de que outra forma você dirigiria um personagem usando um mouse.
No entanto, Maniac Mansion e outras aventuras gráficas ainda incluíam verbos para os
jogadores clicarem. Esses verbos eram basicamente um resquício dos analisadores de texto; os
jogadores clicariam primeiro em um objeto e depois em um verbo para manipular esse objeto de
acordo. Algumas outras aventuras gráficas substituíram esses verbos por ícones que funcionavam
de forma idêntica aos seus equivalentes de texto. É claro que, em muitos casos, havia apenas um
verbo/ícone que teria algum efeito útil em um objeto específico, tornando a funcionalidade dos
ícones amplamente irrelevante. Loom eliminou os verbos inteiramente para permitir que os usuários
simplesmente cliquem duas vezes em um determinado objeto e, em seguida, façam o jogo
descobrir o que eles queriam fazer com o objeto. Se os jogadores clicassem duas vezes em uma
pessoa, Bobbin Threadbare falaria com ela. Se fosse um objeto com texto, Bobbin o leria. Se fosse
uma ovelha, ele a cutucaria. O jogo funciona com os jogadores em vez de contra eles, permitindo
que os jogadores executem apenas as ações que serão úteis para eles. O clique duplo é uma
extensão óbvia do clique único. O único clique move a Bobina para aquele objeto; um clique duplo
faz com que ele tente usá-lo. Obviamente, esse sistema de entrada também é idêntico ao modo
como o apontar e clicar é usado nas plataformas Macintosh e Windows, por isso tem a vantagem
adicional de que os jogadores provavelmente o entenderão antes mesmo de começarem a jogar.
A lição a ser aprendida aqui é que copiar ideias de entrada de padrões estabelecidos é quase
sempre melhor do que inventar algo novo.
Qualquer pequeno ganho que alguém possa obter com um novo método de entrada é quase
sempre negado pela frustração que os jogadores experimentam ao tentar aprendê-lo.
O Sistema de Rascunhos
Embora o jogo possa acabar com um inventário, verbos e conversas ramificadas, ele
adiciona uma mecânica de jogo única e bem projetada, acessível através da roca do
personagem principal. Este sistema permite que os jogadores lancem o equivalente a
feitiços em vários objetos do mundo. Este sistema é bem diferente dos sistemas de
lançamento de feitiços em qualquer outro jogo, e foi especialmente revelador em 1990.
Novamente, a interface é inteiramente de apontar e clicar, e é um sistema muito fácil de aprender.
O sistema é baseado em jogadores ouvindo diferentes tons em diferentes situações e depois
repetindo esses tons em sua pauta, de uma maneira que lembra um jogo de simon. Se os jogadores
clicarem duas vezes em uma roda giratória específica, uma série de quatro tons será tocada. Esses
tons também serão refletidos na roca dos jogadores, que é
exibido na parte inferior da tela. Abaixo da roca estão uma série de notas musicais
que correspondem a posições na roca: c, d, e, f, e assim por diante, até uma oitava completa.
Quando os jogadores ouvem os tons pela primeira vez, essas notas acendem para mostrar aos jogadores
visualmente quais são as diferentes notas. Os jogadores devem então se lembrar desta série de tons
(geralmente escrevendo), e então pode repetir os tons para lançar um
“rascunho” ou soletrar em um objeto diferente. Os jogadores repetem as notas simplesmente clicando em
diferentes locais da roca, uma interface lindamente intuitiva.
Se o jogador joga Loom

no ambiente especializado, o
notas musicais no
roca desaparecer, fazendo
o jogo significativamente
mais difícil.
Se os jogadores jogam no ambiente de especialista, o aprendizado de rascunhos se torna significativamente

mais difícil. A notação musical não está mais presente na tela, e agora
os jogadores só ouvem as notas; eles não piscam mais na roca. Isso força os jogadores a
“tocar de ouvido” para ter sucesso. Isso, aliado ao fato de que os tons exigidos
para uma mudança de rascunho a cada jogo, dá ao jogo significativamente mais replayability do que
muitos outros jogos de aventura. A natureza musical dos rascunhos e de todo o jogo é
uma tremenda ruptura com a maioria dos outros jogos que podem ser jogados com o som completamente
desligado. Em vez de apenas usar música como papel de parede sônico, o Loom torna o
música uma parte integrante do jogo.
A ordem dos tons também pode ser invertida para causar o efeito oposto de tocar
os tons para a frente. Os objetos que os jogadores clicam duas vezes para aprender originalmente os tons todos
correspondem aos rascunhos que eles ensinam aos jogadores: clicar duas vezes em uma lâmina ensina o
“afiar” a tiragem, clicar duas vezes na água pingando de um frasco ensina a tiragem de “esvaziar”, clicar duas
vezes em um pote cheio de corante borbulhante ensinará a tiragem “tinta”, e assim
para frente. Girar tiras com a roca é o principal método para realizar ações em
objetos no jogo. Às vezes, o rascunho aprendido não é totalmente óbvio, e algum pensamento criativo é exigido
dos jogadores para descobrir qual rascunho usar e onde.
Rascunhos que são aprendidos para uso em um aplicativo acabarão tendo aplicativos relacionados, mas
diferentes posteriormente. Por exemplo, uma corrente de ar que inicialmente choca um ovo acaba
ser bastante útil para abrir portas. Um rascunho que cura um humano também pode ser usado para curar um
rasgar o tecido do universo. Todas as conexões são sutis, mas lógicas. A manipulação desses rascunhos
constitui a fonte primária de quebra-cabeças no jogo, e eles são
usado de tal forma que os quebra-cabeças nunca são excessivamente complicados. Loom é um dos poucos
jogos de aventura em que, uma vez que um quebra-cabeça é concluído, os jogadores nunca sentem que o
quebra-cabeça foi arbitrário ou caprichoso.
Dificuldade
Mais uma vez, pelos comentários no manual, pode-se inferir que Loom foi feito desde o início para ser um jogo
fácil de jogar. Definitivamente, tem-se a sensação de que o jogo realmente quer que os jogadores tenham
sucesso e espera que os jogadores vejam o fim de sua adorável história. Tradicionalmente, os jogos de aventura
se orgulhavam de irritar os jogadores e fazê-los jogar o jogo de novo e de novo até que, depois de muito
sofrimento, uma recompensa foi distribuída.
Os jogos da LucasArts fizeram uma ruptura dramática em relação a outros jogos de aventura, na maioria
das vezes, impedindo que os jogadores fossem mortos ou ficassem presos.
Muitos jogos de aventura anteriores incluíam inúmeras maneiras de morrer, punindo assim os jogadores que se
esqueceram de salvar o jogo. Alguns jogos de aventura também permitem que os jogadores progridam no jogo,
mesmo que possam ter esquecido de fazer algo fundamental no início do jogo. Então os jogadores chegariam
a um local, não teriam o objeto necessário lá e não teriam como voltar para pegá-lo. Na verdade, os jogadores
estavam mortos, pois não podiam progredir no jogo, mas esse era um tipo pior de morte: era a morte disfarçada
de vida, onde os jogadores ainda podiam interagir com o mundo do jogo, mas não tinham chance de realmente
ganhar o jogo. . Os jogos da LucasArts estabeleceram um padrão que muitos jogos de aventura subsequentes
seguiram: não seja injusto com os jogadores.
Se os jogos da LucasArts em geral tentaram eliminar a frustração dos jogadores, Loom deu um passo
adiante para tornar o jogo o mais amigável possível. Alguns gritos foram feitos por jogadores que Loom era
muito fácil. De fato, os entusiastas de jogos de aventura que estavam acostumados com os jogos de aventura
que vieram antes do Loom acharam muito fácil terminar. Eles estavam acostumados a morrer em cada esquina
e passar horas batendo suas cabeças contra quebra-cabeças quase incompreensíveis. De fato, muitos
jogadores de aventura estavam acostumados a não conseguir terminar os jogos, pelo menos não sem comprar
um livro de dicas. Mas o problema de fazer jogos que atraíssem apenas os entusiastas veteranos era que
tornava difícil para qualquer novo jogador começar a jogar jogos de aventura. Se os jogadores ainda não
tivessem experiência com esses exercícios tortuosos e complicados de masoquismo, havia uma boa chance de
um jogo de aventura frustrar tanto os jogadores que eles não sentiriam vontade de tentar outro.
História
Com a mecânica do jogo focada para enfatizar o componente narrativo do jogo, todo o
jogo seria em vão se a história que Moriarty desejava contar não fosse da mais alta
qualidade. Felizmente, é. A história de Bobbin Threadbare, o escolhido “Loom-Child”,
cuja tarefa é restaurar o tecido da realidade, é de beleza simples e grande pungência.
Em seu aniversário de dezessete anos, Bobbin é convocado diante dos anciões, apenas
para assistir com espanto como eles são transformados em cisnes. Dame Hetchel, a
tecelã que tem sido como uma mãe para Bobbin, explica-lhe a terrível situação: o jovem
tecelão deve descobrir o que está destruindo lentamente o Tear e salvá-lo antes que
seja tarde demais. Assim começa a aventura de Bobbin, com suas viagens às várias guildas da
Muito do sucesso da
Loom se baseia na força
de sua história fantástica
e caprichosa.
de Loom, chegando a um clímax único completo com um final agridoce. Ao longo do caminho,
pedaços da marca registrada, humor da LucasArts são incluídos (um estilo de humor encontrado
em sua forma mais intensa em The Secret of Monkey Island), embora nunca a ponto de dominar a
história. Alguns jogadores podem ver a história como estritamente voltada para crianças, mas
Loom é um jogo infantil da mesma forma que O Hobbit é um livro infantil, O Cristal Encantado é um
filme infantil ou Bone é uma história em quadrinhos infantil. Todos contêm sofisticação e inteligência
suficientes para que não seja necessário ser criança para apreciá-los, apenas infantil.
A história é ideal para a jogabilidade que o Loom inclui, com a navegação e a rotação de
rascunhos sendo as únicas ações dos jogadores. A jogabilidade e a história estão tão bem
integradas que a jogabilidade acaba envolvendo o jogador na história muito mais do que se a
história fosse contada em um formato não interativo. Ao mesmo tempo, a história nunca parece
planejada por causa da jogabilidade, como muitas histórias de jogos de aventura fazem. O texto da
história é reduzido ao mínimo, nunca entrando em detalhes excessivos sobre qualquer coisa,
permitindo que a imaginação dos jogadores preencha os buracos. É uma história bem contada
visualmente, com a exploração e experimentação dos jogadores com a roca combinando com o
temperamento emocional do personagem que estão interpretando, Bobbin Threadbare. Como
Bobbin adquire a equipe pela primeira vez no início do jogo, faz sentido lógico que ele ainda não
seja um especialista nisso. Assim, as muitas tentativas fracassadas dos jogadores de usar os
rascunhos se encaixam perfeitamente no personagem de Bobbin. Isso contrasta com muitos jogos
de aventura onde, embora os jogadores estejam controlando um personagem inteligente e
experiente, os jogadores devem completar quebra-cabeças idiotas, como descobrir a senha de seu
personagem para fazer login em um sistema de computador, quando obviamente o personagem
que está sendo controlado já conhece essa informação. .
Um problema com jogos de aventura em terceira pessoa, jogos em que os jogadores veem
seu personagem no jogo em vez de apenas ver o que esse personagem veria, é que muitas vezes
o personagem em questão tem uma personalidade e aparência tão fortes que pode ser difícil para
os jogadores sinta-se devidamente imerso no jogo. Se o personagem estiver muito distante de um
que os jogadores possam se ver, os jogadores podem se tornar
frustrado quando esse personagem fala linhas de diálogo que eles não diriam ou executa outras
ações estúpidas. Loom resolve esse problema colocando Bobbin Threadbare dentro de uma capa,
com os jogadores apenas vendo seus olhos. Isso mantém o personagem principal anônimo o
suficiente para que os jogadores acreditem que, de fato, ele está dentro dessa capa. Em um ponto
do jogo em que Bobbin tira o capuz, o jogo rapidamente corta para uma cena diferente, quase
zombando do anonimato contínuo do personagem principal. E o diálogo de Bobbin é mantido nivelado
e anônimo o suficiente para que ele nunca diga nada que possa incomodar os jogadores. Muitos
desenvolvedores de jogos e editores falam em criar personagens fortes, talvez aqueles que possam
ser usados para figuras de ação e direitos de filmes mais tarde. Mas o que muitas vezes mantém um
jogo agradável para os jogadores é um personagem mais anônimo – um que os jogadores podem
esculpir em suas mentes em sua própria ideia de herói.
Loom como um jogo de aventura

Apesar de todos os seus pontos fortes, Loom ainda é um jogo de aventura e, de fato, bastante linear.
Os jogos de aventura são o gênero de jogos de computador mais preocupados com a narrativa
tradicional, ao mesmo tempo em que muitas vezes são os menos encorajadores da criatividade do
jogador. A história que está sendo contada em um jogo de aventura é a história do designer, que foi
claramente estabelecida com antecedência e que permite aos jogadores apenas experimentá-la sem
realmente poder mudar seu resultado. Os críticos dos jogos de aventura são rápidos em apontar
que, na verdade, os jogos de aventura não são jogos, mas apenas uma série de quebra-cabeças
encadeados com pedaços de história entre eles. Os quebra-cabeças, independentemente de sua
forma, servem como portas trancadas entre as diferentes partes da história e, para experimentar o
resto da história, os jogadores devem destrancar essa porta completando o quebra-cabeça. Os jogos,
dizem eles, são obrigados a reagir aos jogadores, enquanto um quebra-cabeça fornece um desafio
mais estático, que, uma vez resolvido, não é tão divertido tentar novamente. Esses críticos sugerem
que, uma vez que a história é vivida, por causa de sua natureza estática, dificilmente vale a pena
experimentá-la novamente.
A jogabilidade de Loom se
concentra no jogador resolvendo
quebra-cabeças simples e
elegantes. Uma vez resolvidos,
os quebra-cabeças não fornecem
muito valor de repetição.
E Loom, por toda a sua beleza e força de design, ainda sucumbe a alguns dos problemas dos
jogos de aventura. Durante as cut-scenes da conversa, o jogo é completamente linear e os
jogadores não têm nenhum controle sobre o jogo. Isso pode ser mais aceitável em doses menores,
mas algumas das cenas do Loom duram um período significativo de tempo. O jogo também pode
às vezes degradar em jogadores tentando clicar em tudo na tela, apenas para ver quais objetos
podem ser manipulados. Há uma boa chance de que, se um objeto puder ser manipulado, os
jogadores precisarão fazer algo com ele para completar o jogo. Isso é bom e ruim: bom porque
limita as ações dos jogadores a ações úteis, em vez de levá-los por um caminho falso atrás de
pistas falsas e diversões inúteis; ruim na medida em que limita severamente a interatividade do
mundo. E algumas vezes a arte da paisagem do jogo é desenhada de tal forma que é difícil
descobrir onde Bobbin pode navegar e onde ele não pode.
Mas, na verdade, essas são queixas menores. É tão ruim que Loom seja uma experiência
de contar histórias com uma história predeterminada? O jogo só vale a pena jogar novamente,
assim como ler um livro ou ver um filme pela segunda vez. Claro, repetir a leitura e visualização é
algo que muitas pessoas gostam, se o trabalho for bom o suficiente para justificar isso. Loom pode
não ser tão interativo quanto Civilization, mas todo jogo precisa ser tão interativo? Um jogo de
Civilization pode contar uma história interessante sobre a ascensão de um império e o avanço da
tecnologia, mas para mim nunca houve um jogo de Civilization com uma história tão envolvente e
tocante quanto a de Loom. Os críticos podem perguntar, por que não contar a história de Loom
como um livro ou um filme de animação? Claro, a história poderia funcionar nessas formas, mas
os jogadores seriam tão atraídos como quando eles têm permissão para explorar e interagir com o
mundo da história em questão? Por meio de um jogo de aventura como Loom, os jogadores
ganham um certo apego emocional e envolvimento nos eventos que acontecem que é impossível
em outras mídias. Talvez não seja um jogo por uma definição excludente, mas isso não o torna
menos valioso.
Capítulo 13
Multijogador
“Ninguém em seu leito de morte jamais disse: 'Gostaria de ter passado mais tempo sozinho com
meu computador'.”
— Dani Bunten Berry
famílias quanto tempo passam jogando seus jogos. Alguém poderia pensar
Como a citação acima sugere,
essa vergonha é porquepoucos jogadores
os videogames de um
para computador gostariam
jogador são de tão
uma busca admitir sua
solitária.
O interessante é como outras atividades igualmente solitárias – ler livros, ouvir música ou
estudar matemática – não são vistas como maneiras embaraçosas de passar o tempo. Além
de sua natureza muitas vezes pueril e conteúdo imaturo, uma diferença fundamental entre
jogos e outras atividades é que os jogos de computador para um jogador apresentam a
ilusão de interação com outro humano, embora nenhum outro humano esteja realmente presente.
Embora os agentes de IA tomem o lugar dos outros jogadores necessários para jogar um jogo que
não seja de computador, de muitas maneiras é realmente o designer que toma o lugar dos outros
jogadores. Infelizmente, o designer só pode tomar o lugar deles na medida em que ele pode se
colocar em forma digital em um CD ou DVD. É claro que, no final, a interação dinâmica que os
jogos single-player oferecem é muito mais limitada do que a que pode ser fornecida nos jogos multi-
player.
Mas para o mundo dos não-jogos, os jogos online para vários jogadores são vistos como tão
anti-sociais quanto os jogos para um jogador, se não mais. De fato, com um jogo online, o usuário
237
238 Capítulo 13: Multijogador
ainda está sozinho em uma sala com o computador, mas se o jogo for bem projetado, permite que o
computador projete os outros jogadores na tela de uma forma que excede em muito o potencial
expressivo de, digamos, um telefone. No entanto, para o mundo exterior, essas interações
interpessoais não são vistas como “reais”. Para eles, os jogadores do mundo estão lutando ou
cooperando ou simplesmente socializando não é um lugar que valha a pena estar. Os milhões de
fãs de jogos multiplayer sabem que esse espaço se torna real por causa das pessoas que o preenchem.
A realidade dos outros jogadores faz com que a experiência de jogar um jogo multi-jogador tenha
uma importância muito maior do que qualquer jogo single-player jamais poderia ter.
Embora os jogos comerciais online para vários jogadores tenham tido uma história difícil ao
longo da vida da indústria, não há dúvida de que, como um meio mais de massa, eles realmente
começaram a se firmar no início do século XXI. Esses jogos para vários jogadores atraem seguidores
tão dedicados e criam experiências tão atraentes que muitos não podem deixar de se perguntar:
assim que o resto do mundo alcança em termos de tecnologia e hábitos de jogo, são os dias de jogo
solo jogos numerados? De fato, se olharmos para os jogos não eletrônicos, os jogos para vários
jogadores são tão antigos quanto os próprios jogos, com jogos para um jogador, como paciência,
sendo a minoria extrema das opções disponíveis. Se olharmos para os clássicos, como xadrez,
Monopólio, Scrabble, Dungeons & Dragons, Cos mic Encounter, Magic: The Gathering ou The
Settlers of Catan, veremos a incrível amplitude e profundidade dos jogos multiplayer. Jogue em todas
as formas de esportes e verá uma forma cuja popularidade ainda excede em muito os jogos de
computador. Embora o legado de jogos multi-jogador baseados em computador seja mais limitado
do que seus irmãos single-player, a história da experiência humana com jogos multi-jogador oferece
uma rica história sobre a qual se basear.
Motivações
A popularidade dos jogos multijogador faz todo o sentido, pois eles satisfazem muitos dos desejos
dos jogadores descritos no Capítulo 1, “O que os jogadores querem”. Muitos desenvolvedores veem
a vantagem mais imediata dos jogos multijogador como a capacidade de substituir os oponentes da
IA por humanos reais, a fim de fornecer adversários muito mais profundos e imprevisíveis. Isso
aumenta a quantidade de desafio que um jogo pode oferecer e permite que um jogo permaneça
atraente por um período de tempo muito maior. Ao contrário dos agentes de IA do jogo, os oponentes
dos jogadores aprenderão enquanto jogam. À medida que os jogadores melhoram, seus oponentes
também melhoram e, assim, o desejo dos jogadores de serem desafiados é atendido. Uma vantagem
ainda mais significativa de ter oponentes humanos é a capacidade de socialização dos jogadores;
qualquer um que tenha jogado um jogo de tabuleiro pode dizer o quão importante é a socialização
entre os jogadores para essa experiência. De fato, muitas pessoas jogam jogos multijogador
exclusivamente porque querem se socializar com outras pessoas que jogam, não por causa de um
amor fundamental pelos jogos.
A presença de jogadores reais para os adversários traz consigo uma tremenda mudança na
importância percebida dos jogadores em jogar o jogo; em vez de apenas ganhar ou perder o jogo
em particular, por meio de seu componente social, os jogos multijogador tornam cada vitória e
derrota um assunto público e, portanto, significativamente mais significativo. O potencial de se gabar
aumenta tremendamente para um jogo multijogador, já que os jogadores agora têm alguém para se
gabar, assim como o potencial de vergonha em uma derrota retumbante. Independentemente de
ganhar ou perder, o potencial para glória e vergonha pode tornar o jogo um
Capítulo 13: Multijogador 239
um jogo para vários jogadores uma experiência muito mais emocional do que participar de uma
experiência para um jogador. Independentemente de vitória ou derrota, a capacidade dos jogadores de
se socializar em um jogo colaborativo e social, como um RPG massivamente para vários jogadores, pode
levar a realidades alternativas carregadas de emoção, onde os jogadores podem se casar e lamentar a
morte de um amigo quando pararem. jogando o jogo.
Finalmente, ter pessoas reais jogando com você pode ajudar a tornar o jogo significativamente
mais interativo, já que lidar com outros humanos é sempre uma experiência muito mais dinâmica do que
interagir apenas com um computador. Observar todos os “desejos” que os jogos multijogador satisfazem
faz com que o sucesso desses jogos não seja surpreendente.
Eles proporcionam aos jogadores um desafio, uma experiência social, o potencial para se gabar, uma
recompensa emocional significativa e uma experiência profundamente interativa. Ao trabalhar em jogos
para vários jogadores, é importante que os designers de jogos mantenham esses pontos fortes em mente
e certifiquem-se de que seus designs reproduzam as qualidades que os jogadores estão procurando.
Os jogos multiplayer são tão fortes em satisfazer o que os jogadores procuram que abrem novas
áreas de design e desenvolvimento de jogos, permitindo o uso de mecânicas que simplesmente não
funcionam em jogos single player. Mesmo que uma IA seja incrivelmente inteligente e desafiadora, os
jogadores ainda não vão querer socializar ou encenar com ela da mesma forma que fariam com um
humano. De fato, ao criar um jogo para vários jogadores, pegar um jogo para um jogador e convertê-lo à
força para vários jogadores pode ser extremamente limitante e impedirá que o jogo final atinja todo o seu
potencial. É importante lembrar que um componente multijogador nem sempre é uma melhoria para um
determinado jogo: alguns títulos são ideais para ser um jogador, assim como outros jogos só podem
funcionar como experiências multijogador.
Os formulários
Ao olhar para jogos de computador para vários jogadores, dois grupos de jogos se apresentam
imediatamente: jogos que são jogados por vários jogadores no mesmo local e amontoados em torno do
mesmo computador ou console, e jogos que são jogados online por vários jogadores que estão em locais
significativamente diferentes. Embora ambos sejam definitivamente experiências para vários jogadores,
esses dois tipos de jogos são extremamente diferentes e cada um apresenta seus próprios desafios de
design.
Multijogador de sistema único

Devido às limitações da rede, os jogos multijogador que ocorrem em torno de um único sistema de
computador têm sido populares e comercialmente viáveis por um bom tempo mais do que os jogos online.
Estes originalmente assumiram a forma de vários jogadores controlando seus substitutos do mundo do
jogo em uma visão compartilhada do ambiente do jogo, com o exemplo mais antigo sendo Pong e
progredindo através de jogos de arcade como Mario Bros., Gaunt let, Smash TV, muitos jogos esportivos. ,
e todos os jogos de luta. Esses jogos são limitados, pois ambos os jogadores precisam ser restritos a
relativamente a mesma parte do mundo do jogo para que ambos possam permanecer visíveis. O jogo
multijogador em tela única pode ser ainda mais problemático quando os jogadores precisam esperar um
pelo outro para executar determinadas ações. Por exemplo, no modo cooperativo em Baldur's Gate: Dark
Alliance, o outro jogador deve ficar ocioso enquanto um jogador manipula seu inventário. Alguns jogos
para PC, como o MULE, usavam uma única tela com cada jogador jogando enquanto o
Muitos dos primeiros

jogos multiplayer, como
Smash TV, confinavam
dois jogadores à mesma
parte do mundo do jogo.
outros jogadores esperaram, referido como jogo de assento quente. Uma solução para o
problema de restringir dois ou mais jogadores ao mesmo local veio com o advento dos jogos
em tela dividida, onde cada jogador tem uma seção do monitor dedicada a exibir a parte do
mundo do jogo que é relevante para o jogo. eles a qualquer momento. Isso inclui clássicos
como Mario Kart e continua até hoje para jogos como Centipede 3D ou War of the Monsters.
Este último título é um dos mais recentes de uma longa linha de jogos a mudar dinamicamente
para tela não dividida quando ambos os jogadores estão no mesmo local no mundo do jogo.
A tela dividida é usada ainda mais extensivamente para adaptações de uma única máquina
de jogos que foram originalmente projetados para serem jogados em uma rede, como os modos
de combate à morte em Halo, Syphon Filter ou SOCOM. Para esses jogos, há a desvantagem
distinta de que todos os jogadores podem ver a localização e o status dos outros jogadores
simplesmente olhando para sua parte da tela. Isso pode ser antiético, mas é difícil evitar quando
a visão deles está próxima da sua própria visão de mundo. Isso não é prejudicial para um jogo
como Mario Kart, mas muitas vezes pode enfraquecer a experiência em um jogo como Halo,
cuja jogabilidade de death-match é modelada após uma competição online e cega. No entanto,
o jogo em tela dividida não pode ser considerado injusto, pois todos os jogadores têm acesso
às mesmas informações sobre o status dos outros jogadores; o fato de ser de tela dividida
simplesmente o torna um tipo diferente de jogo. Alguns jogos de sistema único tentaram permitir
algum grau de jogo cego por meio de várias técnicas desonestas. Os Robot Rascals incluíam
um baralho de cartas especiais que ditavam as condições de vitória para cada jogador, com as
cartas mantidas em segredo até o final do jogo. O Sega Dreamcast incluiu um display no
controlador que permitia aos jogadores de jogos de futebol fazer suas seleções de jogo sem
que os outros jogadores vissem suas escolhas. Apesar das desvantagens potenciais em termos
de jogo cego, os jogos multijogador que ocorrem em torno de um sistema têm uma tremenda
vantagem em termos de interação social que geram. Sempre que você agrupa um monte de
pessoas, presumivelmente já amigos, em torno de uma única tela, eles têm a garantia de
conversar entre si e jogar de maneira diferente do que se os outros jogadores estivessem em
outra sala ou prédio. Qualquer um que tenha assistido à interação verbal e física entre os
jogadores em torno de um carro de corrida ou um título esportivo pode testemunhar isso e o
quanto os jogadores se divertem com essa interação. Embora a comunicação de voz em rede
e outros avanços possam ajudar a fazer com que os jogadores que estão distantes pareçam mais próximos
a proximidade física de seu oponente para comunicação humana real e camaradagem.
Multijogador on-line
É claro que os jogos em rede fornecem uma experiência de jogador significativamente mais
imersiva pela razão de que os outros jogadores são invisíveis uns aos outros. Para jogos online,
os jogadores têm seus próprios computadores e estão situados em locais separados e, portanto,
precisam se projetar muito mais no espaço do jogo, já que nenhum dos outros jogadores pode ver
como eles se parecem, ouvir o que estão dizendo ou observe como eles estão agindo. Jogos de
tiro em primeira pessoa como Unreal, Quake, Counter-Strike e Battlefield 1942 funcionam
extremamente bem em redes, já que a separação dos jogadores permite o jogo às cegas de uma
forma que a tela dividida não pode, tornando esses jogos muito mais desafiadores. Simulações de
combate aéreo, como o clássico Air Warrior , são uma das formas mais antigas de jogos
multijogador em rede e, em espírito, funcionam basicamente da mesma forma que os jogos de tiro.
Muitos jogos de estilo esportivo - incluindo jogos de corrida e jogos de luta - fornecem suporte
multijogador em rede, além de seus jogos multijogador de sistema único.
Embora isso fosse originalmente verdade principalmente nos PCs, o sucesso do Xbox Live fez
incluir um modo multi-jogador de rigueur em jogos de console, pelo menos onde essa jogabilidade
faz sentido.
Jogos online persistentes

para vários jogadores,
como Dark Age of Camelot,
criam mundos virtuais
elaborados nos quais os
jogadores podem mergulhar
completamente.
Jogos persistentes massivamente para vários jogadores (MMPs), como Ultima Online,
EverQuest e Dark Age of Camelot , tornaram-se cada vez mais populares nos últimos anos, embora
os MUDs (masmorras/domínios multiusuário) que os inspiraram existam há quase três décadas.
Esses jogos oferecem o que há de melhor em jogos online imersivos, com os jogadores gastando
muito tempo em mundos virtuais complexos.
Lá eles interagem e formam fortes laços com outros jogadores que muitas vezes nunca encontraram
no mundo físico. Embora esses jogos sejam quase sempre praticados por jogadores sozinhos em
locais separados, os laços sociais que se formam entre os jogadores tornam esses jogos
experiências extremamente sociais. De fato, jogar MMPs pode ser um estilo de vida
escolha que muitos casais vão jogar juntos, com as mulheres tendendo a apreciá-los mais do que
a maioria dos jogos. Esses jogos são muito mais abertos em seu design, enfatizando vários
caminhos para o sucesso e permitindo que os jogadores gastem seu tempo como quiserem.
Os jogadores podem fazer missões, conseguir um emprego e construir uma casa, ou simplesmente
passar todo o tempo socializando com as outras pessoas que encontram lá. De fato, alguns
acusaram esses MMPs de serem apenas salas de bate-papo habilmente disfarçadas. No entanto,
o designer-chefe do Ultima Online e Star Wars Galaxies , Raph Koster, é rápido em apontar que os
jogadores não jogarão esses jogos apenas pela experiência social. Como eles podem fazer isso
por e-mail ou ICQ, não haverá incentivo para continuar jogando (e pagando a taxa de assinatura
mensal que a maioria desses jogos cobra) se tudo o que eles estiverem fazendo com o jogo for
socializar. Para que seja bem-sucedido a longo prazo, o jogo deve fornecer um jogo interessante o
suficiente que facilite a socialização em conjunto com outras recompensas.
Cada uma das diferentes formas que os jogos multijogador podem assumir determina o tipo
de interação que os jogadores terão uns com os outros enquanto jogam. Isso, por sua vez,
determina qual tipo de jogo terá melhor sucesso nessas formas. Ter ambos os jogadores
compartilhando uma visão única do mundo do jogo exige cooperação entre os jogadores se eles
quiserem progredir para novas áreas. Ter uma tela dividida significa que, se o jogo for competitivo,
os jogadores não poderão evitar ver o que os outros jogadores estão fazendo. Ter jogadores em
sistemas separados significa que eles poderão jogar às cegas adequadamente, mas serão
significativamente prejudicados em sua capacidade de interagir uns com os outros durante o jogo,
não importa o que o designer do jogo faça para facilitar a socialização. Todos esses tipos de jogos
podem ser divertidos se, desde o início, o designer estiver totalmente ciente dos pontos fortes e
fracos do tipo de jogo multijogador que está construindo e projetar o jogo para funcionar de maneira
ideal dentro desse paradigma.
Considerações de projeto
É claro que os jogos para vários jogadores apresentam desafios significativamente diferentes em
seu design do que os jogos para um jogador. Por exemplo, o ritmo de jogos multijogador precisa
ser mais variado do que em jogos de um jogador, pela simples razão de que em um jogo
multijogador os jogadores não podem pausar o jogo, pois os outros jogadores precisariam pausar
simultaneamente também. Embora a maioria dos jogos single-player forneçam uma curva variável
com picos em alta tensão e vales em momentos mais calmos, acertar essa curva é ainda mais
importante em um jogo multiplayer, pois os jogadores não conseguem criar seu próprio vale
pressionando o botão de pausa. Sem poder pausar o jogo, os jogadores correm o risco de serem
massacrados pelos outros jogadores se baixarem a guarda por um momento. É da natureza
humana (pelo menos, para todos, exceto para os mais hard-core) precisar de pausas de qualquer
atividade, e um designer deve planejar seu jogo para que seja possível aos jogadores atender às
necessidades do mundo real sem precisar saia do jogo. Isso pode significar deixá-los escolher
quanto tempo esperar para reaparecer depois de morrer, fornecer lugares seguros no mundo para
eles se esconderem sem a ameaça imediata de morte ou ter uma duração de jogo curta o suficiente
para que a pausa não seja um problema importante.
Se possível, você deseja predeterminar quanto tempo levará para os jogadores jogarem seu
jogo, pelo menos em média. Você quer escolher um tempo que seja um investimento razoável para
seu público-alvo e, em seguida, tentar fazer com que o design do seu jogo suporte
comprimento. A maioria dos jogadores quer saber quanto tempo eles precisam para jogar seu jogo, já que
todos, exceto os mais hardcore, têm uma variedade de coisas para fazer com suas vidas além de jogar. É
uma decisão muito diferente jogar um jogo de copas online versus ir
em uma aventura épica em EverQuest ou iniciando um jogo multi-jogador de Civilization III.
Nos jogos de tabuleiro, o Monopólio é um bom exemplo de jogo que muitas pessoas se recusam a jogar
porque eles sabem quanto tempo pode levar nos piores casos. Os jogos podem se arrastar por dias.
Risco e Diplomacia fornecem exemplos ainda mais extremos desse mesmo problema. Se os jogadores
acharem que um jogo está demorando muito para eles (seja como uma aberração ou padrão
procedimento operacional) é provável que desistam no meio do jogo, algo
isso pode ser muito frustrante para os outros jogadores. Deixando os jogadores saberem o que são
entrar antes de iniciar um jogo é uma boa maneira de incentivá-los a jogar
todo o caminho.
Da mesma forma, se possível, você quer que seu design de jogo permita que os jogadores sintam que
eles ainda têm alguma chance de sucesso, mesmo quando estão perdendo. Jogos que
permitir que um jogador fique extremamente à frente dos outros jogadores, mas ainda requer um longo
e tedioso final de jogo para esse jogador completar a vitória encorajará o perdedor
jogadores a desistir, essencialmente perdendo. Embora isso não precise ser desastroso,
é melhor se o seu jogo for projetado para que os jogadores nunca sintam que toda a esperança está perdida. Mão única
para conseguir isso é através do emprego de sistemas de feedback negativo para dar aos jogadores que
estão ficando para trás uma chance melhor de alcançá-lo. Em uma palestra na Game Developers
Conference, Marc LeBlanc discutiu como os sistemas de feedback positivo podem empurrar o jogador
quem está à frente na competição ainda mais à frente, enquanto o feedback negativo manterá
a competição fechar. Por exemplo, em um jogo de corrida, se houver armas montadas no
frente dos veículos, os jogadores que estão atrás podem atirar nos jogadores que estão à frente,
fechando assim a lacuna. Se as armas estiverem montadas na traseira dos carros, no entanto, o feedback
é positivo, permitindo que o vencedor elimine os adversários que já estão atrás
isto. Portanto, com suas armas montadas na frente, Mario Kart é uma boa implementação de feedback
negativo que ajuda a manter as corridas mais próximas e, portanto, mais emocionantes.
Com sua montagem frontal

armas, Mario Kart é
uma excelente
implementação de feedback
negativo mantendo as corridas próximas
entre competir
jogadoras. Retratado aqui:
Mario Kart: Double Dash.
Claro, os jogadores ainda vão desistir do seu jogo, independentemente do quanto você
tente desencorajá-los. De fato, devido à natureza um tanto caótica da Internet, alguns jogadores
podem ser retirados do jogo no meio sem escolha própria.
Seu jogo precisará lidar com essas desistências de uma maneira elegante, de modo que os
jogadores restantes possam continuar jogando, se possível, com os jogadores ausentes
essencialmente perdendo seus slots. Você pode permitir que eles recuperem seus lugares no
jogo se eles se reconectarem com rapidez suficiente, para perdoar inevitáveis falhas na Internet.
Se a saída de jogadores no meio não for bem tratada pelo seu jogo, é quase certo que você está
fadado a frustrar os jogadores que querem continuar jogando.
Permitir que os jogadores personalizem seu avatar no mundo do jogo também é fundamental
para fazer com que os jogadores sintam que estão realmente se colocando no jogo. Isso pode
ser tão simples quanto escolher seu nome ou “alça”, ou escolher sua cor. Os jogadores também
vão gostar de escolher os talentos básicos de seu personagem, quer isso signifique decidir entre
infantaria, médico ou engenheiro em Battlefield 1942 ou entre paladino, ranger e feiticeiro em um
RPG. Diferentes jogadores irão gravitar para diferentes classes com base em suas habilidades e
personalidades. Para aqueles que querem dar um passo adiante, capacitar os jogadores a alterar
seu tipo de corpo, cor de pele e roupas pode ajudar muito a mergulhar na experiência. Assim
como as pessoas gostam de se vestir na vida real como forma de comunicar aos outros que tipo
de pessoa elas são, elas também gostam disso em um espaço online. Curiosamente, no entanto,
os jogadores irão gostar principalmente de ajustar as características de seu avatar que não
afetarão seu sucesso no jogo. Eles vão adorar escolher a cor dos olhos ou o penteado, mas será
preciso que os jogadores com um interesse fervoroso em role-playing interpretem um personagem
fraco com estatísticas enfraquecidas para combinar com suas deficiências físicas.
No Capítulo 7, “Os Elementos da Jogabilidade”, falei sobre a jogabilidade emergente e a
possibilidade de táticas de vários jogadores para levar ao sucesso. Embora esse tipo de escolha
significativa do jogador seja importante nas experiências de jogo para um jogador, no modo
multijogador elas são absolutamente essenciais. Em um jogo multijogador, os jogadores não
estão pensando “O que o designer quer que eu faça aqui?” mas em vez disso "Que tática posso
criar que me permita vencer contra esses outros jogadores igualmente inteligentes?" Se o design
do seu jogo não permitir um espaço flexível o suficiente para os jogadores desenvolverem táticas
únicas para combater os movimentos de outros jogadores, todos, exceto os novatos, perderão
rapidamente o interesse em seu jogo. Com os jogos para vários jogadores, você tem a vantagem
de não precisar criar maneiras de desafiar diretamente os jogadores, mas precisa fornecer a
paleta de ações em potencial que capacitarão os jogadores a desafiarem uns aos outros. Por
exemplo, o salto com foguete pode não ter sido planejado como parte do design de Quake ou de
seu antecessor de salto com foguete Marathon, mas a robustez da tecnologia e o design desses
jogos apoiaram a tática inovadora dos jogadores. Fundamentalmente, os designers de vários
jogadores têm muito menos controle ditatorial sobre as experiências dos jogadores do que os
designers de um jogador, e é de seu interesse reconhecer isso e trabalhar para capacitar os
jogadores em vez de constrangê-los.
Jogando com os pontos fortes
Muitas vezes, quando os designers passam de jogos single-player para multiplayer, a primeira
coisa em que pensam é substituir seus adversários de IA por humanos. Esta é uma escolha que
garante uma experiência mais desafiadora e dinâmica para o usuário. Mas, ao mesmo tempo,
não explora verdadeiramente todo o potencial dos jogos multijogador. Por
anos, os jogos single-player foram construídos em torno das limitações do que uma IA poderia e
não poderia fazer. Muitos jogos de ação, por exemplo, equilibraram sua jogabilidade lançando um
grande número de agentes de IA bastante burros nos jogadores. Quando esses mesmos jogos se
tornaram jogos online de combate mortal, os designers geralmente substituíam essas criaturas
idiotas de IA por jogadores humanos, mas, para equilibrar o jogo, diminuíram drasticamente seu
número e fizeram os jogadores lutarem por si mesmos. Enquanto antes havia duas facções (o
jogador e os inimigos), agora havia tantos adversários quanto jogadores. Essas escolhas simples
conseguiram reequilibrar bastante bem a experiência do jogo. Mas esses jogos de combate ainda
não estavam perto de explorar todo o potencial dos jogos para vários jogadores, porque esses
jogadores humanos poderiam facilmente ainda ser bots realmente inteligentes. No Capítulo 9,
“Inteligência Artificial”, falei sobre como uma inteligência artificial pode ser considerada para passar
no teste de Turing se os jogadores a confundirem com um humano. Para jogos multiplayer, o
objetivo deve ser um pouco diferente: os jogadores nunca poderiam confundir seus adversários
com nada além de outros humanos.
Para criar uma experiência de jogo distintamente multijogador, pode ser valioso seguir uma
dica da rica história de jogos multijogador não computadorizados, particularmente jogos que exigem
mais de dois jogadores. Por exemplo, muitos dos jogos de tabuleiro mais sofisticados envolvem
negociação entre jogadores por meio de trocas e trocas ou estabelecimento de alianças. Excelentes
exemplos de ambas as mecânicas podem ser encontrados em qualquer jogo semi-jogador
multijogador como Diplomacy, Cosmic Encounter e The Settlers of Catan. Em muitos jogos de
tabuleiro de três ou mais jogadores, decidir com quem os vários jogadores se juntarão a qualquer
momento é uma parte fundamental da experiência de jogo. Isso pode ajudar a corrigir quaisquer
problemas de balanceamento que o design do jogo possa ter, já que assim que um jogador ficar
significativamente à frente dos outros jogadores por sorte ou por uma façanha, os outros jogadores
rapidamente o atacarão. Nesses jogos, as personalidades dos jogadores inevitavelmente entram
em jogo, seja pegando leve com o jogador menos habilidoso que se aborrece facilmente ou uma
vingança oculta contra um cônjuge que não se manifesta, exceto durante as sessões de jogo.
Dungeons & Dragons e outros RPGs permitem que os jogadores joguem juntos em um grupo, com
o Dungeon Master criando uma experiência de jogo dinâmica para os outros jogadores de uma
forma que um computador nunca pode. Um jogo online com jogadores localizados a quilômetros
de distância uns dos outros e que provavelmente são estranhos no mundo real provavelmente
nunca recriará a experiência multijogador pessoal. No entanto, os jogos online mais bem-sucedidos
incluem componentes que forçam os jogadores a se socializarem como parte da mecânica do jogo
e, assim, tornam a interação social no jogo muito mais rica. Isso inclui jogadores experientes
coordenando suas táticas em jogos multijogador baseados em equipes, como Counter-Strike ou
Battlefield 1942, ou a recriação da experiência do Dungeon Master em Neverwinter Nights.
Embora o potencial de cooperação dos jogadores deva ser uma parte fundamental de quase
qualquer jogo multijogador, fazer com que os jogadores realmente o façam é outro problema. O
programador líder do Battlefield 1942 , Johan Persson, lamentou a pouca frequência com que a
maioria dos jogadores explora os recursos mais cooperativos do jogo, como um jogador explorando
e fornecendo coordenadas para outro jogador que dispara artilharia. Uma maneira de melhorar as
chances de cooperação dos jogadores é garantir que os jogadores que trabalham juntos tenham
uma vantagem significativa sobre aqueles que não trabalham. É lógico que, se houver uma opção
cooperativa complexa disponível que não forneça benefícios significativos sobre o que se pode
realizar sozinho, a maioria dos jogadores optará por fazer tudo sozinho. Um início
Battlefield 1942 exige que os

jogadores trabalhem juntos
para serem realmente bem-
sucedidos, criando uma
experiência única que não
pode ser replicada em um jogo
para um jogador.
exemplo disso vem de Joust, que tinha níveis de “sobrevivência” onde dois jogadores cooperativos
recebiam um grande bônus de pontuação apenas se ambos não perdessem uma vida durante esse nível.
Quando há uma vantagem significativa em cooperar em um jogo de equipe versus equipe, pode haver o
infeliz efeito colateral de que jogadores mais casuais serão esmagados pela oposição e, portanto, nunca
viverão o suficiente para aproveitar o jogo. Claro, para todos, exceto para os mais sádicos, esmagar
oponentes fracos só é divertido por tanto tempo, então a maioria dos jogadores cooperativos forma clãs
e lutam contra outros clãs em servidores que são rotulados e restritos de acordo.
Proteja os novatos
Os novatos são os jogadores mais vulneráveis, e é trabalho do designer de jogos fazer tudo o que puder
para mantê-los protegidos por tempo suficiente para que eles se familiarizem com as mecânicas e táticas
do jogo. Isso é essencial para o sucesso a longo prazo do seu jogo.
Ao contrário de um jogo para um jogador, onde o designer tem o controle final sobre a experiência de
aprendizado dos jogadores, em um jogo para vários jogadores, seus novos jogadores ficam imediatamente
à mercê dos jogadores mais experientes, que provavelmente não mostrarão aos novatos nenhum trégua.
Quando comecei a trabalhar na Surreal Software, a empresa estava perto de lançar o jogo Drakan
original. Eles estavam gastando muito tempo testando o código multijogador, e eu fui rapidamente sugado
para jogar jogos multijogador com a equipe de desenvolvimento.
Claro, eles jogavam o jogo por muitas horas por dia há pelo menos um ano e se concentravam no jogo
multijogador por vários meses. Como resultado, eles sabiam de trás para frente, enquanto eu não tinha
ideia do que estava acontecendo. O sistema de combate corpo-a-corpo do jogo era particularmente
implacável para novos jogadores, então eu fui espancado várias vezes sem nem mesmo perceber por
que estava sendo morto. Lembro-me de quebrar vários ratos em frustração. Se eu não estivesse sendo
pago para fazer esse teste, certamente teria desistido do jogo e nunca mais o jogaria.
Embora meu problema fosse extremo, essa é aproximadamente a experiência de muitos novatos
que não têm tempo para se preparar adequadamente para um encontro online de jogador contra jogador.
Para um exemplo mais desastroso de novatos sendo derrotados
antes que eles tenham a chance de realmente se familiarizar com o jogo, é preciso olhar
apenas até a história do mercado de simuladores de vôo de combate online. Estes são alguns
dos mais antigos jogos de combate online, e parecem ser ideais para jogos multi-jogador. Mas a comunidade
nunca cresceu além dos fãs de simuladores de vôo super-hardcore.
Uma razão para isso foi que os controles desses simuladores de voo eram tão desafiadores
aprender e a física tão difícil de entender que a maioria dos jogadores
problemas mesmo mantendo seus aviões no ar por muito tempo. Jogue em jogadores experientes
que não mostrou misericórdia em tirar esses novatos, e você tem um mercado que nunca
estendido além de um certo tamanho limitado. No final, os jogos eram simplesmente implacáveis demais para
os novos jogadores.
O Ultimato original
Online teve muitos hostis
usuários conhecidos como
"assassinos de jogadores" que fizeram o
jogo especialmente
desafiador para os mais novos
jogadoras.
Para piorar as coisas para os novatos, é uma regra geral no desenvolvimento de jogos online que uma
porcentagem fixa de jogadores, digamos um por cento, são idiotas completos (ou pelo menos
menos se tornam idiotas ao jogar jogos online) e adoram atacar novos jogadores que
não tem chance contra eles. Embora isso possa ser apenas um por cento do seu público,
infelizmente eles são tipicamente os jogadores mais tenazes e incansáveis. Muitos dos
os jogos de combate multijogador tentaram resolver parcialmente esse problema incluindo áreas de treinamento
para um jogador em seus jogos. Ultima Online, o primeiro comercialmente
jogo massivamente multi-jogador de sucesso, foi particularmente atormentado por matadores de jogadores
quando foi lançado. Isso apesar do fato de que o jogo, ao contrário dos jogos estilo death-match,
não foi projetado para enfatizar jogadores matando outros jogadores. Para muitos jogadores isso
resultou em uma barreira significativa para a entrada. Quase todos os MMPs subsequentes resolveram esse
problema de várias maneiras. Uma solução requer que os matadores de jogadores se registrem como tal e então
permite que eles ataquem apenas outros assassinos de jogadores. Outra técnica envolve a segregação de
novos jogadores em zonas seguras por um tempo antes de permitir que eles vão para locais mais hostis.
Localizações. De fato, até o Ultima Online acabou corrigindo o problema criando um espelho
do mundo que era seguro e, em seguida, permitir que os jogadores que procuravam um ambiente menos hostil
migrassem para ele.
Proteger os novatos é uma preocupação que os designers de jogos online sempre precisarão
lidar e para os quais provavelmente nunca haverá uma solução perfeita. Conforme mencionei
anteriormente, as áreas de treinamento offline podem ser extremamente úteis para os jogadores praticarem
sem a vergonha de serem esmagados por oponentes humanos repetidamente enquanto tentam se atualizar.
Em vez de sempre recompensar os jogadores por matar outros jogadores, Dani Bunten Berry sugeriu que
um sistema de orientação pode ser apropriado, onde os jogadores mais veteranos são recompensados
adequadamente por cuidar dos jogadores mais novos. De fato, Asheron's Call implementou exatamente
esse sistema por meio de alianças, que funcionou muito bem ao dar aos jogadores um grande incentivo
para ajudar uns aos outros, principalmente os novatos.
Manter os recursos no mínimo e os controles o mais simples possível também ajudará.
Quanto mais complexos e difíceis de entender os controles forem, mais tempo levará para alguém se
acostumar com eles e, então, mais à frente os jogadores experientes estarão dos novatos. Os simuladores
de vôo de combate aéreo são um exemplo perfeito de controles muito complexos, criando uma comunidade
de jogos apenas hard-core. Ter controles mais simples, mas combiná-los com uma ampla gama de ações e
táticas, ajuda a manter a barreira de entrada razoavelmente baixa, ao mesmo tempo em que fornece aos
jogadores experientes matérias-primas para experimentar. Finalmente, se o design do seu jogo suportar
algo mais complexo do que a jogabilidade “eu ganho, todos os outros perdem”, o jogo será muito mais
convidativo para novos jogadores.
Os jogos massivamente para vários jogadores tornaram-se particularmente bons nisso, permitindo que
todos os jogadores participem de todas as missões e apoiando os jogadores a serem bem-sucedidos de
várias maneiras igualmente satisfatórias. Muitos jogos de death-match mostram a classificação dos
jogadores no final da partida, em vez de apenas relatar o vencedor. Dessa forma, embora possa demorar
um pouco até que um novato chegue ao primeiro lugar, ele pode se ver saindo do décimo sexto lugar e
subindo para posições mais altas ao longo do tempo. Para os jogadores, há menos vergonha se chegarem
em quinto de oito do que se tudo o que sabem é que não conseguiram vencer.
Socialização
Uma das principais razões pelas quais os jogadores se envolvem em jogos multijogador é socializar com
outros jogadores. Isso é verdade tanto em jogos de computador quanto em jogos que não são de
computador. Qualquer um que tenha jogado jogos de tabuleiro com sua família pode atestar o fato de que
uma pessoa está sempre sugerindo que jogue um jogo enquanto outras vão junto apenas para ter algo
social para fazer, não porque sejam particularmente cativadas pela jogabilidade em si. De fato, quando
comecei a jogar Dungeons & Dragons , não estava muito interessado no jogo (na verdade, eu preferia ter
jogado Champions). Mas Dungeons & Dragons era o que meus amigos queriam jogar, e ao invés de ficar
em casa sem fazer nada, eu participei. Só passei a apreciar a jogabilidade depois de jogar com eles por
algum tempo. Da mesma forma, eu conheci pessoas na faculdade que ficaram tão envolvidas em um
determinado MUD que seus amigos começaram a jogar o MUD apenas para que pudessem socializar com
eles novamente. Certamente um grande número de pessoas que jogam massivamente jogos multi-jogador,
como o EverQuest hoje, o fazem principalmente para se socializar. Isso também explica por que esses
jogos atraíram uma base de fãs feminina maior do que, digamos, jogos de tiro em primeira pessoa: a
sabedoria comum é que as mulheres gostam mais de socializar do que os homens. No mínimo, as mulheres
estão procurando uma experiência social um pouco mais envolvente do que um jogo que gira em torno da
mecânica de matar ou morrer.
Com um jogo de tabuleiro ou um RPG que não seja de computador, a habilidade dos jogadores de se
socializar geralmente vem de graça. No entanto, um jogo como o xadrez é muito menos social do que um
jogo que exige que os jogadores cooperem ou se apunhalem pelas costas. Em um jogo de computador
multijogador com todos os jogadores jogando em uma tela, como Mario Kart ou um
jogo de morte em tela dividida como Halo, a socialização também vem em grande parte de graça,
embora se o jogo for muito frenético e intenso em seu ritmo, a capacidade dos jogadores de
socializar pode ser mais limitada.
Com uma experiência

multijogador em tela dividida,
como encontrada em Mario
Kart: Double Dash, você tem
quase garantida uma
experiência muito social para
os jogadores.
Para um jogo online, o designer precisará se esforçar para facilitar a socialização do jogador.
O primeiro passo é fornecer uma interface com a qual os jogadores podem conversar entre si.
Quase todos os jogos online fazem isso, embora alguns dos jogos anteriores de death-match e
“casuais” não o fizessem. Da mesma forma, alguns jogos online voltados para crianças foram
forçados a deixar de fora as opções de bate-papo por medo de adultos abusarem desse sistema
para obter o endereço de uma criança. Por exemplo, o MMP Toontown Online , voltado para
crianças, permitia a comunicação apenas por meio de uma linguagem baseada em símbolos.
Supondo que você não esteja legalmente impedido de adicionar bate-papo completo, você deseja
facilitar a conversa em todas as partes do jogo, não apenas durante o jogo ativo. Para jogos de
combate de curta duração, se houver um lobby onde os jogadores esperam o jogo começar assim
que todos os jogadores se juntarem, este é um lugar perfeito para conversar, pois os jogadores não
têm nada para fazer. Você também deve habilitar a conversa em qualquer tela pós-jogo onde as
classificações dos jogadores são exibidas; os jogadores vão querer poder conversar aqui para
discutir o que acabou de acontecer, seja para se gabar ou para parabenizar e jurar vingança no próximo jogo
É claro que conversar via teclado é significativamente inferior ao potencial expressivo da fala
humana real, com a vantagem óbvia de que os jogadores podem falar enquanto continuam a jogar.
De fato, o uso de “emoticons” e pontuação criativa pode fazer o melhor para imbuir o texto com a
profundidade emocional do discurso, mas só vai tão longe. A comunicação por voz entre seus
jogadores é gratuita se o seu jogo não estiver online e todos estiverem jogando em uma única tela.
Qualquer um que já tenha jogado um jogo de tiro em primeira pessoa em uma LAN com todos os
jogadores sentados próximos uns dos outros (como depois do expediente em um laboratório de
informática do campus) pode atestar o quanto pode ser divertido jogar contra jogadores próximos. ,
com jogadores gritando de surpresa quando são mortos inesperadamente, xingando uns aos outros
por tiros baratos, provocando uns aos outros que seu tempo de vida é limitado ou proclamando sua
vasta superioridade sobre seus oponentes. Este tipo de socialização provou ser tão popular que os
jogadores que estão em
partes separadas do mesmo edifício ou em escritórios separados são conhecidas por

teleconferência entre si para recriar um espaço onde possam socializar via voz. Isso também explica a
crescente popularidade do suporte de fone de ouvido para
jogos nos consoles; os jogadores realmente querem poder falar uns com os outros enquanto jogam.
A maior desvantagem de adicionar suporte de voz ao seu jogo é o impacto negativo que pode causar
tem na sensação de imersão que você obtém ao jogar o jogo. Apesar de sua simplicidade
Versão “Indiana Jones” da Segunda Guerra Mundial, jogar Battlefield 1942 muitas vezes pode ser um
experiência extremamente imersiva com sua combinação de aviões sobrevoando, explosões acontecendo
por toda parte e batalhas por pontos de controle que parecem realmente importantes
lutas em uma luta épica. Esta imersão pode ser interrompida se você ouvir um
de doze anos do outro lado do fone de ouvido gritando tolices completas ou obscenidades sem parar. No
final, porém, a maioria dos jogadores provavelmente encontrará a perda de
a imersão vale a pena pela capacidade aprimorada de se comunicar e jogar cooperativamente, bem
como pelo puro prazer de ouvir seus colegas jogadores gritando em seu caminho
através da batalha.
Às vezes, travando uma

guerra multijogador no Battlefield
1942 pode ser extremamente
imersivo.
Outra parte importante de facilitar a comunicação do jogador é dar tempo aos jogadores
onde eles se sintam seguros o suficiente para poderem falar sem serem mortos. Isto é particularmente
verdadeiro em jogos intensos no estilo death-match, onde mal há tempo suficiente para compor uma
frase de cinco palavras antes que uma granada caia em seu colo. Claro, incluindo voz
suporte ajudará nisso, mas qualquer um que tenha jogado um jogo de ação verdadeiramente intenso pode testemunhar
quão hipnotizante e frenético pode se tornar, muitas vezes ao ponto de falar e
jogar pode ser pedir demais. Daí a importância de acompanhar o jogo de forma que os jogadores tenham
oportunidades de conversar. Da mesma forma, quanto maior a proporção de glória para vergonha em seu
experiência, é menos provável que os jogadores estejam dispostos a falar, já que cada derrota é
tremendamente humilhante, principalmente quando o vencedor não para de se gabar disso.
Apenas adicionar a capacidade de os jogadores falarem via texto ou até mesmo suporte total de voz
e garantir que os jogadores tenham momentos livres para compor pelo menos frases parciais
não garante uma experiência de jogo social. Uma grande parte da razão pela qual os jogadores gostam
jogando jogos de tabuleiro não computadorizados ou RPGs é que eles estão jogando com amigos que
eles estão familiarizados e cuja companhia eles gostam. Jogar com pessoas aleatórias pela
Internet é muito menos agradável se você conhecer esses jogadores apenas durante um jogo
de morte e depois mudar para um conjunto totalmente novo de pessoas a cada nova partida.
Os jogadores nunca terão a chance de se conhecer. Portanto, ter uma experiência de jogo
que encoraje os jogadores a formar clãs ou guildas que precisam trabalhar juntos para ter
sucesso será essencial para criar uma experiência mais social para seus jogadores. Fomentar
relacionamentos entre jogadores que durem além do tempo em que estão jogando não só
beneficiará os próprios jogadores, mas também o sucesso a longo prazo do seu jogo. Aqueles
jogadores que se tornaram amigos jogando seu jogo provavelmente se reunirão para jogar
como um evento social no futuro, supondo que ainda gostem do jogo e que lhes permita
fortalecer sua amizade enquanto jogam. Esses jogadores também são mais propensos a
conversar entre si em fóruns dedicados ao seu jogo, o que pode ajudar a construir sua
comunidade e atrair outros jogadores para o seu jogo no futuro. A comunidade em torno de
um jogo online é ainda mais importante do que a comunidade de um jogo para um único
jogador, e permitir que os jogadores tenham uma rica experiência social em seu jogo pode
ajudar a construir essa comunidade melhor do que qualquer outra coisa que você possa fazer.
Cada recurso ou mecânica de jogo que você adiciona ao seu jogo multijogador deve ser
examinado para determinar como isso afeta a experiência social dos jogadores. Embora nem
todos os recursos precisem ser sociais (afinal, ainda é um jogo, e provavelmente um
competitivo), qualquer recurso que interrompa ativamente a capacidade dos jogadores de
socializar e trabalhar juntos precisa ser cuidadosamente considerado para garantir o impacto
que terá no jogo valerá o custo. De fato, ter recursos que não fazem nada para melhorar
diretamente a mecânica do jogo, mas ajudam os jogadores a socializar, muitas vezes acaba
melhorando a experiência geral dos jogadores com o seu jogo. Permitir que os jogadores se
comuniquem uns com os outros é um dos aspectos mais atraentes dos jogos multi-jogador e
é algo que um jogo single-player nunca será capaz de fornecer de forma significativa.
caminho.
Problemas de desenvolvimento
Além das considerações de design exclusivas que são levantadas pelos jogos multijogador,
também há vários problemas de desenvolvimento que as equipes precisam estar cientes. Em
primeiro lugar, as equipes de desenvolvimento precisam decidir que tipo de jogo estão
fazendo: multi-jogador ou single-player. Com um jogo somente online, como um RPG
massivamente multijogador, a resposta a essa pergunta é óbvia. Mas para um jogo de ação
que inclui um jogo baseado em progressão de nível para um jogador, adicionar um componente
multijogador pode ser abordado de várias maneiras. Muitos jogos sofreram quando optaram
por adicionar suporte para vários jogadores no meio do desenvolvimento. Esta é uma decisão
que pode parecer que não é grande coisa, mas no final pode exigir reescrever grandes partes
do código ou retrabalhar a própria mecânica do jogo para ser mais apropriada para jogos
multi-jogador. Se o jogo para um jogador estiver significativamente em andamento quando
essa mudança acontecer, isso pode resultar em refazer muito trabalho que estava
perfeitamente bem quando o jogo era apenas para um jogador. No Centipede 3D, fomos
encorajados a adicionar multi-player bem tarde no desenvolvimento, mas além da programação
necessária para fazê-lo funcionar, não tínhamos recursos de arte ou design para torná-lo
divertido. Como não era uma grande prioridade para nós, acabamos adicionando um modo cooperativ
ajustá-lo ou equilibrá-lo. Decidimos especificamente não comprometer a experiência de um

jogador, seja mudando a mecânica ou tirando nosso tempo de trabalhar nessa parte principal do
jogo. Curiosamente, o multi-jogador em Centipede 3D realmente funcionou e não foi um fracasso
completo do ponto de vista criativo; funcionou como uma diversão divertida por um curto período
de tempo. Mas não foi um grande aprimoramento para o título, já que o jogo nunca havia sido
planejado para ele e não tínhamos o tempo de design necessário para torná-lo uma experiência
realmente válida.
Alguns jogos que adicionaram vários jogadores no meio do desenvolvimento acabaram
com mecânicas significativamente diferentes nos jogos multijogador e single player. Isso é
lamentável, já que a ideia de ter um jogo com os dois modos é que os jogadores que são fãs da
experiência single-player podem facilmente mudar para o jogo multiplayer para continuar jogando
o jogo que já gostam. Se o jogo for extremamente diferente, eles podem ficar frustrados e
desistir. Claro, algumas diferenças certamente são boas, como pequenas variações em como o
inventário funciona ou quanto tempo dura um determinado power-up. Mas os jogadores devem
sentir que estão jogando basicamente o mesmo jogo.
Ao desenvolver o Halo, a
Bungie concentrou-se no
desenvolvimento do jogo
para vários jogadores primeiro,
antes de passar para os
níveis de um jogador.
Felizmente, adicionar jogos multijogador a um jogo individual existente não é mais aceitável
para críticos ou jogadores. No Capítulo 15, “Colocando a jogabilidade funcionando”, encorajo os
designers a manter o processo de desenvolvimento de jogos o mais orgânico possível pelo
maior tempo possível. Mas pelas razões acima, é muito importante decidir desde o início se o
seu jogo incluirá vários jogadores. Isso é importante não apenas para que seu código possa ser
arquitetado corretamente e sua mecânica de jogo possa ser projetada para funcionar para
ambos os tipos de jogos, mas também porque você pode usar o jogo para vários jogadores para
ajudá-lo muito no desenvolvimento. Supondo que seu código de rede esteja funcionando cedo o
suficiente, você pode realmente fazer com que sua equipe de desenvolvimento jogue o jogo
multijogador e comece a iterar sua mecânica de jogo cedo para torná-la o mais completa e
divertida possível. Supondo que você continue progredindo e o jogo multijogador seja divertido,
isso pode ser ótimo para o moral da equipe e ajudar as pessoas a ver como o jogo em que estão
trabalhando está se encaixando. E uma vez que sua mecânica é uma quantidade conhecida, construir um div
experiência single-player será muito mais simples. Além disso, pessoalmente, sinto que desenvolver
um jogo divertido para vários jogadores é um desafio muito maior do que construir um jogo para
um jogador, já que você, como designer, tem muito menos controle sobre a experiência. Assim,
desenvolver uma experiência multi-jogador divertida fundamentalmente leva mais tempo do que
uma experiência single-player igualmente divertida. De certa forma, projetar um bom jogo
multijogador é perceber o que os jogadores tentarão fazer depois de jogar seu jogo por um tempo
e como você pode suportar melhor isso com uma mecânica de jogo profunda. Quanto mais tempo
você tiver jogadores jogando seu jogo, mais você poderá equilibrar a experiência de jogo. Assim,
concentrar-se em sua experiência multijogador desde o início lhe dará uma melhor chance de
desenvolver um jogo sólido no final do dia. Tanto o Ensemble com a série Age of the Empires
quanto a Bungie com Halo são conhecidos por se concentrarem deliberadamente em obter sua
experiência multijogador desde o início, antes de trabalhar na experiência de um jogador. Assim,
ambos conseguiram entregar títulos que têm experiências multi-jogador muito bem equilibradas,
ao mesmo tempo em que incluem jogos single-player inigualáveis.
Teste de jogo e feedback do usuário

À medida que você desenvolve seu jogo multijogador e observa as pessoas jogando, você
descobrirá rapidamente que nunca pode antecipar o que os jogadores tentarão fazer. Antecipar o
que os jogadores em um jogo solo farão é bastante difícil; fazer a mesma coisa para um jogo multi-
jogador é quase impossível. Por exemplo, em Centipede 3D vimos a experiência multi-jogador
como estritamente colaborativa, onde os jogadores poderiam jogar os vários níveis juntos. Assim,
os dois jogadores que o jogo permitia eram imunes ao fogo das armas um do outro. Mas assim
que colocamos o código multijogador funcionando e começamos a jogar, a primeira coisa que os
jogadores tentaram fazer foi jogar uns aos outros na água, já que a água é mortal para os navios
“atiradores” dos jogadores. Devido à física leve, mas robusta do jogo, empurrar o outro jogador foi
uma experiência agradável que se tornou ainda mais divertida quando levou à morte do outro
jogador. Eu certamente nunca imaginei esse resultado, mas não é surpreendente, dada a tendência
dos jogadores de pegar uma experiência cooperativa e torná-la adversária o mais rápido possível.
Outro comportamento emergente interessante que os jogadores descobriram rapidamente foi a
capacidade de um jogador pular em cima do outro e montá-lo, girando em qualquer direção que
ele quisesse e agindo como uma torre. Como mencionei, no Centipede 3D não havia literalmente
tempo dedicado a projetar a experiência de jogo multijogador, então não havia nada que
pudéssemos fazer para corrigir, ajustar ou até mesmo encorajar esses comportamentos
interessantes, já que os descobrimos apenas uma semana antes da programação. enviar.
Ainda mais do que em jogos single-player, é essencial testar seu jogo multiplayer pelo maior
tempo possível antes de ser lançado ao público em geral. No entanto, esse teste só pode dizer
muito. Por esse motivo, quase todos os jogos massivamente para vários jogadores incluíram um
“beta aberto” como parte de seu desenvolvimento. Durante esse período, os desenvolvedores
pegam um número grande, embora ainda limitado, do público em geral e os deixam jogar o jogo
ainda não concluído de graça. O número de pessoas atraídas durante esse teste é muito maior do
que o número de jogadores que podem jogar como parte de um esforço de teste interno e, portanto,
fornece uma simulação muito mais próxima de como será o jogo quando finalmente for lançado
Para o mundo. Os jogadores que se inscrevem para esses betas abertos normalmente são
jogadores particularmente dedicados e travessos e, como resultado, levarão os sistemas do seu
jogo ao limite. Obviamente, isso é uma coisa boa.
No entanto, o outro lado disso é que, como eles são jogadores tão dedicados que gostam de jogos
que estão dispostos a jogar um produto com erros e inacabados, esses testadores não representam
necessariamente as opiniões de jogadores mais casuais. Portanto, o feedback que você recebe
deles não necessariamente corresponderá ao que você verá quando o jogo finalmente for lançado.
Além disso, às vezes esses testadores podem ser tentados a não relatar todos os bugs que
descobrem se puderem explorá-los para seu próprio benefício; eles podem esperar continuar a
colher os frutos desses descuidos no jogo final. Há pouco que pode ser feito para remediar isso,
mas é importante que os designers reconheçam isso e saibam que certamente há mais trabalho
de equilíbrio a ser feito quando o jogo for lançado.
Mesmo com um beta aberto, quando seu jogo for lançado para as massas, surgirão problemas
que você não previu. Isso é verdade para jogos multi-jogador de menor escala (como jogos de
death-match) e esses problemas geralmente são resolvidos em patches que são lançados logo
após o lançamento do jogo. Patches são tão comuns que os jogadores passaram a esperá-los. Se
você não tentar rastrear ativamente quais problemas as pessoas estão tendo, tanto com o código
de rede quanto com a mecânica do jogo, e não conseguir ajustar o jogo para corrigir pelo menos
os problemas mais gritantes (e haverá problemas gritantes), jogue Os usuários abandonarão
rapidamente seu jogo em favor de outro jogo cujos desenvolvedores cuidem melhor de seus
usuários finais.
No mundo dos jogos persistentes massivamente para vários jogadores, o dever de manter o
jogo após o lançamento é ainda mais importante. Com esses jogos, os jogadores normalmente
pagam uma taxa de assinatura mensal e, além de ajustes nas mecânicas e balanceamento do
jogador, esperam um fluxo constante de novos conteúdos para mantê-los desafiados e um certo
nível de atendimento ao cliente para resolver seus problemas. De fato, a maioria dos
desenvolvedores desses jogos considera o lançamento como apenas metade do trabalho, com o
jogo precisando de cuidados e ajustes constantes no dia-a-dia, assim como uma trupe de teatro
que acaba de lançar uma nova peça refinará e reescrevê-lo com base em como ele vai com o
público de cada noite. Richard Garriott foi tão longe a ponto de encorajar os desenvolvedores de
MMPs a enviar “recursos finos” e então adicionar recursos ao jogo que os jogadores demonstraram
interesse ou mesmo exigiram.
Ajustar o jogo de forma significativa após o envio pode ser um processo delicado. Em primeiro
lugar, antes de começar a fazer qualquer ajuste, você precisa fazer o possível para entender o
estado atual do seu jogo e o que os jogadores estão gostando e o que não estão. É fácil adivinhar
o que você deve corrigir apenas para quebrar um recurso que os jogadores adoram. Uma maneira
óbvia de rastrear o que os jogadores gostam em seu jogo é ouvir seus comentários diretos, mas
isso pode ser problemático por alguns motivos. Em primeiro lugar, os jogadores que fornecem
feedback podem não ser representativos da pessoa média que joga o seu jogo e podem fazer
parte de uma minoria franca. Um ditado diz: “Os felizes estão jogando o jogo, os infelizes estão no
tabuleiro”. Além disso, os jogadores não são designers de jogos e, como tal, não entendem as
ramificações de alguns dos recursos que estão exigindo. De fato, os designers geralmente são
muito mais bem atendidos observando a raiz do problema que está fazendo com que os jogadores
sugiram um recurso. No final, o designer pode estar em melhor situação com sua própria solução
para esse problema. Art Min, líder de projeto do jogo de estratégia tática online FireTeam, afirmou
que o projeto descarrilou quando eles passaram muito tempo ouvindo os participantes de seu teste
beta aberto. Min apontou que os membros de um teste beta aberto são mais frequentemente
jogadores mais jovens com enormes quantidades de tempo em suas mãos. Desenvolvedores, que
possuem
trabalho a fazer, não têm tempo para lidar com todas as suas sugestões ou demandas e, se
dedicarem muito tempo para aplacar todos, correm o risco de perder o controle de sua própria
visão de design. Por esse motivo, muitos jogos online contratam gerentes de comunidade cujo
único trabalho é ouvir e se comunicar com os jogadores e sintetizar seus comentários em
informações úteis que a equipe de desenvolvimento pode usar para refinar o jogo.
Após o lançamento do The

Sims Online , a equipe da
Maxis usou as métricas do
jogador para descobrir
explorações do jogador.
O fato é que, embora inestimável, o feedback oferecido pelos jogadores, seja em um teste
beta ou após o lançamento do jogo, é problemático na melhor das hipóteses. Uma técnica mais
confiável é observar as métricas do jogador, embora esses dados possam ser bastante difíceis de
entender. Às vezes chamado de mineração de dados, analisar as métricas do jogador é o processo
de rastrear o que os jogadores estão realmente fazendo no jogo e usar esses dados para ajustar a
experiência de jogo. Portanto, se você descobrir que 90% dos seus jogadores estão usando um
tipo específico de objeto, isso pode sugerir que você faça mais objetos desse tipo. Da mesma
forma, se os jogadores nunca estiverem usando um determinado recurso que você colocou, pode
valer a pena tentar determinar por que os jogadores nunca o estão usando e, em seguida, resolver
seus problemas. Se o recurso simplesmente for algo que eles não precisam, pode ser sábio cortar
esse recurso em vez de mantê-lo. Além disso, você pode aprender com esse erro evitando recursos
indesejados semelhantes no futuro. O valor das métricas do jogador é que os dados não podem
mentir ou exagerar e é uma representação justa do que todos os jogadores estão fazendo, não
apenas aqueles que dedicam tempo para conversar com os desenvolvedores. Assim como as
pesquisas em geral podem ser influenciadas pelo desejo das pessoas de parecerem boas de
várias maneiras, também o feedback dos jogadores sobre sua experiência de jogo. No The Sims
Online, os desenvolvedores usaram métricas do jogador para descobrir exploits de jogadores, pois
logo depois que um jogador encontrou um exploit, logo o mundo inteiro saberia e todos estariam
usando um objeto em particular para seu próprio benefício. Analisar as métricas do jogador é
essencial para avaliar o verdadeiro estado do mundo antes de fazer quaisquer alterações e ajustes no seu j
Um mundo próprio
O futuro dos jogos multijogador parece realmente brilhante. Os fãs hardcore do gênero estão tão
fascinados com ele que muitas vezes não têm interesse em jogos single-player. De fato, os MUDs
e os jogos comerciais massivamente multi-jogador que eles inspiraram atraíram um grupo inteiro de
fãs que nunca se interessaram por experiências single-player.
Não se pode contestar que os jogos para vários jogadores, por meio da inclusão de vários
jogadores inteligentes, contêm uma combinação de emergência, novidade e imprevisibilidade que
os jogos para um jogador nunca alcançarão, independentemente do quanto a inteligência artificial
melhore. Ao mesmo tempo, os designers de vários jogadores têm muito menos controle sobre esse
espaço de jogo e, portanto, os jogos podem ser bastante difíceis de entrar, especialmente quando
um jogador se encontra atrasado em meio a um mar de veteranos. O equilíbrio glória/vergonha em
um jogo multijogador pode ser intensamente satisfatório para os vencedores, mas igualmente
deprimente para os perdedores. Além disso, uma vez que outros jogadores estão envolvidos em
um jogo, o nível de imersão que os jogadores podem experimentar é severamente diminuído. Assim
que um jogador no mundo do jogo discute o que viu na TV na noite passada, a suspensão de
descrença dos outros jogadores é quebrada e eles são lembrados de que não estão realmente
correndo por uma floresta encantada ou um campo de batalha da Segunda Guerra Mundial. Isso é
quase impossível de evitar, mas no final, embora os desenvolvedores possam perder o sono se
preocupando com a suspensão da descrença sendo quebrada, os jogadores dos jogos estão felizes
em conversar uns com os outros. Os jogadores de jogos multijogador procuram principalmente uma
experiência social divertida, não uma jornada imersiva que consome tudo com uma narrativa rica.
Isso significa que, apesar de todas as vantagens e potencial inexplorado dos jogos para vários
jogadores, os jogos para um jogador provavelmente continuarão a ser mais populares nos próximos
anos, porque podem fornecer uma experiência altamente personalizada que os jogadores podem
iniciar e parar quando quiserem. Qualquer um que tenha jogado um jogo multi-jogador por tempo
suficiente pode lhe dizer que o inferno realmente são as outras pessoas. Mas para os fãs fervorosos
de jogos multijogador, as desvantagens valem mais do que as experiências únicas que apenas os jogos sociais p
Capítulo 14
Entrevista:
Chris Crawford
Hoje, Chris Crawford é provavelmente mais conhecido por suas contribuições para o
diálogo do design de jogos, incluindo a fundação da Computer Game Devel opers
Conference, a publicação do Journal of Computer Game Design e a
escrevendo o livro The Art of Computer Game Design. Em particular, A Arte de
Computer Game Design, embora escrito em 1983, continua sendo o melhor trabalho de todos os tempos
publicado sobre o assunto, e serviu de inspiração para este livro. O brilho dos jogos de
Crawford também não pode ser negado, incluindo clássicos indiscutíveis como Eastern
Front (1941), Balance of Power e Crawford's
favorito pessoal, Trust & Betrayal: The Legacy of Siboot. Na maior parte dos anos 90
Crawford dedicou-se ao seu trabalho de amor, o sistema interativo de contar histórias
chamado Erasmatron, uma ferramenta que se mostra muito promissora para transformar
histórias interativas de assuntos principalmente pré-escritos em experiências
verdadeiramente dinâmicas. Mais recentemente, ele continuou a contribuir para o diálogo de
design, tendo escrito dois novos livros, Understanding Interactivity/ The Art
de Design Interativo e Chris Crawford em Design de Jogos.
257
258 Capítulo 14: Entrevista: Chris Crawford
O que inicialmente o atraiu para fazer um computador jogar um jogo?

Na verdade, isso começou em 1966, quando eu estava no segundo ano do ensino médio, e um amigo
meu chamado David Zeuch me apresentou os jogos de guerra de tabuleiro Avalon Hill. Nós tocamos
esses, e eu pensei que eles eram muito divertidos. Joguei-os na faculdade, embora não tivesse muito
tempo livre durante meus anos de faculdade. Quando eu estava na pós-graduação, encontrei um
colega que trabalhava no centro de computação e ele estava tentando fazer Blitzkrieg, um jogo de
Avalon Hill, rodar no computador. Eu disse a ele que ele era louco. Eu disse: “Isso não pode ser feito,
esqueça”. Mas essa conversa plantou uma semente. Eu pensei sobre isso, e cerca de um ano depois
decidi que ia tentar. Então eu fui trabalhar e acabou não sendo tão difícil quanto eu temia. Então acabei
montando um pequeno programa em um IBM 1130 em FORTRAN. Na verdade, ele rodava um jogo de
computador, uma pequena simulação blindada tática. A estreia desse jogo veio no início de 1976,
quando o mostrei em uma pequena convenção de jogos de guerra que realizamos. Todo mundo jogou
e achou muito divertido. Então eu comprei um KIM-1 e refiz tudo em torno desse sistema.
Esse design foi inigualável por muitos anos, porque você tinha um movimento oculto genuíno. Eu
construí pequenos terminais minúsculos, como eu os chamava, e cada jogador tinha seu próprio mapa
e pedacinhos, e uma tela para dividir os dois jogadores. Dois caras jogaram este jogo de guerra, cada
um sem saber a posição do outro. Foi muito divertido, e isso foi em 1977 ou 78.
O que te fez pensar que seria impossível?

As dificuldades de organizar a inteligência artificial para isso. Eu pensei: “Isso vai ser impossível”. E o
movimento da grade hexagonal, imaginei que provavelmente fosse computável, e na verdade não é
tão difícil. Mas imaginei que fazer planejamento tático blindado no computador, na época, parecia
ridículo. Agora, você tem que lembrar que foi há vinte e cinco anos, e dado o estado da IA naquela
época, eu estava realmente em terreno bastante sólido pensando que isso era impossível. Mas
acontece que resolvi esse problema, marginalmente, em um ano.
O que te fez pensar que valeria a pena colocar jogos no computador?

Eu era movido por uma coisa e isso era jogar “às cegas”. Eu estava muito preocupado que, não
importa como você olhasse para isso, com jogos de tabuleiro você sempre pudesse ver o que o outro
cara estava fazendo. E isso sempre me incomodou muito, porque era terrivelmente irreal. Simplesmente
não parecia certo, e eu pensei que os jogos seriam muito mais interessantes às cegas. E, de fato,
quando os fizemos, eram jogos imensamente poderosos, muito mais interessantes do que os jogos
convencionais. E assim que eu vi isso, eu sabia que esse era o caminho a seguir. E a tecnologia de
jogo de tabuleiro nunca foi capaz de igualar esse aspecto simples. Foi muito divertido se esgueirar
atrás de seu oponente e, como dizem, enviar 20 quilos pelo cano de escape dele. Foi algo realmente
impressionante, tempos muito inebriantes.
Então, a partir desse trabalho inicial, como você veio trabalhar na Atari?
Bem, na verdade um pouco mais transpirou primeiro. Eu tenho um Commodore Pet e programei isso
em BASIC com algumas rotinas de linguagem assembly para lidar com o material da grade hexadecimal.
Eu havia mostrado meu jogo tático blindado em algumas convenções de jogos de guerra e todos
ficaram muito impressionados. Então eu realmente transformei Tanktics em um produto comercial e o vendi
Capítulo 14: Entrevista: Chris Crawford 259
no Commodore Pet por quinze dólares. E então fiz outro jogo chamado Legion naire, também no
Commodore Pet. E com base nisso, consegui um emprego na Atari, fazendo design de jogos lá.
Na verdade, eu era um dos poucos candidatos a emprego que eles já tiveram que tinha alguma
experiência em projetar jogos de computador. É difícil apreciar o quão pequeno tudo era. A própria
noção de um jogo de computador era, em si, muito esotérica.
Como era a atmosfera na Atari naquela época?

Foi inebriante. Mais uma vez, é muito difícil para as pessoas hoje em dia apreciar como as coisas
eram diferentes há apenas vinte anos. Lembro-me de uma conversa com Dennis Koble. Nós nos
encontramos uma manhã no estacionamento quando estávamos entrando no trabalho e estávamos
conversando no caminho. E eu me lembro de dizer: “Você sabe, algum dia o design de jogos será
uma profissão desenvolvida”. E ele disse: “Sim, talvez um dia seremos como estrelas do rock!”
E nós dois rimos de como esse pensamento era absurdo. Havia, no mundo, uma dúzia de
designers de jogos, a maioria deles na Atari. E todos se conheciam, pelo menos todos na Atari, e
era tudo muito aconchegante. E muitos deles não se consideravam designers de jogos.
Por exemplo, lembro-me de uma reunião em que o gerente do departamento disse: “Tudo
bem, pessoal, precisamos imprimir novos cartões de visita para todos e precisamos selecionar o
tipo de título que você deseja”. E houve uma espécie de debate entre a equipe se eles queriam ser
listados como “Game Designer” ou “Programmer”. Lembro-me de pessoas dizendo: “Nossa, você
sabe, se colocarmos nossos títulos como Game Designer, talvez não consigamos outro emprego”.
E acho que acabamos indo com “Game Programmer”.
Mas o design do jogo não estava nem perto do que é hoje, era apenas uma coisa muito obscura.
Lembro-me de dizer às pessoas quando elas me perguntavam: “O que você faz?” E eu dizia: “Eu
desenho jogos para Atari”. E eles diziam: “Uau. Isso é muito estranho. Como você faz isso?" Era
uma resposta muito exótica naquela época.
Você foi capaz de fazer o que queria em termos de design de jogos?

Dependia do que você estava fazendo. Se você estava fazendo um jogo VCS [Atari 2600], então
você conversava sobre seus jogos com seu supervisor, mas havia uma liberdade considerável.
A sensação era: “Precisamos de muitos jogos de qualquer maneira, e realmente precisamos de
criatividade aqui, então apenas siga seu nariz, veja o que funciona, veja se você consegue criar
algo interessante”. E, em geral, o supervisor lhe dava muita liberdade, a menos que você estivesse
copiando diretamente o design de outra pessoa. Então nessa área nós tínhamos muita liberdade.
Mas uma vez que você tenha seu design completo, haveria uma revisão de design onde todos os
outros designers examinariam e fariam seus comentários. Isso não foi uma coisa de marketing, foi
uma revisão de nível de design.
Todo mundo queria programar o computador [o Atari 800] porque era muito mais poderoso
que o VCS. Então, na época em que comecei, em 1979, a política era que você tinha que provar a
si mesmo fazendo um jogo no VCS primeiro. E só então você poderia ir para o computador. Bem,
eu murmurei e resmunguei; Não gostei nada dessa ideia. Mas aprendi o VCS e fiz um jogo nele.
No entanto, outra política que eles tinham era que todos os jogos tinham que ser feitos em 2K de
ROM. Eles estavam apenas lançando as ROMs 4K, mas na época elas eram bastante caras. E
então a sensação foi: “Você não pode fazer uma ROM 4K. Você tem que provar a si mesmo,
provar que você é um designer digno se vamos
para lhe dar todo esse espaço. Temos que saber que você pode usá-lo bem.” Então eu tive que fazer um 2K
jogos.
E fiz um chamado Wizard, que acho bastante inteligente e funcionou em 2K.
Embora eu tenha feito isso em tempo recorde, terminei quando a Atari estava começando a lançar seus
jogos em 4K. Todo mundo começou a perceber que os jogos em 4K não eram apenas um pouco melhores,
mas imensamente superiores aos jogos em 2K. Portanto, havia a sensação de que qualquer coisa que fosse
comercializada seria comparada com os jogos 4K, e meu design como um jogo 2K simplesmente não podia
se comparar com um jogo 4K. Então os outros designers acabaram dizendo: “Este é um design muito bom,
para 2K, mas simplesmente não funciona”. Eles queriam redesenhado para 4K. Eu poderia ter redesenhado
para 4K e publicado, mas meu sentimento foi: “OK, veja.
Fiz meu jogo no VCS, agora gostaria de passar para o computador. Então não vamos brincar aqui.” Então
argumentei: “Olha, isso foi projetado como um jogo 2K, não vamos simplesmente adicionar recursos a ele.
Se você quer um jogo em 4K, começamos de novo; essa é a única maneira de fazer isso direito.” E murmúrio,
eu consegui passar por ele e ter permissão para ir direto para o Atari 800. Então esse jogo nunca foi
publicado. E não me arrependi.
Então seu maior sucesso comercial na Atari foi Eastern Front (1941). Mas entendo que você teve
problemas para convencer as pessoas de que um jogo de guerra seria bem-sucedido. Você estava
confiante de que muitas pessoas iriam gostar?
Não, não, eu realmente não me importava. Meu sentimento era que este é o jogo que eu queria projetar,
então fiz isso no meu tempo livre. Isso era noites e fins de semana. Enquanto isso, eu estava fazendo muitas
outras coisas no trabalho. Em outubro ou novembro de 1980, fui promovido do design de jogos. Eu fui
basicamente o primeiro evangelista de hardware. Fiz para o Atari o que Guy Kawasaki fez para o Macintosh.
E, na verdade, eu fui bem sucedido nisso. Fiz um trabalho muito bom em atrair pessoas para trabalhar no
Atari, porque era muito melhor que o Apple e tudo o que precisava era de um bom vendedor técnico. Então
eu viajei pelo país dando esses seminários, distribuindo brindes e assim por diante. E eu gerei muito
entusiasmo entre a comunidade de programadores, e o Atari realmente decolou. Houve essa explosão de
software cerca de um ano depois que comecei essa tarefa. Eu tomo o crédito principal por isso.
De qualquer forma, comecei essa tarefa em outubro ou novembro de 1980 e, como parte disso, estava
lançando essas demos de software para mostrar os vários recursos do Atari. E eu disse a mim mesmo:
“Finalmente vou dedicar um tempo para me ensinar esse recurso de rolagem que todo mundo sabe que
está lá, mas ninguém chegou a usar”. Então eu sentei e comecei a brincar com isso, e dentro de algumas
semanas eu tinha uma demo muito boa funcionando. Eu construí um grande mapa de rolagem e pensei:
“Cara, isso é muito legal”. E pelos padrões da época isso era revolucionário. Foi muito além de qualquer
outra coisa, simplesmente alucinante. E eu me lembro de levar isso para a SSI que, na época, era a principal
empresa de jogos de guerra trabalhando na Apple. E eu mostrei para o sujeito lá, e ele não estava muito
entusiasmado. Ele disse: “Uau-de-do, isso nunca será um bom jogo de guerra”. Acho que foi algum tipo de
preconceito contra a Atari, que “Atari não é um computador de verdade”. Eu estava meio desconexo e
pensei: “Caramba, que atitude tacanha”. Então eu decidi: “Vou fazer isso sozinho”. Fiz este jogo da maneira
clássica que muitos jogos são feitos hoje em dia: comecei com um recurso técnico bonitinho e disse: “Como
posso mostrar esse truque gráfico maravilhoso?” Então eu disse: “Vamos construir um jogo em torno da
rolagem”. Fui trabalhar e construí a Frente Oriental. Eu o tinha funcionando em junho de 81, mas a
jogabilidade era horrível. Levei cerca de dois meses para terminar o jogo.
Nós o lançamos através do APX [Atari Program Exchange] em agosto de 1981 e foi um grande
sucesso. Foi geralmente considerado o segundo jogo definitivo da Atari, sendo o primeiro Star
Raiders , é claro.
Então você realmente fez os efeitos gráficos sofisticados primeiro e depois construiu o jogo
em torno disso?
Essa é uma fase que todo designer tem que passar. Você começa projetando em torno de truques
técnicos fofos e, à medida que amadurece como designer, deixa isso para trás.
Então você acabou liberando o código fonte de Eastern Front (1941). O que o motivou a
fazer isso?
Foi um ato extremamente não convencional. Meu sentimento era que este é um campo de
movimento rápido. Eu sou bom. Terei novas e maravilhosas descobertas tecnológicas quando
outras pessoas começarem a usar isso. Eu vou estar em outra coisa. Não senti nenhum sentimento
de possessividade: “Isto é meu, não quero que mais ninguém saiba”. Meu sentimento era e continua
sendo que todos nós lucramos mais com o avanço geral da indústria. Mas não sou um anarquista
de propriedade intelectual. Eu acredito que as pessoas têm o direito de reivindicar certas coisas
como suas. Eu apenas sinto que isso deve ser feito com muita moderação e apenas em situações
em que há algo muito grande que deu muito trabalho. Eu senti que isso era apenas um pequeno
truque técnico, não é grande coisa. Então eu dei.
É engraçado. Havia uma série de tecnologias que eu dei de presente que ninguém realmente
usou. O de rolagem foi um bom exemplo: houve algumas tentativas de usá-lo, mas todas foram
tímidas. Então, outra coisa, eu nunca consegui que ninguém aprendesse um maravilhoso truque
gráfico que me foi mostrado por Ed Logg, e eu meio que peguei e corri com ele. Fiz várias extensões
que levaram muito além do que ele me mostrou. Mas foi uma coisa maravilhosa para fazer
dissolvidas, uma variedade de transições, e foi lindo. Código muito inteligente. Você aplicou isso a
um bitmap e, uau, você poderia fazer coisas fantásticas acontecerem. E eu usei isso várias vezes
e ninguém mais parecia se incomodar em usá-lo. Mas acho que muitas pessoas olharam para o
código-fonte da Frente Oriental como uma forma de perceber que os jogos não são tão difíceis de
escrever.
Então, seu trabalho de evangelismo diminuiu a quantidade de tempo que você passou
desenvolvendo jogos?
Bem, eu fui evangelista de software por apenas um ano. Fui então convidado por Alan Kay para
participar de sua equipe de pesquisa. Na verdade, eu fui o primeiro cara que ele convidou. Por
cerca de três meses, a Divisão de Pesquisa da Atari consistiu em Alan Kay, eu, a assistente
administrativa de Alan, Wanda Royce, e meu funcionário, Larry Summers. E o único lugar que eles
poderiam nos colocar naquela época era nas suítes executivas, havia um quarto vago lá. E lá
estávamos Larry e eu fazendo programação nas suítes executivas. Ray Kassar, o presidente da
Atari, era um cara muito fechado e direto. E ele realmente se ressentiu de estarmos lá em cima.
Quero dizer, isso realmente o incomodou. Então nós temos um novo prédio bem rápido.
Estou curioso sobre outro jogo que você fez durante seus dias de Atari, Gossip. Esse jogo
já foi lançado?
Sim, foi lançado, mas foi lançado quando o Atari estava pegando fogo, então ninguém teve a
oportunidade de vê-lo. A fofoca era um jogo imensamente importante em que eu abordava as
relações interpessoais. Eu percebi muito cedo que os jogos de computador tinham uma
esterilidade emocional sobre eles, e passei muito tempo pensando nisso. Finalmente decidi que
o fator crucial era a ausência de personagens, de pessoas. E lembro-me de escrever um ensaio,
naquela época, intitulado “Pessoas, não coisas”, argumentando que os jogos de computador
eram muito orientados para as coisas e que precisávamos concentrar nossas energias nas
pessoas. Então, tentei projetar algo em torno das pessoas e da interação interpessoal. E Gossip
é o que eu inventei. Um design muito simples, mas muito à frente de seu tempo em termos de
seus objetivos.
Então, como era a jogabilidade?

Era apenas sobre o que eu chamo de relações circunferenciais afetando relações radiais.
Basicamente, a ideia era que você tivesse um grupo de oito pessoas e seu objetivo era ser
popular. Isso foi pouco antes do baile do ensino médio, e você queria ser eleito rei ou rainha do
baile, então você estava fazendo sua política. E a maneira como você fez isso foi chamando as
pessoas. Tinha uma interface muito fofa. Havia oito pessoas sentadas em duas fileiras de quatro;
pareciam palestrantes de um game show. Você era o único no canto superior esquerdo. E você
usaria o joystick para selecionar um dos outros sete jogadores, e então apertaria o botão e o
telefone tocaria na estação daquela pessoa. Ele pegaria o telefone. Então você usaria o joystick
para apontar para outra pessoa. E então, depois de selecionar essa outra pessoa, você empurra
o joystick para cima ou para baixo para mostrar uma expressão facial que varia de um grande
sorriso e acenar com a cabeça para cima e para baixo até uma grande carranca e balançar a
cabeça de lado a lado. Essas eram expressões de quanto você gostava ou não gostava dessa
pessoa. Então, você apontava para alguém e dizia: “Eu gosto tanto dele”, e então seu interlocutor
diria: “Bem, eu gosto tanto dele”. Então seu interlocutor lhe diria coisas sobre o que outras
pessoas estavam dizendo: “Essa pessoa gosta tanto dele, e essa pessoa gosta tanto dele”. E a
ideia era, você tentaria ler o agrupamento social e decidir qual grupo você iria se juntar para
agradar a todos os outros. Até certo ponto, isso envolvia uma certa dose de engano. Você diria a
todos: “Ah, eu gosto muito de você” e você diria: “Ah, se você o odeia, então eu também o odeio”.
Mas você pode ser pego nisso, e isso realmente machucaria; você teve que ser muito cuidadoso
em tudo isso. Foi um joguinho muito interessante.
Como era a mentalidade na Atari durante o crash do videogame?

Havia uma sensação de catástrofe. Acontece que era apenas uma questão de impulso.
Ou seja, tudo o que realmente aconteceu foi que a Atari faliu. A Atari fez muitas coisas realmente
erradas, e foi isso que levou à falência. É que ao falir, desacreditou toda uma indústria, e tantas
empresas que não tinham feito nada de errado e estavam perfeitamente saudáveis, faliram
também. Era apenas uma questão de uma indústria entrar em colapso porque sua empresa líder
estava muito desacreditada. Foi meio bobo de várias maneiras.
Todos se convenceram de que a falência estava sobre nós e todos decidiram: “Oh, todos
nós vamos morrer, então vamos morrer”. As forças subjacentes não haviam mudado muito.
Então as coisas foram capazes
de pegar. Infelizmente, a
recuperação surpreendeu a todos
pela forma. O colapso inicial
desacreditou os videogames, mas
não tanto os jogos de computador.
Infelizmente, na época, a maioria
dos jogos de computador eram
apenas cópias de videogames.
Assim, muitas empresas de jogos
de computador que derivavam
todas as suas vendas de
videogames entraram em colapso. Equilíbrio de poder
Foi muito ruim por um tempo lá.
Não consegui emprego, não consegui nada. Havia duas coisas novas para mim: Balance of
Power e o Macintosh. Eu tive algumas discussões sérias com o pessoal do Amiga sobre se
eu queria fazer evangelismo de software para eles. E realmente isso se resumia a uma escolha entr
Com qual plataforma vou rodar - o Mac ou o Amiga? Eu pensei muito nisso, porque percebi
que você atrela sua estrela a uma plataforma. Escolhi o Macintosh, que acabou sendo a
decisão certa.
Fui trabalhar no Balance of Power. Minha grande esperança era que talvez pudéssemos
reconstruir a indústria em linhas mais racionais. E, você sabe, havia uma chance real lá.
Esse foi o momento crucial da verdade para a indústria de jogos de computador, o período
de 85 a 87. E tomou o rumo errado. Na verdade, 1990 foi quando o destino da indústria foi
selado. E se alguma coisa o selou, foi o Wing Commander de Chris Roberts. Mas tivemos
uma abertura real por um tempo; parecia que poderíamos retirá-lo.
Como você acha que Wing Commander selou o destino da indústria?

A grande questão para a indústria em 1985 era o que venderia, se é que haveria alguma
coisa? Ninguém parecia saber ao certo, mas havia alguns fios. O fato de Balance of Power
ter sido um grande sucesso sugeriu às pessoas que talvez os jogos sérios pudessem ter
um futuro, ou pelo menos jogos que não eram videogames. E havia muita empolgação em
explorar algumas dessas ideias. Os outros jogos que foram um grande sucesso na época
foram toda a série de jogos da Infocom, que continuaram a se sair bem até o crash.
Porque eles eram claramente diferentes dos videogames.

sim. E você colocou esses dois juntos, e apontou fortemente em uma direção. Então, houve
muito esforço nesse sentido. A indústria ainda estava dividida porque era muito mais fácil
projetar os videogames, e eles pareciam vender para um grupo de pessoas que não foram
afetadas pelo acidente. Nós realmente oscilamos em cima do muro: para onde vamos –
videogames ou uma ampla gama de possibilidades de jogos? O que o selou foi o Wing
Commander, por duas razões. A principal coisa que o Wing Commander fez que condenou
a indústria foi que comprou quota de mercado. Ou seja, o Wing Commander era um programa
extremamente caro para escrever. É engraçado; Chris Roberts negou que tenha custado muito,
mas isso se deve a alguma contabilidade interna criativa. Naquela época, por volta de 1990, um
orçamento típico para um jogo seria de US$ 100.000 a US$ 200.000. Havia alguns feitos mais
baratos, mas $ 300.000 era um jogo muito caro. Wing Commander provavelmente custou cerca de
US $ 1.000.000. Para os padrões da época, isso era considerado absurdo. E, de fato, um membro
da Origin me disse que o Wing Commander por si só nunca pagou de volta seu investimento, mas
que os acompanhamentos e complementos sim. Mas o que eles estavam realmente fazendo era
gastar tanto dinheiro que só funcionaria se se tornasse o maior sucesso. Ele fez. O problema era
que eles elevaram o nível de toda a indústria, todos nós temos que produzir jogos de US$ 1.000.000
e, infelizmente, eles só podem funcionar se cada um for o jogo número um. E você só pode ter um
jogo número um. De modo que, por sua vez, forçou o indus a tentar se tornar muito mais
conservador. Temos essas despesas enormes, simplesmente não podemos ganhar dinheiro com
um jogo de número vinte. Qualquer coisa menos do que estar entre os dez primeiros vai perder
dinheiro. Então, muito rapidamente, tornou-se um negócio de sucesso. Isso já estava começando
no final dos anos 80, mas o Wing Commander selou isso. Então, uma vez que se tornou uma
indústria de sucesso, toda a estratégia de marketing, economia e tudo mudou, na minha opinião,
muito para pior. A outra coisa era que Wing Commander também parecia restabelecer ou
reconfirmar o papel do jogo de ação como a onda do futuro. E, basicamente, foi aí que a indústria
se solidificou, e o cimento já endureceu.
Foi logo antes do crash que você escreveu The Art of Computer Game Design, não foi?
Sim, na verdade eu comecei isso assim que entrei na Atari Research. É engraçado, um dos meus
objetivos na Atari Research era: “Vamos realmente aprimorar todo o campo do design de jogos”.
Então eu, em essência, tentei criar uma conferência de desenvolvedores de jogos de computador
dentro da Atari. Tentei organizar um seminário na tarde de sexta-feira. E um pouco de política
entrou no caminho. Mandei convites para todos os designers da Atari, e um cara cabeça-dura que
estava comandando o grupo de software da coin-op ficou furioso por eu não ter passado por ele.
Eu não segui a hierarquia corretamente e, portanto, ele enviou um memorando proibindo qualquer
um de seus funcionários de ir. Essa é uma das razões pelas quais a Atari entrou em colapso; havia
um monte de merda de ego cabeça de porco acontecendo. Assim, os seminários nunca deram
certo. Portanto, decidi: “OK, vou anotar essas ideias”. Comecei a trabalhar no livro. Terminei-o em
1982, mas Ray Kassar, o CEO, também era teimoso e insistiu que ele aprovasse pessoalmente o
manuscrito antes de enviá-lo a uma editora. Então eu mandei para ele, e ele ficou com ele por um
ano.
Você ainda olha para o livro de forma positiva?

Eu certamente percorri um longo caminho. Se eu soubesse que quinze anos depois as pessoas
ainda o estariam lendo e tirando algum benefício dele, eu teria ficado pasmo e simplesmente não
teria acreditado. Ainda recebo e-mails se referindo a ele. Não há dúvida de que ainda está
proporcionando às pessoas algum benefício. E isso diz algumas coisas muito ruins sobre toda a
indústria de jogos e a comunidade de jogos, quão pouco pensamento está acontecendo. É
vergonhoso.
Não há realmente nenhum outro livro como ele.
Sim, todas as outras tentativas acabam sendo livros de programação. É vergonhoso que não
um foi além desse livro.
Desde que você publicou aquele livro, você tem se preocupado muito em compartilhar seus
pensamentos sobre design de jogos com a comunidade. estou curioso porque
isso é.
Há duas razões muito distintas. Primeiro, aguçar meu próprio pensamento por meio da escrita, o que faço
muito. E segundo, comunicar ideias aos outros. Há
alguma sobreposição. Na maioria das vezes eu escrevo para mim mesmo. Eu tenho resmas e resmas de pouco
ensaios de design sobre projetos particulares, onde penso comigo mesmo sobre questões de design. No
entanto, às vezes escrevo um ensaio apenas para consumo público, coloco na web
ou algo assim, e isso é feito com um propósito muito diferente. Mas muitas vezes eu escrevo com ambos
propósitos.
Assim, seus escritos sobre design de jogos levaram ao estabelecimento do Computer

Conferência de desenvolvedores de jogos?
Comecei fundando o Journal of Computer Game Design. Isso acabou por

seja um sucesso; subiu para cento a cento e cinquenta assinantes em vez
rapidamente. E quando chegou a esse nível, percebi que realmente seria possível
para ter uma conferência, havia pessoas suficientes lá fora. Então eu decidi ter um pouco
conferência em miniatura em minha casa. Acabei de colocar um pequeno aviso no Diário, dizendo: “Estou
vai montar uma conferência, vai ser nesta data. E quem quiser
para vir, contacte-me.” Acabamos tendo vinte e seis pessoas presentes a esta conferência, um dia inteiro, e
todos nos sentamos na grande sala no andar de cima e conversamos sobre design de jogos.
Foi uma experiência muito emocionante! Todos concordaram, isso é ótimo, isso é maravilhoso,
temos que fazer isso de novo. Todos se viraram para mim e disseram: “Chris, faça isso de novo”. Eu disse ok.
Eu pensei sobre isso por um tempo e então eu decidi que seria muito bom se eu ampliasse
participação nisso recrutando outras pessoas para me ajudar. Eu decidi a única maneira
eles estariam realmente envolvidos se tivessem um senso de propriedade. Se eu trouxe
como assistentes para mim, isso nunca funcionaria. Então decidi criar uma corporação com um conselho de
administração e convidei outras cinco pessoas para fazer parte do conselho. E para
dar-lhes um senso de propriedade, mesmo que eu possuísse a coisa toda livre e clara e
tinha começado a rodar com meu próprio dinheiro, eu basicamente apenas dei a propriedade. Cada corpo
teve uma participação igual na conferência. Marcamos a conferência, e foi um grande
sucesso, e só cresceu e cresceu a cada ano.
Você previu que ele se tornaria o evento gigantesco que é agora?
Não, e até certo ponto isso reflete uma violação das minhas intenções iniciais. Nós tivemos alguns
disputas claras dentro do conselho: isso é um show, como a E3, ou é uma conferência acadêmica, como
AAAI? Minha sensação era que o cerne disso é a troca de ideias entre
desenvolvedores. Podemos ter um show, mas tem que ser um show à parte. Está sempre escondido
uma esquina. Esta conferência foi projetada para pessoas compartilhando ideias, e é por isso que eu
surgiu a ideia das mesas redondas. Infelizmente, agora é um show, e a conferência agora é uma atividade
secundária.
Então, depois da Atari, você se tornou um desenvolvedor de jogos independente. Por que
você fez isso em vez de optar por voltar para uma grande empresa?
Bem, no início foi forçado em mim. Mas então, uma vez que eu comecei, eu estava trabalhando no
Balance of Power e era um projeto independente. Era mais inércia do que qualquer outra coisa.
Você prefere ser independente?

Sim, sou um trabalhador solitário. Estou muito preocupado com a minha eficiência e com o quanto
eu recebo. Quando você está trabalhando com outras pessoas, você passa muito tempo apenas
segurando a mão delas, explicando coisas para elas, ajudando-as, em vez de realmente fazer
qualquer coisa. Senti que tinha muitas ideias e, se realmente quisesse explorá-las, teria de explorá-
las sozinho.
Então, o que originalmente começou a trabalhar em Balance of Power?

Foi uma espécie de culminação. Meu
interesse em jogos de guerra surgiu
porque eu fazia parte da geração
vietnamita. Enquanto muitas pessoas
queriam resistir à guerra, eu queria
entender a guerra para que eu pudesse
fazer algo a respeito. Senti que
protestar nas ruas era muito ad hoc,
uma solução muito temporária e pouco
eficaz também. Eu estava fazendo
perguntas como, como as guerras
começam? Durante todo o início dos
anos 70 e início dos anos 80, eu era Balance of Power II: A Edição de 1990
um estudante de guerra, aprendendo
tudo o que podia sobre história militar. Finalmente, em 1984, senti que tinha entendido isso bem o
suficiente para poder projetar um jogo em torno de alguns desses conceitos. Eu diria que o suporte
emocional para o jogo foi a música de Bob Dylan “Blowin' in the Wind”. Você sabe, “Quantas vezes
as balas de canhão devem voar antes de serem banidas para sempre?” Foi isso que me deu a
inspiração emocional para continuar com o projeto, embora houvesse muitos pontos em que parecia
impossível. Eu estava adotando uma abordagem completamente diferente para projetar e explorar
novos territórios e houve muitas vezes em que parecia impossível. Foi preciso muito esforço
emocional para superar esses problemas e seguir em frente.
Mas você achou que o conceito era atraente o suficiente para valer a pena?
sim. Eu realmente queria fazer um un-wargame. Temos muitos jogos de guerra.
E em Balance of Power quando você chega ao ponto de ter uma guerra que você perdeu.
Sim, esse era o objetivo do jogo. Não sei se você se lembra, mas se houvesse uma guerra, a tela
ficaria preta e diria: “Nós não recompensamos o fracasso”.
Isso foi uma grande surpresa para muitas pessoas.
Em algum momento você se preocupou que o jogo fosse muito diferente?

Eu não esperava que se tornasse um sucesso, mas senti que era importante fazer. Foi exatamente a
mesma coisa que aconteceu com a Frente Oriental. Eu fiz a Frente Oriental para mim e então, vejam só,
todo mundo adorou. Bem, isso é muito bom. Eu fiz Balance of Power para mim e, caramba, todo mundo
adorou. Mas também fiz outros jogos para mim que foram fracassos lúgubres, comercialmente falando.
Como você conseguiu equilibrar o realismo com a jogabilidade em Balance of Power?

As pessoas falam sobre realismo versus jogabilidade como se fosse um dilema. Eu vejo isso mais como
uma questão de afiar as coisas. Um artista, pintando um retrato, acentuará deliberadamente certos
componentes do rosto que ele sente realçar o caráter do assunto. Eles não veem isso como realismo
versus jogabilidade, eles veem isso como arte. Da mesma forma, senti que precisava aprimorar, editorial
e artisticamente, aqueles elementos que eu achava que mostravam claramente as questões em jogo.
Então eu certamente fiz do mundo um lugar muito mais perigoso. Tirei muitas complexidades chatas,
simplifiquei e aprimorei para um jogo sobre rivalidade geopolítica pura e direta entre as duas
superpotências. E foi só isso, mostrando claramente esse conflito.
Eu li que Trust & Betrayal: The Legacy of Siboot é o seu jogo favorito.
Por que é que?
Todos os jogos que fiz foram originais,
com exceção do segundo Balance of
Power, que fiz a pedido urgente do meu
editor. Com essa única exceção, tudo o
que fiz foi um novo design. Mas com
Siboot fui muito mais longe do que com
qualquer outro jogo, ou seja, em termos
de quão longe levei o design além das
convenções do design de jogos. Siboot
era facilmente o mais avançado. Explorei
ideias com o Siboot que as pessoas
ainda nem chegaram perto. Estávamos
falando sobre Gossip como, de certa Confiança e Traição: O Legado da Siboot
forma, à frente de outros jogos. Siboot
foi muito, muito além de Gossip. A outra coisa sobre Siboot era que não era apenas uma boa ideia.
Havia pelo menos três grandes ideias no Siboot, cada uma delas digna de um jogo por si só.
E então havia muitas outras pequenas ideias. Aqui está um exemplo de uma pequena ideia.
Agora existe um conceito de interface do usuário chamado “dicas de ferramentas”. Se você colocar o
cursor sobre alguma coisa e deixá-la lá por alguns segundos, aparecerá um texto descritivo. Eu antecipei
isso e criei algo vagamente semelhante, onde você pode clicar e segurar um botão para ver sua
funcionalidade. Isso foi quatro anos antes de as dicas de ferramentas serem notadas pela primeira vez
como um item de interface do usuário no mundo dos PCs. Essa não foi uma ideia importante da minha
parte; Eu considerava que era apenas uma coisinha pequena, mas na época, ninguém tinha nada assim.
Então, quais foram as três principais inovações?

Primeiro, a linguagem, o uso da linguagem como elemento de interface primário. Você fala com as
outras criaturas. Eu vejo isso como completamente diferente da abordagem do analisador de texto,
porque eu realmente não acho que isso seja comunicação linguística, isso é algo muito diferente.
Segundo, ele usou um analisador inverso. Na verdade, o conceito central por trás do analisador foi
patenteado pela Texas Instruments em 1979. Eu não sabia disso na época. No entanto, minha
implementação foi diferente o suficiente para que nunca nos preocupemos com problemas de
violação de patentes. A abordagem da TI foi mais orientada por menus. O meu, no final, se resumia
a ser funcionalmente semelhante a um menu, mas tecnicamente é chamado de paleta. Então eu
não inventei esse conceito, mas desenvolvi sua implementação e mostrei muito claramente como
fazer esse tipo de coisa. Essa foi uma grande inovação, e lamento dizer que ninguém parece ter
corrido com esse conceito. A terceira grande inovação do jogo foi o uso de relações de combate
não transitivas, que vem sendo usadas em alguns jogos desde então.
Isso foi basicamente apenas uma extensão da ideia de pedra-tesoura-papel. Esse conceito básico
de relações não transitivas tem um enorme potencial de desenvolvimento; você pode construir
jogos inteiros com extensões disso. E não há razão para que a não transitividade seja aplicada a
três componentes. Você pode ter um anel que tem doze componentes e então as implicações de
vitória ou derrota no anel não transitivo podem ser interpretadas de muitas, muitas maneiras. É
uma área enorme de design de jogos para explorar. Isso seria fácil de implementar. É só que
ninguém está pensando em linhas tão pouco convencionais.
Você acha que a não convencionalidade do projeto prejudicou a popularidade de Siboot ?

Bem, sim e não. Na verdade, só foi vendido no Mac. Nunca houve uma versão para PC feita. Acho
que vendemos cerca de quatro mil cópias no Mac, o que para os padrões da época foi
decepcionante, mas não horrível. A regra geral na época era que você vendia de cinco a dez vezes
mais no PC do que no Mac. Então estamos falando de vinte a quarenta mil cópias se houvesse
uma porta para PC. Mas a editora optou por não fazê-lo.
Então, como em Gossip, seu objetivo era colocar as pessoas nos jogos?
sim. E eu levei esse conceito de “pessoas não coisas” muito mais longe com Siboot do que com
Gossip. Outra inovação foram as histórias intersticiais que aparecem. Eles não eram irrelevantes,
eles realmente se encaixavam no jogo geral.
Então você fez Balance of Power II apenas por insistência da editora?

sim. Eu tinha feito Siboot, e eles publicaram, e era óbvio que não ia dar dinheiro para eles. Eles
estavam obviamente desapontados. Eles estavam perguntando sobre uma sequência. Eles me
pressionaram com força desta vez, e eu senti que lhes devia uma. Então eu fiz a sequência de
Balance of Power .
Então você não tinha grandes

esperanças de melhorar o original?
Não, e na verdade eu senti que Balance
of Power II foi pouco mais que uma
limpeza da BoP I. É engraçado, no
entanto. Pelos padrões da indústria,
era uma nova versão importante e
merecia ser chamada de “Segunda
Edição”. Mas para os meus padrões,
estava apenas arrumando, adicionando
alguns sinos e assobios, mas em
termos de jogabilidade não fez muito.
Balance of Power II: A Edição de 1990
Então, de onde veio a ideia de Guns & Butter ?
Mais ou menos na mesma época, os três melhores designers de jogos do mundo,

independentemente, tiveram a mesma ideia. Cada um de nós disse: “Vou fazer um jogo de
conquistar o mundo, um jogo do Império ”. (Esses três eram Sid Meier, Dan Bunten e eu.) É
interessante como cada um de nós tomou um caminho completamente diferente. Todos nós
sabemos como Sid pegou o dele, e foi um sucesso imenso. Sid, Dan e eu nos reunimos em um
ponto para discutir como nós três abordamos nossos projetos. Sid tinha uma noção muito clara:
ele ia tornar isso divertido. Ele não dava a mínima para mais nada, ia ser divertido. Ele disse: “Eu
não tenho absolutamente nenhuma reserva em brincar com realismo ou qualquer coisa, desde que
eu possa torná-lo mais divertido”.
Minha abordagem era torná-lo educacional, e a abordagem de Dan era torná-lo social.
Dan veio com este pequeno jogo maravilhoso, Global Conquest, onde você realmente interage
com as outras pessoas jogando. Acho que aquele jogo era uma joia desconhecida. Ele bombardeou
ainda pior do que Guns & Butter. Ele teve problemas intermináveis com a Electronic Arts. Eu não
vejo por que ele ficou com eles, porque eles continuaram querendo que ele colocasse elementos
de shoot-'em-up em seus jogos, especialmente MULE . Eu considero MULE , provavelmente, o
melhor design de jogo já feito. Ou seja, em termos da plataforma com a qual ele teve que trabalhar
e da experiência em design da época, o MULE foi definitivamente o melhor já feito. E é um jogo
brilhante, muito divertido e nunca foi portado para uma máquina moderna. Isso é uma tragédia. E
a razão disso é que a Electronic Arts insistiu que os jogadores pudessem atirar uns nos outros.
Dan recusou, apenas disse sem rodeios: “Isso não vai acontecer”. E a missão Global Con foi da
mesma forma. Não se tratava tanto de fotografar, mas de trabalhar em equipe.
Armas e Manteiga
Meu jogo de conquistar o mundo, Guns & Butter, era realmente mais sobre macroeconomia.
De fato, durante o desenvolvimento, foi chamado de Conquista Macroeconômica. Eu acho que é
razoavelmente bem sucedido como um jogo para ensinar sobre como a história realmente se
desenvolve, mas isso é tudo. Foi certamente um dos meus jogos mais pobres, sem dúvida.
Realmente não tinha tanta criatividade. Houve algumas ideias fofas, mas onde esse jogo teve
ideias fofas, Siboot teve trovões de gênio. Por exemplo, a Guns & Butter tinha esse pequeno
algoritmo bacana para gerar continentes. Também desenvolvi um algoritmo maravilhoso para dar
nomes a estados e províncias, e estou muito orgulhoso desse algoritmo; é muito inteligente.
Mas isso é mera esperteza, não gênio criativo.
Guns & Butter tem algumas ideias interessantes sobre balanceamento de sistemas complexos.
Mas você acha que não funcionou?
Não, não funcionou, em grande parte porque eu estraguei completamente o manejo do comércio e das alianças.
Isso foi um desastre. Acho que se eu tivesse dado mais seis meses ao jogo, provavelmente teria
funcionado bem, mas apressei-me.
Balance of the Planet parece ser um jogo extremamente educacional. Era essa sua intenção?
Ah, absolutamente. Eu não tinha a

menor intenção de fazer algo que
fosse divertido. Meu sentimento foi:
“OK, existem todos aqueles shoot-'em-
ups e assim por diante, e eu não vou
tentar competir com essas coisas. Eu
vou fazer um jogo que explora outra
área da humanidade. Então, vou
fazer simulação pura, e vou tornar
essa simulação muito realista e muito
educativa também.” Sabíamos que o
Dia da Terra de 1990 estava chegando
e pensamos: “Vamos lançar essa
coisa a tempo do Dia da Terra”. E Equilíbrio do planeta
senti que essa seria uma das minhas

contribuições. Mais uma vez, a geração do Vietnã, o Dia da Terra e todo esse jazz. Balance of
Power era sobre a Guerra do Vietnã, e Balance of the Planet era sobre o Dia da Terra.
O SimEarth de Will Wright foi lançado logo após o Balance of the Planet. É interessante
comparar os dois. Claro, o dele é mais um brinquedo e o seu é muito mais orientado a
objetivos.
SimEarth não foi um dos melhores esforços de Will. Ele fez coisas brilhantes, mas acho que ele
não tinha um propósito claro com o SimEarth. Era tipo, “OK, aqui está este planeta, e aqui estão
esses processos geológicos, e aqui estão essas formas de vida, e...” Não havia nenhum foco de
design para isso. Ele parece ter dito: “Vamos pegar SimCity e fazer isso em toda a Terra”. Esse
tipo de abordagem extrapoladora do design nunca funciona bem. E não deu
funcionam bem para ele. Certamente foi mais bem-sucedido do que Balance of the Planet, porque
era muito mais bonito e tinha muitos recursos fofos. Mas não foi tão educativo quanto Balance of
the Planet.
O SimEarth tinha muitos sistemas interessantes, mas era difícil entender o que estava
acontecendo.
Era mais que todos os diferentes sistemas, eles meio que não somavam nada. Ele tinha todas essas
simplificações, mas não eram simplificações propositais. Eram simplificações para tornar os sistemas
internos acessíveis, mas não acrescentavam nada. O modelo para o desenvolvimento dos sistemas
vivos não parecia fazer sentido para mim, embora fosse fácil ver seus resultados.
Já ouvi Balance of the Planet criticado por não ser muito divertido. Você vê a diversão como
a condição sine qua non do design de jogos?
Esse é exatamente o problema.
Muitas pessoas vêem a diversão
como a condição sine qua non. Essa
é uma maneira pela qual a indústria
de design de jogos seguiu o caminho errado.
Basicamente, jogos de computador e
videogames são agora um, e na
verdade eles são todos videogames
no sentido de jogos de tiro fofos,
muitos gráficos, esplendor e ênfase
na diversão no sentido infantil. Não
vejo razão para que os jogos de
computador precisem se restringir
dessa maneira. É como se algum Equilíbrio do planeta
corpo dissesse: “Fui ver o filme Das
Boot, mas não foi nada divertido, então é um filme ruim”. Bem, me desculpe, mas Das Boot não foi
feito para ser divertido. Acho que podemos concordar que O Resgate do Soldado Ryan não é um
filme divertido, mas é muito bom. E a mesma coisa vale para a Lista de Schindler. E, claro, há
muitos filmes divertidos. Star Wars foi muito divertido. Mas Hollywood não se restringe da mesma
forma que a indústria de jogos. Suponho que esse foi todo o impulso dos meus esforços durante os
anos 80 e início dos anos 90, para ajudar a indústria de jogos a se tornar uma indústria de
entretenimento de base ampla, em vez de uma indústria infantil e divertida. Eu falhei nisso. Agora
definitivamente não é uma indústria de entretenimento, e nunca será. Eles se colocaram em um
canto do qual nunca poderão se libertar. É mais como quadrinhos. É uma pena ver o meio dos
quadrinhos usado brilhantemente por pessoas como Spiegelman e McCloud, mas é relegado às
lojas de quadrinhos, onde as crianças mascam chicletes. Poucos adultos levam as graphic novels a
sério. Algum progresso é evidente, mas é um processo lento, lento. Eu não tenho certeza se eles
vão conseguir sair dessa lixeira.
Então você acha que a indústria de jogos chegou ao mesmo ponto de estagnação?
sim. Só que eles nem estão tentando sair; eles ainda não perceberam que há um problema.
Então acho que foi isso que o levou a deixar a indústria de jogos e começar a trabalhar
no Erasmatron.
Bem, havia dois fatores nisso. Sim, eu estava me afastando constantemente da indústria de
jogos. A marca disso foi o “Discurso do Dragão” que dei. Essa palestra foi... Vou apenas contar
como terminou. Na palestra, falei sobre “o dragão” como metáfora para esse objetivo artístico.
E, logo no final do discurso, em essência, parei de falar com o público e conversei diretamente
com o dragão. Eu disse: “E agora que finalmente me dediquei de corpo e alma à tarefa de
perseguir o dragão, de repente, lá está ele, posso vê-lo brilhante e claramente”. Comecei a
falar com o dragão, e isso foi intenso. Eu não consigo me lembrar exatamente, mas eu disse
algo como: “Você é poderoso, você é poderoso, você é lindo, mas você é tão feio. Sim, sim,
você me assusta”, e então gritei: “Você me machucou! Eu senti suas garras rasgando minha
alma!” Eu não estava mais dando palestras, isso era muito mais atuação. Eu soltei aquela frase
“você me machucou” com grande paixão, e isso assustou o público. Eles não estavam
acostumados a esse nível de paixão nas palestras técnicas com as quais estavam familiarizados.
E então eu disse: “Não sou bom o suficiente para enfrentá-lo, não sou experiente o suficiente,
então vou fazer isso agora. Tenho que ficar cara a cara com você, olho no olho, e vou fazer
isso agora, aqui. Estendi a mão e puxei uma espada e meio que me agachei e gritei em um
grito de guerra: “Pela verdade, pela beleza, pela arte, ataque!” Fui galopando pelo corredor
central da sala de aula e nunca mais voltei.
Isso foi na Conferência de Desenvolvedores de Jogos de Computador?

sim. Muitas pessoas pensaram: “Bem, Chris deu seu canto de cisne, ele nunca mais voltará”.
Mas, na verdade, voltei no ano seguinte e tinha toda a intenção de continuar emprestando
minha experiência: “Vou nessa outra direção, mas vocês precisam da minha ajuda e ainda
estarei lá”. Infelizmente, um terrível incidente com os membros do conselho da conferência pôs
fim a isso. O que foi tão doloroso não foi apenas o comportamento dos membros do conselho,
mas também a atitude da comunidade, que era: “Ei, aqui é o Vale do Silício, você só precisa
lutar para conseguir o seu. Se eles jogam duro, qual é o problema?” Minha reação foi: “Só não
quero fazer parte dessa comunidade desagradável”. Foi uma experiência tão amarga que se
mudar para Oregon era um imperativo. Eu tive que sair do Vale do Silício. E é engraçado, toda
vez que vou lá agora, posso ver a ganância do Vale do Silício ao meu redor.
Isso realmente me incomoda.
Então isso o levou a trabalhar no Erasmatron?

Eu estava evoluindo nessa direção. Mas o que fez disso um movimento negativo foi A, a
indústria estava indo editorialmente em direções que eu não gostava, e B, a indústria estava
indo em direções morais e sociais das quais eu não gostava.
Então, como surgiu o projeto Erasmatron?

Comecei a fazer histórias interativas. Eu disse: “Vou voltar e vou fazer meu jogo do Rei Arthur
agora”. Porque eu tinha feito um jogo do Rei Arthur no Atari do qual eu me orgulhava, que tinha
muitas boas ideias, mas senti que não fazia justiça às lendas, então senti que devia algo a essas
lendas. Comecei tudo de novo para fazer uma abordagem completamente nova. Isso me levou até
o mecanismo de contar histórias. No entanto, tudo foi codificado à mão e foi extremamente difícil.
Havíamos visitado todas as grandes empresas tentando interessá-las e ninguém se interessou.
Mais ou menos nessa época, encontrei uma senhora chamada Edith Bjornson, que trabalhava
na Fundação Markle. Ela sugeriu que eu levasse a tecnologia em uma direção diferente, como
uma tecnologia capacitadora para permitir que pessoas não técnicas criassem seus próprios
mundos de histórias. gostei muito da ideia. Então Markle me financiou, e a estratégia fundamental
do projeto foi expressa no slogan “Liberte uma onda de criatividade”. Assim, eu estava construindo
três peças de software. O Erasmatron, que é o software de edição para o motor, o motor, que
realmente executou tudo e, finalmente, o front-end, que o entregou ao usuário. Era um projeto
enorme e eu tinha que fazer isso em dois anos.
Infelizmente, o problema acabou sendo muito maior do que eu esperava. O que consegui trabalhar
depois de dois anos foi bom, e de fato tecnicamente adequado, mas não acho que seja
comercialmente adequado.
O que você quer dizer?

É preciso muito esforço para criar um resultado final suficientemente divertido. Laura Mixon
trabalhou em Shattertown Sky por quase dezoito meses. Mas Shattertown simplesmente não
funcionou. Não era divertido, nem estava terminado. Havia lugares onde isso simplesmente parava.
No entanto, ela trabalhou mais e mais duro do que esperava. Não houve falha da parte dela. O
fracasso de minha parte estava subestimando a magnitude da tarefa. Achei que um ano seria
suficiente. Bem, primeiro, ela não obteve software totalmente operacional por pelo menos seis
meses. E segundo, a ferramenta que ela tinha era tão fraca que ela passava muito tempo
trabalhando. A conclusão foi que o Erasmatron precisava ser aprimorado, e havia alguns enfeites
no motor que saíam disso. Mas eles eram na verdade comparativamente menores. A maior parte
do trabalho que tenho feito desde então, no Erasmatron 2, foi tornar mais fácil todo o processo de
criação de um mundo de histórias.
Então você não concluiu que fazer um mundo de histórias é apenas uma tarefa inerentemente
difícil? Você encontrou maneiras de torná-lo mais fácil?
Bem, não há dúvida em minha mente de que criar um mundo de história com Erasmatron 2 é
imensamente mais fácil do que com Erasmatron 1. Erasmatron 2 limpa drasticamente o processo
de criação de um mundo de história, reduzindo o tempo necessário aproximadamente pela metade.
Você vê, com Erasmatron 1, estávamos filmando no escuro. Eu não tinha ideia de como seria o
processo de criação. Não me sinto mal que Erasmatron 1 tenha sido um design ruim; na verdade,
era muito melhor do que o documento de design original. Fiz algumas melhorias, mas não foram
suficientes. Eu acho que, usando Erasmatron 2, as pessoas podem criar excelentes mundos de
histórias com um compromisso adequado de tempo, o que considero ser
menos seis meses e provavelmente um ano, mas não provei isso. É isso que está parando todo o
projeto: preciso de provas.
Isso é algo que você espera fornecer com o projeto Le Morte D'Arthur ?
Eu não sei. Eu tive algum tipo de bloqueio criativo com esse projeto e não entendo o porquê. Eu acho
que um fator é uma sensação de desmoralização. Eu coloquei nove anos neste projeto, e até agora
tem sido um fracasso. Com exceção do financiamento de Markle, ninguém está interessado. Há sempre
alguns potes borbulhando. No momento, existem três grupos separados que manifestaram interesse
nisso. Portanto, não é como se eu chegasse a um ponto em que pudesse dizer “está morto”. Sempre
há algo acontecendo, e sempre há a esperança de que isso vá a algum lugar, mas essas coisas nunca
vão a lugar nenhum. Eu definitivamente estou ficando desanimado.
Como seria uma experiência ideal de contar histórias de Erasmatron?

Vou descrevê-lo de duas maneiras — tática e estratégica. Tático sendo o que o público experimenta
momento a momento, e estratégico sendo a experiência geral. Taticamente, o público verá uma
imagem estática na tela representando o que acabou de acontecer. Ele mostrará o rosto da pessoa
que acabou de fazer o que aconteceu, bem como de qualquer outra pessoa que esteja no mesmo
palco. Terá algum texto explicando o que aconteceu. A outra coisa que quero usar é algo como uma
técnica de quadrinhos. Ou seja, os quadrinhos mostram muito bem a ação entre os quadros. Portanto,
pode exigir dois quadros. Mas eu quero usar os estilos artísticos que se desenvolveram nos quadrinhos.
No livro de Scott McCloud, Understanding Comics, ele tem aquele triângulo que representa a quantidade
de abstração.
Com o rosto sorridente em um canto e o rosto fotorrealista no outro.

Direito. Meu palpite é que gostaríamos de mover esse triângulo para longe do canto do realismo
fotográfico. Gostaríamos de estar em algum lugar muito mais próximo da abstração e da representação.
Então acho que estamos falando de um tipo mais abstrato de exibição. E então haverá seu menu de
opções, expresso como frases completas. Isto é o que o jogador tem permissão para dizer ou fazer.
Estrategicamente, a grande diferença é que todos os mundos da história têm um caráter muito sinuoso
para eles. “Barroom Brawl” não, porque é uma cena única. “Reunião Corporativa” é uma cena única e
até serpenteia um pouco. Descobrimos como lidar com esse problema. Eu pensei que os pontos da
trama seriam suficientes, mas Laura e eu agora bolamos um esquema. Não quero descrever isso como
uma nova descoberta; em vez disso, este é um conceito que vem se formando lentamente há vários
anos.
Estamos colocando carne em seus ossos e acho que vai funcionar.
A ideia é que haja algo como um enredo central que está além do controle do jogador. No entanto,
o jogador controla muitas interações que não apenas influenciarão, mas também determinarão o
resultado final da trama. Por exemplo, considere um mistério de assassinato, como Shattertown.
Basicamente, em algum momento, o tempo vai acabar, e ou os clãs vão para a guerra ou Sky
desmascarará o assassino ou Sky será pego pelo assassino. Esse final foi estabelecido, e os eventos
forçarão esse final. A questão é que o final que você obtém depende criticamente de todas as coisas
que você fez até aquele ponto. Da mesma forma com Le Morte D'Arthur. O design básico diz, muito
claramente, que o jogo final terá a revolta de Mordred. Não importa o que aconteça, Mordred vai se
revoltar em algum momento. E quando o fizer, todos os outros atores vão escolher os lados. Alguns
deles irão com Mordred e outros ficarão com você. Haverá uma grande batalha, e o lado com os
batalhões maiores vence. A decisão de ir com Mordred ou ficar com você será baseada em todas
as coisas que você fez até aquele momento.
Eu vim com outro conceito para Le Morte D'Arthur que estou tentado a seguir, que incorporaria
alguns dos elementos do atual Le Morte D'Arthur.
Neste, você não está jogando como Arthur, você está jogando como Merlin, e você é uma planta
trans do futuro. Sua tarefa é modernizar a sociedade arturiana e, assim, impedir que a Idade das
Trevas aconteça. Você está tentando construir esta sociedade e fazê-la funcionar de forma mais
eficiente e ensiná-los um pouco sobre saneamento e educação e assim por diante. Ao longo do
caminho, todos os nobres estão desenvolvendo seus ressentimentos contra você e tentam várias
tramas para desacreditá-lo ou matá-lo. E, mais uma vez, Mordred se revolta. O resultado final
parece mais proposital, menos sinuoso.
Assim, o jogador é conduzido em uma direção mais do que na versão atual.

Não estamos pedindo que você seja criativo ou crie novas inovações sociais, simplesmente
apresentaremos a você em vários pontos oportunidades para iniciar novas inovações, para dizer:
“Tudo bem, você acha que é hora de ensinar essas pessoas saneamento básico, ou você acha que
é hora de ensiná-los a usar o estribo?” E cada um leva tempo. E ainda há essa trama constante
que se desenvolve à medida que você ajuda essa sociedade a se erguer pelos próprios pés. Mas
ainda há muita interação acontecendo. O que estamos desenvolvendo aqui é um conceito de “semi-
enredo” ou “pseudo-enredo” ou um “enredo esquelético” que pode prosseguir da maneira que um
enredo deveria. Você ainda tem um enredo, mas ele não sequestra toda a história e a domina como
em uma história convencional.
Assim, o jogador tem mais envolvimento do que teria lendo um livro, mas também não tem
liberdade total.
sim. A ideia é que você queira usar restrições dramáticas, não restrições artificiais.
Este é um drama. Tem que evoluir por certas regras. Vamos aplicar essas regras aqui. Não deve
incorrer em ressentimento por parte do jogador que ele não pode cutucar o nariz enquanto fala com
Arthur. Isso não é dramaticamente razoável. Alguns argumentam que se você não der ao jogador
total liberdade para ser criativo, isso simplesmente não funciona. Discordo disso inteiramente.
Contanto que você dê a ele todas as opções dramaticamente razoáveis, ou mesmo a maioria delas,
você está indo bem.
Então você é rápido em não chamar seu sistema Erasmatron de um jogo de qualquer tipo.
Por que é que?
A diferenciação é dupla. A primeira razão é o marketing. Neste momento, jogos de computador

significam Quake, Command & Conquer, ou algo assim. As associações com esse termo são todas
sobre shoot-'em-ups, gestão de recursos, e essas associações são muito claramente definidas na
mente do público. Se eu chamar isso de jogo, eles vão aplicar associações que são enganosas.
Além disso, o termo “jogo”, se você procurar no dicionário, tem mais polegadas de coluna do que a
maioria das palavras. Eu comparei com palavras como

Parte 1

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Parte 1

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Machine Translated by Google

Ricardo Rouse III

Dados de Catalogação na Publicação da Biblioteca do Congresso

Inclui referências bibliográficas e índice.

© 2005, Wordware Publishing, Inc.

Todos os direitos reservados

Avenida Los Rios 2320

Impresso nos Estados Unidos da América

Avisos de direitos autorais

Capítulo 1 O Que os Jogadores Querem .......................1

Capítulo 2 Entrevista: Sid Meier. . . . . . . . . . . . . . . . . . . . 20

Capítulo 3 Fazendo um brainstorming de uma ideia de jogo: jogabilidade, tecnologia,

Centopeia 3D. . . . . . . . . ....... . . ..... . . . . . . . . 50

Capítulo 4 Análise do Jogo: Centopeia . . . . . . . . . . . . . . . . 57

Capítulo 6 Entrevista: Ed Logg. . . . . . . . . . . . . . . . . . . . 87

Capítulo 7 Os Elementos da Jogabilidade . . . . . . . . . . . . . . . 115

Capítulo 8 Análise do jogo: Tetris . . . . . . . . . . . . . . . . . . 141

Inteligência artificial . . . . . . ....... . . ....... . . . . . . 147

Capítulo 9 Inteligência Artificial. . . . . . . . . . . . . . . . . . . 151

Capítulo 10 Entrevista: Steve Meretzky. . . . . . . . . . . . . . . 172

Capítulo 11 Narrativas . . . . . . . . . . . . . . . . . . . . . . . 202

Capítulo 12 Análise do Jogo: Tear. . . . . . . . . . . . . . . . . . 227

Capítulo 13 Multijogador. . . . . . . . . . . . . . . . . . . . . . . 237

Considerações de projeto. . . . . . . .....

Capítulo 14 Entrevista: Chris Crawford. . . . . . . . . . . . . . . 257

Capítulo 15 Fazendo a jogabilidade funcionar . . . . . . . . . . . . 281

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

Capítulo 17 Documentação de desenvolvimento de jogos . . . . . . . . . . 306

Capítulo 18 Entrevista: Jordan Mechner. . . . . . . . . . . . . . . 320

Capítulo 19 O Documento de Design . . . . . . . . . . . . . . . . . 355

Capítulo 20 Análise do Jogo: The Sims . . . . . . . . . . . . . . . . 382

Capítulo 21 Projetando Ferramentas de Projeto. . . . . . . . . . . . . . . . . 392

Capítulo 22 Entrevista: Will Wright. . . . . . . . . . . . . . . . . 408

Capítulo 23 Projeto de Nível . . . . . . . . . . . . . . . . . . . . . . 449

Capítulo 24 Análise do Jogo: Grand Theft Auto III . . . . . . . . . . 475

Capítulo 25 Teste de jogo . . . . . . . . . . . . . . . . . . . . . . . 483

Quem não deve testar. . . . . ....... . . ....... . . . . . . 487

Capítulo 26 Entrevista: Doug Church. . . . . . . . . . . . . . . . 500

Apêndice A Documento de Projeto de Amostra: Atomic . . . . . . . . 535

Apêndice B Documento de Projeto de Amostra: O Sofrimento. . . . . . . . 579

Bibliografia Selecionada. . . . . . . . . . . . . . . . . . . . 672

Introdução à segunda edição

Introdução à segunda edição

Ricardo Rouse III

inimigo equipado. E em Civilization, a jogabilidade é explorar o mundo, construir uma sociedade

O que é design de jogos?

Quem é um designer de jogos?

O que há neste livro?

Para quem é este livro

— Shigeru Miyamoto, falando sobre a criação de Pokémon

2 Capítulo 1: O que os jogadores querem

Por que os jogadores jogam?

Os jogadores querem um desafio Muitos

Capítulo 1: O que os jogadores querem 3

Os jogadores querem socializar Tenho

4 Capítulo 1: O que os jogadores querem

os jogos ainda fornecem a funcionalidade de bate-papo, e os jogadores, quando estão em um

Capítulo 1: O que os jogadores querem 5

Os jogadores querem uma experiência solitária dinâmica

Os jogadores querem o direito de se gabar

6 Capítulo 1: O que os jogadores querem

Os jogadores querem uma experiência emocional Assim

Os jogadores querem explorar Uma