Manual de Producao de Jogos Dig - Heather M. Chandler

PrefAcio de Tom Sloper
C355m Chandler, Heather Maxwell.

Manual de produção de jogos digitais [recurso eletrônico] /
Heather Maxwell Chandler ; tradução: Aldir José Coelho
Corrêa da Silva ; revisão técnica: João Ricardo Bittencourt. –
2. ed. – Dados eletrônicos. – Porto Alegre : Bookman, 2012.
Editado também como livro impresso em 2012.

ISBN 978-85-407-0184-7
1. Computação. 2. Jogos digitais – Gerenciamento de

projetos. 3. Jogos digitais – Desenvolvimento I. Título.
CDU 004.413(035)
Catalogação na publicação: Natascha Helena Franz Hoppen – CRB 10/2150

Tradução:
Aldir José Coelho Corrêa da Silva
Revisão técnica:
João Ricardo Bittencourt
Mestre em Ciência da Computação – PUC-RS
Coordenador Executivo do Curso Superior de Jogos Digitais – UNISINOS
Versão impressa
desta obra: 2012
2012
Obra originalmente publicada sob o título
The Game Production Handbook, 2nd Edition
ISBN 978-1-934015-40-7
Obra original em língua inglesa publicada por Jones & Bartlett Publishers, 40 Tall Pine Drive,
Sudbury, MA 01776.
Copyright©2009
Todos os direitos reservados
Capa: Maurício Pamplona
Leitura Final: Sandro Andretta
Gerente Editorial – CESA: Arysinha Jacques Affonso
Editora responsável por esta obra: Mariana Belloli
Editoração eletrônica: Techbooks
Reservados todos os direitos de publicação, em língua portuguesa, à

BOOKMAN EDITORA LTDA., uma empresa do GRUPO A EDUCAÇÃO S.A.
Av. Jerônimo de Ornelas, 670 – Santana
90040-340 – Porto Alegre – RS
Fone: (51) 3027-7000 Fax: (51) 3027-7070
É proibida a duplicação ou reprodução deste volume, no todo ou em parte, sob quaisquer

formas ou por quaisquer meios (eletrônico, mecânico, gravação, fotocópia, distribuição na Web
e outros), sem permissão expressa da Editora.
Unidade São Paulo

Av. Embaixador Macedo Soares, 10.735 – Pavilhão 5 – Cond. Espace Center
Vila Anastácio – 05095-035 – São Paulo – SP
Fone: (11) 3665-1100 Fax: (11) 3667-1333
SAC 0800 703-3444 – www.grupoa.com.br
IMPRESSO NO BRASIL
PRINTED IN BRAZIL
Para Jack
SOBRE A AUTORA
Heather Maxwell Chandler começou a trabalhar na indústria de jogos em 1996. Sua

empresa, Media Sunshine, Inc., presta serviços de consultoria para desenvolvedores,
publicadores e fornecedores de jogos digitais. Antes de criar a MSI, ocupou vários
cargos de produção na Ubisoft, Activision, Electronic Arts e New Line Cinema. Hea-
ther trabalhou em mais de 30 jogos, inclusive Two Worlds, Monster Madness: Grave
Danger, Ghost Recon: Advanced Warfighter, Ghost Recon 2, Heavy Gear, Apocalypse,
Vigilante 8, Rainbow Six 3: Raven Shield, Dark Reign e Shanghai: Second Dynasty.
Heather também é autora de The Game Localization Handbook e de três capítu-
los de Secrets of the Game Business, 2nd edition, publicado pela Charles River Media.
Publicou vários artigos sobre desenvolvimento de jogos e fez palestras no NLGD Festi-
val of Games, na Game Developers Conference, na Future Play, na North Carolina State
University e na Digital Game Expo. Formou-se com mérito na Vanderbilt University e
recebeu o título de Master of Arts (M.A.) pela USC School of Cinema-Television. Para
obter mais informações, visite www.mediasunshine.com.
AGRADECIMENTOS
Primeiro, gostaria de agradecer a David Pallai por publicar a 2a edição deste livro.
Seu aconselhamento e incentivo foram inestimáveis para mim durante o processo de
redação e edição. Também gostaria de agradecer a Jenifer Niles, minha editora na 1a
edição. Este livro não teria sido possível sem sua ajuda e apoio. Muito obrigada a Tom
Sloper por redigir o prefácio e também a todas as pessoas que concordaram em ser
entrevistadas; os depoimentos resultantes dessas entrevistas fornecem visões únicas
do processo de produção de jogos.
APRESENTAÇÃO
A produção de jogos digitais era menos complicada 30 anos atrás. Em apenas seis
semanas, uma pessoa criava o design, escrevia o código, gerava os recursos gráficos e
testava a funcionalidade de um jogo. Naquela época, alguns personagens constituídos
de blocos e uma ótima jogabilidade entretinham os jogadores por horas, o que tornava
fácil para uma só pessoa executar todas as tarefas de desenvolvimento do jogo. Atual-
mente, as pessoas esperam que os jogos digitais apresentem mais do que apenas uma
boa jogabilidade; elas querem um mundo que as absorva totalmente com personagens
vivos, som de alta qualidade, enredos interessantes e um jogo que evoque emoções
como medo, surpresa, alegria e até mesmo tristeza. Para um jogo responder a essas ex-
pectativas, é preciso um número muito maior de pessoas envolvidas em sua produção.
O gerenciamento da produção de jogos no século XXI é um desafio, principal-
mente porque nenhum processo padronizado assegura a conclusão bem-sucedida de
todos os jogos. Jogos que conseguem chegar às prateleiras das lojas com frequência
enfrentam tantos obstáculos que é comum o produtor e os membros da equipe ficarem
secretamente surpresos por terem conseguido concluir seu trabalho. O lado bom é
que os desenvolvedores estão se aperfeiçoando na produção de jogos, porque estão
aprendendo com seus erros e buscando em outras disciplinas métodos para criar um
processo de desenvolvimento mais eficiente.
O objetivo deste livro é trazer alguma ordem para o caótico mundo da produção
de jogos digitais. Ele não ensinará a projetar o próximo grande jogo ou quais tecnolo-
gias de ponta devem estar presentes na iteração de um jogo de última geração. Em vez
disso, o foco são os aspectos práticos de gerenciamento do desenvolvimento de jogos,
inclusive a definição do objetivo do jogo, a criação de um plano para a realização des-
se objetivo, o gerenciamento eficaz das pessoas que criam o jogo e a manipulação de
todos os outros obstáculos do trajeto.
A produção de jogos não é uma ciência; você não pode esperar que todos os jogos
em que trabalhar apresentem os mesmo desafios e recompensas do último jogo que
criou. No entanto, existem elementos comuns a toda equipe de desenvolvimento de
jogos, e é no aproveitamento dessas semelhanças e na previsão de novos desafios que
o produtor deve focar seus esforços.
Este livro foi dividido em oito seções, todas fornecendo informações-chave sobre
o processo de produção de jogos:
Parte I: Visão Geral da Produção: esta seção apresenta uma visão geral do ciclo
de produção e dos papéis existentes na equipe. Ela termina com uma discussão de
algumas metodologias tradicionais de desenvolvimento de software aplicadas à pro-
dução de jogos atualmente.
xii Apresentação
Parte II: Informações Comerciais: discute informações legais gerais que qual-
quer produtor deve conhecer, assim como o relacionamento entre o publicador e o
desenvolvedor.
Parte III: Gestão de Pessoas: discute como contratar e manter talentos, construir
equipes e se comunicar com eficiência. Essas habilidades são essenciais para qualquer
produtor bem-sucedido.
Parte IV: Produção Técnica: discute todos os miniprojetos que devem ser geren-
ciados durante a produção, que incluem o voiceover, as necessidades de marketing e
a captura de movimentos.
Parte V: Pré-produção: discute toda a atividade de tomada de decisões e plane-
jamento que ocorre durante a pré-produção, como a definição do conceito, requisitos
e planejamento do jogo. Uma fase de pré-produção organizada é essencial para a fase
de produção ser bem-sucedida.
Parte VI: Produção: discute todo o trabalho que deve ser gerenciado durante a
fase de produção. Ela inclui informações sobre técnicas de produção, o ciclo de pro-
dução, classificações etárias e localização.
Parte VII: Testes: discute como testar os jogos e lançar seu código. Ela inclui
informações sobre a submissão de jogos a Sony, Microsoft e Nintendo para aprovação.
Parte VIII: Pós-produção: discute como concluir com sucesso seu projeto com a
preparação de um kit de fechamento e a condução de um post-mortem com a equipe.
Além disso, vários especialistas da indústria foram entrevistados sobre suas ex-
periências de produção de jogos digitais e ofereceram generosamente conselhos e in-
formações que qualquer pessoa envolvida nessa atividade achará valiosos. Boa leitura!
Heather Maxwell Chandler

Produtora Executiva, Media Sunshine, Inc.
heather@mediasunshine.com
www.mediasunshine.com
PREFÁCIO
Com frequência o papel do produtor é ignorado, não só na promoção do jogo, mas,

às vezes, até mesmo dentro da própria indústria de jogos digitais. Os astros neste
setor são seus chefes de programação, arte e design – certamente não seus produto-
res. Afinal, quem é o produtor a não ser a pessoa que lidera e gerencia o projeto? E
isso não é tedioso?
Quando um projeto é bem-sucedido, resultando em um produto altamente exito-
so, é a equipe ou o astro principal que recebe os créditos. Quando um projeto fracassa,
no entanto, o culpado é o produtor.
Há mais coisas relacionadas ao papel de produtor do que se imagina. Produzir
não é apenas gerenciar um cronograma ou fazer cálculos de um orçamento. Geral-
mente, o produtor compartilha a visão de design do jogo, sempre atento à maneira
como esse jogo pracisa agradar ao público. O produtor tem de conseguir falar a lín-
gua dos programadores e profissionais de marketing, executivos e testadores, artistas
e vendedores. Tem de estar familiarizado com a linguagem jurídica dos contratos e
o exagero das campanhas de propaganda. O produtor deve ser capaz de reduzir o
design de um jogo portentoso a apenas alguns itens e transformar uma ideia em um
longo manifesto.
Ao mesmo tempo protetor e carrasco, pai e professor, o produtor desempenha
vários papéis assumindo muitas identidades diferentes no decorrer da produção do
projeto de um jogo digital. Ele é realmente o intermediário – o ponto central de toda a
comunicação, coordenação e gerenciamento na criação de um jogo.
O produtor, em um momento ou outro, estará em contato com todo tipo de pes-
soas do ciclo de vida de um jogo. Do executivo que obteve os direitos de propriedade
intelectual para a criação de um jogo licenciado, ao designer que o transformará em
um design de jogo. Do vice-presidente do estúdio que designa o produtor para o pro-
jeto, ao representante do suporte ao cliente que responderá perguntas do usuário final
sobre problemas de instalação. Do astro de cinema que empresta sua voz ao jogo, às
mães e avós que compram jogos para suas crianças. Do distribuidor que quer saber por
que deve fazer espaço na prateleira para esse jogo em vez de outro, ao programador
júnior que está preocupado com o fato de sua ideia não ter sido implementada. Do
testador que encontrou um bug obscuro porém fatal, ao artista freelancer que quer um
elenco de atrizes mais sexy. O produtor tem de ser diplomático, persuasivo, condes-
cendente, rigoroso, teimoso e amigável.
Mesmo sendo tão importante para o sucesso de um projeto, com frequência o
produtor não recebe treinamento algum para desempenhar a função. Geralmente, ele
assume um papel difícil sem um treinamento formal de gerenciamento. É promovido
para o cargo e espera-se que aprenda por osmose, fazendo, ou que simplesmente saiba
xiv Prefácio
o que fazer de modo intuitivo. Nosso amado segmento da indústria reconhece a impor-
tância de treinar seus programadores, artistas, advogados e profissionais de marketing
– mas não seus produtores, pelo que parece.
A ampla falta de treinamento de produtores resultou na ruína de muitos pro-
jetos. Todo ano, nos corredores da Game Developers Conference, ouvimos histórias
espantosas de projetos que deram errado. Post-mortems só são escritos para projetos
finalizados, portanto, geralmente as piores histórias de guerra não têm registro na li-
teratura.
Nosso segmento da indústria pode não treinar você, mas este livro irá ajudar.
Heather Maxwell Chandler é boa nisso. Ela esteve lá, pôs em prática. Sabe do que fala.
Leia este livro do início ao fim e mantenha-o por perto como um guia prático.
Tom Sloper
Designer, produtor e consultor de jogos digitais
Sloperama Productions – www.sloperama.com
SUMÁRIO
Parte I: Visão Geral da Produção 1
Capítulo 1 Visão Geral da Produção de Jogos 3

1.1 Introdução 3
1.2 Ciclo de produção 4
1.3 Pré-produção 5
Conceito do jogo 6
Requisitos do jogo 7
Planejamento do jogo 8
Lista de verificação da pré-produção 9
1.4 Produção 9
Implementação do plano 10
Rastreamento do progresso 11
Conclusão de tarefas 11
Lista de verificação da produção 12
1.5 Testes 12
Validação do plano 13
Liberação do código 13
Lista de verificação da execução de testes 14
1.6 Pós-produção 14
Aprenda com a experiência 14
Plano de arquivamento 15
Lista de verificação da pós-produção 15
1.7 Resumo do capítulo 15
Capítulo 2 Papéis Existentes na Equipe 17

2.1 Introdução 17
2.2 Produção 18
Produtor executivo 19
Produtor 19
Produtor associado 21
Experiência e treinamento 21
2.3 Arte 23
Diretor de arte 24
Artista líder 24
xvi Sumário
Artista conceitual 24
Construtor de mundos ou designer de níveis 24
Criador de assets 25
Animador 25
Artista técnico 25
Artista de marketing 25
2.4 Engenharia 26
Diretor técnico 27
Programador líder 27
Programador 27
2.5 Design 30
Diretor de criação 30
Designer líder 30
Designer 31
Redator 32
2.6 Teste de garantia da qualidade 34
Líder de testadores de QA 34
Testador de QA 35
2.7 Organização da equipe 35
2.8 Equipe da empresa 37
Marketing e relações públicas 37
Serviços de criação 38
Vendas 38
Capítulo 3 Métodos de Gerenciamento de Projetos 41

3.1 Introdução 41
3.2 Prós e contras 42
3.3 Processo Pessoal de Software (PSP) 44
3.4 Scrum 47
3.5 Project Management Institute (PMI) 51
Parte II: Informações Comerciais 57
Capítulo 4 Informações Legais 59

4.1 Introdução 59
4.2 Direitos de propriedade intelectual 60
Direitos autorais 61
Sumário xvii
Marcas registradas 61
Segredos comerciais 62
Patentes 63
4.3 Contratos legais 63
Contratos de empregado/consultor 64
Contrato por encomenda 64
Contratos de confidencialidade (NDA) 65
Contratos de desenvolvimento 65
Contrato de licença do usuário final (EULA) 66
4.4 Licenças 66
Capítulo 5 Relacionamento entre o Desenvolvedor e o Publicador 71

5.1 Introdução 71
5.2 Apresentando um jogo para um publicador 72
5.3 Gerenciando o relacionamento desenvolvedor-publicador 75
Desenvolvedor independente 80
Desenvolvedor exclusivo do publicador 84
5.4 Aprovações de jogos por terceiros 86
Parte III: Gestão de Pessoas 89
Capítulo 6 Contratando e Mantendo Talentos 91

6.1 Introdução 91
6.2 Contratando talentos 92
Triagem dos currículos 93
Entrevistando talentos 95
Dando feedback 98
6.3 Mantendo talentos 99
6.4 Treinamento 101
Recursos de desenvolvimento de jogos 102
Organizações 102
Conferências e feiras 103
Informações gerais da indústria de jogos 103
Capítulo 7 Equipes 105

7.1 Introdução 105
Leitura recomendada, The Essential Drucker 106
7.2 Liderança do projeto 107
Leituras recomendadas, Liderança 107
xviii Sumário
7.3 Seleção de líderes 108

7.4 Construção da equipe 110
Conhecendo uns aos outros 111
Definição de papéis 114
Treinamento cruzado 115
Leituras recomendadas, Gerenciamento 116
Formas de agrupamento 116
Reuniões da equipe 117
Site da equipe 118
7.5 Engajamento e motivação da equipe 119
Sinais de alerta 119
Atacando os sinais de alerta 121
Mostrando satisfação 122
Compartilhando a visão 123
Pesquisa na equipe 124
7.6 Qualidade de vida 126
Capítulo 8 Comunicação Eficaz 129

8.2 Comunicação escrita 130
8.3 Comunicação oral 130
8.4 Comunicação não verbal 132
8.5 Estabelecendo normas de comunicação 133
8.6 Desafios da comunicação 134
Resolvendo conflitos 134
Dando más notícias 136
Dando um feedback eficaz 137
Parte IV: Produção Técnica 139
Capítulo 9 Jogos On-line Multijogador em Massa 141

9.2 Diferenças entre os MMOs e outros jogos 142
9.3 Pré-produção 143
Questões de tecnologia 143
Questões de design 145
Questões artísticas 146
Equipe de produção 148
9.4 Produção 149
9.5 Pós-produção 151
Sumário xix
Capítulo 10 Voiceover 153

10.2 Planejando o voiceover 154
Design do voiceover 154
Considerações técnicas 155
Formatos de arquivo 156
Roteiro do voiceover 158
Voiceover de espaço reservado 159
Cronograma e equipe 160
10.3 Selecionando um estúdio de gravação 162
Solicitação de orçamentos 163
10.4 Escalando atores 165
Sindicalizados ou não sindicalizados 166
Vozes de celebridades 167
Preparando as descrições de personagens 168
Testes 168
Selecionando os atores e reservando seu tempo 171
10.5 Gravando o voiceover 173
Preparando a sessão de gravação 173
Dirigindo atores 174
Selecionando tomadas 175
Produtos de áudio 176
10.6 Lista de verificação do voiceover 176
Capítulo 11 Música 179

11.2 Planejando a música 180
Design da música 180
Considerações técnicas 181
Cronograma e equipe 182
Solicitação de propostas 184
11.3 Trabalhando com um compositor 185
11.4 Licenciando a música 186
Capítulo 12 Captura de Movimentos 191

12.2 Planejando a captura de movimentos 192
Requisitos da captura de movimentos 193
Lista de tomadas de captura de movimento 194
Cronograma 194
12.3 Trabalhando com um estúdio de captura de movimentos 195
Solicitações de proposta 196
xx Sumário
12.4 Preparando uma tomada de captura de movimentos 196

12.5 Lista de verificação da captura de movimentos 198
Capítulo 13 Marketing e Relações Públicas 201

13.2 Trabalhando com o departamento de marketing 202
Cronograma das etapas do desenvolvimento 202
Documentação do jogo 202
Grupos focais 203
13.3 Embalagem 204
Manuais 204
Arte da caixa 206
Cartões de referência do teclado 206
13.4 Demonstrações 206
Planejando uma demonstração 206
Demos de console 207
Demos localizadas 208
13.5 Recursos de marketing 208
13.6 Builds do jogo 209
Trabalhando com o departamento de relações públicas 209
Press tours 210
Entrevistas 210
Diários dos desenvolvedores 210
Exposições 210
13.7 Lista de verificação de recursos passíveis de entrega 211
Parte V: Pré-produção 213
Capítulo 14 Conceito do Jogo 215

14.2 Início do processo 216
Usando o brainstorm 217
Conceito inicial 218
Gênero 219
Plataforma 219
Análise SWOT 220
Análise competitiva 222
Aprovação 223
14.3 Defina o conceito 224
Sumário xxi
Declaração da missão 225

Cenário do jogo 226
Mecânica do jogo 226
Sinopse da história 227
Arte conceitual 227
Elementos de áudio 228
14.4 Protótipo 229
14.5 Análise de risco 232
14.6 Venda da ideia 234
14.7 Lançamento do projeto 235
14.8 Descrição da fase de conceituação 235
Capítulo 15 Requisitos do Jogo 237

15.2 Defina os recursos do jogo 237
15.3 Defina as etapas e produtos 240
15.4 Avalie a tecnologia 245
15.5 Defina as ferramentas e o pipeline 246
15.6 Documentação 248
Design 249
Arte 250
Técnica 251
15.7 Análise de risco 253
15.8 Aprovação 254
15.9 Descrição da fase de requisitos do jogo 254
Capítulo 16 Planejamento do Jogo 257

16.2 Dependências 258
16.3 Cronogramas 260
Criando um cronograma 261
Cronograma inicial 262
Rastreando tarefas 271
16.4 Orçamentos 274
Criando um orçamento 274
Gerenciando um orçamento 277
16.5 Equipe 279
16.6 Terceirização 280
Comunicação 282
16.7 Middleware 283
16.8 Descrição da fase de planejamento do jogo 286
xxii Sumário
Parte VI: Produção 289
Capítulo 17 Ciclo de Produção 291

17.2 Ciclo de produção do design 293
17.3 Ciclo de produção artística 296
17.4 Ciclo de produção de programação 297
17.5 Trabalho em conjunto 297
Capítulo 18 Técnicas de Produção 301

18.2 Colocando o projeto de volta no rumo certo 302
18.3 Revisões de projeto 305
Conduzindo uma revisão de projeto 306
Vantagens 307
18.4 Análise de estágios cruciais 308
18.5 Relatórios de status semanais 308
Para a equipe de desenvolvimento 309
Para a gerência 310
18.6 Reuniões 310
18.7 Alocação de recursos 312
18.8 Evitando o crescimento desenfreado 312
Priorizando funcionalidades 314
Solicitações de mudança 314
18.9 Estabelecendo processos de aprovação 315
Mantenha o processo simples 316
Defina e publique 316
Centralize o controle 316
18.10 Forças-tarefa 317
Capítulo 19 Criando Builds 319

19.2 Processo de build 320
Cronograma de builds 321
Builds automatizadas 321
19.3 Builds multilíngues 322
19.4 Notas de build 323
Para a equipe de desenvolvimento 323
Para a gerência 323
Para os departamentos de marketing e RP 324
19.5 Evitando a pirataria 324
Esquemas de proteção contra cópias 325
Sumário xxiii
Capítulo 20 Classificações de Software 327

20.2 Classificações etárias de software 328
20.3 ESRB (Estados Unidos) 330
20.4 PEGI (Europa) 333
20.5 BBFC e VSC (Reino Unido) 334
20.6 USK (Alemanha) 334
20.7 OFLC (Austrália) 335
20.8 CERO (Japão) 336
20.9 KMRB (Coreia) 336
Capítulo 21 Localização 339

21.2 Criando conteúdo internacional 340
21.3 Código favorável à localização 340
Assets de idiomas 341
Fontes e caracteres internacionais 342
Interface de usuário 342
Entrada do teclado 343
PAL e NTSC 343
Outras considerações técnicas 343
21.4 Nível de localização 344
21.5 Planejamento da localização 344
Cronograma, orçamento e equipe 345
21.6 Organizando os assets para tradução 346
21.7 Integrando os assets traduzidos 347
21.8 Testando 349
Teste de funcionalidades 349
Teste linguístico 349
21.9 Envio para o fabricante do console 351
21.10 Lista de verificação da localização 352
Parte VII: Testes 355
Capítulo 22 Testes 357

22.2 Cronograma de testes 358
22.3 Plano de testes 359
22.4 Pipeline de testes 362
Banco de dados de rastreamento de bugs 362
Definições de bugs 363
xxiv Sumário
22.5 Ciclo de testes 364

Registrando bugs 364
Atribuindo e fechando bugs 366
Verificando requisitos técnicos 367
22.6 Testes externos 368
Capítulo 23 Liberação do Código 371

23.2 Determinando a liberação do código 371
23.3 Lista de verificação para liberação do código 372
23.4 Gold Masters 374
Parte VIII: Pós-produção 377
Capítulo 24 Post-mortems 379

24.2 Finalidade de um post-mortem 379
24.3 Conduzindo um post-mortem 381
Envolva a equipe inteira 382
Prepare o post-mortem 382
Mantenha o foco 383
24.4 Documento de Lições Aprendidas 384
Capítulo 25 Kits de Fechamento 387

25.2 Definindo os kits de fechamento 388
25.3 Criando os kits de fechamento 388
Assets 389
Ferramentas 390
Código do jogo 390
Documentação 391
25.4 Organizando o conteúdo 392
25.5 Finalizando os kits de fechamento 392
25.6 Lista de verificação do kit de fechamento 393
Sumário xxv
Apêndice A Estudo de Caso – Ciclo de Produção de Um Jogo 395
Apêndice B Glossário 451
Apêndice C Recursos 455
Apêndice D Biografias 459
Índice 471
Parte I
VISÃO GERAL DA
PRODUÇÃO
A lgumas pessoas podem estar se perguntando quais são exatamente as respon-

sabilidades de um produtor em uma equipe de produção de jogos digitais,
uma vez que ele geralmente não é um criador de conteúdo, nem contribui direta-
mente com recursos para o jogo. O que elas não sabem é que, sem um produtor, um
jogo provavelmente nunca chegará às prateleiras das lojas.
O produtor é a principal força condutora que guia o processo de desenvolvi-
mento de jogos para assegurar que o trabalho seja concluído a tempo e conforme o
orçamento. Além disso, ele lidera a equipe e mantém sua motivação em momentos
críticos. Também age como um mediador entre a equipe de desenvolvimento e todas
as forças externas que tentam interferir no trabalho: o departamento de marketing, o
publicador e os concessores de licenças.
Esta seção é uma introdução ao processo geral de desenvolvimento de jogos e
fornece uma explicação básica sobre o que ocorre durante esse processo e como fun-
ciona uma equipe de criação de jogos. Também são apresentadas informações sobre
algumas metodologias de desenvolvimento de software que têm sido aplicadas na
criação de jogos. Estes são os tópicos abordados:
• Visão geral da produção de jogos

• Papéis existentes na equipe
• Processos formais de produção
1
VISÃO GERAL DA
PRODUÇÃO DE JOGOS
Neste capítulo
• Ciclo de produção • Produção • Pós-produção
• Pré-produção • Testes
1.1 Introdução
Se você for um produtor ou líder iniciante, deve estar curioso para saber em
que se meteu. Ainda que provavelmente venha a obter ajuda de seu chefe, do
publicador e da equipe, o peso da responsabilidade de criar um jogo e lançar
seu código é inteiramente seu. Atualmente, já que os orçamentos estão cres-
cendo e as equipes ficando maiores, os produtores e os líderes responsáveis
por um projeto devem ter um conhecimento sólido do processo de produção
de jogos, de como todas as variáveis envolvidas estão relacionadas e de como
modificar o processo para que atenda às necessidades dos jogos.
O processo de produção começa com a definição do conceito inicial do
jogo e termina com a criação de uma versão gold master do código final, com
o restante acontecendo entre esses dois pontos. O processo difere de um pro-
jeto para outro, e essa é uma das razões pelas quais a produção de jogos pode
ser difícil de gerenciar. Um desenvolvedor pode ter uma equipe pequena de
15 pessoas trabalhando em um jogo baseado na Web, mas outro pode ter mais
de 100 pessoas trabalhando em um jogo de console baseado na licença de um
filme conhecido.
Independentemente do tamanho da equipe, do escopo do jogo, do or-
çamento ou de outras variáveis, existe uma estrutura básica para o processo
geral de produção. O processo pode ser dividido em quatro fases principais:
pré-produção, produção, testes e pós-produção. Dentro de cada uma dessas
4 Parte I • Visão Geral da Produção
fases, vários objetivos devem ser atingidos antes de passarmos para a fase
seguinte. A conclusão bem-sucedida de cada fase afeta diretamente o êxito no
lançamento do jogo.
1.2 Ciclo de produção
A Figura 1.1 serve como uma visão geral do ciclo básico de produção. Tarefas
específicas de produção de jogos, como a gravação do voiceover, a criação
de modelos de personagens e a depuração de códigos multijogador, não são
mostradas, já que variarão de um projeto para outro. O diagrama descreve os
objetivos gerais das fases e como o sucesso de cada fase depende da conclusão
da fase anterior. Como você pode ver, o detalhamento do plano do projeto na
pré-produção é importante, pois fornece uma base sólida a partir da qual o
jogo será construído. Um projeto que não define um plano na pré-produção
costuma encontrar vários problemas que poderiam ter sido evitados ou resol-
vidos antecipadamente.
É importante ressaltar que esse diagrama descreve uma visão muito bási-
ca do ciclo de produção de jogos e que alguns jogos, principalmente quando
os riscos são altos, passarão por um processo de produção iterativo com vá-
rios ciclos de produção.
Por exemplo, se você quiser criar uma verificação de conceito funcional
para seu jogo – um nível jogável totalmente polido –, deve incluir alguns
ciclos de desenvolvimento no processo de produção como um todo, com o
primeiro ciclo composto pela pré-produção, produção e teste do protótipo; a
segunda fase enfocando o principal conjunto de recursos e assets do jogo; e
FINALIZAÇÃO
Post-mortem
Plano de
arquivamento
TESTES
Validação do plano
Liberação do código
PRODUÇÃO
Implementação do plano
Rastreamento do progresso
Avaliação de risco
PRÉ-PRODUÇÃO
Conceito
Requisitos do projeto
Planejamento do projeto
Avaliação de risco
Figura 1.1 Ciclo básico de produção de jogos.

1 • Visão Geral da Produção de Jogos 5
um terceiro ciclo criando e adicionando qualquer recurso e asset extra, como

níveis adicionais. A Figura 1.2 é um diagrama de vários ciclos de produção
para um único projeto.
Pré-produção
Primeiro
Finalização protótipo Produção
jogável
Testes
Pré-produção
Segundo
Finalização protótipo Produção
jogável
Testes
Recursos extras
Figura 1.2 Vários ciclos de produção para um único projeto.
1.3 Pré-produção
A pré-produção é a primeira fase do ciclo de produção e é crítica para a de-

finição de como será o jogo, quanto tempo demandará sua criação, quantas
pessoas serão necessárias e quanto custará tudo.
Ela pode demorar de uma semana a mais de um ano, dependendo do
tempo que você tiver para concluir o jogo. Uma regra prática é a de que a
produção requer aproximadamente 10 a 25% do tempo de desenvolvimento
total de um jogo. Portanto, se você estiver trabalhando em um projeto de seis
meses, a pré-produção demorará de algumas semanas a um mês. Se estiver
trabalhando em um projeto de dois anos, a pré-produção demorará de dois a
seis meses.
O principal objetivo da pré-produção é essencialmente a criação do pla-
nejamento do jogo, que é um roteiro para a conclusão deste e a liberação do
código. O planejamento deve incluir informações sobre o conceito do jogo, os
recursos e restrições que afetam esse conceito, a documentação básica técnica
e de design, e, para concluir, quanto custará, quanto tempo levará e quantas
pessoas, com que habilidades, serão necessárias. A pré-produção pode ser
dividida nos componentes a seguir: conceito do jogo, requisitos do jogo, pla-

nejamento do jogo e avaliação de risco.
Conceito do jogo
Jim Lewis, autor de vários livros sobre gerenciamento de projetos, sugere
pensarmos no conceito como se estivéssemos procurando a solução para um
problema. Portanto, um conceito de jogo que começa como uma pergunta
apresenta um problema a ser resolvido. Seria divertido brincar de cowboys e
índios no espaço? Como seria disputar uma corrida com carros conceituais?
Após o conceito inicial do jogo ter sido determinado, geralmente pelo gerente
do estúdio ou pelo publicador, ele é passado para a equipe de desenvolvimen-
to como um problema a ser resolvido.
Muitos conceitos inicialmente são vagos e a equipe primária de desen-
volvimento deve destrinchá-los para que todos entendam facilmente quais
são os objetivos do produto e quais devem ser os principais elementos de jo-
gabilidade necessários ao seu suporte e fortalecimento. Por exemplo, se você
estiver trabalhando em um atirador tático militar realista, não seria apropria-
do que o mundo do jogo usasse tecnologia alienígena fictícia. O conceito tam-
bém define a plataforma de hardware e o gênero do jogo, já que essas decisões
modelarão como o conceito crescerá. Quando o conceito tiver sido determina-
do, você deve comunicá-lo claramente para o resto da equipe de uma maneira
que todos entendam e se entusiasmem. Essa comunicação pode ser feita com
a definição de uma declaração de missão.
Uma declaração de missão deixa as pessoas estimuladas em relação ao
jogo em que estão trabalhando. Ela define o que vai ser feito e para quem está
sendo feito. Para resumir, usarei um termo de que todos se lembrarão – a
declaração de missão é a “conversa de elevador” da equipe. A equipe inteira
deve ser envolvida na definição e modelagem da declaração de missão, assim
todos terão contribuído com uma parte do projeto. Essa sensação de posse é
imperativa para a construção de uma equipe forte. Lembre-se de que a decla-
ração de missão não precisa declarar “como” essas coisas serão feitas, já que o
“como” será resolvido quando o planejamento do projeto for elaborado.
Após determinar o conceito inicial, a próxima etapa é adicionar os ele-
mentos básicos de jogabilidade. Considerações iniciais sobre a mecânica de
jogabilidade, o esquema de controle, o gênero, a história, os personagens e
outros hooks que diferenciarão o jogo da concorrência devem ser incluídas. A
criação de protótipos dos elementos ajuda a definir melhor a experiência do
jogo. Os protótipos podem começar no papel, e à medida que as ideias forem
se desenvolvendo melhor, protótipos jogáveis serão criados. Se possível, tente
criar um protótipo polido que represente a experiência de jogabilidade final.
Quando esses conceitos tiverem um nível maior de detalhes, conduza
uma análise de risco para determinar os maiores riscos da produção do jogo.
Nesse ponto, haverá muitas incertezas, portanto, será difícil determinar ris-
cos específicos. Contudo, se algumas constantes já estiverem definidas, como
o tamanho da equipe ou a tecnologia, elas poderão ser usadas como base de
uma análise de risco inicial. Se você não reservar um tempo para definir os
riscos do desenvolvimento, provavelmente encontrará problemas inespera-

dos no projeto que poderiam ter sido minimizados se fossem identificados
como riscos no início.
Após o conceito ser totalmente definido e um protótipo ser criado, você
o apresentará para o gerente do estúdio e o publicador. Essa apresentação dará
a eles a chance de ver como a equipe planejou criar um jogo sólido a partir
do conceito inicial. Provavelmente eles darão uma resposta à exposição, que
terá de ser incorporada pela equipe. Se gostarem do que ouvirem, aprovarão
o jogo para continuação da pré-produção. Quando essa aprovação ocorrer, o
produtor organizará um lançamento oficial do projeto para apresentar o con-
ceito totalmente aprovado para a equipe.
O Capítulo 14, “Conceito do jogo”, discute a fase de conceituação com
mais detalhes. Após o conceito ser definido, a próxima etapa é determinar os
requisitos do jogo.
Requisitos do jogo
Os requisitos do jogo incluem os recursos básicos de arte, design e engenharia
que devem ter suporte, qualquer restrição ao projeto e a documentação básica
técnica e de design. Todos os recursos devem estar de acordo com o conceito
estabelecido e a declaração da missão.
Os membros da equipe devem ser envolvidos na determinação do con-
junto principal de recursos e na priorização dos outros recursos para poderem
desenvolver uma sensação de posse do jogo. O conjunto de recursos deve
incluir alguns elementos exclusivos que o diferenciem de outros jogos. Uma
maneira de fazer isso é pedir que a equipe liste recursos que “devem entrar”,
“queríamos que entrassem” e “seria bom ter”, discuta-os e então crie um con-
junto de recursos final priorizado. O Capítulo 15, “Requisitos do jogo”, apre-
senta um método para essa atividade.
As restrições devem ser consideradas quando as prioridades do conjunto
de recursos forem definidas Por exemplo, todos podem chegar à conclusão de
que a construção de um novo mecanismo gráfico é um recurso que “deveria
entrar”, mas se não houver tempo suficiente para a construção do mecanismo,
esse recurso será rebaixado para um recurso “que seria bom ter” e a equipe
terá de descobrir outras maneiras de atingir os objetivos gráficos do jogo.
Após o conjunto de recursos ter sido definido e adequado às restrições,
as etapas e os produtos de cada etapa são definidos. Alguns projetos são pla-
nejados com base em etapas mensais e outros se baseiam na primeira etapa
jogável, na etapa alfa e na etapa beta. Os dois métodos funcionam, contanto
que os produtos esperados em cada etapa sejam claramente definidos e divul-
gados para a equipe. Os produtos são os elementos do jogo, como os assets
gráficos, os recursos técnicos e o script dos níveis, que demonstram a jogabi-
lidade e a aparência do universo do jogo.
Enquanto o conjunto de recursos estiver sendo definido, devemos pes-
quisar a tecnologia para descobrir o que funciona melhor para o jogo propos-
to. Isso inclui examinar as restrições de hardware, investigar soluções de mi-
ddleware e avaliar qualquer tecnologia interna adequada. Também devemos
pensar nas ferramentas necessárias à criação dos assets do jogo e na melhor

maneira de estabelecer um pipeline de produção.
Quando todos esses elementos tiverem uma definição melhor, a equi-
pe deve criar alguma documentação básica técnica e de design enfocando os
principais aspectos do jogo. Como ilustrado na Figura 1.2, os jogos podem ser
compostos por vários ciclos de produção; portanto, essa documentação deve
tentar destrinchar o ciclo de produção atual. Os detalhes da documentação
serão adicionados aos recursos principais no decorrer da pré-produção, para
que, quando a produção começar, todos tenham as informações necessárias
para iniciar seu trabalho. Para concluir, conduza uma análise de risco nesse
estágio para determinar os maiores riscos do jogo até então.
Quando os requisitos do jogo estiverem determinados, todos os tomado-
res de decisão do processo devem recebê-los para averiguação e aprovação.
Isso inclui o gerente do estúdio, o publicador e até mesmo o departamento
de marketing. Junto com a equipe de desenvolvimento, esses grupos também
têm sua parte no projeto e vão querer se certificar de que seus interesses sejam
considerados durante a fase de requisitos. Quando os envolvidos examinarem
a documentação, darão uma reposta que provavelmente afetará as restrições. É
uma boa ideia centralizar o recebimento de todas as repostas, determinar o que
pode ser incorporado e então enviar o plano revisado para nova apreciação.
Pode ser difícil fazer todos examinarem os requisitos, principalmente se
os grupos estiverem em regiões geográficas diferentes. Em casos como esse,
o produtor deve reservar uma hora e um local onde os envolvidos possam se
reunir (pessoalmente ou por algum tipo de conferência eletrônica) para che-
gar a um consenso e finalizar os requisitos. Consulte o Capítulo 15, “Requisi-
tos do jogo”, para obter mais informações.
Planejamento do jogo
O planejamento do jogo é onde as informações são reunidas mostrando como
tudo será realizado. O produtor lidera os esforços de preparação do orçamen-
to, do cronograma e das necessidades de pessoal do jogo, mas deve trabalhar
com a equipe para determiná-los. Se ele não consultar a equipe primária de
desenvolvimento, principalmente no caso do cronograma e do pessoal, será
difícil fazer os membros da equipe se comprometerem com o planejamento
do jogo. Isso é particularmente verdade quando o cronograma é muito agressi-
vo e o produtor precisa que todos trabalhem em seu nível mais alto de produ-
tividade. Consulte o Capítulo 16, “Planejamento do jogo”, para ver detalhes
da criação de orçamentos, cronogramas e planos de pessoal.
Quando o orçamento, o cronograma e o planejamento de pessoal esti-
verem montados, a equipe os examinará para verificar se conseguirão obter
os requisitos desejados. Se não for possível, o planejamento ou os requisitos
podem ter que ser corrigidos. Na verdade, tanto os requisitos quanto o pla-
nejamento do jogo serão atualizados sempre que algo mudar no projeto. Não
esqueça de conduzir outra análise de risco e também de pedir que todos os
stakeholders examinem o plano.
Lista de verificação da pré-produção

A Figura 1.3 é uma lista de verificação da pré-produção que você pode usar
para acompanhar seu progresso durante essa fase.
LISTA DE VERIFICAÇÃO DA PRÉ-PRODUÇÃO S/N NOTAS

CONCEITO
NO SITE O conceito inicial do jogo foi definido?
A plataforma e o gênero foram especificados?
A declaração da missão foi concluída?
Os elementos básicos de jogabilidade foram definidos?
O protótipo foi concluído?
A análise de risco foi concluída?
A exposição do conceito está pronta para aprovação?
Todos os stakeholders aprovaram o conceito?
O lançamento do projeto foi agendado?
REQUISITOS DO JOGO
Os recursos que “devem entrar”, que “queríamos que entrassem” e que “seria bom
ter” foram definidos?
As restrições foram definidas e solucionadas nos conjuntos de recursos?
As etapas e os produtos foram definidos?
A tecnologia foi avaliada em relação ao conjunto de recursos desejado?
As ferramentas e o pipeline foram definidos?
A documentação básica do design foi concluída?
A documentação técnica básica foi concluída?
Todos os stakeholders aprovaram os requisitos do jogo?
PLANEJAMENTO DO JOGO
O orçamento foi concluído?
O cronograma inicial foi concluído?
O plano inicial de pessoal foi concluído?
Os membros da equipe primária aprovaram o cronograma e o plano de pessoal?
Todos os stakeholders aprovaram o planejamento do jogo?
Figura 1.3 Lista de verificação da pré-produção.
1.4 Produção
A fase de produção é quando a equipe pode realmente começar a produzir

assets e código para o jogo. Quase sempre é tênue a fronteira entre a pré-pro-
dução e a produção, já que você poderá começar a produzir alguns recursos
enquanto outros ainda estarão na pré-produção. Esse começo da fase de pro-
dução também será afetado pelas verificações e avaliações que o publicador
ou o gerente do estúdio pode querer fazer. Por exemplo, talvez a equipe não
possa começar integralmente a produção antes de um protótipo jogável ter
sido criado e aprovado.
Se tudo for planejado durante a pré-produção, a fase de produção não
deve apresentar surpresas; é claro que raramente é isso que ocorre. Após sua
equipe ter começado integralmente a produção, haverá grandes probabilida-
des de que algum recurso ou asset tenha de ser adicionado, alterado ou remo-
vido. No entanto, se você tiver uma estratégia de implementação organizada
em fases que enfoque primeiro a obtenção dos recursos e assets principais,

será mais fácil se preparar para mudanças inesperadas.
A fase de produção enfoca a criação de conteúdo e código, o rastrea-
mento do progresso e a conclusão de tarefas. Além disso, a avaliação de risco
é contínua durante a produção; portanto, você estará preparado para qualquer
evento inesperado que afetar negativamente o ciclo de produção do jogo. A
produção é livremente dividida nas seguintes fases: implementação do plano,
rastreamento do progresso e conclusão de tarefas.
A implementação do plano requer que o produtor comunique o plano final
para a equipe e forneça para os membros todas as ferramentas e recursos ne-
cessários à sua implementação. Torne o plano publicamente disponível para
a equipe em um formato que seja facilmente acessado, como um site ou uma
área designada para a equipe na rede. Inclua todos os documentos criados na
fase de pré-produção, com o cronograma e as etapas (milestones) em um local
claramente visível. Também é útil afixar cópias impressas de prazos-chave
nas salas da equipe.
Quando o plano tiver sido comunicado para a equipe, o produtor deve
ficar atento para manter todos os seus elementos atualizados. Se o design
de um recurso, o prazo de uma etapa ou a lista de assets mudar, isso deve
ser anotado cuidadosamente no planejamento do jogo e comunicado para a
equipe, o gerente do estúdio e possivelmente o publicador. É importante fazer
essas alterações a tempo, porque todos os envolvidos estarão usando o plano
do projeto como principal ponto de referência. Se o plano não for atualizado
durante o processo de produção, alguns recursos podem não ser considerados
ou recursos errados podem ser implementados.
O crescimento desenfreado (feature creep), situação em que funcionali-
dades são continuamente adicionadas ao projeto durante a fase de produção,
com frequência ocorre durante essa fase porque as coisas mudam regular-
mente. Alguém terá uma boa ideia para o jogo e vai querer adicioná-la ao
conjunto de funcionalidades sem pensar no impacto que isso terá sobre o
cronograma ou os recursos do jogo. O crescimento desenfreado não é bom
para o projeto como um todo porque, sempre que uma nova funcionalidade
é adicionada, mais recursos têm de ser alocados ao seu projeto, bem como
implementação, criação de assets e testes. Isso significa que os recursos já em
uso serão expandidos ao máximo e a inclusão de funcionalidades adicionais
pode fazer o jogo não atender um importante prazo de liberação de código.
Se o crescimento desenfreado não for controlado durante a produção, o jogo
ficará rapidamente sem tempo e recursos. É claro que essa situação pode
ser evitada se você mantiver um controle rigoroso sobre ela. O Capítulo 18,
“Técnicas de produção”, apresenta mais informações sobre como controlar o
crescimento desenfreado.
Após o planejamento do jogo ser implementado, os profissionais de arte,
design, engenharia e testes dependerão ainda mais uns dos outros para con-
cluir tarefas. Se os artistas estiverem esperando os profissionais de design
para ver os detalhes de design de um nível específico, podem ter que ficar
em compasso de espera se essa documentação não estiver pronta. Se a equipe
de cinemática estiver esperando pelos arquivos finais de voiceover do en-
genheiro de som, isso atrasará seu trabalho e colocará em risco o prazo final
de cinemática. Como produtor, você é responsável por trabalhar com seus
líderes para resolver rapidamente qualquer dependência de tarefas. Em al-
gumas situações, talvez a equipe de cinemática possa executar outra tarefa
enquanto espera os arquivos de voiceover, e assim por diante. O rastreamento
do progresso ajuda o produtor e os líderes a identificar gargalos no processo
de produção.
O rastreamento do progresso junto ao planejamento do jogo é crucial para sa-
bermos em que ponto o jogo está em um determinado momento da produção.
Se você não tiver um planejamento no qual basear o rastreamento, seu jogo
sairá de controle rapidamente e você se verá em uma situação desagradável.
Se você, como produtor, não souber quanto tempo falta para a conclusão de
um recurso, ou quanto do recurso já foi concluído, como poderá saber se a
equipe de desenvolvimento do jogo está no caminho certo para cumprir seus
prazos?
O rastreamento do progresso não precisa ser complicado. Na verdade,
quanto mais complicado, mais improvável que as pessoas o usem. Por exem-
plo, você pode decidir rastrear o progresso no Microsoft Project, e se for um
especialista no uso desse software, será muito fácil fazê-lo. No entanto, se
não souber como usar os recursos de rastreamento do Microsoft Project, tal-
vez desista de uma vez por todas de rastrear o progresso. De qualquer forma,
deve implementar um método que funcione para você e a equipe, já que eles
também precisam saber que progresso foi feito. Uma maneira simples de fa-
zer isso é criar listas de verificação ou rastrear tarefas no Microsoft Excel. No
Capítulo 16, “Planejamento do jogo”, há mais detalhes sobre como rastrear
tarefas durante a produção.
Conclusão de tarefas
É muito simples concluir tarefas na maioria das áreas do desenvolvimento
de jogos, principalmente quando o trabalho resulta em um recurso tangível,
como no caso de recursos artísticos e de design. É difícil determinar quan-
do tarefas de engenharia estão concluídas, já que não há indicadores claros
relacionados a quando um trecho de código está concluído, principalmente
quando correções de bugs ainda podem ser feitas no código.
A definição de critérios de saída é uma boa maneira de um produtor ou
líder determinar mais precisamente quando uma tarefa está concluída. Os
critérios de saída são condições que devem ser atendidas antes de uma tarefa
ser considerada terminada. Por exemplo, um documento de design está con-
cluído após ser escrito e aprovado; um modelo de personagem está concluído
após o artista adicionar sua textura final.
Os critérios de saída devem ser de fácil compreensão para todos, princi-

palmente para a pessoa que estiver executando a tarefa. No caso de uma tarefa
difícil de definir critérios, o produtor pode se reunir com os membros e o líder
da equipe apropriada para que todos os envolvidos entrem em acordo quanto aos
critérios de saída. Se você for um desenvolvedor independente trabalhando para
um publicador, os critérios de saída dos principais produtos da etapa devem fi-
car claramente definidos no contrato entre o publicador e o desenvolvedor.
Lista de verificação da produção

A Figura 1.4 é uma lista de verificação da produção que você pode usar para
rastrear seu progresso durante a fase de produção.
LISTA DE VERIFICAÇÃO DA PRODUÇÃO S/N NOTAS

IMPLEMENTAÇÃO DO PLANO
NO SITE O planejamento do jogo foi claramente comunicado para a equipe?
O planejamento do jogo está em um local publicamente acessível?
O planejamento pode ser facilmente atualizado com mudanças feitas pelo produtor?
Todas as pessoas da equipe têm os recursos necessários para fazer seu trabalho?
Há um processo definido para o controle do crescimento desenfreado?
A avaliação de risco está ocorrendo regularmente em toda a produção?
Há um processo definido para o gerenciamento das dependências de tarefas?
RASTREAMENTO DO PROGRESSO
Há um planejamento de jogo no qual o rastreamento do progresso possa se basear?
Há um processo definido para o produtor rastrear o progresso de todas as tarefas?
O progresso é afixado em áreas visíveis nas salas da equipe?
CONCLUSÃO DE TAREFAS
Cada tarefa tem critérios de saída claramente definidos?
Esses critérios de saída estão publicamente disponíveis para a equipe?
Todos os stakeholders estão de acordo sobre quais serão os critérios de saída?
Figura 1.4 Lista de verificação da produção.
1.5 Testes
Os testes são uma fase crítica do desenvolvimento de jogos. É quando o jogo

é verificado para vermos se tudo funciona corretamente e se não há nenhum
bug fatal. Os testes são contínuos durante o processo de produção, já que o
departamento de Garantia da Qualidade (Quality Assurance – QA) verificará
as builds, as novas funcionalidades e os novos recursos da etapa à medida
que ficarem disponíveis no jogo. Após a etapa beta, quando todos os assets e
recursos do jogo estiverem totalmente implementados, a equipe de desenvol-
vimento se dedicará principalmente à correção de bugs e à criação de novas
builds (versões compiladas e executáveis do jogo) para a equipe de QA testar.
A fase de testes pode ser considerada como tendo duas partes: a validação do
plano e a liberação do código. O Capítulo 22, “Testes”, contém informações
mais detalhadas sobre o processo de testes.
A principal responsabilidade do departamento de QA é criar o plano de testes
para o jogo e validar o jogo em relação ao plano. O plano de testes é baseado
nos assets e funcionalidades descritos no planejamento do jogo. Se o plane-
jamento do jogo não estiver atualizado, a QA não poderá criar os planos de
testes apropriados. O produtor e os líderes devem trabalhar juntos ao depar-
tamento de QA para tornar disponíveis todas as informações necessárias à
criação de planos de testes precisos. Além disso, o departamento de QA deve
trabalhar com a equipe de desenvolvimento para instruí-la sobre o processo
de testes e sobre como usar o software de rastreamento de bugs.
O jogo deve ser validado em todas as áreas, e dependendo de seu tama-
nho, isso pode requerer um período de tempo significativo para os testes. Por
exemplo, se estiverem trabalhando em um jogo de PC localizado em dois idio-
mas, os testadores de QA terão de verificar várias configurações de PC, com
diferentes sistemas operacionais, placas de som e placas de vídeo. Também
terão de verificar cada uma das versões localizadas nessas configurações.
O departamento de QA não é responsável apenas por encontrar bugs,
mas também por regredir bugs que a equipe de desenvolvimento corrigiu. Ge-
ralmente, um bug não é considerado fechado até o departamento de QA tê-lo
verificado novamente no jogo e confirmado que ele foi corrigido.
Após um jogo ter sido totalmente testado, o departamento de QA começará o
processo de liberação do código. O processo de liberação do código é diferente
do teste de QA normal por serem examinados candidatos ao lançamento do có-
digo (code release candidates – CRC) – builds que a equipe de desenvolvimento
considera prontas para distribuição. Nesse ponto da produção, todos os princi-
pais bugs já foram corrigidos, a funcionalidade está conforme projetado e todos
os assets do jogo foram finalizados. O jogo só precisa de um último conjunto de
verificações para confirmarmos se está pronto para ser entregue ao fabricante.
O produtor deve reservar tempo no cronograma para o processo de lan-
çamento do código para que o departamento de QA tenha tempo suficiente
para fazer as verificações finais em um jogo. O tempo para essa atividade
variará, dependendo do tamanho do jogo e do tamanho do departamento de
QA. O ideal é que haja tempo suficiente para o departamento de QA executar
o plano de testes inteiro no CRC, o que pode levar apenas um dia ou demorar
uma semana. Se eles conseguirem concluir o plano de testes inteiro e consta-
tarem que tudo confere, o código do jogo será considerado lançado e o disco
poderá ser entregue ao fabricante para replicação. Consulte o Capítulo 23,
“Liberação do código”, para ver mais detalhes sobre esse processo.
Se você estiver trabalhando em um produto para console, também terá
de enviar o jogo para o fabricante do console para aprovação. Eles têm suas
próprias verificações e avaliações para cada jogo, e se não aprovarem um jogo,
este não será fabricado até os problemas serem corrigidos e o jogo ser reenvia-
do para aprovação. Há a chance de que, mesmo se o departamento de QA do
desenvolvedor lançar o código de um jogo, ele não seja aprovado pelo fabri-
cante do console. No entanto, geralmente os desenvolvedores podem reenviar
builds para aprovação até receberem a aprovação final.
Lista de verificação da execução de testes

A Figura 1.5 é uma lista de verificação para ser usada na fase de testes de
um jogo.
LISTA DE VERIFICAÇÃO DOS TESTES S/N NOTAS

VALIDAÇÃO DO PLANO
NO SITE O plano de testes foi criado?
O plano de testes foi atualizado para o departamento de QA?
O plano de testes foi atualizado com qualquer alteração que tenha sido feita
no planejamento do jogo?
As etapas de testes foram consideradas no cronograma?
O software de rastreamento de bugs foi disponibilizado para os testadores
e a equipe de desenvolvimento?
Todas as áreas do jogo foram testadas?
Todos os bugs foram regredidos e fechados?
LIBERAÇÃO DO CÓDIGO
A equipe de desenvolvimento enviou um candidato final à liberação do código?
Há tempo suficiente no cronograma para o departamento de QA concluir
o plano de testes no candidato à liberação do código?
O departamento de QA aprovou o produto para liberação do código?
Somente no caso de console: O jogo que teve o código liberado foi enviado
para o fabricante do console para aprovação?
Somente no caso de console: O fabricante do console aprovou o jogo para replicação final?
Figura 1.5 Lista de verificação da execução de testes.
1.6 Pós-produção
Após o jogo ter o código liberado e ser aprovado para fabricação, o processo
de desenvolvimento deve ser finalizado antes de estar oficialmente concluído.
Muitas vezes, essa etapa é esquecida ou ignorada, o que não é apropriado. É
nesse momento que a equipe pode relaxar, preparar um kit de fechamento
para projetos futuros e examinar os prós e contras de sua recente experiência
de desenvolvimento de um jogo. A fase de pós-produção é composta por dois
elementos: o aprendizado com a experiência e o plano de arquivamento.
Aprenda com a experiência

O aprendizado por meio da experiência é a melhor maneira de melhorarmos
o processo de desenvolvimento de jogos para projetos futuros. Uma maneira
de fazer isso é com a condução de um post-mortem no fim de um projeto. Um
post-mortem é uma chance para todos os envolvidos examinarem o que ocor-
reu de bom e ruim em um projeto e proporem soluções para projetos futuros
com base nessas experiências.
Como produtor, você pode planejar a condução de pequenos post-mortems

em pontos-chave durante o desenvolvimento, como nas etapas alfa e beta. Nunca
é tarde demais para aprender algo sobre a melhoria do processo, até mesmo no
meio do projeto. O Capítulo 24, “Post-mortems”, fornece detalhes sobre como
conduzir e publicar um post-mortems.
Plano de arquivamento
Após o jogo ter seu código liberado, ele será arquivado para uso em projetos futu-
ros. Isso é feito com a criação de um kit de fechamento. Esse kit contém toda a do-
cumentação de design, o código-fonte, o arquivo-fonte da arte, os assets finais do
jogo, os arquivos finais de música e tudo o mais que foi usado na criação do jogo.
Os kits de fechamento são necessários porque o publicador pode querer
criar uma versão especial do jogo a ser instalada em um componente de hard-
ware ou a equipe de desenvolvimento pode querer reutilizar o código ou os
assets em outro projeto. Eles são particularmente úteis quando a equipe traba-
lha em uma franquia e quer basear a próxima iteração dela no código-fonte do
jogo anterior. O Capítulo 25, “Kits de fechamento”, apresenta mais detalhes
sobre como criar e arquivar esses kits.
Lista de verificação da pós-produção

A Figura 1.6 é uma lista de verificação da pós-produção para você acompa-
nhar seu progresso.
LISTA DE VERIFICAÇÃO DA FINALIZAÇÃO S/N NOTAS

PLANO DE ARQUIVAMENTO
NO SITE O kit de fechamento foi concluído?
APRENDIZADO POR MEIO DA EXPERIÊNCIA

O post-mortem foi concluído?
O post-mortem foi publicado para o estúdio de desenvolvimento inteiro?
Figura 1.6 Lista de verificação da pós-produção.
1.7 Resumo do capítulo
O processo de produção de jogos pode ser desafiador para um produtor ge-

renciar, mas se for executado metodicamente, o desafio pode ser menor. Este
capítulo apresentou uma visão geral do processo inteiro de produção de jogos
do ponto de vista do produtor. Foram fornecidas informações gerais sobre a
pré-produção, a produção, os testes e a pós-produção de um projeto. Essas
áreas serão apresentadas com mais detalhes em capítulos subsequentes deste
livro. O próximo capítulo fornecerá uma visão geral dos papéis existentes em
uma equipe de produção. É útil considerar essas informações no contexto do
processo geral de produção de jogos.
2
PAPÉIS EXISTENTES
NA EQUIPE
Neste capítulo
• Produção • Design • Organização da equipe
• Arte • Teste de garantia da • Equipe da empresa
• Engenharia qualidade (QA)
2.1 Introdução
Para entendermos melhor o ciclo de produção, é importante saber quais são

os papéis normalmente encontrados em uma equipe de desenvolvimento
de jogos. Os papéis variam de equipe para equipe, dependendo das neces-
sidades do projeto, do tamanho da empresa e do escopo do projeto. Por
exemplo, se estiver trabalhando em um jogo de celular, a equipe pode ter
quatro pessoas, todas desempenhando vários papéis no projeto. Se estiver
trabalhando em um jogo de console de próxima geração, a equipe pode
ter mais de 80 pessoas, cada uma desempenhando um papel específico no
projeto.
Este capítulo discutirá os papéis que normalmente compõem uma equi-
pe de desenvolvimento e como as equipes são organizadas. Além disso, serão
apresentadas informações sobre funções não relacionadas à produção, como
vendas e marketing. Para obter informações mais detalhadas sobre papéis e
descrições de funções, consulte o livro Get in the Game! de Marc Mencher.
TRABALHANDO NO DESENVOLVIMENTO DE JOGOS
Wade Tinney e Coray Seifert

Large Animal Games
Se você estiver trabalhando na produção de jogos, precisa ter um conhecimento profundo

do assunto e entender por que as pessoas jogam. É surpreendente o número de pessoas
que não jogam e tentam ser contratadas por uma empresa de jogos. Você tentaria ser
contratado por um estúdio cinematográfico se não assistisse a filmes regularmente? A
pessoa deve não só jogar, mas também pensar neles criticamente. Se você não entende
a interatividade e como um determinado conjunto de opções afeta a experiência de jogo
de um jogador, provavelmente não conseguirá ajudar a equipe de desenvolvimento. Essa
habilidade de pensar criticamente a jogabilidade é particularmente importante para pro-
dutores e designers.
Os aspirantes a desenvolvedor de jogos também têm de saber interagir construti-
vamente com outros membros de uma equipe criativa. Foi-se a época em que um jogo
comercial podia ser criado por uma só pessoa. Agora é imperativo que os desenvolvedores
entendam a importância do trabalho em equipe na criação de um produto bem-sucedido.
Até mesmo a experiência de trabalho de equipe em outros segmentos criativos da indús-
tria é um bom começo; se você tiver experiência por ter trabalhado colaborativamente no
projeto de um filme, por exemplo, ou até mesmo em um projeto escolar, essa experiência
pode ajudar a prepará-lo para a indústria de jogos.
Além disso, você deve ter disciplina para concluir suas tarefas dentro de prazos aper-
tados, sem auxílio externo e, em muitos casos, com menos recursos do que gostaria. Com
frequência, equipes de desenvolvimento menores precisam que cada membro assuma di-
ferentes papéis e faça o que for necessário para o jogo ser concluído. Isso pode incluir pro-
jetar partes do jogo, tomar decisões referentes a orçamentos e cronogramas e até mesmo
criar assets gráficos. Se você conseguir se adaptar rapidamente a situações como essas,
seu lugar é na criação de jogos.
2.2 Produção
Os papéis de produção compreendem uma escala que vai do coordenador

de produção ao produtor executivo. As pessoas envolvidas na produção de
jogos se dedicam ao gerenciamento e acompanhamento do desenvolvimento
do jogo e são os principais intermediários entre a equipe de desenvolvimen-
to e qualquer pessoa de fora da equipe, até mesmo o gerente do estúdio.
Quem desempenha papéis de produção deve manter a equipe satisfeita, mo-
tivada e produtiva no projeto. Geralmente os profissionais de produção não
são responsáveis pela criação eficaz dos assets do jogo, já que sua principal
responsabilidade é gerenciar de maneira eficiente as pessoas que estão crian-
do o conteúdo. Esse gerenciamento mantém a equipe focada na conclusão
eficaz das tarefas do jogo e não no acompanhamento de cronogramas, na
2 • Papéis Existentes na Equipe 19
manipulação de questões pessoais, no gerenciamento de fornecedores ex-

ternos, na negociação de contratos, na revisão de textos de marketing e em
qualquer coisa que não faça parte da criação do conteúdo do jogo.
Existem três papéis de produção básicos, embora os nomes possam va-
riar de uma empresa para outra:
• Produtor executivo
• Produtor
• Produtor associado
Nem todos são necessários em todos os projetos, o que significa que as

responsabilidades mudam para cada papel, dependendo das necessidades do
projeto.
Produtor executivo
O produtor executivo (PE) geralmente é um produtor com cinco a dez anos de
experiência em produção. Quase sempre os PEs supervisionam vários proje-
tos e sua principal função é assegurar que todos os jogos em desenvolvimento
avancem tranquila e eficientemente. Eles se dedicam a tarefas de produção
mais genéricas – pesquisa das necessidades de hardware e middleware, es-
tabelecimento de programas de treinamento de funcionários, negociação de
contratos, avaliação de fornecedores externos e outras atividades que benefi-
ciarão os projetos atuais e futuros.
Normalmente, um PE é subordinado ao vice-presidente ou ao diretor ge-
ral (CEO) do estúdio. Ele gerencia vários produtores e trabalha com eles indi-
vidualmente para avaliar e implementar soluções para possíveis problemas
nos projetos. Não se envolve com operações cotidianas da equipe de desen-
volvimento e não se comunica com os líderes do projeto regularmente, já que
isso é responsabilidade do produtor.
Produtor
O produtor geralmente é um desenvolvedor com três a cinco anos de expe-
riência em produção e que trabalhou como produtor associado em vários pro-
dutos. Costuma ser responsável por um único jogo e por toda a equipe de
desenvolvimento desse jogo. O produtor é uma das pessoas que ficam mais
em evidência no projeto e é o representante da equipe para qualquer pessoa
de fora dela. Sua principal responsabilidade é assegurar que o jogo seja entre-
gue a tempo, conforme o orçamento, com todos os recursos esperados, com
a melhor qualidade possível, mantendo ao mesmo tempo a equipe focada e
entusiasmada com seu trabalho. Embora o produtor tenha um forte envolvi-
mento com os líderes do projeto na tomada de decisões criativas, ele tenta
principalmente facilitar o processo de desenvolvimento e não impor o con-
teúdo criativo e os recursos do jogo.
O produtor é subordinado a um produtor executivo ou ao vice-presidente
do estúdio e trabalha junto aos departamentos de marketing, vendas, opera-
ções e relações públicas (RP), ao gerente do estúdio, aos serviços de criação,

ao departamento jurídico, a fabricantes de console e a fornecedores externos.
Também gerencia o plano de desenvolvimento do jogo, divulga-o para a equipe,
acompanha-o e elimina qualquer risco à execução do plano. Basicamente, o pro-
dutor conduz a equipe de desenvolvimento à finalização do projeto.
Os produtores podem se dedicar a diferentes áreas, dependendo das neces-
sidades de seus projetos e de como suas equipes de desenvolvimento estão es-
truturadas. A divisão mais perceptível nos papéis de produção podem ser vistas
quando comparamos um produtor publicador com um produtor desenvolvedor.
Um produtor desenvolvedor (PD) gerencia diretamente uma equipe de
desenvolvimento interna. Ele trabalha junto aos líderes de arte, programação,
design e garantia da qualidade do projeto. Como núcleo da equipe, o PD e os
líderes trabalham juntos para criar o plano de desenvolvimento e atualizá-lo
quando necessário; o PD também se envolve com o cotidiano da produção do
jogo. Se estiver trabalhando para um publicador externo, o PD se comunicará
regularmente com o produtor publicador. A Figura 2.1 é um diagrama dos
principais pontos de contato de um PD.
Um produtor publicador (PP) representa os interesses do publicador e
geralmente trabalha com desenvolvedores externos. Raramente ele gerencia a
equipe de desenvolvimento real; em vez disso, supervisiona outros departa-
mentos que não estão diretamente envolvidos no ciclo interno de desenvolvi-
mento de jogos, como vendas, marketing, garantia da qualidade e localização.
O PP pode gerenciar vários projetos, principalmente se nem todos tiverem
sido agendados para ser lançados ao mesmo tempo. A Figura 2.2 é um diagra-
ma dos principais pontos de contato do PP.
Produtor
publicador
RP Artista líder
Produtor
desenvolvedor
Líder de QA Designer líder
Programador
líder
Figura 2.1 Principais contatos do produtor desenvolvedor no projeto.

Produtor
desenvolvedor
Localização Vendas e
operações
Produtor
publicador
Gerência Serviços
do estúdio de criação
Líder
Marketing e RP
de QA
Figura 2.2 Principais contatos do produtor publicador no projeto.
Podemos encontrar vários tipos de produtores em um projeto, como um

produtor de criação ou um gerente de projeto. O tipo de produtor depende do
projeto, do tamanho da equipe e das necessidades da empresa.
Produtor associado
Normalmente, o produtor associado (PA) tem de um a três anos de experiên-
cia e pode ter começado em uma posição de nível básico no desenvolvimen-
to, como testador de garantida da qualidade ou coordenador de produção.
A principal responsabilidade do PA é ajudar o produtor em qualquer tarefa
relacionada à produção. Um PA mais experiente também pode ser responsá-
vel por produzir um aspecto maior do jogo, como a localização, a música e o
voiceover, a cinemática ou testes beta abertos.
O produtor associado é subordinado diretamente ao produtor e pode ha-
ver vários em um projeto. Eles interagem com a equipe diariamente e também
podem ser incumbidos de ajudar os líderes de arte, design e engenharia quan-
do necessário.
Experiência e treinamento
Uma vez que os produtores têm tipos variados de experiência – alguns co-
meçaram no desenvolvimento de jogos e foram galgando graus na hierarquia
e outros trabalhavam em um segmento diferente da indústria e foram trans-
feridos para o desenvolvimento de jogos –, não há diretrizes fixas quanto às
habilidades que um produtor deve ter. Alguns produtores são mais técnicos
do que outros e trabalham mais efetivamente quando se dedicam a enfatizar
a tecnologia durante o desenvolvimento de jogos; outros podem ser mais
eficientes conduzindo os recursos de design do jogo. No entanto, qualquer
pessoa que trabalhe em uma posição de produção deve ter as seguintes ca-
racterísticas:
Sólidas habilidades de liderança: Essas habilidades incluem motivar

equipes e pessoas, mediar conflitos, construir consensos e fornecer a vi-
são condutora do jogo do início ao fim.
Boas habilidades de comunicação: Toda a comunicação deve ser clara,
diplomática e oportuna. Essas aptidões incluem a habilidade de dar más
notícias de uma maneira delicada, oferecer feedback construtivo e res-
ponder qualquer pergunta de maneira direta.
Habilidades organizacionais altamente desenvolvidas: Essas habilida-
des incluem a criação de cronogramas, a delegação de tarefas e o acom-
panhamento de todos os pequenos detalhes do projeto. O conhecimento
de princípios de gerenciamento de projetos é extremamente útil.
Desejo de trabalhar com (e para) os outros: Acima de tudo, o produtor
existe para servir a equipe, e não o contrário. A equipe está criando o
conteúdo do jogo e o produtor deve criar um ambiente de trabalho que
permita que ela dê o máximo de produtividade. O produtor deve es-
tar sempre disponível para ouvir reclamações, sugestões e perguntas da
equipe e lidar com elas de uma maneira positiva e compreensiva. A pro-
dução não é lugar para alguém que não goste de trabalhar com pessoas.
Embora haja algum treinamento disponível para produtores de jogos, es-

ses programas são raros. Mas há várias áreas às quais um produtor pode se
voltar para desenvolver essas habilidades:
Conhecimento da indústria de jogos: Mantenha-se atualizado quanto

às tecnologias e tendências mais recentes da indústria, converse com
outros desenvolvedores e jogue jogos.
Treinamento em gerenciamento de projetos: Faça alguns cursos de ge-
renciamento de projetos, ou, ainda melhor, torne-se um gerenciador de
projetos ou mestre de Scrum certificado. O Capítulo 3, “Métodos de ge-
renciamento de projetos”, a Parte V, “Pré-produção”, e a Parte VI, “Produ-
ção”, fornecem informações adicionais sobre gerenciamento de projetos.
Treinamento em gerenciamento de pessoas: Aprenda como gerenciar
e motivar de maneira eficaz as pessoas. Vários livros e cursos fornecem
informações valiosas sobre como gerenciar um grupo variado de pessoas.
A Parte III deste livro, “Gerenciando pessoas”, discutirá o gerenciamento
com mais detalhes.
Experiência em falar em público: Ganhe mais confiança para falar
em reuniões da equipe fazendo um curso de oratória. A Toastmasters
(www.toastmasters.org), por exemplo, é uma organização sem fins lu-

crativos em que as pessoas se encontram para praticar habilidades de
oratória e liderança.
HABILIDADES DO PRODUTOR
Stephanie O’Malley Deming, produtora

Xloc
O produtor deve ser um bom diplomata e ter habilidade para se comunicar com pessoas
de todos os níveis, de um criador de texturas ao vice-presidente do estúdio. Ele deve des-
cobrir o que motiva cada pessoa da equipe e usar esse conhecimento para fazer todos se
entusiasmarem com suas tarefas. Boas habilidades organizacionais e aptidão para execu-
tar várias tarefas são importantes.
Uma pessoa que quiser ser produtora deve começar de baixo, como coordenador de
produção, designer assistente ou testador de QA, e construir seu caminho para ascender
na hierarquia. Ganhe o máximo de experiência prática que puder, porque experiência con-
ta muito. Estar em campo ajudará a entender como e por que as decisões são tomadas
e permitirá que você preveja possíveis problemas no cronograma de produção. Também
dará traquejo para liderar e conversar de maneira embasada com os desenvolvedores de
sua equipe e assegurar que as melhores decisões sejam tomadas para os aspectos de de-
sign, engenharia e arte do jogo. Após se tornar um produtor, você terá muitas experiências
diferentes em que se basear e saberá que processos funcionarão melhor.
2.3 Arte
Os artistas são responsáveis por criar todos os assets gráficos do jogo – perso-
nagens, cinemática, veículos, prédios e níveis –, e à medida que a tecnologia
melhora, a qualidade dos assets deve acompanhar os avanços, principalmente
na próxima geração de hardware. Essas máquinas têm mais memória, poder
de processamento e espaço de armazenamento, o que dá aos artistas a oportu-
nidade de criar objetos altamente detalhados, ambientes terrestres e aquáticos
de aparência realista e efeitos especiais para explosões e condições climáticas
comparáveis às do mundo real.
Os artistas trabalham junto aos designers para definir os objetos, os
mundos e a cinemática que serão necessários e também trabalham com a
engenharia para determinar como a tecnologia pode ser usada de maneira
mais eficaz no pipeline de produção de arte. Se inúmeros assets gráficos
tiverem de ser criados, é provável que o número de artistas ultrapasse o
de outros membros da equipe em uma proporção de dois para um. Cada
equipe pode ter diferentes nomes para os cargos de criação artística de uma
equipe de desenvolvimento. Os cargos básicos de criação artística são os

seguintes:
• Diretor de arte
• Artista líder
• Artista conceitual
• Construtor de mundos ou designer de níveis
• Criador de assets
• Animador
• Artista técnico
• Artista de marketing
Diretor de arte
A principal função do diretor de arte é divulgar a visão artística para a equipe.
Essa pessoa é habilitada em todos os aspectos da criação de arte digital e é res-
ponsável por assegurar que os assets gráficos estejam relacionados uns com
os outros dentro do jogo. Um diretor de arte é um artista muito habilitado e
respeitado que tem de cinco a dez anos de experiência. Nem todos os projetos
terão um diretor de arte na equipe.
Artista líder
O artista líder trabalha junto ao diretor de arte para assegurar que a visão
artística seja mantida em todo o processo de desenvolvimento. Ele gerencia
a qualidade dos assets gráficos e as tarefas diárias da equipe e é um interme-
diário entre o diretor de arte e a equipe de criação artística. Essa mediação
permite que o diretor de arte se dedique aos aspectos de criação do jogo, em
vez de gerenciar o pessoal. Se a equipe não tiver um diretor de arte, o artista
líder assumirá a responsabilidade pela definição da visão artística. O artista
líder é um artista experiente e respeitado com pelo menos três a cinco anos de
experiência em desenvolvimento de jogos.
Artista conceitual
Os artistas conceituais são visionários. Eles são responsáveis por criar os con-
ceitos de todos os assets gráficos antes que estes sejam produzidos. São habi-
litados em arte 2D, desenho tradicional e métodos de pintura, e às vezes em
arte 3D. Trabalham diretamente com o diretor de arte na criação e documen-
tação da visão artística do jogo.
Construtor de mundos ou designer de níveis

Os construtores de mundos são responsáveis por construir a geometria e criar
as texturas do mundo do jogo. Eles são habilitados em arte 2D e 3D e conhe-
cem o design de níveis. Em algumas empresas, esse cargo é considerado um
cargo de design, já que a jogabilidade é fortemente afetada pela maneira como

o mundo do jogo é projetado.
Criador de assets
O criador de assets também tem habilidades artísticas em 2D e 3D, mas é
responsável pela criação dos assets que aparecem no mundo do jogo. Esses
assets incluem coisas como personagens, armas, veículos, acessórios, telas
de interface de usuário e qualquer outro asset necessário. Alguns criadores
de assets se especializam em um tipo específico de asset, como, por exemplo,
veículos.
Animador
Os animadores são responsáveis por criar todas as animações cinemáticas e
in-game. Eles precisam ter experiência em animação 2D e 3D tradicional. No
entanto, a animação 3D é mais desejável para o desenvolvimento de jogos,
principalmente se quisermos nos beneficiar das tecnologias mais recentes.
Artista técnico
Os artistas técnicos gerenciam o lado técnico da criação de assets, como a
criação de volumes de colisão, a garantia de que os objetos sejam exportados
corretamente e a aplicação de atributos físicos a um objeto. Eles trabalharão
junto à engenharia nas ferramentas gráficas e no pipeline da arte e, portanto,
precisam ter conhecimento técnico suficiente para se comunicar com os pro-
gramadores.
Artista de marketing
Os artistas de marketing criam todos os recursos de marketing do jogo. Essas
atividades incluem capturar tela do jogo, filmar vídeos da mecânica do jogo,
criar arte de alta resolução, bolar a embalagem e tudo o mais que o departa-
mento de marketing precisa para promover o jogo. Geralmente, esses artistas
são habilitados em arte 2D, com algum conhecimento de arte 3D.
A experiência e o treinamento necessários para um artista criador de jogos são
bem claros. Em geral, um artista deve ter habilidade artística e conseguir ex-
pressá-la através das formas artísticas tradicionais, como a pintura, o desenho
e a escultura. Outro componente crucial é saber como usar software 2D ou 3D
para criar assets. A maioria das universidades ou escolas de arte oferece aulas
de uso do software, portanto, essa barreira não é difícil de superar.
Também é bom que os artistas conheçam a indústria de jogos, já que a
tecnologia está sempre mudando e afetando a maneira como a arte pode ser
usada no jogo. Se os artistas acompanharem essas mudanças, poderão trazer

esse conhecimento para os jogos em que trabalharem e continuar melhorando
os elementos gráficos à medida que a tecnologia evoluir.
Para concluir, os artistas devem ter sólidas habilidades de comunicação,
porque se comunicarão com os designers, os programadores e o pessoal de
produção de uma equipe. Uma comunicação eficaz tornará o trabalho de to-
dos mais fácil no projeto.
HABILIDADES ARTÍSTICAS
Carey Chico, diretor de arte

Pandemic Studios
Os artistas de criação de jogos precisam ter muita experiência em trabalhar frente a uma
folha de papel vazia, já que isso é essencial para estimular a mente. Também devem saber
como desenhar usando os métodos tradicionais de desenho, como caneta e tinta. Devem
aprender a usar as ferramentas existentes no mercado, o que inclui as ferramentas de pin-
tura em 2D e de criação de conteúdo em 3D. Para concluir, devem obviamente ter algum
conhecimento técnico, já que a indústria de jogos é extremamente técnica, e é essencial que
possam se comunicar com os profissionais técnicos e de criação.
Uma maneira de começar a trabalhar como artista de criação de jogos é se envolver
em uma comunidade de modding. A comunidade de modding usa editores de nível de um
jogo específico para criar novos assets, níveis e missões do jogo. Quando os mods estão
concluídos, geralmente os criadores os oferecem como downloads gratuitos. Há vários
editores de nível (como o Unreal) prontamente disponíveis, que aspirantes a artistas de
criação de jogos podem usar para desenvolver e demonstrar suas habilidades. Os níveis
modificados podem ser o começo de um portfólio de arte de jogos que pode ajudar o
aspirante a fazer uma empresa de desenvolvimento se interessar.
2.4 Engenharia
Os programadores lidam com todos os aspectos do jogo – elementos gráfi-

cos, animação, ferramentas de criação de scripts, aspectos físicos, interface de
usuário (IU), som e outros – e são responsáveis por criar todo o código que faz
o jogo funcionar. Eles devem começar com os documentos de design, definir
a funcionalidade necessária, escrever o código que cria a funcionalidade e
então revisá-lo de acordo com o feedback. Também trabalham junto à equipe
de arte para determinar as necessidades técnicas de arte do jogo.
A engenharia de jogos é muito diferente da engenharia de software co-
mercial, principalmente no que diz respeito à alta prioridade dada à criação de
um pacote de software para entretenimento. Geralmente, os programadores de
jogos têm paixão por jogos e conhecem as habilidades exclusivas requeridas

pelo cargo. Eles têm de trabalhar bem com profissionais de criação, gerentes e
outros programadores do projeto para que a equipe possa concretizar a visão do
jogo. Os papéis básicos de engenharia de um projeto de jogo são os seguintes:
• Diretor técnico
• Programador líder
• Programador
Diretor técnico
O diretor técnico é a contrapartida do diretor de arte. Ele deve conhecer as
tecnologias mais recentes e determinar como melhor utilizá-las no código do
jogo. Esses profissionais dedicam parte de seu tempo à pesquisa e desenvol-
vimento e são os principais responsáveis pela definição dos padrões de codi-
ficação, determinação das tecnologias que serão usadas no jogo, codificação
e manutenção de bibliotecas, e assim por diante. Nem todos os projetos têm
um diretor técnico. Ele deve ser um programador experiente com pelo menos
cinco a dez anos de experiência.
Programador líder
O programador líder é responsável por gerenciar as tarefas diárias da equipe.
Também trabalha junto ao diretor técnico para determinar que tecnologias se-
rão necessárias no jogo. Ele pode ou não ter a chance de trabalhar realmente no
código do jogo, já que isso vai depender do quanto estiver ocupado com o ge-
renciamento dos programadores. Se não houver um diretor técnico na equipe, o
programador líder será responsável por definir os padrões técnicos do jogo. Um
programador líder tem de três a cinco anos de experiência, conhecimento geral
em todas as áreas da tecnologia de jogos e boas habilidades de comunicação.
Programador
“Programador” é um título genérico para um papel que pode ter muitas varia-
ções dentro de uma equipe de desenvolvimento. Muitos programadores de jo-
gos são versados em várias áreas da programação, mas costumam se dedicar a
uma ou duas especializações. No entanto, têm de ser suficientemente flexíveis
para sair de suas áreas de especialização e trabalhar em outras se necessário.
Algumas áreas básicas de engenharia existentes em uma equipe de de-
senvolvimento são as seguintes:
Programador de rede: É responsável por criar o código multijogador.
Essa pessoa trabalha junto ao designer de ambientes multijogador para
assegurar que todas as funcionalidades de mecânica de jogo necessárias
tenham suporte.
Programador de som: O programador de som se dedica à criação do
mecanismo de som do jogo. Essa pessoa trabalha junto ao designer de
som para assegurar que o mecanismo sonoro consiga suportar os recur-

sos de som desejados no jogo.
Programador gráfico: O programador gráfico é responsável por criar o
código gráfico. Essa pessoa trabalha junto ao artista técnico nas ferra-
mentas gráficas e no pipeline de produção de arte.
Programador de ferramentas: O programador de ferramentas é res-
ponsável por criar as ferramentas proprietárias usadas durante o desen-
volvimento do jogo. Entre elas, podemos citar as ferramentas de script,
iluminação, localização e exportadores, e qualquer outra que possa ser
codificada para otimizar o pipeline de produção do jogo. Esse profissio-
nal trabalhará com várias pessoas diferentes da equipe para saber que
ferramentas são necessárias.
Programador de IA: O programador de IA lida com os comportamentos
de inteligência artificial (IA) do jogo. Essa pessoa trabalha junto à equipe
de design para identificar que comportamentos e funcionalidades são
necessários para os personagens do jogo.
Muitos programadores de jogos são formados em ciência da computação,
mas também há os autodidatas. Independentemente do caminho tomado, os
programadores de jogos precisam conhecer linguagens de programação, sis-
temas operacionais, compiladores, depuradores e interfaces de programação
de aplicativos (APIs). Após serem instruídos nessas áreas básicas, eles devem
pesquisar continuamente as tecnologias mais recentes e entender como elas
afetam seu trabalho. As tecnologias de jogos mudam constantemente e novas
plataformas sempre surgem a cada três ou quatro anos.
Como os artistas e o pessoal de produção, os programadores também devem
conhecer a indústria de jogos e querer criar e jogar jogos. Além disso, precisam
ter sólidas habilidades de comunicação e capacidade de trabalhar em um am-
biente baseado em equipe e de se relacionar bem com vários tipos de pessoas.
HABILIDADES DE ENGENHARIA
Tobi Saulnier, presidente

1st Playable
Software de jogos está ficando mais complicado e sofisticado em termos de linhas de

código e complexidade matemática. Isso significa que os programadores devem conhecê-
-los mais ampla e profundamente do que seria viável para um autodidata. Duas das áreas
mais importantes em que os programadores de jogos trabalham são o mecanismo básico

do jogo e o código que é executado acima dos principais recursos fornecidos pelo meca-
nismo.
O programador que estiver trabalhando no mecanismo básico de um jogo de con-
sole tem de ser um bom codificador de assembly e se sentir confortável trabalhando com
hardware e compiladores. As áreas em que eles podem trabalhar incluem renderização,
criação de efeitos, física e iluminação. O objetivo é fazer o código ser executado mais
rapidamente e mais elementos gráficos serem canalizados através da memória, em alguns
sistemas muito idiossincráticos. Essa pessoa também deve conhecer o uso de memória
e CPU – especificamente para mecanismos de jogos – e se sentir confortável cruzando a
fronteira entre software e hardware. O programador também precisará ter muita paciên-
cia, porque se estiver trabalhando com hardware novo (o que geralmente é o caso no de-
senvolvimento de jogos), os compiladores e outras ferramentas terão bugs e não estarão
maduros. E quando os compiladores estiverem maduros, o hardware terá mudado.
O programador que estiver trabalhando em códigos específicos de jogos deve enten-
der e saber implementar o gerenciamento do estado do jogo, algoritmos de manipulação
de personagens, IA e outros comportamentos do jogo. Essa área também está ficando
muito complexa, principalmente com as plataformas tendo cada vez mais poder de pro-
cessamento. O programador, portanto, tem de conseguir trabalhar com especificações
inconstantes, porque muitos dos comportamentos que ele estiver implementando serão
ajustados durante o processo de produção. Com frequência, essas alterações só são iden-
tificadas após o jogo chegar a um estado suficientemente jogável a ponto de algum teste
poder ser executado e os designers constatarem que os comportamentos não estão crian-
do uma experiência divertida.
Jogos grandes têm nichos em áreas como rede e programação sonora que passam a
ser extensas demais, a ponto de o programador trabalhar em apenas uma delas no proje-
to inteiro. Outros programadores são importantes no trabalho junto aos profissionais de
design e arte, como criadores de scripts de IA, de shaders para artistas e de ferramentas
que acelerem os gargalos da produção. Esses programadores têm experiência técnica,
mas na maioria das vezes trabalham com os profissionais de criação que não têm envol-
vimento com o software, portanto, será útil se eles também tiverem alguma experiência
em arte ou design.
Basicamente, as empresas procuram programadores facilmente adaptáveis com uma
sólida experiência em engenharia como base. É importante que o programador aprenda rá-
pido para poder se alternar entre tarefas, se adaptar às necessidades de um jogo específico
ou ajudar em uma área que tenha se tornado o caminho crucial de um projeto específico.
Dependendo do tamanho da equipe, por exemplo, o programador poderia estar codifi-
cando a IA de um projeto e então ter de codificar o sistema de animação de outro projeto.
Além disso, os programadores têm de ser capazes de trabalhar com o código de outras
pessoas e, é claro, escrever códigos em que outras pessoas consigam trabalhar. Os jogos
requerem modificações no código de um projeto para outro, o que significa que diferentes
programadores trabalharão no código-base. Com os sistemas mais recentes, seria muito
incomum podermos nos dar ao luxo de construir um jogo a partir do zero.
2.5 Design
Os designers têm um amplo conjunto de responsabilidades em uma equipe de

desenvolvimento, como projetar o esquema de controle do jogo, criar os his-
tóricos e as personalidades dos personagens e projetar o sistema de combate.
Resumindo, eles são responsáveis por criar uma experiência de jogo atraente
e imersiva. Para atingir esse objetivo, devem trabalhar junto aos artistas e pro-
gramadores para determinar como a arte e a tecnologia podem ser usadas de
modo a tornar o jogo mais realista.
Os designers trabalham no processo de produção do início ao fim. Na
pré-produção, eles discutem e simulam possíveis ideias de jogabilidade e en-
tão documentam as que funcionarão melhor dentro dos limites do jogo. Du-
rante a produção, implementam o design do jogo, o que inclui criar missões,
redigir diálogos e testar o jogo. Suas tarefas também incluem incorporar feed-
back e projetar novamente certos aspectos do jogo quando necessário. Além
disso, os designers devem trabalhar cooperativamente com os outros mem-
bros da equipe em todo o processo de desenvolvimento. Os cargos básicos de
design em uma equipe de desenvolvimento são os seguintes:
• Diretor de criação
• Designer líder
• Designer
• Redator
Diretor de criação
Cada equipe de desenvolvimento interpretará o papel e a responsabilidade
de um diretor de criação de maneira diferente. Normalmente, o diretor de
criação é responsável por comunicar a visão geral de concepção do jogo para
a equipe e assegurar que essa visão seja passada a cada aspecto do jogo.
Para ter sucesso nesse cargo, o diretor de criação deve interagir com vá-
rios membros diferentes da equipe. A Figura 2.3 é um diagrama dos tipos de
interações que um diretor de criação deve estabelecer em um projeto. As in-
terações giram em torno dos membros que são diretamente responsáveis por
gerar assets gráficos. O diretor de criação deve assegurar que os ambientes,
os personagens, a música, o diálogo e a jogabilidade operem em conjunto
para formar um todo coeso. É importante ressaltar que o diretor de criação
não assume o papel do diretor de arte e, em vez disso, trabalha com ele na
determinação da aparência do jogo. Nem todos os projetos têm diretores de
criação. Geralmente, a pessoa que ocupa esse cargo tem de cinco a dez anos
de experiência na área e já trabalhou como designer líder em vários produtos.
Designer líder
O designer líder é responsável por gerenciar as tarefas diárias da equipe de
design e atuar como intermediário entre o diretor de criação e os designers.
Redator
Designer
Designer líder
de som
Diretor de
criação
Construtores Artista
de mundos conceitual
Produtor
Figura 2.3 Principais contatos do diretor de criação no projeto.
Ele conduz a equipe de design na documentação dos conceitos de design,

na criação de protótipos de jogabilidade, na implementação de recursos de
design, no balanceamento da jogabilidade e na recriação de recursos quan-
do necessário. Se a equipe não tiver diretor de criação, o designer líder
será responsável por comunicar a visão de concepção do jogo. Geralmente,
um designer líder tem pelo menos de três a cinco anos de experiência em
design.
Designer
“Designer” é um título genérico para um papel que tem diferentes funções
em uma equipe. O designer é responsável por criar, simular, implementar e
balancear diferentes áreas do jogo, dependendo de sua experiência. Alguns
tipos de designers encontrados em uma equipe são os seguintes:
Designer de sistemas: Essa pessoa projeta os componentes de sistema
da jogabilidade. Alguns exemplos seriam o sistema de pontuação, o
modelo de combate, o esquema de controle e o sistema de criação de
personagens.
Designer de IU: Essa pessoa projeta a Interface de Usuário (IU) do jogo,
o que inclui como as telas da IU funcionarão e estarão relacionadas.
Designer de níveis: Também conhecido como construtor de mundos,
essa pessoa cria os layouts dos níveis do jogo. Alguns desenvolvedores
consideram essa atividade como um papel da área artística em vez de
pertencer ao design. Em alguns casos, o designer cria os designs dos

níveis em papel e então um artista constrói os níveis.
Roteirista: Essa pessoa insere os objetos e inimigos interativos nos ní-
veis. Essencialmente, ela controla quantos inimigos um jogador encon-
trará, onde os desafios de jogabilidade aparecerão em um nível, como
personagens que não forem do jogador interagirão com o personagem do
jogador, e assim por diante.
Redator
O redator é responsável por criar os elementos da história, os personagens
e o diálogo do jogo. Ele interage com o designer líder e/ou com o diretor de
criação para assegurar que esses elementos estejam de acordo com a visão
de concepção do jogo. Também redige textos de marketing e RP, o conteúdo
do site, o manual e qualquer outra coisa que precisar ser escrita relacionada
ao jogo. Os redatores devem ter experiência em redação criativa e em redigir
para mídia interativa.
Como no caso dos produtores, não existem regras claramente definidas com
relação às habilidades que um designer deve ter. Os designers vêm de vários
tipos de experiência sem uma trajetória profissional padrão. Eles precisam
ter sólidas habilidades de comunicação, tanto escrita quanto verbal, porque
precisam expressar com clareza conceitos abstratos de criação para uma equi-
pe inteira de pessoas e guiar essas pessoas na materialização das ideias. Os
designers conhecem várias teorias de jogos e jogam muito. Basicamente, eles
devem ser receptivos e ter uma ideia do que o jogador acha divertido e inte-
ressante.
HABILIDADES DE DESIGN
Clint Hocking, diretor de criação

Ubisoft
O design de jogos é um campo tão novo que ainda não há um caminho específico para se
seguir. Nessa função, você tem de conseguir enxergar tanto o aspecto de design do sistema
quanto o aspecto de design da experiência. Até onde sei, não há um meio realmente eficaz
de receber treinamento nas duas áreas.
O melhor conselho que posso dar a alguém que quer ser um designer de jogos é
receber uma educação ampla. Entre em uma boa escola de ciências humanas, ou em uma
boa escola de engenharia onde o ensino interdisciplinar seja enfatizado. Forme-se em ciên-
cia da computação, mas faça disciplinas de belas-artes ou o contrário. Enquanto estiver
estudando, trabalhe em jogos e jogue. Projete jogos de RPG com papel e caneta, jogos de
tabuleiro, jogos de cartas, jogos baseados na Web ou aventuras em texto, faça um filme
independente para aprender como trabalhar em situações desfavoráveis com pequenas
equipes de pessoas com diferentes habilidades e técnicas artísticas – qualquer coisa que
você puder fazer para adquirir uma experiência ampla e diversificada trabalhando com
profissionais tanto técnicos quanto de criação será útil.
Após trabalhar algum tempo na comunidade de modding e lançar um nível para um
mod do Unreal chamado “Strike Force”, comecei minha carreira na indústria de jogos como
designer de níveis no Splinter Cell. Meu nível acabou sendo selecionado para ir para a E3,
onde fizemos muito sucesso, e meu outro nível acabou sendo o nível demo do jogo na OXM.
Durante o desenvolvimento do Splinter Cell, o designer do jogo abandonou o projeto
na etapa Alfa e fui chamado para assumir o lugar dele. O redator também deixou o pro-
jeto, e já que tenho mestrado em redação criativa, e tinha trabalhado junto ao redator,
fui solicitado a assumir essa tarefa também. Ao começar a trabalhar no Splinter Cell: Chaos
Theory, assumi o papel duplo de chefe de designers de níveis e redator de roteiro. Quando
estávamos aproximadamente no meio do projeto, também assumi o cargo de diretor de
criação. Tem sido como uma montanha-russa, e tive muita sorte de estar no lugar certo
na hora certa.
Em equipes de desenvolvimento, os papéis desempenhados pelos vários designers
são definidos e variam de acordo com seus talentos específicos. Eu mesmo fui designer de
níveis, líder de designers de níveis, designer de jogos, redator/designer, diretor de criação…
Trabalhei com designers muito metódicos e orientados a processos, designers muito vol-
tados à criação e alguns muito técnicos.
Atualmente, estou na pré-produção como diretor de criação. Trabalho diretamente
com o programador líder, o produtor e o gerente de marketing. Abaixo de mim estão os
líderes de criação, o designer do jogo, o diretor de arte, o líder dos designers de níveis, o
redator etc. Portanto, no nível superior, o diretor de criação tem muita influência sobre
o conceito do jogo, e no nível abaixo, o designer do jogo tem tanta influência quanto os
outros líderes de criação. Em projetos menores, o designer do jogo pode ser equivalente
ao diretor de criação.
O designer de níveis é responsável por entregar um nível, o roteirista por entregar um
código funcional e o redator/designer por entregar roteiros. Profissionais que atuem “ex-
clusivamente” como designers de jogos podem ser responsáveis por trabalhar com testes
de foco e distribuir os relatórios de cada teste, conversar com o designer de níveis sobre o
que significam os relatórios e distribuir uma documentação que ilustre o plano de acom-
panhamento para o produtor ou o diretor de criação. Certos designers, como o diretor
de criação, o líder dos designers de níveis ou o designer do jogo, serão responsáveis por
jogar o jogo constantemente, distribuir avaliações periódicas do conteúdo, comentários
e críticas, e tarefas para os designers de níveis para que eles possam melhorar seus níveis.
Geralmente, o profissional de criação mais experiente do projeto tem muita influên-
cia nos estágios iniciais. No começo há muita liberdade para ser criativo, mas quanto mais
se avança, menos liberdade se tem e mais restrições são adotadas. Perto do fim do proje-
to, o líder de criação quase não interfere, e nos últimos dias antes da entrega, o programa-
dor líder é que gerencia tudo. De certa forma, a “influência” migra da área de criação para
a técnica com o passar do tempo a um ritmo imposto pelo produtor.
Como regra geral, os melhores designers – líderes ou não – têm uma coisa em co-
mum. Todos eles conseguem ver os sistemas, o conteúdo e a experiência (ou qualquer as-
pecto do design a que se dedicarem) do ponto de vista do jogador. Os melhores designers
são capazes de abrir mão da direção específica que adotam para a experiência e o design
para facilitar para o jogador se expressar no espaço interativo. Diferente de outras áreas
de criação, onde o criador tem muito controle autoral sobre sua criação, os designers de
jogos não criam experiências específicas; eles são facilitadores que dão às pessoas a opor-
tunidade de se envolverem com um conjunto significativo de experiências. É difícil entender
isso e abrir mão do controle autoral, mas é algo crucial para nos tornarmos bons designers.
2.6 Teste de garantia da qualidade
Os testadores de garantia da qualidade (QA) são uma parte vital do processo

de desenvolvimento de jogos e lidam com o teste exploratório (play testing) e
a busca de defeitos no jogo. Geralmente, os testadores começam seu trabalho
na fase de produção, após as builds jogáveis do jogo estarem disponíveis. Eles
participam do processo de desenvolvimento até o fim e com frequência são as
últimas pessoas a concluírem seu trabalho no jogo. Os testadores trabalham
junto a todos os membros da equipe de desenvolvimento e constituem um
bom meio de testarmos protótipos e novos recursos. Os papéis básicos da
execução de testes são os seguintes:
• Líder de testadores de QA
• Testador de QA
Líder de testadores de QA
O líder de testadores de QA trabalha junto ao produtor e outros líderes de um
projeto para avaliar os recursos do jogo do ponto de vista da execução de tes-
tes. Por exemplo, se o jogo for usar 50 variáveis na criação de um personagem,
o líder de testadores de QA estimará quanto tempo levará o teste dessas variá-
veis e provavelmente sugerirá que a quantidade seja reduzida para diminuir o
tempo de teste. Essa recomendação pode ser feita porque as combinações dos
testes de diferentes variáveis podem consumir rapidamente um tempo valioso
necessário ao teste de outras áreas do jogo. Ele também determina, junto com
o produtor e os líderes, quando o jogo está pronto para ter seu código liberado.
O líder de testadores de QA é responsável por redigir o plano de testes
do jogo. Para fazer isso, deve saber exatamente como cada parte do jogo fun-
ciona, de modo que esses detalhes possam ser incluídos no plano de testes.
Para concluir, ele gerencia todos os testadores e atribui a eles áreas específicas
do plano de testes para verificarem. Um líder de testadores de QA deve ter de

dois a três anos de experiência como testador de QA.
Testador de QA
Os testadores de QA são responsáveis por verificar a funcionalidade do jogo
em relação ao plano de testes, testar novos recursos e protótipos e encontrar
defeitos no software do jogo. Além disso, verificam se o jogo atende todos os
requisitos técnicos do fabricante do console. Eles passam grande parte de seu
dia de trabalho jogando o jogo e, portanto, têm opiniões embasadas sobre o
fator diversão como um todo.
Não há treinamento formal para um cargo de testes. Em geral, os testadores
são pessoas que gostam de jogar jogos e têm habilidade para analisar proble-
mas e determinar sua causa. Os testadores devem ter boas habilidades de co-
municação oral e escrita para poderem descrever claramente um bug para um
desenvolvedor. Os líderes dos testadores também devem ter boas habilidades
organizacionais e de comunicação, já que são responsáveis por gerenciar uma
equipe de pessoas.
O departamento de testes é um local adequado para quem quer entrar na
área de desenvolvimento de jogos, pois os testadores são expostos a todos os
aspectos do desenvolvimento. Eles também se comunicam diretamente com
os desenvolvedores todo dia.
2.7 Organização da equipe
A hierarquia da equipe pode ser organizada de várias maneiras, dependen-

do do tamanho da equipe e dos papéis a serem desempenhados. Empresas
pequenas podem ter uma só pessoa desempenhando vários papéis em um
projeto, como produtor-designer líder, e empresas grandes podem ter pes-
soas com uma função claramente definida, como criador de IU ou programa-
dor de IA. Independentemente do tamanho da equipe, uma hierarquia clara
deve ser estabelecida para as pessoas saberem com quem falar para obter
informações.
A Figura 2.4 mostra o organograma geral de uma equipe pequena típica
com uma estrutura produtor/líder. O produtor gerencia os líderes de arte, en-
genharia, design e QA e os líderes gerenciam o resto da equipe de desenvolvi-
mento. Com a equipe organizada dessa maneira, ainda é possível uma única
pessoa desempenhar vários papéis, mesmo que possa causar algum conflito.
Por exemplo, Wade Tinney é produtor/designer líder na Large Animal Games.
Às vezes ele vê seu lado produtor discordar de seu lado designer, principal-
mente quando envolve adicionar mais tempo ou dinheiro ao projeto.
Produtor
Artista líder Programador líder Designer líder Líder de QA
Artistas Programadores Designers Testadores de QA
Figura 2.4 Equipe pequena com estrutura produtor/líder.
A Figura 2.5 é um organograma de uma equipe maior. Essa estrutura

ainda segue o modelo produtor/líder, mas agora setores especializados são
visíveis em cada área de atuação. Em uma estrutura como essa, um progra-
mador de rede subordinado ao programador líder pode ser responsável por
vários outros programadores de rede. Além disso, um produtor associado foi
incluído nessa equipe para ajudar o produtor no gerenciamento diário das
tarefas de produção.
Produtor
Produtor
associado
Programador
Artista líder Designer líder Líder de QA
líder
Construtores Programadores Testadores

Designers
de mundos de rede de QA
Artistas Programadores Teste de

Redatores
conceituais de ferramentas requisitos
Programador Designers
Artistas técnicos
de IA de som
Programador
Animadores Roteiristas
de som
Programador
gráfico
Figura 2.5 Equipe grande com estrutura produtor/líder.
A Figura 2.6 mostra o organograma de uma equipe encabeçada por um

produtor executivo e diretores em cada área de atuação. Essa estrutura costu-
ma ser mais comum em equipes de desenvolvimento maiores. Nessa estrutura
específica, tanto o produtor quanto o diretor de criação se reportam direta-
mente ao produtor executivo. O produtor é responsável por gerenciar todo o
Produtor executivo
Produtor Diretor de criação
Produtor associado
Diretor de arte Diretor técnico Designer líder Líder de QA
Artista líder Programador líder Designers Testadores
Artistas Programadores
Figura 2.6 Equipe estruturada com produtor executivo.
pessoal da equipe e o diretor de criação por gerenciar a visão de concepção

do jogo. Essa estrutura de subordinação pode ser diferente para cada equipe
de desenvolvimento.
Essa estrutura também indica que os líderes são os intermediários entre
os diretores e o resto da equipe. Além disso, um coordenador de produção
foi adicionado para ajudar o produtor em tarefas cotidianas. Isso é particular-
mente útil quando o produtor associado está gerenciando várias áreas do jogo,
como localizações e gravações de voiceover.
2.8 Equipe da empresa
Qualquer lista de créditos completa inclui o agradecimento a todas as pessoas

da empresa que participaram da criação e do lançamento de um jogo bem-
-sucedido. Geralmente, as pessoas que desempenham esses papéis trabalham
para o publicador e são responsáveis pela criação da embalagem, da campa-
nha de marketing, do plano de vendas e de tudo o mais que complemente o
jogo propriamente dito. Normalmente, elas têm contato com o produtor e são
tratadas como membros externos da equipe de desenvolvimento. Esses depar-
tamentos são os seguintes:
• Marketing e relações públicas

• Serviços de criação
• Vendas
Marketing e relações públicas

A principal responsabilidade do departamento de marketing é vender o jogo
para o público-alvo. Seu desafio é construir uma campanha de marketing
atraente baseada nos recursos, na história e na mecânica do jogo que induza

os jogadores a querer comprá-lo. Para serem mais efetivos, os profissionais de
marketing devem ser envolvidos no jogo durante a pré-produção. Esse envol-
vimento lhes dará a oportunidade de sugerir recursos e outras maneiras de
tornar o jogo mais vendável. Por exemplo, eles podem sugerir o uso de música
licenciada de uma banda popular, o emprego de vozes de celebridades ou a
inclusão de algum novo recurso de jogabilidade exclusivo.
O departamento de relações públicas (RP) é responsável por gerar pu-
blicidade para o jogo através de sites, revistas e comerciais de televisão. Esse
processo inclui marcar entrevistas com a equipe de desenvolvimento e or-
ganizar press tours para o jogo. Além disso, eles criam eventos publicitários
exclusivos para os jogadores fazerem perguntas sobre o jogo. Os departamen-
tos de marketing e relações públicas trabalham integrados para garantir que
ambos apresentem uma visão unificada do jogo para o público-alvo. Consulte
o Capítulo 13, “Marketing e relações públicas”, para obter mais informações.
Serviços de criação
O departamento de serviços de criação trabalha junto ao departamento de
marketing para criar a embalagem e o manual do jogo. Após a aparência da
embalagem ter sido definida, eles geram os recursos necessários, criam o
layout final e coordenam a impressão de todos os materiais.
Já que o produtor está mais familiarizado com o jogo do que alguém do
departamento de serviços de criação, espera-se que ele forneça o texto do
manual, as capturas de tela (screen shots) e outros recursos do jogo para os
materiais impressos. Consulte o Capítulo 13, “Marketing e relações públicas”,
para obter mais informações sobre o processo de criação da embalagem e do
manual.
Vendas
O departamento de vendas é responsável por vender o jogo para lojas varejis-
tas, como Walmart, EB Games e Best Buy, e para fornecedores on-line, como o
Direct2Drive do grupo IGN. Eles também determinam se edições especiais do
jogo serão criadas para aumentar as vendas. Por exemplo, poderia ser criada
uma edição especial do jogo incluindo material de divulgação, um guia estra-
tégico e outros bônus.
Com tantas pessoas envolvidas na criação de jogos, o produtor deve conhecer

os papéis e responsabilidades de todos na equipe. Este capítulo apresentou
uma visão geral dos papéis de produção, arte, engenharia, design, testes e da
corporação encontrados em uma equipe, e discutiu rapidamente a experiên-

cia e o treinamento necessários para o seu desempenho.
Tendo um conhecimento claro dos papéis existentes na equipe, o produ-
tor pode decidir que estrutura de equipe e processo de produção são apropria-
dos para o desenvolvimento de um jogo. O próximo capítulo discutirá alguns
processos formais de produção que podem ser usados de maneira eficaz em
equipes de desenvolvimento, inclusive o Processo Pessoal de Software e as
metodologias ágeis.
3
MÉTODOS DE GERENCIAMENTO
DE PROJETOS
Neste capítulo
• Prós e contras • Scrum
• Processo Pessoal de • Project Management
Software (PSP) Institute (PMI)
3.1 Introdução
Os desenvolvedores de jogos tendem a evitar o uso de um processo formal

de engenharia de software (talvez porque tenham medo de reprimir a ener-
gia criativa da equipe) e, em vez disso, partem direto para a produção sem
tomar uma decisão clara sobre como gerenciar o ciclo de desenvolvimento.
Isso funcionava bem 25 anos atrás, quando as equipes eram pequenas e todos
conheciam com clareza suas responsabilidades no desenvolvimento. Os jogos
também eram muito mais simples de criar – menos assets, linhas de código e
recursos. Atualmente, as equipes são maiores e os jogos são mais complexos
e lançados simultaneamente em várias plataformas e idiomas. Os desenvol-
vedores estão percebendo que devem encontrar maneiras melhores de geren-
ciar o ciclo de desenvolvimento. Para fazer isso, estão examinando como os
processos de engenharia de software são gerenciados em outros segmentos da
indústria e tentando adaptá-los ao desenvolvimento de jogos.
O Processo Pessoal de Software (Personal Software Process – PSP) e
uma metodologia ágil conhecida como Scrum são dois processos de desen-
volvimento de software que têm sido usados com sucesso por desenvolvedo-
res de jogos nos últimos anos. Outros processos de desenvolvimento de soft-
ware também podem ser adaptados ao desenvolvimento de jogos; qual você
deve escolher vai depender do tipo de jogo, das restrições e dos recursos
disponíveis. Há prós e contras no uso de qualquer tipo de processo, portanto,

leve isso em consideração ao pesquisar qual será o melhor para sua equipe
de desenvolvimento.
Os processos formais de produção são um tópico amplo, e discuti-los
com detalhes não faz parte do escopo deste livro. No entanto, este capítulo
apresentará informações gerais sobre os prós e contras do uso de um pro-
cesso formal, sobre como dois estúdios implementaram com sucesso o PSP
e o Scrum e sobre os benefícios trazidos pelo Project Management Institute
(PMI).
3.2 Prós e contras
Como muitos desenvolvedores de jogos não são treinados em processos de

gerenciamento de projetos, nenhuma terminologia ou método comum é usado
de um projeto para outro. Isso dificulta para as equipes saberem como suas
tarefas se encaixam no processo de desenvolvimento e afetam o trabalho dos
outros. Por exemplo, um designer não pode roteirizar um nível até o artista tê-
-lo construído ou um artista não pode adicionar iluminação a um nível antes
da ferramenta de iluminação ter sido codificada. É importante que a equi-
pe tenha ciência dessas dependências para que possa planejar seu trabalho
de acordo. Quando o trabalho não é planejado apropriadamente, o caminho
crítico fica sobrecarregado e gargalos se desenvolvem no fluxo de trabalho,
colocando o projeto em risco. O uso de um processo formal de engenharia de
software pode amenizar alguns desses problemas.
Muitos processos de engenharia de software, como o PSP e o Scrum,
requerem que a equipe se envolva na determinação das tarefas que têm de ser
executadas, na estimativa de quanto tempo levará sua execução e no rastrea-
mento do progresso dessas tarefas. Esse nível de envolvimento da equipe faz
com que as pessoas se sintam mais donas de seu trabalho. A moral aumenta
porque elas controlam diretamente suas tarefas, o que significa que podem ter
um impacto direto sobre o sucesso (ou falha) do projeto.
Quando as pessoas veem que a produção do jogo está sob controle, ficam
mais confiantes quanto ao sucesso do jogo. Um processo formal permite que
a equipe veja claramente um progresso tangível, o que a motiva a seguir em
frente em seu trabalho. Por exemplo, o Scrum usa gráficos de burndown para
mostrar o progresso que a equipe está fazendo. Esses gráficos permitem que as
equipes vejam quando estão adiantadas, atrasadas ou corretas no cronograma.
Se estiverem atrasadas, poderão ver isso mais cedo e corrigir o ritmo antes
que ele se torne um problema e ponha o projeto em risco.
Outro benefício do uso de processos formais de engenharia de software
é que métricas do projeto podem ser geradas referentes a quanto tempo leva a
execução de uma tarefa, e essas informações podem ser usadas na estimativa
de tarefas semelhantes em projetos futuros. Isso permite principalmente que
o produtor e a equipe gerem estimativas mais precisas para as tarefas. Quan-
to mais precisas forem essas estimativas, mais fácil será para uma equipe
3 • Métodos de Gerenciamento de Projetos 43
planejar o ciclo de produção, decidir que recursos e assets podem ser imple-
mentados e determinar mais seguramente quando o jogo será terminado. Por
exemplo, se um artista rastrear precisamente quanto tempo leva a criação de
um nível de 200m x 200m, essa informação poderá ser registrada e depois
usada para estimar essa mesma tarefa em outro projeto.
O produtor e os líderes se beneficiam enormemente do uso de um pro-
cesso formal. Quando um processo-padrão é usado, é mais fácil trazer novos
membros para a equipe e fazê-los entrar rapidamente no ritmo de desenvol-
vimento do jogo. Novas pessoas que ingressarem na equipe podem começar a
trabalhar imediatamente, em vez de precisarem de alguns dias para descobrir
o que devem fazer. Além disso, o produtor e os líderes podem usar seu tempo
gerenciando realmente o processo de desenvolvimento do jogo e não apagan-
do incêndios. Uma vez que você sabe exatamente onde o projeto está em um
determinado momento, nenhuma grande surpresa deve surgir sem aviso.
Há algumas desvantagens no uso de um processo formal de engenharia
de software, mas muitas delas podem ser superadas com o tempo, principal-
mente quando as pessoas começarem a usar, entender e se sentir à vontade
com o processo. Um problema do uso de processos como o Scrum ou o PSP
no desenvolvimento de jogos é que esses processos são mais adequados para
tarefas de engenharia e menos para tarefas de design e artísticas. Os proces-
sos foram desenvolvidos originalmente para a engenharia de software porque
quase sempre há incertezas referentes ao escopo do trabalho e ao tempo ne-
cessário para a codificação de um recurso e a correção de bugs. Quando esses
processos são adotados, há mais controle sobre as tarefas de engenharia, e
critérios de saída podem ser estabelecidos para sabermos quando o código
está concluído.
As pessoas podem hesitar em usar um processo formal por várias ra-
zões. Para algumas, seu desconhecimento do processo será um obstáculo,
pois elas podem não querer usar algo em que têm pouca experiência. Outras
podem perceber o processo como algo rígido que reprimirá a criatividade
e a inovação; também podem achar que estão sendo menos envolvidas nas
decisões do projeto, em vez de mais envolvidas. Para as pessoas que acha-
rem que a criatividade será afetada, explique que haverá mais tempo para
simular e polir o jogo, já que agora grande parte de seu tempo será gasto na
implementação de recursos do projeto e não em apagar incêndios. Para con-
cluir, elas podem achar que a cultura da empresa se tornará mais corporati-
va e menos divertida. Explique que esse é um processo para ajudar a equipe
em vez de controlá-la.
Outro item que deve ser considerado no uso desses processos é o custo
de treinamento e implementação. Por exemplo, no PSP todos os envolvidos
têm de fazer um curso de duas semanas; além de ser caro, ter pessoas indispo-
níveis por duas semanas afetará o projeto. Se você estiver planejando gastar
dinheiro no treinamento de pessoas, certifique-se de que a empresa e as pes-
soas se comprometam a fazer o processo funcionar. Qualquer investimento
em tempo ou dinheiro nessas áreas será válido pelo aumento na eficiência e
pela redução de riscos ao projeto.
3.3 Processo Pessoal de Software (PSP)
O Processo Pessoal de Software, estabelecido pelo Software Engineering

Institute da Carnegie Mellon University, ensina os engenheiros a entender e
melhorar seu próprio processo de codificação. Ele dá ênfase a como ensinar
os engenheiros a gerenciar a qualidade de seu código, se comprometer com
o que possam realmente realizar, melhorar a estimativa e o planejamento e
reduzir bugs no código. Grande parte desse esforço envolve a condução de
revisões de código em cada estágio do ciclo de desenvolvimento de software.
O PSP constitui um grande compromisso, já que os engenheiros devem
passar por um treinamento de duas semanas e concluir dez tarefas em casa.
Além disso, para o PSP ser mais eficaz, todos os engenheiros da equipe de-
vem ser treinados e usar esse processo juntos no projeto, o que pode ser caro.
Os custos de treinamento são recuperados pela certeza e estabilidade dos pro-
dutos codificados. Se quiser mais informações, consulte o Apêndice C, “Re-
cursos”, para ver o site oficial do PSP.
O Processo de Software para Equipes (Team Software Process – TSP) é
outro componente do PSP. O TSP ocorre quando todas as pessoas da equipe,
inclusive os designers e artistas, aplicam os princípios do PSP em seu tra-
balho. O objetivo é construir equipes autodirecionadas que estabeleçam os
objetivos do projeto, formulem um plano para atingir esses objetivos e acom-
panhem seu progresso em direção a eles. Se o TSP for integrado de modo
eficaz ao processo de produção, a equipe ficará mais motivada e conseguirá
cumprir com sucesso cronogramas de projeto mais agressivos – principal-
mente porque foi envolvida na criação do plano, conhece tudo que deve ser
feito durante o desenvolvimento e tem como saber muito mais cedo quando o
projeto está se desviando do caminho.
PSP E TSP
Tobi Salunier, Presidente

1st Playable
O Processo Pessoal de Software (PSP) (TM SEI CMU) é um programa de treinamento

profissional para engenheiros de software projetado para ajudar a pessoa a aprender mais
sobre seu próprio processo de engenharia de software e conhecer maneiras de melhorá-lo.
Especificamente, o treinamento foca em maneiras de planejar tarefas e detectar bugs mais
cedo, com as duas atividades resultando em estimativas de prazo mais precisas. Termina-
mos um grande projeto na Vicarious Visions depois de muita hora extra, e uma das prio-
ridades do post-mortem foi tentar melhorar nosso processo de desenvolvimento de jogos.
Tinha ouvido falar desse processo em meu cargo anterior de pesquisa e desenvolvimento
(P&D) na General Electric, pelo meu envolvimento com o programa de qualidade local.
Como a complexidade do software é um dos fatores mais importantes em projetos lon-
gos, parecia que tentar o PSP na Vicarious Visions poderia ser parte da solução. Mas seria
um desafio convencer os desenvolvedores do jogo de que um processo estruturado como
o ensinado pelo PSP seria bom para eles. Como qualquer tipo de melhoria de processo, o
processo de desenvolvimento de software não é algo que você possa forçar as pessoas a
adotar e gostar; as pessoas não querem que lhes digam que algo é bom para elas – em vez
disso, querem julgar por si próprias.
O interessante no PSP é que o programa de treinamento é projetado para as pessoas
ganharem experiência imediata no processo e então determinarem se é algo que gosta-
riam de usar em um projeto de desenvolvimento de jogos. O treinamento é composto por
duas sessões de uma semana em sala de aula, separadas por alguns meses. Essa aborda-
gem dividida em estágios permite que os envolvidos adquiram novos hábitos e coletem
seus próprios dados para validar que técnicas funcionam para eles. O treinamento tem
enfoque individual, para que cada pessoa tenha a chance de identificar e melhorar áreas
fracas e transformar o material no que for mais útil para cada uma.
Decidimos enviar todos os engenheiros para o programa de treinamento para tirar
o máximo de proveito. Como em qualquer grande programa de treinamento, se você não
treinar todas as pessoas, o processo não será tão eficaz; elas voltarão do treinamento
querendo usar algo novo, mas não conseguirão continuar se forem minoria. Uma grande
desvantagem é o custo; além do tempo alocado, as taxas do curso também são muito ca-
ras (para um desenvolvedor de jogos). E todos os gerentes de projeto teriam de se progra-
mar de acordo com o período de treinamento. No entanto, achamos que o investimento
valeria a pena a longo prazo. Como éramos uma empresa, só trabalhávamos em projetos
maiores e mais complexos, e mesmo algumas semanas de atraso em um desses grandes
projetos custaria muito mais. Logo, mesmo se as pessoas não concordassem com o PSP
antes do treinamento, tinham esperanças de que veriam seu valor após o curso e iriam
querer utilizar pelo menos parte dele.
O TSP é um componente adicional desse treinamento profissional. Envolve a equi-
pe inteira e fornece uma estrutura para assegurar que a equipe tenha o suporte que
precisa para os membros aplicarem todo esse grande conhecimento do processo que
aprenderam. Um importante benefício secundário do TSP é que ele fornece uma es-
trutura para o processo básico de planejamento de projetos que assegura que toda a
equipe entenda e trabalhe em direção aos mesmos objetivos. Basicamente, o TSP requer
que a equipe se reúna durante quatro dias seguidos e crie o planejamento do projeto e a
lista de tarefas em um período de tempo condensado. Isso é diferente da abordagem de
planejamento mais ad hoc, que pode usar etapas semelhantes mas talvez envolva menos
membros da equipe em cada uma e cujos estágios ocorrem durante um período de algu-
mas semanas. Embora possa parecer difícil ter a equipe inteira dedicada a essa semana
de planejamento (já que muitos membros ainda podem estar finalizando seus projetos
anteriores), envolver a equipe em todo o planejamento antecipadamente é mais eficiente
a longo prazo e é menos provável que os membros esqueçam tarefas que teriam de ser
incluídas no plano.
Consultores externos podem vir à empresa e ajudar a iniciar esse processo. A maioria
das pessoas da área de desenvolvimento é de executores, não planejadores, portanto, é
preciso muita disciplina para reservar esse tempo inicial para o planejamento. Um consul-
tor pode ajudar a manter as pessoas no caminho certo durante a fase de planejamento.
Quando treinamos as pessoas em PSP na Vicarious Vision, não sabíamos se uma

equipe estaria interessada em também usar o TSP. Não queríamos pressupor que as equi-
pes usariam o TSP, mas certamente apoiaríamos qualquer equipe que quisesse fazê-lo.
Após o treinamento em PSP, algumas pessoas ficaram interessadas em dar esse próximo
passo com o TSP, e várias delas foram colocadas juntas em um projeto para desenvolver
o Spider-Man DS. Se essa equipe conseguisse usar com sucesso o TSP, seus pares ficariam
mais dispostos a vê-lo como algo que seria bem-sucedido em seus projetos.
O uso do TSP para o Spider-Man trouxe vários benefícios. Em primeiro lugar, não
poderíamos ter concluído com sucesso esse projeto dentro dos prazos apertados de um
título de lançamento sem um processo seguro para o planejamento e a comunicação.
Além do curto ciclo de desenvolvimento, um título de lançamento no DS traz um conjunto
próprio de problemas de desenvolvimento – como o trabalho em uma plataforma que não
é final e esperar certos componentes estarem disponíveis para teste. O TSP nos permitiu
manter um loop de realimentação muito mais compacto para que todos vissem mais cedo
quando nossas suposições não estavam funcionando e seria necessário replanejar.
Uma vantagem do TSP é que a equipe acompanha seu próprio progresso e é a pri-
meira a ver quando está se desviando do plano. Quase sempre eles mesmos conseguem
resolver o problema. Já que o plano e a lista de tarefas do TSP podem ser vistos e ficam
disponíveis para todos, a equipe também poderia pedir ajuda de uma maneira mais em-
basada em dados. Por exemplo, eles poderiam solicitar recursos para ajudar em um con-
junto de tarefas específico e claramente definido, em vez de apenas pedir mais pessoas.
Além disso, se quisessem adicionar um novo recurso ao jogo, poderiam consultar o plano
e saber implicitamente qual seria o impacto – seria necessário mais tempo; outro recurso
teria de ser reduzido ou cortado; ou outro recurso seria necessário no projeto.
Existem algumas desvantagens no uso do TSP, mas os benefícios são muito mais
importantes. Em primeiro lugar, o treinamento em PSP e TSP é caro e requer um tempo
reservado. A empresa tem de querer investir tempo e dinheiro para seguir integralmente o
treinamento ou não conseguirá implementá-lo com sucesso.
Além disso, consultores e instrutores qualificados são difíceis de encontrar e são
realmente necessários na implementação inicial do TSP no processo de produção. Eles
podem tornar a transição muito mais fácil e são recursos inestimáveis para responder
qualquer pergunta sobre o processo.
Para concluir, o TSP requer um grande esforço de coleta de dados – as pessoas têm
de rastrear quanto tempo cada tarefa levou e atualizar sua lista de tarefas diariamente.
A equipe também pode ficar hesitante quanto a rastrear essas informações, principal-
mente se achar que elas serão usadas como um meio de julgá-la. Por exemplo, se um
programador estiver constantemente demorando mais para concluir uma tarefa do que
o previsto na estimativa inicial, pode se sentir vulnerável se a gerência estiver examinando
suas tarefas. Isso pode resultar em um aumento geral nas tarefas, ou na coleta de dados
imprecisos, o que fará com que a gerência comece a desconsiderar os planos da equipe.
Nesse caso, o TSP perderá qualquer vantagem que poderia trazer para um planejamento
mais preciso e acabará perdendo a credibilidade tanto por parte da equipe quanto da
gerência. Se houver uma cultura básica de confiança entre a gerência e a equipe, esse pro-
blema poderá ser evitado.
3.4 Scrum
O desenvolvimento ágil é um conjunto de metodologias dedicadas à percep-

ção do valor real do produto por meio de iteração e feedback. Ele não incenti-
va a equipe a construir vários componentes de um jogo isoladamente, reuni-
-los e então esperar que tudo funcione como planejado. Em vez disso, enfatiza
a construção de uma iteração inicial do jogo contendo uma funcionalidade
muito básica e a continuação do desenvolvimento dessa funcionalidade no
decorrer de iterações do produto até o jogo estar concluído. Existem várias
metodologias ágeis para uso, entre eles o Scrum. Para obter mais informações
sobre o desenvolvimento ágil, consulte Integrating Agile Development in the
Real World, de Peter Schuh.
O Scrum é uma metodologia de enfoque gerencial que é suficientemente
flexível para ser usada em uma grande variedade de ambientes de desenvol-
vimento de jogos. Também é relativamente fácil de implementar, já que não
requer treinamento formal, só o comprometimento por parte da equipe em
usar o processo. Os aspectos básicos do Scrum envolvem a criação de sub-
conjuntos de equipes autodirecionadas dentro da equipe maior do projeto,
lideradas por um “mestre de Scrum”, que tem poderes para remover qualquer
obstáculo que afete o progresso operacional da equipe. As equipes são mul-
tifuncionais (artistas, designers e engenheiros), pequenas (normalmente com
cinco a dez pessoas) e trabalham juntas para concluir um conjunto de tarefas
que resultarão em um produto tangível no fim de um determinado período de
tempo. Esses períodos de tempo específicos são chamados de sprints e geral-
mente duram um mês. A sprint é o bloco de construção do progresso do jogo,
porque no fim de cada sprint há um componente de jogo tangível e jogável.
A próxima sprint se baseia na sprint anterior, em um processo iterativo. Para
ver mais detalhes sobre o Scrum, consulte Agile Software Development with
SCRUM, de Ken Schwaber e Mike Beedle.
O SCRUM E O DESENVOLVIMENTO DE JOGOS
Clinton Keith, Diretor técnico

High Moon Studios
Minha experiência vem da indústria de defesa. Alguns dos problemas de gerenciamento

de projetos que esse segmento encontrou nas décadas de 1960 e 1970 são iguais aos
que estamos tendo agora no desenvolvimento de jogos. Por exemplo, na década de 1970
a indústria de defesa começou a usar a abordagem de cascata (implementação com as
fases de design, codificação, integração e testes), esperando reduzir sua taxa de falhas em
projetos com grandes equipes. No entanto, o que viram foi a taxa de falhas aumentar com
essa abordagem; em vez de uma taxa de falhas de 30 a 40%, agora eles estavam presen-
ciando uma taxa de falhas de 60 a 70%. Estudando as razões desse problema, perceberam
que os projetos deviam ser concluídos em etapas iterativas, em vez de em uma grande
etapa de várias fases. Com a introdução do primeiro processo formal de desenvolvimento
iterativo, as taxas de falhas foram reduzidas.
Envolvi-me com o desenvolvimento de jogos em meados da década de 1990 e desco-
bri que esse segmento industrial estava adotando muitas das mesmas práticas de cascata
à medida que o tamanho de suas equipes crescia. Como resultado, os atrasos estavam
aumentando. Sabia que precisava encontrar uma maneira de reduzir as falhas e estava es-
tudando como os desenvolvedores japoneses manipulavam seus processos de desenvolvi-
mento de software. Em geral, alguns dos desenvolvedores japoneses mais bem-sucedidos
eram muito iterativos e estavam mais interessados em ver iterações de produtos e não
documentos de planejamento, mas mesmo assim seus projetos continuavam atrasando
devido a uma falta de processo. Começamos testando metodologias que combinavam
mais planejamento com desenvolvimento iterativo e aplicamos essa técnica quando eu era
Diretor de Desenvolvimento de Produtos no Angel Studios.
Quando assumi o papel de Diretor Técnico no Sammy Studios, li Agile and Iterative
Development, de Craig Larman, que discutia os fundamentos do desenvolvimento ágil. Em
resumo, o desenvolvimento ágil enfoca a descoberta do valor real do produto por meio
da iteração e do feedback da maneira mais rápida possível (por incrementos) usando
processos bem definidos, porém simples. A chave para essa metodologia é projetar, im-
plementar, integrar, depurar e ajustar fatias verticais à medida que se avança, em vez de
dividir o projeto em fases para cada uma. Surgem menos suposições e trabalho oculto
como resultado.
Após ler sobre as quatro áreas do desenvolvimento ágil, decidi que o Scrum com-
binava bem com os processos de desenvolvimento que já estava usando. O Scrum é um
processo de gerenciamento simples de entender e fácil de começar a usar de modo eficaz;
podia colocar esse processo em funcionamento em um mês e ver uma melhoria imediata.
Foi muito fácil fazer a equipe aceitar o Scrum, já que ele era muito parecido com
a metodologia para a qual estávamos mudando. A maior alteração foi se adaptar ao
método do Scrum de usar etapas (sprints) de 30 dias e afixar gráficos de burndown na
parede. Os gráficos de burndown rastreiam o progresso diário da equipe e mostram o
tempo restante necessário à conclusão dos objetivos priorizados da sprint. Se a equipe
não atingir alguns dos objetivos de prioridade mais baixa no fim dos 30 dias, eles serão
passados para a sprint do mês seguinte.
O Scrum funciona bem com o desenvolvimento de jogos porque força a equipe a
fazer builds mensais do jogo no início do projeto. Já que o processo é iterativo, os as-
pectos mais importantes do jogo são concluídos mais cedo na produção e podem con-
tinuar sendo polidos ou adicionados conforme o tempo permitir. A equipe pode reagir
a qualquer elemento de jogabilidade emergente enquanto houver tempo. Pode cancelar
recursos que se mostrarem pouco divertidos ou viáveis e enfatizar e expandir recursos que
se mostrarem melhores do que o esperado. Portanto, em vez de gastar grande parte do
tempo de pré-produção criando um documento de design de 500 páginas que descreva o
jogo, podemos construir um protótipo funcional que demonstre os principais recursos de
jogabilidade. Outra maneira de ver isso é como um bolo; todo mês, a equipe está tirando
fatias completas de um bolo de sete camadas. Inversamente, com os processos tradicionais
(como a cascata), a equipe trabalha para criar a infraestrutura de um bolo e, no fim da

versão alfa, tem um bolo sem glacê.
O desenvolvimento com o Scrum pode ser interessante para os publicadores porque
eles poderão ter uma ideia melhor de qual será a aparência do jogo e se sentirão mais
confortáveis para arriscar cinco ou seis milhões de dólares no projeto. Eles poderão acom-
panhar o progresso mensal do jogo por meio das builds sem precisar esperar seis meses
para ver se estão desperdiçando dinheiro. Se o publicador tiver um envolvimento maior
no processo de desenvolvimento, também poderá examinar os gráficos de burndown e ter
uma visão mais clara do progresso do jogo e de quando os recursos serão implementados.
Inicialmente, os publicadores podem relutar em adotar esse processo de desenvol-
vimento, já que precisam se conscientizar de que redigir grandes documentos de design e
criar um cronograma no Microsoft Project dá apenas a ilusão de controle. Na verdade, o
Scrum dá mais controle ao processo, já que um produto tangível deve estar pronto a cada
30 dias, o que dá uma visão mais precisa do progresso. Acabamos achando bom envolver
os publicadores no processo de planejamento de cada sprint mensal.
Há muitas vantagens no uso do Scrum. O que mais aumenta é a moral da equipe
como um todo. As pessoas ficam mais entusiasmadas e produtivas porque se sentem
donas de suas tarefas e têm controle direto sobre o que estão fazendo. Também ficam
mais propensas a remover obstáculos em seu trabalho se tiverem a sensação de posse, e
o Scrum lhes dá isso. Já que em grande parte o Scrum envolve equipes auto-organizadas,
a equipe trabalhará em conjunto para resolver problemas em vez de esperar a gerência
resolvê-los. Isso significa que a gerência passa menos tempo tentando saber o que está
acontecendo com o jogo a cada semana, porque, com o Scrum, todas as informações
ficam à mostra (postadas na parede da sala de operações).
O Scrum também evita o desgaste da equipe. Já que estamos acompanhando as
tarefas tão rigorosamente e podemos avaliar o progresso do jogo, agora temos provas
de que, após um determinado período de tempo (geralmente duas semanas), as horas-
-extras não surtem mais efeito. Após algumas semanas de trabalho fazendo horas-extras,
na verdade as pessoas ficam menos eficientes do que se estivessem trabalhando nas horas
normais da semana. Sabendo disso, podemos programar horas-extras em pequenas doses
(alguns dias) se precisarmos realmente apertar o passo para atingir um prazo. A equipe
fica mais feliz e obtemos um trabalho de melhor qualidade. Além disso, com a remoção
dos obstáculos levantados em reuniões diárias de 15 minutos, vemos um extraordinário
aumento na produtividade. Esse é um ótimo exemplo de como trabalhar de maneira mais
inteligente em vez de trabalhar mais.
Uma desvantagem do Scrum é que ainda estamos tentando descobrir como incluir
de modo eficaz a arte e o design nesse processo. Como essas áreas são mais subjetivas,
é mais difícil encaixá-las em um processo quantitativo. No momento, temos pequenas
equipes compostas por alguns programadores, alguns artistas e talvez um designer. Todos
podem trabalhar juntos para projetar e implementar um recurso. Isso dá mais controle ao
designer, já que ele não tem que esperar meses por seus documentos de design se torna-
rem recursos funcionais do jogo.
Ainda estamos aprendendo como adaptar o Scrum ao desenvolvimento de jogos. O
Scrum é mais apropriado para projetos com incertezas e valor emergente. No entanto, na
criação de conteúdo que não tenha incertezas (como um pacote de expansão, conteúdo
para download ou até mesmo apenas a produção de níveis do jogo), processos mais tra-
dicionais podem ser usados. Eles incluem documentos, gráficos de Gantt e cronogramas
detalhados do Microsoft Project. Se não houver incertezas no que estiver sendo feito,
você poderá criar um plano-mestre para mostrar ao seu publicador que consegue cumprir
aquela data de entrega no natal.
No entanto, há algumas desvantagens no Scrum. O depoimento a seguir,

com Lucien Parsons, dos estúdios ZeniMax Online, discute algumas delas.
DESVANTAGENS DO SCRUM
Lucien Parsons, Diretor de produção

ZeniMax Online Studios
Acredito que a adoção do Scrum por equipes de desenvolvimento de jogos, principalmen-

te em projetos grandes, tem sido algo positivo para a indústria. Usado apropriadamente,
ele ajuda as equipes a manterem o foco, o que fica mais difícil à medida que as equipes
crescem. Também fornece uma linguagem e uma estrutura comuns para as pessoas se
organizarem. Porém, há requisitos no processo de desenvolvimento de jogos que tendem
a se perder na pressa em “ser ágil”.
Em primeiro lugar, é preciso se certificar de que um exame inicial completo seja feito
com o objetivo de definir o escopo do projeto, que o escopo seja reavaliado e que mudan-
ças sejam comunicadas regularmente. É muito fácil os itens se acumularem no backlog, já
que “só o importante será feito”. Isso me afetou negativamente em meu segundo projeto
de Scrum porque cada item do backlog original foi sendo substituído por outra solicita-
ção de “maior prioridade”. Não comuniquei claramente que essa atitude afetaria o prazo
das solicitações anteriores e, consequentemente, elas não seriam concluídas no prazo ori-
ginal. À medida que cada item ia sendo substituído, tentei transmitir qual seria o impacto
individual, mas já que itens que perdem a prioridade tendem a ser apenas rebaixados no
backlog do produto em vez de removidos, a gerência geral presumiu que todos eles seriam
executados.
Da mesma forma, muitas equipes parecem cair na armadilha de que o Scrum subs-
titui o planejamento antecipado e contínuo de longo prazo. O foco contínuo do Scrum
em iterações rápidas pode ser um problema para a equipe, porque ela pode começar a
trabalhar visando às builds e não ao produto final, ou pode começar a basear seu traba-
lho nos desejos do publicador e não no jogo, já que o publicador precisa de um quadro de
referência para saber que progresso está sendo feito em cada sprint. Quando não há esse
quadro de referência, é difícil para as pessoas que fazem parte da equipe de desenvolvi-
mento saberem o volume de trabalho e esforço que uma etapa demandou. Por exemplo,
uma vez usei o Scrum em parte de um projeto, mas não informei isso à gerência geral.
A equipe gostou muito e os membros foram muito produtivos durante as sprints. Mas
quando mostramos a etapa concluída para a gerência, ela foi rejeitada porque a gerência
não tinha um quadro de referência para servir de comparação. Na opinião da gerência, a

equipe devia ter mais para mostrar pelo volume de trabalho que disse ter executado.
Outra área em que a união entre o Scrum e o desenvolvimento de jogos não funciona
de maneira ideal é na organização de equipes. Uma ideia existente por trás do Scrum é a
de que esforços colaborativos geram resultados melhores, e assim criamos equipes com
menos pessoas para trabalhar juntas no mesmo recurso. Mas há algumas tarefas repeti-
tivas altamente especializadas que ocorrem durante o desenvolvimento onde um esforço
colaborativo não é realmente necessário. Por exemplo, o que acontece quando você tem
um animador que precisa criar 300 animações nos próximos três meses? Qual é o valor da
inclusão de mais pessoas a esse grupo? Há muitas coisas que podemos usar no Scrum que
são ótimas, mas a natureza interdisciplinar de um grupo é menos importante quando esta-
mos em plena produção e as pessoas estão trabalhando em assets reais do jogo. Portanto,
essa é uma área que acho que se beneficiaria de uma pequena modificação nos princípios
do Scrum para ele funcionar melhor em um ambiente de desenvolvimento de jogos.
3.5 Project Management Institute (PMI)
O Project Management Institute (PMI) é uma organização internacional que

promove a disciplina de gerenciamento de projetos em todos os tipos de seg-
mentos industriais. Ele acompanha as tendências atuais e os métodos reco-
mendados de gerenciamento de projetos, atua como um depósito central de
recursos e fornece oportunidades de comunicação em rede com outros geren-
tes de projeto. O instituto oferece três tipos de certificações – a mais comum
sendo o PMP (Project Management Professional).
O PMI designou um conjunto específico de requisitos que devem ser
atendidos para a obtenção de um PMP. Os requisitos são bem rigorosos e
incluem ter até 7.500 horas de experiência em gerenciamento de projetos
(só 4.500 horas serão necessárias se você tiver um diploma de bacharel), 35
horas de treinamento específico em gerenciamento de projetos e uma nota
suficiente para aprovação no PMP Credential Examination. Uma vez que ti-
ver obtido o PMP, você terá de manter seu status ativo ganhando pelo menos
60 unidades de desenvolvimento profissional (PDUs, Professional Develop-
ment Unit) durante um período de três anos, e enviando a taxa e o pedido de
renovação para o PMI.
O PMI também mantém o Project Management Body of Knowledge
(PMBOK), que é a principal referência dos padrões do PMI para o processo de
gerenciamento de projetos. Além disso, ele lista livros, periódicos e conferên-
cias relevantes relacionados à disciplina de gerenciamento de projetos. É atua-
lizado a cada três a quatro anos. O PMBOK é um guia geral dos processos e mé-
todos endossados pelo PMI e não contém necessariamente detalhes de todas as
informações de gerenciamento de projetos que estão disponíveis para os PMPs.
O site do instituto, www.pmi.org, tem informações sobre as melhores
práticas de gerenciamento de projetos e dá instruções sobre como se tornar
um PMP certificado. Se você quiser saber mais sobre os aspectos básicos do

gerenciamento de projetos, esse recurso é um bom ponto de partida.
CERTIFICAÇÃO PMP
Karin Groepper Boosman

PMP, Aspyr Media, Inc.
O valor da obtenção de um PMP é a disponibilidade de métodos-padrão para lidarmos

com nossos jogos de maneira inteligível para os investidores, desenvolvedores e todos os
stakeholders. Acredito que o uso de métodos técnicos de gerenciamento de projetos na
indústria de jogos fará com que mais jogos sejam concluídos a tempo, conforme o orça-
mento e com qualidade, e também melhorará as condições de trabalho para as pessoas.
Uma das coisas que admiro no PMI e no PMBOK é sua agilidade – a ideia de que
a disciplina de gerenciamento de projetos evolui e cresce à medida que mais segmentos
industriais veem o benefício de organizar o trabalho dessa forma. Se a indústria de jogos
adotasse amplamente o gerenciamento de projetos e contribuíssemos com nossas pró-
prias necessidades e modificações, nós mesmos melhoraríamos o PMBOK.
Mesmo com os jogos variando de um projeto para outro, há processos comuns que
ocorrem em todos os projetos. Lembre-se de que os projetos que usam os métodos endos-
sados pelo PMI vão de sistemas bancários à construção de pontes e o desenvolvimento de
software. É algo que perpassa todos os segmentos industriais e define um terreno comum
em uma ampla variedade de projetos. O PMI entende que não existem dois projetos exata-
mente iguais e exprime isso no PMBOK. O que se espera é que um PMP certificado e expe-
riente possa consultar o PMBOK e descobrir que métodos seriam mais apropriados para
um projeto. O controle de qualidade, o gerenciamento de riscos e outras atividades têm
áreas comuns nesses projetos. Tudo depende do nível até onde você pretende explorá-las. A
indústria de jogos tende a reinventar a roda a cada projeto e pode se beneficiar vendo que
outras empresas já percorreram esses caminhos e resolveram esses problemas.
Em minha empresa, usamos a abordagem do PMBOK em todos os projetos, até
mesmo os iterativos que usem uma metodologia ágil ou o Scrum no desenvolvimento do
produto. À primeira vista, parece que a abordagem que o PMBOK sugere é estritamente
em cascata e, portanto, se encontra no lado oposto das metodologias ágeis – mas eu
descordaria disso. O PMBOK especifica claramente que cada projeto, independentemente
dos objetivos da indústria ou do projeto, tem necessidades variadas e que a profundidade
ou maneira com que cada Grupo de Processos e Área de Conhecimento é usado deve ser
determinada pela equipe. Seja qual for a técnica ou a metodologia de desenvolvimento da
equipe, as variáveis descritas pelo PMBOK podem ser aplicadas. Por exemplo, o PMBOK
recomenda que haja um Plano de Gerenciamento da Qualidade. Independentemente de o
jogo ser desenvolvido iterativamente ou não, o plano de qualidade é um componente ne-
cessário para ele ser bem-sucedido. Para um jogo muito pequeno, desenvolvido por apenas
alguns desenvolvedores, o plano de qualidade poderia ser tão simples quanto “Todos na
equipe jogam o jogo durante uma hora diariamente, postam suas descobertas no wiki/fo-
rum/whiteboard da equipe e são responsáveis por assegurar que os bugs que encontraram
sejam gerenciados”. A simplicidade desse plano não anula sua utilidade e ele é um Proces-
so de Gerenciamento de Projetos válido. Seria tão válido quanto um documento de 100
páginas descrevendo o plano de testes, com um grupo de testes de 20 pessoas ampliando
os esforços de uma equipe trabalhando em um ciclo de sprints de 2 anos e 6 semanas.
Este depoimento discute os grupos de processos e as áreas de conheci-

mento do PMI que existem em qualquer projeto.
GRUPOS DE PROCESSOS E ÁREAS DE CONHECIMENTO DO PMI

PMP, Aspyr Media, Inc.
Os cinco grupos de processos são: Início, Planejamento, Execução, Monitoração e Con-

trole, Fechamento. Cada projeto, independentemente do tamanho ou escopo, passa por
cada um desses grupos de processos, geralmente em ciclos durante a existência do proje-
to. A seguir, temos as definições de cada um dos grupos de processos:
Início: Essa fase é composta pelo que ocorre no começo do projeto. Nela, o trabalho
a ser executado é definido e comunicado, e o líder do projeto é designado e recebe auto-
ridade específica sobre o projeto e seus produtos. No mundo dos jogos, com frequência
essa fase é chamada de “sinal verde” do projeto. Nela, os critérios de aceitação das etapas
e do fim do projeto também são definidos.
Planejamento: Essa fase costuma ser subestimada e ignorada. Durante o planeja-
mento, os objetivos do projeto (de alto nível e provisórios) são definidos e os planos
das várias áreas de conhecimento são desenvolvidos. No desenvolvimento ágil/iterativo, o
projeto pode voltar à fase de planejamento em cada sprint quando o trabalho concluído
é avaliado e a prioridade da próxima tarefa é reordenada.
Execução: Em poucas palavras, essa fase integra todos os recursos necessários à
implementação do plano de gerenciamento do projeto.
Monitoração e Controle: Avaliação consistente e frequente do progresso dos obje-
tivos do projeto/etapa/sprint. Variações ocorridas em relação às linhas de base iniciais ou
atuais são calculadas e medidas corretivas tomadas para que o controle do projeto seja
mantido/restaurado.
Fechamento: São todas as atividades relacionadas à finalização de um projeto, in-
clusive envio para o concessor da licença/fabricante, tarefas de arquivamento e processos
de post-mortem.
As áreas de conhecimento do gerenciamento de projetos são grupos de processos, a
maioria deles aplicável a grande parte dos projetos e utilizável em vários níveis, dependen-
do da complexidade do projeto. São elas: gerenciamento da integração, gerenciamento do
escopo, gerenciamento do tempo, gerenciamento de custos, gerenciamento da qualidade,
gerenciamento de recursos humanos, gerenciamento de comunicações, gerenciamento de

riscos e gerenciamento de aquisições. A maneira de cada equipe lidar com essas áreas de
conhecimento varia, mas todas elas estão sendo usadas atualmente na maioria dos esfor-
ços de desenvolvimento e publicação de jogos; e se não estiverem, deveriam estar.
Em minha empresa, podemos ter muitos projetos sendo executados em um determi-
nado momento com vários níveis de complexidade. Algumas coisas que fazemos são tão
semelhantes ao que fizemos no passado e já foram tão aperfeiçoadas que não precisamos
elaborar um grande e detalhado plano-mestre de gerenciamento de projetos com uma
documentação extensa para cada área de conhecimento, enquanto outros projetos são
muito complexos e envolvem a dependência de parceiros externos sobre os quais podemos
ter controle limitado. Embora os tipos de projetos variem e o nível até onde usamos os
processos e ferramentas do PMBOK dependa da complexidade e do estilo de desenvolvi-
mento do projeto, não temos uma abordagem de gerenciamento para cada projeto.
Usamos todas as áreas de conhecimento do PMBOK descritas a seguir:
1. Gerenciamento do escopo (planejamento, definição, verificação, controle). Em
nossos projetos que não usam uma metodologia ágil (não iterativos), essa área é
definida no começo do projeto. O Departamento de Produção e Projetos coleta
o máximo de dados possível sobre o escopo com todos os departamentos partici-
pantes (programação, arte, design, CG, marketing e assim por diante). A produção
integra então todas essas informações e conversa com a equipe inteira sobre o es-
copo em uma reunião inicial. Em nossos projetos desenvolvidos com metodologias
ágeis (iterativos), o escopo é definido vagamente no começo do projeto por seu(s)
patrocinador(es). O backlog do produto é então ordenado pela produção e defini-
do/gerenciado no resto do projeto sprint a sprint.
2. Gerenciamento do tempo (definição de atividades, sequenciamento, estimativa de
recursos, estimativa de duração [velocidade], desenvolvimento/controle do crono-
grama). Em projetos não iterativos, essa área é definida no início, na fase única de
planejamento. A produção coordena quando os principais produtos serão necessá-
rios, comunica dependências para toda a equipe e acompanha essa programação
para avaliar o valor do trabalho executado até a data em um determinado projeto.
Em nossos projetos iterativos, fazemos uma versão de alto nível no início, onde a
estimativa de trabalho é dividida entre as sprints planejadas e datas de início são
definidas. Em seguida, o componente de gerenciamento do tempo é atualizado con-
tinuamente à medida que o trabalho progride entre uma sprint ágil e outra.
3. Gerenciamento de custos (estimativa, orçamento, controle). Mudamos pouca coisa
na abordagem do PMBOK. Sem gerenciar os custos de seu projeto continuamente,
avaliando o valor agregado em intervalos muito próximos, você não saberá onde
está. Independentemente da metodologia de desenvolvimento, no início do projeto
temos uma ideia aproximada do que vamos gastar e em que momento. Usamos
essa ideia como base à medida que o projeto avança e avaliamos em intervalos de
um mês o volume de trabalho executado em comparação com o volume planejado,
atribuindo um valor em dólares para isso. Dessa forma, rastreamos o aumento dos
custos e temos como lidar com ele. Também descobrimos mais cedo se o projeto
está tendo problemas e se tem um orçamento irreal antes que uma crise se instaure.
4. Gerenciamento da qualidade (planejamento, garantia, controle). O fato de a ve-

rificação da qualidade ser executada continuamente durante todo o projeto e não
somente no fim é algo de muito valor no PMBOK. Acredito que esse seja um dos
aspectos em que o desenvolvimento iterativo de software se destaca em comparação
com as metodologias de gerenciamento de projetos tradicionais. Os ciclos de testes
constantes, alinhados às sprints, nos dão informações em tempo real sobre o que
está realmente ocorrendo, e já que o processo iterativo é projetado para incorporar
o feedback de qualidade/teste como parte do ciclo ativo, essa é uma área em que o
PMI e o desenvolvimento de jogos tem um tratamento semelhante.
5. Gerenciamento de recursos humanos (planejamento de recursos, contratação, de-
senvolvimento e gerenciamento da equipe do projeto). Nos projetos iterativos e não
iterativos que executamos, elaboramos um planejamento de RH no início do proje-
to. Geralmente conseguimos prever os requisitos de pessoal de todo o projeto nas
fases de planejamento. Um planejamento de RH adequado evita/ameniza as horas
extras à medida que um projeto é concluído, e os funcionários apreciam muito isso.
Acredito que, ao considerar o gerenciamento de RH como um processo de gerencia-
mento de projetos, obtemos orçamentos mais precisos e os funcionários ficam mais
satisfeitos.
6. Gerenciamento das comunicações do projeto (planejamento das comunicações,
distribuição de informações, relatório de desempenho, gerenciamento de stakehol-
ders). Novamente, a estrutura do desenvolvimento iterativo/Scrum é muito apro-
priada para o gerenciamento das comunicações. As equipes se comunicam diaria-
mente, há reuniões de revisão do backlog do produto e das sprints em intervalos
específicos, e quem é responsável por saber o que e quando é claramente especi-
ficado. Em projetos não iterativos, o produtor e nosso departamento de projetos
trabalham juntos no início do projeto para elaborar o plano de comunicações, que
é compartilhado com toda a equipe em uma reunião inicial. Os projetos diferem
tanto que não temos um modelo para usar.
7. Gerenciamento de riscos (planejamento, identificação, análise, plano de respos-
ta, monitoração, controle). Neste exato momento estamos implementando um
robusto sistema de gerenciamento de riscos, e já estamos vendo os benefícios. In-
dependente da natureza de seu projeto ou metodologia, o gerenciamento de risco
pode e deve ser implementado. Por aqui ele melhorou a transparência e o ânimo,
e a segurança de nos mantermos preparados para possíveis riscos manteve nossos
orçamentos sob controle. A melhor coisa que fizemos foi identificar os riscos ante-
cipadamente e atribuir limites de custo para a tomada de decisões caso obstáculos
ocorram. Geralmente a equipe gosta de ter a oportunidade de fazer um brainstorm e
classificar os riscos do projeto. É interessante ver como os diferentes pontos de vista
da equipe fornecem uma discussão de riscos diversificada. A equipe discute os riscos
e classifica-os quanto à probabilidade (inevitável, provável, possível e improvável) e
à gravidade (o projeto deve ser abandonado, desvio grave no custo/cronograma, o
custo e o cronograma não mudarão). Atribuímos então aos riscos médios a altos
um plano de prevenção e um plano de resposta, assim como projetamos o impacto
no custo. Dessa forma, quando obstáculos ocorrem, raramente são inesperados e a
equipe e os stakeholders sabem como proceder.
Leitura recomendada
Há muitos livros sobre métodos de gerenciamento de projetos; os dois a se-
guir são altamente recomendados. Rapid Development, de Steve McConnell,
descreve várias metodologias de desenvolvimento de software e discute como
elas podem ser usadas de maneira eficaz. O autor é um especialista reconhe-
cido em seu campo e defensor da melhoria das práticas de desenvolvimento
de software em todos os segmentos da indústria.
Project Planning Scheduling and Control, de Jim Lewis, apresenta in-
formações muito práticas e fáceis de entender sobre princípios básicos do
gerenciamento de projetos. O livro inclui vários formulários que podem ser
facilmente integrados ao processo de produção de sua equipe.
O gerenciamento de pessoas e projetos pode ser desafiador, mas há várias fer-

ramentas e recursos disponíveis e em uso em outros segmentos da indústria
que podem tornar o processo muito mais fácil. Os desenvolvedores de jogos
estão começando a perceber que essas ideias também podem ser adaptadas ao
desenvolvimento de jogos e têm obtido êxito com a implementação do Scrum
e do PSP. Este capítulo apresentou algumas informações básicas sobre os pro-
cessos formais de produção e como eles podem ser úteis para produtores e
líderes. Ele termina com uma lista de livros recomendados para qualquer pro-
dutor responsável por gerenciar o desenvolvimento de jogos.
Isso conclui a primeira seção do livro, que apresentou informações ge-
rais sobre o processo de desenvolvimento de jogos, os papéis existentes nas
equipes e os processos de gerenciamento de projetos. A próxima seção dis-
cutirá o lado comercial do desenvolvimento de jogos, inclusive problemas
legais e o trabalho com seu publicador.
Parte II
INFORMAÇÕES
COMERCIAIS
A inda que o objetivo principal do desenvolvimento de jogos seja a criação de

um produto de entretenimento, o produtor tem de ficar atento a algumas in-
formações comerciais para ser bem-sucedido. É necessário conhecimento dos con-
ceitos legais básicos para lidarmos com licenças, direitos de propriedade intelectual
e fornecedores externos.
Além disso, se um produtor estiver tentando expor um jogo desenvolvido in-
dependentemente para um publicador, algum conhecimento de como os publicado-
res trabalham será útil. Os tópicos são os seguintes:
• Direitos de propriedade intelectual

• Contratos de desenvolvedor
• Apresentando um jogo para um publicador
• Relacionamento entre desenvolvedor e publicador
4
INFORMAÇÕES LEGAIS
Neste capítulo
• Direitos de • Contratos legais
propriedade • Licenças
intelectual
4.1 Introdução
Como produtor, talvez você tenha de falar com um advogado ou com o depar-
tamento jurídico do publicador sobre certos assuntos. Por exemplo, um pro-
dutor desenvolvedor participa da negociação das etapas de desenvolvimento
que entrarão no contrato de publicação. Um produtor publicador pode ter de
trabalhar com possíveis licenças para definir os detalhes de um acordo de
licenciamento. Nos dois casos, o produtor trabalha com advogados qualifica-
dos para assegurar que todos os aspectos legais sejam manipulados de modo
adequado. Portanto não é necessário que ele seja formado em direito, mas é
útil que conheça algumas questões legais genéricas que serão encontradas
durante o desenvolvimento de jogos.
Tom Buscaglia, famoso advogado especializado em jogos, foi entrevis-
tado para dar algumas informações gerais sobre os problemas legais para os
quais um produtor deve ficar atento. Também escreveu uma série de artigos
sobre informações legais básicas que os desenvolvedores, principalmente os
independentes, devem conhecer. As informações dos artigos estão listadas
no Apêndice C, “Recursos”. O conteúdo extraído da entrevista será citado no
decorrer do capítulo.
60 Parte II • Informações Comerciais
QUESTÕES LEGAIS E PRODUÇÃO
Tom Buscaglia
O advogado dos jogos
Após os assets estarem protegidos e o negócio inicial ser fechado, o produtor não lidará
com questões legais diariamente, se tudo correr bem. No entanto, em alguns casos, um
advogado precisa ser consultado, principalmente quando um produtor independente está
criando um jogo para um publicador. Alguns exemplos seriam os seguintes: o projeto está
começando a divergir e ir além do escopo original de trabalho que foi detalhado no con-
trato de publicação; pequenas modificações são feitas em um contrato dos itens a serem
entregues; a fonte monetária muda; ou alguma outra coisa afeta a qualidade e o prazo dos
produtos acordados. Em casos como esses, o contrato de publicação deve ser retificado
com a compensação pelo tempo e as despesas adicionais incorridos pelo desenvolvedor.
Isso é necessário para o desenvolvedor continuar sendo uma entidade econômica viável.
Contratos de publicação, como qualquer outro contrato, são orgânicos – e não es-
táticos – e, quando necessário, devem ser retificados e revisados durante todo o processo
de desenvolvimento, pelo produtor ou pelo produtor junto com um advogado. Além dis-
so, se o sell-through, a rentabilidade do jogo, garantir isso, a ajuda de um advogado pode
ser necessária em uma auditoria das vendas pós-lançamento para verificar se o publicador
está pagando os royalties corretamente.
O produtor e seu advogado devem examinar todos os assets do jogo (arte, modelos
3D, música e sons, código do programa e, é claro, qualquer marca registrada de terceiros)
desde o primeiro dia para verificar se estão intactos e se são de propriedade do desenvol-
vedor. Afinal, você não pode vender o que não é seu. Portanto, verificar se o desenvolvedor
detém os direitos exclusivos de todo o conteúdo do jogo é a primeira etapa essencial na
venda de qualquer jogo.
4.2 Direitos de propriedade intelectual
Ideias criativas são uma commodity na indústria de jogos; todo dia, os desen-
volvedores criam novos personagens, novos enredos, novo código e novos de-
signs de jogos, esperando que essas ideias se integrem e criem uma experiên-
cia de jogo interessante. Todos esses elementos são considerados Propriedade
Intelectual (PI). Os direitos de PI protegem legalmente invenções, símbolos e
a expressão criativa, e podem ser comprados, vendidos, comercializados, do-
ados, licenciados etc., da mesma forma que propriedades tangíveis (como um
bem imóvel). Contudo, já que a PI é uma ideia e, portanto, é intangível, deve
ser expressa de alguma maneira discernível que a torne tangível e protegida
por lei.
Vários tipos básicos de PI são legalmente válidos: direitos autorais, mar-
cas registradas, segredos comerciais e patentes. As diferenças dependem de
como a ideia é expressa. Os produtores devem conhecer as diferenças entre
4 • Informações Legais 61
eles, principalmente os produtores independentes trabalhando com um pu-

blicador. Se o publicador estiver interessado em seu jogo e pronto para assi-
nar um contrato, provavelmente demandará que o direito autoral seja passa-
do para ele para que possa criar produtos derivados e reproduzir o produto
sem problemas legais. No entanto, se você for um desenvolvedor conhecido,
como Peter Molyneaux ou Will Wright, estará em melhor posição para nego-
ciar com o publicador e, provavelmente, manterá os direitos autorais de seu
trabalho.
As equipes de desenvolvimento também devem tomar cuidado para não
incluir assets no jogo que sejam marcas registradas ou tenham direitos au-
torais – a menos que direitos legais sejam obtidos para isso. Por exemplo,
máquinas de vender Coca-Cola® e giz de cera Crayola® não podem ser usados
em jogos sem o contato com as empresas que detêm essas propriedades e a
finalização de um contrato de uso desses direitos. Em alguns casos, podem
ser negociados com essas empresas contratos de inserção de produtos que
beneficiarão as duas partes.
Direitos autorais
Os direitos autorais protegem a expressão original da ideia de uma pessoa ou
grupo de pessoas em um meio tangível. Alguns exemplos seriam textos literá-
rios, obras musicais e esculturas.* No entanto, eles não protegem a ideia ou o
conceito real, independentemente da forma em que são expressos. Só o meio
de expressão da ideia pode ter direito autoral. Por exemplo, você não pode
proteger com direitos autorais a ideia que teve para um jogo, a menos que ela
seja expressa de uma forma tangível, como em um código de computador.
A vantagem é que a proteção por direitos autorais entra imediatamente
em vigor no momento em que a expressão da ideia é tornada tangível; você
não precisa registrar especificamente o trabalho no escritório de direitos auto-
rais para estar protegido. Contudo, ao registrar seu direito autoral, terá acesso
a todos os benefícios legais que garantirão o direito em um tribunal de justiça.
Os direitos autorais são regidos pela lei federal.
Se você for um desenvolvedor independente trabalhando com um grupo
de pessoas para criar um jogo que será exposto para um publicador, precisará
que todos na equipe atribuam o direito autoral a você ou a uma empresa co-
mum, como o desenvolvedor. O publicador levará mais a sério sua empresa
e a exposição do jogo se souber que você protegeu os direitos autorais e tem
autoridade para passá-los para ele.
Marcas registradas
As marcas comerciais e de serviço, também conhecidas como marcas registra-
das, são símbolos, palavras ou dispositivos identificadores usados para dis-
* N. de R.T.: No Brasil, o registro de obras autorais, como obras literárias e concepção grá-
fica de personagens, é efetuado na Biblioteca Nacional.
tinguir a mercadoria de marca registrada de outras mercadorias semelhantes.

Por exemplo, a logomarca da Ubisoft é uma marca registrada que distingue os
jogos que essa empresa publica de outros jogos, e a forma de uma garrafa de
Coca-Cola é uma marca registrada que a distingue de outros refrigerantes de
cola. As marcas registradas são regidas por leis federais.
Os direitos de marca registrada impedem que outras pessoas usem uma
marca semelhante, mas não que fabriquem mercadorias parecidas e as ven-
dam com uma marca registrada diferente. Portanto, há uma grande variedade
de sucos de laranja nas mercearias para escolhermos, mas todos identificados
por marcas registradas diferentes.
As marcas registradas devem ser inconfundíveis para conseguir se dife-
renciar de outras mercadorias semelhantes. Algumas marcas registradas são
mais fortes do que outras e, assim, conseguem se impor mais. A força de uma
marca registrada é expressa por vários termos que definem da mais fraca à
mais forte: genérica, descritiva, sugestiva, arbitrária e fictícia. As marcas gené-
ricas são fracas e não distintivas porque usam um termo comum que descreve
o item real, como “Café” ou “Jogo”. Elas não são passíveis de proteção como
marcas registradas.
As marcas descritivas descrevem a função ou a finalidade pretendida da
mercadoria, como “baixo teor de gordura” para mercadorias que têm pouca
gordura. Essas marcas também não são protegidas pela lei de marcas regis-
tradas, a menos que, por meio de um esforço intenso de vendas e marketing,
elas passem a ter uma grande identificação com uma mercadoria ou serviço
específico e adquiram um segundo significado, como em “Holiday Inn”.
As marcas sugestivas não descrevem a mercadoria diretamente e reque-
rem algum raciocínio no que diz respeito a como o termo se aplica à mercado-
ria. São consideradas distintivas e são protegidas como marcas; por exemplo,
os lápis de cor “PrimsacolorTM” e os gravadores de fita “MemorexTM”. As mar-
cas registradas sugerem a função da mercadoria sem descrevê-la realmente.
As marcas arbitrárias são palavras, símbolos e dispositivos comuns que
não têm relação com a mercadoria que estão distinguindo. Os computadores
AppleTM são um exemplo conhecido. Essas marcas são inerentemente distin-
tivas e não precisam adquirir um significado secundário quando usadas como
marca arbitrária.
As marcas fictícias são criadas com a finalidade exclusiva de atuar como
uma marca registrada. Esse é o tipo mais forte de marca registrada e o mais
facilmente fixável; alguns exemplos seriam “KodakTM” e “XeroxTM”.
No Brasil, as marcas devem ser registradas no Instituto Nacional de Pro-
priedade Industrial (INPI). Antes de fazer o registro, você deve fazer uma pes-
quisa completa das marcas registradas para verificar se a marca está disponí-
vel, ou pode contratar uma empresa para fazer isso. Depois que você enviar o
pedido, o instituto determinará se a marca é exclusiva e a registrará.
Segredos comerciais
Segredos comerciais são informações que a empresa mantém em sigilo e que
proporcionam vantagem competitiva. Seu desenvolvimento gera custo e traz va-
lor econômico para a empresa que os possui. Os segredos comerciais são regidos
por leis e a proteção só existe quando as informações são mantidas em sigilo e
não podem ser obtidas legal ou independentemente por outras pessoas. Alguns
exemplos de segredos comerciais seriam métodos, técnicas e fórmulas, sendo
um exemplo bem conhecido a fórmula secreta da Coca-Cola.
Os segredos comerciais também são aplicáveis a ideias viáveis comer-
cialmente, como as ideias para a criação de jogos, mas para que a ideia seja
considerada um segredo comercial, ela deve ser mantida em sigilo. É nes-
sa hora que os contratos de confidencialidade (nondisclosure agreements –
NDAs) são úteis. Se você tiver vontade de compartilhar sua ideia de um jogo
com alguém e quiser que ela continue sendo considerada confidencial, terá
de fazer a pessoa assinar um NDA antes de compartilhar a informação. Con-
sulte “Contratos de confidencialidade (NDA)” mais adiante neste capítulo
para obter mais informações.
Patentes
As patentes são aplicáveis às invenções. Elas impedem que outras pessoas
fabriquem, usem ou vendam a invenção por um período de tempo fixo, que
atualmente é de 20 anos. Para obter uma patente, o inventor deve revelar inte-
gralmente como a invenção funciona, incluindo diagramas e descrições. Uma
ideia não pode ser patenteada. A invenção também deve ser nova, envolver
uma etapa inventiva e ter uma aplicação útil. Por exemplo, as patentes de
software podem envolver coisas como sistemas operacionais, compiladores,
sistemas gráficos e sistemas de arquivos.
No Brasil, as patentes devem ser registradas no INPI e são caras. Além
disso, quando o prazo de 20 anos expira, elas passam a ser de domínio públi-
co e qualquer pessoa pode fabricar, usar ou vender a invenção.*
4.3 Contratos legais
Contratos legais são acordos entre duas ou mais partes que descrevem as
responsabilidades e deveres de cada uma em relação às outras. Como pro-
dutor, você pode fazer parte da negociação dos termos de contratos legais
de fornecedores externos, publicadores e licenciadores. Por exemplo, você
pode ter de determinar o cronograma das etapas e as listas de produtos de
um contrato de desenvolvimento externo. Esta seção fornecerá uma visão
geral de alguns contratos legais comuns em que você pode ser envolvido:
contratos de empregado/consultor, contratos por encomenda, contratos de
confidencialidade (NDA), contratos de publicador e contratos de licença do
usuário final (end user license agreement – EULA).
* N. de R.T.: Software não é registrado como patente no INPI, sendo registrado em uma
categoria especial denominada Programa de Computador.
Contratos de empregado/consultor
Os contratos de empregado/consultor são usados por desenvolvedores inde-
pendentes para garantir que todo o trabalho da equipe de desenvolvimento
seja totalmente de propriedade da empresa. Essencialmente, cada pessoa da
equipe passa seus direitos de PI para a empresa, ou seja, a empresa passa a ter
autoridade para vender os direitos de PI para um publicador, o que torna sua
empresa mais atraente para possíveis publicadores.
Embora os contratos sejam personalizados para uma determinada em-
presa, eles abordam vários pontos principais. A primeira modalidade é para
definir questões de propriedades de PI específicas, como quais PIs pertencem
à empresa e quais pertencem ao empregado, e a segunda é para transferir
coletivamente toda a posse das PIs designadas para a empresa. Além disso,
diretrizes podem ser definidas para empregados que saírem antes do proje-
to ser concluído, como terem de documentar integralmente seu trabalho ou
concordar em não se apropriar de direitos de outros empregados da empresa.
A linguagem pode ser tão restritiva quanto a empresa achar necessário. Esse
tipo de contrato deve ser redigido por um advogado.
Contrato por encomenda

Quando um fornecedor externo criar algo para ser usado no jogo, como mú-
sica, assets gráficos ou código, ele será dono desses assets, estando protegido
por um dos direitos de propriedade intelectual discutidos anteriormente nes-
te capítulo. Ou seja, você não terá nenhum direito legal para usá-los, a menos
que obtenha permissão do fornecedor para fazê-lo. No entanto, isso não sig-
nifica que o fornecedor seja obrigado a lhe conceder direitos exclusivos; ele
também pode querer licenciar esses assets para outras empresas de jogos.
Esse problema pode ser evitado se um contrato de trabalho por enco-
menda for definido antes de qualquer asset ser criado. O contrato em questão
transfere todos os direitos para a pessoa que está contratando o fornecedor e,
para efeitos legais, a parte contratante é considerada a criadora do trabalho.
Por exemplo, se você contratar um compositor por encomenda para a criação
da música, inquestionavelmente será o dono de todos os direitos musicais
após o trabalho ser concluído. Ou seja, você poderá usar a música em outros
produtos que criar ou licenciá-la para outros interessados usarem.
É importante ressaltar que só há duas situações em que um contrato por
encomenda pode existir. A primeira é aquela em que um fornecedor externo
é comissionado para criar um trabalho totalmente novo e assina um contrato
por encomenda antes de começar a trabalhar. Além disso, o trabalho deve
se encaixar em uma das categorias de trabalho comissionado detalhadas na
Lei de Direitos Autorais: uma tradução, um texto educativo, um teste, as
respostas de um teste, um atlas, a contribuição em um trabalho coletivo,
uma compilação, material complementar ou a contribuição em um filme ou
outro trabalho audiovisual. Por exemplo, um artigo a ser publicado em uma
revista poderia ser um contrato por encomenda, já que é uma contribuição
feita para um trabalho coletivo, mas um romance não poderia ser um con-
trato por encomenda, porque não se encaixa em nenhuma das categorias

mencionadas anteriormente.
A segunda situação do contrato por encomenda envolve qualquer traba-
lho criado por funcionários que faça parte de seu escopo empregatício. Por
exemplo, qualquer código escrito por um programador que for funcionário
de sua equipe de desenvolvimento será trabalho por encomenda. Ele não é
dono dos direitos do trabalho, já que esses são mantidos pelo empregador. É
claro que essa situação pode se complicar no trabalho com funcionários em
período não integral, e nesse caso um advogado deve ser consultado. Para ob-
ter mais informações sobre contratos por encomenda, consulte a circular do
Escritório de Direitos Autorais dos Estados Unidos chamada “Works Made for
Hire Under the 1976 Copyright Act”, que está listada no Apêndice C.
Contratos de confidencialidade (NDA)

Como discutido na seção sobre PIs, os conceitos e ideias dos jogos não são
protegidos por direitos autorais e marcas registradas – ou seja, o desenvolve-
dor deve protegê-los como segredos comerciais, e um contrato de confiden-
cialidade (non-disclosure agreement – NDA) pode ajudar. Basicamente, um
NDA declara que o que você está discutindo com a outra parte deve permane-
cer em sigilo, permitindo assim que os conceitos sejam considerados segredos
comerciais. Se você discutir seu conceito com alguém que não tiver assinado
um NDA, o conceito perderá seu status de segredo comercial e passará a ser
de domínio público. Logo, se quiser proteger suas ideias, não as discuta com
ninguém sem ter um NDA assinado.
Os dois tipos comuns de NDA são o unilateral e o mútuo. Um NDA uni-
lateral é usado quando discutimos o conceito do jogo com alguém que não faz
parte da indústria de jogos, como um investidor independente. Essa modali-
dade protege qualquer ideia discutida com o investidor, porque ele não tem
segredos – nós sim. Um NDA mútuo é usado quando as pessoas da indústria
discutem ideias umas com as outras, como quando um publicador discute
conceitos do jogo com um desenvolvedor independente. Essa modalidade
protege as informações reveladas pelas duas partes. Em casos como esse, o
publicador costuma fornecer o NDA.
O problema é que a maioria dos publicadores reluta em assinar qualquer
tipo de NDA com desenvolvedores externos. Isso ocorre porque os publicado-
res examinam centenas de jogos por ano; há o risco de já terem em produção
ou nos estágios conceituais um jogo semelhante ao que está sendo apresenta-
do. Podemos pedir, mas provavelmente eles não assinarão. É claro que essa
situação cria um dilema para qualquer desenvolvedor que está expondo uma
ideia, mas é quase certo que se o publicador não estiver interessado em seu
jogo, ele dirá isso e não vai querer copiá-lo.
Contratos de desenvolvimento
Os contratos de desenvolvimento entre publicador e desenvolvedor externo
descrevem quais responsabilidades uma parte tem com a outra. Esses contra-
tos cobrem todas as questões envolvidas no relacionamento desenvolvedor/

publicador, inclusive os termos financeiros, elementos do projeto, cronogra-
mas das etapas de entrega de assets e adiantamentos financeiros, posse de PI,
planos de marketing, planos de distribuição e obrigações de cada parte.
Os termos financeiros definirão o cronograma de pagamentos e a estrutura
de royalties. Geralmente, os adiantamentos do desenvolvedor são divididos em
uma série de pagamentos vinculados aos produtos entregues nas etapas. O con-
teúdo e os prazos de uma etapa específica serão detalhados na seção do contrato
referente às obrigações do desenvolvedor. Além disso, diretrizes específicas de
envio e aprovação são definidas para cada produto.
Um dos itens mais importantes abordados no contrato é a transferência
de direitos de PI do desenvolvedor para o publicador. Isso significa que o
desenvolvedor abrirá mão de todos os direitos do código, personagens, textu-
ras, história, conceitos e o que mais entrar na criação do jogo. Também pode
abranger qualquer ferramenta proprietária que o desenvolvedor criar para oti-
mizar o processo de desenvolvimento do jogo, como ferramentas de script,
editores de textura ou plug-ins de software. Se o jogo for baseado em uma
licença existente, como a de um filme, diretrizes detalhadas sobre como o
desenvolvedor pode utilizar a licença serão incluídas.
Os contratos de desenvolvimento também discutem outras contingên-
cias, como quem é responsável pelo teste de QA, localização, publicidade e
direitos ancilares (por exemplo, negociações referentes à área cinematográ-
fica e televisiva). Além disso, como nos contratos de empregado/consultor,
também são incluídas informações sobre como disputas entre as partes se-
rão arbitradas. O publicador é responsável por finalizar o contrato de publi-
cação, mas o desenvolvedor precisará que um advogado o examine antes de
assinar.
Contrato de licença do usuário final (EULA)

Os contratos de licença do usuário final (end user license agreement – EULA)
protegem o publicador e estabelecem um contrato de licença entre o dono da
PI e o usuário final. A finalidade básica do EULA é evitar a revenda e o alu-
guel do jogo. No entanto, devido à maneira como os jogos de console foram
originalmente classificados para efeitos de direitos de PI, eles podem ser re-
vendidos e comercializados. É por isso que podemos alugar jogos de console
ou comprar cópias usadas na loja de games local. Para jogos de PC, o EULA
pode ser redigido de modo a tornar a revenda ilegal. Geralmente, o publicador
fornece um EULA padrão para jogos qualificados.
4.4 Licenças
TM TM
Os jogos baseados em licenças, como Spider-Man , James Bond ou Natio-
TM
nal Football League , estão se tornando mais comuns a cada ano. O interesse
dos produtores em proteger licenças conhecidas se dá pela possibilidade de
cativar um público que já está familiarizado com a marca, o que desperta

mais atenção para o jogo e se converte em mais vendas. Por exemplo, é mais
fácil vender um jogo de aventura baseado em Harry Potter do que um jogo
que apresente personagem e universo desconhecidos. Um jogo “Harry Pot-
ter” significa imediatamente que terá Harry e seus amigos, magos, aventuras
fantásticas, criaturas míticas e vários personagens mágicos. Um personagem
desconhecido não gera nenhuma associação imediata, portanto, os jogadores
têm de ser informados sobre os elementos existentes.
APROVAÇÕES DE LICENÇAS
Stuart Roch, Produtor Executivo

Activision
No que diz respeito especificamente a problemas de cronograma, muita atenção deve ser
dada por parte do produtor ao envio de pacotes de aprovação bem mais cedo do que
normalmente seria necessário. Ao lidar com um jogo de filme licenciado, o produtor tem
de considerar o tempo de retorno mais longo que resulta de cronogramas de produção de
filmes ativos, principalmente quando os diretores fazem parte do processo criativo.
Em Enter the Matrix, a Warner Brothers aprovou muitos dos assets, mas na maioria
dos casos fez isso por razões legais e não de criação. Já que os irmãos Wachowski estavam
tão envolvidos na criação do jogo, a Warner Brothers permitiu que eles fossem responsá-
veis pela maioria das aprovações relacionadas à área de criação, tendo tempo para nos
ajudar mais com o lado empresarial da produção do jogo.
Enter the Matrix foi ainda mais peculiar do que outros jogos licenciados porque os
irmãos Wachowski ajudaram muito desde o início, nos dando um passe de acesso quase
total à produção do filme. Por termos um relacionamento não tradicional e totalmente
complementar com os irmãos Wachowski, eles abriram portas para nós que, de outra
forma, não teríamos conseguido abrir. Sendo no trabalho com o protagonista, o designer
de figurino, a equipe de efeitos visuais ou até mesmo ouvindo ideias dos próprios irmãos,
o toque pessoal dos Wachowski significou o nível de colaboração mais próximo que já
tínhamos experimentado até o momento com a produção do filme.
Normalmente o produtor não é envolvido no processo de garantia dos

direitos interativos de uma licença; em vez disso, ele recebe o projeto com
uma licença específica já vinculada. Ou seja, o produtor deve planejar o im-
pacto que isso terá sobre a produção, principalmente sobre o design, o crono-
grama e a criação de assets.
Dependendo de como a negociação do licenciamento for estruturada,
o licenciador pode ter um envolvimento ínfimo na produção do jogo ou um
envolvimento fundamental na determinação do design, dos assets e dos re-
cursos do jogo. No mínimo, provavelmente ele terá direitos de aprovação do
conceito geral e dos principais assets do jogo, já que sua maior preocupação é
proteger a integridade da licença. Por exemplo, na criação de um jogo baseado
em um desenho animado da Disney, provavelmente o desenvolvedor não te-
ria permissão para criar um conteúdo de classificação M, já que esses títulos
são direcionados às crianças; portanto, um jogo nunca fará alusão a Mickey
Mouse protagonizando uma matança indiscriminada. Essas aprovações têm
de ser claramente explicadas no contrato de licenciamento e o produtor deve
considerá-las no cronograma. Você não vai querer atrasar a produção de um
título porque esqueceu de reservar duas semanas para receber do licenciador
a aprovação final do conceito do jogo.
Além disso, pode haver um documento volumoso explicando claramen-
te o que pode ou não ser feito com os personagens e ambientes baseados em
uma licença. Ele pode detalhar que tipos de vestimenta o personagem usa,
que ações pode executar no jogo, que outros personagens do universo podem
aparecer e assim por diante. O produtor precisa ter essas informações durante
a pré-produção para que todas sejam consideradas e integradas apropriada-
mente ao jogo. Acima de tudo, o produtor deve ser proativo quando trabalhar
com licenças; portanto, o estabelecimento de um bom relacionamento com
seu contato licenciador é a primeira etapa para assegurar que aprovações,
conceitos e assets sejam liberados rapidamente.
Crie um cronograma para o licenciador que mostre quando os assets e as
builds serão enviados para aprovação e indique o prazo para seu recebimento,
TRABALHANDO COM UM LICENCIADOR
Jamie Fristrom
Torpex Games
Ao trabalhar com um licenciador, temos de adicionar algum tempo ao cronograma de

produção para o recebimento da aprovação de todos esses materiais, e geralmente os
licenciadores usam o tempo que acham necessário. Você pode ter cláusulas nos contratos
que limitem quanto tempo eles terão para aprovar algo; se não tiver uma resposta quando
o prazo expirar, isso indicará “aprovação” e você poderá prosseguir com a produção.
Em algumas situações, você se verá trabalhando com dois licenciadores: por exem-
plo, um filme baseado em um livro ou história em quadrinhos. Os direitos de aprovação
serão divididos entre os licenciadores ou você terá de enviar todo o material para as duas
partes.
Possivelmente, seu licenciador deixará a mecânica do jogo e a documentação do
design por sua conta, mas vai querer ver builds regulares do jogo para ter uma ideia de
como o processo está avançando. É provável que haja muitas coisas que você não poderá
fazer com o personagem dele. Por exemplo, talvez não possa matar alguém, o que afetará
o design do jogo. Isso pode ser desafiador, mas o ajudará a ser criativo e fazer coisas que
ainda não foram feitas nos jogos.
de modo que o licenciador tenha uma ideia melhor de como esses ciclos de
aprovação afetam o cronograma do jogo. Se você puder ser proativo dando ao
licenciador tudo que ele precisa, terá mais probabilidade de estabelecer uma
relação de trabalho positiva com ele.
Embora não se espere que o produtor tenha conhecimento de todas as ques-

tões legais envolvidas no desenvolvimento de um jogo, ele deve ter um co-
nhecimento geral de algumas dessas questões, principalmente direitos de
propriedade intelectual, contratos de desenvolvedor e licenças. Este capítulo
apresentou uma breve visão geral dessas questões e forneceu exemplos, para
que os produtores estejam mais preparados para discuti-las.
O próximo capítulo discutirá o relacionamento entre desenvolvedor e
publicador, informações sobre como expor um jogo para um publicador e
como gerenciar o relacionamento desenvolvedor-publicador. Esses elementos
serão importantes para qualquer produtor que estiver gerenciando um desen-
volvedor independente e procurando um parceiro publicador.
5
RELACIONAMENTO ENTRE
O DESENVOLVEDOR E O
PUBLICADOR
Neste capítulo
• Apresentando • Gerenciando o • Aprovações de jogos
um jogo para um relacionamento por terceiros
publicador desenvolvedor-
-publicador
5.1 Introdução
Os desenvolvedores devem ter uma comunicação aberta com seu publicador,

pois ele é o responsável pelo produto final e por sua venda para possíveis
compradores. Os publicadores devem trabalhar bem com os desenvolvedores,
porque sem eles não há produtos para vender. Esse relacionamento pode ser
muito complexo, principalmente quando um desenvolvedor independente e
um publicador trabalham juntos. Mais complexidade é adicionada quando
eles trabalham em um título de console ou celular que é enviado a um fabri-
cante de consoles para aprovação. Este capítulo discutirá os principais aspec-
tos do relacionamento desenvolvedor-publicador, da apresentação de um jogo
para um publicador ao gerenciamento da relação desenvolvedor-publicador.
5.2 Apresentando um jogo para um publicador
À medida que fica mais caro criar jogos e são necessárias equipes maiores,
os publicadores ficam mais seletivos quanto aos desenvolvedores com que
querem trabalhar. Geralmente, os desenvolvedores internos têm acesso direto
às pessoas que tomam decisões sobre que jogos serão desenvolvidos e, por-
tanto, não ficam sob tanta pressão para criar e expor a ideia de um jogo. Se
um desenvolvedor interno não tiver uma ideia para um jogo, provavelmente
o publicador terá um jogo em mente para o desenvolvedor.
Desenvolvedores independentes, por outro lado, devem encontrar um
parceiro de publicação que os ajude a terminar o jogo e colocá-lo nas prateleiras
das lojas. O desenvolvedor pode ter uma ótima ideia para um jogo e já estar em
sua pré-produção, mas a menos que consiga encontrar um publicador, prova-
velmente o jogo não será lançado ou dará retorno. Para encontrar um parceiro,
os desenvolvedores devem demonstrar seus jogos para possíveis publicadores.
Demonstrar um jogo não é tarefa fácil, já que o desenvolvedor tem de
conseguir comunicar com sucesso toda a experiência que o jogador vivencia-
rá, mesmo se o jogo ainda não tiver sido concluído – na verdade, o jogo ainda
pode estar na fase conceitual e não ter assets tangíveis. A partir da demons-
tração, o publicador deve ter uma visão clara sobre se o jogo proporcionará a
experiência proposta e será lucrativo.
DEMONSTRANDO PARA UM PUBLICADOR
Don Daglow, presidente e CEO

Stormfront Studios
Quase todos os desenvolvedores fazem demonstrações para publicadores. No começo da

história desse segmento industrial o processo era muito menos formal. Relacionamentos
de longo prazo entre desenvolvedor e publicador desempenhavam um papel importante
no desenvolvimento de novos jogos e as ideias eram discutidas em conjunto e então apro-
vadas. Na última década, a indústria de jogos mudou seu foco para equipes de criação
internas. Como no caso de outras mídias de entretenimento, agora os publicadores de
jogos procuram ativamente demonstrações de desenvolvedores externos como meio de
avaliação, não dependendo apenas de seus esforços criativos internos.
O bom nesse processo de demonstração altamente desenvolvido é que um desen-
volvedor estabelecido pode conseguir imediatamente uma reunião com os principais to-
madores de decisão. Contudo, se você desperdiçar o tempo das pessoas, pode perder esse
status “nossas portas estão abertas, procure-nos quando quiser”. Certifique-se de fazer
bom uso do tempo dos publicadores no momento da exposição. Você pode não conseguir
um contrato, mas deixe a sala com sua reputação fortalecida pelo que ocorreu durante a
reunião. Os publicadores o receberão novamente na próxima vez que você estiver pronto
para demonstrar uma oportunidade.
5 • Relacionamento entre o Desenvolvedor e o Publicador 73
Como os publicadores veem demonstrações de várias centenas de jogos

por ano, a maioria deles tem algum tipo de processo de demonstração esta-
belecido, o que lhes permite conhecer rapidamente o potencial do jogo. Esse
processo os ajuda a decidir quais jogos não são adequados às suas necessida-
des e quais merecem mais atenção e, possivelmente, algum suporte financeiro
inicial. O processo de demonstração varia com base em coisas como o tipo
de jogo que está sendo exposto, para quem ele está sendo exposto, há quanto
tempo o jogo está em desenvolvimento e qual o tipo de parceria necessária.
SOLICITAÇÃO DE PROPOSTAS

Stormfront Studios
Normalmente, os publicadores remetem Solicitações de Proposta (SPs), principalmente

no caso de propriedades licenciadas ou projetos menores. (Projetos maiores costumam ser
manipulados por equipes internas do publicador.) A SP inclui informações sobre a proprie-
dade, a plataforma de destino, a estimativa de orçamento e a data de entrega desejada.
Os publicadores fazem uma pesquisa antes de contatar os desenvolvedores e enviam uma
SP para as três a cinco equipes que acharem ser as melhores para um projeto específico.
Alguns publicadores podem enviar uma SP com o design completo de um jogo (incluindo
sua mecânica, personagens, designs de níveis etc.). Nesse caso, estão procurando um de-
senvolvedor para manipular o projeto na forma de um “contrato por encomenda”, em que
o design foi concluído e o desenvolvedor fornece as “mãos” que o implementarão.
Alguns publicadores procuram o trabalho de maior qualidade, outros o de menor
preço, mas a maioria tenta equilibrar custo e qualidade. Quando os desenvolvedores dão
sua resposta a uma SP, eles redigem um relatório esclarecendo aspectos relacionados às
solicitações específicas de conteúdo da SP, descrevendo elementos-chave da jogabilidade
e fornecendo um cronograma e um orçamento estimados. Geralmente, protótipos são
feitos de acordo com as especificações em resposta às SPs por serem muito caros. No
entanto, os desenvolvedores podem recorrer a exemplos de outros jogos que ilustrem pon-
tos-chave discutidos em sua resposta. No estágio de envio de SPs, os publicadores estão
mais interessados no orçamento, no cronograma e em saber se o jogo será divertido – se
tivessem dúvidas quanto ao talento do desenvolvedor, este nem receberia uma SP.
Alguns desenvolvedores não transmitem as informações apropriadas

para o publicador tomar uma decisão inicial sobre o valor do jogo. Já que os
publicadores examinam várias centenas de jogos por ano, é essencial que o
desenvolvedor saiba que informações e materiais serão necessários na expo-
sição. A melhor maneira de saber como demonstrar um jogo com sucesso é
conversar com outros desenvolvedores e com alguém do departamento de
compras do publicador. Lee Jacobson, vice-presidente de compras e desen-
volvimento empresarial da Midway Entertainment, tem algumas sugestões
específicas sobre o que é necessário para se preparar um jogo interessante.
COMO DEMONSTRAR UM JOGO
Lee Jacobson, VP de compras e desenvolvimento empresarial

Midway Entertainment
Entre 10 e 15 anos atrás, o importante nos jogos era a inovação trazida pela jogabili-
dade. Agora que os jogos evoluíram para se tornar um entretenimento mais popular, o
importante é contar histórias e como elas são executadas. Além disso, à medida que os
jogos vão ficando mais caros, os publicadores têm mais departamentos, como publica-
ção, marketing, vendas e desenvolvimento de produtos, opinando nas decisões tomadas.
Já que tantas pessoas estão envolvidas, um desenvolvedor independente expondo um jogo
original tem de conseguir transmitir a ideia em um período de tempo muito limitado. Há
três recursos muito importantes na avaliação do potencial de publicação de um jogo.
O primeiro é dar um tratamento bem sucinto ao jogo. Seria uma sinopse de uma
a duas páginas explicando sua essência, como ele pode ser posicionado no mercado e
como pode ser divulgado para o cliente ou varejista. Se você tiver que fazer uma longa
dissertação explicando os méritos do jogo, é provável que o consumidor não entenda
imediatamente seu atrativo.
Não perca tempo criando um documento de design detalhado. No estágio de de-
monstração, isso não é importante. Em primeiro lugar, porque os publicadores não terão
tempo para lê-lo. Além disso, após o publicador começar a trabalhar com um desenvol-
vedor, seu feedback afetará o design do jogo. Infelizmente, a maioria dos desenvolvedores
perde tempo redigindo um documento detalhando toda a mecânica e os recursos maravi-
lhosos de seu jogo, mas não conseguem descrevê-lo em uma ou duas frases que demons-
trem por que as pessoas vão querer comprá-lo.
O segundo recurso, que na verdade está se tornando obrigatório, é um protótipo ou
uma fatia vertical jogável. Não precisa ser longo, mas deve mostrar como será a aparência
final do jogo e como ele será jogado – sem desculpas para a qualidade visual, a qualidade
da animação, os valores da produção, cortes de câmera, iluminação e assim por diante.
Os publicadores vão preferir ver uma fatia de dois minutos da experiência, onde o ambien-
te tenha uma aparência fantástica, em vez de um universo imenso que possa ser explorado
durante quatro horas mas que tenha uma aparência horrível.
Uma demo altamente polida tem mais chances de levar o desenvolvedor à próxima
etapa do processo de exposição. Ela permite que o publicador saiba que o desenvolvedor
não só entendeu a essência do jogo como também sabe o que o consumidor precisa ver.
Esse detalhe é importante; muitos desenvolvedores o ignoram e não percebem que não
interessa o que eles acham arrojado e sim o que é arrojado para o consumidor.
A terceira coisa é um trailer do jogo. Ele só precisa ter de trinta segundos a um
minuto, mas, a partir do momento que começar, tudo – inclusive a música ambiental, a
animação, a disposição dos elementos e os ângulos da câmera – deve funcionar conjun-
tamente para transmitir a experiência emocional do jogo. Tem de ser editado da maneira
certa, narrado corretamente e intercalado por filmagens do jogo para dar ao publicador
uma ideia de como ele é arrojado.
Os altos valores de produção do trailer reforçarão a ideia de que, além do de-
senvolvedor saber criar um jogo, ele também sabe como transformá-lo em um meio de
entretenimento. Esses trailers podem ser disseminados facilmente na empresa do publi-

cador, permitindo que as pessoas vejam imediatamente se o jogo funciona ou não. Eles
também são úteis porque qualquer pessoa poderá assistir ao vídeo e ver facilmente os
destaques do jogo.
Os desenvolvedores também podem preparar outros materiais de apoio para de-
monstrar que conhecem o mercado em que o jogo está inserido e o que eles querem que o
jogo faça – por exemplo, uma visão geral muito breve dos produtos rivais do jogo e como
os recursos do jogo o tornam diferente do que já existe. Não cometa o erro de listar recur-
sos técnicos como recursos do jogo, por exemplo, um melhor mapeamento de normais.
Em vez disso, concentre-se no que diferencia o jogo e em como o publicador pode vendê-
-lo para um público mais amplo. Outras informações que podem ser incluídas seriam um
resumo de outros jogos criados pelo desenvolvedor e a opinião da crítica. Informações
dessa natureza ajudam o publicador a determinar os riscos que um desenvolvedor pode
trazer. Para concluir, inclua uma avaliação inicial do cronograma e da estimativa de or-
çamento; essas informações serão detalhadas à medida que o jogo avançar no processo.
O acordo típico é o modelo padrão publicador-desenvolvedor em que o publica-
dor patrocina 100% do desenvolvimento do jogo antecipadamente visando às vendas e
royalties futuros. Nesse acordo, normalmente o publicador fornece o software comercial
de terceiros, as ferramentas e os kits de desenvolvimento. O desenvolvedor é solicitado a
concluir etapas mensais (milestones) que são avaliadas regularmente pelo publicador. Vá-
rias estruturas de royalties podem ser ventiladas para dar suporte a esse modelo. À medida
que o perfil de risco passar do publicador para o desenvolvedor, o acordo pode mudar.
Também há acordos de copublicação. Nesse caso, o jogo quase sempre é totalmen-
te patrocinado pelo estúdio de desenvolvimento que procura um publicador responsável
por embalar e distribuí-lo para os varejistas. O publicador recebe uma taxa de distribui-
ção, que costuma ser uma percentagem das vendas do jogo. A taxa vai depender do que o
publicador trouxer para a negociação, que pode ir da embalagem e distribuição do jogo
ao patrocínio da campanha de marketing.
5.3 Gerenciando o relacionamento desenvolvedor-publicador
Após um desenvolvedor e um publicador terem acordado um relacionamen-

to, esse deve ser mantido, não importando se o desenvolvedor é indepen-
dente ou trabalha para o publicador. O básico para que o relacionamento seja
mantido é semelhante nos dois casos – o publicador tem de ser informado
sobre o progresso do jogo e o desenvolvedor precisa de recursos e suporte
provenientes do publicador.
Negligenciar esse relacionamento pode ser prejudicial para o processo
de desenvolvimento. Se o desenvolvedor não conversar com o publicador re-
gularmente sobre o progresso do jogo, o publicador pode ficar frustrado com
a aparente falta de progresso. Essa frustração pode fazer o publicador alocar
os recursos necessários para outro projeto, atribuir o projeto a outro desenvol-
vedor ou cancelá-lo. Se o publicador não der feedback para o desenvolvedor
no decorrer do processo de produção, o desenvolvedor pode atender todos os
requisitos das etapas, mas talvez o produto final não seja o que o publicador
esperava. Em casos como esse, o publicador pode pedir mudanças adicionais
após o término, o que significará mais custos e recursos tanto para o desenvol-
vedor quanto para o publicador.
Esse relacionamento pode ficar mais complexo porque tanto o desenvol-
vedor quanto o publicador apostaram muito no sucesso do jogo e farão o que
puderem para assegurá-lo. A complexidade aumentará ainda mais quando
ambos os lados opinarem sobre a abordagem de certas coisas no jogo. Por
exemplo, com frequência os publicadores designam seu produtor para tra-
balhar com o desenvolvedor, junto ao produtor deste. Essa situação de haver
dois produtores no projeto pode gerar alguma confusão se as responsabilida-
des dos dois produtores não forem claramente definidas.
O Produtor Publicador (PP) é o representante da empresa publicadora
e se certificará de que todos os esforços de vendas, marketing, operações e
testes estejam em sincronia com o cronograma de produção do jogo. Quase
sempre ele é responsável por examinar os produtos das etapas do desenvolve-
dor e autorizar o pagamento. Responsabilidades adicionais poderiam incluir
coordenar as tarefas de marketing e localização do jogo, lidar com aprovações
de licenças e agir como advogado do desenvolvedor no publicador.
Mesmo se a desenvolvedora for propriedade do publicador, ela conti-
nuará remetendo builds para aprovação, mas terá uma vantagem por já es-
tar na folha de pagamento do publicador. O pagamento da desenvolvedora
não estará vinculado à conclusão dos produtos das etapas. Isso não a eximirá
de concluir as etapas a tempo, mas lhe dará mais flexibilidade em relação a
quando essas etapas serão examinadas.
O PP não é responsável pelo gerenciamento diário da equipe de desen-
volvimento. Essa responsabilidade é do Produtor Desenvolvedor (PD). O PD
é responsável por criar o plano de desenvolvimento do jogo e se certificar de
que esse plano seja concluído durante o ciclo de produção. Ele lida com qual-
quer problema de RH que ocorrer na equipe, solicitações de equipamento e o
que mais afetar diretamente as pessoas da equipe de desenvolvimento.
RELACIONAMENTO DESENVOLVEDOR-PUBLICADOR

1st Playable Productions
As diferenças dos papéis de um produtor em um estúdio independente e em um estúdio

de posse do publicador são muito acentuadas. Em alguns aspectos, elas são iguais; mas
em outros, o relacionamento com o cliente muda totalmente.
Por exemplo, no trabalho em um estúdio independente, cada contrato oferece um
risco comercial significativo se algum atraso ou outros problemas forem encontrados.
Você pode perder muito dinheiro e colocar seu negócio em risco, pode perder esse cliente
e prejudicar a empresa. Além disso, já que provavelmente seus clientes terão seus próprios
processos e sistemas, a cada projeto você terá de converter qualquer que seja o conjunto
de processos e sistemas que seus clientes estiverem usando para os sistemas internos usa-
dos por sua equipe de desenvolvimento – bancos de dados de bugs, formulários, proces-
sos de aprovação etc.
Em um estúdio do publicador, você pode ficar sujeito ao mal-humor de seu chefe
caso se atrase ou exceda o orçamento, mas as consequências serão muito mais amenas
já que é improvável que o estúdio seja fechado (a menos que esse seja o único projeto em
que você está trabalhando e seu desempenho apresentar falhas repetidas). Além disso, há
muito mais obediência dentro de um estúdio interno em relação a processos e sistemas.
Já que você só tem um cliente, todos os seus processos serão consistentes com os do pu-
blicador e poderão ser otimizados. No entanto, agora o projeto tem mais visibilidade para
seu cliente, que tem muito mais controle direto sobre tudo, dos recursos à abordagem de
desenvolvimento. Por exemplo, em vez de debater o preço de um projeto e fornecer um
serviço que fará o cliente selecioná-lo, descartando outros desenvolvedores, você tem de
conseguir justificar seu orçamento e negociar um escopo e um cronograma viáveis com
o departamento de marketing. Logo, em um estúdio interno, o aspecto do papel do pro-
dutor referente ao gerenciamento do cliente é muito diferente; ele passa a ser mais um
gerenciamento da hierarquia da empresa em contraste com o gerenciamento de clientes.
No depoimento a seguir, Jeff Matsushita discute como mantém o ciclo de

desenvolvimento no caminho certo na Activision. Também discute o relacio-
namento desenvolvedor-publicador.
RESPONSABILIDADES DO DESENVOLVEDOR E DO PUBLICADOR
Jeff Matsushita, produtor executivo

Activision
A maioria das empresas tem um método formal de supervisão do progresso dos títulos
em produção. Em meu papel atual na Activision, é minha função usar esse tipo de pro-
cesso para assegurar que o ciclo de desenvolvimento permaneça no caminho certo, que
o produto atenda as expectativas e que todos os envolvidos com o produto trabalhem
em sintonia. Nessa experiência e nas anteriores, tive o privilégio de trabalhar com muitos
desenvolvedores, tanto internos quanto externos, e de entender alguns aspectos interes-
santes da maneira como os desenvolvedores e publicadores trabalham juntos.
Muitos fatores afetam o relacionamento entre o desenvolvedor e o publicador,
como os termos do acordo, o desenvolvedor ser interno ou externo e o histórico do desen-
volvedor quanto à entrega de títulos de alta qualidade no prazo e conforme o orçamento.
Outro fator que influencia esse relacionamento é quem traz a Propriedade Intelec-
tual (PI) para o negócio. Por exemplo, o publicador se sentirá mais confiante em relação a
um projeto se fornecer a PI. Nesse caso, provavelmente ele terá mais feedback no processo
de desenvolvimento, já que deseja que sua licença seja representada de maneira apro-
priada. O publicador acaba se tornando o cliente do desenvolvedor. Por outro lado, se o
desenvolvedor trouxer a PI para o negócio, o publicador trabalhará com ele para assegurar
que haja um esforço sólido de marketing dando suporte à visão que o desenvolvedor tem
do jogo. Esses exemplos são raros, já que o desenvolvedor deve trazer uma franquia for-
temente estabelecida e ter experiência na sua execução ou ter um jogo de alta qualidade
bem perto da conclusão.
Devido aos orçamentos cada vez maiores necessários no desenvolvimento e venda
de jogos AAA, os publicadores tomam mais cuidado com propriedades e desenvolvedores
desconhecidos. Quase sempre, eles só trabalham com desenvolvedores conhecidos e PIs
estabelecidas. Além disso, os publicadores preferem trabalhar com um desenvolvedor in-
terno em uma nova PI para poderem ter maior controle sobre o projeto e avaliar melhor
os riscos.
O projeto é resultado do trabalho árduo do desenvolvedor – o programa, a arte, o
som, e assim por diante. O produto é o pacote final que é anunciado na mídia, entregue
aos distribuidores e comprado por clientes. Em resumo, o publicador é responsável por
pegar o projeto do desenvolvedor e transformá-lo em um produto. O publicador pega o pro-
jeto, planeja a embalagem, acondiciona na caixa e manipula as vendas e a distribuição do
produto. Quando a PI vem do publicador, ele também pode patrocinar o desenvolvimento
e fornecer os elementos criativos básicos iniciais. O importante é que o publicador pegue
os esforços do desenvolvedor e os converta em algo que produza receita para todos. Em
termos mais elementares, poderíamos dizer que o publicador atua na área de venda de
jogos e o desenvolvedor tem a função de criá-los.
Para facilitar esse processo, o publicador designa um produtor para trabalhar no
título. Esse produtor da parte do publicador é responsável por gerenciar o risco geral asso-
ciado ao desenvolvimento do projeto, o que inclui assegurar que o desenvolvedor forneça
tudo que foi prometido a tempo e gerencie a equipe de desenvolvimento de maneira efi-
caz. Além disso, o produtor trabalha com o desenvolvedor para ajudá-lo a criar o melhor
jogo possível. O produtor fornece recursos do publicador para o teste de foco das funcio-
nalidades e dá feedback para o desenvolvedor. Para concluir, ele também gerencia todos
os processos de produção para garantir que os esforços de desenvolvimento, marketing,
testes e localização permaneçam em sincronia.
O desenvolvedor, por outro lado, é responsável por executar o projeto. A menos que
haja recursos específicos relacionados à PI trazidos ao projeto pelo publicador, isso inclui
tudo que for necessário ao desenvolvimento do software e geralmente é fornecido para
o publicador na forma de produtos predeterminados nos estágios iniciais do acordo. A
decisão de como gerenciar a equipe do projeto fica a cargo do desenvolvedor. O publi-
cador não tem necessariamente que opinar como os produtos serão criados, contanto
que eles sejam entregues no prazo. No entanto, se forem entregues com atraso, tiverem
baixa qualidade ou o desenvolvedor estiver mostrando sinais claros de que está tendo ou-
tros problemas, provavelmente o publicador terá maior interesse em como o projeto está
sendo executado. Isso não significa que ele vai querer interferir e assumir o controle, mas
pode exigir uma visibilidade maior do projeto para verificar se tudo está correndo bem no
desenvolvimento do jogo e se seu investimento não está em risco.
Para evitar que problemas assim ocorram, o desenvolvedor deve fornecer o máxi-
mo de informações possível ao concluir etapas para os publicadores para tornar as ex-
pectativas mais realistas. Por exemplo, um jogo raramente tem boa aparência no início
do desenvolvimento. Um protótipo contendo apenas cenas básicas, controles básicos e
efeitos visuais básicos provavelmente não impressionará muitas pessoas que não tiverem
um contexto onde encaixá-lo. Quando o desenvolvedor fornecer esse tipo de build, é es-
sencial que ele passe algum tempo contextualizando cuidadosamente os produtos para
que todos entendam por que os materiais foram bem-sucedidos e como eles mostram
que o desenvolvimento está prosseguindo com um nível mínimo de risco à qualidade, ao
cronograma e, às vezes, até mesmo ao orçamento. O publicador quer entender como uma
parcela tão limitada do jogo se encaixa no plano de desenvolvimento e como ela evoluirá
para um título AAA.
Outro aspecto do estabelecimento de um contexto é o desenvolvedor ser claro
quanto ao que significa “concluído”. Quando não é explicitamente definido, o termo
“concluído” pode significar qualquer coisa, como ser visto em um kit de desenvolvimento
ainda sem a arte, ter recursos básicos jogáveis in-game ou não ter bugs e estar pronto
para distribuição. É claro que se o publicador estiver esperando um nível de qualidade
final e o desenvolvedor só quiser fornecer uma primeira versão, as pessoas acabarão ques-
tionando o valor da build final e inevitavelmente começarão a duvidar do progresso do
desenvolvimento como um todo. Mas se houver detalhes sobre o que foi incluído no pro-
duto – por exemplo, 10% de todas as animações foram concluídos, polidos e podem ser
vistos in-game junto com a lista de animações concluídas –, o publicador terá uma visão
muito melhor do que foi incluído no produto. Portanto, poderá avaliar melhor o estado
do jogo. Se o publicador estiver examinando um produto que o desenvolvedor disse estar
concluído, e estiver óbvio que não foi, ele perderá a confiança no desenvolvedor e este não
entenderá por quê.
Para amenizar isso, a maioria dos publicadores prefere que o desenvolvedor escla-
reça as peculiaridades das etapas. Nesses casos, o publicador não impõe qual será o con-
teúdo de cada produto, mas pode ter definições do que é esperado nas versões alfa, beta,
primeira versão jogável etc., que correspondam apropriadamente ao estado do desenvol-
vimento. O desenvolvedor é responsável por dizer ao publicador quando o mecanismo do
jogo, as animações, a arte, a IA etc. serão concluídos e por gerenciar o projeto para que
essas etapas sejam executadas. O publicador só se envolverá no processo de desenvolvi-
mento se achar que as tarefas não estão sendo executadas e seu desenvolvimento está
correndo risco.
Qualquer que seja a situação, é importante que haja um relacionamento sólido en-
tre publicador e desenvolvedor. Tanto o publicador quanto o desenvolvedor têm obriga-
ções a cumprir para que o título seja bem-sucedido. O mais importante é gastar o máximo
de tempo possível para esclarecer as particularidades dos produtos. Já que o critério final
que define o êxito do desenvolvimento é se o jogo é ou não divertido – um conceito no
mínimo abstrato –, é importante que em todos os outros aspectos a comunicação se dê
nos termos mais concretos possíveis.
Desenvolvedor independente
Desenvolvedores independentes dependem muito da verba do publicador
para a conclusão de um jogo. Para o publicador selecionar o melhor desen-
volvedor para a tarefa, ele analisa a lista de candidatos de um determinado
trabalho com o devido cuidado, tentando descobrir o que puder sobre a ha-
bilidade do desenvolvedor em entregar um jogo de qualidade, no prazo e
dentro do orçamento. Os publicadores vão querer se reunir com a equipe de
desenvolvimento, entender como o processo de produção do desenvolvedor
funciona e provavelmente vão pedir referências junto a outras pessoas que
trabalharam com o desenvolvedor. Também é importante que a equipe de
desenvolvimento faça uma avaliação cautelosa referente ao publicador.
Após o publicador contratar o desenvolvedor, eles negociarão um cro-
nograma de conclusão e pagamento das etapas do projeto. Esse cronogra-
ma é afetado por fatores como a plataforma de hardware, o escopo do jogo,
os termos do contrato, as propriedades de licença intelectual (PI) e outras
variáveis do projeto. Não há prazos de conclusão e pagamento exatamente
iguais, embora os mesmos tipos de produtos sejam esperados no decorrer do
processo.
Durante a fase inicial de pré-produção, o publicador espera receber uma
documentação técnica e de design detalhada, um orçamento completo, o cro-
AVALIANDO MINUCIOSAMENTE OS DESENVOLVEDORES
Jay Powell
Digironin Games
A avaliação minuciosa dos desenvolvedores não é uma ciência exata, mas descobri algu-
mas coisas que podem melhorar suas chances de selecionar um desenvolvedor confiável
para seu jogo:
• Pesquise o histórico da empresa como um todo; isso é essencial para mostrar a

experiência deles no uso da plataforma. Tenha alguma tolerância ao examinar a ex-
periência de desenvolvimento – por exemplo, se eles desenvolveram um título GBA,
provavelmente podem criar um título DS.
• O que eles fizeram? Isso inclui o que fizeram como um grupo, o que as pessoas do
grupo fizeram em outras empresas e também o que elas fizeram com o desenvol-
vedor com quem você está tratando. Se a empresa estiver usando o jogo “x” como
prova de sua competência, procure saber se os membros de sua equipe trabalharam
nesse jogo.
• Pesquise a fundo o histórico de software do desenvolvedor. Descubra quem foram
as pessoas que trabalharam nos jogos e que papéis elas desempenharam no projeto.
Se houver pessoas específicas que você queira que trabalhem em seu projeto, cite
isso no contrato.
• Verifique referências. Se a empresa não quiser dar referências, isso pode ser um aler-
ta. Verifique os créditos em seus jogos para saber quem foi o publicador. Tente
contatar alguém que conheça o publicador que trabalhou com eles para obter in-
formações.
• Se possível, faça uma visita para ver seus escritórios. Caso contrário, faça entrevistas
por telefone para ter uma ideia de seu processo de produção, ética no trabalho e
confiabilidade.
• Em alguns casos, principalmente com desenvolvedores menos experientes, você
pode pedir que preencham um documento detalhando o histórico da equipe, sua
experiência no trabalho com outras plataformas e qualquer coisa que dê uma boa
indicação de seu nível de conhecimento no desenvolvimento de jogos.
Lembre-se de que os desenvolvedores também devem fazer uma análise cautelosa

com o publicador com quem estão trabalhando. Por exemplo, o desenvolvedor deve co-
nhecer o processo de aprovação de etapas do publicador – que inclui o tempo de resposta
para aceitação e feedback, que tipos de prazos o publicador exige, quem é o produtor
com quem a equipe está trabalhando, e assim por diante. É uma boa ideia perguntar a
outros desenvolvedores sobre suas experiências quando trabalharam com um publicador.
nograma, o planejamento de pessoal e a verificação de conceito da jogabi-

lidade. Há casos em que esses materiais são criados e apresentados para o
publicador na exposição inicial.
Nesse estágio, o publicador pode querer informações adicionais sobre
os processos de produção que serão usados para rastrear o progresso do jogo.
Essa é uma preocupação válida, já que ele está investindo no jogo e quer rece-
ber um retorno por essa empreitada. Se o PP não tiver confiança na habilidade
do PD em gerenciar o processo de produção, pode se envolver muito com as
tarefas diárias de produção executadas pela equipe. Essa não é uma situação
ideal, já que o publicador não está interessado em gerenciar uma equipe de
desenvolvimento – é por isso que o projeto foi atribuído a um fornecedor ex-
terno. No entanto, ele fará o que for necessário para proteger o investimento.
Quando a produção do título for iniciada, o publicador vai querer ver
builds regulares do jogo. Ao examinar a build, o PP dará feedbacks e solicitará
mudanças no jogo. É esperado que isso ocorra para um escopo razoável e o
feedback adicional deve melhorar a qualidade geral do jogo. Por exemplo, o
PP pode pedir que um nível seja roteirizado novamente ou que os controles
do jogo sejam ajustados.
Em alguns casos, o publicador pode solicitar uma alteração maior em um
recurso ou que um novo recurso seja adicionado. Quando o PD receber essas
solicitações, terá de avaliá-las para saber se estão de acordo com o escopo
combinado para o jogo, como descrito na documentação e no cronograma das
etapas. Há casos em que a solicitação substitui um recurso planejado e, por-
tanto, pode não afetar o escopo ou o cronograma negativamente.
Em outros casos, a solicitação de funcionalidades afetará o cronograma e
os recursos, o que significa custos adicionais de produção para as duas partes.
Quando isso ocorrer, o PD deve informar imediatamente o publicador sobre

o impacto: o cronograma pode ter de ser estendido, o desenvolvedor pode
ter de contratar mais pessoas ou outros recursos terão de ser cortados para a
solicitação ser encaixada. Se nenhuma dessas mudanças for feita, o PD e o PP
devem renegociar as etapas e os pagamentos.
Um desenvolvedor lidando com solicitações de recursos adicionais e
feedback do publicador pode ficar frustrado, mas se uma relação de trabalho
sólida for estabelecida com o PP, essa frustração será menor. O PP está no pro-
cesso para ajudar o desenvolvedor, e um bom PP trabalhará com ele para lidar
com qualquer problema inesperado no projeto.
TRABALHANDO COM PUBLICADORES
Don Daglow, Presidente e CEO

Stormfront Studios
Escolha seu publicador cuidadosamente por meio de uma pesquisa completa. Considere
trabalhar com um publicador como se fosse sair em um cruzeiro – você paga por tudo
antecipadamente e não pode voltar atrás se houver um problema. Há casos em que os
publicadores pedem aos desenvolvedores que adicionem mais recursos a um jogo sem
receber mais por isso e o desenvolvedor tem de dizer apenas “Sinto muito, isso não está
na especificação nem no orçamento ou cronograma. O que devemos cortar para abrir
espaço a esse novo recurso?”. Em outros, pode haver mal-entendidos involuntários e as
duas empresas terão de trabalhar juntas para resolvê-los (por exemplo, “como ninguém
especificou quando a detecção de colisões deveria funcionar, achamos que seria em mar-
ço e vocês em setembro!”).
Se estiver em uma situação de conflito com um publicador sobre o conteúdo do
jogo ou a aprovação de uma etapa, seja firme e racional em suas posições mas não fique
indiferente. O produtor do publicador discutirá com seu chefe em nome do desenvolvedor
para descobrir uma maneira justa e racional de lidar com um problema. Em um mundo
perfeito, o produtor com quem trabalhamos seria um provocador que tiraria o melhor do
grupo, da mesma forma que bons editores melhoram bons escritores. Os melhores produ-
tores desafiam seus desenvolvedores e os provocam para dar seu melhor – isso gera jogos
melhores… e royalties maiores.
O próximo depoimento detalha o modelo de produção usado na Large

Animal Games, assim como a forma como eles gerenciam o relacionamento
desenvolvedor-publicador.
GERENCIANDO O RELACIONAMENTO
DESENVOLVEDOR-PUBLICADOR

Large Animal Games
Somos uma pequena desenvolvedora independente, que cria jogos para o mercado casual
de downloads. No passado, geralmente tínhamos cerca de seis projetos em desenvolvi-
mento simultaneamente, variando em tempo de produção de seis semanas a seis meses.
Tivemos sucesso com esse modelo, mas agora que nosso catálogo de títulos originais
está gerando royalties, estamos em uma posição em que não precisamos executar tantos
projetos pequenos. Hoje mantemos nosso foco em projetos maiores, com um ciclo de
desenvolvimento de seis a oito meses. Temos projetos patrocinados internamente, como
Rocketbowl, e projetos patrocinados por outros publicadores, como Saints & Sinners Bingo,
dos quais também recebemos uma parcela do back-end.
Os publicadores são um fenômeno relativamente novo no nicho de jogos baixáveis.
Há apenas algumas empresas patrocinando ativamente o desenvolvimento de terceiros no
momento.
Embora não sejamos uma desenvolvedora tradicional de jogos de console ou PC,
o relacionamento que temos com nosso publicador é semelhante. Trabalhamos com eles
para criar um plano de desenvolvimento no início do projeto, que define os recursos prin-
cipais, as etapas e o cronograma de pagamentos. No entanto, a publicadora com a qual
trabalhamos é menor, o que significa que temos de lidar com menos sobrecarga corpora-
tiva, e em geral há mais flexibilidade.
No decorrer de um projeto de seis a oito meses, geralmente temos cerca de oito eta-
pas-chave, que incluem produtos como a conclusão do design, a conclusão dos recursos
principais e a conclusão do conteúdo. O publicador trabalha conosco durante o processo
de desenvolvimento para assegurar que essas etapas sejam concluídas integralmente e no
prazo. Ele fornece alguns recursos de QA, produz materiais de marketing e faz acordos
com parceiros de distribuição.
Temos um bom relacionamento com nosso publicador. Falamos com ele aproxi-
madamente uma vez por semana, dependendo de onde estejamos no projeto. Quando
surgem problemas, chegamos a falar com ele várias vezes ao dia. Em geral, quando tudo
corre bem durante o ciclo de desenvolvimento, o publicador não é envolvido ativamente.
Mas quando o publicador tem algumas preocupações, elas são trazidas para nossa ava-
liação e as resolvemos. O publicador dá um bom feedback e nunca nos sentimos acuados;
ele sabe que entregaremos uma experiência de jogo de qualidade.
Para uma desenvolvedora pequena trabalhando no mercado de jogos baixáveis, ter
um produto apoiado por um publicador pode trazer vantagens significativas. Um pu-
blicador pode realmente deixar seu jogo em boa posição e garantir um acordo melhor e
promoções mais adequadas junto a um distribuidor de jogos on-line.
No depoimento a seguir, Jay Powell discute as etapas do desenvolvimen-

to e as especificidades do contrato.
ETAPAS DO DESENVOLVIMENTO
Jay Powell
Digironin Games
Os publicadores incluirão uma cláusula de encerramento no contrato. Por exemplo, se

uma etapa estiver “x” dias atrasada, ou for malsucedida, o publicador pode decidir en-
cerrar o contrato. Para impor isso, o contrato tem de ser muito específico sobre o que
constitui uma etapa. Portanto, em vez de dizermos que um conjunto de tarefas estará 50%
concluído, o publicador vai querer uma lista dos recursos e tarefas reais que devem ser
concluídos em uma etapa específica.
Embora geralmente um Documento de Design do Jogo (DDJ) e um Documento de
Design Técnico (DDT) sejam incluídos como parte do contrato, eles podem não estar total-
mente concluídos antes do contrato ser assinado. Nesse caso, o publicador não exigirá um
cronograma específico antecipadamente, mas vai querer uma lista dos desdobramentos
da etapa. Uma cláusula é incluída no contrato para a inclusão de adendos até um determi-
nado prazo contendo a etapa especificamente definida. Isso permite que o publicador e o
desenvolvedor tenham alguma flexibilidade quanto ao que deve ser incluído em uma etapa
específica, mas também dá ao publicador algo com o que comparar a etapa quando ela
for submetida à aprovação. O contrato costuma incluir um processo de aprovação bem
definido – por exemplo, o publicador terá “x” dias para examinar e dar o feedback.
Após o publicador examinar a etapa, normalmente ele dá um feedback para o de-
senvolvedor sobre o que quer mudar. O desenvolvedor tem de ficar atento para dizer ao
publicador quando as alterações não fizerem parte do escopo pedido e solicitar um re-
querimento formal de alteração. Ele tem de tomar cuidado, porque às vezes um grupo
de pequenas coisas se avoluma e afeta o escopo do projeto. Por outro lado, o publicador
pode pedir pequenas alterações aceitáveis que não demandem requerimentos de alteração.
O processo de pedidos de alteração é definido no contrato. Um pedido de alteração
é formalizado quando um publicador solicita alterações em uma etapa que afetarão o
escopo do projeto. Esse pedido de alteração define o que precisa ser feito e é apresentado
ao desenvolvedor. O desenvolvedor examina as solicitações e traz um plano especificando
quanto em tempo e dinheiro será necessário para que se faça a alteração. O publicador
pode então decidir se essas alterações são necessárias.
Desenvolvedor exclusivo do publicador

Como mencionado anteriormente, a grande vantagem de alguém ser um de-
senvolvedor exclusivamente interno é que as verbas são garantidas, o que
significa que a equipe pode se concentrar em criar o jogo, em vez de se preo-
cupar em receber os pagamentos pelas etapas dentro do prazo.
Nesse tipo de relacionamento, o publicador também tem um envolvimen-
to maior com a equipe durante o processo de desenvolvimento, ou seja, pode
oferecer mais recursos para a equipe. Por exemplo, o publicador pode pegar
emprestado temporariamente os especialistas de equipes de outros projetos
internos, tornando possível para a equipe concluir uma tarefa crucial a tempo.
Também é mais fácil para o publicador fazer solicitações de recursos e per-
mitir alongamentos no cronograma para assegurar que um recurso solicitado
entre no jogo.
Alguns publicadores também atribuem um PP para trabalhar com um
desenvolvedor exclusivamente interno. O PP trabalha com o PD para coorde-
nar as atividades de teste, marketing e outras tarefas relacionadas ao jogo. Ele
não costuma gerenciar as atividades diárias da equipe de desenvolvimento
mas pode se envolver mais nos processos de produção que estão sendo usa-
dos, principalmente se houver processos com abrangência em toda a empresa
que tenham de ser adotados.
Jamie Fristrom, da Torpex Games, tem algo a dizer sobre o relacionamen-
to desenvolvedor-publicador: “Estar subordinado a outra empresa muda seu
ponto de vista sobre a aquisição de pessoal. Quando você é um publicador
independente, tenta não contratar pessoas até estar certo de que elas são ne-
cessárias. Quando está trabalhando internamente para outra empresa, tenta
conseguir as pessoas assim que possível – mesmo se não tiver certeza de que
precisa delas. Já que seu publicador ou contratante está tentando colocar pes-
soas em vários estúdios diferentes, isto é, ele não está interessado apenas no
trabalho de seu próprio estúdio, geralmente é necessário mais tempo para en-
contrar as pessoas certas. Quando elas aparecem, tentamos contratá-las antes
que sejam designadas para outro desenvolvedor”.
O PAPEL DO GERENTE DE PROJETO
Tobi Saulnier, Presidente

1st Playable
Antes da Vicarious Visions ser propriedade da Activision, ela era uma desenvolvedora inde-
pendente que trabalhava com muitos publicadores. Essa variedade de clientes e contratos
exclusivos tem grande impacto sobre o gerenciamento do desenvolvimento de produtos.
A abordagem da Vicarious Visions era atribuir um produtor interno a cada título,
que era chamado de gerente de projeto (GP), para diferenciar esse papel do produtor
publicador (PP). O GP começa a participar muito cedo na fase de avaliação inicial de
viabilidade do projeto. Ele é multidisciplinar e tem de saber se comunicar com as equipes
de arte, design, engenharia e com o publicador. Além disso, o GP tem de estar ciente das
limitações do projeto referentes a marketing e vendas. Ele trabalha diretamente com o PP
que atua como ponte para todos os planos de marketing, requisitos de licença, datas de
entrega e assim por diante.
Embora a gerência da Vicarious Visions desse muito apoio, principalmente no início
do processo de desenvolvimento, durante grande parte do processo, o GP era o principal
ponto de contato do PP. Isso ajuda a otimizar a comunicação entre o desenvolvedor e
o publicador. Quando um projeto está pronto para começar, o GP recebe um termo de
abertura do projeto documentando os objetivos e suposições internos do jogo que foram
desenvolvidos durante o processo de vendas, e ele é usado para evitar a perda de informa-
ções na passagem do trabalho para a equipe de desenvolvimento.
Quando o projeto começa, o GP trabalha junto ao PP na definição de quais serão as
restrições de PI. Por exemplo, diretrizes específicas são definidas sobre que personagens e
elementos da história podem ser usados, que conteúdo novo pode ser criado e que temas
podem ser explorados. À medida que a pré-produção avança, o GP trabalha com sua
equipe de desenvolvimento para se certificar de que eles conheçam as restrições e para
que questões pendentes sejam resolvidas.
Durante a pré-produção, o GP trabalha com o designer e os líderes para criar os
documentos de design do jogo e o design técnico, o guia de estilo e o cronograma de de-
senvolvimento, que define os detalhes das etapas restantes.
Quando o documento de design do jogo é concluído e o título entra em produção,
o projeto demanda muito menos interação com o marketing e fica inteiramente nas mãos
do GP, enquanto a equipe segue com os recursos e o cronograma combinados. O GP é
responsável por assegurar que todos tenham o que acharem necessário para ser produ-
tivos, apresentar os assets para o PP examinar, preencher formulários de aprovação de
licenciadores e outras atividades.
O papel do GP pode mudar dependendo de quanto ele estiver sobrecarregado e de
seu nível de experiência. Há casos em que o PP designado só tem um projeto e, portanto,
pode dar mais suporte para o GP. Em outros, o PP tem dez projetos e não pode dar muito
suporte para o GP. Isso significa que o GP deve estar preparado para lidar com tarefas tão
diversas quanto a burocracia de aprovação do licenciador, a localização, a coordenação
dos testes iniciais e a preparação de materiais para o marketing e o RH, mesmo se o PP
for o responsável final.
Basicamente, o GP deve fazer o que for necessário para manter o projeto organizado
e prosseguindo sem problemas. Isso inclui dar atenção ao jogo, examinar testes de jogo e
funcionalidades, monitorar o progresso por meio da alocação de recursos e acompanhar
prazos.
O GP também deve redigir notas de build e obter a aprovação de etapas com o PP.
Para concluir, assim que houver problemas, o GP trabalhará com o líder do projeto para
encontrar soluções. Será útil se o GP tiver alguma especialização em arte, design ou enge-
nharia para conseguir entender os detalhes práticos de como o jogo foi integrado. Entre
todos esses papéis, o GP também é o principal incentivador da equipe, provendo qualquer
necessidade e fazendo a conclusão de cada etapa ser festejada e todos se divertirem um
pouco entre um prazo e outro.
5.4 Aprovações de jogos por terceiros
Jogos publicados para plataformas de hardware proprietárias, como consoles

ou celulares, devem ser remetidos aos respectivos fabricantes para aprova-
ção, como a Sony, Microsoft ou Nintendo. Na maioria dos casos, o publicador
ou desenvolvedor quer o conceito do jogo aprovado pelo fabricante antes da
produção começar. Por exemplo, tanto a Sony quanto a Microsoft exigem que
uma proposta de conceito seja aprovada por elas antes do desenvolvimento
de um título começar. Se o desenvolvedor saltar essa etapa do processo, pode

ver o título plenamente desenvolvido sendo rejeitado, antes mesmo de ser
remetido para aprovação final e fabricação.
Esses fabricantes também têm um conjunto padrão de requisitos técni-
cos que cada produto deve atender para ser aprovado para lançamento. Os
requisitos são listados em uma documentação detalhada e abordam todos os
aspectos do jogo, como a maneira de redigir mensagens pop-up específicas,
definir a lista de amigos e assim por diante. O desenvolvedor tem de atender
todos esses requisitos ou o jogo não passará no processo de aprovação. Os
requisitos devem ser integrados ao processo de desenvolvimento para que
possam ser implementados e testados junto com os outros recursos do jogo.
Os fabricantes de consoles designam um gerente de conta como o principal
ponto de contato para ajudar o desenvolvedor a passar pelo processo de apro-
vação. Também podem ter alguma sugestão de jogabilidade que melhore o
jogo para que dê mais destaque aos recursos específicos da plataforma. Con-
sulte o Capítulo 23, “Liberação do código”, para obter mais informações sobre
o processo de aprovação de consoles.
Desenvolvedores independentes têm um relacionamento de publicação di-

ferente de desenvolvedores totalmente subordinados aos seus publicadores.
Esse relacionamento se manifesta na maneira como o produtor interage com
o publicador. Nos dois casos, o produtor é responsável por conduzir a equipe
pelo processo de desenvolvimento, mas pode assumir diferentes conjuntos
de responsabilidades dependendo do relacionamento publicador-desenvol-
vedor. Este capítulo discutiu esse relacionamento e algumas maneiras de os
produtores gerenciá-lo de modo eficaz, assim como algumas práticas padrão
para a preparação da apresentação de um jogo.
O capítulo fecha a parte “Informações comerciais” do livro. A próxima
parte focará em como gerenciar com eficácia as pessoas da equipe de desen-
volvimento. O primeiro capítulo da seção discute como contratar e manter
talentos de qualidade.
Parte III
GESTÃO DE PESSOAS
J á que as pessoas são o recurso mais valioso de qualquer equipe de desenvol-

vimento, saber como gerenciá-las de maneira eficaz é crucial para o produtor.
Mesmo se o jogo estiver perigosamente atrasado, se a equipe for bem gerenciada e
motivada, terá uma chance maior de entregar um projeto bem-sucedido.
A habilidade para lidar com pessoas não surge naturalmente para todos, mas
não se preocupe se você não for tão carismático quanto gostaria. Se quiser realmente
ser um bom líder para sua equipe, é possível melhorar suas habilidades de geren-
ciamento.
Esta seção tratará das habilidades necessárias para o gerenciamento bem-suce-
dido das pessoas em projetos. Serão apresentadas informações sobre como motivar
uma equipe, dar feedback, identificar talentos e melhorar a comunicação entre a
equipe e você. Os tópicos são estes:
• Contratando e mantendo talentos

• Liderança do projeto
• Construindo equipes
• Motivando pessoas
• Comunicação eficaz
6
CONTRATANDO E
MANTENDO TALENTOS
Neste capítulo
• Contratando talentos • Mantendo talentos • Treinamento
6.1 Introdução
Se tivermos a combinação certa de talentos e personalidades que sejam apai-

xonados por jogos, isso ajudará bastante a tornar o jogo um sucesso. Um gru-
po de pessoas pode trabalhar junto no mesmo jogo por quatro anos ou mais,
por isso, se elas não se derem bem ou não complementarem os talentos
umas das outras, a qualidade e as chances de sucesso do jogo diminuirão,
porque mais tempo será gasto no gerenciamento de personalidades do que
na criação do jogo. Por exemplo, o produtor ou líder não deve gastar muito
tempo com um membro da equipe com personalidade difícil esperando que
ele melhore, já que esse esforço desviará a atenção da produção de outras
áreas cruciais do jogo.
Como produtor, talvez você não tenha o privilégio de contratar ou de-
mitir, mas quase sempre vai estar envolvido no processo de entrevista e ter
alguma influência sobre quem é contratado e adicionado à equipe. O proces-
so de contratação lhe permitirá ser seletivo quanto às pessoas que realmente
se tornarão funcionárias. O produtor deve ser seletivo com quem está con-
tratando porque será responsável por lidar com problemas de pessoal, como
atrasos, trabalho de baixa qualidade, prazos perdidos e assim por diante. Este
92 Parte III • Gestão de Pessoas
capítulo apresenta algumas informações gerais sobre contratação, retenção e

treinamento de talentos do ponto de vista do produtor.
6.2 Contratando talentos
Encontrar pessoas talentosas pode ser difícil, principalmente se você não es-
tiver em um dos centros de desenvolvimento de jogos na Califórnia, no estado
de Washington ou no Texas. No entanto, pessoas com talento e paixão pela
criação de jogos não pensarão duas vezes em se mudar se encontrarem a opor-
tunidade certa. Há vários recursos disponíveis para a busca de talentos – tra-
balhar com recrutadores, postar aberturas de vagas no site da empresa e recru-
tar pessoas nas conferências e feiras de desenvolvimento de jogos. Lembre-se
também de que a pessoa certa para o trabalho é que pode encontrar você, já
que há várias pessoas interessadas em criar jogos como meio de ganhar a vida.
Talvez não sejam suficientemente experientes para alguns dos cargos mais
altos, mas podem ser talentos apropriados para os níveis iniciais.
Você pode ter um departamento de Recursos Humanos (RH) interno que
trate do processo de contratação ou talvez possa usar o departamento de RH
de seu publicador. Nos dois casos, geralmente o departamento de RH é o pon-
to inicial de contato de todos os possíveis candidatos, sendo o órgão que lida
com a logística de criação e divulgação de descrição de vagas, coleta de cur-
rículos, coordenação de entrevistas por telefone, preparativos de viagem para
entrevistas in loco, negociação salarial e propostas de acordo final.
O produtor é responsável por informar ao departamento de RH sobre
suas necessidades de contratação, fornecendo detalhes de descrição do cargo,
e por entrevistar possíveis candidatos. Ele também pode determinar quem
mais na equipe entrevistará os candidatos.
O processo de entrevista começa com a análise dos currículos enviados e
a seleção de uma lista de possíveis candidatos para uma entrevista inicial por
telefone. Geralmente, o produtor ou líder conduz essa entrevista e recomenda
se a pessoa deve ser chamada para uma entrevista in loco. Se um candidato
for chamado para entrevista, o máximo de pessoas possível deve ter a opor-
tunidade de entrevistá-lo. O ideal é que todos da equipe sejam envolvidos,
mas talvez isso não seja viável se houver mais de dez membros na equipe. Em
equipes maiores, as pessoas que terão mais contato com o entrevistado devem
ser envolvidas no processo de entrevista.
Após o candidato ser entrevistado, o produtor e outras pessoas envolvi-
das no processo dão seu parecer quanto a seus pontos fortes e fracos. Essas
informações são usadas para determinar se uma proposta de trabalho deve ser
feita. A gerência do estúdio também é envolvida no processo de contratação
e costuma dar o parecer final sobre quem será contratado, principalmente no
preenchimento de vagas sênior na equipe. Ela é envolvida especialmente no
caso de um estúdio grande com vários projetos, já que se espera que o candi-
dato seja designado para outros projetos quando necessário.
6 • Contratando e Mantendo Talentos 93
CONTRATANDO BONS FUNCIONÁRIOS

Large Animal Games
A Large Animal definiu um processo confiável e controlado para a triagem de futuros

funcionários que reduz o tempo gasto em entrevistas com os desenvolvedores e traz os
melhores candidatos para o topo da lista. Quando queremos preencher uma vaga nova,
postamos a descrição do cargo em nosso site junto com um questionário on-line que cada
interessado deve responder antes de fazer o upload de seu currículo. Ele inclui perguntas
que vão de “Já trabalhou no projeto de um jogo?” a “Quais os últimos três jogos em que
trabalhou?” e “Qual o melhor emprego que teve e por que gostava dele?”. Esse questio-
nário serve como um bom filtro, nos dando uma visão mais precisa da personalidade,
habilidades de comunicação e profissionalismo de um candidato do que um currículo
pode fornecer.
Recebemos mais de 150 respostas para um anúncio que postamos recentemente
procurando um artista – uma resposta surpreendente para uma empresa pequena como
a nossa. Usando o questionário, conseguimos reduzir a lista a 10 candidatos selecionados
para as entrevistas por telefone. Por exemplo, muitas pessoas da lista foram rapidamente
eliminadas devido a suas respostas pouco profissionais às perguntas, que com frequên-
cia incluíam erros de digitação e uma gramática fraca. Essas respostas indicavam que a
pessoa não estava tão interessada ou entusiasmada com o cargo e deu pouca atenção a
detalhes. Quando ficamos com uma lista menor de 10 candidatos, pedimos a eles referên-
cias e conversamos com pelo menos duas dessas pessoas indicadas por cada candidato.
Em seguida, fizemos pequenas entrevistas de 10 minutos por telefone, e para concluir,
fizemos entrevistas in loco com seis interessados.
Como na maioria das empresas, a retenção de pessoas é um problema para nós,
mas ninguém que trabalhou aqui por mais de seis meses jamais nos deixou. Simplesmente
queremos que a Large Animal seja o melhor emprego que nossos funcionários já tiveram.
Cultivamos um ambiente que é ao mesmo tempo descontraído e desafiador e queremos
que os funcionários tenham uma qualidade de vida melhor do que teriam em empresas
maiores de desenvolvimento de jogos que podem pagar salários mais altos. Todos os fun-
cionários trabalharam em grandes empresas no passado e optaram conscientemente por
permanecer em uma empresa pequena para poder preservar um forte senso de camarada-
gem e envolvimento criativo. Como os jogos casuais para download são muito menores
do que um título normalmente obtido nas lojas, os funcionários da Large Animal têm a
oportunidade de trabalhar em uma variedade muito maior de projetos do que teriam em
uma desenvolvedora tradicional para PC ou console.
Triagem dos currículos

A triagem de currículos e a verificação de portfólios é a primeira etapa na
seleção de um pool de possíveis candidatos. Ao examinar currículos, preste
atenção a se o histórico profissional do candidato apresenta grandes lacunas
– isso pode indicar que ele foi despedido e demorou para encontrar outra
vaga, ou que reservou algum tempo para voltar a estudar, ou foi afastado ou
precisou parar para resolver problemas pessoais. É importante perguntar ao
candidato sobre as lacunas em sua vida profissional durante a entrevista ini-
cial por telefone.
Se o candidato tiver um histórico de pular de empresa em empresa –
seis meses em uma, um ano em outra –, considere isso um alerta. Ele pode
não ser muito dedicado ao seu trabalho, estando mais interessado em au-
mentos salariais, ou pode ter dificuldades para permanecer em uma empre-
sa. Por outro lado, pode não ter tido sorte com cortes de pessoal em várias
empresas seguidas ou não sabe avaliar muito bem em que empresas vale a
pena trabalhar.
Se ele listar no currículo a participação em títulos já concluídos, não se
acanhe e confirme. Sabemos que as pessoas podem exagerar (ou até mesmo
mentir) em relação à contribuição que deram em um jogo. O Moby Games
(www.mobygames.com) é um site que lista participações na criação de jogos
e é um bom ponto de partida para a confirmação dessa informação. Mas não
é de forma alguma uma lista completa, portanto, se os créditos não estiverem
listados, não presuma o pior.
Se quiser, verifique também que tipo de críticas receberam os títulos em
que o candidato participou, principalmente se estiver querendo preencher
uma vaga de líder e essa pessoa tiver participado como líder em outros títu-
los. Se os jogos apresentarem continuamente críticas fracas, pergunte ao can-
didato sobre o jogo e as críticas se optar por entrevistá-lo. O GameRankings.
com (www.gamerankings.com) e o Metacritic (www.metacritic.com) são dois
bons bancos de dados on-line com críticas de jogos.
Preste atenção a como o candidato descreve as responsabilidades de seu
cargo em empregos anteriores. Se a descrição tiver poucas informações (mas
muitas palavras) ou as informações parecerem repetitivas, ele pode estar in-
ventando sobre quais foram suas tarefas na criação do jogo. Dê atenção espe-
cial a qualquer alegação exagerada que não pareça corresponder ao nome do
cargo, como um roteirista dizer: “Redesenhei totalmente os aspectos single-
player durante a produção”. Sem dúvida, você terá de obter mais informações
sobre afirmações como essa durante a entrevista por telefone para não acabar
contratando alguém que achasse ser o diretor de criação do jogo, enquanto era
o roteirista líder de gameplay.
Para concluir, verifique o nível de experiência que o candidato tem nes-
se segmento da indústria. Provavelmente você não vai querer contratar al-
guém sem nenhuma experiência para um cargo intermediário na equipe, em-
bora possa abrir algumas exceções. Se quiser contratar para o nível iniciante,
poderá pensar em alguém sem muita experiência, mas tente determinar se a
experiência de trabalho anterior do candidato o preparou para uma posição
de nível inicial. Verifique também se essa pessoa gosta de jogar. Embora talvez
esse não seja um fator tão importante para certos cargos, você quer alguém
que goste de se divertir e tenha um conhecimento geral a respeito de jogos.
O PROCESSO DE ENTREVISTA
Melanie Cambron, recrutadora da indústria de jogos
O processo de entrevista começa realmente com o currículo. Ao fazer a triagem dos currí-
culos, procure uma carreira que progrediu de maneira lógica. A indústria de jogos é volátil,
e demissões são muito comuns, portanto, um histórico de mudanças rápidas de emprego
nem sempre significa problema, como pode ocorrer em outros segmentos. No entanto,
você precisa ter cuidado para não contratar um novo funcionário que deixe a empresa em
30 dias. Um candidato sólido é alguém com educação, que trabalhe nesse segmento há
algum tempo, que demonstre boa estabilidade e crescimento em empregos anteriores e
tenha concluído com sucesso títulos bem recebidos. Além disso, procure pessoas cujas ex-
pectativas salariais e de trabalho correspondam à sua experiência e à posição procurada.
Em seguida, para os candidatos que conseguirem passar na triagem de currículos
e na entrevista, é importante lembrar que não é só a empresa que está avaliando o can-
didato, o candidato também está avaliando a empresa. É crucial que todos os principais
membros da equipe entrevistem o candidato, principalmente aqueles que se comunicarão
e trabalharão com essa pessoa regularmente, e também é importante que eles deixem
seus egos fora da sala. Com frequência, membros mais jovens aproveitam a entrevista
para demonstrar poder de maneira pouco amigável. Embora seja vital extrair a verdade
do candidato, também é vital fazê-lo sem arrogância. Para conseguir o talento-chave que
você deseja, a empresa tem de ser percebida como acolhedora.
A empresa também deve ser percebida como “inteligente”, portanto, prepare a equi-
pe para entrevistar de maneira apropriada. Verifique se todos sabem as perguntas básicas
a serem feitas durante a entrevista para extrair detalhes sobre o conjunto de habilidades
do candidato e como ele interagiu com pessoas e equipes no passado. Revise essas per-
guntas com os membros antes da entrevista.
Quando o processo de entrevista estiver concluído, é hora de analisar os resulta-
dos. Se várias pessoas estiverem entrevistando os candidatos, raramente você terá um
consenso em relação à contratação, portanto, deve pesar as opiniões com base em di-
versos fatores, inclusive a posição do entrevistador na equipe, a relação de trabalho que
o entrevistador teria com o possível funcionário e quanto você confia na habilidade do
entrevistador em julgar caráter e habilidades. Investigue por que quem disse “não” fez isso.
Suas objeções são razoáveis? Se possível, é uma ótima ideia reunir as entrevistas e discutir
o candidato em um fórum do tipo “mesa redonda”. Isso ajuda a extrair uma perspectiva
mais abrangente e você pode descobrir que o candidato deu informações diferentes para
pessoas diferentes.
Entrevistando talentos
Após os currículos serem filtrados e os candidatos com chances serem se-
lecionados, a maioria das empresas faz uma entrevista inicial por telefone
antes de chamar o candidato para uma entrevista in loco. A entrevista por
telefone nos permite ter uma ideia inicial do que o candidato está procuran-
do. Se ele tiver expectativas desmedidas ou diferentes quanto ao salário, as
responsabilidades, as condições de trabalho etc., a entrevista por telefone é
uma boa maneira de descobrir isso antes que mais tempo e dinheiro sejam
gastos com o candidato.
Faça perguntas básicas na entrevista por telefone e tente ter uma ideia da
personalidade, das inclinações e dos talentos da pessoa. Algumas perguntas
da entrevista podem ser as seguintes:
• Que tipo de posição você está procurando?

• Em sua opinião, quais são as responsabilidades do cargo para o qual está
se candidatando?
• Por que se acha qualificado para esse cargo?
• Por que quer sair de seu emprego atual?
• Que habilidades trará para nossa empresa? Quais desenvolverá traba-
lhando conosco?
• Quais são os seus pontos fortes? E os fracos?
• Que tipos de jogos você joga?
• Já jogou [Insira o nome de um jogo desenvolvido por sua empresa]? O
que achou dele? O que mudaria?
Se o cargo exigir mudança de residência, pergunte ao candidato se ele se

importaria e quanto tempo precisaria para mudar se uma proposta fosse feita.
Se o candidato for selecionado para uma entrevista in loco, marque vá-
rias entrevistas no mesmo dia para que ele possa se encontrar com o maior
número possível de potenciais membros da equipe. Verifique se a equipe sabe
como entrevistar adequadamente as pessoas. Se não souberem como entre-
vistar alguém, bons candidatos não se impressionarão com perguntas como
“Quem é seu personagem favorito em G.I. Joe?” e “Quem venceria, Darth Va-
der ou Sauron?”. Perguntas fora de contexto como essas não dão nenhuma
informação sobre as habilidades e a experiência do candidato ou como ele
pode aplicar sua experiência na equipe de desenvolvimento. Por outro lado,
são úteis para sabermos do que o candidato gosta e se ele se enquadra na
cultura da empresa. Apenas certifique-se de que a entrevista como um todo
tenha uma boa combinação de perguntas para que você possa ter uma ideia
mais aproximada do candidato no curto espaço de tempo que estiver com ele.
Perguntas úteis abordariam as habilidades do pretendente, suas expe-
riências anteriores, o que ele espera do emprego e o que planeja para o futuro
de sua carreira. A entrevista in loco é o momento em que você e a equipe
poderão obter informações diretas sobre suas filosofias de desenvolvimento
de jogos, como ele se sai no trabalho em equipe e em que nível suas habili-
dades são apropriadas para o cargo. Muitas das perguntas seriam as mesmas
feitas durante a triagem por telefone, e mais algumas perguntas específicas
quando necessário. Por exemplo, se você estiver contratando um modelador
3D, o chefe de arte terá de ser específico em relação à habilidade do candidato
no uso de um software gráfico 3D. Um candidato a programador tem de ser

entrevistado pelo engenheiro programador líder sobre suas habilidades de
codificação e as linguagens de programação que conhece.
Não se acanhe em pedir ao candidato para mostrar suas habilidades. Por
exemplo, se estiver contratando um roteirista, peça aos candidatos para traze-
rem alguns exemplos de script para a entrevista. Considere também reservar
algum tempo durante a entrevista para lhes dar um minitutorial da ferramen-
ta de scripts usada em seu jogo e veja se conseguem criar algo simples em 30
minutos. Os artistas devem trazer seus portfólios e programadores podem ter
de trazer exemplos de código, contanto que não sejam confidenciais.
VANTAGENS DE UM MBA
Lucien Parsons, diretor de produção

ZeniMax Online Studios
Embora a indústria de jogos tenha muito conhecimento institucional de como aproveitar

ao máximo a tecnologia e do que torna um jogo divertido, não há muito conhecimento
sobre como gerenciar uma empresa de maneira eficiente. Isso não é de surpreender, con-
siderando-se que esse segmento começou com pequenas equipes e um enfoque claro na
construção de grandes jogos, e não na construção da infraestrutura de uma empresa. Con-
sequentemente, à medida que as empresas cresciam, não havia uma estrutura desenvolvida
para elas gerenciarem projetos de vários milhões de dólares com equipes de 100 pessoas ou
mais. Nos últimos anos, a indústria reconheceu essa deficiência e está trabalhando ativa-
mente para corrigir isso. É aí que um MBA pode ser uma ferramenta útil para um produtor.
O que torna o MBA importante é a exposição a exemplos de como outros segmen-
tos lidaram com os problemas que agora estamos encontrando na indústria de jogos. Na
Wharton, passávamos muito tempo estudando casos que demonstravam tanto os méto-
dos tradicionais de gerenciamento e produção quanto as empresas pioneiras que tiveram
êxito usando métodos diferentes. A outra grande vantagem de se ter uma educação for-
mal em negócios é o treinamento na criação e análise de várias estruturas – como planos
de marketing, métodos de produção e filosofias de gerenciamento – que permite que a
pessoa graduada reconheça os perigos e armadilhas que são recorrentes em qualquer área
ou segmento novo – potencialmente, é experiência antecipada. Considero os graduados
com MBA que apreciam nosso segmento como fortes candidatos para cargos de produ-
ção, mesmo se não tiverem muita experiência em jogos, porque sei que foram expostos a
várias maneiras de se estruturar uma equipe, gerenciar um projeto, lidar com problemas
de pessoal e vender um produto – todas habilidades cruciais necessárias na criação de um
jogo. É claro que apenas um MBA não torna alguém um bom produtor, ou até mesmo um
bom gerente, mas sem dúvida é útil.
Dando feedback
Após o candidato ser entrevistado, a equipe deve dar um feedback sobre se
essa pessoa é ou não adequada à posição. Como já foi discutido, raramente o
produtor dá a palavra final sobre quem será contratado para uma vaga; nor-
malmente, essa decisão é tomada pela gerência do estúdio, que considerará
com cuidado o feedback do produtor e da equipe. A descoberta de alguém
adequado ocorre mais facilmente quando vários candidatos são entrevistados.
No entanto, você pode ter só um ou dois candidatos qualificados para uma
vaga; logo, o feedback tem de ser considerado cuidadosamente antes de uma
proposta de emprego ser feita.
Ao darmos feedback, temos de lembrar de ser específicos sobre o que nos
agradou ou não. Dizer que alguém é um “forte candidato” não dá nenhuma in-
formação de por que essa pessoa deve ser contratada. Comentários específicos
como “conseguiu inventar soluções criativas para alguns problemas comuns
que encontramos na equipe” e “identificou áreas de melhoria em nosso pro-
cesso de desenvolvimento” fornecem uma definição melhor sobre quais são
os pontos fortes de uma pessoa. Lembre-se também de ser objetivo em sua
avaliação de um candidato – considere os talentos e habilidades que ele trará
realmente para o cargo e não se é fã de Jornada nas Estrelas, tem um corte de
cabelo esquisito ou frequentou a universidade rival.
Se não achar que um candidato é adequado para uma determinada vaga,
não hesite em explicar por quê. Novamente, forneça comentários específicos.
Você terá de explicar suas razões para as outras pessoas – principalmente se
elas tiverem uma impressão positiva. Se sentir alguns traços duvidosos no
candidato, mas achar que ele pode ser uma opção, discuta esses aspectos com
os outros envolvidos no processo de entrevista para saber se tiveram as mes-
mas reservas. O melhor é que todos se reúnam para discutir suas impressões
sobre o candidato para que a avaliação seja abrangente.
TRABALHANDO COM RECRUTADORES
Os recrutadores são mais úteis quando procuramos talentos de alto gabarito, principal-
mente se esse talento estiver trabalhando para a concorrência. Um recrutador pode abor-
dar essa pessoa diretamente, o que é muito melhor em um segmento industrial pequeno.
A primeira etapa do trabalho com um recrutador é preparar uma descrição de car-
go bem detalhada. Quanto mais informações você der ao recrutador sobre o cargo e a
equipe, melhor. Ambiente de trabalho? Interação da equipe? Dinâmica da equipe? Pontos
fracos de outros candidatos? Tipo de personalidade que seria adequado? O tipo que não
seria? Quanto mais detalhes, menos candidatos você terá de entrevistar e mais rápido será
o processo de recrutamento.
De posse dessas informações, o recrutador contata possíveis candidatos e avalia seu

potencial. Ele esclarece todas as perguntas e expectativas do cliente e do possível candi-
dato no começo do processo para reduzir surpresas dos dois lados. O processo de verifi-
cação pode avançar positivamente com as duas partes tendo certeza de que os aspectos
básicos, como despesas de mudança, salário, benefícios e problemas de imigração, já
foram discutidos para a satisfação de todos. Em seguida, o recrutador coordena a triagem
por telefone e as entrevistas físicas e verifica referências se necessário.
Após o candidato ser selecionado, o recrutador facilitará o processo de contratação
coordenando a proposta, a mudança e problemas de visto. Para concluir, quando o can-
didato estiver em sua nova posição, o recrutador fará um acompanhamento tanto com ele
quanto com o cliente para saber se estão satisfeitos.
6.3 Mantendo talentos
Manter bons talentos é um desafio para muitas empresas, já que as pessoas

estão sempre procurando melhores oportunidades ou situações profissio-
nais, principalmente quando não estão felizes em sua posição atual. Se tiver
pessoas talentosas em sua equipe e quiser mantê-las, faça o que puder para
atender suas expectativas e deixá-las felizes. Não é preciso satisfazer todos
os seus caprichos, mas você tem de dar a elas os recursos necessários para
executarem suas tarefas, ouvir suas reclamações, sugestões e ideias e lhes dar
oportunidades de crescer na empresa.
Surpreendentemente, dinheiro não é o principal fator de motivação da
maioria das pessoas e sim confiança e respeito. Quando têm oportunidade,
quase todas as pessoas preferem ganhar menos dinheiro e trabalhar em uma
empresa em que são respeitadas por seus pares, ouvidas pela gerência e têm
liberdade para tomar decisões sobre suas contribuições, em vez de ganhar
mais dinheiro em um ambiente em que são tratadas desrespeitosamente, ig-
noradas e não podem opinar no que contribuem. É claro que dinheiro ajuda
a manter pessoas talentosas, mas se elas não tiverem as outras coisas, co-
meçarão a procurar uma empresa que as satisfaça, mesmo se isso significar
receber menos.
As pessoas também querem ser recompensadas pelo comprometimento,
pela lealdade e pelo trabalho de alta qualidade. Mais uma vez, essa recom-
pensa não precisa ser monetária – embora, é claro, abonos sejam apreciados
–, podendo ser oferecida na forma de mais responsabilidade, maior respeito
(principalmente por parte da gerência) e atribuições mais importantes. Se al-
guém sentir que suas contribuições não estão sendo reconhecidas como de-
veriam, ficará frustrado e acabará deixando a empresa. Você tem de saber
quais funcionários estão superando as expectativas e trabalhando bastante
para construir o melhor jogo possível para poder dar a eles o reconhecimento
que merecem. Essas pessoas são as que serão seus membros de equipe mais
leais e servirão como exemplos positivos de como outras pessoas da equipe

serão tratadas se demonstrarem as mesmas características.
Além desses benefícios intangíveis, também há alguns benefícios tan-
gíveis que contribuem para um ambiente de trabalho mais amigável para os
funcionários: assistência médica, odontológica e oftalmológica, férias, planos
401(K), distribuição de ações, licença paternidade. Um bom pacote de benefí-
cios ajuda muito a mostrar aos funcionários que a empresa os valoriza. Se sua
empresa for pequena, comece com uma lista básica de benefícios e aumente-a
à medida que crescer.
Associação a uma academia de ginástica: Incentive os funcionários a

ficarem em forma; a boa forma traz mais saúde e menos tempo de licença
por doença.
Horas de trabalho flexíveis: As horas de trabalho flexíveis permitem que
as pessoas definam seu horário de trabalho para poderem dar o melhor de
si – algumas pessoas trabalham melhor de manhã cedo, outras preferem tra-
balhar tarde da noite. Para promover a colaboração entre todos os membros
da equipe, defina as horas principais em que as pessoas terão de estar no
escritório e certifique-se de cumprir ou exceder essas horas você mesmo.
Hardware e software: As pessoas ficam frustradas quando esperamos
que executem suas tarefas em hardware ou software que não seja ade-
quado a essas tarefas.
Bebidas gratuitas e outros petiscos: Todo mundo gosta de pequenos
prazeres como esses e eles são algo barato que a empresa pode fornecer.
Não esqueça de oferecer lanches saudáveis e suco de frutas.
Competições: Reserve um horário perto das 5 da tarde para a equipe
competir. Jogar é uma ótima atividade para solidificar equipes.
É claro que há muitas outras coisas que mostram que os funcionários são
valorizados. Consulte o Capítulo 7, “Equipes”, para ver mais exemplos.
MANTENDO A EQUIPE FELIZ
Para uma indústria de vários bilhões de dólares, a indústria de jogos continua se manten-
do muito coesa. Histórias e reputação dos desenvolvedores podem se espalhar rapida-
mente, e é por isso que criar um ambiente de trabalho saudável e positivo é essencial para
atrair talentos. Os membros da equipe têm de se sentir atualizados no que diz respeito
ao cronograma, ao direcionamento e a qualquer mudança maior no desenvolvimento
do jogo para não ficarem desamparados e querer expressar insatisfações com a empresa
para outras pessoas da indústria. Ficar desinformado sobre o status de seu projeto é uma
reclamação frequente de funcionários descontentes. Isso gera desmotivação e antipatia

pela empresa, podendo levar a postagens negativas em blogs e propaganda desfavorável.
Um grande passo em direção à promoção de uma imagem positiva que atrairá o tipo de
talento de qualidade que você deseja é simplesmente manter sua equipe atualizada em
todos os aspectos da produção do jogo.
6.4 Treinamento
O treinamento é um elemento essencial para as pessoas terem êxito em seus

cargos. Afinal, não podemos esperar que elas saibam tudo. Embora haja uma
suposição intrínseca de que as pessoas têm habilidade para desempenhar
bem as tarefas que receberam, nem sempre elas têm as ferramentas necessá-
rias para isso. Por exemplo, se alguém for solicitado a assumir uma posição de
liderança no meio do desenvolvimento, pode não estar preparado para passar
da criação de conteúdo para o gerenciamento. Embora talvez tenha habilidade
para fazer a mudança, pode precisar de mais treinamento em aptidões básicas
de gerenciamento de pessoal, como a negociação de conflitos ou a motivação.
Além disso, terá de considerar o jogo como uma soma de suas partes, em
vez de se preocupar apenas com um aspecto. Um artista líder, por exemplo,
tem de liderar os artistas que estão criando todo o conceito artístico do jogo
– texturas, modelos, níveis, cinemática e assim por diante. Portanto, é impor-
tante reservarmos algum tempo para treinamento, já que esse tempo reduzirá
custos a longo prazo.
Algumas pessoas são autodidatas e altamente motivadas e têm uma com-
preensão clara do treinamento e das informações de que precisam. Elas sabem
que cursos e livros serão úteis, fazem perguntas e coletam informações e são
sempre receptivas a um feedback relativo ao desempenho, podendo até mes-
mo solicitá-lo regularmente. Uma maior orientação é necessária para ajudar
certas pessoas a determinar suas necessidades, mas é importante descobrir
em que elas precisam de treinamento e atender essas necessidades se possí-
vel. Bons empregadores se interessam ativamente em desenvolver seus fun-
cionários e oferecer oportunidades de treinamento.
As áreas importantes em que um funcionário pode precisar de treina-
mento adicional são liderança, comunicação e habilidades técnicas. Qualquer
pessoa em uma posição de liderança se beneficiará de treinamento em todas
essas três áreas, principalmente se for nova no cargo. Programas de treinamen-
to para a melhoria das habilidades de liderança e comunicação podem ser difí-
ceis de encontrar, mas talvez a universidade local ofereça cursos de educação
continuada nessas áreas. O treinamento técnico pode ser feito internamente,
se necessário, por pessoas da equipe tecnicamente capacitadas. Livros e cursos
on-line também são bons recursos de treinamento. Além disso, várias organi-
zações, conferências e sites fornecem informações, e até mesmo cursos, para a
melhoria das habilidades de desenvolvimento de jogos.
APRENDENDO A TRABALHAR EM EQUIPE
Tracy Fullerton, Professora Assistente

University of Southern California
A Faculdade de Cinema-Televisão da University of Southern California (USC) é muito boa

em treinar pessoas para trabalharem colaborativamente em projetos de criação. A cola-
boração é a base de seu programa de criação de filmes e está profundamente enraizada
no processo de produção ensinado. Na Divisão de Mídia Interativa desse programa, as-
similamos essa tradição. A ideia não é executar um grande projeto logo na primeira vez,
mas trabalhar em vários projetos e protótipos pequenos que envolvam diferentes tipos de
jogos. É desafiador, mas os participantes começam a compreender rapidamente como os
jogos funcionam. Nas turmas intermediárias, os alunos trabalham em projetos maiores
baseados em equipes. Nos projetos avançados, as equipes são ainda maiores e cada pes-
soa trabalha em uma área especializada.
Esse processo comporta traços de realidade já que, quando os alunos chegam aos
projetos avançados, têm de vender suas qualidades para a pessoa que é o produtor ou
diretor do projeto para serem selecionados para a vaga. A metodologia também tem base
prática, porque quando os alunos saem para o mundo real, têm de saber fazer demons-
trações e conversar com outras pessoas que podem não ter conhecimento da linguagem
específica de desenvolvimento de jogos. Esse é um dos elementos enfatizados no progra-
ma interativo – a noção de que os alunos podem trabalhar juntos e atuar colaborativa-
mente para não acabarem com um jogo feito somente por eles próprios e produzirem um
jogo feito em colaboração com várias outras pessoas.
Recursos de desenvolvimento de jogos

Existem muitos sites, organizações e conferências de desenvolvimento de jo-
gos que fornecem uma grande quantidade de informações. Essas organizações
profissionais são um ótimo local para encontrar desenvolvedores de jogos com
a mesma mentalidade, e as conferências e feiras são sempre uma boa oportuni-
dade para se relacionar com outras pessoas com os mesmos interesses.
Organizações*
International Game Developers Association (IGDA) – www.igda.org:
Associação dedicada à comunidade de desenvolvimento de jogos digi-
tais. Também é uma das patrocinadoras da Game Developers Conferece.
No Brasil existem quatro chapters da IGDA: Recife (PE), São Paulo (SP),
São Leopoldo (RS) e Rio de Janeiro (RJ).
* N. de R.T.: No Brasil temos a ABRAGames (Associação Brasileira das Desenvolvedoras

de Jogos Eletrônicos), que representa as empresas de jogos nacionais, e a ACIGames (Asso-
ciação Comercial, Industrial e Cultural de Games, www.acigames.com.br), que representa
basicamente o setor varejista de jogos digitais.
Academy of Interactive Arts and Sciences (AIAS) – www.interactive.

org: Academia que promove interesses comuns do entretenimento inte-
rativo. Também hospeda a D.I.C.E. Summit anual.
SIGGRAPH – www.siggraph.org: Associação direcionada ao universo
gráfico do entretenimento interativo. Hospeda uma conferência anual
todo ano para criadores de conteúdo digital.
Conferências e feiras*
Austin Game Developers Conference (Austin GDC) – www.austingdc.
net: Conferência anual realizada todo mês de setembro que oferece pa-
lestras, mesas-redondas e tutoriais apresentados por membros da comu-
nidade de desenvolvimento de jogos.
Consumer Electronics Show (CES) – www.cesweb.org: Feira anual que
apresenta as tecnologias mais recentes para consumidores.
D.I.C.E. Summit – www.interactive.org: A D.I.C.E. é uma conferência
anual que enfoca os desafios da área de criação no desenvolvimento de
jogos. É hospedada pela AIAS.
Game Developers Conference (GDC) – www.gdconf.com: Conferência
de uma semana realizada todo mês de março que oferece palestras, tuto-
riais e mesas-redondas apresentados por membros atuantes da comuni-
dade de desenvolvimento de jogos. A GDC também oferece uma feira de
empregos e uma exposição de fornecedores.
IGDA Leadership Forum – www.igda.org/leadership/: Conferência anual
que enfoca principalmente a produção e a liderança na indústria de jogos.
Montreal International Game Summit (MIGS) – www.sijm.ca: Confe-
rência anual realizada no outono em Montreal dedicada ao desenvolvi-
mento de jogos.
Penny Arcade Expo (PAX) – www.pennyarcadeexpo.com: Conferência
anual que foi iniciada pelos criadores dos quadrinhos Penny Arcade. É
direcionada aos profissionais e estudantes de desenvolvimento de jogos
e a qualquer pessoa interessada em videogames.
Informações gerais da indústria de jogos
Blues News – www.bluesnews.com: Site que apresenta as últimas notí-

cias da indústria, críticas e outras informações sobre jogos.
Develop – www.developmag.com: Revista de desenvolvimento de jogos
publicada na Europa.
* N. de R.T.: O maior evento técnico brasileiro que também reúne a indústria é o Simpósio
Brasileiro de Jogos e Entretenimento Digital (SBGames) – www.sbgames.org.
The Escapist – www.escapistmagazine.com: Revista on-line sobre joga-

dores e a cultura dos jogos.
Gamasutra – www.gamasutra.com: Site com todo tipo de recursos de
desenvolvimento de jogos, como ofertas de emprego, notícias da indús-
tria e artigos sobre desenvolvimento de jogos.
GameDev.net – www.gamedev.net: Site contendo artigos técnicos sobre
desenvolvimento de jogos, críticas de livros, fóruns, ofertas de emprego
e outras informações úteis.
Game Development Search Engine – www.gdse.com: Ótimo recurso
para ofertas de emprego na área de desenvolvimento de jogos e possíveis
candidatos.
Game Developer Magazine – www.gdmag.com: Revista publicada nos Es-
tados Unidos que fornece artigos sobre desenvolvimento de jogos. Tam-
bém inclui ofertas de emprego.
Game Rankings – www.gamerankings.com: Site que posta todas as crí-
ticas de um jogo e determina uma média geral com base nessas críticas.
Metacritic – www.metacritic.com: Site que posta todas as críticas de um
jogo e determina uma nota média.
Moby Games – www.mobygames.com: Site que coleta e posta informa-
ções sobre participações em jogos e outras notícias sobre a indústria de
jogos.
Next-Generation – www.next-gen.biz: Site com notícias e artigos diá-
rios relativos à indústria de jogos.
Como as pessoas são o recurso mais valioso e caro de uma equipe de de-
senvolvimento de jogos, é importante encontrar e manter bons talentos. Essa
tarefa fica mais difícil à medida que a indústria de jogos cresce, já que as
empresas estão se empenhando para se tornar o melhor empregador para os
melhores talentos. Este capítulo discutiu como contratar, manter e treinar ta-
lentos e apresentou informações sobre como filtrar currículos, que perguntas
fazer durante uma entrevista e como manter pessoas talentosas felizes e pro-
dutivas. O próximo capítulo discutirá como transformar todos esses indiví-
duos talentosos em uma equipe de desenvolvimento produtiva.
7
EQUIPES
Neste capítulo
• Liderança do projeto • Engajamento e • Qualidade de vida
• Seleção de líderes motivação da equipe
• Construção da equipe
7.1 Introdução
O desenvolvimento de jogos digitais é uma indústria jovem – tanto na idade

de seus profissionais quanto da própria indústria. Essa juventude é refletida
no senso de imaturidade que normalmente é encontrado nas equipes de de-
senvolvimento. Algumas pessoas acham, equivocadamente, que o trabalho
em uma empresa de jogos só envolve diversão e jogos. Embora até certo ponto
isso seja verdade, mesmo assim espera-se que os funcionários ajam de manei-
ra profissional – isso significa chegar ao trabalho na hora certa e assumir a res-
ponsabilidade pela conclusão de qualquer tarefa que for atribuída. Uma das
maiores responsabilidades de um produtor é gerenciar esses jovens talentos e
assegurar que todos deem uma contribuição útil para o jogo.
Para ser um produtor convincente e eficaz, você deve desenvolver suas
habilidades de liderança para conseguir conservar o entusiasmo da equipe,
cuidar de suas necessidades e manter todos motivados para desenvolver o
jogo. Motivação pode ser um desafio, já que requer o gerenciamento de mui-
tas personalidades diferentes, ajuda para as pessoas descobrirem seus pontos
fortes e a neutralização de qualquer risco ao entusiasmo da equipe, como cro-
nogramas encurtados, personalidades difíceis e assim por diante. O produtor
deve assumir essa responsabilidade seriamente; caso contrário, as pessoas
deixarão de colaborar umas com as outras e a qualidade do jogo será afetada.
Se o produtor se comprometer com a construção e manutenção de uma

equipe forte, muitos dos outros riscos do projeto serão minimizados, princi-
palmente porque as linhas de comunicação estarão abertas e as pessoas conhe-
cerão esses riscos muito mais cedo no processo. Graças a esse estado de alerta,
os riscos terão menos chance de se transformar em problemas mais sérios. Este
capítulo discutirá algumas maneiras de construirmos equipes fortes e manter-
mos o projeto em andamento, até mesmo durante períodos estressantes.
COMO O PRODUTOR CONSTRÓI UMA EQUIPE
Tracy Fullerton, professora assistente

Quando estou produzindo, considero meu papel um pouco como uma atividade de en-
genharia social – assegurar que haja um ambiente em que os envolvidos possam fazer
o melhor trabalho possível, sintam que estão contribuindo com o máximo que podem
e tenham os recursos necessários para fazer o trabalho. Outra pessoa poderia lhe dizer
que a função do produtor é concluir o projeto a tempo e dentro do orçamento. Também
é importante, mas me dedico mais a assegurar que a equipe e os processos não tenham
problemas. Isso envolve muitas conversas com as pessoas para que eu saiba em que elas
estão trabalhando e ajude-as a colaborar com outros membros da equipe.
A melhor maneira possível de gerenciar a equipe é assegurar que todos os seus mem-
bros, inclusive os executivos, sintam um senso de autoria. Às vezes, nem todas as pessoas
querem que as outras sintam esse senso de autoria; elas querem tomar decisões sozinhas e
impô-las para os outros, e é aí que você pode se ver em uma situação difícil. Mas a melhor
situação é quando podemos manter as pessoas em comunicação e criar um bom ambien-
te em que os executivos vejam que seu parecer é importante e os artistas, tecnólogos e
designers sintam que suas opiniões têm influência sobre o jogo.
Leitura recomendada, The Essential Drucker

Peter F. Drucker escreveu sobre gerenciamento por mais de 30 anos e é con-
siderado um dos primeiros especialistas no assunto. Ele acredita que para fa-
zermos as pessoas darem o seu melhor, temos de gerenciar seus pontos fortes
e dar a elas amplas oportunidades de desenvolvimento pessoal e profissional.
The Essential Drucker é uma seleção de seus artigos sobre gerenciamento re-
comendada para qualquer pessoa que queira se tornar um líder melhor. O
livro discute tópicos como a tomada de decisões eficazes, a contratação de
pessoas adequadas e muitos outros assuntos focados em como ser um gerente
melhor. Informações completas sobre este título podem ser encontradas no
Apêndice C, “Recursos”.
7 • Equipes 107
7.2 Liderança do projeto
O produtor é visto como o líder da equipe e geralmente é seu representante

oficial em marketing, gerenciamento e tudo o mais que é externo à equipe.
Além disso, ele é diretamente responsável pela integridade do projeto e de
todos na equipe, portanto, deve ser um líder eficaz e positivo. Se a equipe
for conduzida por um líder ineficaz ou negativo, ela e o jogo irão padecer. Se
você não acha que possui qualidades naturais de liderança, não se preocupe.
Se já é produtor, muito provavelmente deve ter exibido qualidades suficien-
tes de liderança para ter sido encarregado de uma equipe e um jogo. Se espera
se tornar produtor, pode desenvolver qualidades de liderança que já tenha.
No entanto, terá de tomar a iniciativa para desenvolver suas habilidades, já
que as empresas raramente têm programas de treinamento para esse tipo de
crescimento.
Mas, afinal, o que é um líder? Um líder é alguém que se apresenta com
confiança e tem uma visão firme, valores e apreço pelas pessoas com quem
está trabalhando. Ele consegue reunir um grupo de pessoas para atingir um
objetivo compartilhado e fazê-las se responsabilizar por seu trabalho. De-
monstra constantemente empolgação, entusiasmo e uma atitude positiva em
relação ao seu trabalho. E o mais importante, o líder tem coragem e iniciativa
para correr riscos, tomar decisões impopulares e fazer o que for necessário
para atingir os objetivos do projeto.
Um líder é definido mais pelo que faz do que pela posição que ocupa na
equipe, o que significa que outra pessoa que não seja o produtor pode ser um
líder para a equipe. Pode ser difícil distinguir os líderes da empresa, mas se
você pensar com cuidado, lembrará de alguém – como o artista respeitado que
está sempre levando as pessoas a criar arte de ótima qualidade.
O importante é que você pode se tornar um líder melhor se trabalhar
nisso. A chave é conhecer bem sua personalidade e temperamento para po-
der desenvolver suas habilidades naturais de liderança. Há alguns arquéti-
pos básicos de liderança – alguém carismático que inspire as pessoas a fazer
o impossível, o tipo forte silencioso que lidera pelo exemplo e uma pessoa
que trabalha pessoalmente com cada membro da equipe para fortalecer suas
melhores qualidades. Familiarize-se com eles e descubra em que estilo ou
estilos se encaixa melhor; você verá que diferentes estilos de liderança fun-
cionam melhor em situações distintas. Se não trabalhar para melhorar suas
habilidades de liderança, pode acabar chefiando uma equipe desanimada,
infeliz e improdutiva.
Leituras recomendadas, Liderança

Project Leadership, de James P. Lewis, fornece aconselhamento prático para
alguém que esteja em posição de liderança em uma equipe de projeto. Várias
técnicas são apresentadas para a melhoria das habilidades de liderança.
The Leardership Challenge, de James M. Kouzes e Barry Z. Posner, é um

estudo de todos os tipos de líderes em diferentes organizações. Os resultados
são resumidos em práticas básicas de liderança.
On Becoming a Leader, de Warren Bennis, é considerado um manual de
liderança com informações detalhadas sobre as características da liderança e
o que podemos fazer para desenvolvê-las para nosso próprio uso.
The 7 Habits of Highly Effective People, de Stephen R. Covey, é um
recurso respeitado de melhoria pessoal que apresenta as sete áreas prin-
cipais de crescimento que têm impacto positivo sobre os relacionamentos
interpessoais.
7.3 Seleção de líderes
Como discutido no Capítulo 2, “Papéis existentes na equipe”, normalmen-

te as pessoas que ocupam as posições de líder de arte, design, programação
e garantia da qualidade não são criadores de conteúdo. Elas gerenciam os
criadores de conteúdo e fornecem liderança e direcionamento para o projeto.
Os líderes mais eficazes têm especialização em suas áreas e muita habilida-
de pessoal, ou seja, eles podem aconselhar pessoas, como o produtor ou os
membros juniores da equipe, sobre as técnicas e processos necessários para
a obtenção do resultado desejado. Por exemplo, um artista líder que conheça
as limitações técnicas do hardware dos consoles pode conversar inteligen-
temente tanto com a equipe de arte quanto com a de programação sobre que
ferramentas são necessárias para a criação de um solo de aparência real. O
artista líder também ajuda a equipe de arte a concluir com sucesso suas tare-
fas no projeto gerenciando o cronograma, dando feedback útil, respondendo
perguntas, organizando tutoriais sobre novas técnicas, definindo o pipeline
de produção de arte etc. O programador líder e o designer líder fornecem os
mesmos tipos de serviços para as equipes de programação e de design, res-
pectivamente.
Líderes fortes são um recurso inestimável para qualquer produtor. Se o
produtor puder contar com os líderes no gerenciamento das tarefas diárias
de arte, programação e design, poderá se dedicar a outros aspectos do proje-
to, como localizações, gerenciamento de fornecedores externos, lidar com os
departamentos de marketing e jurídico, atualizar a gerência sênior em relação
ao status do projeto e fornecer aos líderes e à equipe recursos necessários
para a execução de suas tarefas. Se um líder não for tão forte em uma área
quanto é em outra, o produtor deve fornecer treinamento para que ele melho-
re nessa área, evitando problemas futuros. Por exemplo, um designer líder
que for um designer talentoso mas difícil de lidar não conseguirá gerenciar
a equipe de design de maneira eficaz. Os outros designers podem hesitar em
levar preocupações para ele por medo de serem tratados indelicadamente ou
dispensados rudemente. Se o designer líder continuar agindo assim, mesmo
7 • Equipes 109
com treinamento e aconselhamento apropriados, o produtor deve considerar

substituí-lo por alguém que talvez não seja um designer tão talentoso mas
tenha mais habilidade com as pessoas.
Quando selecionamos líderes, temos a tendência de designar alguém
talentoso que tenha concluído com sucesso alguns jogos. O benefício desse
tipo de designação é haver um especialista prontamente disponível para ofe-
recer orientação técnica ou artística para os membros da equipe. No entanto,
essa pessoa pode não estar preparada para as responsabilidades gerenciais e
administrativas do cargo. Ela vai passar de criador de conteúdo respeitado
para alguém que terá de começar a gerenciar pessoas, cronogramas e políticas
empresariais e talvez não tenha muito interesse em aceitar uma posição de
líder por causa desse tipo de tarefas. Pode preferir permanecer como criador
de conteúdo e liderar a equipe de uma maneira menos oficial.
Na verdade, um líder não deve ser a pessoa artisticamente mais talento-
sa ou tecnicamente mais dotada da equipe. Você deve manter esses talentos
fazendo o que fazem melhor – criando recursos de alta qualidade para o jogo.
Se mover esses criadores de conteúdo de alta qualidade para posições de li-
derança, eles não terão tempo para criar conteúdo e a qualidade do jogo cairá.
Você também pode se deparar com problemas no cronograma se mover um de
seus criadores de recursos mais prolíficos para uma posição em que ele não
poderá criar porque o cronograma de construção de níveis pode rapidamente
começar a atrasar.
Ao selecionar líderes, tente escolher os melhores gerentes para o cargo
e não a pessoa mais tecnicamente dotada. Pessoas com fortes habilidades ge-
renciais costumam ser organizadas, trabalhar bem com os outros, ter sólidas
habilidades de comunicação, conhecer sua área e conquistar o respeito de
seus pares. É mais fácil ajudar alguém a melhorar seu conhecimento de práti-
cas artísticas e técnicas do que treinar essa pessoa para ser mais carismática,
portanto, lembre-se disso quando selecionar líderes para o projeto.
Líderes ineficazes que não corrigem suas deficiências podem colocar o
projeto em risco. Quantas vezes você ouviu alguém da equipe de desenvolvi-
mento reclamar de quanto o seu líder é ineficaz ou inútil? Se essa reclamação
for comum e não for resolvida imediatamente, as pessoas subordinadas a esse
líder pararão de perguntar, apontar riscos e fazer o jogo progredir. Em vez
disso, elas perderão rapidamente o interesse em contribuir para o jogo e verão
as coisas decaírem lentamente no projeto à medida que a comunicação se de-
teriorar entre os membros da equipe.
Em alguns casos, um produtor pode não ter autoridade para substituir
um líder ineficaz que não respondeu ao treinamento. Nessas situações, é cria-
da uma deficiência que o produtor tem de resolver. Ele pode decidir assumir
parte do papel do líder e fornecer as habilidades gerenciais ou técnicas au-
sentes ou conceder informalmente status de líder para um membro júnior da
equipe que tenha demonstrado tendências para ser um bom líder. Se estiver
preso a um líder que se tornou um fardo, tente lidar com a situação sem sobre-
carregar nenhum dos membros da equipe subordinado a ele.
LÍDERES EFICAZES
Jamie Fristrom
Torpex Games
Um líder eficaz não pode ser apenas um especialista em sua área; ele também tem de ter
sólidas aptidões para lidar com pessoas e a habilidade para liderar. A aptidão para lidar
com pessoas determinará o quanto seu estilo de gerenciamento é eficaz para conseguir
que elas façam o que lhes foi solicitado. É comum pessoas serem promovidas à posição de
líder com base somente em seus talentos, mas com frequência elas não têm as habilida-
des de liderança exigidas pelo cargo. Se um líder não conseguir gerenciar corretamente as
pessoas subordinadas a ele, elas não desenvolverão suas habilidades ou carreiras e ficarão
frustradas, o que trará desmotivação e colocará o projeto em risco. Se alguém não estiver
funcionando como líder, não há problema em retornar essa pessoa à sua função anterior.
Isso foi feito algumas vezes na Treyarch sem nenhum grande problema.
É melhor promover pessoas que exibam habilidades naturais de liderança em vez de
presumir que isso é algo que pode ser aprendido. Há situações em que alguém é promovido
para a posição de líder e dentro de seis meses fica evidente que essa pessoa não é adequada
pa-ra o cargo. Nesse momento, costuma ser tarde demais para treiná-la para ser líder, por-
tanto, as opções são substituí-la por outra pessoa, designar um líder assistente ou esperar
que ela consiga concluir o trabalho sem colocar o projeto em um risco significativo.
7.4 Construção da equipe
A construção da equipe é uma parte crucial do processo de desenvolvimento

de jogos e com frequência uma das mais negligenciadas. Há uma noção errada
de que designar um grupo de pessoas para trabalharem juntas cria uma equi-
pe, o que definitivamente não é o caso. Um grupo é composto por indivíduos
cujo trabalho é direcionado por alguém que é o líder do grupo. Uma equipe
é composta por um grupo de pessoas que trabalham juntas para atingir um
objetivo comum e todas elas são mutuamente responsáveis pelo resultado, o
que é muito diferente de um grupo. Para termos equipes fortes, elas devem ser
construídas e suportadas durante todo o projeto.
Como líder do projeto, uma das principais responsabilidades do pro-
dutor é fazer de tudo para construir uma equipe forte. Essa tarefa não é para
pessoas de pouca coragem ou que fiquem tímidas na presença de outras. Para
começar, você tem de conseguir lidar com todo tipo de personalidades dife-
rentes e fazer todas elas trabalharem umas com as outras em harmonia. Tem
de lidar com sua equipe tanto como indivíduos quanto como equipe, criando
o melhor ambiente de trabalho possível para a pessoa e fazendo ao mesmo
tempo o que for melhor para a equipe.
7 • Equipes 111
O produtor também corre alguns riscos quando faz as pessoas participa-

rem de atividades de “construção da equipe”, principalmente porque essas
atividades podem ser consideradas cafonas ou de mau gosto. No entanto, se
ele não tentar construir uma equipe, nunca a terá, ficando apenas com um
grupo de pessoas trabalhando conforme as instruções de seu líder ou pro-
dutor – ou seja, sem compartilhamento de ideias, colaboração, senso de pro-
priedade ou orgulho do projeto e entusiasmo –, o que pode levar a jogos de
pouco interesse que não cairão no gosto do consumidor. Esta seção discutirá
algumas técnicas simples de construção de equipes que se mostraram eficazes
em um ambiente de desenvolvimento de jogos.
DESAFIANDO PERSONALIDADES
Melanie Cambron, Recrutadora da Indústria de Jogos
A inteligência, além da criatividade e da autenticidade, é comum na indústria de jogos e

também torna essa área única em relação aos outros segmentos. Com frequência esse seg-
mento atrai (ou forma) pessoas que são brilhantes em suas funções mas têm dificuldade
em se socializar e se entrosar com os outros. Ao lidar com esses tipos de personalidades,
temos de esclarecer a situação tanto para o cliente quanto para o funcionário e tentar
encontrar uma maneira dessa pessoa conseguir se adaptar. Já que o desenvolvimento de
jogos é colaborativo e socialmente orientado, é raro quando um acordo pode ser feito
para a pessoa ficar apenas sentada em sua mesa e executar suas tarefas sem interagir com
ninguém. Quando quiser trazer pessoas talentosas para seu projeto, verifique se suas per-
sonalidades combinam com a equipe.
Da mesma forma, é vital que a equipe seja bem conduzida. Líderes egoístas que se
comunicavam desrespeitosamente já destruíram equipes, criando ambientes de trabalho
tão ruins que pessoas talentosas deixaram a empresa apenas para ficar longe deles. A
gerência tem de monitorar continuamente a dinâmica da equipe e criar um ambiente de
trabalho que permita a comunicação aberta para ficar informada de situações como essa
e cortá-las pela raiz.
Em resumo, a química social é crucial para uma equipe forte e, independentemente
de estarmos lidando com um programador júnior brilhante ou um designer líder veterano,
a questão social é importante.
Conhecendo uns aos outros

O quanto você conhece realmente seus colegas de equipe? Ainda que possa
ter trabalhado em um ou dois projetos com eles, sabe exatamente com o que
contribuíram para o projeto, ou, melhor ainda, sabe ao menos seus nomes e
sobrenomes? Pequenas equipes de desenvolvimento de dez pessoas ou menos
podem ter essas informações, principalmente porque todos desempenham vá-

rios papéis e dependem do trabalho de outras pessoas da equipe.
No entanto, à medida que as equipes de desenvolvimento ficam maiores,
não é raro alguém não saber os nomes completos de todos os membros ou
até mesmo quem está em sua equipe. É importante que as pessoas conheçam
essas informações básicas. Isso pode parecer óbvio, mas todo dia há casos de
alguém perguntando a um amigo discretamente: “Quem é esse cara? Ele está
no meu projeto? O que ele faz?”. Responder a perguntas simples como essas
pode ajudar muito na construção de uma equipe forte.
Uma das primeiras coisas que devemos fazer quando uma nova equipe é
reunida é pedir que todos se apresentem e descrevam brevemente o que farão
no projeto. Isso só leva um minuto ou menos; a maioria das pessoas não lem-
brará os nomes de todo mundo após essa reunião inicial, mas esse exercício
inicia o “processo de conhecer uns aos outros”.
Se alguém novo estiver sendo adicionado, envie um e-mail de apresen-
tação para a equipe alguns dias antes da pessoa começar a trabalhar e em seu
primeiro dia faça apresentações pessoais para todos os membros. Não há nada
mais embaraçoso do que alguém entrar no escritório na segunda de manhã
e ver um estranho sentado em uma mesa próxima. Esse embaraço aumenta
quando a nova pessoa e seu colega não são apresentados, principalmente se
nenhum dos dois conseguir vencer a timidez se apresentando eles próprios;
eles podem acabar trabalhando lado a lado durante semanas sem ter ideia de
quem é o outro.
Se houver verba no orçamento, considere promover um evento de lan-
çamento do projeto em uma pista de boliche ou restaurante local para dar às
pessoas tempo para se socializarem umas com as outras em um ambiente fora
do trabalho. Elas podem se sentir mais à vontade interagindo nesse cenário
casual e isso lhes permitirá ter uma ideia melhor de como são as personalida-
des dos outros.
Crie também placas com o nome e o departamento das pessoas. Por
exemplo, “John Doe, Criador de Personagens”. Elas ficarão nas mesas, forne-
cendo uma maneira fácil de fixação dos nomes de cada um e o que fazem na
equipe. À medida que as pessoas associarem os rostos aos nomes e souberem
quem é responsável por quais recursos interessantes do jogo, podem começar
a conversar com quem nunca interagiram em nível pessoal. Placas com no-
mes também tornam mais fácil para um funcionário novo se familiarizar com
seus colegas de equipe e suas funções.
Reserve alguns minutos de cada reunião semanal com a equipe para uma
ou duas pessoas fazerem uma apresentação de cinco minutos sobre sua ex-
periência no desenvolvimento de jogos, técnicas de desenvolvimento prefe-
ridas, hobbies ou qualquer coisa sobre a qual quiserem falar para a equipe.
Os membros da equipe podem descobrir que John Doe compartilha o mesmo
interesse em voo livre, World of Warcraft ou jazz, o que pode ajudar muito
na criação de uma maior empatia entre eles. Além disso, essas apresentações
são algo divertido e interessante que a equipe pode ficar ansiosa para ver nas
reuniões semanais.
7 • Equipes 113
CONSTRUINDO UMA EQUIPE FORTE

Large Animal Games
Na Large Animal, estamos comprometidos com a construção de uma equipe forte que
trabalhe bem em conjunto. Embora isso possa ser mais fácil para uma empresa de 12 pes-
soas do que para empresas maiores com centenas de funcionários, a construção de equi-
pes pode ser eficaz em uma empresa de qualquer tamanho se houver comprometimento.
Queremos que todos que trabalham na Large Animal sintam um forte senso de pro-
priedade criativa dos jogos que desenvolvemos. Na verdade, todas as pessoas da equipe
têm grande influência sobre o jogo, e o produto final é reflexo de seu esforço coletivo.
Grandes ideias podem vir de qualquer um, e queremos que todos se sintam à vontade para
compartilhar suas ideias com os demais. Também descobrimos que as pessoas ficam mais
confiantes e trabalham melhor quando se entusiasmam com o material, e gostam de fazer
muita pesquisa para conhecer bem o conteúdo com o qual estão trabalhando. Por exem-
plo, quando trabalhamos em Rocketbowl, levamos a equipe inteira para o boliche para que
pudessem pensar em outras mecânicas de jogo que funcionariam bem. Além desse tipo de
“pesquisa de campo” ser uma ótima maneira de estimular novas ideias sobre o jogo em
que você está trabalhando, também dá às pessoas uma chance de estabelecer empatia fora
do escritório – outro aspecto importante da construção de equipes fortes.
Uma comunicação eficaz na equipe é importante mesmo quando não trata dos
jogos que estamos construindo juntos. Na Large Animal, almoçamos juntos quase que
diariamente e discutimos os últimos filmes, jogos que temos jogado em casa e outros inte-
resses externos. Também jogamos jogos de tabuleiro ou cartas, o que é uma ótima opor-
tunidade para interagirmos uns com os outros em situações que não sejam apenas de
trabalho. Além de os jogos analógicos despertarem ideias e percepções para os jogos digi-
tais que criamos, também é surpreendente o quanto se pode aprender sobre seus colegas
de equipe e seus pontos fortes individuais sentando do outro lado da mesa de jogo. Caso
contrário, talvez nunca soubéssemos que nosso líder de programação, Yossi Horowitz, faz
uma cara incrivelmente velada no pôquer. Achamos que uma comunicação mais eficiente
entre a equipe é construída com base em um rico vocabulário compartilhado composto
por piadas, referências e memórias. É muito mais divertido conversar sobre trabalho com
alguém com quem apreciamos ter conversas não relacionadas a trabalho.
Queremos que todos saibam como as tarefas individuais em que estão trabalhan-
do se encaixam no conceito geral do jogo. Uma coisa que fazemos para encorajar isso é
começar cada manhã com uma curta reunião com a equipe. Ficamos aproximadamente
25 minutos conversando sobre o que cada um fez no dia anterior, as tarefas em que irão
trabalhar hoje e se há algum obstáculo que possa impedir que essas tarefas sejam con-
cluídas. Aprendemos muito sobre os padrões de trabalho uns dos outros ouvindo relatos
sobre as tarefas. Pode acontecer de alguém não ter percebido que há um problema em
que a equipe pode ajudar até que os membros saibam de sua existência na reunião.
Definição de papéis
Os membros da equipe de desenvolvimento têm um forte desejo de contribuir
e querem saber exatamente qual é seu papel na equipe. Conflitos ocorrem
quando os papéis não são definidos claramente. Por exemplo, se houver dois
artistas líder em uma grande equipe de desenvolvimento e eles não definirem
que áreas cada um está supervisionando, isso gerará confusão. Os artistas da
equipe não saberão a que líder levar suas perguntas ou problemas e os pró-
prios líderes não saberão como alocar novas responsabilidades artísticas, o
que pode resultar em recursos e assets inacabados quando o jogo for entregue.
Os artistas e os líderes ficarão cada vez mais frustrados com essa situação, o
que levará a um trabalho menos eficiente e de menor qualidade e possivel-
mente a conflitos entre os líderes e os artistas.
Essa frustração também pode ocorrer se um programador júnior não en-
tender especificamente quais são suas tarefas no projeto. Se o programador
líder pedir a um programador júnior que trabalhe na interface de usuário mas
não definir exatamente quais são as expectativas, o programador não saberá se
deve liderar uma força-tarefa para fazer a IU ser projetada, prototipada e im-
plementada ou se deve simplesmente implementar as tarefas que recebeu (e ao
mesmo tempo ele pode não saber quem é responsável por lhe designar tarefas).
Essas situações podem ser remediadas quando esclarecemos para as pes-
soas quais são seus papéis. Jim Lewis, autor de Team Based Project Manage-
ment, desenvolveu um exercício simples de explicação de papéis que pode
ser feito no começo do projeto e deve ser praticado ao longo dele sempre que
novas pessoas forem adicionadas ou houver sinais de ambiguidade de papéis.
Também é um bom exercício para o produtor e os líderes fazerem durante a
pré-produção, para que todos saibam claramente quem é responsável por que
aspectos do projeto.
O exercício começa com cada pessoa respondendo as quatro perguntas
a seguir:
• Como a empresa vê seu papel na equipe?

• Como você vê seu papel nessa equipe?
• Que recursos precisa para desempenhar de maneira eficaz seu papel?
• O que precisa saber sobre os papéis de outras pessoas para executar me-
lhor seu trabalho?
As pessoas anotam as respostas a essas perguntas e vêm preparadas para

discuti-las em uma reunião. Cada um apresenta suas respostas e, em seguida,
todos as discutem e chegam a um consenso sobre qual a melhor definição
para o papel dessa pessoa. Dez a 20 minutos devem ser alocados para cada
membro. Se você fizer isso para uma equipe grande, agende algumas reuniões
separadas em vez de tentar fazer uma única reunião que dure horas. No fim
da reunião, as definições dos papéis são digitadas para cada pessoa, postadas
no site e exibidas nas salas da equipe. A Figura 7.1 é um exemplo de planilha
que pode ser usada na organização dessas informações após o exercício ser
concluído.
7 • Equipes 115
Expectativas O que preciso O que preciso saber

Papel da empresa Funções no projeto dos outros? dos outros?
NO SITE Produtor – conclusão do projeto – fazer a equipe concluir o projeto – notificação de riscos – quais são as habilidades
no prazo no prazo ou sinais de problemas especiais de cada pessoa
– atendimento dos – programar e acompanhar o – informações sobre no projeto
padrões de qualidade progresso como cada pessoa está – o que cada pessoa
do projeto – comunicar-se com a gerência em se saindo no projeto e precisa no projeto para
– condução e motivação nome da equipe como estão concluir seu trabalho
da equipe – entender o conceito do projeto e desempenhando seus – entender as limitações
– comunicação do comunicar para a equipe papéis de programação, arte e
conceito do projeto – motivar a equipe – informações sobre os design
para a gerência, o – lidar com problemas de pessoal recursos necessários
departamento de – conseguir os recursos necessários para a conclusão do
marketing e pessoas para a equipe trabalho
externas – definir processos de produção – ajuda para comunicar
– trabalhar com os departamentos informações para o
de marketing e RP resto da equipe
– trabalhar com os líderes nas
habilidades gerenciais e de
comunicação
– coordenar localizações
– trabalhar com fornecedores
externos
– conhecer o que cada um está
fazendo no projeto e o progresso
que estão fazendo
– manter a equipe informada sobre o
progresso e atualizada quanto a
mudanças no projeto
– elaborar e manter um site da
equipe
– identificar riscos, sinais de
problemas e soluções
Figura 7.1 Exemplo de uma planilha de definição de papéis.
Treinamento cruzado
O treinamento cruzado é um método em que as pessoas da equipe são trei-
nadas em áreas em que ainda não trabalharam. Por exemplo, fazer um artista
acompanhar um programador durante um dia para aprender como codificar
recursos para a ferramenta de criação artística. Ou fazer um artista passar o
dia testando o jogo com o departamento de QA para aprender os detalhes de
testes, registro e regressão de bugs. Uma vez que as pessoas passarem algum
tempo desempenhando o papel de outra, entenderão melhor o papel dessa
pessoa no projeto.
Essa prática pode até mesmo levar a melhorias no processo. Por exemplo,
se um artista mostrar a um programador o processo de importar um nível para o
jogo e então pedir que ele o execute, o programador pode perceber que há uma
maneira de melhorar o conjunto atual de ferramentas para tornar o processo
mais fácil para o artista. Um designer com algum treinamento básico em como
criar níveis 3D entenderá melhor como deve documentar seus designs de ní-
veis para eles serem mais facilmente convertidos em espaços 3D por um artista.
O treinamento cruzado também é uma boa maneira de integrar novas
pessoas à equipe. Na primeira semana, elas podem passar parte de cada dia
acompanhando um artista, programador ou designer. Essa atividade pode
ajudá-las a se tornar parte da equipe mais rapidamente e saber quais são os
papéis e responsabilidades das pessoas no projeto.
Leituras recomendadas, Gerenciamento

The Tao of Coaching, de Max Landsberg, oferece vários exercícios de acon-
selhamento excelentes acompanhados de exemplos divertidos de ler e fáceis
de entender.
The Mythical Man-Month, de Frederick P. Brooks, é um livro respeitado
que contém ideias importantes sobre o custo da mão de obra no desenvolvi-
mento de software. Este livro é altamente recomendado para qualquer pessoa
que trabalhe desenvolvendo software.
Marcus Buckingham e Curt Coffman, autores de First Break All the Ru-
les: What the World’s Greatest Managers Do Differently, fizeram pesquisas
com gerentes de várias empresas para determinar que qualidades os gerentes
eficientes possuem.
Peopleware, de Tom DeMarco e Timothy Lister, é direcionado a gerentes
e líderes de equipe que coordenam equipes de desenvolvimento de software.
Este livro oferece muitos conselhos práticos para a construção de equipes, a
seleção dos líderes certos e o aumento da produtividade.
Formas de agrupamento
As formas de agrupamento podem afetar a força da equipe. Se você tiver todos
os programadores, designers e artistas sentados em grupos separados, será
difícil fazer a comunicação fluir entre os grupos. Se os profissionais de áreas
afins ficarem juntos, tenderão a se concentrar somente nos recursos que estão
criando para o jogo, em vez de também levar em consideração a contribuição
das outras áreas. Surgirão situações em que os artistas reclamarão dos pro-
gramadores, os programadores reclamarão dos designers, os designers recla-
marão dos artistas, e assim por diante. A motivação será afetada, já que uma
mentalidade “nós” contra “eles” se desenvolverá dentro da equipe.
Embora artistas, programadores e designers possam preferir se agrupar
por área de atuação, pensando ser mais útil consultar seus pares quanto a uma
questão técnica ou artística, esse agrupamento não ajuda em nada na constru-
ção da equipe. Uma melhor forma de agrupamento é aquela em que as pessoas
que estão trabalhando em recursos semelhantes ficam juntas, para poder estar
em contato imediato com quem estiver trabalhando em funcionalidades pare-
cidas. Por exemplo, a reunião de criadores de níveis, programadores gráficos
e roteiristas cria um grupo multifuncional responsável pela manipulação de
todos os aspectos de criação de um nível jogável. Ainda que essas pessoas
sejam de áreas diferentes, elas dependem do trabalho umas das outras para
fazer algo funcionar com sucesso no jogo. Você também pode agrupar os ani-
madores e programadores que estiverem trabalhando juntos no sistema de
animação, o que ajudaria a melhorar o processo de feedback.
Além disso, considere os tipos de personalidades que estão sentadas
próximas umas das outras. Se possível, certifique-se de que pessoas positi-
vas e entusiasmadas sejam posicionadas em todas as salas da equipe. Essas
pessoas trazem uma energia positiva natural para a equipe e deixam os outros
7 • Equipes 117
realmente empolgados com aquilo em que estão trabalhando. Elas também

ajudam a reduzir a energia negativa de pessoas que têm tendência a reclamar.
Os membros da equipe podem reclamar de mudar de lugar entre os gru-
pos de assentos, principalmente se não estiverem acostumados a fazer isso.
Também podem ficar preocupados com o aumento no nível de ruído em um
ambiente em que as pessoas são encorajadas a conversar umas com as ou-
tras. Para manter o ambiente de trabalho produtivo, informe-os que qualquer
reunião que durar mais do que alguns minutos e/ou envolver três ou mais
pessoas deve ser conduzida em áreas fora da sala da equipe para que os outros
não sejam incomodados. Você também pode comprar “tapa-ouvidos” para to-
dos na equipe. Dessa forma, as pessoas se sentirão mais confortáveis no am-
biente mais aberto.
Reuniões da equipe
As reuniões também são uma boa oportunidade de melhorar a construção
da equipe. Como discutido anteriormente neste capítulo, elas são uma óti-
ma maneira de introduzir novos membros e de conhecer melhor os mem-
bros existentes. As reuniões da equipe são principalmente um momento para
discussão do progresso do jogo e fornecem um fórum para os membros da
equipe levantarem questões e preocupações. À medida que as equipes de
desenvolvimento forem crescendo, esse fórum regular será mais importante
para os membros que não estiverem totalmente envolvidos com as ocorrên-
cias diárias do projeto.
Forneça uma atualização completa do projeto a cada reunião. Discuta
que progressos foram feitos no plano geral do projeto, que eventos de mar-
keting e RP estão sendo planejados, que progressos foram feitos na obtenção
da aprovação de licenças, o status atual de solicitações de hardware e o que
mais tiver ocorrido no projeto na semana anterior. Essas informações ajudam
as pessoas a ter uma noção geral do jogo e saber como seu trabalho se encaixa
nesse cenário maior. O entusiasmo da equipe aumentará quando os membros
virem o volume de trabalho que foi executado na última semana.
As reuniões da equipe também constituem um bom momento para a dis-
cussão de qualquer boato que estiver circulando sobre o projeto ou a empresa.
Se os boatos não forem verdadeiros, deixe isso claro na reunião. Mas se algo
no boato for verdadeiro, diga à equipe exatamente qual é a situação. Dar ex-
plicações é muito melhor do que permitir que as pessoas comecem a basear
suas decisões em boatos que saírem de controle. Discuta também etapas futuras
e possíveis mudanças no cronograma. Se os membros forem lembrados com
algumas semanas de antecedência sobre um prazo iminente, podem começar
a trabalhar de maneira mais eficiente para evitar correrias antes do prazo ter-
minar. Mas se o cronograma mudar por alguma razão – se os prazos forem en-
curtados ou alongados –, informe isso à equipe e explique as razões. A equipe
se comprometeu com o jogo e tem o direito de saber sobre mudanças ocorridas
no plano.
Estabeleça uma hora fixa para a reunião, de modo que ela passe a ser
um compromisso na mente dos membros da equipe. Faça anotações durante
a semana sobre os itens que serão discutidos na próxima reunião. As pessoas

passarão a considerar a reunião da equipe como uma fonte de informações
úteis. Também não custa nada fornecer ocasionalmente alguns biscoitos ou
rosquinhas durante a reunião.
Site da equipe
Um wiki ou site bem cuidado funciona como a principal fonte de informações
sobre o projeto e é um ótimo recurso de construção da equipe. O site é um depó-
sito ativo de documentos de design, protótipos, listas de tarefas, fotos de mem-
bros da equipe e outros materiais relacionados ao projeto. Deve ser bem organi-
zado para que as pessoas possam achar facilmente as informações que precisam.
Alguns tipos de informação que podem ser incluídos no site são os seguintes:
• Documentos de design
• Documentos técnicos
• Cronogramas de reuniões
• Duração das reuniões
• Relatórios de status semanais
• Atualizações de marketing
• Diretrizes de processos
• Férias e ausências
• Prazos de etapas-chave
• Descrições dos produtos das etapas
• Planos de teste de QA
• Informações de contato (números de telefone e endereços de e-mail pes-
soais)
• Formulários (relatórios de despesas, solicitações de alteração e assim por
diante)
• Nomes e tarefas de cada membro da equipe
• Protótipos
• Cronogramas de desenvolvimento
• Diretrizes de teste de jogabilidade
• Anúncios importantes (novos membros na equipe, mudanças no crono-
grama etc)
O armazenamento dessas informações em um local de acesso público

permite que os membros da equipe fiquem tão informados quanto quiserem
sobre o projeto. Algumas pessoas visitarão pouco o site; outras o tornarão sua
página inicial e o acessarão diariamente. O site da equipe também é uma ótima
ferramenta para novos membros serem instruídos sobre o projeto ou de dire-
cionamento da gerência para o conjunto mais atual de documentos de design.
Para tornar o site da equipe uma ferramenta eficaz, mantenha-o sem-
pre atualizado. Assim, a equipe poderá procurar no site as informações mais
atuais do projeto. Essa prática também assegura que a equipe inteira tenha
acesso igual a todas as informações – e não apenas os poucos que perguntam
constantemente aos líderes sobre o status do projeto. No momento em que os
7 • Equipes 119
membros da equipe perceberem que o site não contém as informações mais

recentes, pararão de usá-lo como ferramenta de desenvolvimento e passarão
a depender mais do produtor e dos líderes no fornecimento direto das infor-
mações necessárias.
7.5 Engajamento e motivação da equipe
O engajamento e a motivação são elementos importantes de uma equipe forte.

Se a equipe se sentir responsável ou estiver engajada, será mais eficiente e
produzirá um trabalho de melhor qualidade. Se as pessoas estiverem alta-
mente motivadas e entusiasmadas com o jogo, também não se importarão em
encaixar uma tarefa adicional quando necessário para melhorar o projeto o
máximo possível. Se você se aproveitar desse entusiasmo e implementar pra-
zos apertados obrigatórios por um período extenso, desmotivará a equipe e
provavelmente o resultado será um trabalho de menor qualidade e um grupo
de pessoas frustradas.
Quando as pessoas veem que seu feedback, opiniões e preocupações es-
tão sendo considerados na tomada de decisões, elas se comprometem com
os objetivos do projeto. Esse suporte também ocorre quando elas conseguem
visualizar claramente o sucesso do projeto em suas mentes, o que significa o
jogo sendo entregue no prazo, com ótimas críticas e permanecendo durante
meses como primeiro entre os mais vendidos. Se as pessoas conseguirem vi-
sualizar e compartilhar esse sucesso, vão ficar ansiosas para trabalhar em um
projeto por seis meses ou um ano para transformar o sucesso em realidade.
Se alguns membros da equipe não estiverem motivados ou engajados,
você pode ter um problema sério. Se houver uma ou duas pessoas não sa-
tisfeitas na equipe, esse número aumentará rapidamente se elas estiverem
visivelmente desmotivadas ou falarem sobre sua insatisfação com o projeto.
Quando isso ocorrer, o produtor deve lidar com a situação o mais rápido pos-
sível para impedir que o entusiasmo geral da equipe seja prejudicado.
Sinais de alerta
Funcionários insatisfeitos exibem sinais de alerta que mostram seu desconten-
tamento com sua situação profissional. Se você perceber algum desses sinais
de alerta, resolva-os o mais rápido possível. Infelizmente, quando esses sinais
de alerta se manifestam, o problema já é muito sério e requer um grande esforço
para ser resolvido de maneira satisfatória. Alguns desses sinais de alerta são:
Ausências ou atrasos excessivos ou não planejados: O funcionário está
chegando e saindo do trabalho na hora? Está obtendo muitas licenças
por doença? Está pedindo liberação para férias na última hora? Embora
as ausências possam ser justificadas por problemas pessoais em casa,
elas também podem indicar que um funcionário está insatisfeito com
sua situação no trabalho. Se a vida pessoal de um funcionário estiver afe-
tando sua disposição para trabalhar, ele deve notificar isso à sua gerên-
cia para tentar encontrar uma solução temporária. No entanto, se estiver
constantemente infeliz no trabalho, talvez esteja procurando emprego
em outro local e é por isso que se ausenta ou atrasa. Podem existir mui-
tas razões para ele estar procurando outro emprego e se você parar para
pensar quais seriam, talvez consiga impedir que um funcionário exem-
plar procure um concorrente.
Comprometimento: O funcionário se compromete prontamente com
uma atribuição de longo prazo (por exemplo, trabalhar pelos próximos
seis meses na criação da infraestrutura de rede de um jogo)? É difícil de
convencer sobre planos de férias futuras? Se você sentir que alguém não
está comprometido em ficar na equipe a longo prazo, tem de descobrir
por quê.
Reclamações: O funcionário reclama publicamente da gerência ou de
outros membros da equipe? Por exemplo: “Ele é um inútil, não enten-
de nada de …”. Queixosos proativos acabam mudando de emprego; os
menos proativos não, mas suas reclamações criarão um ambiente de tra-
balho negativo. Isso, por sua vez, gerará mais funcionários insatisfeitos.
Falta de empenho: O funcionário é produtivo? Perde prazos ou não se
preocupa se está atrasado? Usa seu tempo de maneira eficiente? Ou se
demora fora de sua mesa, conversando com outros funcionários? É bom
ressaltar que esse comportamento também pode indicar que o funcioná-
rio está com acúmulo de tarefas e perde tempo porque não sabe como li-
dar com elas, portanto, se distrai esperando que o problema desapareça.
Ou pode indicar que a carga de trabalho do funcionário não é adequada
e ele não tem tarefas e responsabilidades suficientes para manter-se ocu-
pado durante oito horas por dia.
Apatia: O funcionário está ativamente envolvido com o projeto ou ape-
nas vem trabalhar e passa suas oito horas sem fazer nenhum comentário?
Se as pessoas não estiverem entusiasmadas com o projeto em que estão
trabalhando ou com o papel que desempenham no projeto, se tornarão
funcionários apáticos e menos eficientes. Além disso, se já estiveram
extremamente envolvidas no passado, mas repentinamente ficaram apá-
ticas, com certeza algum incidente específico disparou esse comporta-
mento. A apatia pode se espalhar rapidamente pela equipe se não for
resolvida.
Solicitações não atendidas: Se um funcionário tiver solicitado ferra-
mentas (como um novo computador) para fazer um trabalho melhor, mas
essas solicitações não forem atendidas a tempo (ou de forma alguma),
começará a surgir insatisfação. Se a solicitação envolver algo que possa
ser facilmente obtido, essa é uma ótima maneira de mostrar boa vontade
aos funcionários e fazê-los saber que a gerência se preocupa com suas
necessidades. Se por alguma razão a solicitação não puder ser atendida,
explique isso para o funcionário e discuta se ele aceitaria outra coisa.
7 • Equipes 121
Quando esses sinais de alerta se manifestarem, talvez já seja difícil rever-

ter a situação e transformá-la em algo positivo. Um produtor que se mantiver
atento ao humor das pessoas da equipe poderá detectar alguns desses sinais de
alerta mais cedo, antes da situação sair muito de controle. O produtor deve co-
nhecer os funcionários e seus hábitos de trabalho. Por exemplo, pessoas que se
atrasam constantemente podem apenas não estar conseguindo acordar na hora.
ENTUSIASMO DA EQUIPE
Stuart Roch, produtor executivo

Activision
Se sua equipe de desenvolvimento estiver desmotivada, certamente você perceberá. A pro-

dutividade deve cair, as licenças por doença e para a resolução de problemas pessoais
podem aumentar e você ouvirá reclamações até mesmo sobre o sistema de refrigeração
estar fazendo barulho nos canais subterrâneos. O segredo do produtor proativo é princi-
palmente assegurar que a equipe não fique desmotivada. Gerenciar um projeto correta-
mente desde o início e ser organizado tendo um cronograma regular e revisões de recursos
são comportamentos que podem fazer a diferença.
Quando uma equipe está desmotivada, com frequência não há muito a se fazer para
tirá-la desse estado. Oferecer abonos financeiros não surte muito efeito, nem discursos
entusiásticos nas reuniões regulares. O que geralmente deixa uma equipe desmotivada é
um projeto significativamente atrasado, demandando horas extras, ou um produto que
simplesmente não é atraente, causando um mal-estar geral em vez de entusiasmo no nú-
cleo da equipe. Quando o projeto está atrasado, os produtores têm de lidar com a equipe
desmotivada de várias maneiras diferentes, dependendo da situação, sabendo que a essa
altura não há muito a se fazer para entusiasmá-la novamente.
Atacando os sinais de alerta

Se você detectar algum desses sinais de alerta, deve conversar com o funcioná-
rio imediatamente. Uma de suas responsabilidades como gerente é assegurar
que seus funcionários estejam satisfeitos e sejam produtivos. Se ignorar esses
sinais, os problemas só ficarão piores e o funcionário pode acabar diminuindo
o entusiasmo da equipe ou deixando a empresa. Se alguém estiver com pro-
blemas pessoais que estiverem afetando seu desempenho, você terá de lidar
com essa pessoa de maneira diferente do que com alguém que tiver problemas
relacionados ao trabalho. Mas você precisa descobrir a causa do problema para
que ele possa ser solucionado de modo adequado. Faça perguntas ao funcio-
nário que o induzam a conversar sobre o problema; não o confronte nem faça
acusações. Perguntas como “O que você faria nessa situação?” ou “Como você
acha que o projeto está avançando?” são bons pontos de partida para uma con-
versa. As respostas do funcionário revelarão informações úteis sobre o motivo

de estar insatisfeito e o que pode ser feito para melhorar a situação.
Mantenha a comunicação aberta para detectar e lidar com esses sinais.
Se alguém estiver mencionando repetidamente o mesmo assunto, provavel-
mente a raiz do problema ainda não foi resolvida, portanto, você terá de fazer
uma investigação adicional para descobrir qual é realmente o problema para
que ele possa ser resolvido. Lembre-se de que você não pode resolver os pro-
blemas de todo mundo, não importa o quanto tentar – algumas pessoas nunca
ficarão satisfeitas. No entanto, muitos funcionários ficarão gratos pelos esfor-
ços que você fez para resolver seus problemas e criar um ambiente de trabalho
agradável para eles.
MOTIVAÇÃO DA EQUIPE
Se o produtor tiver uma equipe em processo de deterioração, terá de priorizar a mo-

tivação de seus membros. Palavras de estímulo, como as proferidas nos vestiários nos
intervalos dos jogos, podem ter um impacto muito positivo. Se as equipes não estiverem
sendo informadas do que está ocorrendo com o jogo como um todo, tenderão a se de-
sagregar, em vez de seguir juntas. Mesmo se estiverem trabalhando apenas em uma pe-
quena parte do jogo, é preciso que saibam o que está ocorrendo no restante da empresa.
Faça a equipe se sentir como um grupo realmente coeso trabalhando em conjunto para
atingir o mesmo objetivo.
Mostrando satisfação
Outra maneira de aumentar o entusiasmo e criar um ambiente de trabalho
mais agradável é mostrar regularmente satisfação com a equipe. Esse feed-
back vai lhes mostrar que você os vê como pessoas e não apenas recursos do
cronograma de projeto e que está ciente dos sacrifícios que eles estão fazendo
para criar um grande jogo. Ainda que alguns desses gestos possam parecer
pequenos e tolos, eles não passarão despercebidos, mesmo se ninguém fizer
nenhum comentário. Alguns exemplos de gestos simples que significam mui-
to são os seguintes:
Forneça alimentação durante horas extras: Se as pessoas estiverem
trabalhando até tarde, pague um jantar saudável. Se estiverem traba-
lhando no fim de semana, forneça almoço. Além disso, abasteça-se com
doces, pretzels e outros lanchinhos (inclusive os saudáveis), para que
haja algo para as pessoas beliscarem durante o dia. As equipes gostam
7 • Equipes 123
de uma refeição gratuita e há menos paradas quando a comida está dis-

ponível no escritório.
Celebre os aniversários mensalmente: Uma vez por mês, durante as
reuniões da equipe, traga bolo ou sorvete para celebrar os aniversários
do mês. As pessoas sempre acham isso divertido e gostam de saber quem
está fazendo aniversário com elas.
Celebre a conclusão das etapas do projeto: A equipe de desenvolvi-
mento trabalha duro para concluir as etapas no prazo, portanto, mostre
reconhecimento trazendo um bolo para celebrar ou dando à equipe in-
gressos grátis para o cinema. Melhor ainda, libere a equipe por algumas
horas durante o dia para que todos vocês possam assistir ao filme juntos.
Festas de lançamento/conclusão: Quando um projeto terminar, organi-
ze uma festa para celebrar o sucesso. Se houver dinheiro suficiente no
orçamento, leve a equipe inteira para um belo jantar.
Agradeça: Lembre-se de dizer “obrigado” à sua equipe por um trabalho
bem feito. O agradecimento pode ser dado na reunião da equipe, por e-
-mail ou ambos. Esse gesto simples fará a equipe saber que seu trabalho
é apreciado.
Compartilhando a visão
Se a equipe entender coletivamente a visão do jogo, os membros terão uma
ideia melhor de como seu trabalho contribuirá para o projeto como um todo.
Logo, é importante manter a equipe informada sobre a visão do jogo, prin-
cipalmente quando essa visão mudar. Uma visão compartilhada significa a
equipe conhecer os objetivos gerais do jogo, quais os recursos principais,
como o enredo e os personagens se encaixam e quem é o público-alvo. Para
a equipe entender melhor esses itens, o produtor tem de informá-la quando
decisões cruciais forem tomadas e explicar o que levou a essas decisões. Essas
informações ajudarão a equipe a ajustar seu trabalho à nova visão do jogo.
Uma comunicação sólida, clara e aberta é essencial para o estabeleci-
mento de uma visão compartilhada com a equipe. Uma maneira simples de
se fazer isso durante a pré-produção é postar o conceito e a visão iniciais do
jogo no site. Continue a construção desse conceito com documentos de design
e protótipos para a equipe poder participar da evolução do jogo do conceito à
versão gold master.
Durante a produção, reserve algum tempo nas reuniões semanais da
equipe para demonstrar a última versão do jogo. Mostre os novos elementos
que foram adicionados após a última semana e cite quem os criou. À medida
que o jogo for ficando mais estável, reserve horários para a equipe testar a
jogabilidade e participar de sessões com vários jogadores. Além disso, divul-
gue publicamente informações-chave sobre o jogo nas salas da equipe. Essas
informações devem incluir a arte conceitual, resumos de missões, esquemas
de controle e qualquer outra coisa que ajude a comunicar do que trata o jogo.
Pesquisa na equipe
Se a equipe de desenvolvimento parecer pouco entusiasmada, o produtor
deve descobrir o motivo e remediar a situação o mais rápido possível. No
entanto, se a equipe inteira estiver desmotivada, será mais difícil descobrir
a causa, já que você terá de saber por que várias pessoas estão insatisfeitas e
não apenas uma.
Uma maneira de descobrir isso é conduzindo uma pesquisa anônima na
equipe. A pesquisa deve fazer perguntas sobre até que ponto as pessoas enten-
deram os objetivos do projeto, se conhecem bem seus prazos e que confiança
têm no sucesso do trabalho. Pergunte também como a comunicação poderia
ser melhorada, que problemas elas acham importantes e que elementos do
jogo são mais empolgantes. Será útil se você definir um sistema de classifi-
cação numérica para as respostas, já que esse sistema facilitará a organização
das informações e a priorização das áreas com as quais as pessoas estão mais
insatisfeitas. Em perguntas abertas, indague coisas como “Quais são os três
elementos que mais o empolgam nesse jogo?” ou “Quais são os três elementos
que mais o preocupam nesse jogo?” para que os participantes possam forne-
cer particularidades em cada resposta. Isso lhe permitirá organizar as respos-
tas para ver quais particularidades são mencionadas com mais frequência.
Uma pesquisa anônima é eficaz para mostrar problemas não identifica-
dos. As pessoas são mais honestas em suas opiniões quando sabem que não
terão problemas por causa delas. Não fique surpreso se ouvir reclamações
sobre coisas que você nem mesmo sabia que existiam ou se as pessoas recla-
marem sobre o péssimo trabalho que o produtor está fazendo.
Quando as pesquisas forem devolvidas, organize as informações e redija
um relatório resumido. Compartilhe esse relatório com a equipe e marque
uma reunião para discutir todas as áreas de preocupação, que medidas estão
sendo tomadas e quem está encarregado de pôr as soluções em prática. O
plano de ataque é o aspecto mais importante da pesquisa porque ele mostra à
equipe que suas preocupações são válidas e ações estão sendo tomadas para
melhorar a situação. Se você não informar à equipe as ações que estão sen-
do tomadas, provavelmente os membros vão considerar a pesquisa mais um
exercício inútil da gerência e ficarão ainda mais desmotivados.
Quando os problemas maiores forem resolvidos e a equipe parecer ter
melhorado, se quiser, faça a pesquisa novamente, alguns meses depois. Repe-
tir a pesquisa é útil para ver se a atitude da equipe está mais positiva e se as
pessoas ainda estão preocupadas com as mesmas coisas. Se as mesmas preo-
cupações aparecerem na segunda pesquisa, o plano de ação não foi tão eficaz
como deveria. Em casos assim, continue pedindo feedback sobre as soluções
que a equipe acha que resolverão o problema e vá em frente com elas. Se a
pesquisa mostrar que o entusiasmo geral está mais alto e há menos problemas,
o plano de ação pode ser considerado eficaz. A segunda pesquisa também re-
velará o próximo conjunto de problemas que precisa de soluções.
7 • Equipes 125
AUMENTANDO O ENTUSIASMO DA EQUIPE
Heather Chandler
Media Sunshine, Inc.
Em qualquer equipe de desenvolvimento, alguém tem de ficar alerta para o seu entusias-
mo. Se a equipe não estiver muito entusiasmada, a qualidade e a eficiência de seu traba-
lho serão afetadas. Todos os membros da equipe de desenvolvimento têm algo importan-
te com o qual contribuir e precisam ouvir que seu trabalho é apreciado.
Quando trabalhávamos na versão Xbox de Ghost Recon 2, tivemos a ideia do discurso
do “Herói”. Na época, estávamos trabalhando bastante para preparar nossa demo para a
E3. Também estávamos no processo de finalizar o nome e a imagem do personagem herói
do jogo. Durante nossa reunião regular com a equipe, demos envelopes lacrados para
todos e dissemos que eles continham o nome e a imagem finais do “personagem herói”.
Os participantes abriram seus envelopes e viram um pequeno espelho dentro. Quando
viram esses espelhos, falamos que eles eram os heróis do jogo e que, se não fosse por eles,
o jogo não teria ficado tão consistente e teríamos de nos virar para concluir o trabalho. É
verdade que tudo isso soava um tanto piegas, mas vários membros da equipe me falaram
depois que gostaram muito do que dissemos e que se sentiram melhor e mais empolgados
com a contribuição que deram para o jogo.
O próximo depoimento discute a importância de mantermos as pessoas

animadas e motivadas.
DEFININDO QUALIDADE DE VIDA
Qualidade de vida pode significar várias coisas para diferentes pessoas. Para alguns é
uma boa casa, boas escolas e jantar com a família. Para outros, no entanto, tudo gira
em torno do trabalho e da criação de um grande jogo. O trabalho é seu hobby. É com
esse grupo que você deve tomar cuidado. Embora não seja preciso tirá-los do prédio to-
dos os dias às 18 horas, você deve deixar bem claro que os quer revigorados e descansa-
dos. Lembre-os de que, quando estão descansados, são mais produtivos e podem olhar
o jogo com uma visão mais clara.
Alguns desses trabalhadores incansáveis podem agir assim porque tiveram de mu-
dar de cidade para assumir o cargo e não conhecem ninguém ou nenhum lugar para se
divertir. Passe algum tempo mostrando-lhes as redondezas e convide-os para fazer algo
divertido. Churrascos com a equipe podem ser um ótimo meio de relaxar e possivelmente
revelarão interesses comuns além do trabalho.
Acima de tudo, lembre-se de que os membros das equipes de desenvolvimento real-

mente trabalham muito e devem continuar assim, mas sem prejudicar seu casamento,
relacionamentos pessoais e saúde. Preocupe-se com sua felicidade e saúde mental e eles
se dedicarão ainda mais ao projeto.
7.6 Qualidade de vida
Nos últimos anos, a qualidade de vida dos desenvolvedores tem sido debatida
pela comunidade de desenvolvimento de jogos digitais, principalmente porque
as pessoas estão se abrindo mais para expressar suas preocupações com os da-
nos de se trabalhar durante longas horas, deixando em segundo plano a família,
os amigos e a saúde. Pergunte a qualquer desenvolvedor sobre esse assunto e
com certeza ele falará sobre uma época em que fazia quantidades insanas de
horas extras durante várias semanas seguidas. Na indústria de jogos, trabalhar
assim é chamado de “crunch time” ou “death march”, e é uma parte aceita e
esperada do desenvolvimento, mas a que custo? Esses mesmos desenvolvedo-
res que fazem horas extras também dirão que as relações familiares e pessoais
foram afetadas, sua saúde começou a declinar ou ambos. Fazer horas extras me-
lhorou realmente o jogo? Vale a pena o desenvolvedor viver, comer e respirar
trabalho? Como as horas de trabalho e a qualidade de vida podem melhorar?
A International Game Developers Association (IGDA) está trabalhando
ativamente nesse problema e criou um grupo de interesse especial dedicado à
melhoria da qualidade de vida dos desenvolvedores de jogos. As informações
que compilaram podem ser acessadas em seu site: www.igda.org/qol.
Em 2004, o comitê redigiu um artigo sobre o estado atual das condições
de trabalho desse segmento, que incluía discussões sobre os desafios para o
desenvolvedor de jogos atingir um equilíbrio saudável entre trabalho e vida
pessoal, o impacto negativo das horas extras, a instabilidade no emprego e a
fragilidade com que as equipes de desenvolvimento são organizadas e geren-
ciadas. Esse artigo apresentava fortes razões para a melhoria da qualidade de
vida, como estudos mostrando que muitas horas extras acabam diminuindo
a produtividade, e que, à medida que os desenvolvedores vão envelhecendo
e constituem famílias, preferem deixar o segmento em favor de empregos que
lhes permitam passar mais tempo com elas.
Infelizmente, já que os produtores lideram os projetos e são responsáveis
pelo cronograma, com frequência são considerados culpados por essas con-
dições de trabalho inadequadas. Se o jogo não for planejado apropriada e rea-
listicamente pelo produtor, a equipe pode acabar fazendo muitas horas extras
para implementar seus principais recursos. Além disso, muitos produtores
não têm nenhum tipo de treinamento formal em gerenciamento de projetos,
principalmente projetos de desenvolvimento de software, o que torna difícil
para eles determinar apropriadamente o escopo, o tempo e os recursos de um
projeto específico.
7 • Equipes 127
Uma das maneiras de melhorar a qualidade de vida é estudando técnicas

formais de gerenciamento de projetos e pesquisando como as empresas não
pertencentes ao segmento de desenvolvimento de jogos conseguem executar
projetos sem esgotar seus funcionários ou deixá-los doentes – empresas pú-
blicas, desenvolvedoras de software empresariais e outras corporações que
executam projetos em larga escala. A IGDA está procurando soluções nessas
áreas e postou informações sobre melhores práticas de desenvolvimento de
software no site Quality of Life.
A qualidade de vida é uma questão importante porque a safra atual de
talentos está ficando esgotada, doente e não consegue estar com a família e os
amigos. Esse esgotamento diminui o entusiasmo geral, a eficiência e a qualida-
de de trabalho de uma equipe. Os desenvolvedores estão começando a entender
que a solução para esses problemas não surgirá da noite para o dia, mas tam-
bém estão procurando meios de melhorar a situação agora, como os seguintes:
Planejar um limite de horas extras no cronograma: Se uma ou duas
semanas de horas extras forem agendadas antecipadamente para as eta-
pas-chave, os envolvidos poderão planejar o impacto em suas vidas pes-
soais. Além disso, se eles souberem quando ocorrerão as horas extras,
poderão tentar trabalhar de maneira mais eficiente durante o período
anterior ao prazo apertado para reduzir a quantidade de horas extras.
Estudos mostraram que fazer muitas horas extras diminui a produtivida-
de, portanto, não programe mais do que duas semanas seguidas de horas
extras.
Dar compensação de horas no fim do projeto: A “compensação de ho-
ras” é uma licença adicional que compensa as horas extras trabalhadas.
Quando um projeto for concluído, dê aos funcionários a compensação
de horas para eles poderem relaxar, recarregar suas baterias e voltar ao
trabalho revigorados.
Treinamento gerencial para produtores e líderes: Sólidas habilidades
de gerenciamento de projetos e pessoas são cruciais para a resolução
de problemas de horas extras e equilíbrio entre trabalho e vida pessoal.
Bons gerentes de pessoal sabem como manter as equipes motivadas e
como aumentar o entusiasmo. Bons gerentes de projeto conseguem
HORAS EXTRAS

Activision
Mais do que qualquer pessoa, são os produtores os maiores responsáveis pela equipe e
pelo controle da qualidade de vida. Como líder da equipe, se ele gerenciar vários projetos
seguidos inadequadamente, garantirá a execução de horas extras e uma baixa qualidade

de vida, da mesma forma que o planejamento e o controle adequados dos projetos desde
o início pode quase eliminar a necessidade de horas extras, exceto durante pequenos pe-
ríodos baseados em tarefas.
Embora a cultura de uma empresa possa ser tal que as horas extras sejam conside-
radas parte do trabalho, é responsabilidade do produtor limitar o escopo de design do
projeto a um patamar aceitável – dadas as restrições no cronograma – e fazer correções
apropriadas no curso das ações quando necessário para manter a equipe trabalhando
para atingir objetivos racionais, se o projeto começar a sair de controle. Em um projeto
gerenciado adequadamente, as horas extras devem ser usadas minimamente e quando
necessário e baseadas em objetivos direcionados a tarefas durante períodos curtos, em vez
de serem usadas pela equipe inteira sem um objeto final definido. Reduzir as horas extras
do projeto e manejá-las corretamente quando necessário é o melhor que um produtor
pode fazer para manter a equipe motivada.
Quando horas extras forem necessárias, lembre-se de que os desenvolvedores têm
famílias. Gestos delicados como mandar flores para a esposa de um membro da equi-
pe no aniversário dele ou recompensar o trabalho bem feito por um membro com um
cartão-presente de um bom restaurante, para que a esposa possa usufruir da gratificação,
ajudam muito a mostrar reconhecimento pelos sacrifícios da família em casa. É claro que
esses pequenos gestos não eliminarão totalmente os sentimentos negativos que a família
de um membro da equipe pode ter, portanto, os produtores devem lembrar que as horas
extras não afetam apenas os membros da equipe.
controlar o cronograma, o que resulta em menos horas extras, melhor

qualidade do trabalho e uma equipe mais forte.
Existem equipes de várias formas e tamanhos, mas lembre-se de que elas são
compostas por pessoas, e os produtores têm de saber lidar com as pessoas e
com a equipe como um todo. Se os membros da equipe não estiverem felizes
e sendo produtivos, a equipe também não será. O produtor deve dedicar boa
parte de seus esforços à construção e manutenção de uma disposição sólida e
de uma motivação forte na equipe. Isso é feito com a seleção de líderes fortes,
o comprometimento com exercícios de construção da equipe e a rápida rea-
ção a qualquer sinal de funcionários insatisfeitos. O produtor deve ter sólidas
habilidades de gerenciamento de pessoas e projetos e ser um bom comuni-
cador. O próximo capítulo descreverá algumas maneiras de promover a boa
comunicação em um bom projeto e usá-la como ferramenta para melhorar as
interações na equipe.
8
COMUNICAÇÃO EFICAZ
Neste capítulo
• Comunicação escrita • Estabelecendo normas • Desafios da
• Comunicação oral de comunicação comunicação
• Comunicação não
verbal
8.1 Introdução
Nos numerosos post-mortems publicados pela Game Developer Magazine,

com frequência a comunicação é citada como algo que precisa melhorar du-
rante o processo de desenvolvimento de jogos. Mas o que significa exata-
mente melhorar a comunicação? Em primeiro lugar, como saber se a comu-
nicação é ruim? O que é uma boa comunicação? Essas são perguntas difíceis
de responder, porque cada pessoa gosta de receber informações de uma ma-
neira, ou seja, certas formas de comunicação são mais eficazes para algumas
pessoas do que para outras. Podemos pensar que estamos comunicando algo
claramente para só depois descobrir que a outra pessoa nos interpretou mal.
Como produtor, é sua responsabilidade promover uma boa comunicação
na equipe e assegurar que todos recebam as informações corretas e necessá-
rias em um formato inteligível. Os tipos de comunicação que ocorrem dia-
riamente durante qualquer projeto são a escrita (e-mail e notas de reunião),
a oral (reuniões) e a não verbal (linguagem corporal). Este capítulo discutirá
algumas maneiras gerais de melhorarmos essas áreas de comunicação e ma-
neiras simples de lidarmos com os desafios de nos comunicar.
8.2 Comunicação escrita
Durante o desenvolvimento de um jogo, geralmente a comunicação escrita é a

principal forma de o produtor transmitir informações. Quantos e-mails você
envia e recebe em um dia? Para a maioria dos produtores e líderes, pode ser
acima de 100 ou mais – o que é muita informação para ler e assimilar em um
só dia. As interações por e-mail devem ser claras e concisas, para que você
não passe o dia inteiro no computador lidando com suas mensagens, em vez
de interagir com a equipe em um nível mais imediato. Aqui estão algumas
diretrizes para a redação de e-mails claros e eficazes:
• Use títulos informativos.

• Coloque as informações mais importantes no início.
• Use um estilo conciso.
• Inclua particularidades, principalmente em relação a prazos e outras in-
formações importantes.
• Construa malas-diretas para reduzir o spam interno.
• Use a marca “alta prioridade” moderadamente, ou as pessoas ignorarão
sua importância.
• Use frases coerentes e sem erros de gramática.
• Use listas com marcadores para transmitir rapidamente os pontos prin-
cipais.
• Use uma fonte grande e fácil de ler.
Muitas dessas diretrizes são aplicáveis também à redação de outros tipos

de documentos, como notas de reunião ou relatórios de status. E você pode
criar um formato padronizado para que as pessoas consigam entender me-
lhor as informações apresentadas. Em alguns casos de comunicação escrita,
principalmente se as informações forem cruciais, você terá de fazer um acom-
panhamento pessoal com os destinatários para confirmar se eles receberam
o e-mail, as notas ou o relatório e estão interpretando as informações corre-
tamente. Esse acompanhamento só leva alguns minutos, e se as informações
forem vitais, o tempo gasto terá valido a pena.
8.3 Comunicação oral
A comunicação oral é a forma mais eficaz de comunicação, principalmente

quando é preciso discutir tópicos delicados (como más notícias) ou motivar
a equipe para concluir uma etapa. A comunicação face a face com alguém
é mais pessoal porque o interlocutor pode interagir conosco e ter suas per-
guntas ou preocupações respondidas imediatamente. No entanto, também
pode ser duvidosa, já que a comunicação verbal depende da interpretação e
algumas pessoas “ouvem seletivamente” e só guardam as informações que
querem guardar.
8 • Comunicação Eficaz 131
As reuniões, formais ou informais, são uma das principais formas de

comunicação oral do produtor. Logo, aproveite ao máximo todas as suas reu-
niões. Do ponto de vista do processo, defina uma agenda, tome notas e liste
os itens de ação de cada reunião. (O Capítulo 18, “Técnicas de produção”,
apresenta mais informações sobre como fazer reuniões úteis.)
Para as reuniões serem eficazes, é preciso pensar no que será dito e qual
a melhor maneira de dizê-lo. Por exemplo, se você estiver discutindo com a
equipe algumas mudanças importantes na jogabilidade que acabaram de ser
passadas pela gerência, não comece a reunião reclamando da gerência e de
como essas mudanças são absurdas. Em vez disso, concentre-se nos aspec-
tos positivos das mudanças e apresente diplomaticamente para a equipe as
razões por que elas serão feitas. Você não precisa fazer as razões parecerem
interessantes, apenas tenha cuidado em como apresenta essas informações
para não aborrecer as pessoas desnecessariamente – provavelmente elas res-
ponderão melhor a uma comunicação positiva em vez de negativa.
Certifique-se também se entendeu o que as pessoas estão lhe dizendo.
A comunicação é uma via de mão dupla, e se você interpretar mal um dos
membros de sua equipe, isso pode se refletir desfavoravelmente. A escuta
ativa é uma técnica que nos assegura uma compreensão melhor do que esta-
mos ouvindo. Essa técnica não é fácil de executar na primeira vez, mas você
adquirirá mais experiência com a prática. Na escuta ativa nos concentramos
ativamente no que a pessoa está dizendo e mostramos isso repetindo oca-
sionalmente o que foi dito. Não é preciso repetir tudo; seria uma chateação
para a pessoa que está falando e ela pode achar que você está apenas reme-
dando sua fala, em vez de ouvi-la. Portanto, repita apenas os pontos-chave.
Por exemplo, se alguém estiver reclamando de um colaborador, você pode
dizer algo como: “Deixe-me ver se entendi bem. Joe está lhe chamando a
atenção porque acha que você está atrasado em suas tarefas, quando, na
verdade, Sam é que está atrasado, o que está afetando seu trabalho”. Se você
estiver correto, a pessoa concordará e continuará a conversa. Se estiver er-
rado, ela lhe dirá a informação de novo, possivelmente de outra forma, até
você repetir corretamente.
Isso também pode funcionar inversamente. Se você estiver apresentando
informações para alguém, como mudanças no cronograma de produção, ter-
mine a conversa perguntando quais são as mudanças e como elas afetarão o
cronograma da pessoa. Não é difícil fazer as pessoas repetirem o que lhes foi
dito e, se elas errarem, diga as informações de uma maneira diferente até ter
certeza de que entenderam. Na maioria dos casos, também devemos comple-
mentar as conversas com informações-chave e as decisões com e-mails. Dessa
forma, um registro escrito sempre estará disponível para consulta.
Quando você estiver se comunicando verbalmente com alguém, lembre-
-se dessas informações básicas:
• Não murmure; seja claro em sua declaração.

• Não fale em voz baixa, principalmente durante reuniões.
• Não use palavras de baixo calão.
• Não fale sozinho; converse com as pessoas.
• Faça pausas de vez em quando, para que as pessoas tenham a chance de

dizer algo.
8.4 Comunicação não verbal
O que comunicamos não verbalmente tem tanto impacto quanto o que dize-
mos. Por exemplo, quantas vezes você fez uma pergunta a alguém e a pessoa
agiu como se tivesse sido interrompida em algo importante (mesmo se estives-
se apenas navegando na Internet)? É como se estivéssemos atrapalhando, até
mesmo quando temos uma pergunta válida relacionada a trabalho, e, portanto,
não nos aproximamos dessa pessoa de novo exceto quando absolutamente ne-
cessário. Além disso, com que frequência já pegou alguém de mau-humor, por
alguma razão, e a pessoa descontou em você só porque estava por ali? E quanto
a pessoas que não nos levam a sério – elas transformam tudo em piada e agem
como se não soubéssemos nada? Incidentes como esses não são agradáveis, ge-
ralmente aborrecem e podem afetar como percebemos as pessoas no trabalho.
Como produtor, você deve ser particularmente cuidadoso com a maneira
como suas pistas não verbais são compreendidas pela equipe. Como seu líder,
tem de estar sempre disponível para perguntas (não importa de que magnitude),
conseguir transformar algo negativo em positivo (e não o contrário) e agir de
uma maneira decisiva (até mesmo ao pedir ajuda aos outros). Você não pode se
dar ao luxo de ser caprichoso, desinteressado ou afetado – esse comportamento
diminuirá rapidamente o respeito e a autoridade conquistados na equipe.
Por exemplo, se você estiver em um escritório, não mantenha sua porta
fechada o tempo todo. Se estiver em um cubículo, não fique constantemente
com os fones de ouvido. Os dois comportamentos indicam que você está
indisponível e não quer ser incomodado por ninguém. Essa atitude pode
ser desencorajadora para membros da equipe que se sentirem mais seguros
sabendo que você está sempre disponível para eles. Lembre-se de que uma
de suas principais responsabilidades como produtor é servir à equipe e não
o contrário.
Se alguém se aproximar para conversar e você achar a pessoa incômo-
da, não vire os olhos ou suspire; em vez disso, aja como se estivesse pronto
para conversar e resolver qualquer problema que ela estiver tendo. Um “olá”
amigável ajuda bastante, portanto, quando passar pelas salas da equipe, sor-
ria, pare nas mesas das pessoas e veja em que estão trabalhando. Se você
mostrar um interesse genuíno no que a equipe está fazendo, eles apreciarão
o reconhecimento.
Já que as pistas não verbais são muito importantes e temos um método
preferido de dar e receber informações, será útil se você ler alguns livros de psi-
cologia para entender melhor as pessoas. Além disso, existem muitas informa-
ções sobre diferentes tipos de personalidades e como elas interagem umas com
as outras, o que é bom saber quando gerenciamos grandes grupos de pessoas
com personalidades diferentes. Por exemplo, o livro Type Talk at Work discute
como costumam funcionar os 16 tipos de personalidades de Meyers-Briggs em
um ambiente de trabalho. O autor discute maneiras eficazes de se comunicar,

definir objetivos, construir equipes etc. com cada tipo de personalidade. Lem-
bre-se de que os tipos de personalidade são estereótipos; portanto, não espere
que as pessoas se encaixem exatamente em apenas uma categoria.
8.5 Estabelecendo normas de comunicação
As normas de comunicação são diretrizes que as pessoas adotam consciente

ou inconscientemente ao interagir umas com as outras. Essas normas são for-
muladas de diversas maneiras: podem surgir naturalmente com o tempo, são
definidas antecipadamente ou são acionadas por um problema que precise de
solução. Um exemplo de norma que surge naturalmente seria o hábito de pa-
rar na sala de seu chefe toda manhã para atualizá-lo sobre o que você planeja
fazer durante o dia. Se em uma manhã você não conversar com seu chefe, os
dois podem achar que algo está errado sem saber o quê. Um exemplo de nor-
ma que é definida antecipadamente é quando seu chefe exige que você passe
em sua sala toda manhã às 9 horas e o atualize em relação ao que planeja fazer
durante o dia. Se você não fizer isso, ele vai querer saber por que não compa-
receu ao seu compromisso. E, para concluir, se houver um problema em seu
projeto que coloque a data de entrega em risco, seu chefe pode instituir uma
política em que você tenha de enviar uma lista de tarefas para ele toda ma-
nhã – essa norma costuma ser estabelecida como solução para um problema
específico.
O estabelecimento de normas de comunicação para a equipe pode ajudar
a promover uma boa comunicação entre os membros. Além disso, o envolvi-
mento da equipe na definição de um conjunto de normas é uma ótima ativi-
dade de consolidação da equipe – cada um dá sua opinião sobre quais seriam
as normas e todos concordam com a lista final. Depois que um conjunto de
normas for estabelecido, surgirão naturalmente outras normas que melhora-
rão a comunicação geral entre os membros da equipe, os líderes, o produtor e
a gerência do estúdio.
É simples conduzir uma reunião para o estabelecimento de algumas
normas de comunicação. Reúna a equipe inteira na sala, peça que discutam
alguns dos problemas de comunicação que estão tendo no projeto e estabe-
leça que áreas precisam de melhorias. Quando os participantes definirem os
problemas de comunicação, conseguirão formular mais facilmente um con-
junto de normas. Após os problemas serem definidos, explique para a equipe
o que são normas e peça que discutam que diretrizes funcionarão para eles.
Quando tiverem discutido todas as ideias, peça que reduzam a quantidade e
definam as normas. Aqui está um exemplo de algumas normas de comunica-
ção de uma equipe:
• Saiba quem é o ponto de contato para suas perguntas.

• Tenha consideração pelo tempo das outras pessoas.
• Não murmure nem fale baixo.
• Não grite nem eleve a voz.

• Seja positivo com as críticas, não reclame.
• Aja profissionalmente com seus pares.
A COMUNICAÇÃO E O DESENVOLVIMENTO DE JOGOS
Jamie Fristrom
Torpex Games
Li vários livros sobre produção de filmes e programas de televisão, já que esses recursos
oferecem conselhos que são aplicáveis à produção de jogos. O que achei interessante foi
que os filmes e a televisão têm indústrias maduras e, portanto, desenvolveram uma técni-
ca que lhes permite se programar de maneira eficaz e cumprir seus prazos. É só considerar
as tomadas necessárias e os personagens que fazem parte dessas tomadas. Eles não pre-
cisam de um sistema de agendamento muito pesado com gráficos Gantt ou o MS Project,
porque já têm um sistema em funcionamento que torna fácil produzir.
Acabaremos chegando a esse ponto no desenvolvimento de jogos, onde teremos
uma técnica semelhante, com a produção de personagens, níveis e outros assets seguindo
um processo padronizado, independentemente do jogo. Ainda teríamos de esboçar o pla-
no de produção, mas se tivéssemos práticas otimizadas e comuns, seria muito mais fácil
estimar precisamente quando um jogo terminaria.
8.6 Desafios da comunicação
Os desafios da comunicação são esperados em qualquer situação, mas uma

comunicação clara certamente os ameniza bastante. Algumas áreas básicas
em que devemos tomar cuidado extra com a comunicação são a resolução
de conflitos, a divulgação de notícias ruins e o fornecimento de um feedback
eficaz sobre o desempenho.
Resolvendo conflitos
Conflitos ocorrem em qualquer projeto, portanto, não fique surpreso se ocor-
rerem no seu. Algumas causas básicas de conflitos são diferenças de perso-
nalidade, comunicação inadequada e desentendimentos sobre como as coisas
ou que coisas devem ser feitas. Como produtor, você se envolverá em con-
flitos e terá de mediar conflitos entre outros membros da equipe. Não tenha
medo de confrontos, porque o conflito não tomará maiores proporções se for
tratado de maneira oportuna e assertiva.
Uma das coisas mais importantes que devemos lembrar no caso de um
conflito é não tentar resolvê-lo enquanto os ânimos estiverem exaltados. Você
ou a outra pessoa podem dizer algo de que se arrependerão depois e o conflito

piorará. Por exemplo, se um recurso for cortado do jogo devido ao cronograma
e você descobrir alguns dias depois que o designer líder instruiu os designers a
continuarem trabalhando nele, não o enfrente enquanto ainda estiver visivel-
mente irritado. Espere um pouco até se acalmar e então lide com a situação. O
mesmo se aplica quando você estiver mediando conflitos entre outras pessoas
– elas só devem discutir a situação após ambas terem se acalmado.
Antes de discutir o conflito com outra pessoa, tente descobrir exatamen-
te do que se trata. No exemplo dado anteriormente, o conflito pode ter se ori-
ginado do designer não ter entendido que o recurso foi cortado do jogo, dele
não ter concordado com essa decisão ou de não ter respeitado sua autoridade
e tentado enfraquecê-la. O que quer que o tenha incomodado, tente entender
bem e formule maneiras para lidar com o problema.
Quando finalmente você se encontrar com a outra pessoa para resolver o
conflito, comece expondo os fatos. Siga essas diretrizes como ponto de partida:
• Não generalize a situação dizendo palavras como “sempre”, “nunca” e

“constantemente”. Atenha-se aos fatos e não faça suposições nem floreie.
• Não presuma que sabe quais foram as motivações para alguém fazer algo.
Há muitas razões para as pessoas agirem da forma que agem, e você não
saberá por que até perguntar a elas.
• Não confunda problemas com personalidades. Por exemplo, se alguém
não entender o que você está dizendo, não presuma que é porque a pes-
soa é estúpida.
• Não resolva conflitos publicamente. Se alguém agir de maneira inapro-
priada durante uma reunião, não censure a pessoa no local; em vez dis-
so, lide com a situação privadamente após a reunião.
Após expor os fatos, descreva o impacto tangível que essa situação terá
sobre o projeto para que a pessoa entenda melhor a causa e o efeito. Dê a ela
uma chance para responder e então diga o que precisa ser feito para remediar
a situação. Mostre como uma melhora na situação beneficiará a ela e ao proje-
to. Usando o exemplo anterior, a conversa poderia ser assim:
“A equipe concordou em cortar o recurso do jogo porque não havia tem-
po suficiente para implementá-lo. Essa decisão foi comunicada na reunião
da equipe e por e-mail. Na quarta-feira, soube por outro designer que você
instruiu os designers a continuarem trabalhando nele. Essa ordem atrasou a
documentação de design da IU e agora a construção da IU ficará parada até
a documentação ser concluída. [Dê à pessoa uma chance para responder. Ela
pode se desculpar, dizer por que quer manter o recurso ou ter uma reação
emotiva. Independentemente do que fizer, esteja preparado para declarar as-
sertivamente sua solução para o problema. Mas dê uma resposta apropriada
à situação.] Os designers precisam que a documentação de design da IU seja
concluída, portanto, por favor, peça que trabalhem nela até o final. Se estiver
decidido sobre a construção desse recurso, marcaremos uma reunião para dis-
cutir isso novamente com os líderes – talvez possamos construir uma versão
em escala menor ou substituir outro recurso.”
É claro que cada caso é um caso, mas esse formato apresenta uma boa
maneira de mantermos a conversa focada na resolução do conflito. Se a pes-
soa tiver uma reação emotiva durante a reunião, diga que você não pode con-
tinuar a discussão e marcará outra hora para conversar com ela.
Dando más notícias

Pode chegar um momento durante o desenvolvimento do jogo em que notícias
ruins tenham de ser dadas para a equipe. Coisas como o cancelamento do pro-
jeto, demissões e pessoas essenciais deixando a empresa podem se encaixar
nessa categoria. Embora possa parecer assustador ser o único responsável por
dizer às pessoas que o projeto foi cancelado, que o prazo de entrega foi encur-
tado ou que alguém foi demitido, não será tão ruim se você o fizer com hones-
tidade e respeito. Acima de tudo, seja honesto sobre o porquê de algo estar
acontecendo. Você não precisa entrar em detalhes, mas exponha o contexto da
decisão e responda qualquer pergunta com o máximo de honestidade possível.
Tenha cuidado também com a maneira de dar a notícia. Ainda que algo
ruim possa estar ocorrendo – como demissões –, não exagere nos aspectos ne-
gativos. As pessoas já estarão se sentindo suficientemente mal por seus ami-
gos que podem estar saindo. Em vez disso, discuta o porquê das demissões,
que medidas foram tomadas para minimizar o impacto e o que está sendo
feito para ajudar os funcionários que terão de procurar novos empregos.
Para concluir, dê as más notícias na hora certa. As pessoas sentem natu-
ralmente quando as coisas não estão indo muito bem e começarão a tirar suas
próprias conclusões sobre o que está acontecendo. Em casos assim, às vezes os
boatos são muito piores do que a realidade, e quando você tiver resolvido o pro-
blema, a motivação pode estar baixa. Se você encontrar grupos de pessoas sus-
surrando no corredor ou junto à máquina de café, provavelmente há pressenti-
mentos na equipe de que algo ruim está ocorrendo no estúdio. Como produtor, é
sua responsabilidade resolver essas preocupações rapidamente verificando qual
é o problema. Se não houver nenhum problema, e boatos começarem a circular
sobre alguma coisa, marque uma reunião com a equipe e pergunte quais são suas
preocupações. Discuta os problemas e verifique se todos ficaram satisfeitos com
os resultados da discussão fazendo um acompanhamento posterior.
DANDO MÁS NOTÍCIAS

Activision
Se você tiver o hábito de falar diretamente e ser honesto com a equipe, dar más notícias
pode não ser tão assustador quanto parece. Embora ninguém goste de ouvir más notícias,
como o projeto estar atrasado, os membros vão querer que o produtor esteja lá para
divulgá-las e responder a qualquer pergunta nos bons e maus momentos. Manter a equi-
pe sempre informada, comunicando todos os tipos de notícias sobre o projeto, pode ser
difícil, mas essa comunicação é uma parte necessária do cargo e deve ser feita de maneira
honesta e direta.
Dando um feedback eficaz

A maioria das empresas faz avaliações de desempenho anuais para que os
funcionários saibam em que áreas se destacaram e que áreas podem melhorar.
Essas avaliações de desempenho são uma ótima ferramenta de aprendizado
para os funcionários, principalmente se eles estiverem atrás de uma promo-
ção ou quiserem melhorar suas habilidades. Dar feedback aos funcionários
em outras épocas do ano também é importante (mesmo quando não se trata de
uma avaliação formal), porque não é muito justo avaliar o funcionário apenas
uma vez por ano. Se eles receberem um feedback regular, você terá funcioná-
rios mais fortes e habilitados. O feedback regular também é crucial quando
o funcionário está tendo problemas com seus hábitos no trabalho ou com a
qualidade.
Para avaliar de maneira justa cada funcionário, o produtor e o líder apro-
priado devem se envolver no processo de feedback, assim como qualquer
outra pessoa a qual ele se reportar diretamente. Dessa forma, o funcionário
obterá uma avaliação completa das contribuições que deu ao projeto e um
feedback mais construtivo. A maioria dos funcionários espera receber feed-
back porque quer saber se está fazendo um bom trabalho ou se tem de melho-
rar em áreas deficientes.
Aqui estão algumas diretrizes gerais para o fornecimento de um feed-
back eficaz:
• Baseie o feedback em observações pessoais e não no que as pessoas dis-

serem sobre alguém. Se os membros da equipe lhe derem feedback sobre
outro membro, você deve considerá-lo ao fazer suas próprias observa-
ções, mas não repita simplesmente o feedback como o ouviu.
• Dê feedback com frequência e na hora certa. Se perceber que um fun-
cionário está tendo um mau desempenho, não espere a avaliação anual;
converse com ele assim que possível. Da mesma forma, ver uma tarefa
bem feita e dar um feedback positivo imediatamente fortalecerá sua rela-
ção com o funcionário.
• Seja específico com o feedback. Não diga apenas que o funcionário pre-
cisa melhorar seus hábitos no trabalho; cite exemplos específicos de seus
maus hábitos e dê sugestões sobre como melhorá-los.
• Concentre o feedback nos comportamentos e não nos indivíduos. Por
exemplo, em vez de dizer a uma pessoa que é difícil se aproximar dela
com comentários, diga que, pelo fato de ela interromper e cortar constan-
temente as pessoas, isso torna difícil conversarem com ela.
• Seja construtivo e não destrutivo. Você não quer que o funcionário se

sinta mal com o que fez no passado; quer que ele saiba em que deve tra-
balhar visando ao futuro.
• Sempre que possível, compense um feedback negativo com um positivo.
Esse equilíbrio fará com que o funcionário saiba que você não está “ten-
tando prejudicá-lo”, e sim que vê seus pontos fortes e as áreas em que
deve melhorar. É uma abordagem que dará credibilidade ao seu feed-
back. No entanto, cuidado para não usar esse método em excesso, por-
que o funcionário ficará condicionado a esperar um feedback negativo
sempre que você começar uma conversa com um feedback positivo.
Lembre-se de que até mesmo um feedback negativo pode ser dado de ma-
neira construtiva. Você não quer que a pessoa saia da reunião se sentindo perse-
guida. Mas ela deve sair com um conhecimento claro do que precisa melhorar.
A comunicação é uma parte importante de qualquer esforço em equipe e a boa

comunicação ajuda a construir uma equipe mais forte. Já que existem várias
formas de comunicação – escrita, verbal e não verbal –, é importante saber
usar cada uma delas de maneira eficaz. Este capítulo apresentou uma visão
geral de como fazer isso, junto com alguns métodos práticos de melhoria da
comunicação. Ele termina com algumas diretrizes para a manipulação de de-
safios específicos da comunicação.
O próximo capítulo começará a seção sobre produção técnica. Nesta se-
ção, serão apresentadas informações sobre como programar subprojetos den-
tro da produção, como tomadas de voiceover, tomadas de captura de movi-
mento e criação de recursos de marketing. Esses elementos têm um impacto
direto sobre o processo de produção como um todo e devem ser adicionados
ao cronograma de produção.
Parte IV
PRODUÇÃO TÉCNICA
A produção técnica envolve os elementos do jogo que costumam ser gerencia-

dos como subprojetos dentro do ciclo de produção. Esses elementos incluem
a voz, a música e a captura de movimentos. Os jogos on-line multijogador em massa
(massively multiplayer online games) também serão discutidos, já que eles apresen-
tam algumas questões próprias que devem ser planejadas durante o desenvolvimen-
to.
O voiceover e a música dão uma grande contribuição para a percepção do som
no jogo. Um bom desempenho no voiceover pode fazer um bom jogo ser ótimo.
Por outro lado, uma performance ruim pode torná-lo menos interessante. O mesmo
pode ser dito para a música e a captura de movimentos. Em grandes projetos de de-
senvolvimento, esses são alguns dos elementos que costumam ser terceirizados, e os
produtores devem saber como programá-los dentro da fase de produção.
O marketing também é uma parte importante da produção, porque os recursos
de marketing afetam diretamente o processo. Quando os profissionais de marketing
estão planejando o lançamento de um título, eles precisam da arte de marketing, de
entrevistas com desenvolvedores e de builds jogáveis com bastante antecedência. Se
o produtor não conseguir fornecer os recursos de marketing, as vendas do jogo serão
afetadas negativamente.
Esta seção do livro discutirá esses subprojetos do ciclo de desenvolvimento de
um jogo e fornecerá vários detalhes sobre a manipulação eficaz dessas necessidades
exclusivas. Os tópicos são os seguintes:
• Jogos on-line multijogador em massa

• Planejando o voiceover
• Contratando e licenciando música
• Preparando uma tomada de captura de movimentos
• Trabalhando com o departamento de marketing
9
JOGOS ON-LINE
MULTIJOGADOR EM MASSA
Neste capítulo
• Diferenças entre os • Pré-produção • Pós-produção
MMOs e outros jogos • Produção
9.1 Introdução
Um jogo on-line multijogador em massa (Massively Multiplayer Online –

MMO) é aquele que hospeda centenas de milhares de jogadores ativos. Os
jogadores podem interagir uns com os outros em um mundo persistente em
tempo real, ou seja, eventos do universo do jogo continuam a ocorrer até mes-
mo quando o jogador não está conectado e jogando ativamente. Os jogos são
construídos em arquitetura cliente-servidor e estão constantemente em uso
porque os jogadores desfrutam deles 24 horas por dia, sete dias por semana.
Os MMOs apresentam alguns desafios peculiares de produção, principalmen-
te durante a fase de pós-produção em que o jogo entra no ar e pessoas reais
começam a interagir com seu universo.
Embora os detalhes dos desafios da produção não façam parte do escopo
deste livro, é importante realçar alguns para que eles possam ser planejados
no ciclo de desenvolvimento do jogo. Todd Keister, produtor que trabalha
na ZeniMax Online, ajudou na elaboração deste capítulo. Ele tem extensa
experiência na produção de MMOs e concordou em compartilhar seu conhe-
cimento sobre o assunto.
142 Parte IV • Produção Técnica
9.2 Diferenças entre os MMOs e outros jogos
Há várias diferenças essenciais entre um MMO e um jogo tradicional de con-

sole ou PC. Embora um jogo de console ou PC possa incluir recursos on-line,
geralmente eles limitam o número de jogadores que podem estar on-line e o
mundo do jogo não é persistente. A marca registrada do MMO são os dados de
personagens persistentes em um mundo persistente. Isso, junto à progressão
do personagem do jogador a longo prazo e à quantidade de conteúdo neces-
sária para preencher o vasto mundo do jogo, requer um sólido gerenciamento
do cliente, do servidor e dos dados – muito mais do que em jogos tradicionais
de PC ou console com um componente on-line.
Muitos MMOs não têm um lançamento físico tradicional. A Web mani-
pula um percentual cada vez maior da distribuição, concorrendo com os cos-
tumeiros varejistas e suas lojas físicas. Muitos jogadores ainda compram a cai-
xa com o jogo em sua cadeia de lojas de eletrônicos ou loja de jogos favorita,
mas um número cada vez maior está pagando para fazer o download do jogo
inteiro em seus computadores sem sair de casa. Várias empresas criadoras ou
grupos de publicação de jogos fornecem portais para facilitar a comunicação
com seus jogadores ao mesmo tempo em que demonstram novos jogos e pro-
dutos para o público pelo portal.
A maioria dos MMOs emprega algum tipo de modelo de assinatura para
gerar renda. Alguns modelos exigem que os jogadores paguem uma taxa men-
sal, enquanto outros são baseados em uma abordagem de jogo gratuito em
que só é cobrado o acesso a conteúdo e recursos extras. O modelo simples de
assinatura mensal evoluiu para modelos de objetos digitais, modelos de con-
teúdo episódico etc., e os hábitos dos consumidores mudaram para acompa-
nhar essas alterações. O iTunes demonstra com que rapidez as pessoas pagam
por um objeto digital ($0,99 por uma canção) e o NetFlix ilustra o mesmo no
caso de um consumidor pagando por um serviço que lhe deixe modificar a
fila de downloads (por exemplo, trocar a ordem de três vídeos, escolhendo
qual ficará na frente do atual na sequência de download). Um número cada
vez maior de jogos está alavancando essas tendências emergentes com grande
sucesso financeiro. Novos conteúdos também são lançados regularmente para
que haja novidades no jogo e as pessoas continuem a jogá-lo. Às vezes, o novo
conteúdo são algumas armas ou itens novos, enquanto, em outros casos, pode
ser uma expansão totalmente diferente em que novos níveis, personagens,
missões e recursos sejam adicionados ao jogo.
No início do ciclo de vida de um jogo, com frequência patches são ba-
seados em necessidades de eliminação de bugs críticos ou falhas no sistema
que se tornaram evidentes com o aumento de jogadores entrando no mundo
do jogo. Uma manutenção regular envolvendo correções de bugs e mudanças
no equilíbrio da jogabilidade ocorre em intervalos constantes – aproximada-
mente uma vez por semana. Você também pode ter atualizações de conteúdo
gratuitas que costumam ser patches maiores que surgem com muito menos
frequência. Devido ao grande número de pessoas que o jogo suporta, é impor-
tante resolver qualquer problema crítico assim que possível para que ele não
9 • Jogos On-line Multijogador em Massa 143
piore à medida que mais pessoas o encontrarem. Por exemplo, pode haver
uma missão que distribua erroneamente uma recompensa de 10.000 peças
de ouro em vez das 10 peças de ouro pretendidas. E, por acaso, essa missão
hipotética ocorre no início da principal série de missões da história que a
maioria dos jogadores alcança quando seu personagem está perto do nível 8.
Rapidamente, a economia que foi meticulosamente ponderada durante meses
por uma equipe de sistemas foi destruída porque todos os jogadores estão
comprando os melhores equipamentos e eliminando a curva de progressão.
Para concluir, a equipe de produção não terá terminado com o jogo quan-
do o entregar. Não haverá tempo para compensar horas no fim do projeto e
recarregar as baterias. Em vez disso, a equipe estará muito ocupada entre 30
e 90 dias após o jogo ser lançado. Terá de monitorar o jogo quando ele entrar
no ar e ficar à disposição para resolver rapidamente qualquer problema que
for descoberto em relação ao equilíbrio da jogabilidade, bugs inesperados, co-
brança e autenticação, e assim por diante. Além disso, uma equipe de suporte
ao cliente deve monitorar constantemente o jogo para verificar se tudo está
funcionando corretamente e se os jogadores não estão tendo nenhum proble-
ma que os impeça de jogar.
9.3 Pré-produção
Como nos outros jogos, a pré-produção é uma fase essencial no desenvolvi-

mento dos MMOs. Os stakeholders do projeto têm de estar de acordo com os
princípios fundamentais que guiam o conceito do jogo como um todo. Um
exemplo é o modelo financeiro – o jogo poderá ser comprado em pequenas
parcelas ou será baseado em um modelo de assinatura? Do ponto de vista do
designer, devem ser tomadas decisões sobre se o jogo enfocará encontros jo-
gador versus jogador (player versus player – PvP) ou jogador versus ambiente
(player versus environment – PvE). Além disso, terão de ser tomadas decisões
tecnológicas quanto ao pipeline, ferramentas, mecanismo do jogo, especifica-
ções artísticas e assim por diante.
Questões de tecnologia
Devido à arquitetura do jogo, a tecnologia necessária para um MMO é muito
diferente da de outros jogos com componentes on-line. Alguns itens gerais
que devem ser considerados são o nível de tecnologia que você terá no lança-
mento, como a definição de até onde a tecnologia do jogo será de ponta. Por
exemplo, qual serão as especificações mínimas de hardware para os usuários
finais, qual o nível de detalhes da renderização gráfica e como as interações
da física serão manipuladas. Lembre-se de que superestimar os aspectos téc-
nicos pode ser prejudicial para a sustentabilidade e o impacto no mercado.
É crucial definir um modelo escalável para a arquitetura cliente-servi-
dor-dados. Em um MMO, o jogo tem de manipular uma grande quantidade de
dados. Isso inclui inúmeros assets de animações, texturas e partículas, assim

como links de dados de mensagens do servidor para a coordenação de dados
posicionais, dados persistentes dando informações sobre quem pode ter quais
habilidades e quantos pontos foram gastos nelas e o inventário geral do perso-
nagem do jogador. Todas essas informações devem ser vinculadas ao cliente
e dar aos jogadores a sensação de que estão tomando parte na experiência
com todas essas ações aparentemente ocorrendo no exato momento em que
eles apertam um botão. Resumindo, todos os dados do jogo, de personagens,
de cobrança, do ambiente e as entradas do jogador são ativados e propagados
com base na camada de mensagens entre cliente e servidor e o sistema de ge-
renciamento de dados (normalmente um banco de dados). O cliente é a janela
do jogador para esse novo mundo e deve ser sutil na geração de elementos
e na manipulação da prioridade das mensagens para que o ambiente pareça
uniforme e imersivo e os controles pareçam dar feedback instantâneo às ações
do jogo.
No lado do servidor, você tem de definir como os dados do jogo serão
passados. Por exemplo, como os dados do jogador estão sendo distribuídos
pela rede? Qual a melhor maneira de enviar uma quantidade mínima de da-
dos ao jogador para manter seu status atualizado corretamente em tempo real?
Pequenos pacotes de dados são essenciais para reduzir a quantidade de ban-
da larga usada e evitar problemas de latência no servidor. Outros itens que
devem ser considerados são os tipos de mensagens que você enviará para o
jogador e a frequência com que as enviará. O buffer de memória não deve ficar
cheio com mensagens que não sejam realmente importantes para o jogador.
Outro problema importante a ser resolvido é como o jogo lidará com a la-
tência do servidor. A latência é basicamente um atraso no tempo que um pacote
de dados leva para ser transmitido do computador do jogador para o servidor
do jogo e para o servidor retornar um pacote de dados para o computador. O
desenvolvedor deve projetar os sistemas do jogo de modo que a menor quan-
tidade possível de informações seja transmitida entre o cliente e o servidor.
Isso assegura que os buffers de mensagens não fiquem excessivamente cheios e
percam pacotes e que outros problemas não influenciem a experiência de jogar.
A latência do servidor afeta o design geral do jogo, portanto, lembre-se desse
problema ao projetar os sistemas de animação e outras áreas em que o jogador
possa notar problemas de latência ao jogar.
é útil definir o modelo de assinatura na pré-produção. tudo é projetado
com base em qual será esse modelo para que os hooks do back-end possam ser
construídos durante a produção. isso inclui decisões sobre como manipular o
rastreamento da conta, o rastreamento do jogador e relatórios do usuário, e tam-
bém que sistemas são necessários para fornecer a habilidade de refinar facil-
mente os valores da jogabilidade. é importante que esses sistemas estejam fun-
cionando antes que alguém possa entrar no jogo, para que você consiga resolver
os problemas mais cedo, em vez de esperar que se transformem em problemas
maiores. sem esforços repetidos para testar os sistemas de jogabilidade e otimi-
zar como o jogo coleta, processa e apresenta dados para as outras equipes (que
reagirão a eles), você pode facilmente criar uma situação que estará mal equipa-
do para resolver a tempo. o uso de bots para testar esses sistemas pode fornecer
uma grande quantidade de dados úteis para a resolução de qualquer problema

que jogadores humanos poderiam encontrar.
Embora haja algumas opções de middleware para MMOs, há limitações
em seu uso. Cada produto tem vantagens e desvantagens, portanto, é im-
portante avaliar essas opções cuidadosamente durante a pré-produção. Al-
gumas soluções de middleware fornecem ótimas ferramentas de criação de
conteúdo, mas podem não ter aspectos da camada de rede. Outras podem
fornecer um ótimo renderizador com excelente potencial visual, mas ter defi-
ciências em outras áreas. Atualmente não há uma solução tecnológica única
e padronizada para criação de MMOs que satisfaça plenamente os requisitos
de um projeto.
Questões de design
Jogos como World of Warcraft e Everquest 2 formalizaram os recursos padrão
esperados em qualquer MMO de alta qualidade (AAA). Se esses recursos não
fizerem parte do jogo, isso afetará diretamente a sustentabilidade do produto.
Esse conjunto de recursos esperados se expande quando um novo MMO chega
ao mercado e adiciona mais recursos ou maior polimento aos recursos existen-
tes. Por exemplo, as ferramentas que permitem que os jogadores procurem seus
grupos ou planejam ataques evoluíram bastante em um espaço de tempo relati-
vamente curto. A função básica é muito densa e inclui recursos como funciona-
lidade e versatilidade de bate-papo, lista de amigos, busca de amigos, suporte a
associações, sistema de missões, sistemas de correio e casa de leilão e sistemas
rápidos de viagens. O objetivo principal é o jogador se conectar novamente ao
jogo, portanto, você também terá de incluir alguns recursos que mantenham o
jogo à parte, além dos recursos básicos que o jogador espera. Conserve baixas as
barreiras à entrada, e isso inclui o suporte a máquinas low-end, ou você se ar-
riscará a perder demografia técnica. Alguns jogos que tentam ser “high-end”, no
que diz respeito à tecnologia, podem não alcançar a massa crítica de jogadores
necessária à perpetuação do título por vários anos. Simplesmente, se seu jogo
não puder ser executado em sistemas com especificações mínimas, você perderá
uma grande parcela do mercado e, assim, limitará o possível sucesso do jogo.
Ao definir o conceito básico da jogabilidade, crie um modelo sólido de
desenvolvimento de personagens no início do processo e construa a jogabili-
dade baseando-se em como os personagens interagirão e operarão em grupos.
Trata-se, basicamente, de um guia geral das habilidades de uma classe; como
a classe avança com o tempo, seu balanceamento em comparação às outras
classes, o papel exclusivo da classe (se aplicável) e o conceito do papel no
fim do jogo. É uma boa ideia incluir também maneiras de outros jogadores
conhecerem as vantagens e desvantagens de cada classe para saberem facil-
mente quais classes devem incluir em grupos e grandes ataques coletivos.
Por exemplo, alguém usando um personagem lenhador tem de poder saber
facilmente que tipo de personagens e classes seria útil adicionar a um grupo
para cumprir uma missão específica. O jogador tem de saber o benefício de
adicionar outro tipo de personagem a seu grupo, assim como o que fazer ao
enfrentar um tipo de personagem específico. A construção desses recursos
antecipadamente e a ênfase na jogabilidade e no equilíbrio básicos fornecerão

uma base sólida para o jogo e então os sistemas e funcionalidades poderão ser
construídos de acordo com essa base para ampliar a experiência do jogo.
Pense em como o personagem do jogador evoluirá e progredirá no jogo.
Esse é um dos principais fatores que manterão as pessoas se conectando no-
vamente ao jogo. Os jogadores ficarão muito apegados aos seus personagens e
passarão várias horas personalizando-o, e ainda outras mais desenvolvendo o
personagem no decorrer do jogo. Tradicionalmente, os jogos só nos permitiam
projetar a aparência do personagem durante a fase inicial de sua criação no
começo do jogo. Atualmente, um número maior de jogos fornece ao jogador
maneiras criativas de personalizar ainda mais o personagem posteriormente
no jogo. Você terá de criar guias de estilo artístico detalhando não só a apa-
rência das armas, itens e personagens, mas também sua aparência no nível
inferior, intermediário, superior e épico. Isso ajuda a definir uma escala re-
lativa se as melhores armas forem as maiores, por exemplo – principalmente
se as corridas e avatares do jogo variarem muito em seus tamanhos gerais.
Novamente, já que o direito de se exibir é um fator importante nesses jogos
altamente sociais, você vai querer criar situações para o jogador em que ele
veja alguém passando com um cavalo épico e brilhante cuspindo fogo e pen-
se – “Como consigo isso!!!???!!”. O jogador sabe, pelo contraste visual, que o
objeto (nesse caso, o cavalo) é raro, mas imediatamente surge a vontade de
possuir os itens mais raros e arrojados do jogo.
Decida se o jogo enfocará mais a experiência jogador versus jogador
(PvP) ou jogador versus ambiente (PvE). Um design baseado em PvP pode ter
muito mais tipos de mapas direcionados a modos de jogo PvP, como a captura
de mapas de bandeiras, grandes campos de batalha ou guerras de cerco em
que cidades lutam contra outras cidades.
Um jogo PvE é aquele em que os jogadores interagem com personagens
não jogadores (non-player characters – NPCs) e enfrentam monstros controla-
dos por IA. O jogador pode conversar com o guardião de uma cidade e receber
uma missão – ele então tem a opção de executar a missão sozinho ou formar
um grupo com outros jogadores ativos para executá-la. Os jogos PvE podem
ter paisagens mais abertas e os jogadores mais habilidades que lhes deem uma
vantagem poderosa sobre os inimigos controlados pelo computador, como a
habilidade de constrição por enraizamento, que se mostra frustrante entre
jogadores. (A constrição é um tipo essencial de habilidade que é muito útil no
PvE mas não funciona tão bem no PvP. As raízes são como redes ou blocos de
gelo que congelam o personagem e o impedem de se mover.) Portanto, embora
o jogador ainda esteja interagindo e competindo com jogadores ativos, não
está tentando combatê-los diretamente para atingir seus objetivos. Ao comba-
ter monstros, o jogador pode escolher as habilidades que deseja desenvolver
em seu personagem (invisibilidade, combate, magia) para derrotá-los.
Questões artísticas
Enquanto estiver na pré-produção, você também terá de tomar algumas deci-
sões importantes sobre a arte do jogo. Em jogos tradicionais de PC ou console,
temos mais controle sobre como exibir vários jogadores ao mesmo tempo nos
ambientes. Se você estiver trabalhando em um jogo para um único participan-
te, terá ainda mais controle sobre a interação do jogador com o ambiente. Nes-
se caso, terá condições de dar a certos assets artísticos uma resolução maior,
porque saberá que os limites de renderização do jogo permitirão que alguma
combinação de modelos de personagens e assets ambientais sejam exibidos
ao mesmo tempo. Em um MMO, os problemas de renderização devem ser
considerados, porque você terá de decidir como lidará com vários jogadores
na tela ao mesmo tempo. Por exemplo, como o jogo renderizará 50 jogadores,
efeitos de armas, pequenos animais e condições climáticas, tudo sendo exibi-
do simultaneamente durante uma batalha em escala real? O uso de modelos
de personagens e assets artísticos que contenham uma baixa contagem de po-
lígonos e nível de detalhes (level of detail – LOD) ajuda a renderizar o jogo
mais facilmente. É uma armadilha comum desenvolvedores iniciantes em
MMO criarem personagens e ambientes altamente detalhados que têm ótima
aparência quando há apenas um ou dois jogadores na tela, mas que travam o
jogo quando mais pessoas participam.
Um projeto que se envolve muito cedo com a produção em massa de
assets artísticos, sem medir precisamente e avaliar continuamente as especi-
ficações de renderização, como o número de objetos em exibição, contagens
de polígonos, “draw calls” e etc, com frequência se transforma em uma si-
tuação onde posteriormente os assets devem ser limpos por verificações de
nível de detalhes intensivas e visualmente impactantes. É importante defi-
nir alguns alvos artísticos irregulares no início do processo com a criação de
zonas de protótipos que incluam todas as principais situações que podem
ocorrer em uma área – por exemplo, monstros surgindo, texturas ambientais
e confusão de níveis – para que você possa ter uma ideia das medidas an-
tecipadas que devem ser tomadas para melhorar o renderizador ou definir
diretrizes para cenas e zonas.
Também é crucial saber como o ambiente do jogo será disposto. Os
MMOs usam áreas instanciadas para lidar com o excesso de pessoas. Elas
são mapas ou zonas, como uma masmorra, que surgem em um servidor es-
pecificamente para um jogador ou um grupo exclusivo de jogadores. Decida
o que será instanciado, o que não será e tenha uma ideia geral de quantos
assets podem ser instanciados em um espaço. Acima de tudo, você deve
persistir nas áreas de teste até ter uma boa ideia da resolução das texturas,
do número de objetos em exibição, da provisão de partículas e assim por
diante, lembrando-se sempre de que 50 jogadores na cena afetarão suas pro-
visões. Além disso, defina que áreas do jogo serão cidades, espaços abertos
(sem prédios) e espaços da comunidade (prefeituras, bancos e outros locais
em que grandes grupos de jogadores possam se concentrar). Outro desafio
é o conteúdo ser vasto, ou melhor, extremamente profundo. O jogo incluirá
objetos, animais, itens diversos, variações de terreno, sistemas climáticos e
diferentes tipos de arquitetura. Além desses assets que são usados na cons-
trução de um nível, o jogo também incluirá NPCs, sistemas de partículas,
sistemas de habilidades, sistemas de construção, efeitos especiais de com-
bates, animações etc.
Equipe de produção
Você encontrará muitos dos mesmos desafios que encontramos na construção
de outros tipos de equipes quando construir uma equipe de desenvolvimento
de MMOs, mas há algumas coisas que devem ser consideradas na formação de
uma equipe. Como em qualquer jogo, é muito importante preencher as vagas
principais no início do projeto com pessoas fortes que consigam trabalhar jun-
tas em direção à visão unificada do jogo. No caso dos MMOs, a tecnologia é um
dos maiores desafios, portanto, você precisará de líderes fortes nas áreas clien-
te e servidor e de um diretor técnico, todos preferivelmente com experiência
anterior em MMOs. Um bom programador gráfico é um recurso importante e
raro que seria de grande ajuda na avaliação de mecanismos de renderização e
poderia auxiliar o líder da área do cliente a definir as necessidades iniciais de
tecnologia. É claro que você também precisa de um bom Diretor de Arte com
muita experiência em pipelines para ajudar na definição das especificações
artísticas iniciais e na preparação de ferramentas. Quanto mais experientes em
MMOs forem esses líderes, melhor. Há certos obstáculos que sempre surgem
em projetos de MMOs e essa experiência ajudará a equipe a superá-los.
Na avaliação de soluções de middleware, a capacidade e a experiência
de seus líderes de programação e arte farão toda a diferença na personaliza-
ção do que virá com o SDK e o reforço nas áreas do pipeline e de tecnologia
que não serão abordadas por ele. Não é aconselhável iniciar usando proces-
sos incompletos no pipeline, porque é provável que essas áreas nunca sejam
corrigidas quando a produção plena começar, o que é perigoso. Se as coisas
não tiverem sido definidas e estiverem funcionando plenamente quando a
produção começar, haverá desperdício de tempo na manipulação de gargalos
e paliativos que poderiam ter sido manipulados corretamente no início do
processo. Uma equipe grande só adiciona mais pressão a essas áreas proble-
máticas, portanto, é melhor que uma equipe pequena cuide desses problemas
o mais cedo possível.
Já que muitos MMOs têm um ciclo de desenvolvimento médio de qua-
tro a cinco anos, a estrutura da equipe tem de ser bem flexível para suportar
a entrada e saída de pessoas do projeto no decorrer do ciclo. Devido à lenta
evolução, com frequência surgirão situações em que você pode não precisar de
uma determinada pessoa por cerca de seis meses e ela estar disponível muito
mais cedo. Portanto, poderá colocá-la no projeto sem ter muito que fazer ou
arriscar perdê-la para outro projeto ou até mesmo outra empresa. Geralmente,
tendemos a trazer as pessoas quando surge a oportunidade, e isso pode levar à
situação de haver pessoas demais disponíveis no início do projeto. Elas terão
de esperar as ferramentas e o pipeline de produção serem definidos antes de
poderem começar a contribuir para o jogo. O segredo não é simplesmente en-
contrar trabalho para todos, essa parte é fácil. O importante é manter-se fiel à
ordem de execução da preparação inicial da infraestrutura e do pipeline sem
se sentir inclinado a ter uma grande equipe de arte ou design já no início do
projeto trabalhando nos recursos antes dos aspectos básicos serem definidos.
A polinização entre equipes é essencial. A divisão da equipe de desen-
volvimento em grupos específicos, como grupo de conteúdo versus de progra-
mação, pode ser fatal. Você agrupará as equipes de acordo com sua área espe-
cífica, como arte, design e programação, mas não pode deixá-las se isolarem
umas das outras porque isso as separará da equipe como um todo e diminuirá
o espírito de grupo. Devido à longa duração do ciclo, também é comum as
funções de uma pessoa se expandirem no decorrer do projeto. Por exemplo,
um produtor associado pode começar o projeto ajudando a gerenciar o crono-
grama e a lista de tarefas, depois trabalhar no refinamento e monitoração do
pipeline e do sistema de gerenciamento de versões para então acabar como
Live Producer.
No entanto, após o trabalho de pré-produção ser “concluído”, a equipe
avançará muito rapidamente. Quando o pipeline estiver funcionando e a in-
fraestrutura estiver pronta, a equipe terá de avançar com o máximo de veloci-
dade para obter todos os objetos, armas, personagens e demais itens do jogo.
Devido à grande quantidade de conteúdo, o tamanho da equipe pode crescer
rapidamente e o índice de gasto financeiro aumentar muito. Tente prolongar o
máximo possível essa transição para uma equipe grande. Por exemplo, cons-
trua um exemplo de cada tipo de zona, com uma equipe pequena. Isso ajudará
a revelar os problemas básicos a serem resolvidos e iterados com o grupo pe-
queno. Nesse momento, a correção de bugs poderá ser feita mais rapidamente,
o que pode economizar tempo e dinheiro posteriormente no projeto.
9.4 Produção
Embora os MMOS tenham problemas de produção semelhantes aos de outros

jogos, há algumas diferenças nos modos de produção que devem ser conside-
radas quando você construir o plano do jogo. Geralmente, os ciclos tradicio-
nais de desenvolvimento de jogos são direcionados por datas – o jogo deve
ser lançado no Natal ou junto com a estreia de um filme. As datas das versões
alfa, beta e gold master são agendadas e a equipe tenta cumprir esses prazos
para assegurar que o jogo seja entregue no momento necessário. Nos MMOs,
as etapas da produção são direcionadas principalmente por eventos – quando
a infraestrutura estará pronta, quando o pipeline artístico estará pronto, quan-
do a versão alfa estará concluída etc. A equipe se dedica a testar os conceitos-
-chave da jogabilidade até eles ficarem satisfatórios. Isso permite que o jogo
seja construído com base no que funciona.
Depois o foco mudará para a determinação de quantas pessoas um servi-
dor pode suportar e por quanto tempo. A melhor maneira de se fazer isso (an-
tes de você ter acesso a jogadores ativos em uma versão open ou closed beta)
é criando robôs (ou “bots”) que funcionem como jogadores. Os bots podem
ajudar os desenvolvedores a prototipar a provisão de polígonos, o layout das
zonas, o caminho da IA, pontos de geração, mensagens do servidor e assim
por diante. Isso os ajudará a otimizar o jogo reduzindo a quantidade de dados
trocada entre o cliente e o servidor. Um dos desafios do uso de bots é saber-
mos quando seu comportamento pode estar diretamente relacionado ao com-
portamento de um jogador ativo. Se uma comparação um a um direta entre
jogadores e bots for usada, dados errados serão gerados. Por exemplo, os bots
nunca poderão simular totalmente os comportamentos dos jogadores. Deve
ser reservado algum tempo no desenvolvimento para tentarmos estabelecer
a proporção relativa entre bots e jogadores ativos. Em algumas áreas, como
um serviço de combate, cerca de 50 bots podem ser necessários para simular
a carga gerada por um único jogador. Para sobrecarregar um servidor de bate-
-papo, um bot pode ter o mesmo peso de 500 jogadores.
Os termos tradicionais para os principais estágios do desenvolvimento
de MMOs são Amigos e Família, Alfa, Closed Beta e Open Beta. O conceito
geral é permitir que as pessoas que não forem os clientes-alvo anônimos, e
que devem ser as mais pacientes, vejam os recursos logo no início, quando
ainda se espera que o jogo esteja instável e os prazos sejam inconsistentes. A
versão closed beta é quando um grupo seleto de usuários tem permissão para
jogar o jogo inacabado, dar feedback e identificar bugs, tudo sob a proteção
de um acordo de confidencialidade – que impede que informações sobre o
jogo vazem antes do planejado pelo desenvolvedor. Em uma versão closed
beta, o jogo está incompleto – os assets não estão 100% finalizados, proble-
mas conhecidos estão presentes e o balanceamento da jogabilidade não está
concluído. A versão closed beta é importante porque é a primeira oportuni-
dade que os desenvolvedores terão de testar a sobrecarga dos servidores com
pessoas e ver com que destreza o jogo manipula uma grande quantidade de
jogadores ativos. Ela revelará qualquer problema possível não limitado à ren-
derização, latência ou equilíbrio do jogo. Pode mostrar problemas específicos
na estrutura de classes ou economia do jogo. E podem ser revelados bugs que
não foram vistos anteriormente. Se a versão closed beta receber um feedback
positivo dos usuários, essa também será uma boa maneira de gerar alguma
expectativa inicial sobre o jogo.
A versão open beta é quando o jogo está completo com seus recursos
e assets, mas ainda há bugs e possíveis problemas de equilíbrio da jogabili-
dade. Geralmente, o desenvolvedor está a um mês ou mais do lançamento e
deseja coletar imensas quantidades de dados de grandes cargas de jogadores,
para execuções cada vez mais longas nos servidores ativos antes da repentina
carga do dia do lançamento. No passado, um jogo podia conter uma versão
closed beta e era perfeitamente aceitável que apresentasse bugs, assets ausen-
tes e até mesmo uma jogabilidade desajeitada. Todos os participantes do teste
ficavam empolgados e geralmente isso gerava comentários positivos. Agora
que o mercado de MMOs está ficando mais competitivo e há muito mais
empresas desenvolvendo-os, existe muita disputa por testadores beta. O jogo
acaba sendo julgado com eficácia um estágio antes – quando está na closed
beta. Ou seja, o público-alvo pode tomar decisões finais de compra com base
nas reações dos jogadores ao jogo antes da open beta – o estágio tradicio-
nal em que o desenvolvedor sente que o jogo está pronto para lançamento.
Portanto, a tendência é chegarmos a uma versão closed beta mais polida e
termos o jogo basicamente pronto para lançamento quando a versão for open
beta. Isso deixa a equipe sob pressão no fim de um longo ciclo.
Outro evento-chave que precisa ser planejado na produção é o lança-
mento do jogo. Já que os MMOs dão suporte a milhares de jogadores ativos
em tempo real, 24 horas por dia, sete dias por semana, um sólido plano de
lançamento deve ser elaborado cerca de três a seis meses antes do jogo ser
lançado. Esse plano inclui informações sobre a frequência de lançamento de
patches, quando novo conteúdo será adicionado ao jogo e planos gerais para
o lançamento de pacotes de expansão. A equipe que cuidará dos problemas
que ocorrerem após o lançamento (geralmente chamada de equipe live) tem
de estar formada e pronta para qualquer coisa. Geralmente, a equipe live
inclui um Líder de QA, um Representante da Comunidade, um Diretor de
Operações, um Líder de Operações do Jogo, um Líder de Suporte ao Cliente
e os líderes da equipe de desenvolvimento. Eles trabalharão juntos antes,
durante e após o lançamento para eliminar preocupações dos jogadores,
problemas de equilíbrio da jogabilidade e qualquer bug crítico que afetar a
experiência de jogar.
9.5 Pós-produção
No dia do lançamento, todos estão no escritório. Ainda há uma equipe de

QA completa e todos estão prontos pra trabalhar longas horas. Uma vez que
o jogo é lançado, a equipe começa imediatamente a monitorar o desempe-
nho do hardware, a economia, as classes que estão sendo mais afetadas,
fontes de comunidades como os fóruns e o que mais ocorrer no jogo. Ajus-
tes são feitos dinamicamente em qualquer área para preservar a experiência
para os jogadores ativos. Programadores eliminam bugs quando eles sur-
gem. O loop do feedback é extremamente importante para que uma decisão
rápida seja tomada sobre problemas de alta prioridade que precisam ser
resolvidos imediatamente. A prioridade é drasticamente afetada pela fre-
quência com que um erro pode ocorrer. Por exemplo, se 20 jogadores entre
30 perderem 10 peças de ouro ao comprar algo, esse é um bug de prioridade
mais alta do que um bug que exclua um item do inventário e ocorra uma a
cada dois milhares de vezes em que um jogador pressione uma sequência
muito rara de teclas.
A produção de um MMO apresenta muitos dos mesmos desafios da produção

de outros jogos, e várias técnicas discutidas neste livro podem ser aplicadas
ao desenvolvimento de MMOs. No entanto, há alguns problemas próprios
que têm de ser considerados em cada fase do desenvolvimento, para assegu-
rarmos um jogo tecnicamente consistente e bem projetado que possa ser apre-
ciado por milhares de jogadores ao mesmo tempo. Este capítulo destacou vá-
rios problemas que devem ser considerados durante as fases de pré-produção,
produção e pós-produção.
10
VOICEOVER
Neste capítulo
• Planejando o voiceover • Escalando atores • Lista de verificação do
• Selecionando um • Gravando o voiceover voiceover
estúdio de gravação
10.1 Introdução
Nos jogos digitais de hoje, voiceover de qualidade já é algo esperado pelos jo-
gadores. Eles querem ser imersos no universo do jogo, e isso significa que os
personagens devem ser convincentes e falar de uma maneira que combine com
o mundo do jogo. Um bom trabalho de voiceover aumenta o apelo do jogo e
torna um bom jogo ainda melhor. Inversamente, um fraco trabalho de voiceover
prejudica a experiência do jogo e faz um bom jogo parecer abaixo da média.
Esse desejo de imergir totalmente o jogador no mundo do jogo também
torna o trabalho de voiceover mais complexo e, portanto, mais difícil de ge-
renciar. Há mais personagens, mais linhas de diálogo e mais diversificação
no uso de diálogos dentro do jogo. Por exemplo, Tom Clancy’s Ghost Recon
tinha cerca de 600 linhas de diálogo e aproximadamente cinco vozes diferen-
tes, mas quatro anos depois Tom Clancy’s Ghost Recon 2 tinha mais de 2.500
linhas de diálogo e mais de 15 vozes diferentes. Atualmente, jogos como Mass
Effect e Grand Theft Auto IV têm voiceovers ainda mais complexos e difíceis
de gerenciar – centenas de personagens (alguns com vozes de celebridades),
dezenas de milhares de linhas de diálogo e sistemas de voiceover dinâmicos
para que o jogador não ouça sempre as mesmas pistas de voz.
Se seu jogo tiver milhares de linhas de diálogo com vários personagens,
o trabalho deve começar com meses de antecedência para a criação do roteiro,
a reserva de um estúdio de gravação, o teste com atores e a gravação e o pro-

cessamento dos arquivos de voiceover. Como nos outros aspectos do desen-
volvimento de jogos, se essas tarefas forem planejadas cuidadosamente, você
será mais bem-sucedido durante o processo de voiceover.
10.2 Planejando o voiceover
É preciso que ocorra um planejamento inicial do voiceover do jogo na fase

de pré-produção. Nessa fase, os objetivos de design do voiceover poderão ser
definidos e qualquer consideração técnica para eles serem atingidos deve ser
examinada. Se o voiceover for considerado posteriormente no processo de
desenvolvimento, será mais difícil, demorado e custoso implementá-lo.
Uma coisa que você deve lembrar ao planejar o voiceover é que é melhor
esperar o máximo possível antes de gravar o voiceover final. O diálogo do voi-
ceover mudará durante o desenvolvimento. Por exemplo, durante o teste do
jogo, o designer pode decidir que a inclusão de uma linha de diálogo é neces-
sária para tornar o objetivo da missão mais claro. Essa inclusão pode ser mais
fácil e barata se o diálogo final não tiver sido gravado. No entanto, se o plano
básico tiver sido descrito antecipadamente, mas não implementado, isso dará
à equipe a flexibilidade de procurar oportunidades de melhorar o roteiro com
essas revisões de maneira mais eficiente. Logo, mesmo não precisando gravar
o voiceover final até bem depois da versão alfa, você deve ter o plano básico
descrito para acomodar qualquer mudança ou inclusão de última hora.
Design do voiceover
O voiceover é uma das principais maneiras de darmos vida aos personagens
e à história do jogo para o jogador. Por exemplo, um bom ator de voiceover
conseguirá transmitir se um personagem é humano ou alienígena e ansioso ou
despreocupado. O voiceover transmite informações sobre o estado mental ou
a situação de um personagem para o jogador. O personagem está com medo,
triste, em perigo ou confiante? O voiceover está vindo de uma transmissão
televisiva ou de outra sala?
Além disso, o design do voiceover é o principal fator que determina
quanto custará a obtenção dos efeitos de voiceover desejados. O design de-
talha como o voiceover será usado no jogo, quantas linhas de diálogo são
necessárias, quantos personagens terão partes faladas e que diálogo terá pro-
cessamento e efeitos adicionais. Geralmente o designer do jogo e o designer
do som trabalham juntos no design do voiceover para assegurar que ele seja
considerado em detalhes e funcione para o jogo.
Por exemplo, se estiverem trabalhando em um jogo massively multi-
player on-line, os designers podem decidir que todos os personagens não
jogadores devem ter várias centenas de respostas faladas para diferentes si-
tuações. Se houver 100 personagens no jogo, o diálogo terá mais de 10 mil
10 • Voiceover 155
linhas, o que criará uma enorme quantidade de assets sonoros a serem gra-
vados e rastreados. Após examinar o design inicial e perceber que não há
tempo ou dinheiro suficiente para gravar essa quantidade de diálogos, os
designers podem acabar reconsiderando e revisando o design do voiceover
adequadamente.
O design do voiceover será diferente para cada jogo, com o gênero do
jogo tendo grande influência sobre algumas das diferenças. Por exemplo, ge-
ralmente jogos de RPG e de aventuras têm uma grande quantidade de perso-
nagens e conversas ocorrendo entre eles e, portanto, tendem a ter um diálogo
extenso. Jogos que não são direcionados por uma história, como os jogos de
corrida e alguns jogos de ação, costumam ter menos partes faladas e usam o
diálogo para direcionar o jogador pelo espaço da experiência do jogo ou para
criar atmosfera.
Considerações técnicas
Além de decisões criativas sobre o voiceover, decisões técnicas também de-
vem ser tomadas. Fatores técnicos, como os formatos de arquivo, diferirão
com base no mecanismo de jogo que estiver sendo usado, mas há algumas
considerações técnicas gerais que devemos lembrar ao planejar o voiceover
do jogo.
Evite a concatenação
A concatenação é um método em que linhas de diálogo separadas são unidas
no mecanismo do jogo e reproduzidas. Por exemplo, a frase “Olá, meu nome
é [Nome do Personagem]” seria criada in-game pela união da linha gravada
“Olá, meu nome é” e outra linha gravada com o nome do personagem. Os
programadores podem querer usar a concatenação para reduzir a quantidade
de memória de busca do asset sonoro apropriado e diminuir a quantidade
de assets do jogo a serem rastreados. No entanto, a concatenação é um pro-
blema para as localizações, já que idiomas diferentes têm regras gramaticais
diferentes. Além disso, um diálogo concatenado é difícil de gravar, porque
é complicado ajustar as inflexões e a altura da voz de cada linha de diálogo.
Quando a linha completa for reproduzida in-game, o jogador pode notar que
dois arquivos foram reunidos, em vez de ouvir um arquivo contínuo.
Gerenciando assets
Quer o jogo envolva 100 ou 10.000 arquivos de áudio, devemos dar atenção a
como esses assets serão rastreados e gerenciados durante o processo de desen-
volvimento. Quanto mais arquivos de áudio houver, mais importante será um
sistema de gerenciamento de assets de áudio. No mínimo, estabeleça um local
exclusivo no banco de dados de controle de códigos-fonte para armazenar os
arquivos-fonte dos assets de áudio, o roteiro do voiceover e as descrições dos
personagens. Dessa forma, as alterações feitas nos assets, no roteiro ou em
notas dos personagens serão controladas e isso assegurará que todos estejam
trabalhando a partir da versão mais atual. Se várias versões do roteiro estive-

rem disponíveis, você pode acidentalmente fazer uma gravação proveniente
da versão errada durante a última sessão de gravação. Esse pode ser um erro
caro, já que provavelmente você teria de regravar o diálogo correto em um
momento posterior.
Além disso, um sistema de gerenciamento de assets facilita determinar
se o estúdio de gravação entregou todos os assets necessários. O ideal é que
um dos programadores possa definir um processo automatizado para compa-
rar os nomes de arquivo de assets de áudio com os nomes de arquivo listados
no roteiro de voiceover. Se os arquivos entregues pelo estúdio de gravação
não forem validados e cobrados imediatamente, você pode acabar perdendo
arquivos de áudio importantes. Se a ausência desses arquivos só for notada
posteriormente no projeto, mais custos podem surgir caso você tenha de vol-
tar ao estúdio de gravação para buscá-los.
Se houver várias partes faladas com muitas linhas para cada parte, pode
ser interessante considerar a criação de um banco de dados para rastreamento
de todos os assets de voiceover. Um banco de dados pode ser útil porque você
terá como fazer a classificação de acordo com muitas variáveis diferentes. Por
exemplo, a gravação de 10.000 linhas de diálogo poderia demorar vários me-
ses. Um banco de dados lhe permitiria fazer a classificação pelos personagens
que deseja gravar em uma determinada semana ou pelos diálogos que foram
ou não gravados.
Convenção de nomenclatura de arquivos

Defina a convenção de nomenclatura de arquivos antes de gravar qualquer
voiceover, até mesmo de arquivos de espaço reservado, do jogo. Se uma con-
venção não for estabelecida no começo, muita confusão surgirá caso o desig-
ner do jogo, o designer do som e o estúdio de gravação estiverem usando ma-
neiras diferentes de nomear os arquivos. Será impossível determinar o que foi
gravado e o que não foi. Se os arquivos para voiceover de espaço reservado ti-
verem o mesmo nome dos arquivos finais de voiceover, você poderá simples-
mente trazer os arquivos finais e substituir os arquivos de espaço reservado.
Selecione uma convenção que permita que alguém olhe o nome do ar-
quivo e saiba exatamente quem fez a fala e onde ele está localizado no jogo.
Na Figura 10.1, foi selecionada uma convenção de nomenclatura de arquivos
que indica o número da missão, o nome do personagem e a quantidade crono-
lógica de linhas desse personagem nessa seção do jogo.
Formatos de arquivo
Geralmente os formatos de origem dos arquivos de áudio são algum tipo de
arquivo .wav ou .aiff, que é algo que um estúdio de gravação pode fornecer
facilmente a um desenvolvedor. Quando os arquivos-fonte são entregues, o
programador pode converter os arquivos de áudio para uso no jogo. O progra-
mador de som que estiver criando os arquivos-fonte de áudio tem de conhecer
todas as especificações para poder distribuir arquivos com a profundidade de
bits, a taxa de amostragem, o formato e a plataforma de destino corretos. A

Figura 10.2 lista alguns formatos e especificações de som comuns usados em
jogos.
Nome Diálogo Nome do arquivo

Vilão 13 Estamos na van, chefe. Vamos despistar a 01_vil13_01.wav
NO SITE
polícia na interestadual.
Bullet Point Sam, eles estão fugindo! 01_bp_01.wav
Sam Vou interceptá-los. 01_sam_01.wav
Civil 3 Ajudem-me! 01_c3_01.wav
Sam Vou chamar a ambulância. 01_sam_01.wav
Figura 10.1 Exemplo de convenção de nomenclatura de arquivo.
A profundidade de bits, também conhecida como resolução, indica quan-

tos bits são usados por um arquivo de som em um intervalo de tempo especí-
fico. Um som de melhor qualidade requer uma profundidade de bits mais alta.
Taxa de amostragem é quantas amostras são extraídas a cada segundo
quando o som é convertido para um formato digital. Um som de melhor qua-
lidade ocorre com taxas de amostragem mais altas. A profundidade de bits
e as taxas de amostragem funcionam juntas, com os pares comuns sendo 8
bits/22 kHz (áudio low-end), 16 bits/44 kHz (áudio com qualidade de CD) e
24 bits/96 kHz (áudio com qualidade de DVD).
A reprodução pode ser em mono, estéreo ou de outro tipo. A reprodução
em mono indica que o arquivo de som é reproduzido em um único canal e em
estéreo indica que o arquivo é reproduzido em vários canais.
O formato do arquivo de som está relacionado com a extensão do arqui-
vo. Os formatos WAV ou WMA são comuns para arquivos de som de PCs, e o
formato AIFF é o formato de som comum para Macintosh. A plataforma pode
ser PC, Macintosh ou plataformas de console proprietárias.
Os arquivos-fonte devem ser distribuídos descompactados para fornece-
rem um som de melhor de qualidade, principalmente se forem convertidos
para outro formato ao serem usados no jogo. Arquivos descompactados tam-
bém podem ser úteis em mixagens de sons, experiências com diferentes efei-
tos especiais e para a correção de arquivos de som corrompidos. No entanto,
se os arquivos-fonte tiverem de ser compactados, o esquema de compactação
apropriado deve ser usado.
Profundidade de bits 8 bits 16 bits 24 bits

Taxa de amostragem 22 kHz 44 kHz 96 kHz
Tipo Mono Estéreo Estéreo
Formato WAV AIFF WMA
Plataforma PC Mac PC
Figura 10.2 Especificações de arquivos de som.

Roteiro do voiceover
Um roteiro de voiceover é o documento principal que detalha todo o diálogo a
ser gravado para o jogo. Um roteiro bem organizado e contendo todas as infor-
mações necessárias para os atores, programadores de som e equipe de desen-
volvimento ajuda muito a assegurar que o processo de voiceover ocorra sem
problemas. O roteiro deve ser o local central de todas as informações sobre o
diálogo, inclusive nomes de arquivos, efeitos de áudio, contexto e inflexões.
Se esses elementos estiverem localizados em documentos separados, haverá
mais assets a serem rastreados e alterações feitas no diálogo podem não ser
transportadas para todos os documentos, ou seja, fica mais fácil cometer erros.
Uma planilha é o melhor formato para a organização do roteiro de voiceo-
ver, porque todas as informações podem ser apresentadas e dispostas claramen-
te de uma maneira lógica. Outro benefício da conversão do roteiro de voiceover
para uma planilha é a possibilidade de usarmos filtros para classificar as infor-
mações de diferentes maneiras. Um ator ou o diretor de elenco a classificará por
“nome de personagem”. Um programador de som a classificará por “efeitos”
para ver rapidamente que arquivos usam efeitos. Para esses filtros funcionarem
de maneira apropriada, todas as informações devem ser rotuladas consisten-
temente. A Figura 10.3 é um exemplo de como as informações do voiceover
podem ser organizadas em uma planilha. Observe que todo o diálogo é listado
em ordem cronológica para mostrar como a conversa flui entre os personagens.
A primeira coluna lista o número da linha. É útil saber o número da linha
durante a sessão de gravação para que você possa acessar rapidamente qual-
quer linha com um ator; será particularmente útil se você tiver de regravar uma
linha, ou uma pick-up line. Apenas informe ao ator que números de linhas
terão pick-up recordings. A segunda coluna lista o nome do personagem que
está falando a linha. A terceira lista o diálogo. A quarta coluna lista o nível
ou a área em que esse diálogo será ouvido. A quinta coluna lista o tipo de in-
formação que está sendo transmitida – por exemplo, aqui há uma brincadeira
Linha Direção Nome do

Personagem Português Nível Tipo SfX Contexto
no de voz arquivo
NO SITE 1 Vilão 13 Estamos na van, chefe. 1 Abertura Estática Os vilões estão Séria 01_vil13_01.wav
Vamos despistar a polícia da missão de tentando fugir da
na interestadual. rádio polícia após roubarem
um artefato do museu.
2 Bullet Sam, eles estão fugindo! 1 Objetivo Bullet Point estava Séria, voz alta 01_bp_01.wav
Point monitorando a conversa
no rádio e sabe o que os
vilões estão planejando.
3 Sam Eu os interceptarei. 1 Objetivo Sam recebeu o relatório Séria, calma 01_sam_01.wav
de Bullet Point e
interceptará os vilões
na estrada.
4 Civil 3 Ajudem-me! 1 Personagem Este civil foi atingido Assustada, 01_c3_01.wav
que não é pelos vilões quando gritando
do jogador estavam tentando
escapar.
5 Sam Você ficará bem. Chamei 1 Cinemática Sam para de perseguir Suave 01_sam_02.wav
a ambulância. os vilões e ajuda o civil
ferido.
Figura 10.3 Planilha de voiceover.

entre os personagens, informações direcionando o jogador para um objetivo

específico ou o diálogo da cinemática? É útil anotar essas informações para que
você possa classificar rapidamente o roteiro de voiceover por tipo de diálogo. A
sexta coluna lista qualquer efeito especial que tiver de ser adicionado durante
o pós-processamento, como efeitos de rádio. O programador de som precisará
dessas informações para assegurar que todo o diálogo seja processado com os
efeitos corretos. A sétima coluna fornece contexto para o diálogo. A oitava co-
luna fornece informações sobre a direção vocal da linha. Essas duas colunas
são importantes para o ator. Mesmo se os atores tiverem alguém dirigindo-os
na gravação, essas colunas fornecerão algumas informações básicas sobre o que
é necessário e podem ajudá-los a se preparar. Além disso, quando o roteiro for
enviado para ser traduzido para uma versão internacional, essas informações
serão necessárias para os tradutores e os atores do voiceover localizado. A nona
coluna lista o nome de arquivo correto que será usado pelo jogo.
Se alguma dessas informações estiver ausente ou localizada em outro ar-
quivo, haverá uma maior probabilidade de algo ser esquecido e erros serem
cometidos. O problema mais dispendioso que pode ocorrer é o diálogo neces-
sário não ser gravado inteiramente na tomada do voiceover. É demorado e caro
reservar o tempo de atores de voiceover para cada sessão de gravação, portanto,
se o roteiro de voiceover não detalhar cada linha a ser gravada, algumas partes
do diálogo podem ser perdidas durante a sessão, ou seja, os atores teriam de
ser chamados novamente em uma data posterior para gravar o diálogo perdido.
Um formato tradicional de roteiro cinematográfico também pode ser útil,
principalmente para atores que estiverem gravando o diálogo de cenas de cor-
te, mas esse formato não deve ser o principal do roteiro. Ele também pode ser
usado pelo redator na criação do diálogo in-game e das cenas de corte cine-
máticas, já que se trata de um formato mais familiar e mais legível durante o
processo de redação. Também é um formato útil para a revisão do diálogo,
porque um grupo de pessoas pode facilmente se reunir, distribuir papéis e
ler as linhas em voz alta para testar o ritmo, o conteúdo, buscar erros e assim
por diante. No entanto, qualquer diálogo escrito em um formato de roteiro
tradicional deve ser convertido para a planilha-mestre de voiceover durante
o processo, para que ela permaneça sendo o principal documento de origem
dos diálogos do projeto.
Voiceover de espaço reservado

Se houver tempo no ciclo de desenvolvimento, a gravação de diálogo de espaço
reservado e sua integração ao jogo é uma ótima maneira de ouvir como o diá-
logo soará. Ao ouvir o diálogo de espaço reservado, o designer e o redator sabe-
rão se as informações cruciais estão sendo claramente transmitidas para o joga-
dor. Também poderão ouvir como o diálogo soa, entender o ritmo e descobrir se
algum diálogo adicional deve ser criado antes da gravação final do voiceover.
Muitos membros da equipe de desenvolvimento ficarão felizes em ser
atores de voiceover por algumas horas e o produtor e o redator poderão ganhar
alguma experiência comunicando-se com os atores em relação aos tipos de
desempenho necessários. O diálogo de espaço reservado deve ser criado várias
semanas antes da última sessão de gravação para podermos nos beneficiar ao

máximo e fazer qualquer ajuste no que será necessário na última sessão.
O outro benefício do diálogo de espaço reservado é a resolução de pro-
blemas no pipeline de assets de áudio. Verificações podem ser feitas no uso
de assets e da memória, na convenção de nomenclatura de arquivos, no for-
mato de arquivo dos assets de áudio in-game e em outros itens que afetem
os aspectos técnicos do áudio. Os arquivos de espaço reservado devem ter
o mesmo nome dos arquivos finais de voiceover. Dessa forma, poderão ser
simplesmente substituídos pelos arquivos finais de voiceover quando esses
estiverem prontos. Além disso, o programador e o designer de áudio poderão
aprender a trabalhar juntos para fazer o voiceover funcionar no jogo.
Cronograma e equipe
Um cronograma inicial de voiceover deve ser criado no começo da pré-produ-
ção para que haja tempo para a busca de um estúdio de som e o agendamen-
to da sessão de gravação. Como mencionado anteriormente neste capítulo,
planeje a sessão de gravação para ocorrer o mais tarde possível durante a
produção, já que as necessidades de diálogo mudarão no decorrer do projeto.
Além disso, se o diálogo for gravado cedo demais no desenvolvimento, novas
tomadas podem ser necessárias mais à frente. Essas regravações podem ser
caras, principalmente se o ator original não estiver disponível e todo o diá-
logo tiver de ser regravado com um novo ator para que as regravações tenham
a mesma voz.
Se milhares de linhas de diálogo tiverem de ser gravadas, seria bom você
agendar várias sessões de voiceover para acomodar as necessidades do proje-
to. Isso lhe dará tempo para fazer melhorias em diálogos gravados em sessões
anteriores. Em geral, o padrão são 50 linhas de diálogo gravadas em uma hora.
Normalmente, uma linha de diálogo é considerada como uma frase ou cerca
de oito a dez palavras.
Em algumas situações, a equipe de cinemática pode precisar do diálogo
final gravado mais cedo no desenvolvimento, para ter tempo de fazer a ani-
mação dos personagens de acordo com o diálogo e trabalhar na sincronização
labial. Nesse caso, você deve agendar uma sessão mais cedo só para gravar o
voiceover usado na cinemática. Será preciso trabalhar junto à equipe de ci-
nemática para determinar o melhor momento para as gravações cinemáticas
do voiceover. Se essas gravações forem feitas tarde demais no cronograma, a
equipe de cinemática pode não ter tempo suficiente para terminar seu traba-
lho. O agendamento correto dessa gravação é ainda mais crucial no trabalho
com um fornecedor de cinemática externo, porque haverá menos controle
sobre sua agenda.
A Figura 10.4 é uma visão geral das principais tarefas que devem ser
agendadas para as gravações de voiceover. Os períodos de tempo foram basea-
dos na gravação de 3.000 linhas de diálogo in-game com oito a dez atores. Os
tempos de duração devem ser aumentados se o jogo tiver mais diálogo e atores.
Muitas variáveis podem afetar o cronograma e devem ser levadas em
consideração quando ele for criado. Algumas delas são as seguintes:
Tarefa Recurso Prazo

Diálogo inicial escrito Redator ~ 3-4 meses antes da versão beta
NO SITE
VO de espaço reservado gravado Designer de som ~ 3-4 meses antes da versão beta
Envio de pedidos de orçamento Produtor ~ 3-4 meses antes da versão beta
para estúdios de som
Reserva de tempo para a sessão Produtor assim que você tiver definido um estúdio de som
de gravação de VO
Diálogo escrito atualizado Redator ~ 6-8 semanas antes da gravação do som
VO de espaço reservado adicional gravado Designer de som ~ 6-8 semanas antes da gravação do som
Teste com atores Estúdio de som ~ 4-6 semanas antes da gravação do som (mais
tempo se envolver uma grande quantidade de atores)
Escalação de atores Redator/Produtor/ ~ 4-6 semanas antes da gravação do som (mais
Designer de som tempo se envolver uma grande quantidade de atores)
Diálogo final escrito Redator ~ 2 semanas antes da gravação de som agendada
Diálogo gravado Redator/Produtor/ ~ 3-4 semanas antes da versão beta (mais tempo se
Designer de som houver muitos diálogos a serem gravados)
Diálogo processado e pronto para a Designer de som ~1 semana antes da versão beta
equipe de desenvolvimento
Figura 10.4 Visão geral do cronograma de voiceover.
Quantas linhas de diálogo: Mais diálogo significa mais tempo neces-

sário no cronograma.
Cronograma de produção do projeto: No caso de um projeto de seis me-
ses, o processo de voiceover deve ser acelerado para que tudo seja feito.
Quantidade de voiceover necessária para a cinemática: O voiceover
usado na cinemática pode ter de ser gravado mais cedo para os artistas
terem tempo de animar o diálogo.
Disponibilidade dos atores: Talvez nem todos os atores estejam dis-
poníveis quando você precisar deles; podem já ter sido contratados ou
estar de férias.
Disponibilidade do estúdio de gravação: O estúdio de gravação pode
ter sido reservado com antecedência para outros projetos, portanto, é
melhor tentar reservar o tempo no estúdio alguns meses antes da data
projetada para a gravação.
A inclusão de tempo extra no cronograma ajudará a acomodar alguns
desses itens inesperados.
Já que a organização e a execução de uma tomada de voiceover são demo-
radas, designe uma pessoa como encarregada por essa tarefa. Se não houver
uma grande quantidade de voiceover para ser gravada, a pessoa não ocupará
essa função em tempo integral. No entanto, se houver 10.000 linhas ou mais
para serem gravadas, celebridades estiverem sendo usadas ou várias tomadas
de som tiverem de ser agendadas, o trabalho pode tomar o tempo integral de
uma pessoa coordenando-o no decorrer de alguns meses.
Esse coordenador seria responsável por comunicar-se com o redator, o
designer de som, o estúdio de gravação e qualquer outra pessoa envolvida no
processo de voiceover para assegurar que todas as tarefas e produtos sejam
manipulados a tempo. Geralmente, um produtor associado ou um designer de
som pode cuidar do gerenciamento dessa tarefa. Em alguns casos, no trabalho

com um grande publicador, ele assume a responsabilidade de coordenação
das tarefas. O importante é que uma pessoa assuma essa responsabilidade e
atue como principal ponto de contato.
10.3 Selecionando um estúdio de gravação
Encontrar um estúdio de som com o qual seja fácil trabalhar e que forneça as-
sets de alta qualidade fará o trabalho de voiceover correr mais tranquilamen-
te. Um bom estúdio de som trabalhará junto à equipe de desenvolvimento
para assegurar que as gravações finais estejam corretas para o jogo. Eles for-
necerão uma ajuda inestimável no teste e na escalação de atores, na execução
das sessões de gravação e na distribuição dos assets de áudio dentro do prazo.
Também podem fornecer serviços adicionais sob demanda, como direção do
voiceover, tracking, pagamento dos atores sindicalizados do projeto e proces-
samento de efeitos especiais.
Ao selecionar um estúdio de som, é preciso que você já tenha uma
ideia clara das necessidades do projeto. Se precisar gravar apenas algumas
centenas de linhas de diálogo com o mesmo ator, considere o uso de um
estúdio menor e atores não sindicalizados. Se estiver gravando uma grande
quantidade de diálogos com vários atores e o diálogo for para um título de
alto nível, considere o uso de um estúdio maior que tenha experiência na
execução de tomadas de som.
É uma boa ideia conversar com pessoas que gravaram diálogos para ou-
tros jogos; com frequência elas têm um estúdio de som para recomendar e
você poderá obter um feedback direto sobre as vantagens e desvantagens de
um determinado estúdio. Algumas perguntas que você deve fazer ao pesqui-
sar estúdios de som são as seguintes:
Eles têm experiência na gravação de diálogos de videogames? A ex-
periência com voiceover de videogames os ajudará a entender melhor
quais são as necessidades do voiceover. Não ter experiência específica
em jogos não é um grande problema, contanto que eles tenham experiên-
cia na gravação de voiceover.
São signatários de algum sindicato? Os signatários de sindicatos são auto-
rizados a pagar autores sindicalizados. Se um estúdio não for signatário de
um sindicato, você terá de contratar um serviço de folha de pagamento do
sindicato ou definir sua empresa de jogos ou o publicador como signatário.
Que tipos de equipamento de gravação estão disponíveis? Os equipa-
mentos, como os microfones e a mesa de mixagem, são adequados para
atender às expectativas de qualidade?
Que software é usado na edição? Por exemplo, se o designer de som
do jogo estiver usando ProTools para editar o áudio, vai querer usar um
estúdio que grave com ProTools.
Qual o tamanho do estúdio? Se houver a necessidade de gravar vários

atores ao mesmo tempo, a cabine de gravação do estúdio pode acomodar
isso? Se várias pessoas estiverem presentes na sessão de gravação – reda-
tor, produtor, designer de som –, o estúdio tem tamanho suficiente para
todas elas?
Eles estão preparados para inserções por telefone? Se alguém tiver de
participar da sessão de gravação, mas não puder estar fisicamente no es-
túdio, poderá ser trazido para a sessão por telefone? Esse recurso será
particularmente útil se você estiver trabalhando com um estúdio em ou-
tra cidade.
Qual o tempo de entrega dos produtos de áudio? Com que rapidez
eles conseguem entregar o áudio após a sessão de gravação? Essa estima-
tiva deve ser incluída no cronograma. Esse pode ser um fator decisivo
para você selecionar um estúdio se o projeto estiver com um cronograma
apertado.
Que opções estão disponíveis para a entrega de produtos de áudio? Os
assets de áudio têm de ser gravados em um CD para serem entregues ou
podem ser postados em um servidor de FTP? Os arquivos podem ser
distribuídos em diferentes formatos e com diferentes esquemas de com-
pactação? O estúdio pretende usar software proprietário para converter
os arquivos para o formato de arquivo desejado para o jogo?
Quais são as taxas? Geralmente os estúdios cobram taxas horárias ou
diárias pelo tempo em que os atores ficam gravando no estúdio. Eles
também cobram taxas pelo processamento dos arquivos após a sessão de
gravação. Além disso, são cobradas taxas pelo tempo dos atores e elas
podem diferir para cada ator.
Que custos adicionais são gerados? Exemplos de serviços que geram
custos adicionais são o teste e a escalação de atores, a direção dos atores,
a criação do diálogo, e assim por diante. Custos adicionais também po-
dem ser gerados por discos, refeições, postagem etc.
Com que antecedência deve ser reservado o tempo do estúdio? Um es-
túdio pode ter de ser reservado com vários meses ou apenas uma semana
de antecedência. Também é bom saber quais as chances de reserva de
sessões de aperfeiçoamento na última hora.
Solicitação de orçamentos
Ao enviar solicitações de orçamentos para vários estúdios de som, você pode-
rá comparar preços e serviços, o que lhe permitirá selecionar o melhor estú-
dio para seu projeto. Receber várias propostas também é uma boa maneira de
saber quanto tempo os estúdios precisarão para gravar o voiceover e com que
rapidez eles esclarecem dúvidas.
Os estúdios podem ter um formato preferencial para a entrega de orça-
mento, portanto, verifique antes para saber se eles têm formulários específicos
que você deva usar. Se não tiverem, verifique com eles que informações são
necessárias e crie um formulário que apresente claramente as principais infor-
mações que o estúdio precisará para calcular o orçamento. No mínimo, eles
terão de saber quantas linhas de diálogo serão gravadas, quantos personagens
do jogo terão diálogo e quantos atores serão usados para gravá-lo.
O envio de uma contagem de linhas estimada é muito importante para a
criação da proposta. Essa contagem será a base de grande parte das estimativas
de tempo e custo do estúdio. Na verdade, cada estúdio pode ter um método di-
ferente para a determinação da contagem de linhas, mas geralmente contamos
cada frase (cerca de oito a dez palavras) como uma linha. Não cometa o erro de
basear a contagem em quantas linhas são usadas na planilha de voiceover (con-
sulte a Figura 10.3), já que esse método pode gerar uma contagem imprecisa se
um ator tiver um parágrafo do diálogo listado em uma única célula da planilha.
Um erro no cálculo da contagem de linhas dificultará para os estúdios agenda-
rem o tempo dos atores e determinarem os custos de maneira precisa.
Por exemplo, o tempo dos atores é reservado por um máximo de quatro
horas para uma única sessão de gravação. Se eles excederem esse período de
quatro horas porque a contagem de linhas era muito maior do que o plane-
jado, terão de ser chamados novamente para uma nova sessão de gravação,
o que gerará tempo e custo adicionais. Além disso, talvez eles não possam
comparecer novamente durante o período que você já reservou no estúdio, ou
seja, tanto o ator quanto o estúdio terão de encontrar tempo para o término da
sessão. Esse atraso pode colocar o cronograma do projeto em risco.
Outras informações importantes que devem ser incluídas na proposta
são quantas vozes exclusivas estão sendo gravadas e quantos atores são neces-
sários para gravá-las. De acordo com as regras da Screen Actors Guild (SAG),
um ator da SAG tem permissão para gravar até três vozes exclusivas em uma
única sessão de gravação por uma remuneração fixa. Se fizer vozes adicio-
nais, deve receber compensação extra. Se você gerenciar cuidadosamente as
expectativas para as vozes dos personagens no jogo, poderá escalar um ator
para fazer várias vozes e economizar dinheiro. Por exemplo, se pedir que um
ator de voiceover experiente desempenhe três papéis menores no jogo, só terá
de escalar e pagar um ator.
Se for necessário escalar uma voz mais importante que será ouvida em
todo o jogo, é melhor que o ator selecionado para esse papel faça apenas essa
voz. Dessa forma, ele poderá se dedicar a dar vida ao personagem principal, e
a voz se sobressairá como única no jogo. Além disso, a quantidade de diálogos
de um personagem principal pode demandar várias sessões de gravação, ou
seja, não haveria tempo para o ator gravar vozes adicionais em uma sessão.
Com relação ao custo, também devemos lembrar que os atores são pa-
gos por um mínimo de quatro horas. Portanto, se o ator só for necessário no
estúdio de gravação por uma hora, ele ainda será pago por quatro horas de
trabalho. Já que você terá de pagar pelo tempo do ator de qualquer forma, re-
gistre o máximo de diálogos que puder durante a sessão – alterne leituras de
linhas com linhas genéricas adicionais que possam ser usadas no jogo (como
cumprimentos, gritos e qualquer outra coisa que possa ser útil posteriormente
no desenvolvimento).
Outros itens que devem ser incluídos na solicitação de orçamento são os

seguintes:
Processamento de arquivos: Indique se você deseja que o estúdio de
som processe integralmente todos os arquivos e remova estalos, cliques e
outros artefatos sonoros dos arquivos de áudio finais. Indique também se
precisará de algum processamento de efeitos especiais para os arquivos
(por exemplo, estática de rádio).
Necessidade de atores exclusivos: Se você estiver procurando um ator
que possa imitar um determinado sotaque ou falar um idioma específico,
inclua-o na solicitação de proposta. Embora essa necessidade não afete a
taxa de gravação do estúdio, pode afetar o pagamento do ator.
Sindicalizado ou não sindicalizado: Se o projeto demandar atores sindi-
calizados, as taxas adicionais do sindicato devem ser adicionadas à pro-
posta pelo tempo do ator. Os atores não sindicalizados serão discutidos
posteriormente neste capítulo.
Formatos de entrega de arquivos: Indique em que formato os arqui-
vos devem ser entregues. Por exemplo, você pode especificar arqui-
vos .wav descompactados com 24 bits/96 kHz. Se quiser formatos de
arquivo adicionais, como descompactado de 16 bits/44 kHz, indique
isso também. Não esqueça de detalhar como deseja que esses arquivos
sejam entregues – gravados em um disco ou carregados em um servidor
de FTP, por exemplo.
Cronograma inicial: Informe ao fornecedor com que tipo de cronograma
você deseja trabalhar. Indique quando poderá entregar a contagem de
linhas e o roteiro de voiceover finais e quando precisa receber os arqui-
vos de áudio finais. Esse planejamento ajudará o fornecedor a gerenciar
seu tempo. Ele pode ter de melhorar o tempo de entrega dos produtos de
áudio finais para atender o prazo de áudio do jogo. Se o fornecedor não
tiver tempo ou os recursos para assumir um projeto com certas restrições
de prazo, isso pode ficar evidente durante o processo de proposta.
A Figura 10.5 é um exemplo de orçamento de voiceover que seria enviada
a um fornecedor. Nesse exemplo, o fornecedor de voiceover terá de contratar
os atores que estão desempenhando esses mesmos papéis no filme. Garantir o
uso de celebridades no voiceover adiciona algum tempo extra ao cronograma.
10.4 Escalando atores

A escalação do ator correto para um papel é um dos aspectos mais importantes
do processo de voiceover. Se o ator correto for escalado, ele pode ir além da
simples gravação de linhas de diálogo para adicionar algo mais ao personagem
e dar vida a ele. A escalação de atores apresenta muitos elementos que você
deve considerar para assegurar a contratação da pessoa certa para o papel.
Assets de voiceover
Alguma celebridade será usada? Inclua os Sim, os atores que fazem os personagens principais no filme também
NO SITE nomes das celebridades na coluna “Notas” farão suas vozes no jogo.
da tabela.
Sindicalizados ou não sindicalizados Sindicalizados
(versão em inglês)
Profundidade de bits (ex: 8 bits, 16 bits etc.) 16 bits
Taxa de amostragem (ex: 22 kHz, 44 kHz) 44 kHz
Canais (mono/estéreo/5.1) Dolby 5.1
Formatos de entrega de arquivos Arquivos wave, descompactados
Processamento requerido. Liste qualquer Edições básicas de estalos e cliques, nomes de arquivo de acordo com o
efeito especial necessário. sistema de nomenclatura de arquivos fornecido pelo desenvolvedor.
Masculino/
Personagem Est. no de linhas Idade Notas
Feminino
Bullet Point 5.000 M 25 É preciso contratar o ator que está
desempenhando esse papel no filme.
Melanie Colie 5.000 F 26 É preciso contratar o ator que está
Caribou 3.000 M 24 É preciso contratar o ator que está
Professora 1.000 F 65 A atriz tem de falar chinês e inglês.
Também pode fazer a voz de outros
personagens do jogo.
Sam 1.000 M 21 O ator também pode fazer a voz de
outros personagens do jogo.
Mulher 1 50 F No meio dos quarenta Essa atriz fará a voz de 3 personagens.
Mulher 2 75 F No início dos quarenta A voz é feita pela mesma atriz que faz
a Mulher 1.
Homem 1 50 M No meio dos quarenta Esse ator fará a voz de 3 personagens.
Homem 2 75 M No meio dos trinta A voz é feita pelo mesmo ator que faz
o Homem 1.
kH
Figura 10.5 Exemplo de uma proposta de voiceover.
Sindicalizados ou não sindicalizados

Uma das primeiras coisas que devem ser consideradas é se você contratará atores
sindicalizados ou não sindicalizados. Sua escolha vai depender do orçamen-
to do projeto, do escopo e do cronograma. Atores não sindicalizados são mais
baratos, já que não há cobranças adicionais de taxas do sindicato. No entanto,
atores talentosos não sindicalizados são difíceis de encontrar. Ao usar atores não
sindicalizados, ainda que inicialmente economize dinheiro, você pode acabar
gastando mais se for muito demorado encontrar os atores certos ou se os atores
precisarem de várias tomadas para gravar cada linha corretamente. Se as neces-
sidades de voiceover do projeto forem mínimas, de cerca de algumas centenas de
linhas, o uso de atores não sindicalizados não será um grande risco.
Nos Estados Unidos, os atores sindicalizados são membros da Screen
Actors Guild (SAG), da American Federation of Television and Radio Artists
(AFTRA) ou, às vezes, de ambas. Os atores sindicalizados são encontrados
mais facilmente porque podem ser contatados por bancos de dados mantidos
pela SAG e pela AFTRA. Os custos do uso de atores sindicalizados incluem o
pagamento normal do ator, mais um percentual adicional que vai diretamente
para o sindicato para sua assistência previdenciária e médica.
Além disso, atores sindicalizados têm diretrizes de trabalho rigorosas e
devem ser pagos de acordo com uma programação de pagamentos definida
pelo sindicato. Por exemplo, todos os atores sindicalizados devem ser pagos
por um mínimo de quatro horas de trabalho, independentemente de quanto

tempo a sessão demorar. Eles também ficam limitados a não mais do que três
vozes ou personagens exclusivos por sessão de gravação. Qualquer voz adi-
cional demanda pagamento extra.
É mais caro contratar atores sindicalizados, mas esse custo pode se jus-
tificar, já que são profissionais certificados. Se estiver trabalhando em um
grande projeto e tiver de contratar vários atores, considere a contratação de
atores sindicalizados.
Vozes de celebridades
Nos últimos anos, o uso de voiceovers de celebridades se tornou muito popu-
lar. As celebridades dão ao jogo uma qualidade cinematográfica e é útil para
fins de marketing e relações públicas (RP). No entanto, um tempo adicional
deve ser incluído no cronograma, porque contratos precisam ser assinados e
aprovações podem ser requeridas para os arquivos finais de voiceover que en-
trarão no jogo. Além disso, podem existir restrições quanto à disponibilidade
do ator e o número de horas de gravação que ele pode fazer. Se usar voiceo-
vers de celebridades, comece a pré-produção do processo de voiceover mais
cedo para que haja tempo de lidar com problemas inesperados.
Se estiver usando uma celebridade internacionalmente conhecida, veri-
fique com seu agente como deve ser manipulado o voiceover para as versões
localizadas. O publicador pode ser obrigado contratualmente a usar um ator
Hz
de voiceover específico aprovado pela celebridade para dublar suas linhas
em outros idiomas. Foi isso que ocorreu com Bruce Willis, que fez a voz do
personagem principal em Apocalypse, um jogo para PlayStaion publicado
pela Activision. O ator gravou as linhas do personagem na versão em inglês e
atores aprovados por ele gravaram as linhas nas versões localizadas.
TRABALHANDO COM VOZES DE CELEBRIDADES

Activision
Tivemos sorte em trabalhar tão próximos à equipe de produção de Matrix. Trazer astros
de Hollywood para o estúdio para gravar diálogos pode ser muito complicado, mas com
a ajuda da produção do filme conseguimos reservar um tempo com os atores de Matrix
em dias em que tinham uma programação de filmagens mais leve ou entre seus compro-
missos com o filme. Com a cooperação dos irmãos Wachowski e a equipe de produção
de Matrix, o agendamento do tempo dos personagens principais para atividades como
voiceover, captura de movimentos ou fotografia digital se deu sem problemas. Reco-
mendamos que você trabalhe o mais próximo possível com o escritório de produção
do filme para assegurar que o tempo gasto com o elenco seja organizado, tornando-o
menos incômodo tanto para a equipe de desenvolvimento do jogo quanto para os pró-
prios atores.
Preparando as descrições de personagens

A descrição dos personagens dá uma ideia clara de quem é o personagem e
como ele deve soar. Essas notas são úteis para os atores que fazem teste para
um papel específico, já que eles não precisam adivinhar quem é o persona-
gem e podem se concentrar em criar uma voz que o defina. As descrições
também ajudam a direção do elenco a restringir o universo do tipo de ator
necessário para o papel.
A Figura 10.6 é um exemplo de modelo de descrição de personagem.
Uma imagem é muito importante, pois dá uma ideia clara do tipo de ator ne-
cessário para o papel. Outras informações essenciais, como o gênero, a idade
e a etnia, são descritas para estreitar ainda mais o universo. Uma descrição
breve dos padrões de fala e tom de voz também é útil. O ator que falar as li-
nhas pode usar essas informações para determinar como o personagem soará.
A última parte apresenta informações de onde o personagem aparece e sua
principal função no jogo. Geralmente, esse tipo de descrição é útil para um
jogo em que há alguma liberdade em como as linhas são lidas.
A Figura 10.7 é outro exemplo de descrição de personagem. Mas esse
exemplo usa uma abordagem diferente, já que informações detalhadas são
apresentadas sobre o histórico e a personalidade do personagem. As informa-
ções de histórico podem nem mesmo aparecer no jogo, mas apresentam um
personagem mais minuciosamente detalhado.
A descrição de voz apresenta o tom de voz do personagem, padrões de
fala e sotaques. A seção de referências inclui referências a atores famosos que
têm uma voz semelhante à que o personagem deve ter no jogo. Essas referên-
cias são muito úteis para o diretor de elenco e os atores.
A seção de exemplos de diálogo lista os diálogos que o personagem terá
no jogo. Esses exemplos podem ser usados quando os atores estiverem crian-
do fitas de teste. Podemos avaliar melhor como um ator soará no papel se ele
estiver sendo testado com diálogos que serão realmente usados no jogo e se o
diálogo for o mesmo entre diferentes candidatos.
Esse tipo de descrição de personagem funciona bem para personagens
principais que precisem ser mais bem definidos. A descrição detalhada tam-
bém funciona bem para personagens que apareceram em versões anteriores
do jogo e desenvolveram suas personalidades e históricos dentro do universo
do jogo.
Testes
Os testes dão a oportunidade de ouvir a leitura de vários atores diferentes para
cada personagem. Dependendo de como forem definidos, você também terá a
oportunidade de ver como os atores acatam a direção, quais seus potenciais
e se podem fazer várias vozes. O estúdio de gravação organizará os testes ou
recomendará uma agência de talentos para fazê-los.
Se não houver tempo ou dinheiro para marcar um teste separado, a sele-
ção dos atores pode ser feita pela escuta de uma fita de voiceover do ator. Isso
não é recomendado, já que não permitirá que você ouça exatamente como o
ator interpretará o personagem de seu jogo. Você terá de aceitar que ele é o
ator certo para o papel com base em informações não relacionadas ao jogo.
O processo básico de teste envolve o agendamento de uma hora para os
atores irem ao estúdio gravar alguns exemplos de diálogos do jogo. Quando
eles chegarem ao estúdio, receberão as descrições de personagens e um roteiro
de voiceover. O diretor de voiceover, se um for contratado, passará o roteiro
com eles e os preparará para o teste. O ator gravará a amostra de diálogo e essas
linhas serão processadas e disponibilizadas para o desenvolvedor. O desenvol-
vedor fará então as seleções finais de atores com base nas fitas dos testes.
Figura 10.6 Exemplo de descrição de personagem.
Nome: Bullet Point

Idade: 25 anos
NO SITE
Gênero: Masculino
Tipo: Super-humano
Papel: Herói; membro da Unidade de Justiça
Voz: Forte, confiante
Padrões de fala: Bullet Point é um executivo de marketing e tem uma voz forte, clara e bem projetada. Em conversas, ele é
demorado e muito analítico, mas em combate é rápido e direto. Tende a gritar durante as lutas, adotando um tom de
voz militar ao dar ordens.
Outras informações ??* Personagem do jogador
* Novo na equipe, permite que o jogador vivencie o mundo da Unidade de Justiça por seus olhos.
Nome Rainha do Gelo (nome real: Melanie Cole)

NO SITE
Histórico Nascida em 1979, Melanie cresceu em Virginia Beach, VA. Seu pai era arquiteto e sua mãe
trabalhava como recepcionista. Aluna mediana, Melanie estudou no Tidewater Community
College durante dois anos antes de mudar para a Old Dominion University, onde se formou
em História em 2002. Os pais de Melanie morreram em 2004, quando sua sensibilidade se
manifestou. A rajada glacial destruiu três casas, matando sete pessoas. Horrorizada,
Melanie fugiu, mas acabou sendo presa pela polícia. Mais tarde, nesse mesmo dia, seu
poder se manifestou novamente, destruindo a delegacia e matando vários policiais. Bullet Point
e Sensei foram chamados e conseguiram imobilizar Melanie. Ela foi levada para Masada,
onde a Divisão de Justiça pôde treiná-la no uso de seus poderes. Desde então, Melanie
aprendeu a controlar sua sensibilidade e se mostrou um membro valioso da Divisão de Justiça.
Personalidade Melanie é extremamente discreta e tem dificuldade para travar relações duradouras com as
pessoas. Embora tenha lutado ao lado de outros membros da Divisão de Justiça por dois anos,
ainda os chama por seus codinomes e evita se socializar fora do trabalho. Os membros da
Divisão de Justiça brincam dizendo que sua arma ofensiva mais poderosa é o olhar gélido. Ela
ainda sofre por sua família e sente um profundo remorso pelas vidas que tirou, mesmo
sabendo que as mortes foram acidentais. Apesar das centenas de horas de treinamento,
Melanie teme perder o controle de seus poderes, o que resultaria em mais mortes de inocentes.
Voz A voz de Melanie é baixa e firme. Ela só levanta sua voz quando pune ou discorda de alguém.
Com frequência soa astuta ou condescendente, principalmente ao explicar algo para outras
pessoas, e pode parecer insensível ao dar más notícias. Fala inglês sem sotaque carregado.
Referências Gillian Anderson (Arquivo X)

Exemplo de diálogo “É realmente muito ruim, mas não é problema nosso. Estamos aqui para prender Zomborg e
isso é tudo em que estou interessada em conversar.”
“Que parte de ‘imediatamente’ você não entendeu? Você já estava sendo esperado. Entre lá e
faça seu trabalho.” “Não tenho tempo para lidar com isso. A Divisão também não tem.
Aguente ou desista.”
Figura 10.7 Outro exemplo de descrição de personagem.

Para escolher com sucesso o ator correto durante os testes, temos de

lembrar várias coisas. Em primeiro lugar, alguém da equipe de desenvolvi-
mento deve estar presente, ainda que seja por telefone, durante os testes.
Pedir que alguém da equipe participe do processo de teste é essencial, já
que os membros poderão aconselhar o diretor de voiceover sobre as ca-
racterísticas específicas que estão procurando no ator. Por exemplo, se o
personagem tiver um sotaque russo, o desenvolvedor poderá esclarecer se
esse sotaque deve ser forte, leve, exagerado ou mais realista. Dessa forma,
quando ele estiver examinando os testes, não precisará se preocupar se
o ator que usou um leve sotaque russo conseguirá fazer um sotaque mais
forte e realista.
O outro benefício de haver alguém da equipe no teste é que a pessoa
terá uma experiência direta de como é trabalhar com um ator específico. Por
exemplo, o ator pode precisar de muita orientação, ser difícil de lidar ou não
ter uma experiência de atuação suficientemente ampla para um personagem
central. Todas essas informações são úteis na seleção final do ator.
Se ninguém da equipe estiver disponível para acompanhar o teste, peça
feedback sobre os atores ao estúdio de gravação. Os estúdios de gravação ten-
dem a trabalhar sempre com o mesmo grupo de atores e poderão dar um feed-
back importante sobre a habilidade do ator em dar o que está sendo pedido.
Também poderão opinar sobre se os atores acatam bem a direção.
Em segundo lugar, certifique-se de que a amostra de diálogo do teste re-
flita o tipo de diálogo que entrará realmente na versão final do jogo. Se estiver
trabalhando em um jogo militar realista, inclua uma amostra de diálogo que
reflita como os soldados falam. O diálogo também deve incluir uma ampla va-
riedade de emoções, volumes e durações para o ator gravar. Por exemplo, in-
clua diálogos que sejam conversas, envolvam irritação, falas gritadas, sussur-
radas, felizes e assim por diante. Além disso, inclua diálogos que sejam curtos
comentários in-game – “área protegida” – e diálogos mais longos compostos
por várias frases que possam aparecer na cinemática. Essa ampla variedade de
exemplos de diálogo lhe dará uma ideia melhor de quanto o ator é apropriado
para o personagem.
Em terceiro lugar, não hesite em pedir que atores adicionais sejam cha-
mados para os testes. Se não ouvir um ator adequado para o personagem que
você está tentando moldar na primeira rodada de testes, chame outro grupo
de atores para o teste. A gravação do voiceover é muito cara e é melhor encon-
trar a pessoa certa em vez de regravar o diálogo posteriormente.
Os testes devem ser feitos bem antes da sessão real de gravação para que
você tenha tempo de selecionar os atores e reservar seu horário. Consulte no-
vamente a Figura 10.4 para ver uma programação geral para os testes.
Selecionando os atores e reservando seu tempo

Após as fitas do teste serem concluídas e passadas para você para verificação,
a seleção final dos atores deve ser feita. Se outras pessoas tiverem interesse
no ator que será escolhido para um papel específico, ouçam as fitas juntos
e determinem quem deve ser escalado. Esse processo pode ser frustrante e
trabalhoso, principalmente se cada pessoa tiver uma opinião em relação ao
que está procurando no personagem. É no enfrentamento desse desafio que
as descrições de personagens são úteis: se as descrições estiverem suficien-
temente detalhadas, todos devem ter uma ideia semelhante de como o perso-
nagem soará. Se sua equipe não estiver de acordo com a descrição básica do
personagem, pode ser difícil entrar em consenso quanto a um ator.
Embora sua maior preocupação seja conseguir o ator certo para o perso-
nagem, várias outras qualidades vocais além da habilidade de atuar devem
ser consideradas na avaliação das fitas do teste:
Enunciação: As palavras devem ser claramente articuladas e sem ne-
nhum ruído da boca, como estalos, barulho de engolir e ruídos dos lá-
bios. Ouça também como os sons sibilantes são emitidos; alguns atores
pronunciam palavras com um “S” ou “P” que é muito forte ou muito
leve. Esses tipos de padrões de fala podem ser difíceis de amenizar na
sessão de gravação.
Padrões de respiração: Ouça como o ator respira quando fala. Se ele
inspirar várias vezes ao ler as frases, isso será ouvido nas gravações. Um
bom editor de som pode amenizar algumas das inspirações se elas ocor-
rerem durante intervalos lógicos do diálogo.
Impostação: Determine se a impostação do ator combina com o jogo. Se
a impostação for muito alta e aguda ou muito baixa e grave, será difícil
para os jogadores entenderem informações essenciais. Um ator com um
alcance amplo não deve ter problemas em impostar sua voz apropriada-
mente. No entanto, se seu alcance não for muito amplo, será difícil para
ele mudar a impostação natural de sua voz.
Cadência: Ouça o ritmo da fala do ator. Ele soa natural ou monótono?
Um personagem com uma cadência incomum para sua voz não é um
problema. No entanto, pode ser problemático se o ator tiver naturalmen-
te uma cadência incomum.
Quando uma decisão final tiver sido tomada para todos os atores, comu-
nique suas escolhas para o estúdio de som. Eles pegarão essa lista e agendarão
os atores para a sessão. Se estiver agendando os atores você mesmo, primeiro
agende-os em stand-by e só faça a reserva final após a programação de grava-
ção ser confirmada com o estúdio de som. Stand-by significa o ator estar dis-
ponível para a sessão de gravação, mas sem estar totalmente comprometido;
é equivalente a inserir algo a lápis em um cronograma. Nenhum pagamento
é devido a atores em stand-by. Reservar significa que o ator está totalmente
comprometido com a sessão e receberá um pagamento, mesmo se ela for can-
celada ou remarcada; resumindo, o ator comprometeu-se com o projeto e não
pode se comprometer com nenhum outro trabalho durante esse período.
10.5 Gravando o voiceover
Após os atores serem reservados e o tempo do estúdio ser agendado, você está
quase pronto para gravar o voiceover. A gravação do voiceover pode ser um
processo estressante, já que muitos elementos devem ser preparados e finali-
zados antes da sessão. Esse estresse será menor se a planilha de voiceover es-
tiver concluída e pronta para ser usada, todos os atores tiverem sido escalados
e agendados e a equipe de desenvolvimento tiver se preparado para a sessão.
Preparando a sessão de gravação

Já que os atores são agendados por um máximo de quatro horas de cada vez,
use seu tempo de maneira eficiente na sessão. Para aproveitar ao máximo o
tempo do ator, você deve preparar vários itens antes da sessão de gravação.
Primeiro, decida quem dirigirá os atores e quem mais participará da ses-
são. Não é problema haver várias pessoas na sessão de gravação, contanto que
haja apenas uma trabalhando diretamente com o ator. Se você estiver traba-
lhando com celebridades, o publicador também pode querer ter alguém na
sessão, principalmente se quiser filmá-la para uso do departamento de RP. A
equipe de desenvolvimento também pode querer ter várias pessoas presentes,
como o produtor, um designer, o designer de som e assim por diante. O reda-
tor do diálogo deve participar da sessão, já que é a pessoa certa para aconse-
lhar o diretor de voz sobre o contexto e a distribuição das linhas. Se o redator
tiver experiência na direção de atores de voz, talvez possa dirigir a sessão.
Certifique-se de que o roteiro de voiceover (consulte a Figura 10.3) esteja
concluído e pronto para ser usado. O roteiro deve ser enviado para o estúdio
de gravação antecipadamente para que eles possam prepará-lo para os atores.
O estúdio dividirá o roteiro por personagens. Traga também a versão eletrô-
nica desse roteiro para a sessão de gravação. Se alguma mudança for feita no
diálogo, o roteiro poderá ser rapidamente atualizado com essas alterações.
Além disso, se houver tomadas extras selecionadas ou linhas adicionais in-
cluídas, a planilha poderá ser atualizada para refletir isso.
Os arquivos dos testes originais dos atores devem estar disponíveis para
eles ouvirem na sessão de gravação. Essa disponibilidade lembrará o ator ra-
pidamente da voz que foi criada para o personagem e dará ao diretor de voi-
ceover um bom ponto de partida para discutir com o ator qualquer alteração
na voz. Se ocorrerem várias tomadas em diferentes momentos do cronograma,
os arquivos de áudio de sessões de gravação anteriores devem estar disponí-
veis para os atores imitarem o diálogo que gravaram. O estúdio de som terá
acesso a esses arquivos e poderá prepará-los para as sessões.
Traga também a última versão das descrições dos personagens para as
sessões. Essas notas refrescarão a memória do ator em relação ao personagem
e darão ao diretor de voz informações concretas de como descrever o perso-
nagem para o ator.
A filmagem da mecânica do jogo ou um trailer também são ferramentas

úteis para mostrar aos atores do que trata o jogo e como suas vozes serão usa-
das nele. Não traga uma demo jogável; o tempo gasto na preparação da demo
e em sua execução pode ser utilizado na gravação do diálogo. Se a filmagem
da mecânica do jogo não estiver disponível, esteja preparado para descrever a
experiência geral do jogo para o ator para ele compreender melhor como esse
diálogo será usado.
Prepare um guia de pronúncia para palavras-chave que devem ser pro-
nunciadas de maneira consistente. Esse guia é particularmente necessário
para palavras que tenham sido criadas especificamente para o jogo, como no-
mes incomuns de personagens e nomes de locais fictícios. Palavras do mundo
real também devem ser incluídas, como frases em idioma estrangeiro, nomes
e locais internacionais e palavras que normalmente sejam pronunciadas de
maneira errada. O guia de pronúncia deve incluir uma grafia fonética da pala-
vra. Se houver tempo, arquivos de áudio podem ser gravados com a pronún-
cia correta e reproduzidos para o ator durante a sessão.
Para concluir, tenha o cronograma atualizado para cada dia da sessão de
gravação. Isso o ajudará a rastrear as entradas e saídas de atores e tornará mais
fácil reprogramar atores, se necessário. Por exemplo, um ator pode ser reser-
vado para uma sessão de quatro horas, mas concluir tudo em duas. Você pode
consultar o cronograma para saber se algum outro ator pode ser agendado
mais cedo e aproveitar melhor o tempo na cabine de gravação.
Dirigindo atores
Diretores de voz profissionais podem ser contratados para conduzir a sessão
de gravação. A vantagem do uso de um profissional é que eles sabem traba-
lhar com atores para obter o desempenho desejado. A desvantagem é o custo.
No entanto, um diretor profissional pode ser um bom investimento na grava-
ção de milhares de linhas de diálogo com vários atores, porque provavelmen-
te você obterá o desempenho desejado na primeira gravação e não precisará
regravar o diálogo em uma data posterior. A maioria dos estúdios de som
poderá ajudá-lo a localizar um diretor profissional para sua sessão.
Se alguém da equipe de desenvolvimento for manipular a direção de
voz, certifique-se de que essa pessoa seja um comunicador oral eficaz. O di-
retor de voz ou diretor de atuação tem a responsabilidade de fazer o ator se
sentir à vontade e dar um feedback claro para ele; e também tem de saber
criticar e dirigir o ator de maneira delicada, para que este não fique frustrado
durante a sessão. O mais importante é essa pessoa se manter positiva e focada,
até mesmo durante uma sessão difícil em que o ator não estiver respondendo
às orientações dadas. Em vez de se sentir frustrada, ela precisa enxergar dife-
rentes maneiras de dirigir o ator para obter o desempenho apropriado.
Algumas diretrizes gerais para a direção de voiceover são as seguintes:
Deixe o ator se aquecer: Peça ao ator que faça alguns ensaios de par-
te do diálogo para ficar aquecido e pronto para gravar. Pode acontecer
de ele não ficar realmente aquecido e relaxado até estar na sessão de
gravação. Nesses casos, verifique o diálogo que foi gravado no começo da

sessão e peça ao ator para regravá-lo se necessário.
Deixe toda a parte gritada para o fim da sessão: Informe ao ator an-
tecipadamente sobre gritos ou conversas em voz alta. A parte gritada
cansará as cordas vocais do ator, e ele vai querer ter tempo suficiente
entre as sessões de voiceover para descansar. Todas as partes em voz alta
e gritadas devem ser gravadas no fim da sessão para que as cordas vocais
não fiquem cansadas já no início.
Dê feedback específico para os atores: Se estiver solicitando uma re-
gravação ou uma captação, forneça informações específicas para o ator
sobre o que é preciso mudar. Se o ator não conhecer as peculiaridades,
provavelmente produzirá o mesmo desempenho que forneceu na primei-
ra vez. Por exemplo, ele pode não estar articulando claramente ou a fala
pode não estar coincidindo com a emoção desejada. Deixe esse feedback
claro, para o ator poder atingir o desempenho que você está procurando.
Não interrompa o ator após cada leitura de linha – deixe fluir: A maio-
ria dos atores consegue falar rapidamente uma página inteira de diálogo
sem intervalo e fazer duas ou três tomadas de cada linha de diálogo. Por
exemplo, se o roteiro tiver 20 linhas de diálogo, o ator lerá a primeira
linha três vezes (cada leitura terá uma inflexão diferente para a linha),
então passará para a próxima linha e a lerá três vezes (com inflexões di-
ferentes), e, assim por diante, até ter concluído a página de diálogo. Essa
forma de gravar linhas facilita para o ator se manter focado no persona-
gem que criou. Se o ator tiver de parar após ler cada linha para o diretor
poder examinar as tomadas, isso quebrará sua concentração e também
aumentará muito mais o tempo de gravação do diálogo (ou seja, mais
dinheiro será gasto na sessão de gravação).
Selecionando tomadas
Durante a sessão de voiceover, os atores fazem várias leituras, ou tomadas, de
cada linha, e a tomada final é selecionada entre essas opções. A anotação exata
dessas informações é importante porque geralmente o programador de som e
o editor de som são duas pessoas diferentes. O programador de som é respon-
sável por gravar a sessão e passá-la para o editor de som para processamento.
Para o editor de som saber que tomada é a final, ele precisa de notas de roteiro
que registrem quantas tomadas foram gravadas para cada linha e qual foi esco-
lhida como tomada final. Cada estúdio de som pode ter uma maneira um pou-
co diferente de fazer isso, portanto, discuta o processo de gravação e seleção
de tomadas antes da sessão de gravação começar. Por exemplo, alguns estúdios
podem rotular várias tomadas de uma única linha como “1A”, “1B” e “1C”,
com o número correspondendo ao número da linha. Capturas gravadas para
essa mesma linha em um momento diferente da sessão seguiriam o padrão.
Tomadas alternativas podem ser selecionadas para uma mesma linha
e também devem ser incluídas nas notas de roteiro como alternativas. Você
também deve designar uma maneira de distinguir tomadas alternativas na

convenção de nomenclatura de arquivos. Dessa forma, a tomada final e a al-
ternativa serão facilmente diferenciadas. Lembre-se de que os estúdios co-
bram pelo número de linhas que processam e entregam; logo, se você acabar
adicionando muitas tomadas alternativas, o custo pode aumentar.
Produtos de áudio
Após o diálogo ser gravado e as tomadas serem selecionadas, os arquivos serão
enviados para o editor de som para processamento. Ele será responsável por
preparar os arquivos de áudio com o formato e o nome de arquivo corretos.
Como já discutimos, defina antecipadamente que formatos e efeitos especiais
são necessários e quais são os nomes dos arquivos. Essa definição evitará con-
fusão quando a equipe de desenvolvimento receber os arquivos e começar a
integrá-los ao jogo. Alguns estúdios fornecem os dados brutos da sessão de
gravação inteira sob demanda. Esses dados podem ser úteis se o designer de
som precisar editar alguns dos arquivos ou se outra tomada tiver de ser usada.
10.6 Lista de verificação do voiceover
A criação de uma lista de verificação com as tarefas que devem ser concluídas
na sessão de voiceover pode ser útil. A Figura 10.8 é um exemplo que pode
ser usado.
Como o voiceover é uma parte de destaque do jogo, a gravação de um voiceo-

ver de qualidade é importante. À medida que os jogos vão ficando maiores,
fica ainda mais importante e difícil incluir o voiceover. Já se foram os dias
em que os jogos tinham apenas algumas centenas de linhas de diálogo grava-
das por desenvolvedores; milhares de linhas de diálogo faladas por atores de
voiceover profissionais são a norma atualmente. Para obter o melhor diálogo
possível, encontre um bom fornecedor de gravação de som para trabalhar na
gravação de um voiceover de qualidade. Este capítulo discutiu algumas das
tarefas-chave que devem ser executadas no gerenciamento de voiceovers de
jogos. Foram apresentadas informações sobre como encontrar um fornecedor,
escalar e dirigir atores, formatar o roteiro de voiceover e gerenciar a sessão de
gravação.
Lista de verificação do voiceover S/N Notas

Pré-produção
NO SITE O design inicial do voiceover foi concluído?
As descrições iniciais dos personagens foram redigidas?
O cronograma inicial do voiceover foi criado?
O orçamento inicial do voiceover foi criado?
A convenção de nomenclatura de arquivos foi estabelecida?
O sistema de gerenciamento de arquivos foi estabelecido?
Os formatos de entrega de arquivos foram definidos?
Notas de escalação de atores foram redigidas com exemplos de diálogos?
Solicitações de proposta foram enviadas para os estúdios de som?
Produção
O estúdio de som foi selecionado?
Foi tomada uma decisão final sobre o uso de atores sindicalizados ou não sindicalizados?
As datas de gravação foram reservadas provisoriamente com o estúdio de som?
O roteiro inicial de voiceover foi redigido?
O diálogo de espaço reservado foi gravado e implementado no jogo?
Testes foram agendadas?
Vozes de celebridades estão sendo usadas? Elas estarão disponíveis nas datas provisórias?
A seleção final de atores foi concluída? Eles estarão disponíveis nas datas provisórias?
Sessão de gravação
As datas foram definidas e reservadas com os atores?
O roteiro de voiceover foi definido?
Os arquivos de teste estão disponíveis para os atores escutarem?
O guia de pronúncia foi definido?
A filmagem do jogo está disponível para ser mostrada aos atores?
O diretor de voz foi reservado para a sessão?
Todas as tomadas finais foram selecionadas?
Pós-produção
O estúdio de som editou as tomadas finais de arquivos de áudio?
Os arquivos foram entregues no formato correto? Versões descompactadas estão
disponíveis?
Os dados brutos da sessão de gravação foram entregues?
O roteiro de voiceover foi atualizado com alterações feitas no diálogo e linhas
alternativas?
Figura 10.8 Lista de verificação do voiceover.

11
MÚSICA
Neste capítulo
• Planejando a música • Trabalhando com um • Licenciando a música
compositor
11.1 Introdução
A música é uma ferramenta muito eficaz para a definição do tom de um jogo

digital e torna o mundo do jogo mais envolvente. A série Silent Hill usa mú-
sica e som com ótimos resultados para aumentar o terror de um mundo habi-
tado por criaturas demoníacas. Em alguns casos, ela é uma das últimas coisas
consideradas em um projeto, e o produtor começa a procurar um compositor
bem depois do jogo ter entrado em produção. Em outros, é parte integrante
do jogo inteiro e é planejada durante a pré-produção. Por exemplo, a série
de jogos Tony Hawk é conhecida por licenciar música de bandas famosas.
O licenciamento de música nessa escala requer planejamento e negociações
legais. Se as licenças não forem protegidas antes de o código do jogo ser lan-
çado, provavelmente a trilha sonora será removida do jogo.
As coisas que devemos lembrar quanto à música incluem considerações
técnicas, orçamentos, cronograma e o modo como a música será usada no
jogo. Além disso, você pode querer licenciar a música em vez de usar uma
composição original. Este capítulo fornecerá uma visão geral de como plane-
jar e usar música em seu jogo.
11.2 Planejando a música
Como qualquer outro elemento do jogo, a música deve ser discutida durante
a pré-produção. Você não tem necessariamente de finalizar o planejamento
inteiro da música nesse momento, mas é aconselhável determinar quanto quer
gastar, decidir se vai licenciar a música, trabalhar com uma composição origi-
nal, ou ambos, e criar provisoriamente um cronograma para a conclusão dos
assets musicais e sua integração ao jogo. Além disso, se espera que a trilha
sonora evoque uma determinada atmosfera, discuta o assunto na pré-produção
para assegurar que a música combine com os elementos artísticos e de design.
Design da música
O designer de som trabalhará com um designer líder ou um diretor de cria-
ção para determinar as necessidades musicais do jogo. Por exemplo, se for
um jogo de ação-aventura em que o jogador passe muito tempo explorando o
mundo e parte do tempo combatendo o inimigo, um tipo de música in-game
poderá ser usado enquanto o jogador estiver explorando e outro tipo quando
ele estiver lutando.
Ao determinar as necessidades musicais, considere quais as principais
áreas do jogo que precisarão de música:
• In-game
• Interface gráfica out-game
• Cinemática
Essa definição poderá então ser detalhada dentro de cada categoria. Por
exemplo, no uso de música in-game, ela será proveniente de uma fonte am-
biental do mundo do jogo (como o rádio de um carro) ou estará tocando cons-
tantemente em segundo plano? A interface gráfica out-game poderá ter um
trecho musical sendo repetido continuamente ou abranger várias canções se
repetindo em sequência enquanto o jogador estiver nas telas out-game. A ci-
nemática pode ter uma trilha sonora que corresponda diretamente à imagem,
ou vários loops musicais genéricos podem ser compostos e inseridos na trilha
sonora por um artista cinemático.
Após ter uma ideia de onde deve haver música no jogo, estime quantos mi-
nutos de música são necessários. A maioria dos compositores cobra por minuto
para criar música original e as taxas podem variar de 300 a mais de 1500 dólares
por minuto. A remuneração vai depender de quem é o compositor, se a música,
está sendo gravada com músicos ou se está sendo criada digitalmente. Além dis-
so, se músicos forem usados, você também pode ter de pagá-los; seu compositor
pode acertar os detalhes com você e os músicos.
A quantidade de músicas vai variar para cada jogo e deve ser orçada de
acordo. Por exemplo, se você precisar de 30 minutos de música original e só
puder gastar 10 mil dólares, terá de encontrar um compositor que faça o ser-
viço por cerca de 330 dólares por minuto. Por outro lado, você pode reduzir
a quantidade de músicas do jogo e pagar um compositor que cobre mais por
11 • Música 181
minuto. Se encontrar um compositor com quem queira trabalhar e ele tam-

bém quiser trabalhar com você, ambos devem conseguir chegar a um acordo.
Durante a pré-produção, o designer e o programador de som terão de discu-
tir qualquer restrição técnica que afete o modo como a música será imple-
mentada no jogo. Essas restrições técnicas podem gerar alguns desafios, mas
também serão oportunidades de descobrir soluções criativas para superá-los.
Alguns dos elementos técnicos que devem ser considerados são os seguintes:
Limitações de memória: Consoles e telefones têm limitações de memó-
ria que devem ser consideradas no projeto de som dos jogos. Se o design
de som demandar que todos os itens sejam carregados na memória para
funcionar, você pode acabar decidindo que ele não é apropriado para um
console PS2, que tem um limite de 64 MB para tudo – código, som, arte,
roteiro. Jogos de celulares também têm esse tipo de limitação, ainda mais
do que os títulos de console.
Fluxo contínuo de áudio: O fluxo contínuo de áudio é composto por arqui-
vos de som que saem diretamente do disco e são reproduzidos em tempo
real. Ele não precisa ser armazenado na memória, ou seja, as limitações de
memória podem ser amenizadas se essa abordagem for usada como maneira
de distribuir áudio no jogo. O designer de som deve especificar os arquivos
de áudio que serão transmitidos diretamente e os que devem ser carregados
na memória, para que não haja problemas de desempenho. Por exemplo, o
uso de fluxo contínuo de áudio para uma resposta de IA pode diminuir a
velocidade das ações, já que o código terá de procurar no disco o arquivo
apropriado para então reproduzi-lo. Se as respostas de IA forem carregadas
na memória, a resposta apropriada será reproduzida imediatamente.
Limitações de espaço em disco: Outra limitação que deve ser conside-
rada é o espaço que você terá no disco para armazenar sons. Se tiver vá-
rios gigabytes de espaço disponíveis para o jogo inteiro, provavelmente
isso não será problema. No entanto, se estiver planejando incluir vários
idiomas no mesmo disco, é preciso que haja espaço suficiente para o ar-
mazenamento de cada conjunto de voiceovers localizado.
Compactação: Como na cinemática, os arquivos de música terão de ser
compactados na versão final do jogo. A compactação permite que mais
músicas e efeitos sonoros sejam incluídos no jogo, porque os tamanhos
dos arquivos são reduzidos. O designer de som deve determinar que es-
quema de compactação fornece o melhor resultado, tanto em termos de
qualidade de som quando de espaço necessário no disco. Se os arquivos
forem excessivamente compactados, o som terá baixa qualidade; muitas
nuances não serão ouvidas.
Trilhas sonoras personalizadas: Se seu jogo der suporte à funcionalida-
de de trilhas sonoras personalizadas, os jogadores poderão importar suas
próprias trilhas para o jogo, usando um CD ou arquivos MP3. Assim, se
alguém quiser ouvir música clássica em vez de heavy metal ao pilotar

carros, essa opção estará disponível. Se seu jogo incluir esse recurso,
você não precisará gastar muito dinheiro licenciando músicas porque
provavelmente vários jogadores personalizarão a experiência do jogo
com suas próprias seleções musicais.
Formatos de áudio: A que formatos musicais seu jogo dará suporte?
Há vários formatos para serem escolhidos, cada um com suas vantagens
e desvantagens. Em geral, o designer de som e o programador de áudio
escolhem o formato que forneça a melhor qualidade de som e fique den-
tro dos limites de memória. Por exemplo, arquivos MIDI são usados para
jogos de celular; o som não é o melhor possível, mas o armazenamento
de vários minutos de música em formato MIDI não ocupa muito espaço.
Outros formatos de áudio digital disponíveis com melhor qualidade de
som são o WAV, ADPCM, Redbook Audio e MP3.
Cronograma e equipe
Independentemente de você licenciar a trilha sonora ou contratar um com-
positor, é preciso determinar as necessidades musicais bem antes de seu jogo
alcançar a versão beta. Quando chegar à versão beta, pode ser tarde demais
para contratar um compositor para criar a música original, porque você não
conseguirá encontrar alguém que trabalhe de última hora. Se conseguir, pro-
vavelmente a qualidade do trabalho não será tão boa como poderia ser, devido
ao tempo limitado. Também será tarde demais para começar a negociar com
vários publicadores sobre as faixas que você está interessado em licenciar.
A versão alfa é um bom momento para se começar a contatar publicado-
res de músicas em busca de faixas licenciadas ou enviar solicitações de pro-
posta para possíveis compositores. Se você contratar um compositor externo,
certifique-se de que o contrato especifique que o trabalho que ele está fazendo
é “por encomenda”. Ou seja, sua empresa é dona dos direitos de PI da música,
e não o compositor. Consulte o Capítulo 4, “Informações legais”, para obter
mais informações sobre o contrato por encomenda.
Se houver um compositor interno disponível para trabalhar em seu pro-
jeto, pode ser tentador gerenciar essa pessoa sem um cronograma formal de
entrega de produtos, já que você poderá falar com ele na hora que quiser. No
entanto, isso não é recomendado. Como qualquer membro da equipe, o compo-
sitor precisa saber especificamente quais são seus prazos para poder se planejar
de acordo. Se ele tiver de entregar as mixagens finais das músicas no momento
da versão beta, terá de programar etapas entre a pré-produção e a versão beta
para poder cumprir seus prazos. O bom em se ter um compositor interno é
que ele estará imediatamente disponível para qualquer necessidade musical de
emergência que surgir em um projeto. Além do mais, qualquer trabalho feito
por um compositor interno passa a ser propriedade de seu empregador.
Como ocorre com o voiceover, é útil a implementação de música de es-
paço reservado durante a produção para dar uma ideia melhor das necessida-
des musicais finais e de como soará o jogo. Apenas não se esqueça de remo-
ver qualquer música provisória antes do jogo ser entregue, principalmente se
11 • Música 183
estiver usando música licenciada cujos direitos não tiver. Certifique-se tam-
bém de que as filmagens de marketing iniciais do jogo não incluam músicas
licenciadas cujos direitos não sejam seus, porque isso pode se transformar
em uma questão legal se o músico ou seu publicador descobrir.
Ao compor seu cronograma de planejamento musical, inclua os prazos das
músicas necessárias para fins de marketing. Por exemplo, o departamento de
marketing pode precisar de um ou dois minutos de música para um trailer de
jogo da E3. Se o jogo estiver no estágio alfa, a música final pode não estar pronta
ou as faixas finais podem não ter sido legalmente licenciadas. Nesse caso, você
precisará de alguma música provisória que o departamento de marketing possa
usar sem problemas legais e que evoque como soará a música final do jogo. Se o
jogo final estiver usando uma trilha sonora orquestrada, uma música orquestrada
provisória poderá ser usada no trailer. Se você já tiver contratado um compositor
ou tiver um compositor interno, provavelmente ele poderá compor uma música
exclusivamente para essa peça de marketing em um ou dois dias.
CRONOGRAMA DA CINEMÁTICA
Se você tiver cinemática pré-renderizada no jogo e estiver usando música original ou licen-
ciada, deve considerar os prazos da cinemática quando criar o cronograma de planeja-
mento musical. Por exemplo, um compositor criando música original para um conjunto
de necessidades cinemáticas precisa ver uma versão inicial dessa cinemática antes de po-
der começar seu trabalho, para ter uma ideia clara da quantidade de música necessária e
dos eventos do jogo que serão enfatizados pela música.
Em geral, os compositores preferem compor de acordo com as imagens para a mú-
sica ser sincronizada apropriadamente com os eventos-chave da cinemática. Para que isso
ocorra, ele tem de receber uma cinemática final e no ritmo certo, com trilhas de voiceover
e efeitos sonoros, algumas semanas antes de seus produtos musicais finais serem termi-
nados. Isso lhe permitirá ajustar o ritmo final da trilha sonora da cinemática e mixá-la
corretamente para que fique sincronizada com o voiceover e os efeitos sonoros.
Se alguma edição for feita na cinemática após a música final ser entregue, você terá
de enviá-la de volta ao compositor para a música ser sincronizada novamente. Dependen-
do da extensão das edições, isso pode demorar um pouco, porque o compositor rearran-
jará e removerá partes da música para ajustá-la ao novo ritmo. Se possível, evite editar a
cinemática após a música, o voiceover e os efeitos sonoros finais serem concluídos, já que
essa ação adicionará mais tempo ao cronograma e pode colocar o projeto em risco.
Se o compositor estiver entregando apenas loops musicais que sejam reproduzidos
como música de segundo plano na cinemática e não depender da música para pontuar
imagens-chave do jogo, a sincronização não será tão crucial. Se alguma edição for feita, a
música continuará sendo repetida quando necessário até a cinemática terminar.
Após ter se decidido sobre um compositor ou definido as trilhas que irá

usar, você terá de determinar o prazo para receber todos os assets musicais finais
do jogo. O compositor deve se planejar para entregar as mixagens musicais finais

cerca de um mês antes da versão beta. Se estiver no contrato, o produto musical
final também deve incluir as bases, que são as trilhas instrumentais individuais
existentes dentro da mixagem musical final. Elas podem ser usadas na composi-
ção de variações para comerciais, trailers do jogo ou jogos futuros.
Planeje ter todos os direitos musicais finalizados e contratos assinados
cerca de um mês antes da versão beta. Isso assegurará que tudo esteja con-
cluído na data de entrega do jogo. Se não conseguir os direitos de uma faixa
musical até a versão beta, considere substituir ou remover essa faixa do jogo.
A Figura 11.1 é a visão geral do cronograma musical de um jogo. Quando
o compositor começar a entregar a música para ser ouvida, você deve agendar
os prazos específicos para lhe dar um feedback e receber de volta as faixas
musicais revisadas para verificação.
Solicitação de propostas
Envie solicitações de proposta para vários compositores durante a pré-pro-
dução para ter uma ideia dos preços, da rapidez com que respondem, de seu
estilo musical e de quanto tempo levarão para compor música para seu jogo.
Os compositores podem ter um formato preferido para o recebimento das so-
licitações de proposta, portanto, primeiro verifique com eles se é necessário
usar algum formulário. Em geral, as solicitações de proposta devem incluir o
máximo de informações possível sobre as necessidades musicais do jogo. Os
itens que devem ser incluídos são os seguintes:
• Total geral dos minutos de música necessários

• Quantas peças musicais diferentes são necessárias
• Quanto tempo cada peça musical deve ter
• Detalhes de onde cada peça musical estará localizada no jogo (IU, in-
-game, cinemática)
• Qualquer mixagem de som, voiceover e música que for necessária
• Formato dos produtos musicais
• Prazo-limite para recebimento de todos os produtos finais

Design musical determinado Designer de som/ Antes da produção começar
NO SITE programador de som
Produtos musicais iniciais definidos Designer de som Versão alfa
Adicionar música provisória ao jogo Designer de som Versão alfa
Enviar solicitações de proposta para compositores Produtor Versão alfa
(no caso de trabalho com compositores externos)
Começar a negociar direitos musicais Produtor Versão alfa
(no caso de licenciamento da música)
Primeiro conjunto de composições Compositor Cerca de 2-3 meses antes
entregue pelo compositor da versão beta
Compositor entrega mixagens musicais finais Compositor Cerca de 1 mês antes da versão beta
Proteger todos os direitos musicais finais Produtor Cerca de 1 mês antes da versão beta
Implementar toda a música final no jogo Designer de som Versão beta
Figura 11.1 Visão geral do cronograma dos produtos musicais.

11 • Música 185
A Figura 11.2 é um exemplo das informações que você deve incluir em

uma solicitação de proposta. Essa uma maneira bastante simples de organizar
as necessidades musicais e os prazos.
Necessidades
Duração Detalhes da mixagem Local Formato Notas Prazo
musicais
NO SITE Tema 120 Mixagem full Dolby 5.1 IU .wav Tema principal do jogo, será ouvido 30 de abril,
principal segundos sempre que os jogadores estiverem 2007
nas telas out-game. Deve combinar
com a atmosfera descrita no
documento “Visão Musical” incluso.
Loop 1 30 Estéreo In-game .wav Ouvido no jogo como peça musical 30 de maio,
segundos repetida de segundo plano. Deve 2007
combinar com a atmosfera descrita
no documento “Visão Musical” incluso.
Loop 2 30 Estéreo In-game .wav Ouvido no jogo como peça musical 30 de maio,
segundos repetida de segundo plano. Deve 2007
combinar com a atmosfera descrita
no documento “Visão Musical” incluso.
Cinemática 180 Estéreo, música + voice- Cine- .wav Entrega das mixagens finais de 30 de junho,
inicial segundos over + efeitos sonoros, a mática música, vo e efeitos sonoros em 2007
música deve ser sincro- trilhas separadas.
nizada com as imagens.
Cinemática 60 Estéreo, só música, mú- Cine- .wav Entrega das mixagens finais de 30 de junho,
intermediária segundos sica de segundo plano, mática música, vo e efeitos sonoros em 2007
sem sincronização. trilhas separadas.
Cinemática 90 Estéreo, música + voice- Cine- .wav Entrega das mixagens finais de 30 de junho,
final segundos over + efeitos sonoros, a mática música, vo e efeitos sonoros em 2007
música deve ser sincro- trilhas separadas.
nizada com as imagens.
Figura 11.2 Exemplo de proposta musical.
Além disso, você terá de fornecer alguma documentação e exemplos de

como deseja que a música soe. O documento de visão musical deve fornecer
informações gerais sobre o gênero musical, os temas das etapas do jogo e qual-
quer outra consideração especial (como preferências regionais). Também deve
incluir amostras de música de outros jogos, trilhas sonoras, bandas, composi-
tores ou qualquer outro tipo de áudio que dê uma ideia da atmosfera que você
deseja para o jogo. Após enviar as propostas, faça um acompanhamento junto
a cada compositor e tome sua decisão final.
11.3 Trabalhando com um compositor
Provavelmente o designer de som é que trabalhará diretamente com o compo-

sitor. O produtor costuma ser envolvido como conselheiro e pode ter a pala-
vra final na aprovação das trilhas musicais concluídas do jogo. Ele é o respon-
sável final por aprovar os produtos e pagar o fornecedor.
Antes do compositor poder começar a trabalhar na música, terá de ter
uma ideia melhor do que trata o jogo. Portanto, envie para ele uma build
do jogo ou um trailer se não houver uma build disponível para reprodução.
Além disso, a arte conceitual, as descrições de personagens e o enredo tam-

bém podem ser úteis para transmitir a atmosfera do jogo. O compositor pode
examinar esses elementos, junto com o documento de visão musical, para
determinar os temas e a inspiração para o jogo.
Após o compositor receber esses elementos, poderá começar a esboçar
as trilhas musicais. Planeje várias rodadas de feedback entre o compositor e o
designer de som, antes de a música final ficar pronta. O compositor fornecerá
um esboço de mixagem da música inicial para o designer de som examinar e
ver se está no caminho certo. É aí que o processo de feedback começa.
O processo de feedback tem de ser definido antecipadamente para o tem-
po ser usado de maneira eficaz e o compositor não ficar esperando semanas
(ou meses) por feedback. É importante que todo o feedback seja comunicado
por escrito para as partes apropriadas. Se um feedback verbal for fornecido
via conferência por telefone, anote as conversas e envie-as por email para
assegurar que haja um registro por escrito.
Estabeleça prazos para quando o feedback será fornecido e quando será
implementado. Por exemplo, quando o compositor entregar amostras para
verificação, ele deve receber um feedback dentro de três dias. Se nenhum
feedback for fornecido, poderá assumir que tudo está correto e passar para a
próxima fase. Após o designer de som ter dado feedback, o compositor terá de
determinar quando o próximo conjunto de amostras com as sugestões incor-
poradas estarão prontas para verificação. Esse prazo é comunicado por escrito
para o designer de som.
Para concluir, quando alguém estiver dando feedback, certifique-se de
que esse seja útil e construtivo. Não é suficiente dizer “não gostei, mas não
sei a razão”, porque essa declaração não dá nada em que o compositor possa
trabalhar. Ele não saberá o que mudar para atendê-lo. Seja específico quanto
ao que não gostou, mesmo se achar tolo. Por exemplo, “Não gostei dos gritos
no fim da canção, são muito agudos e podem incomodar o jogador. Talvez
possamos reduzir o tom ou substituir por outra coisa”. Esse tipo de feedback
é muito mais fácil de manipular. Se possível, forneça códigos de tempo espe-
cíficos das áreas da música que estiver criticando.
É uma boa ideia lembrar gentilmente aos compositores sobre os prazos
de que dispõem, para que eles possam garantir a entrega a tempo. Eles po-
dem ficar muito absorvidos pelo trabalho e esquecer que seu prazo final é
em três dias. Dessa forma, você terá certeza de que terá tudo de que precisa
no momento certo.
11.4 Licenciando a música
Se estiver licenciando a música, decida em que bandas está interessado e co-

mece a contatar seus publicadores. Geralmente, os publicadores manipulam
todas as negociações de direitos musicais. Se for uma banda popular, essas
11 • Música 187
negociações podem demorar um pouco, portanto, comece o processo assim

que puder. Lembre-se de que se estiver licenciando a música, provavelmente
não poderá alterá-la.
O contrato pode limitar quantos minutos serão usados, o número de mixa-
gens que poderão ser feitas na trilha ou que outras bandas poderão aparecer no
jogo. Os direitos podem custar uma taxa fixa ou envolver um adiantamento re-
lativo aos royalties de cada cópia vendida do jogo. Talvez você também consiga
que a banda grave uma versão especial da canção ou até mesmo uma canção
original para ser usada no jogo.
Provavelmente o publicador do jogo também envolverá seu departamen-
to jurídico no processo. Dessa forma poderá ter certeza de que todos os direi-
tos apropriados serão levados em consideração no contrato. O contrato deve
definir claramente como a música poderá ser usada no jogo, como poderá ser
usada nos materiais de marketing e se poderá ser usada em demos ou trailers
do jogo. Também deve detalhar se a faixa poderá aparecer em uma trilha so-
nora do jogo, que é algo que está se tornando mais comum.
TRABALHANDO COM UM COMPOSITOR
Raymond Herrera
3volution Productions
Jogo desde os 10 anos e sempre quis combinar música e jogos. Comecei a 3volution
Productions junto com meu sócio, Laddie Ervin, para tornar isso realidade. Estamos
envolvidos em todos os aspectos de áudio e jogos: composição de música original, licen-
ciamento de música, voiceover e efeitos sonoros. Nossa experiência em jogos facilita o
trabalho com os desenvolvedores na determinação das necessidades musicais do jogo.
Em alguns casos, o desenvolvedor sabe exatamente o que é necessário – 15 canções por
uma quantia “X” em dinheiro. Em outros, ele está procurando alguma orientação sobre
que música deve incluir no jogo – música original, música licenciada e assim por diante.
O fator mais importante ao determinar as opções musicais de um jogo é o dinheiro
disponível e a quantidade de música desejada. Se houver necessidade de muita música e
o orçamento for limitado, o desenvolvedor pode remixar canções. Canções remixadas são
vantajosas para o jogo e a banda. A banda passa a ter um remix e trabalhou com pessoas
com quem nunca achou que trabalharia, e o jogo ganha uma trilha personalizada e a
possibilidade de usar o nome da banda, sem um preço mais alto. Os sons e o voiceover
do jogo podem ser usados na criação de remixes para realmente associá-los ao jogo. Por
exemplo, a 3volution usou os gritos da equipe e os sons de artilharia que o jogador ouve
no jogo para o tema de Rainbow Six: Lock Down.
Acredito que os videogames possam se beneficiar do uso de música da mesma
forma que os filmes fazem atualmente – selecione um hit que possa ser usado como
âncora e remixe-o ou licencie o original e inclua-o na campanha de marketing. Essa
canção poderá então ser o destaque em uma trilha sonora do jogo, junto com outras
músicas inspiradas nele.
Outra maneira de obter música de qualidade sem gastar muito dinheiro é formando
um supergrupo de músicos para trabalhar por alguns dias na criação e gravação de uma
canção que só exista no jogo. Por exemplo, para o jogo de WWE em que a 3volution tra-
balhou, tínhamos um supergrupo composto por mim na bateria, Shavo do System of a
Down no baixo, Wes do Limp Bizkit na guitarra, B-Real do Cypress Hill nos vocais e o DJ
Lethal como DJ. Em alguns casos, o departamento de marketing paga para que um vídeo
seja feito para a canção e apareça na MTV.
Para fazer a música ganhar maior impacto, gostamos de nos envolver com o jogo
na fase de pré-produção. Dessa forma, podemos encontrar maneiras criativas para os de-
senvolvedores aproveitarem ao máximo seus orçamentos. Por exemplo, se formarmos um
supergrupo para gravar uma canção, poderemos persuadir o departamento de marketing
a tirar o dinheiro necessário de seu orçamento. Ou seja, os desenvolvedores não terão de
investir uma grande quantia na música e ainda assim obterão uma canção exclusiva e de
alta qualidade para seu jogo. Além disso, se estivermos envolvidos desde o início, podere-
mos garantir a total integração entre música, voiceover e efeitos sonoros.
Quando começar a trabalhar em um jogo, converse com os desenvolvedores para
saber o que é necessário e qual é a atitude do jogo. Em seguida, converse com o pessoal
de marketing. Ao conversar com eles, deixe-os entusiasmados com toda a gama de pro-
moções associadas – trilhas sonoras do jogo, iTunes, bandas excursionando e mostrando
clipes do jogo, e vídeos musicais.
O processo começa com uma conferência por telefone entre a 3volution e todas as
partes interessadas. Quando as reuniões iniciais são concluídas, criamos um guia com
base nas discussões do tipo de música a ser gerada, dos formatos de arquivo e qualquer
outro detalhe importante do produto. Ele é enviado para todas as pessoas envolvidas
no processo – o publicador, o desenvolvedor, o departamento de marketing e assim por
diante. Esse guia é útil porque contém todas as pessoas responsáveis pelo que foi dito e
acordado. Depois disso, o feedback é manipulado via e-mail. Todos os envolvidos são
passados para a cadeia de e-mail para terem a chance de dar sua opinião. Os prazos das
etapas também são definidos e agendados com o desenvolvedor. Mais tempo significa
melhor qualidade.
A música é a última coisa que é trabalhada nos jogos. Esperamos que isso mude
porque ela pode ser muito importante para tornar o jogo mais eficaz e divertido de jogar.
11 • Música 189
Não é difícil usar música de maneira eficaz nos jogos digitais. Se você definir
suas necessidades musicais antecipadamente, poderá determinar se terá de
contratar um compositor para criar música original ou se licenciará a obra de
um músico (popular ou nem tanto). Este capítulo discutiu o que deve ser con-
siderado na definição das necessidades musicais, como preparar solicitações
de proposta para compositores, como trabalhar com compositores e alguns
fundamentos do licenciamento de músicas. Essas são as principais áreas com
as quais um produtor deve se preocupar ao incluir música no jogo.
12
CAPTURA DE MOVIMENTOS
Neste capítulo
• Planejando a captura • Preparando uma • Lista de verificação
de movimentos tomada de captura de da captura de
• Trabalhando com um movimentos movimentos
estúdio de captura de
movimentos
12.1 Introdução
Se você estiver trabalhando em um jogo em que os movimentos dos persona-

gens sejam muito nítidos para o jogador e importantes para a aparência geral
do jogo, considere o uso da captura de movimentos (motion capture) como
parte do processo de animação de personagens. Com a captura de movimen-
tos, movimentos reais de seres humanos, animais ou até objetos podem ser
gravados e implementados para a obtenção de um efeito mais realista e natu-
ral. Além disso, à medida que a tecnologia avança, os jogadores esperam ver
os personagens dos jogos se movendo e se comportando mais realisticamente.
A captura de movimentos deve ser planejada com bastante antecedência
para que os animadores tenham tempo de limpar os dados da captura e fazer
as animações funcionarem corretamente no jogo. Dependendo da quantida-
de de movimentos capturada e de animadores trabalhando no projeto, isso
pode levar vários meses de trabalho, mas o resultado vale o esforço. Se você
estiver planejando usar captura de movimentos, determine as necessidades
na pré-produção. Como em qualquer outro projeto, o planejamento e a orga-
nização são a chave do sucesso. Este capítulo apresentará uma visão geral, do
ponto de vista do produtor, de como planejar uma tomada de captura de mo-
vimentos. Para informações mais detalhadas sobre este tópico, consulte The
Animator’s Motion Capture Guide, de Matt Liverman.
12.2 Planejando a captura de movimentos
O artista líder e o animador têm um envolvimento muito grande no processo

de captura de movimentos (também chamada de motion capture ou mocap),
já que conhecem as necessidades de animação e são responsáveis por imple-
mentar as animações no jogo. O produtor trabalhará com eles para encontrar
um fornecedor e planejar a sessão.
Para começar, o animador terá de fazer uma lista mestra de todas as ani-
mações necessárias no jogo. Isso inclui como os personagens andam, correm,
apanham itens, seguram itens, se abaixam, se deitam, se viram e qualquer
outro movimento que será visto no jogo. O animador decide então quais ani-
mações pode criar a partir do zero e quais serão baseadas na captura de mo-
vimentos. As vantagens de se animar algo manualmente é que podemos criar
um movimento incomum que uma pessoa real na verdade não conseguiria
fazer. Também pode ser mais rápido criar uma animação de boa aparência a
partir do zero do que editar dados de captura de movimentos para obtenção
do mesmo efeito. A desvantagem de se animar algo a partir do zero é que os
movimentos podem não parecer muito naturais ou realistas, principalmente
se o personagem estiver executando uma atividade comum como caminhar.
Uma das maiores vantagens do uso da captura de movimentos é a cria-
ção desses movimentos realistas. Se uma pessoa real for gravada caminhando
de um lado para o outro da sala, várias pequenas características, como o modo
de andar, o movimento dos braços e o movimento da cabeça, serão difíceis de
incluir em uma animação criada a partir do zero. É claro que uma das desvan-
tagens da captura de movimentos é o custo. Pode ser caro capturar movimen-
tos para o jogo, principalmente se eles forem muitos.
PREPARANDO TOMADAS DE CAPTURA DE MOVIMENTOS

Activision
Na preparação da mocap, o mais importante é começar a se organizar cedo. Você terá

de contatar e visitar alguns estúdios de mocap não só para encontrar o melhor acordo
possível, mas também para verificar se a tecnologia atende às necessidades específicas de
seu projeto, se a personalidade da equipe de mocap combina com a da sua equipe e se
é possível encontrar um estúdio que tenha uma boa chance de continuar atuando nessa
12 • Captura de Movimentos 193
área a longo prazo. Pela minha experiência, o negócio de mocap é complicado e a última
coisa que você deseja é contratar uma empresa que feche suas portas quando seu projeto
estiver pela metade, deixando-o na mão.
Na análise de propostas concorrentes, é importante não só examinar os custos di-
retos, como o tempo de cena, a mídia descartável ou o custo de marcadores de mocap,
mas também prestar atenção no que às vezes podem ser custos ocultos. Um custo que
pode surgir depois, se não for negociado e explicado cuidadosamente, por exemplo, é o de
processamento de mocap. Se os custos de processamento de mocap forem especificados
para serem cobrados por segundo, você pode se ver em circunstâncias desagradáveis em
que acabará pagando 30 ou 100 dólares por segundos preciosos em que o ator está em
uma pose T ou em que a animação está começando e terminando. Se conseguir negociar
um acordo de cobrança pelo movimento, poderá poupar o estúdio de mocap e seus ani-
madores de terem de analisar cada segundo de uma tomada de captura de movimentos a
ser comprada e evitar a dor de cabeça de se preocupar com o resultado de cada segundo
de animação posteriormente.
Independentemente da maneira como o contrato for redigido, você precisará de
descrições detalhadas do que é um filme fácil, médio ou complexo. Uma tomada fácil
pode custar 15 dólares por segundo mas uma tomada complexa com várias pessoas pode
custar 100 dólares por segundo, e você não quer discutir com seu fornecedor depois sobre
a razão de um ciclo de caminhada ter sido classificado como complexo só porque seu
contrato não tinha detalhes suficientes.
Com relação ao agendamento, o tempo da sessão de mocap pode ser flexível, de-
pendendo do cronograma de sua equipe de animação. Esteja alerta para o fato de que,
no trabalho com um filme e no compartilhamento do tempo de atores ou de cena, uma
produção de Hollywood pode querer fazer a mocap antes ou depois do que você gostaria,
pressionando ainda mais sua equipe de animação para preparar a tomada no início do
cronograma ou fazer a mocap depois, forçando-a a se virar para trazer todas as anima-
ções para o jogo.
Requisitos da captura de movimentos

Se o artista líder e o animador decidirem que a captura de movimentos é ne-
cessária, terão de determinar o seguinte:
Como gerenciar assets: A captura de movimentos gera muitos assets,
portanto, o animador precisa ter um processo definido para o gerencia-
mento dos dados da captura de movimentos e sua conversão em um as-
set de animação a ser usado no jogo.
Convenção de nomenclatura de arquivos: Uma convenção de nomen-
clatura de arquivos é necessária para que o animador possa examinar o
nome do arquivo e saber qual é o movimento sem ter de abrir o arquivo.
A convenção de nomenclatura de arquivos deve ser estabelecida meses
antes para as informações poderem ser passadas para o fornecedor da
captura de movimentos.
Formatos de arquivo: Embora o jogo possa usar um formato de arquivo

proprietário para as animações, uma decisão deve ser tomada sobre que
formato de arquivo será necessário para os dados de captura de movi-
mentos que estão sendo gravados.
Lista de tomadas de captura de movimento

Após o animador determinar os requisitos de captura de movimento e ter uma
lista dos movimentos que devem ser capturados, ele os organizará em uma
lista mestra de tomadas. A Figura 12.1 é um exemplo de planilha básica de
mocap. Mais informações podem ser adicionadas, se necessário.
ID no Posição base Descrição do movimento Duração Personagem Nome do arquivo

1 De pé Caminhando (movimento padrão) 3 segundos Bullet Point bp_up_walk_1
NO SITE 2 De pé Caminhando (movimento padrão) 3 segundos Montezuma mz_up_walk_1
3 Abaixado Caminhada abaixado, ao investigar furtivamente 3 segundos Bullet Point bp_cr_walk_1
4 Abaixado Caminhada abaixado, ao investigar furtivamente 3 segundos Montezuma mz_cr_walk_1
Figura 12.1 Planilha básica de mocap.
A primeira coluna lista um número de identificação para a tomada, que

será uma referência importante durante a sessão de gravação de mocap. A
segunda coluna lista a posição base do personagem no início e no fim. Uma
posição base é necessária para o animador poder se alternar entre diferentes
animações sem os movimentos surgirem repentinamente durante as transi-
ções. A terceira coluna descreve o movimento a ser gravado. A quarta lista a
duração do movimento. O estúdio de captura também pode querer basear seu
pagamento na duração de cada movimento; logo, é importante incluir essa
informação. A quinta coluna lista o personagem do jogo que está fazendo esse
movimento. Isso é importante anotar para que o ator correto grave movimen-
tos para o personagem. A sexta coluna é o nome do arquivo.
Essa lista de tomadas é a planilha mestra de todos os movimentos a se-
rem capturados para o jogo. É recomendado que essa planilha seja mantida
sob o controle de versões para que não surjam várias versões. Assim, você não
irá para a gravação da captura de movimentos com a lista incorreta.
Cronograma
Como mencionado anteriormente, as sessões de captura de movimentos devem
ocorrer suficientemente cedo no projeto para o animador ter tempo de limpar
os dados e implementar a animação no jogo. A Figura 12.2 é uma visão geral
das principais tarefas que devem ser agendadas para a captura de movimento.
Esses períodos de tempo são baseados em um ciclo de desenvolvimento de dois
anos para um jogo com 500 movimentos feitos por um ou dois atores. Também
estamos supondo que o estúdio de captura de movimentos consiga capturar
100 movimentos usáveis por dia durante a sessão de gravação. Os tempos de
duração serão maiores se o jogo tiver mais movimentos e atores.

Lista inicial de captura de movimentos concluída Animador Cerca de 6-8 meses antes da versão beta
NO SITE Envio de solicitações de proposta para estúdio de Produtor Cerca de 12-14 meses antes da versão beta
captura de movimentos
Reserva de tempo para a tomada de captura de Produtor assim que você tiver escolhido um estúdio
movimentos
Teste com os atores Estúdio de captura
Cerca de 4-6 semanas antes da tomada de
de movimentos captura de movimentos (mais tempo no caso de
escalação de uma grande quantidade de atores).
Escalação de atores Animador/Produtor Cerca de 4-6 semanas antes da tomada de
captura de movimentos (mais tempo no caso de
escalação de uma grande quantidade de atores).
Lista final de tomadas de captura de movimentos Animador Cerca de 2 semanas antes da tomada de captura
concluída de movimento agendada
Captura de movimentos gravada Animador/Produtor Cerca de 6-8 meses antes da versão beta
(mais tempo no caso de gravação de uma
grande quantidade de movimentos ou de
movimentos complexos)
Movimentos processados e implementados no jogo Animador Cerca de 1 semana antes da versão beta
Figura 12.2 Tarefas gerais que devem ser agendadas para uma tomada de captura
de movimentos.
12.3 Trabalhando com um estúdio de captura de movimentos
Na escolha de um estúdio de captura de movimentos, é importante fazer estas

perguntas:
Qual o tempo de entrega dos produtos de animação? Você precisa en-
contrar um estúdio que faça as entregas rapidamente, para aproveitar ao
máximo seu tempo de produção. Se o tempo de entrega for mais longo
do que o previsto, mas você ainda quiser usá-los, inclua um tempo am-
plo no cronograma para isso.
Quantas horas são trabalhadas em um dia de gravação? Muitos estú-
dios de captura de movimentos planejam um dia de oito horas de grava-
ção e cobram pelas horas-extras quando a sessão ultrapassa esse patamar.
Qual é o processo de teste e escalação de atores? O estúdio de captura
de movimentos tem de ajudá-lo a encontrar atores para seu projeto. A
captura de movimento é um trabalho cansativo e você quer ter certeza de
que os atores estejam acostumados a isso.
Quais são as taxas? Alguns estúdios cobram por segundo e outros por
movimento. Movimentos simples envolvendo uma pessoa são muito
mais baratos do que movimentos complexos que requerem vários atores.
Que custos adicionais são cobrados? Há algum outro custo de alimen-
tação, acessórios, ou arranjos especiais?
Com que antecedência o tempo do estúdio pode ser reservado? Você
pode reservar o estúdio meses antes de ter a lista de tomadas final? Des-
cubra também se há penalidades pelo cancelamento de uma sessão re-
servada previamente. Se você cancelar com muita antecedência, talvez
não seja cobrado.
Solicitações de proposta
O envio de uma solicitação de proposta para diferentes fornecedores permi-
tirá que você compare custos e prazos. Embora um fornecedor possa ser um
pouco mais caro, talvez ele consiga redirecionar as animações para os mode-
los dos personagens. Tudo vai depender dos serviços de que você precisa e de
quanto pode gastar. Inclua os itens a seguir em uma solicitação de proposta:
• Quantos atores são necessários.

• Quantos movimentos requerem um único ator e quantos requerem vários
atores.
• Quantos movimentos serão capturados.
• Duração de cada movimento.
• Quantos movimentos precisam de edição.
• Quantos movimentos têm looping.
• Que acessórios são necessários (se houver algum).
• Prazos de entrega.
• Formato da entrega.
A Figura 12.3 é o exemplo de uma proposta de captura de movimentos

que inclui essas informações.
Formato de
Movimentos necessários no de movimentos Duração média Looping entrega de arquivos
NO SITE Movimentos de uma pessoa 600 movimentos 2 segundos Looping necessário Arquivos .trc ou .htr; têm
(masculino) para 500 movimentos de estar totalmente
processados e editados.
Movimentos de uma pessoa 600 movimentos 2 segundos Looping necessário Arquivos .trc ou .htr; têm
(feminino) para 500 movimentos de estar totalmente
Movimentos de duas pessoas 50 movimentos 5 segundos Sem looping Arquivos .trc ou .htr; têm
(masculino e feminino) de estar totalmente
Movimentos de duas pessoas 20 movimentos 5 segundos Sem looping Arquivos .trc ou .htr; têm
(masculino e feminino) de estar totalmente
Serviço Quantidade Notas
Atores necessários 1 homem, 2 mulheres Precisará de escalação e pré-produção
Acessórios Mesa, cadeira, bola de basquete, Usados para o movimento de uma única pessoa
rifle, pistola
Prazos Tomada inicial agendada para 27 Arquivos editados e processados a serem devol-
de outubro de 2008. vidos em lotes, com a entrega final ocorrendo
em 27 de novembro de 2008.
Figura 12.3 Exemplo de proposta de captura de movimentos.
12.4 Preparando uma tomada de captura de movimentos
Após ter selecionado um fornecedor, escalado atores e reservado tempo do es-

túdio, comece a preparação da tomada de captura de movimentos. Se estiver
planejando gravar 500 movimentos, a captura demorará cerca de cinco dias se

você estiver bem organizado. Antes da tomada, prepare o seguinte:
Lista final de tomadas de captura de movimentos: Classifique essa lista
por personagem e então por tipo de movimento. Por exemplo, primei-
ro você fará todas as animações de caminhada em pé de Bullet Point,
seguidas por animações com o personagem abaixado e, então, com ele
correndo. Um ator de captura de movimentos não deve trabalhar mais
de seis horas por dia, principalmente se for usado por mais de um dia.
Qualquer jornada além de seis horas cansará o ator e os movimentos dos
dias subsequentes não ficarão tão nítidos.
Cronogramas diários: Crie um cronograma de quando os atores serão
necessários diariamente e de que movimentos serão gravados. Envie esse
cronograma para todos os envolvidos na gravação para deixá-los a par
dos objetivos do dia.
Quando estiver pronto para a tomada de captura de movimentos, você
precisará do animador líder, do produtor (ou do produtor associado) e do dire-
tor de captura de movimentos. O animador e a direção de captura de movimen-
tos trabalharão junto aos atores para obter os movimentos desejados. O produ-
tor estará lá para fazer as coisas avançarem e as sessões seguirem o cronograma.
Se os atores não conhecerem um movimento, precisarão de algum tempo
para ensaiá-lo. Certifique-se de que o animador possa fornecer orientações
claras sobre o que está procurando; ele também deve estar preparado para
demonstrar o movimento quando necessário. O animador deve pensar em
exemplos do movimento com antecedência, para que não haja desperdício de
tempo durante a gravação enquanto ele pensa em uma maneira de descrever
o movimento para o ator.
Se necessário, várias tomadas podem ser feitas para um movimento. Ge-
ralmente, o estúdio de captura de movimentos não cobra por várias tomadas,
somente pelos movimentos finais que entrega. Portanto, no fim de cada dia
de gravação, o estúdio pedirá ao animador para examinar todas as tomadas
do dia e selecionar as que o agradam. O estúdio pode pedir que o animador
selecione as tomadas no decorrer do dia para seus editores poderem começar
a limpar os dados.
TRABALHANDO COM ATORES DE CAPTURA DE MOVIMENTOS

Activision
Ao procurar atores de mocap, você pode usar indicações ou simplesmente encontrar ato-
res pelos canais tradicionais de Hollywood. Em muitos casos, o estúdio de mocap tem
uma lista de atores que podem ser selecionados; portanto, use o fornecedor como recurso
se não souber como proceder. Após identificar o ator de mocap, não seria exagerado
levá-lo para um teste para verificar se seu estilo de movimentação combina com suas ne-
cessidades. Há muitos casos em que é possível negociar um dia de testes nas instalações
escolhidas para a mocap como última medida antes da assinatura de um contrato, logo,
esse também pode ser um bom dia para fazer seu teste com o ator.
Quando o dia da gravação chegar, provavelmente seu diretor de animação será a
pessoa mais indicada para dirigir o ator e obter os movimentos de que você precisa. No
caso de trabalho com uma produção hollywoodiana, não é raro atribuírem um diretor
para dirigir o ator principal, ainda mais se você estiver em um palco do sindicato. É sem-
pre uma boa ideia contratar um diretor assistente experiente de Hollywood para fazer o
dia render e manter as listas de chamada organizadas. Seu diretor principal estará preo-
cupado em obter as tomadas necessárias, será preciso ajudar com as outras responsabili-
dades de direção, tais como as planilhas de chamada para verificar se todos voltaram do
lanche a tempo.
12.5 Lista de verificação da captura de movimentos
Pode ser útil criar uma lista de verificação das tarefas que devem ser execu-
tadas na sessão de captura de movimentos. A Figura 12.4 é um exemplo que
pode ser usado.
Lista de verificação da captura de movimentos S/N Notas

Pré-produção
NO SITE O design inicial da lista de animações foi concluído?
As animações da captura de movimentos foram identificadas?
O cronograma inicial da captura de movimentos foi criado?
O orçamento inicial da captura de movimentos foi criado?
Solicitações de proposta foram enviadas para os estúdios de captura de movimentos?
Produção
O estúdio de captura de movimentos foi selecionado?
As datas foram reservadas provisoriamente com o estúdio de captura de movimentos?
A lista inicial de capturas de movimento foi preparada?
A lista de capturas de movimento foi definida?
O diretor foi reservado para a sessão?
Pós-produção
O estúdio de captura de movimentos editou as tomadas finais dos arquivos de animação?
Os arquivos foram entregues no formato correto? Versões descompactadas estão disponíveis?
Figura 12.4 Lista de verificação da captura de movimentos.

À medida que a tecnologia vai se aperfeiçoando, os personagens dos jogos

começam a parecer mais realistas e os movimentos contribuem muito para
isso. A captura de movimentos é algo que deve ser considerado se você qui-
ser movimentos naturais e realistas em seu jogo. Essa é a melhor maneira de
capturar todos os pequenos movimentos que ocorrem quando alguém está
caminhando, correndo, saltando ou apanhando algo. As tomadas de captura
de movimentos podem ser complexas, mas se você tiver um animador e um
artista líder experientes, o envolvimento do produtor será principalmente na
busca do fornecedor e na organização da gravação. Este capítulo discutiu o
que devemos procurar em um estúdio de captura de movimentos e como pre-
parar a gravação.
13
MARKETING E
RELAÇÕES PÚBLICAS
Neste capítulo
• Trabalhando com • Demonstrações • Lista de verificação de
o departamento de • Recursos de marketing recursos passíveis de
marketing • Builds do jogo entrega
• Embalagem
13.1 Introdução
A equipe de marketing, junto com os produtores do jogo, coordena a campa-

nha de marketing com sua data de lançamento. A missão da equipe é gerar
vendas do jogo pela propaganda, portanto, ela precisa de feedback da equi-
pe de desenvolvimento para assegurar que os recursos-chave do jogo sejam
transmitidos de maneira eficaz para o público. Porém, embora possa querer
simplesmente um jogo de alta qualidade e bem-sucedido, as solicitações de
recursos ou assets do departamento de marketing na última hora podem ge-
rar atritos com a equipe de desenvolvimento. Neste capítulo, discutiremos
maneiras de manter o relacionamento entre o departamento de marketing e a
equipe de desenvolvimento harmonioso.
13.2 Trabalhando com o departamento de marketing
É importante envolver o departamento de marketing cedo no processo de de-

senvolvimento, já que eles têm acesso a muitas informações sobre jogos con-
correntes, testes de foco e tendências da indústria. Durante o estágio de con-
ceituação, geralmente o gancho básico do jogo é definido e o departamento de
marketing costuma ter um feedback útil sobre ele.
Para facilitar a comunicação com o departamento de marketing, estabe-
leça um ponto único de contato na equipe de desenvolvimento cuja função
será trabalhar com eles. Se o departamento de marketing solicitar um código
de demonstração a um desenvolvedor, relatórios de status do código do jogo
a outro e conteúdos de manuais a um terceiro, a situação pode ficar confusa e
incômoda para a equipe de desenvolvimento. Divergências sobre os recursos
do produto podem gerar inimizades entre os fãs se informações erradas forem
disseminadas em entrevistas ou no site do jogo. Um canal de comunicação
sólido reduzirá o risco desses problemas ocorrerem.
A equipe de desenvolvimento terá de fornecer ao departamento de mar-
keting capturadas de tela (screen shots), demos, builds do jogo e texto de ma-
nuais. Por vezes, as solicitações da equipe de marketing podem parecer exces-
sivas, ainda mais se a equipe não souber antecipadamente o que esperar. No
entanto, se o contato da equipe de desenvolvimento estiver trabalhando junto
à equipe de marketing e puder agendar as solicitações de produtos, poderá
otimizar o processo, reduzindo a pressão sobre a equipe de desenvolvimento.
Cronograma das etapas do desenvolvimento

Antes de fazer solicitações, a equipe de marketing precisa conhecer o crono-
grama de desenvolvimento, para evitar solicitações de recursos durante datas
cruciais do processo. O contato do departamento de marketing terá informa-
ções sobre as principais etapas e poderá ajudar a equipe de marketing a esta-
belecer um cronograma, que deve incluir o seguinte:
• Alfa
• Beta
• Aprovação
• Liberação do código
• Data de lançamento
A Figura 13.1 é um cronograma com as principais etapas do desenvolvi-

mento e informações gerais dos prazos.
Documentação do jogo
O departamento de marketing precisará de informações sobre a história, os
personagens principais e os recursos do jogo para criar uma campanha pro-
mocional eficaz. Ele também terá de saber qual é o público-alvo do jogo e
ter informações sobre qualquer asset ou recurso disponível em diferentes
13 • Marketing e Relações Públicas 203
Etapa Prazo geral Data limite

Alfa Cerca de 6-8 meses antes da data de entrega 25 de março de 2009
Beta Cerca de 1-2 meses antes da data de entrega 15 de agosto de 2009
Aprovação do fabricante do console Cerca de 4-6 semanas antes da data de entrega 15 de setembro de 2009
Liberação do código Cerca de 2-4 semanas antes da data de entrega 1o de outubro de 2009
Entrega Data de entrega 15 de outubro de 2009
Figura 13.1 Principais etapas do desenvolvimento.
versões. O departamento de marketing pode solicitar que diferentes versões

do jogo apresentem conteúdo exclusivo da plataforma, como personagens
ou níveis. A equipe de desenvolvimento deve apresentar as informações a
seguir para o departamento de marketing:
Lista de recursos: Essa lista inclui os principais recursos, níveis, perso-
nagens e a mecânica do jogo. Também detalha qualquer elemento exclu-
sivo da plataforma.
História: A trama é resumida, junto com qualquer elemento da história
que afete a mecânica do jogo.
Esquema de controle: Essa informação dará à equipe de marketing uma
ideia de como é a navegação no mundo do jogo, que poderá ser transmi-
tida para o público em materiais de marketing.
Regras básicas de jogabilidade: Esses documentos delineiam a maneira
como o jogo funciona. A equipe de marketing precisa conhecer a mecâ-
nica do jogo ou não conseguirá transmiti-la para o público. Um breve
resumo pode ser mais eficaz do que documentos básicos de design, prin-
cipalmente se esses forem complicados ou longos.
Descrições dos personagens: Essas informações detalham a aparência,
a voz e a personalidade do personagem. Com frequência os personagens
são usados como parte da campanha de marketing do jogo, portanto, es-
ses documentos podem ser muito úteis. Se vozes de celebridades forem
usadas, elas devem ser incluídas aqui.
Trapaças e detonados: Para demonstrar o jogo para jornalistas e com-
pradores, a equipe de marketing precisará de trapaças e detonados (che-
ats and walkthroughs). Isso lhes permitirá finalizar o jogo de maneira
eficiente, mostrando seus principais recursos.
Grupos focais
Durante a fase de pré-produção, provavelmente o departamento de marke-
ting organizará um teste de foco do jogo. Isso resultará em feedback sobre os
conceitos, os recursos, a história ou os personagens do jogo. Geralmente, o
departamento de marketing trabalha com um fornecedor externo para prepa-
rar o teste de foco.
Quase sempre, os desenvolvedores acham útil receber feedback direto do

público-alvo, sobretudo quando o jogo em desenvolvimento representa uma mu-
dança maior na direção de uma franquia. Nesse caso, o produtor do jogo pode
transmitir perguntas específicas que a equipe de desenvolvimento deseja fazer
ao grupo de foco. Qualquer desenvolvedor que participar do teste de foco conhe-
cerá antecipadamente a reação do grupo a um recurso ou aspecto do jogo.
Quando não for possível fazer um teste de foco formal, os desenvolve-
dores podem optar por organizar um teste de foco informal por sua própria
conta. Nesse caso, é importante que os participantes assinem contratos de
confidencialidade (NDAs). Consulte o Capítulo 4, “Informações legais”, para
obter mais informações sobre NDAs.
Ao conduzir um teste de foco informal, estabeleça os objetivos de ma-
neira precisa com antecedência. Se os desenvolvedores estiverem esperando
algum feedback sobre a configuração de controle, verifique se a build é está-
vel, certifique-se de que haja hardware suficiente para todos os participantes
e estabeleça algum método para a coleta de informações sobre o teste, como
um questionário que os participantes tenham de preencher.
13.3 Embalagem
A equipe de marketing precisará de todos os recursos necessários para a cria-

ção da caixa, do manual e dos suplementos, e é função do desenvolvedor
fornecê-los. Os prazos desses produtos devem ser distribuídos no cronograma
de desenvolvimento, para que atrasos desnecessários sejam evitados (como
ser forçado a esperar o manual do usuário ser concluído). Empresas de desen-
volvimento menores terão de criar a embalagem e entregá-la para impressão,
mas normalmente estúdios maiores usam um departamento de serviços de
criação que produz toda a embalagem. Mesmo assim, o desenvolvedor terá de
fornecer os recursos necessários para essa equipe a tempo, como o texto do
manual, screen shots e a configuração do controlador.
Manuais
O produtor terá de trabalhar junto à equipe de marketing para assegurar a
criação bem-sucedida do manual do usuário. A equipe de desenvolvimento
é responsável por criar o rascunho final do texto do manual. Desde o início,
o produtor terá de estabelecer um prazo para a conclusão do rascunho final,
para dar à equipe de marketing tempo suficiente para a edição, organização,
revisão e impressão do manual antes da data de entrega do jogo. Para alcan-
çar essa data a tempo, o departamento de marketing pode pedir o rascunho
final do manual antes dos recursos do jogo terem sido implementados. Você
terá de fornecer as informações mais precisas que puder e manter a equipe de
marketing e o redator do manual atualizados sobre qualquer mudança feita
na jogabilidade.
Devido ao processo de localização, é provável que o departamento de

marketing internacional precise de uma cópia do manual original antes da
equipe do país. Para jogos de PC, normalmente o departamento de marke-
ting precisa do manual final cerca de seis a oito semanas antes da data de
entrega. Isso lhes dá tempo suficiente para a manipulação da impressão e
distribuição.
Para consoles, o cronograma é diferente, porque a embalagem precisa ser
aprovada pelo fabricante do console antes da replicação. Portanto, é impor-
tante trabalhar junto ao departamento de marketing para que todos os recur-
sos da embalagem sejam recebidos a tempo. Os jogos têm perdido suas datas
iniciais de entrega por atrasos na aprovação da embalagem. Para evitar isso,
certifique-se de verificar as datas de envio da embalagem com os gerentes de
contas dos seus parceiros.
No início do processo, você terá de estabelecer um método de atualiza-
ção e correção do texto do manual. Após a versão final ter sido enviada para
a equipe de marketing, questões cruciais serão descobertas, como cortes ou
acréscimos de recursos.
Uma maneira fácil de fornecer essas atualizações é passar um rascunho
do manual que esteja 95 a 99% pronto para o departamento de marketing na
data de vencimento solicitada, mas dar tempo no cronograma para outra ro-
dada de revisões e atualizações. Essas alterações devem ser agendadas o mais
tarde possível para que os desenvolvedores tenham o máximo de tempo para
ajustar o texto e acomodar qualquer alteração na jogabilidade. Certifique-se
de comunicar todas essas alterações para os membros da equipe responsáveis
pela versão traduzida do manual.
Ao discutir o manual com a equipe de marketing, descubra se há algum
limite de palavras e passe essa informação para o redator do manual. Em al-
guns casos, os manuais traduzidos têm uma quantidade máxima de palavras
que é menor do que o equivalente no idioma de origem, portanto, pode ser
necessário criar uma versão mais curta para eles. Caso contrário, o próprio
departamento de marketing internacional pode ter de editar o manual, o que
resultaria na omissão de informações importantes.
Com frequência, screen shots aparecem no manual para apresen-
tar elementos da IU para o usuário. Os manuais traduzidos vão demandar
screen shots traduzidas e localizadas. Você não precisará de screen shots da
build final para a versão traduzida; o importante é que as capturas sejam le-
gíveis e claras.
A equipe de marketing pode solicitar uma versão eletrônica do manual
para a versão gold master para PCs. Em jogos controlados por orçamento, por
exemplo, isso ajuda a economizar os custos de impressão do manual. Os ma-
nuais eletrônicos também são eficazes quando um jogo é entregue com vários
idiomas em um único disco ou quando é lançado como parte de um pacote.
Se um manual eletrônico for necessário para a versão gold master, cer-
tifique-se de que todos os envolvidos conheçam o prazo de envio do manual
eletrônico final para o departamento de marketing. A equipe de desenvol-
vimento pode usar um arquivo provisório com o manual até a versão final
ficar pronta.
Arte da caixa
Normalmente, o layout e a aparência final da caixa são criados pela equipe de
marketing. É mais fácil fornecer recursos para a caixa do que para o manual,
porque o departamento de marketing é que costuma redigir o texto da caixa.
O desenvolvedor precisa apenas revisar o texto, fornecendo correções ou su-
gestões quando necessário. Com frequência, ele só fornece screen shots para
a parte de trás da caixa. Como sempre, é importante estar a par dos prazos de
acondicionamento para versões de console, já que elas requerem a aprovação
de terceiros antes da impressão.
Cartões de referência do teclado

Os cartões de referência do teclado fornecem os comandos e o layout de jogos
de PC e são um produto separado ou um desdobramento da capa do manual.
Se seu projeto incluir um cartão de referência, ele deve ser considerado no
cronograma de desenvolvimento para que o departamento de QA tenha tem-
po de comparar a funcionalidade do jogo com as informações inseridas no
cartão. Um cartão de layout separado terá de ser criado e testado para cada
idioma adicional, portanto, fique alerta para layouts de teclados internacio-
nais ao criar esse produto.
13.4 Demonstrações
As demos são ferramentas de marketing que aumentam o entusiasmo por um

jogo, permitindo que os consumidores o joguem antes de comprá-lo. Você
pode fornecer demos para jogadores via Internet ou como um disco de ins-
talação. As demos podem ser criadas após a liberação do código do jogo,
mas às vezes é necessário criar uma demo durante a produção. Embora essa
situação esteja longe do ideal para a equipe de desenvolvimento, o lança-
mento de uma demo perto da data de entrega do jogo pode criar expectativa
e aumentar as vendas.
Planejando uma demonstração

Uma demo deve ser planejada com meses de antecedência. Mesmo se a equi-
pe de marketing decidir durante a fase de pré-produção que a demo não é
necessária, é bom planejar uma para o caso de precisar dela. Uma demo será
necessária em algum momento, seja para uma exposição, como um incentivo
a compras antecipadas do jogo ou como uma maneira de aumentar o interesse
do consumidor. O planejamento da demo não tem custo e você estará pronto
se lhe pedirem repentinamente para criar uma. Ele não precisa ser detalhado;
pode ser formulado durante a pré-produção e atualizado no decorrer do pro-
cesso de desenvolvimento. Deve incluir:
Conteúdo: Converse com a equipe de marketing para determinar o con-

teúdo específico da demo. Que níveis serão apresentados? Que persona-
gens serão manipulados? Que recursos serão demonstrados? O conteúdo
deve dar aos jogadores uma boa ideia do jogo, mas tem de deixá-los que-
rendo mais.
Cronograma preliminar da produção: Após o escopo da demo ter sido de-
terminado, a equipe poderá começar a trabalhar em assets e recursos especí-
ficos. Se um determinado nível for incluído na demo, primeiro ele deve ser
construído e polido. Todos esses detalhes devem ser considerados no cro-
nograma de produção para que os recursos da demo possam ser planejados
com antecedência. Se um recurso for cortado, você poderá atualizar o cro-
nograma da demo quando estiver atualizando o cronograma de produção.
Cronograma de testes: O departamento de QA poderá reservar um tem-
po para o teste da demo se souber com bastante antecedência quando ela
ficará pronta. Pode ser necessário tirar alguns testadores do jogo para tes-
tarem a demo, principalmente se ela estiver sendo produzida enquanto o
jogo ainda estiver em desenvolvimento. O departamento de QA também
pode contratar mais pessoas durante esse período para assegurar que
haja testadores suficientes para dar conta dos dois projetos.
Prazos básicos para o lançamento em revistas: O ideal é que a equipe
de marketing receba a demo antes do lançamento do jogo. Se a demo
for lançada em um disco de revista, haverá prazos específicos para cada
edição. A impressão das revistas pode demorar e uma demo completa
pode ser necessária com meses de antecedência. Por exemplo, se a demo
for encartada em uma edição de outubro da revista, os desenvolvedores
terão de enviar a versão final em julho.
Diretrizes técnicas: Se a demo for incluída em um disco de revista, pode
ter de seguir certas diretrizes técnicas, como um limite para o tamanho do
arquivo. Se for um jogo de console, terá de funcionar com o iniciador de
demos da revista. É importante entrar em contato com a equipe da revista
para coletar as informações necessárias antes de enviar a demo para eles.
Na improvável possibilidade da equipe de marketing decidir que o jogo
não precisa de uma demo, esse plano pode ser usado na criação de uma ver-
são polida e consistente do jogo, que poderá então ser apresentada em eventos
para imprensa, conferências e exposições.
Demos de console
Se a equipe estiver criando uma demo de console, fatores adicionais devem
ser considerados:
Versões PAL e NTSC são necessárias? Na criação de uma demo de con-
sole para o mercado internacional, versões PAL e NTSC podem ser ne-
cessárias. Se for esse o caso, certifique-se de que o jogo possa ser jogado
nos dois modos.
A demo tem de ser enviada para terceiros para aprovação? As demos

de console precisam ser enviadas para terceiros para aprovação antes do
lançamento. O tempo de aprovação pode variar, dependendo de quantos
títulos o publicador estiver tentando aprovar. É bom dar duas semanas
para a aprovação de demos por terceiros. Isso inclui o tempo de reenvio
de uma demo, para o caso de um problema ser descoberto durante o pri-
meiro envio.
A demo atende os requisitos técnicos? Há requisitos técnicos específi-
cos para demos da Sony, Microsoft e Nintendo. Verifique as especifica-
ções com seu gerente de contas de terceiros.
Se você programar os itens anteriormente citados, isso ajudará a otimizar
seu processo de desenvolvimento. Certifique-se de que todos os membros de
sua equipe conheçam o prazo de conclusão da demo e mantenha um crono-
grama detalhado que considere o desenvolvimento, os testes e o envio.
Demos localizadas
Se uma demo localizada estiver em desenvolvimento, há vários outros fatores
a serem considerados:
Quantos idiomas terá a demo? Se a demo for traduzida e localiza-
da, você terá de distribuir no cronograma a organização de recursos, o
processo de tradução, a integração de texto traduzido e a fase de testes.
Essas tarefas levarão algumas semanas. Os profissionais de marketing
devem informar à equipe com antecedência sobre os idiomas de que pre-
cisarão na demo. Se o tempo for curto, descubra se uma versão somente
no idioma original será suficiente. A produção de uma demo localizada
no meio do projeto pode ter um impacto negativo sobre o cronograma de
desenvolvimento, já que envolve o trabalho de vários desenvolvedores.
A demo será multilíngue? Se for, o atraso em um idioma pode colocar os
outros em risco. Certifique-se de agendar cuidadosamente a tradução, a
integração e o teste de cada idioma para que todos os recursos traduzidos
sejam integrados ao mesmo tempo.
Como a seleção de idiomas será manipulada? Se você estiver criando
uma demo multilíngue, sua equipe terá de saber como a demo seleciona-
rá o idioma a ser exibido. Essa seleção do idioma pode ser armazenada
em um arquivo de configuração para que seja lembrada na próxima vez
que a demo for iniciada.
13.5 Recursos de marketing
O departamento de marketing também precisa de outros recursos da equipe

de desenvolvimento, como arte de alta resolução e filmagem da mecânica do
jogo. A fim de preparar a distribuição desses recursos, trabalhe com a equipe

de marketing para estabelecer um cronograma durante a fase de pré-produ-
ção. Alguns desses recursos adicionais são:
• Screen shots – da ação in-game com alta resolução.
• Filmagem da jogabilidade – usada na criação de trailers e comerciais do
jogo.
• Arte de alta resolução – arte que possa ser usada como pôsteres ou capas
de revista.
13.6 Builds do jogo
Durante o ciclo de desenvolvimento, a equipe de marketing precisará de

builds* do jogo para mostrar a jornalistas, varejistas e possíveis clientes para
gerar expectativa e comentários em torno do jogo. A imprensa e os varejistas
saberão que estão olhando um jogo em desenvolvimento, portanto, não vão
esperar uma versão polida antes do lançamento. Sempre que as builds forem
disponibilizadas, certifique-se de incluir um documento que detalhe recur-
sos, bugs, instruções de instalação e qualquer outra informação pertinente. Já
que os membros da equipe de desenvolvimento não terão como demonstrar o
jogo para todos os possíveis compradores e jornalistas, é bom incluir qualquer
instrução ou advertência relativa à demo. O documento deve ser fácil de ler e
deve fornecer informações de contato para o caso de assistência ser necessá-
ria. A demo deve ser acompanhada por um resumo detalhando como o jogo
pode ser demonstrado da melhor forma possível.
Você deve considerar marcar as builds que forem enviadas para fora
da equipe de desenvolvimento. Isso demanda a atribuição de um marcador
exclusivo a cada build que for distribuída fora da equipe. Será mantida en-
tão uma lista mestra de todas as builds marcadas e dos destinatários dessas
builds. Se uma build vazar na Internet, o marcador exclusivo poderá ser usa-
do na determinação da build que vazou. Programas de software comerciais e
soluções proprietárias estão disponíveis para a marcação de software.
Outras builds que a equipe de marketing pode solicitar são builds para
feiras, para pré-estreias e sob demanda, como as que permitem a captura da
filmagem da jogabilidade.
Trabalhando com o departamento de relações públicas

O departamento de relações públicas (RP) é responsável por intermediar o
contato com membros da mídia para criar publicidade para o jogo. Os mem-
bros da equipe de RP marcam entrevistas e press tours e aconselham a equipe
de desenvolvimento sobre os elementos básicos do jogo que devem ser divul-
gados.
* N. de R.T.: Uma build é uma versão compilada e executável do jogo.

Press tours
As press tours são um método de promoção para títulos de alto nível. Con-
firme as datas das press tours o mais cedo possível no processo de desenvol-
vimento, principalmente se estiver trabalhando em um título de alto nível.
Certifique-se de que o cronograma seja montado de acordo com os prazos da
equipe de desenvolvimento; não é aconselhável que os desenvolvedores via-
jem durante etapas cruciais do processo.
Antes da press tour, verifique se os desenvolvedores que foram convi-
dados para viagens de divulgação internacionais estão levando passaportes
válidos, para evitar atrasos. Planeje também com antecedência a build que
será exibida durante a press tour. Como no caso das builds para exposições,
algumas partes do jogo serão mostradas, mas o acesso a outras será restrito.
Se os desenvolvedores estiverem ocupados demais para uma press tour,
a equipe de marketing pode trazer um pequeno grupo de jornalistas para vi-
sitar o estúdio de desenvolvimento. A apresentação e a participação no jogo
podem ser acompanhadas por representantes do departamento de RP do pu-
blicador do jogo ajudando a equipe de desenvolvimento.
Entrevistas
Durante o processo de desenvolvimento do jogo, jornalistas conduzirão entre-
vistas com vários membros da equipe de desenvolvimento. A maioria delas
pode ser feita por e-mail e não precisa de um planejamento antecipado. No
entanto, é importante observar o prazo das entrevistas por e-mail. Para entre-
vistas com jornalistas internacionais, é preciso alocar tempo para a tradução
antes da publicação.
Diários dos desenvolvedores

Os diários dos desenvolvedores são criados pela equipe de desenvolvimento
para ajudar os departamentos de RP e marketing. Eles são escritos pelos de-
senvolvedores e descrevem o trabalho que está sendo feito no jogo. Normal-
mente, há um espaço dedicado no site do jogo onde os diários dos desenvol-
vedores são postados e atualizados.
Exposições
As exposições são uma ferramenta poderosa para a geração de publicidade
para um jogo. Em exposições maiores, os desenvolvedores têm de estar pre-
sentes e demonstrar o jogo. Esse é um grande chamariz para jornalistas, que
gostam de falar diretamente com membros da equipe de desenvolvimento
sobre o jogo e seus principais recursos.
Se os desenvolvedores forem demonstrar o jogo em uma exposição, é
bom praticarem na frente de um grupo de pessoas para não parecerem em-
baraçados ou confusos se forem interrompidos ou questionados. Eles devem
conhecer os recursos principais do jogo, o que inclui os presentes na demo e
aqueles que estarão disponíveis na versão final.
Nome do produto Data estimada Notas

NO SITE Localizações: francês, alemão, espanhol, italiano
Produção
Primeira versão jogável consulte o cronograma de produção
Alfa consulte o cronograma de produção
Congelamento do código consulte o cronograma de produção
Beta consulte o cronograma de produção
Envio para pré-certificação da Microsoft consulte o cronograma de produção
Candidato à liberação do código consulte o cronograma de produção
Envio para certificação da Microsoft consulte o cronograma de produção
Data de entrega (todas as plataformas, todas as linguagens) consulte o cronograma de produção
Caixa e documentos
Primeiro rascunho do manual Cerca de 10 semanas antes do envio ou da
data de entrega para o país
Cerca de 6-8 semanas antes do envio ou da
Primeiro rascunho do manual com screen shots data de entrega para o país
Layout da caixa e do manual para aprovação Cerca de 4-6 semanas antes do envio ou da
do desenvolvedor data de entrega para o país
Recursos de marketing
Build da demo Varia, o marketing pode querer que a demo
seja entregue alguns meses antes ou na
mesma época do jogo.
Primeira demonstração do código para jornalistas Cerca de 3-4 meses antes da data de entrega
Nova demonstração do código para jornalistas Assim que a versão nacional tiver o código
liberado ou aprovado
Cronograma de etapas de produção Cerca de 8-10 meses antes da data de entrega
Resumo do design Cerca de 8-10 meses antes da data de entrega
Lista de recursos Cerca de 8-10 meses antes da data de entrega
Recursos do jogo para o site (som, arte) Cerca de 6-8 meses antes da data de entrega
Esboços conceituais do jogo Cerca de 6-8 meses antes da data de entrega
Imagens de alta resolução (para capas de revistas) Cerca de 6-8 meses antes da data de entrega,
varia conforme a necessidade
Filmagem da jogabilidade (para trailers) Cerca de 4-6 meses antes da data de entrega
Códigos de trapaça e detonados Cerca de 4-6 meses antes da data de entrega
Screen shots Entregas semanais, determine a quantidade
com antecedência
Entrevistas com desenvolvedores Varia, dependendo da necessidade
Press tour nacional Varia, mas pode ocorrer perto da versão beta
Press tour internacional Varia, mas pode ocorrer perto da versão beta
Figura 13.2 Exemplo de lista de verificação de entrega de recursos.
13.7 Lista de verificação de recursos passíveis de entrega
A Figura 13.2 mostra um exemplo de lista de verificação de recursos pron-

tos. A primeira coluna mostra o recurso, a segunda indica a data de entrega
e a terceira fornece um prazo geral de quando o recurso será necessário. Al-
guns projetos têm um cronograma de desenvolvimento acelerado, ou seja, os
produtos também têm um cronograma acelerado. Dependendo do escopo da
campanha de RP e marketing, um projeto pode ter um cronograma de entrega
de recursos muito mais longo. Esse cronograma fornece uma visão geral dos
tipos de recursos que costumam ser solicitados e das estimativas de tempo
para fins de planejamento.
Como produtor do jogo, é crucial que você gerencie o relacionamento entre

o departamento de marketing e a equipe de desenvolvimento para assegurar
que trabalhem juntos harmoniosamente. Enquanto os desenvolvedores estive-
rem trabalhando no jogo, o cronograma terá de incluir os principais produtos
de marketing. A publicidade do jogo será afetada se recursos úteis não forem
fornecidos para a equipe de marketing a tempo. Neste capítulo, examinamos
os tipos de recursos que o departamento de marketing precisa, assim como os
prazos em que normalmente esses recursos são necessários.
Parte V
PRÉ-PRODUÇÃO
A pré-produção é a primeira fase do desenvolvimento de jogos, e talvez seja

a mais crítica. Durante a pré-produção, os objetivos do jogo são definidos e
acordados pela equipe, a gerência e o publicador. No fim da pré-produção, um pla-
no completo é criado para o jogo, detalhando o trabalho que precisa ser feito, quem
vai fazê-lo e quando precisa ser concluído.
Esta seção do livro enfocará as principais tarefas que devem ser concluídas du-
rante a pré-produção. Serão apresentadas informações sobre a definição e aprovação
do conceito, a análise de risco, a prototipagem, a criação de orçamentos e cronogra-
mas, e planos de formação de equipes. Os tópicos são os seguintes:
• Definindo um conceito
• Análise de risco
• Definindo requisitos do jogo
• Cronogramas
• Orçamentos
14
CONCEITO DO JOGO
Neste capítulo
• Início do processo • Protótipo • Lançamento do
• Definição do conceito • Análise de risco projeto
• Venda da ideia
14.1 Introdução
A pré-produção começa com a definição do conceito do jogo. Afinal, você

não pode começar a trabalhar em um jogo antes de ter uma ideia de qual será
seu objetivo e qual será a aparência final do jogo quando ele for concluído.
O conceito inicial começa com uma ideia ampla – por exemplo, como seria
disputar uma corrida com carros conceituais – e então mais detalhes são adi-
cionados para estreitar o conceito e criar uma visão do jogo. Elementos como
a plataforma de hardware, o gênero e os principais recursos são definidos,
junto com mais detalhes sobre como será o mundo do jogo, os designs dos
personagens e a jogabilidade. Após tudo isso ser definido, qualquer pessoa
que for apresentada às informações tem de conseguir entender os objetivos do
conceito do jogo.
Raramente o produtor determina sozinho o conceito inicial e o design
geral do jogo, exceto quando está patrocinando uma equipe de desenvolvi-
mento de jogos e tem a palavra final sobre todas as decisões de design do
jogo. Na verdade, o design do jogo é uma tarefa colaborativa e o principal
papel do produtor é gerenciar o processo de desenvolvimento e assegurar
que todos os elementos-chave do design sejam manipulados. Geralmente,
um designer líder ou um diretor de criação gerencia o processo criativo para
assegurar que todos os elementos do jogo deem suporte ao conceito inicial.
216 Parte V • Pré-produção
Em alguns casos, se você tentar gerenciar o processo tanto de criação quanto

de produção, pode se ver diante de um dilema quando tiver uma ideia para
um recurso arrojado, mas tiver de cortá-lo por razões de produção. Além
disso, se assumir algumas das responsabilidades do designer líder sem defi-
nir rigorosamente isso em seu papel como produtor, os outros membros da
equipe – principalmente o designer líder – podem ficar frustrados por não
entenderem por que você tem autoridade criativa sobre o projeto.
É claro que há casos em que o produtor também é o líder principal de
criação, e essa pode ser uma boa maneira de estruturar uma equipe, contanto
que todos entendam o que o seu papel como produtor-diretor representa. O
segredo é definir as responsabilidades gerenciais de criação e produção cla-
ramente no projeto para as pessoas terem certeza de que as duas áreas estão
sendo tratadas com destreza no ciclo de desenvolvimento do jogo. Após os
papéis serem claramente definidos para as tarefas de pré-produção, você po-
derá começar a trabalhar no conceito do jogo.
Lembre-se de que quando uma equipe colabora em um projeto criativo,
as pessoas nunca ficam 100% de acordo. Se você gastar seu tempo tentan-
do fazer todo mundo concordar com os detalhes do jogo, pouco progresso
será feito. As pessoas podem passar muito tempo discordando das decisões
e, assim, nenhuma decisão final será tomada. Se elas não concordarem com a
maneira como um determinado elemento funciona no jogo, não perca tempo
tentando convencê-las de que a ideia é boa. Em vez disso, aproveite o tempo
prototipando a ideia, obtenha algum feedback real sobre o fator diversão da
jogabilidade e faça ajustes ou altere a funcionalidade com base nessas infor-
mações.
Este capítulo apresentará uma visão geral dos elementos do jogo que
são definidos na fase conceitual. Para demonstrar alguns dos pontos-chave, o
exemplo de um jogo será usado em todo o capítulo e em capítulos subsequen-
tes que discutem o processo de desenvolvimento do jogo.
14.2 Início do processo
No começo do processo de desenvolvimento do jogo, provavelmente a equi-

pe será composta por um produtor, o designer líder, o programador líder e o
artista líder. Essa equipe básica é responsável por pegar um conceito e trans-
formá-lo no design de um jogo. Isso significa determinar o conceito, a plata-
forma, o gênero, a mecânica do jogo, os designs dos personagens e qualquer
outro elemento-chave do jogo.
Se você estiver trabalhando para uma empresa de desenvolvimento do
publicador, provavelmente este atribuirá à sua equipe os jogos específicos
em que ela deve trabalhar, o que inclui a plataforma, o gênero e o conceito
inicial. Com essas informações básicas, a equipe principal terá de definir
todos os outros elementos do jogo. Se você estiver trabalhando para uma de-
senvolvedora independente, sua equipe principal virá com o conceito inicial
14 • Conceito do Jogo 217
e o esmiuçará. Independentemente de onde o conceito inicial teve origem,

ainda haverá muito trabalho de criação para a equipe fazer.
O trabalho no conceito inicial não deve demorar mais do que algumas
semanas. Se você demorar mais do que isso, perderá um tempo valioso da
pré-produção e o entusiasmo criativo que pode ter crescido na equipe pela
excitação de trabalhar em um novo projeto. Uma das primeiras coisas que
demandará a participação da equipe será uma sessão de brainstorm.
Usando o brainstorm
As sessões de brainstorm são uma oportunidade de envolver a equipe na dis-
cussão de várias ideias sobre o jogo. Você pode fazer um brainstorm sobre o
conceito inicial do jogo, a jogabilidade básica, o ambiente do jogo ou a aparên-
cia dos personagens. Sessões de brainstorm bem gerenciadas também são um
ótimo exercício de construção de equipes porque permitem que todos deem
suas opiniões sobre o que torna um jogo divertido. A equipe principal é que
participa da sessão de brainstorm, mas, se quiser, abra-a para outras pessoas
do estúdio; depende do volume de ideias que quiser gerar nas sessões.
Antes de organizar uma sessão de brainstorm, familiarize-se com as dire-
trizes de como gerenciá-la de maneira eficiente. Se a sessão não for gerencia-
da apropriadamente, não gerará informações úteis e os participantes podem
ficar frustrados com a experiência. Algumas reclamações comuns de uma ses-
são de brainstorm malsucedida são as seguintes:
• A sessão perdeu o foco e não forneceu informações úteis.

• As ideias dos participantes não foram ouvidas.
• Não surgiu nenhuma ideia nova.
• Os participantes se sentiram usados quando viram que as decisões finais
não tinham relação com as sugestões iniciais.
Esses erros podem ser evitados se algumas diretrizes forem seguidas na

preparação e condução da sessão. Prepare-se para a sessão antecipadamente:
Defina claramente a finalidade da sessão: Se a finalidade for pensar em
nomes para o personagem principal do jogo, certifique-se de que todos
os envolvidos na sessão saibam disso. Defina também quem presidirá a
sessão e quem tomará notas.
Envolva o grupo certo de pessoas na sessão: Em alguns casos, não é
útil envolver 50 pessoas. Você pode precisar de várias sessões meno-
res sobre diferentes tópicos ou ser seletivo sobre quem será convidado.
Por exemplo, se estiver discutindo os recursos gráficos que devem ser
incluídos no jogo, precisará de mais artistas e programadores e menos
designers.
Peça a todos os envolvidos que se preparem para a sessão com antece-
dência: Informe as pessoas sobre o tópico que será discutido para que elas
possam fazer alguma pesquisa preliminar. Elas podem querer saber o que
os concorrentes fizeram, que tecnologias estão disponíveis ou desenvolver

algumas ideias. Dessa forma, todos já estarão pensando sobre o tópico antes
da sessão, o que tornará o tempo gasto no brainstorm mais produtivo.
Durante a sessão, estabeleça um conjunto de normas a serem seguidas. A
finalidade dessas normas é criar um ambiente em que as pessoas se sintam à
vontade para dar suas ideias. Algumas normas básicas são as seguintes:
Não critique ninguém ou nenhuma ideia durante a sessão: Quando al-
guém der uma ideia, não a descarte de imediato. O objetivo da sessão é
gerar informações, não eliminá-las.
Não comece a discutir uma ideia durante a sessão: Escreva cada ideia
no quadro e então passe para a próxima. A sessão perderá rapidamente o
foco se as pessoas começarem a discutir uma única ideia e você perderá
a oportunidade de ouvir outras ideias ótimas.
Quando as ideias pararem de fluir, esteja preparado para gerar mais: Se
as pessoas começarem a ficar sem ideias na sessão, examine as já geradas e
desenvolva-as ou prepare algumas perguntas provocativas para fazer e ge-
rar discussão novamente. Por exemplo, o que nossos concorrentes fazem
que não estamos fazendo? Como podemos evitar o problema de _____?
Após as ideias serem geradas, passe algum tempo com a equipe agrupan-
do-as em ideias afins e então priorize-as. Partindo disso, gere um relatório dos
resultados da sessão de brainstorm e adicione-o às notas da reunião. As ideias
de prioridade mais alta serão atribuídas a pessoas específicas para que deem
prosseguimento e pesquisem. Seja muito claro sobre os itens de ação gerados
em cada sessão de brainstorm e inclua-os nas notas da reunião. Se você não
der prosseguimento a nenhuma das ideias geradas, as pessoas sentirão que
sua participação foi uma perda de tempo. Alguns dos tópicos a serem discuti-
dos poderiam ser o gênero, a plataforma e o conceito inicial do jogo.
Agende a sessão de brainstorm como uma das primeiras tarefas da pré-
-produção para poder ouvir as ideias de todos abertamente. Tente ter o má-
ximo possível de sessões de brainstorm feitas e documentadas na primeira
semana do projeto. Quanto mais você adiar a sessão de brainstorm, mais de-
morará para determinar o conceito inicial do jogo. O ideal é que cada sessão
de brainstorm seja gerenciada por alguém que tenha uma postura neutra sobre
o tópico abordado. Dessa forma, sua atenção poderá ser dedicada à condução
eficaz da sessão e à tomada de notas. Após cada sessão terminar, publique as
notas dentro de 24 horas. Além disso, cada item de ação gerado deve ser con-
cluído pela pessoa designada em não mais do que alguns dias.
Conceito inicial
O conceito inicial pode ser gerado por qualquer um – o publicador, o produ-
tor, o designer líder ou qualquer outro membro da equipe. Não precisa ser de-
talhado, mas tem de apresentar um objetivo interessante para o jogo alcançar.
Às vezes é chamado de gancho do jogo. Esse gancho fornece a base de todas
as decisões do jogo e é algo que o departamento de marketing pode comunicar

facilmente para o público-alvo quando chega a hora.
Geralmente os conceitos iniciais começam como uma pergunta a ser res-
pondida – e se existissem zumbis vivendo no espaço? E se os animais tives-
sem humanos de estimação? Após o conceito inicial ser determinado, são
tomadas decisões que moldam qual será a aparência da versão final do jogo.
Aqui está um exemplo de conceito inicial para um jogo chamado Unida-
de de Justiça: um grupo de desajustados poderia se reunir como a Unidade de
Justiça e salvar o mundo de supervilões?
Gênero
Gênero é o tipo de jogo, como luta, RPG (role-playing game) ou tiro em pri-
meira pessoa (first person shooter – FPS). Ao categorizar os jogos em gêneros,
os desenvolvedores e publicadores conseguem visualizar melhor a mecânica
do jogo. Por exemplo, o gênero FPS envolve uma perspectiva em primeira
pessoa em que o jogador atira em elementos do mundo do jogo e fica posicio-
nado atrás da arma, vendo somente sua arma e a mão de seu avatar. Doom e
Half-life são exemplos clássicos de jogos de atiradores em primeira pessoa.
Outros gêneros de jogos são os de combate, esportes, simulações, representa-
ção de papéis, estratégia e atiradores em terceira pessoa.
O gênero afeta o design do jogo. Aqui está uma demonstração de como o
gênero molda o jogo, usando a Unidade de Justiça como exemplo:
Jogo de combate: Se Unidade de Justiça fosse um jogo de combate para
dois jogadores, poderia apresentar uma lista de super-heróis e vilões a
serem selecionados. Os impulsionadores de vendas seriam personagens
desbloqueáveis, os movimentos combinados e possivelmente a associa-
ção com uma propriedade licenciada, como um herói de quadrinhos
existente.
Estratégia em tempo real: Como um RTS (real-time strategy), o jogo
apresentaria um exército de super-heróis lutando contra ondas de inva-
sores alienígenas.
Jogo de interpretação de personagens: Como um RPG (role playing game)
em primeira pessoa, o jogador assumiria o papel de um personagem, lutan-
do contra o mal em um universo de super-heróis com vilões mascarados e
combatentes do crime.
Em algum momento durante a fase conceitual, o gênero do jogo será
definido. O designer pode combinar vários gêneros, aperfeiçoar um gênero
existente ou até mesmo tentar criar um novo gênero. Ideias sobre o gênero
também são discutidas na sessão de brainstorm.
Plataforma
A plataforma é o hardware que será usado no jogo, como um PC, o Micro-
soft Xbox 360, o Nintendo DS ou um telefone celular. A diferença entre as
plataformas, como as configurações do controlador e as limitações técnicas,

influenciam o design do jogo. Por exemplo, um jogo projetado para telefone
celular não apresentará elementos gráficos ou tecnologia de ponta. Os jogos
de celulares são menos complexos e mais fáceis de finalizar quando o jogador
só tem alguns minutos disponíveis. Um jogo de PC apresenta elementos grá-
ficos de ponta e um esquema controlador mais complexo. A experiência de
jogar exige uma disponibilidade de tempo muito maior.
Quando o jogo for lançado em várias plataformas, considere os elemen-
tos de design que funcionam melhor em cada uma e personalize o design de
acordo. Em consoles, os jogadores esperam um jogo apropriado à plataforma
que escolheram, em vez de um jogo projetado para PC e portado para um
Xbox 360, e vice-versa. Aqui está um exemplo de como o design de Unidade
de Justiça mudaria para diferentes plataformas:
PC: Uma versão de Unidade de Justiça baseada em PC apresentaria a ca-
pacidade de personalização como um recurso primário, permitindo que
o jogador criasse novos inimigos, mapas e tipos de missão.
Nintendo DS: Como um jogo DS, Unidade de Justiça seria um FPS sim-
ples e fácil de aprender com um layout semelhante ao de Metroid Prime.
O jogador progrediria por vários níveis, combatendo ladrões de banco e
supervilões.
Xbox 360: Como um jogo Xbox 360, Unidade de Justiça é um título
de ação explosivo apresentando rápidas sequências de ação e ambiente
multijogador baseado em equipes. Os principais impulsionadores de
vendas seriam a perspectiva imersiva em primeira pessoa, vários mo-
dos multijogador e uma campanha de jogador único direcionada por
uma história.
Análise SWOT
Uma análise SWOT, que é a abreviação de Strengths, Weaknesses, Opportu-
nities e Threats (Pontos Fortes, Pontos Fracos, Oportunidades e Ameaças),
identifica os pontos fortes e fracos do conceito do jogo, as oportunidades de
mercado e qualquer ameaça que possa afetar o sucesso do jogo.
Comece uma análise SWOT identificando um jogo que seja um possí-
vel concorrente. Pode ser um jogo de gênero semelhante ou com recursos de
jogabilidade parecidos, um jogo que seja interessante para seu público-alvo
ou um jogo baseado em licenças semelhantes. Após ter determinado quem é
o concorrente, analise os pontos fortes e fracos. Use essas informações para
comparar os pontos fortes e fracos de seu jogo com os do concorrente. Quando
conseguir definir claramente quais são os pontos fortes e fracos de seu jogo,
será fácil descobrir maneiras de explorar ou neutralizá-los, conforme o caso.
Essas informações contribuem para a criação de um design sólido e fornecem
a base da estratégia de marketing do jogo.
Os pontos fortes e fracos são influências internas sobre as quais temos
algum controle. As ameaças e oportunidades identificam influências exter-
nas que afetam o projeto e fogem ao controle. Por exemplo, seu jogo poderia
ser um lançamento para uma nova plataforma – um ponto forte, já que você
poderia optar por desenvolver para outra plataforma. Isso também é uma
oportunidade porque o fabricante do console promoverá o jogo junto à pla-
taforma do novo console. Inversamente, se você estiver trabalhando em um
MMO que não ofereça nenhum recurso exclusivo que o diferencie de World
of Warcraft, esse é um ponto fraco, já que você tem algum controle sobre
o conteúdo e o conjunto de recursos do jogo. No entanto, se estiver traba-
lhando em um MMO que se passe em um ambiente exclusivo, mas que seja
lançado no mesmo dia do lançamento de um pacote de expansão de World of
Warcraft, essa é uma ameaça porque você não tem controle sobre as datas de
lançamento dos outros jogos.
Aqui está uma lista de tópicos que você deve considerar ao fazer sua
análise SWOT:
pontos fortes oportunidades

• Recursos básicos • Tendências da indústria ou do es-
• Recursos inovadores tilo de vida
• Recursos do jogador • Inovações técnicas
• Impulsionadores de vendas exclu- • Tendências do mercado
sivos (USPs, unique selling points) • Pontos fracos da concorrência
• Valores de produção • Globalização
• Vinculação a licenciamento • Mercado-alvo
• Preços satisfatórios • Nichos de mercado-alvo
• Apelo popular • Parcerias
• Apelo internacional • Tendências de middleware
• Potencial para entrada de receitas • Datas de lançamento
• Recursos de marketing
• Vinculação a franquia ameaças
• Potencial de integração a console
• Influências políticas
• Potencial multiplataforma
• Pontos fortes da concorrência
• Experiência da equipe
• Datas de lançamento da concor-
rência
pontos fracos
• Demanda cautelosa no mercado
• Falta de experiência da equipe • Perda da equipe principal
• Falta de recursos competitivos • Perda de patrocínio
• Nenhuma inovação • Inovações técnicas
• Escolha da plataforma
• Empresa pouco conhecida
• Questões financeiras
• Cronograma e prazos
• Disponibilidade de recursos
• Falta de entusiasmo na equipe
• Liderança fraca
A Figura 14.1 é um formulário que pode ser usado para a condução de

uma análise SWOT. Na execução da análise, é igualmente importante defi-
nir como serão explorados os pontos fortes e as oportunidades e como serão
neutralizados os pontos fracos e as ameaças. A análise SWOT passará a fazer
parte do planejamento do jogo e será atualizada no decorrer da produção.
A análise SWOT deve ser concluída durante as primeiras semanas da
pré-produção para que todos os membros da equipe tenham conhecimento
pleno da concorrência e dos desafios, já que isso afetará a seleção do conjunto
de recursos e da estratégia de desenvolvimento do jogo. Designe uma pessoa
para conduzir essa análise, como um produtor associado, ou até mesmo o
produtor principal. Essa pessoa terá de obter informações com a equipe de
desenvolvimento e o departamento de marketing.
Análise SWOT
O principal concorrente de Unidade de Justiça é PostMortal, um FPS que se passa em um universo de super-heróis.
NO SITE Fatores internos Fatores externos
Nossos pontos fortes Como explorar Nossas oportunidades Como explorar
Comparado com o rival PostMor- Enfatizar esses Unidade de Justiça será lança- A promoção conjunta do jogo e
tal, Unidade de Justiça apresenta recursos no plano do na mesma época da se- do filme cria uma história separa-
uma forte experiência multijoga- de marketing. quência cinematográfica, o da para o jogo que tem ligação
dor, incluindo um avatar multijo- que também chamará atenção com algumas tramas importantes
gador personalizável, jogabilidade para o jogo. do filme.
variada e muitos mapas.
Nossos pontos fracos Como neutralizar Nossas ameaças Como neutralizar

Unidade de Justiça apresenta uma Deixe esse recurso PostMortal foi agendado para Espalhe cedo a notícia de o
experiência de jogador único, não de lado no plano lançamento 2 meses antes de participante poder jogar como seu
linear e de passeio livre que não de marketing e Unidade de Justiça e isso pode personagem favorito da Unidade
suscitará as mesmas emoções de ressalte os recursos ter um impacto negativo sobre de Justiça . Patrocine a criação de
PostMortal, que é linear e segue multijogador. as vendas – as pessoas podem uma competição entre inimigos, em
rigidamente o roteiro. comprar o jogo de super-heróis que o vencedor ganhe um encontro
PostMortal em vez de Unidade com o elenco do filme e uma cópia
de Justiça . antecipada do jogo.
Figura 14.1 Formulário de análise SWOT.
Análise competitiva
Além de uma análise SWOT, também é recomendável a condução de uma
análise competitiva completa da concorrência atual e futura. Essa análise
competitiva será particularmente importante se você estiver expondo um jogo
para um publicador. Ao apresentar uma análise competitiva como parte de
sua exposição, você estará demonstrando que conhece o mercado e sabe como
diferenciar seu jogo dos outros.
A análise competitiva contém algumas informações que são semelhantes
às da análise SWOT. Por exemplo, ela realça os pontos fortes e fracos do jogo
concorrente. Além disso, essa análise lista outras informações pertinentes,
como estatísticas de vendas (se disponíveis), pontuação média da crítica e
qualquer recurso-chave que faça o jogo se diferenciar dos outros. Todas essas
informações ajudam a dar uma ideia melhor da força da concorrência e o que
Data de Estatís-
Desen- Plata- Crítica
Jogo Publicador lançamento Resumo do jogo Recursos ticas de
NO SITE
volvedor formas média
estimada vendas
PostMortal Funtime A-1 Xbox360, Outubro PostMortal é uma nova -Avenger Boy é o persona- n/a n/a
Studios Publishing PS3 de 2009 IP sobre super-heróis. É gem principal do jogador.
um jogo de -Novo IP que não tem
ação-aventura em apelo diversificado.
terceira pessoa e o -Modos multijogador
jogador assume o limitados, mas terá uma
papel de Avenger Boy. pequena campanha de
Outros super-heróis cooperação on-line.
estarão no jogo, mas o -Ação-aventura tradicio-
jogador só controla um nal em terceira pessoa;
herói. O jogo a exclusividade está nos
apresenta super-heróis cenários e personagens.
vestidos tradicional- -Cada personagem tem
mente em um cenário um superpoder exclusivo
de 1950. Avenger Boy para usar contra o inimi-
se junta a outros heróis go. Ele auxiliará no jogo
para combater o Dr. se sua ajuda for solici-
No Good. tada pelo jogador.
Figura 14.2 Exemplo de planilha de análise competitiva.
é preciso para fazer o jogo parecer melhor. A Figura 14.2 é um exemplo de

planilha de análise competitiva.
Aprovação
Após as informações conceituais básicas serem definidas e uma análise
SWOT ser conduzida, elabore um resumo e apresente-o para todas as partes
interessadas para aprovação. Se o publicador gostar do rumo tomado, talvez
faça algumas sugestões menores e deixe você continuar o trabalho. No entan-
to, se o conceito estiver se desviando do que o publicador previu, ele pode
solicitar alterações maiores e pedir que você faça uma nova apresentação. Se
estiver trabalhando em um ciclo de desenvolvimento de dois anos, planeje
essa reunião de aprovação inicial para cerca de duas ou três semanas após o
início da pré-produção. Se estiver trabalhando em um projeto de seis meses,
tente fazer essa reunião cerca de uma semana após o início da pré-produção.
Obter aprovação nesse estágio é importante, já que pode lhe poupar tra-
balho. Se você prosseguir definindo o conceito e redigindo documentos de
design, pode acabar descobrindo que sua equipe passou meses reunindo todas
essas informações sem que elas sejam o que o publicador ou a gerência do es-
túdio tinha em mente. E como eles estão pagando a conta de desenvolvimento
do jogo, é melhor assegurar que a equipe entregue o tipo de jogo desejado.
Marque uma reunião com todos os stakeholders e apresente as informa-
ções que você tem até agora. Envolva outros membros-chave da equipe nessa
reunião para que eles respondam perguntas e ouçam o feedback em primeira
mão. Certifique-se de tomar notas precisas na reunião, enviá-las para a equipe
examinar e dar continuidade a qualquer item de ação.
RESTRIÇÕES DO DESIGN

Ubisoft
Devemos tomar muito cuidado na criação de um conceito e do design inicial para não
pensar nos recursos e no conteúdo. Você tem de definir sobre o que é seu jogo e não quantos
níveis ou armas existem e qual é a munição alternativa. Tem de saber sobre o que é seu jogo
nos aspectos mais gerais e poder representar isso com algum tipo de diagrama de sistema
simples. Você não precisa saber sobre o que ele é em termos de história, nem de sistemas. O
conceito tem de ser bonito e elegante, porque é a base do jogo inteiro. Quando você tiver
certeza de que seu conceito geral é forte, poderá começar a pensar na mecânica e na dinâ-
mica que darão suporte a ele. Os recursos e o conteúdo devem então fluir naturalmente
a partir da mecânica e da dinâmica. Se agir assim, não deve ter problemas para limitar o
conteúdo e os recursos a um conjunto significativo. Ideias são moleza, a harmonia entre
elas é que é difícil de atingir. Se você começar com um conjunto aleatório de boas ideias
e tentar construir um conceito de baixo para cima, não terá um todo harmonioso. Se co-
meçar com uma visão do todo e então reforçá-la robustamente com os sistemas que ela
requer, provavelmente não terá de se preocupar com limitações de tempo ou recursos.
Em Chaos Theory, trabalhei muito próximo do gerente de marketing para conhecer
as necessidades do público e transmitir sua visão do jogo. Uma síntese decisiva de ideias
ocorreu daí. O conceito de Chaos Theory – de ações pequenas tendo repercussões poten-
cialmente grandes –, assim como o sistema Mais Perto do Que Nunca do jogo e os sistemas
que os suportam, surgiu de longas discussões entre as equipes de design e marketing
(e outras). Tudo veio tanto da necessidade de haver sistemas expressivos, unificados e
robustos quanto da necessidade de diferenciar o título dos da concorrência e reforçar a
franquia e a marca onde ela era fraca. Os elementos de marketing do jogo são conceitos
como tensão, liberdade, qualidade cinemática e opções significativas. Eles vêm dessa
colaboração inicial entre marketing e design. Algumas pessoas percebem isso e dizem
que sou um designer direcionado pelo marketing e que os designers que projetam para
o mercado apenas reciclam designs consagrados, sem fazer nada novo. Essas pessoas
comparam os elementos mencionados anteriormente com os padrões “20 armas dife-
rentes”, “corridas de três jogadores” ou “cinco mundos alienígenas diferentes”. O design
tem de trabalhar junto ao marketing, mesmo que seja somente para assegurar que essa
equipe saiba exatamente do que trata o jogo para poder transmitir isso e ajudar a criar
a necessidade de jogos mais significativos e menos derivativos.
14.3 Defina o conceito
Após os stakeholders terem aprovado o direcionamento inicial do conceito,

a equipe principal continuará definindo-o. Durante essa fase, a equipe co-
meça a detalhar mais a mecânica, o ambiente, os personagens, o enredo e os
principais recursos do jogo. Limitações técnicas devem ser consideradas va-

gamente, mas não censure nenhuma ideia sobre limitações percebidas nesse
momento. Em vez disso, enfoque a criação e a prototipagem de um jogo diver-
tido. Quando esses elementos estiverem prontos para verificação, os progra-
madores poderão avaliar integralmente as limitações técnicas. Embora talvez
eles não possam implementar o que foi originalmente projetado, conseguirão
entender qual era o objetivo e descobrir maneiras alternativas de atingi-lo
dentro das restrições técnicas.
Durante a fase de definição do conceito, o designer líder e o artista líder
devem gerar vários produtos. O mais provável é que eles mesmos criem esses
produtos, principalmente se não houver outros recursos disponíveis. Os tipos
de informações definidas durante essa fase são os seguintes:
• Declaração da missão
• Cenário do jogo
• Mecânica do jogo
• Sinopse da história
• Arte conceitual
• Elementos de áudio
Em um ciclo de desenvolvimento de dois anos, planeje passar cerca de

um a dois meses definindo o conceito inicial. Em um ciclo de seis meses, pro-
grame passar aproximadamente de uma a duas semanas nisso.
Declaração da missão
A declaração da missão define os objetivos principais do projeto. Jim Lewis,
autor de Project Planning Scheduling and Control, acha que uma declaração
de missão deve responder essas duas perguntas:
• O que vai ser feito?

• Para quem está sendo feito?
Se você não conseguir responder claramente essas perguntas, será difícil

formular uma declaração de missão que transmita concisamente a essência
do jogo. Boas declarações de missão agem como o ponto de referência de
todas as ideias consideradas para o jogo. Se a ideia melhorar a declaração de
missão, deve ser um bom acréscimo ao jogo. Se for contra algum aspecto da
declaração de missão, não deve fazer parte da versão final do jogo. Após uma
declaração de missão ser definida, divulgue-a publicamente para a equipe, a
gerência do estúdio e o publicador.
Envolva a equipe principal em uma sessão de brainstorm para determi-
nar qual é a declaração da missão. Passem algumas horas discutindo e tentem
finalizar a declaração da missão até o dia seguinte. Após ela ser determinada,
cada membro da equipe terá uma ideia melhor da direção a tomar para gerar
seu produto da pré-produção.
Por exemplo, a declaração da missão de Unidade de Justiça é:

Unidade de Justiça é um jogo de super-heróis do mercado de massa com
controles otimizados. Foi planejado para fãs de quadrinhos e filmes de super-
-heróis que queiram viver as aventuras favoritas de seus heróis.
Cenário do jogo
O cenário influencia a aparência do jogo, como o ambiente, os objetos, a lo-
calização, os designs dos personagens e qualquer outro elemento que faça
parte do universo do jogo. O jogo pode ter cenários de ficção científica (Halo),
do mundo real (Ghost Recon 2), de fantasia (série Final Fantasy) e históricos
(Call of Duty).
O designer líder terá algumas ideias sobre os cenários que funcionam
bem com o conceito inicial e deve trabalhar com o artista líder para deter-
minar a aparência do cenário. Ele vai redigir uma descrição do cenário e o
artista líder criará a arte conceitual para mostrar sua aparência. Isso pode
demorar alguns dias ou semanas para terminar, dependendo dos outros as-
sets que esses recursos também estiverem gerando. O cenário pode evoluir
com base em outras decisões tomadas sobre a história, os personagens e a
mecânica do jogo.
O cenário de Unidade de Justiça é o seguinte:
O jogo se passa em um mundo clássico de vilões cruéis e assassinos
armados. A equipe do jogador é composta por heróis excêntricos com super-
poderes. Em um universo cheio de heróis e vilões impassíveis, a Unidade de
Justiça é um grupo de desajustados bizarros com estranhos poderes e perso-
nalidades excêntricas. Unidade de Justiça é parte paródia e parte tributo às
superequipes clássicas dos anos sessenta, complementado por histórias de
origem improvável e vilões poderosos.
Mecânica do jogo
A mecânica do jogo abrange várias das ações que o jogador executa ou vi-
vencia no jogo. É composta por grande parte da documentação de design à
medida que a funcionalidade dos diferentes sistemas de jogabilidade é deta-
lhada. Alguns dos sistemas que se encaixam nessa categoria são os seguintes:
• Desafios para o jogador (como chefes e enigmas de nível final)

• Recompensas do jogador (como pontos, armas extras ou itens especiais)
• Curva de aprendizado (com que rapidez o jogador conseguirá aprender
os fundamentos e começará a ter uma experiência divertida?)
• Esquema de controle (como o jogador usará o controlador ou o teclado?)
• Ações do jogador (como correr, saltar e jogar feitiços)
• Elementos multijogador
Essa relação não lista todos os sistemas que devem estar presentes em
qualquer jogo, mas é um bom ponto de partida para a determinação das áreas
do jogo que precisam de mais detalhes. Os sistemas são definidos antes da

exposição do jogo para o publicador.
O designer líder é quem assume a criação de grande parte da documenta-
ção de design. Ele trabalha com os outros líderes e o produtor para assegurar
que todos os elementos necessários sejam definidos e funcionem com o con-
ceito aprovado. Nesse estágio da produção, os documentos descreverão uma
visão de como cada sistema de jogabilidade poderia funcionar, sem fornecer
detalhes minuciosos. Os requisitos de funcionalidade serão desenvolvidos
após a mecânica geral do jogo ser aprovada. No trabalho em um ciclo de de-
senvolvimento de dois anos, a produção desses documentos de jogabilidade
pode demandar do designer líder de duas a quatro semanas.
Por exemplo, os elementos da mecânica multijogador de Unidade de Jus-
tiça são:
Unidade de Justiça apresenta dois modos multijogador. Em Justificativa,
duas equipes de até oito jogadores (16 no total) lutam uma contra a outra em
batalhas direcionadas por objetivos. Em Defesa, até 16 jogadores podem jogar
independentemente em lutas de vale-tudo.
Sinopse da história
A história está se tornando cada vez mais importante nos jogos. Além dos
jogadores quererem uma experiência de jogo atraente, eles também estão in-
teressados em uma história interessante. Uma boa história é a diferença entre
um bom e um ótimo jogo, porque ajuda o jogador a entrar ainda mais no mun-
do do jogo. Os detalhes da história não precisam ser totalmente definidos na
fase conceitual; isso é algo em que o redator pode trabalhar enquanto o desig-
ner finaliza os documentos de design. No entanto, a sinopse deve apresentar
um enredo que integre o cenário, a mecânica e os personagens do jogo em
uma experiência de entretenimento coesa para o jogador.
A sinopse da história de Unidade de Justiça é a seguinte:
O executivo de marketing Mark Ferrier desenvolveu poderes surpreen-
dentes ao ser atingido por um raio durante uma apresentação. Inicialmente,
os manteve em segredo, mas após testemunhar a Unidade de Justiça em uma
batalha intensa com o desprezível Wire Hanger, se uniu a ela em sua defesa.
A Unidade recrutou Ferrier, que escolheu o nome Bullet Point. Junto com
Montezuma, Rainha do Gelo, Major Malfunction e Caribou, ele combate o
crime e aqueles que o cometem.
Arte conceitual
Como diz o ditado, uma imagem vale por mil palavras. A arte conceitual
mostra a aparência dos elementos visuais do jogo antes de qualquer asset
artístico ser produzido. Ela pode ser apreciada por qualquer pessoa, do ge-
rente do estúdio aos membros da equipe, e já que todos estarão olhando a
mesma coisa, é uma ferramenta útil para transmitir a visão do jogo. Qualquer
equipe principal de pré-produção deve incluir um artista conceitual para

começar a projetar algumas das ideias da equipe. O artista conceitual traba-
lhará principalmente com o artista líder e o designer líder na aparência dos
personagens e nos níveis e objetos do jogo. É preciso que haja um processo
definido, gerenciado pelo artista líder, para a equipe dar feedback. O artista
conceitual pode levar várias semanas para produzir, dependendo do volume
a ser gerado e do nível de detalhes.
ARTE CONCEITUAL

Pandemic Studios
No passado, as equipes de desenvolvimento de jogos não eram muito grandes e a tecno-

logia era um fator que limitava a criação de mundos com aparência realista. Agora que as
equipes ficaram maiores e podemos criar mundos imensos e realistas, os desenvolvedores
de jogos adotaram um paradigma de arte conceitual que é derivado da indústria cinema-
tográfica – conceituamos todos os assets antes de criá-los para o jogo.
As principais razões para a arte conceitual ser importante e ter cada vez mais desta-
que na criação de assets para tecnologia de próxima geração são as seguintes:
• Ajuda a visão artística a ser mantida durante todo o caminho que leva aos assets
finais que aparecerão no jogo.
• Os artistas podem trabalhar e retrabalhar os assets em papel, onde o custo é muito
mais baixo, e só criar os assets reais quando todos concordarem com o que entrará
no jogo.
• A terceirização de assets artísticos se tornará mais comum à medida que o volu-
me de assets necessários para títulos de próxima geração aumentar; portanto, uma
arte conceitual claramente definida assegurará que os assets tenham uma aparência
consistente com o jogo, independentemente de onde foram criados.
Elementos de áudio
O áudio é uma parte crucial do jogo, já que ajuda na ambientação do mes-
mo. Pense na série de jogos Silent Hill – eles seriam tão assustadores se você
jogasse com som e música desligados? O designer líder pode trabalhar com
um designer de som por alguns dias para elaborar um plano inicial para o
voiceover, os efeitos sonoros e a música. O designer de som dará sugestões
sobre os elementos de áudio que funcionam melhor com o cenário, a história
e a mecânica de jogo propostos.
A visão geral do áudio responde a perguntas como as seguintes:
• Cada personagem terá uma voz exclusiva?

• Como as pistas de voz dos personagens funcionarão no jogo (por exem-

plo, como ajuda para o jogador, alívio cômico ou desenvolvimento do
personagem)?
• Que tipos de música funcionarão melhor com o jogo (canções heavy me-
tal licenciadas, uma partitura original orquestrada ou música instrumen-
tal eletrônica)?
• Em que partes do jogo a música será tocada (por exemplo, só no shell da
IU ou em tempo real na mecânica do jogo durante batalhas climáticas)?
• Que tipos de efeitos sonoros funcionarão melhor no jogo?
14.4 Protótipo
A prototipagem é um componente-chave do desenvolvimento de jogos, prin-

cipalmente durante a fase de pré-produção. Ela dá à equipe várias oportuni-
dades de validar novos recursos da jogabilidade e qualquer outra coisa que
não esteja bem definida (por exemplo, o pipeline de uma ferramenta). No
desenvolvimento de jogos, um protótipo é uma versão inicial jogável de uma
mecânica ou ideia proposta para o jogo. O protótipo não tem necessariamente
de ser jogável na forma digital; em alguns casos, a jogabilidade pode ser pro-
totipada com jogos de tabuleiro existentes, um baralho ou uma imitação com
caneta e papel – geralmente chamados de protótipos de “baixa fidelidade”.
Não é sempre que esses tipos de protótipos contêm elementos jogáveis e dinâ-
micos. Protótipos de alta fidelidade acabarão sendo criados. Eles costumam
ser baseados em software e fornecem um modelo dinâmico e funcional do
sistema proposto e uma melhor representação da experiência de jogar. No
entanto, podemos identificar e resolver muitos problemas em protótipos de
baixa fidelidade antes de passar para um de alta fidelidade.
Vários objetivos podem ser atingidos durante a prototipagem. Protótipos
exploratórios são usados na investigação de novas ideias, na identificação de
requisitos ou na busca de novas alternativas. Protótipos experimentais são
usados na validação de requisitos do sistema (como as estatísticas de arma-
mentos que funcionam melhor para balancear as armas do jogo). Esses dois
tipos de protótipos devem gerar trabalho que será descartado durante o pro-
cesso, mas isso não deve ser visto como perda de tempo ou dinheiro. Embo-
ra grande parte desse trabalho prototipado talvez não seja usada, as lições
aprendidas sobre os pontos fortes e fracos dos conceitos valem o esforço. A
prototipagem também pode levar a outras ideias a serem implementadas na
versão final do jogo. Se houver alguma relutância quanto ao tempo gasto em
trabalho que será descartado, protótipos operacionais podem ser usados. Eles
são compostos por um protótipo inicial que é refinado em iterações, até se
tornar uma versão funcional final entregue com o jogo.
Outra coisa que devemos considerar antes de começar um protótipo
(principalmente um baseado em software) são os objetivos primários e o
público-alvo. Por exemplo, o protótipo demonstrará uma fatia vertical da
jogabilidade? Isso requer a implementação de elementos que forneçam um
exemplo representativo da experiência de jogabilidade final. Abrange a me-

cânica principal do jogo com o balanceamento apropriado, assets artísticos
polidos (inclusive a IU, modelos dos personagens principais e um nível jo-
gável), assets de áudio característicos e demonstrações-chave de inovações
na tecnologia (por exemplo, jogabilidade baseada na física). Um protótipo
vertical é fortemente recomendado na exposição de um jogo para um publi-
cador.
O protótipo enfocará um recurso específico e só será visto por membros
da equipe de desenvolvimento? Por exemplo, o programador líder está traba-
lhando em um protótipo do novo sistema de animação para resolver gargalos
no pipeline de engenharia e arte? Esse tipo de protótipo não precisa do mes-
mo nível de detalhe e polidez; pode ser montado com assets provisórios e
conter problemas funcionais que possam ser resolvidos depois.
Embora o processo de prototipagem possa ser superficialmente cate-
gorizado em fases, essas fases podem não ter um início e um fim distintos,
principalmente durante a iteração. Normalmente, o processo começa com a
definição do que está sendo prototipado. Em seguida, um protótipo de baixa
fidelidade é criado, com base nesses requisitos iniciais. A equipe fará itera-
ções nesse protótipo. A iteração envolve um ciclo de especificação dos re-
quisitos, o design de algo que os atenda, avaliação dos resultados e início
do ciclo novamente. Podem ocorrer várias iterações no mesmo protótipo; a
quantidade costuma depender do tempo disponível no cronograma.
Uma vez que a equipe estiver satisfeita com os resultados, pode decidir
que o recurso ou ideia não é viável e descartar o protótipo, pode ter uma nova
ideia que queira prototipar ou pode decidir passar para a próxima fase de
criação de um protótipo de alta fidelidade. Esse protótipo também passará
por algumas iterações até a equipe ficar satisfeita com os resultados. Quando
isso ocorrer, as especificações do protótipo serão congeladas e uma versão
final será construída com elas.
A prototipagem pode ocorrer em qualquer fase do ciclo de desenvolvi-
mento, e a equipe deve tentar prototipar o máximo possível. Cronogramas e
prazos apertados podem impedir um alto nível de prototipagem perto do fim
da fase de produção, portanto, tente tirar vantagem dos blocos de tempo não
agendados que ocorrem na pré-produção. É melhor passar um dia ou dois (ou
até uma semana) prototipando recursos-chave do jogo do que passar várias
semanas implementando um recurso que acabe não funcionando como espe-
rado. Se isso ocorrer, haverá pouco tempo no cronograma de desenvolvimen-
to para o ajuste ou a recriação do recurso e o jogo pode acabar sendo entregue
com o recurso da maneira que se encontra. É comum a manipulação de vários
protótipos ao mesmo tempo – alguns protótipos podem ser mais complicados
(como uma fatia vertical do jogo), enquanto outros podem ser mais simples.
Não deixe de prototipar, principalmente se houver tempo no cronograma. A
fase de prototipagem é contínua durante a pré-produção e é conduzida pelo
designer líder ou, possivelmente, pelo produtor.
CRIANDO PROTÓTIPOS
Tracy Fullerton
Uma das coisas mais importantes que o protótipo de um jogo fornece é a possibilidade
de conhecermos imediatamente a experiência do jogador. Um protótipo também torna
a ideia tangível e, portanto, cria algo que é muito mais fácil para os membros da equipe
explicarem e manipularem a partir de seu próprio ponto de vista. Na maioria das vezes,
as pessoas tendem a discordar quando estão sendo teóricas, logo, você verá designers e
programadores discordando; mas eles podem estar falando a mesma coisa, só que, como
não têm um protótipo ou algo concreto para referenciar, nem mesmo percebem.
Confio fortemente na prototipagem em papel e não gosto que os alunos redijam es-
pecificações do jogo até terem algum tipo de protótipo. No momento em que temos uma
ideia, podemos começar a modelar a mecânica básica e as estruturas subjacentes. Esses
primeiros modelos em papel – e talvez você tenha de construir dois ou três para conhecer
todos os sistemas – serão usados na construção de protótipos digitais. Depois que esses
são criados, as pessoas podem começar a definir especificações.
Um design realmente inovador vem de perguntas ousadas e impertinentes e de dedi-
carmos pequenos períodos de tempo e dinheiro verificando se essas perguntas fornecerão
respostas interessantes e provocadoras. A prototipagem em papel é algo que um designer
dedicado pode fazer dentro do tempo alocado para ele. Geralmente um designer conse-
gue finalizar um protótipo, recrutar testadores de jogabilidade e fazer alterações, tudo
em um curto período de tempo. É um método experimental fantástico para fazermos esse
tipo de perguntas interessantes. Por exemplo, neste exato momento estou trabalhando em
um jogo em que a questão central que estamos tentando entender é “como criar um jogo
sobre a jornada de iluminação espiritual?”.
É muito importante que a equipe de tecnologia faça parte da equipe de criação;
mas é igualmente importante que a tecnologia não seja o fio condutor do design da ex-
periência. Isso significa que o designer tem de conhecer e respeitar os limites técnicos da
plataforma com a qual está trabalhando, mas criativamente ele não precisa viver dentro
desses limites da mesma forma que os tecnólogos. Os designers têm de conhecer as limi-
tações técnicas suficientemente bem para contorná-las ou usá-las como trampolim para
algum tipo de virada criativa que não restrinja o jogo, mas torne-o melhor. Uma das
melhores maneiras de se fazer isso é pedir que os tecnólogos joguem os protótipos em
papel. Novamente, quando a ideia é tangível, as pessoas podem conversar sobre ela e da
discussão surge a essência do que o designer estava tentando fazer com esse recurso ou
técnica. Ou seja, os tecnólogos não têm apenas de implementar cegamente o recurso;
na verdade, eles fazem parte do processo de descoberta do que é o recurso. Fazer parte
do processo facilita para os tecnólogos a implementação da essência do recurso.
14.5 Análise de risco
A avaliação de risco é um processo contínuo e o produtor deve estar sempre

consciente de quais são os maiores riscos para o jogo, até mesmo após a pro-
dução começar. Fazer uma avaliação de risco inicial na pré-produção, envol-
vendo todos os stakeholders do projeto, é uma boa maneira de identificar e
começar a se preparar para os riscos.
Riscos são coisas que podem dar errado em um projeto, como um mem-
bro-chave da equipe sair no meio do processo, a não conclusão do pipeline
gráfico a tempo para o início da produção ou um fornecedor externo perder
sua data final de entrega. Quando os riscos forem identificados, priorize-os
e planeje estratégias de mitigação. Lembre-se de que nem todos os riscos são
iguais. Embora alguns problemas possam ter uma probabilidade maior de
ocorrer, o impacto pode não ser tão grave como o de um problema de proba-
bilidade mais baixa.
O livro de Steve McConnell, Rapid Development, contém um capítulo
excelente sobre gerenciamento de riscos e é leitura recomendada para qual-
quer pessoa que queira aprender mais sobre isso. Como ele ressalta, não é tão
empolgante trabalhar em um projeto que utilize o gerenciamento de riscos, já
que há pouca necessidade de as pessoas correrem para apagar incêndios. Em
vez disso, todos podem se dedicar à conclusão do jogo, porque os riscos já
foram identificados e previstos no cronograma.
Sua abordagem é dividida em duas partes: avaliação de riscos e controle de
riscos. Durante a avaliação de riscos, a equipe principal tem de fazer o seguinte:
• Identificar riscos que possam afetar o projeto.

• Analisar a probabilidade de cada problema ocorrer e o impacto que ele
terá sobre o projeto.
• Priorizar cada risco, começando com os de maior impacto.
Há vários problemas que podem ocorrer em qualquer jogo, afetando a

data de entrega, a qualidade do trabalho, o escopo dos recursos e o custo.
Ao fazer a avaliação de riscos, discuta o máximo de riscos que puder e então
priorize-os adequadamente. Os maiores problemas são os que têm alta proba-
bilidade de ocorrer e que terão maior impacto sobre o projeto. A Figura 14.3 é
uma grade de classificação básica para quatro níveis de risco. Mais níveis de
risco podem ser adicionados se for apropriado ao seu projeto. Os riscos que se
encaixem nas categorias 1 e 2 são considerados cruciais e devem ter soluções
definidas para o seu gerenciamento, se surgirem.
A segunda parte da estratégia de gerenciamento de riscos de McConnell
envolve o controle de riscos. Após os riscos serem identificados e prioriza-
dos, a equipe deve fazer o seguinte:
Probabilidade de ocorrência Alta
3 1
4 2
Baixa Alta
Impacto sobre o projeto

Figura 14.3 Grade de classificação de riscos.
• Criar um plano de gerenciamento que neutralize ou remova os riscos

mais cruciais. Certifique-se de que os planos para cada risco sejam con-
sistentes com o plano geral do projeto.
• Implementar os planos propostos para eliminar os riscos.
• Monitorar o progresso em direção à eliminação dos riscos conhecidos.
Além disso, qualquer risco novo deve ser identificado e controlado no

decorrer do desenvolvimento com o uso do mesmo processo de avaliação e
controle de riscos discutido anteriormente.
O gerenciamento de riscos é responsabilidade de todos na equipe, em-
bora o produtor deva liderar o esforço de identificação de riscos e soluções.
A reunião inicial de avaliação detalhada de riscos deve ocorrer após alguns
dos principais elementos do jogo terem sido definidos. Assim, haverá uma
ideia melhor dos elementos que apresentam riscos. Passe um dia definindo os
riscos com a equipe, um ou dois dias criando o plano de eliminação de riscos
e, então, divulgue esse plano para a equipe. A Figura 14.4 é um exemplo de
planilha de análise de risco.
Impacto
Probabilidade Classificação
Risco sobre Estratégias de mitigação
de ocorrência do risco
o projeto
O licenciador proprietário Alta Alto 1 -Marcar uma reunião de lançamento com o
da IP de Unidade de licenciador no início da pré-produção para
Justiça pode não dar um examinar os objetivos do projeto e restrições
feedback e a aprovação a no cronograma.
tempo. Se ele não aprovar
o conteúdo da versão gold
master, o processo de
envio para o fabricante do
console sofrerá atrasos, o
que pode afetar a data de
entrega.
O design tem de criar um Baixa Alto 2 -Dedicar-se à prototipagem dos principais pode-
sistema de mecânica jogá- res de cada personagem para limitar o número de
vel em que os poderes dos variáveis que devem ser balanceadas.
super-heróis sejam balan- -Trabalhar com a engenharia para obter um pro-
ceados igualmente tótipo digital funcional o mais rápido possível.
entre eles. -Criar um sistema que permita que as variáveis
sejam facilmente alteradas e testadas na mecâni-
ca do jogo.
-Continuar a discutir ideias de superpoderes até
os recursos principais serem prototipados e
aprovados.
Durante o ciclo de desen- Alta Baixo 3 -Treinar pelo menos 2 pessoas para manipular
volvimento de 2 anos, tarefas específicas do projeto.
alguns funcionários podem -Reservar um tempo para a contratação e treina-
sair da empresa. mento de novas pessoas no meio do projeto.
-Dedicar-se à criação de um ambiente de traba-
lho positivo para aumentar a retenção de funcio-
nários.
-Estar alerta para qualquer mudança repentina
nos hábitos de trabalho dos funcionários para
poder identificar pessoas insatisfeitas e aumentar
sua satisfação antes de elas começarem a
procurar outro emprego.
-Exigir que as pessoas documentem o trabalho
que estão fazendo e examinar todos os assets no
sistema de controle de código-fonte no fim de
cada dia.
A arte conceitual inicial do Baixa Baixo 4 - A arte conceitual deve se basear no documento
jogo pode não descrever de design de personagens fornecido pelo
exatamente a aparência licenciador.
dos personagens de -O feedback do licenciador deve ser implemen-
Unidade de Justiça. tado rapidamente até que ele esteja satisfeito
com os desenhos conceituais.
-Assegurar que os artistas tenham acesso a toda
a arte conceitual disponível de personagens
do filme.
Figura 14.4 Planilha de análise de risco.
14.6 Venda da ideia
Após os documentos conceituais, os protótipos e a análise de risco serem con-

cluídos, o produtor marcará uma reunião de exposição com o publicador e o ge-
rente do estúdio. Esteja preparado para apresentar todos os aspectos do jogo para
eles, inclusive a análise de risco. Os líderes do projeto também devem participar

para poder responder a qualquer pergunta dentro de duas áreas de atuação.
A reunião de exposição pode durar de duas a três horas. Planeje uma
agenda e inclua uma parada no meio para que as pessoas tenham a chance
de fazer um intervalo e se restabelecer (você não quer que elas durmam na
reunião). Certifique-se de que todos os apresentadores demonstrem entusias-
mo com o jogo e consigam transmiti-lo para os participantes. Pessoas pouco
eloquentes para falar em público não devem fazer apresentações na reunião
de exposição. Peça a alguém que tome notas durante a reunião para que o
feedback seja registrado.
Após a apresentação, o publicador e o gerente do estúdio podem ter gos-
tado de tudo que foi mostrado e consentir que você dê continuidade a essas
ideias na pré-produção. Porém, é mais provável que tenham um feedback so-
bre certos elementos do jogo e queiram que ele seja incorporado antes de
permitirem que seu projeto passe para a próxima fase da pré-produção. De
qualquer forma, esse é um resultado positivo para todo o trabalho árduo que
a equipe executou até o momento. Em casos extremos, eles podem decidir
engavetar o projeto ou lhe pedir que volte atrás e crie um novo conceito. Se
isso ocorrer, verifique se entendeu exatamente o que eles não gostaram na
exposição e que áreas precisam de maiores mudanças.
14.7 Lançamento do projeto
Quando a ideia for aprovada por todos os stakeholders, marque um lança-

mento formal do projeto. O lançamento é um ótimo exercício de construção
de equipes porque dá a oportunidade de todos os membros da equipe se reu-
nirem e conversarem sobre o projeto. Também é uma ótima maneira de saudar
qualquer membro novo que tenha entrado nessa fase do desenvolvimento.
Considere um almoço com a equipe ou uma saída em grupo como parte do
lançamento para as pessoas também terem a chance de se socializar casual-
mente umas com as outras e conhecer seus colegas de equipe.
Além disso, se estiver trabalhando em um título de console, você terá
de enviar esse conceito inicial para o fabricante do console para aprovação.
Ele também pode solicitar mudanças no conceito. Se rejeitar totalmente o
conceito, talvez você tenha de corrigi-lo e reenviá-lo para aprovação. Pode
ocorrer de ele rejeitar o conceito e não permitir que você reenvie um conceito
revisado, mas isso raramente acontece.
14.8 Descrição da fase de conceituação
A Figura 14.5 é um resumo de cada etapa que deve ser concluída na fase de
conceituação. Ele é baseado em um ciclo de desenvolvimento de dois anos.
Cronograma Estimativa Estimativa de

Conceito inicial Recursos Tarefas
geral de início finalização
Brainstorm O produtor conduz 1 semana 1o de outubro 5 de outubro Discuta os conceitos iniciais do jogo, inclusive o
as sessões, a equipe de 2007 de 2007 gênero e a plataforma.
participa.
Conceito inicial Designer líder 1 semana 8 de outubro 12 de outubro Examine as notas do brainstorm. Defina o conceito inicial,
de 2007 de 2007 o gênero e a plataforma. Incorpore o feedback da equipe.
Análise Produtor, marketing 2 semanas 15 de outubro 26 de outubro Examine a concorrência atual e potencial, execute
competitiva de 2007 de 2007 a análise SWOT com base no conceito inicial.
Aprovação do O produtor conduz 2-3 semanas 29 de outubro 31 de outubro Apresente o conceito inicial, com o gênero e a
conceito inicial a reunião, os líderes após a pré-pro- de 2007 de 2007 plataforma, para aprovação. Análise competitiva
participam. dução começar. inicial concluída. Incorpore o feedback da gerência.
Cronograma
Defina o conceito Recursos Tarefas
geral
Declaração da O produtor conduz 1-2 dias 1o de novembro 2 de novembro Defina a declaração da missão do jogo.
missão as sessões, a equipe de 2007 de 2007
participa.
Cenário do Designer líder, 3-5 dias 5 de novembro 9 de novembro Defina o cenário do jogo, inclusive a aparência.
jogo artista líder de 2007 de 2007
Mecânica do Designer líder 2-4 semanas 12 de novembro 6 de dezembro Crie a visão geral de como os principais elementos do jogo
jogo de 2007 de 2007 funcionarão: desafios, recompensas, curva de aprendizado,
esquema de controle, elementos de áudio, ambiente multijogador.
Sinopse da Designer líder, 3-5 dias 10 de dezembro 14 de dezembro Crie a história de fundo do jogo, as biografias dos persona-
história redator de 2007 de 2007 gens, a descrição geral de como a história se desenrola no jogo.
Arte conceitual Artista líder, 3-5 dias 12 de dezembro 7 de dezembro Crie a arte conceitual do cenário, dos personagens e dos
artista conceitual de 2007 de 2007 objetos do jogo.
Elementos de Designer líder, 2-4 dias 17 de dezembro 21 de dezembro Crie a visão geral de como o voiceover, os efeitos
áudio designer de som de 2007 de 2007 sonoros e a música serão apresentados no jogo.
Prototipagem Designer líder, 4-6 semanas 12 de novembro 21 de dezembro Crie protótipos dos principais elementos do jogo.
produtor de 2007 de 2007
Análise de risco O produtor conduz 2-3 dias 19 de dezembro 21 de dezembro Avalie os riscos do projeto, determine a estratégia
as sessões, a equipe de 2007 de 2007 de eliminação, divulgue para a equipe.
participa.
Venda a ideia Produtor, líderes 2-3 meses após 2 de janeiro 4 de janeiro Apresente todos os principais elementos de
a aprovação do de 2008 de 2008 jogabilidade para a gerência para aprovação,
conceito inicial incorpore seu feedback.
Lançamento Produtor Após a gerên- 7 de janeiro 7 de janeiro Reúna-se com a equipe para celebrar a aprovação do
do projeto cia aprovar a de 2008 de 2008 conceito. Se estiver trabalhando em um título de console,
exposição. envie o conceito do jogo para o fabricante do console
para aprovação.
Figura 14.5 Descrição da fase de conceituação.
A importância da fase de conceituação na pré-produção não pode ser subes-

timada. O conceito é a base a partir da qual o jogo será construído, e se ele for
fraco ou não for totalmente definido antes do início da próxima fase, elemen-
tos importantes podem ficar ausentes do jogo e só serem descobertos quando
a equipe estiver no meio da produção. Este capítulo discutiu algumas das
principais áreas que devem ser definidas e aprovadas pelos stakeholders do
projeto antes de a pré-produção continuar. Essas áreas são o conceito inicial,
a mecânica do jogo, o cenário, os personagens e os elementos de áudio. Tam-
bém foram apresentadas informações sobre prototipagem e análise de risco,
que são parte integrante do processo.
Após o conceito ser firmemente estabelecido, começará a próxima fase
da pré-produção, a determinação de requisitos do jogo. O próximo capítulo
discutirá os produtos que são gerados durante essa fase, como um conjunto
básico de recursos, as etapas e a documentação de design.
15
REQUISITOS DO JOGO
Neste capítulo
• Definição dos recursos • Avaliação da • Análise de risco
do jogo tecnologia • Aprovação
• Definição das • Definição das • Descrição da fase de
etapas e produtos ferramentas e pipeline requisitos do jogo
• Documentação
15.1 Introdução
Quando os produtos da fase de conceito inicial forem concluídos e aprova-

dos, a equipe terá de determinar os requisitos do jogo. Os requisitos detalham
como o conceito será transformado em um jogo real. São tomadas decisões
sobre os principais objetivos do projeto, o conjunto básico de recursos e os
produtos das etapas. Além disso, a tecnologia básica e o pipeline de produ-
ção devem ser estabelecidos. Para concluir, toda a documentação deve ser
redigida e finalizada. Após esses itens serem concluídos, você terá uma ideia
clara do que precisa ser feito para o jogo ser criado. Eles serão então usados na
determinação das necessidades de orçamento, cronograma e pessoal do jogo.
15.2 Defina os recursos do jogo
Durante a pré-produção, todo mundo tem alguma opinião sobre que recursos
modernos podem ser incluídos no jogo. É claro que você não terá como in-
cluir todas as solicitações de recursos: algumas não combinarão com a visão
do jogo, a equipe não terá tempo suficiente para incluir tudo ou a tecnologia
pode não suportar a funcionalidade. Portanto, você precisa priorizar os recur-

sos em camadas diferentes de implementação. Por exemplo, os da camada um
são os recursos básicos do jogo, os da camada dois adicionam valor aos recur-
sos básicos e a camada três designa recursos que seria interessante incluir. O
ideal é que todos os recursos da camada um sejam incluídos, e talvez você
ainda tenha tempo para adicionar muitos (ou todos) dos recursos da camada
dois. Geralmente, os recursos da camada três são considerados na versão se-
guinte do projeto e não entram no jogo final.
Para começar, envolva a equipe em uma sessão de brainstorm para deci-
dir que recursos devem ser incluídos no jogo. Conduza essas sessões durante
dois ou três dias. Discuta recursos multijogador, recursos de jogador único, a
mecânica, o som e qualquer outro aspecto do jogo. Reúna todas as opiniões
sobre recursos em uma única lista e então categorize-as por tipo. Isso ajudará
o produtor e os líderes a priorizarem melhor os recursos. Algumas categorias
que devem ser consideradas são as seguintes:
Processo: Esses recursos estão ligados à melhoria do processo de de-
senvolvimento. Isso inclui a melhoria dos formatos da documentação de
design, o estabelecimento de um processo de aprovação para níveis mul-
tijogador e a preparação de minitutoriais que ensinem as pessoas como
usar as ferramentas de desenvolvimento.
Produção: Esses recursos envolvem melhorias nas ferramentas e na tec-
nologia usadas na criação do jogo. Por exemplo, acrescentar a funciona-
lidade de recortar e colar à ferramenta de script, melhorar o modo como
objetos destrutíveis funcionam no jogo e adicionar a funcionalidade de
iluminação realçada às ferramentas de arte.
Jogabilidade: Esses recursos são compostos por elementos de jogabili-
dade que afetarão diretamente a experiência do jogador e que podem ser
vistos por ele. Isso inclui a habilidade do jogador controlar veículos, a
funcionalidade de alterar opções dinamicamente e a possibilidade do
jogador personalizar seu avatar.
Você também pode criar categorias ligadas a elementos de jogabilidade
específicos, por disciplina ou qualquer outro agrupamento que o ajude a ter
um controle melhor sobre os tipos de recursos solicitados. A Figura 15.1 é um
exemplo de lista mestra de recursos categorizada.
Após essa lista ser gerada e categorizada, o produtor a enviará para os
líderes e pedirá que atribuam individualmente uma prioridade a cada recurso
dela. Os líderes devem basear suas prioridades nas restrições conhecidas do
projeto. Por exemplo, se o jogo for do tipo time to market, o prazo final de
liberação do código será a principal restrição e todos os recursos básicos terão
de ser criados dentro do tempo limitado do projeto. Se o jogo for a sequência
de uma franquia bem-sucedida, a restrição será fazer com que esteja à altu-
ra do predecessor, portanto, mais tempo pode ser adicionado ao cronograma
para garantir que o jogo tenha todos os recursos-chave.
15 • Requisitos do Jogo 239
Categoria Recurso
Jogabilidade objetivos dinâmicos para as missões
NO SITE
Processo o processo de revisão da missão também deve incluir níveis multijogador
Processo estabelecer um sistema para a circulação de documentos de design e de atualizações de documentos en-
tre a equipe
Jogabilidade interface de usuário fácil de entender
Jogabilidade missões que possam ser jogadas novamente
Produção melhoria das questões ligadas à física para que as explosões pareçam mais realistas
Jogabilidade possibilidade do jogador personalizar a aparência dos personagens
Produção suporte à funcionalidade de recortar e colar na ferramenta de script
Figura 15.1 Lista mestra de recursos categorizada.
Os líderes também devem considerar as preocupações gerais de arte, en-

genharia, design e teste ao atribuir prioridades. Por exemplo, o artista líder
pode ficar tentado a atribuir a prioridade mais alta a todas as solicitações de
recursos de arte e uma prioridade mais baixa às solicitações de recursos de
design. No entanto, se ele não considerar convenientemente as necessidades
gerais do jogo, este pode acabar com um ambiente gráfico surpreendente mas
uma jogabilidade mediana. Líderes experientes saberão como criar um equi-
líbrio entre as necessidades artísticas, de design, de engenharia e de jogabili-
dade de um projeto.
Após cada líder ter atribuído uma pontuação para os recursos (com 3
sendo a prioridade mais alta e 1 a mais baixa), reúna todos os dados e adi-
cione-os à lista mestra de recursos. Inclua uma coluna para as pontuações
de cada pessoa, sendo a última uma média das pontuações. Após calcular a
pontuação média, use esse valor para classificar a lista inteira. A Figura 15.2 é
um exemplo de planilha de pontuação de recursos após sua classificação por
pontuação média.
Categoria Recurso Prod. Arte Design Eng. QA Média

Jogabilidade objetivos dinâmicos para as missões 3 3 3 3 3 3
NO SITE Processo estabelecer um sistema para a circulação de documentos
de design e de atualizações de documentos entre a equipe 3 3 3 3 3 3
Jogabilidade interface de usuário fácil de entender 3 3 3 3 3 3
Processo o processo de revisão da missão também deve incluir
níveis multijogador 3 3 3 2 3 2,8
Produção melhoria das questões ligadas à física para que as

2 3 1 3 1 2
explosões pareçam mais realistas
Jogabilidade missões que possam ser jogadas novamente 2 2 2 1 2 1,8
Jogabilidade possibilidade do jogador personalizar a aparência dos 1 2 3 1 1 1,6
personagens
Produção suporte à funcionalidade de recortar e colar na ferra-
menta de script 1 1 3 1 1 1,4
3 = necessário
2 = desejado
1 = interessante
Figura 15.2 Planilha de pontuação de recursos classificada por pontuação média.

Após concluir a planilha, marque uma reunião com os líderes para

discutir os resultados. Essa reunião pode durar algumas horas, já que você
terá de examinar cada recurso, avaliar sua pontuação geral e decidir se ele é
“necessário”, “desejado” ou “interessante”. Mesmo que nem todos concor-
dem 100% com a pontuação de cada recurso da lista, esse exercício fornece
uma boa maneira de se obter um consenso sobre os recursos que são mais
importantes para o jogo. Quando a reunião terminar, divulgue a lista final
classificada para a equipe. Ela fornecerá a base para a definição das etapas e
produtos.
CRESCIMENTO DESENFREADO

Ubisoft
Parte do problema é que não há como distinguir os recursos – basicamente, qualquer

recurso novo pode ser chamado de melhoria ou correção de bug de um recurso existente,
portanto, é difícil definir rigorosamente quando a regra foi quebrada. Em minha opinião,
se você projetar corretamente, isso não deve ocorrer. Se começar com um conceito para o
jogo inteiro e então especificar a mecânica e a dinâmica que dão suporte a ele, você não
sairá descontroladamente atrás de recursos. E também não tentará copiar recursos atra-
entes aleatórios de outros jogos porque seu jogo não será um conjunto aleatório de recur-
sos e, sim, um todo coeso. Essa ideia é muito otimista, e não há como o desenvolvimento
de um jogo funcionar assim, mas é um bom ponto de partida. Procure focar apenas o que
é significativo para o conceito criativo do jogo. Qualquer coisa fora disso (por melhor que
seja) será crescimento desenfreado (feature creep).
15.3 Defina as etapas e produtos
Após os recursos básicos serem determinados, o produtor poderá elaborar a

documentação inicial das etapas e produtos. As etapas marcam um evento
importante durante o desenvolvimento do jogo e são usadas no rastreamento
do progresso do projeto. Elas dão objetivos menores e mais gerenciáveis para
a equipe alcançar e podem ser facilmente definidas pela listagem dos produ-
tos que são esperados em cada etapa.
Cada equipe de desenvolvimento tem um conjunto de etapas diferente
para marcar o progresso do jogo. Algumas equipes estabelecem etapas men-
sais e outras trabalham para concluir etapas maiores que duram alguns meses.
Em um ciclo de desenvolvimento de dois anos, é comum vermos o seguinte
conjunto de etapas:
Primeira versão jogável: Essa é a primeira das etapas principais do jogo.

Ela contém jogabilidade e assets representativos. Com frequência, é ba-
seada no protótipo que foi criado na pré-produção. Essa etapa é geralmen-
te agendada para ocorrer de 12 a 18 meses antes da liberação do código.
Alfa: Nessa etapa, a funcionalidade-chave da jogabilidade é implementa-
da, os assets estão 40-50% concluídos (o resto é espaço reservado), o jogo
está sendo executado na plataforma de hardware correta no modo de depu-
ração e muita coisa já foi feita para começarmos a ter uma ideia de como ele
está ficando. Os recursos podem passar por maiores ajustes nesse momen-
to, dependendo dos resultados do playtest e de outros feedbacks. A etapa
alfa ocorre entre 8 e 10 meses antes da liberação do código.
Congelamento do código: Nesse momento, o código do jogo está con-
cluído e os programadores apenas corrigirão bugs. Nenhum recurso adi-
cional é incluído para que o código possa se estabilizar e os bugs críticos
sejam identificados e corrigidos. Essa etapa ocorre cerca de 3 a 4 meses
antes da liberação do código.
Beta: Na etapa beta, o jogo está com o código e os assets concluídos. A
arte, o design e a engenharia só se dedicam à correção dos bugs listados
no banco de dados de bugs. Nenhum asset novo é gerado, nenhum recur-
so novo é codificado e nenhuma alteração é feita nos recursos e funcio-
nalidades existentes a menos que um bug seja identificado. A etapa beta
ocorre cerca de 2 a 3 meses antes da liberação do código.
Código candidato à liberação: Nessa etapa, todos os bugs foram elimi-
nados e os desenvolvedores têm certeza de que a build está pronta para
ser entregue ou enviada para o fabricante do console para aprovação.
O código candidato à liberação é testado em relação ao plano de teste
de QA e qualquer crash bug ou outros problemas críticos são corrigidos
quando necessário. A equipe não faz ativamente nenhuma correção. O
primeiro código candidato à liberação deve estar pronto para o teste de
QA cerca de 3 a 4 semanas antes da data da liberação.
A Figura 15.3 é uma tabela com mais detalhes sobre cada uma das etapas
de desenvolvimento.
Após ter determinado que etapas devem ser incluídas no cronograma de
produção, defina com o máximo de detalhes que produtos são esperados em
cada uma. Isso é importante para que haja uma maneira clara da equipe deter-
minar se a etapa foi concluída. Se nada for definido, como a equipe saberá se
a etapa foi concluída? Essa lista também será útil para o departamento de QA,
já que eles sabem exatamente que partes do jogo precisam ter a funcionalida-
de verificada. Também é uma ótima maneira de acompanhar o progresso do
jogo e saber se algo importante foi omitido.
Uma maneira simples de definir as etapas é estabelecer uma lista de
produtos para cada uma. Essas listas podem ser iniciadas na pré-produção
e atualizadas à medida que informações sobre o jogo forem definidas. Inclua
informações sobre o que foi concluído e está pronto para ser testado em cada
Envio para terceiros –

Primeira versão Congelamento Liberação
Alfa Beta SOMENTE NO CASO
jogável do código do código
DE CONSOLE
NO SITE Cronograma 12-18 meses antes da 8-10 meses antes da 3-4 meses antes da 2-3 meses antes Primeiro código Envio do código
liberação do código liberação do código liberação do código da liberação do candidato à candidato à
código liberação liberação pelo
disponível para o menos 8-12
QA 3 semanas semanas antes da
antes do prazo data de entrega
final de liberação. desejada.
Engenharia Funcionalidade inicial de Funcionalidade básica da Código concluído Código concluído, Congelamento Código final. Se
alguns recursos-chave mecânica do jogo incluída para todos os só correção de total do código. for rejeitado, só
incluída para demonstrar para todos os recursos. Os recursos. Só há bugs desse ponto Durante essa bugs específicos
uma jogabilidade muito recursos funcionam como correção de bugs em diante. fase, só crash como solicitado
básica. projetado, mas podem ser desse momento em bugs podem ser pelo fabricante
ajustados e alterados com diante. Nenhum corrigidos. Bugs serão corrigidos
base em algum feedback. O recurso novo é críticos podem para reenvio.
jogo é executado na platafor- adicionado, a menos ser corrigidos
ma de hardware pretendida. que seja aprovado com aprovação.
pela gerência sênior.
Arte De dois a três assets de Os assets estão 40-50% Os assets estão Todos os assets de Congelamento Arte concluída. Se
arte são criados e podem concluídos, com assets 80-90% concluídos, arte estão concluí- total da arte. for rejeitada, só
ser vistos na build. Os provisórios ocupando o com assets provisó- dos e funcionando Nenhuma bugs específicos
assets demonstram a resto do jogo. rios ocupando o res- no jogo. Só corre- correção na arte, como solicitado
aparência da versão final to do jogo. ções maiores de a menos que pelo fabricante
do jogo. bugs ocorrem desse esteja relacionada serão corrigidos
ponto em diante. a um crash bug. para reenvio.
Design Os recursos básicos estão Toda a documentação de O jogo está em um Todos os assets do Congelamento Design final. Se for
definidos; a mecânica design foi concluída. A nível 80-90% jogável. design estão total do design. rejeitado, só bugs
principal do jogo tem implementação dos recursos O feedback do concluídos e Nenhuma específicos como
uma documentação está em andamento; 40-50% playtest está sendo funcionando no correção no solicitado pelo
básica e um protótipo das tarefas de produção do incorporado. jogo. Só correções design, a menos fabricante serão
jogável, se possível. design estão concluídas. As maiores de bugs que esteja corrigidos para
áreas principais do jogo ocorrem desse relacionada a um reenvio.
podem ser jogadas como ponto em diante. crash bug.
projetado. Ajustes menores na
mecânica podem
ser feitos, com
base no feedback
do playtest.
Som O som do jogo foi defini- 40-50% dos efeitos sonoros O voiceover final foi Todos os assets Congelamento Som final. Se for
do, inclusive o voiceover, estão funcionando. O design gravado e incluído no sonoros finais total do som. rejeitado, só bugs
a música e os efeitos do voiceover está em jogo. A música final foram incluídos e específicos como
sonoros. Exemplos estão andamento e arquivos de VO também foi incluída. estão funcionando solicitado pelo
disponíveis para provisórios estão sendo Os efeitos sonoros no jogo. fabricante serão
demonstrar como o som gravados. Música em foram 80-90% corrigidos para
é abordado no jogo. processo de composição. implementados. reenvio.
Localização
Trabalho com o Trabalho com o fornecedor Os assets de texto e Os assets de Congelamento Localização final.
publicador para para determinar o voiceover finais são idioma finais são total da Se for rejeitada, só
determinar que idiomas cronograma de entrega de enviados para integrados ao jogo. localização. bugs específicos
são necessários. assets. Envie glossários, tradução. As O teste linguístico como solicitado
Selecione o fornecedor códigos de trapaça e traduções são é concluído. Envie pelo fabricante
de localização e envie detonados para o concluídas e builds para os serão corrigidos
para ele os documentos fornecedor. Teste o pipeline devolvidas para o conselhos de para reenvio.
de design e a primeira de localização para verificar desenvolvedor para classificação etária
versão jogável. Defina o se as traduções estão sendo integração. apropriados para
pipeline de localização. exibidas corretamente. obter a classifi-
cação final.
Produção As localizações
Os requisitos básicos e o A produção plena começou. As localizações Todas as tarefas Fim da produção.
planejamento do jogo Os requisitos e o começaram. O foram concluídas. de produção Só é preciso
são concluídos planejamento do jogo são manual está em Só correções de foram concluídas. gerenciar o
totalmente concluídos e processo de redação. bugs ocorrem Se for necessário processo de
aprovados. No caso de Os recursos de desse ponto em enviar o jogo para envio.
trabalho com licenças, todas marketing estão diante. O manual o fabricante do
as licenças são obtidas e um sendo gerados. foi concluído. Os console,
processo de aprovação é fornecedores formulários de
definido. externos envio já estarão
terminaram seu preenchidos e
trabalho. Todas as prontos para
aprovações de seguir.
licenças foram
obtidas. A equipe
de desenvolvimen-
to pode começar a
finalizar o projeto.
QA Teste do jogo Agora o jogo pode ser O plano de testes foi Todos os aspectos Teste dos códigos Testes continuam
comparando-o com os jogado plenamente, embora 100% concluído. A do jogo podem ser candidatos à sendo feitos no(s)
produtos da etapa de talvez sejam necessários funcionalidade testados e liberação em candidato(s) a
primeira versão jogável alguns ajustes em uma ou completa do jogo corrigidos. O busca de crash envio até o jogo
definidos na fase de outra funcionalidade. O pode ser testada e playtest continua bugs que receber a
requisitos. playtest pode começar. Teste corrigida. O playtest para a equipe de impeçam o jogo aprovação final.
do jogo comparando-o com continua. Pode haver design dar o de ser entregue.
os produtos da versão alfa um teste envolvendo polimento final no
esperados para essa etapa. a lista de produtos jogo.
da etapa de
congelamento do
código.
Figura 15.3 Etapas comuns no desenvolvimento.

aspecto do jogo. Se um asset ou recurso não estiver totalmente concluído, de-

termine o que deve ser concluído para constar no jogo na entrega de cada eta-
pa, já que alguns itens podem ser muito grandes e se estender por várias etapas
antes de estarem totalmente concluídos. Use categorias como as seguintes:
• Personagens, objetos, níveis

• Cinemática
• Recursos de jogabilidade
• Recursos de engenharia
• IU (Interface de Usuário)
• Som
• Localização
• Roteiro
• Geral
Talvez você não consiga fornecer todas as informações no início do pro-

jeto, já que muitas decisões ainda terão de ser tomadas, mas dê o que puder.
Após as listas iniciais serem estabelecidas, envie-as para os líderes para que
eles possam verificar se os objetivos das etapas são atingíveis. Divulgue essas
listas para a equipe para que os membros conheçam claramente as expectati-
vas de cada etapa. Habitue-se, também, a procurar regularmente atualizações
nas listas. No entanto, não faça alterações no conjunto de produtos de uma eta-
pa que será concluída em alguns dias – isto é, não adicione itens à lista de pro-
dutos da etapa alfa uma semana antes da etapa terminar. A Figura 15.4 é um
exemplo de lista de produtos parcial para a etapa alfa de Unidade de Justiça.
DEFININDO ETAPAS

Stormfront Studios
Converti-me ao desenvolvimento ágil, mas ainda acredito no uso do método de cascata

para o planejamento das etapas globais de um projeto como um todo. Pense nisso da
seguinte forma: Lewis e Clark sabiam que iam para o oeste em sua expedição de mapea-
mento da América do Norte e sabiam aproximadamente a distância do Oceano Pacífico.
Mas não tinham um mapa detalhado mostrando exatamente que caminho seguir. Você
pode usar um conceito semelhante para seu cronograma de produção: crie um cronogra-
ma geral baseado na abordagem em cascata para seu projeto completo e em seguida pen-
se nas primeiras etapas essenciais e use um processo ágil para planejar uma sprint de 30
dias para chegar lá. Certifique-se de ter algo que funcione e que você possa demonstrar na
tela no fim desses 30 dias e de que os assets, o código e as lições aprendidas na primeira
sprint tornem possível planejar os 30 dias subsequentes.
Nosso processo básico de elaboração de um cronograma começa com a fase conceitu-
al, em que decidimos os elementos-chave do jogo aos quais daremos um tratamento mais
geral. Em seguida, planejamos como o jogo funcionará e será jogado na fase de pré-produção
e produzimos uma demo que trate dos grandes riscos do projeto. A mecânica do jogo é
divertida? É possível obter uma taxa de quadros de 60 q/s se tivermos 101 cães e um porco
se movendo na tela? Tendo terminado esse planejamento, você poderá entrar na fase de
produção, em que o tamanho da equipe crescerá e grande parte do trabalho será feita. Para
concluir, você passará pela fase de testes, em que o jogo será testado e depurado e serão
feitos o balanceamento e os ajustes finais. É bom que haja etapas sendo concluídas pelo
menos uma vez por mês, embora as etapas mais distantes talvez não sejam muito claras no
início de um projeto.
Unidade de Justiça
Produtos da etapa alfa para 30 de março de 2007
NO SITE Última atualização em 10 de fevereiro de 2007
Níveis
- Os níveis a seguir estarão com todos os assets e o roteiro da mecânica:
*Sala de justiça
*Covil do vilão
- Os níveis a seguir terão uma geometria básica e poderão ser vistos no jogo,
mas não estarão com a mecânica roteirizada:
*Prefeitura
*Complexo de escritórios
Personagens
- Os personagens a seguir terão todos os assets:
*Bullet Point
*Montezuma
- Os personagens a seguir poderão ser vistos no jogo, mas não terão as texturas finais
*Caribou
IU
- O esquema de cores e a fonte estarão concluídos e aprovados
- O fluxo da IU será prototipado no Macromedia Flash
- Telas básicas da IU que serão implementadas e estarão funcionando:
*Tela inicial
*Tela de perfis
*Tela de opções
- A IU in-game terá uma arte provisória com a funcionalidade básica de:
*Barra de saúde
*Inventário
Som
- Pistas de VO e designs de som provisórios serão implementados para os níveis a seguir:
*Sala de justiça
*Covil do vilão
- Designs de som serão concluídos para os níveis restantes do jogo
Engenharia
- Ferramentas de script concluídas e funcionando
- Ferramentas de arte concluídas e funcionando
- APIs de rede serão implementadas
- Processo de construção finalizado e definido
Figura 15.4 Lista parcial de produtos da etapa alfa de Unidade de Justiça.

15.4 Avalie a tecnologia
Durante a fase de requisitos do jogo, o programador líder avalia as necessi-

dades de tecnologia do projeto. Decisões devem ser tomadas sobre que me-
canismo de jogo, ferramentas de arte, ferramentas de script, sistemas de IA,
sistemas de física e outros elementos técnicos são necessários para fornecer a
funcionalidade de jogo desejada. A tecnologia usada dependerá do cronogra-
ma, dos recursos, das funcionalidades desejadas e da qualidade dessas fun-
cionalidades. Por exemplo, se o objetivo principal do jogo for ter elementos
gráficos de ponta, o programador líder passará algum tempo avaliando que
tecnologia gráfica é necessária.
O programador líder também deve pesquisar como essa tecnologia será
obtida: ela será codificada por programadores internos ou um pacote de soft-
ware existente será licenciado e modificado para uso no jogo? Há prós e con-
tras nas duas opções e provavelmente jogos maiores usarão uma combinação
de tecnologia interna e tecnologia licenciada.
Os benefícios da criação da tecnologia internamente são que ela será pro-
priedade do estúdio e, portanto, não terá taxa de licenciamento; especialis-
tas internos estarão disponíveis imediatamente para corrigir bugs e adicionar
melhorias aos recursos; e a tecnologia pode ser personalizada especificamen-
te para o jogo. Uma desvantagem é que os programadores têm de gastar um
tempo valioso do desenvolvimento reinventando funcionalidades técnicas
básicas (como a física, a IA e a animação), isto é, terão menos tempo para se
dedicar à funcionalidade específica do jogo. Além disso, o uso de uma equipe
de programadores internos para codificar funcionalidades básicas, como o
sistema de física, pode ser mais caro a longo prazo do que o licenciamento de
uma solução de middleware, como o Havok.
O principal benefício do licenciamento de uma tecnologia existente é
que ele fornece uma estrutura básica para tecnologias comuns, ou seja, os
programadores podem se dedicar à funcionalidade específica do jogo. As des-
vantagens podem ser os custos (principalmente se o orçamento for pequeno),
o suporte técnico limitado do fornecedor e a necessidade de alterar o código
para que atenda à funcionalidade do jogo. No entanto, essas desvantagens
podem valer o trabalho se o licenciamento economizar tempo e/ou dinheiro
durante o processo de desenvolvimento.
Após o programador líder ter pesquisado as tecnologias disponíveis, ele
fará uma recomendação para o produtor. O produtor pode usar essa informa-
ção ao criar o orçamento e o cronograma e trabalhará junto ao programador
líder para determinar as melhores soluções tecnológicas para o jogo.
15.5 Defina as ferramentas e o pipeline
Além de avaliar que tecnologias serão usadas no jogo, o programador líder tra-
balhará com os outros líderes para definir o pipeline de produção. O pipeline
de produção é a série de etapas que são necessárias para o código e os assets
funcionarem em uma versão jogável. Ele deve incorporar sem problemas as
ferramentas, os assets e as necessidades de produção do jogo. É muito raro um
asset ser criado e instantaneamente usado no jogo; ele pode ter de ser converti-
do para um formato de arquivo específico ou compilado no código. O jogo não
pode ser jogado instantaneamente com as novas atualizações e assets; antes, os
programadores devem compilar o código e construir um novo arquivo executá-
vel. Devemos considerar principalmente o seguinte ao definir o pipeline:
Que ferramentas e software são necessários? Ferramentas de software
são necessárias para converter os formatos de arquivo, e um software de
controle de código-fonte deve ser usado para a inserção e remoção de
assets na build. Decisões também devem ser tomadas sobre os compila-
dores e linguagens de codificação que serão usados.
O pipeline dá suporte a funcionalidade bidirecional? O pipeline deve
dar suporte à possibilidade de os assets serem convertidos para uso no
jogo e transformados novamente na fonte original. Isso permite que alte-
rações sejam feitas mais rapidamente nos assets.
Qual é o caminho crucial? Há algum gargalo? Ninguém deve ficar com
um volume desproporcional de trabalho no pipeline e se tornar um gar-
galo na conversão de assets. Limite também o número de etapas do pi-
peline; os assets têm de poder ser vistos e jogados em uma build o mais
rápido possível.
Quando o sistema precisa estar funcionando plenamente? Para que
uma build jogável com os assets corretos seja criada, o pipeline tem de
estar funcionando. O funcionamento parcial pode ser usado por alguns
meses, contanto que não impeça as pessoas de criarem assets e vê-los no
jogo.
Como os assets são gerenciados e rastreados no sistema? Decida que
software de controle de código-fonte será usado para que as pessoas pos-
sam extrair os assets antes de trabalhar neles. Tudo deve ser mantido
sob o controle de versões para impedir que várias versões de um arquivo
causem confusão no pipeline.
Que áreas do sistema podem ser automatizadas? Automatize o pipeli-
ne o máximo possível para reduzir o tempo e os erros humanos.
Após essas perguntas serem respondidas, os líderes poderão determinar
qual pipeline funciona melhor para o jogo. The Game Asset Pipeline, de Ben
Carter, é um ótimo recurso para a obtenção de mais detalhes sobre a prepa-
ração de um pipeline de produção. Por exemplo, o pipeline de produção de
Unidade de Justiça requer que os artistas criem seus modelos de personagens
CRIANDO O PIPELINE

Pandemic Studios
Uma das necessidades existentes no desenvolvimento de um jogo é uma sólida estratégia

para as ferramentas. Você deve ter um grupo de profissionais dedicado à programação de
ferramentas em sua equipe. Eles podem melhorar as ferramentas proprietárias que fazem
parte de seu pipeline atualizando recursos, corrigindo bugs e adicionando novos recursos
com base nas necessidades de desenvolvimento do jogo.
Isso é importante porque muitos dos problemas que enfrentamos durante o desen-
volvimento de jogos são as ferramentas não funcionarem ou serem muito lentas. Já que
uma produção de jogos eficiente depende da criação rápida de assets, os desenvolvedores
estão constantemente pensando em maneiras de usar ferramentas para acelerar o pipeli-
ne de produção de assets – principalmente se o mesmo tipo de asset estiver sendo criado
repetidamente. Quanto mais um artista demorar para transformar a fonte artística de um
asset em um recurso que possa ser visto no jogo, menos ele vai querer lidar com o proces-
so e menor será a qualidade.
O diretor de arte e o diretor técnico trabalham juntos para criar um pipeline de pro-
dução eficiente para os assets de arte. Há várias coisas a considerar na definição de como
o pipeline deve funcionar. Primeiro, certifique-se de que o pipeline não seja afunilado por
um único componente do processo. Por exemplo, se o processo depender muito do 3DS-
Max é porque o pipeline é impulsionado pela arte e todos os envolvidos terão de passar
por um artista para ver algo funcionando no jogo. Todas as pessoas pertinentes da equipe
têm de poder acessar, manipular, modificar e alterar o conteúdo do jogo simultânea ou
igualmente. Isso pulveriza os riscos do desenvolvimento e fornece vários pipelines para a
conclusão do trabalho.
O número de etapas do pipeline deve ser o menor e menos problemático possível.
Não peça que artistas não técnicos executem tarefas técnicas do pipeline para fazer seus
assets funcionarem no jogo. Provavelmente eles cometerão erros e terão de voltar atrás e
refazer os assets. Isso os atrasará. O pipeline deve promover a aceleração do ambiente de
desenvolvimento.
Certifique-se de que os dados que passam pelo pipeline possam ser gerenciados
de uma maneira rápida e eficiente. Se o pipeline começar com um nódulo de dados com
informações sendo adicionadas à medida que ele avança, descubra como erros podem ser
corrigidos durante o trajeto em vez de ter de iniciar o processo a partir do zero. Também
ajuda limitar as ferramentas usadas no pipeline. Por exemplo, não misture o 3DSMax e o
Maya, escolha um deles. Além disso, mantenha o número de conversões de dados em um
nível mínimo.
Outra coisa essencial é o pipeline ser bidirecional. Qualquer pessoa deve poder con-
verter facilmente um conjunto de dados em outro. Por exemplo, se um artista tiver de
criar uma cinemática com duas pessoas caminhando em um cenário, ele exportará todos
os assets de arte necessários para o AfterEffects, criará o cenário e então exportará tudo
novamente para o jogo.
Para finalizar, automatize a divulgação de conclusão de etapas do pipeline. Pode pa-

recer muito simples lembrar de dizer às pessoas que estão esperando seus dados que você
não precisa mais deles e que elas podem começar a usá-los. No entanto, a comunicação
é interrompida porque as pessoas não conseguem mantê-la. Elas se ocupam e esquecem
totalmente que alguém está esperando a informação de que o asset está pronto. Portanto,
quanto mais maneiras houver dessa comunicação ser automatizada, mais eficiente será o
pipeline. Se um artista inserir algo no SourceSafe, um e-mail poderia ser enviado automa-
ticamente para a pessoa apropriada informando o que foi concluído.
em 3DSMax; portanto, converta-os para um formato de arquivo proprietário e

insira-os na build. A build é preparada de modo que o artista possa copiar o
modelo para uma build em seu kit de desenvolvimento pessoal e ver instan-
taneamente sua aparência no jogo. No entanto, para o modelo de personagem
ser visto integralmente em uma build oficial, os programadores devem criar
uma nova build e divulgá-la para a equipe.
15.6 Documentação
À medida que a pré-produção for chegando ao fim, uma documentação deve

ser concluída para todos os elementos principais do jogo. Isso inclui a docu-
mentação artística, de design e técnica. Se a documentação não for redigida
claramente ou não fornecer as informações desejadas para o público-alvo, as
pessoas podem acabar não lendo. Se isso ocorrer em seu projeto, como produ-
tor sua responsabilidade é trabalhar com os redatores da documentação para
criar algo que seja útil para a equipe. Se a equipe não estiver lendo os docu-
mentos por causa de alguma outra razão – falta de tempo ou por acharem que
já entenderam como um recurso funciona –, você terá de reservar uma hora
para que todos leiam a documentação juntos.
Cada equipe de desenvolvimento terá um formato diferente para a do-
cumentação de design, artística e técnica. O segredo é ter um formato que
seja fácil de ler e forneça informações claras sobre como o jogo funciona. Há
vários livros sobre design de jogos que discutem como formatar documentos
de design detalhadamente. Essas mesmas lições podem ser transportadas para
os documentos artísticos e técnicos. Game Design Workshop: Designing, Pro-
totyping and Playtesting Games, de Tracy Fullerton, Chris Swain e Steve Ho-
ffman, é um bom recurso de consulta sobre a redação de documentos eficazes.
Considere ter formatos de documentos diferentes para públicos distin-
tos. A documentação necessária à equipe de desenvolvimento deve incluir
todos os detalhes de cada recurso da jogabilidade. A ideia é que qualquer
membro da equipe de desenvolvimento possa consultar a documentação para
obter orientações claras sobre como um recurso deve funcionar no jogo. A
documentação de design é o recurso definitivo para a resolução de qualquer
problema de design, portanto, se o design de um recurso mudar, atualize a do-

cumentação para que ela reflita isso. A documentação da gerência do estúdio
deve enfocar a mecânica geral do jogo, os recursos-chave e como tudo isso se
combina para fornecer a experiência geral do jogador.
Mesmo quando o recurso tem um protótipo funcional, algum tipo de
documentação é necessário como registro escrito de como ele funciona. Em
primeiro lugar, não serão todas as pessoas que terão acesso ao protótipo ou
conseguirão vê-lo funcionando corretamente, e se houver documentação, elas
poderão lê-la para entender como o recurso funciona. Além disso, geralmente
o departamento de QA usa a documentação de design para redigir o plano de
testes. Por exemplo, se um artista criar um protótipo funcional do shell de
IU do jogo e não documentar a funcionalidade, será difícil para a QA redigir
um plano de testes preciso para verificar se todos os botões, caixas e telas
estão funcionando corretamente no jogo. Você não pode esperar que a equipe
de QA carregue o protótipo da IU em um computador e então jogue o jogo e
compare as telas reais da IU com as do protótipo. Isso gera trabalho adicional,
trabalho para o qual eles não têm tempo; eles podem deixar passar uma parte
importante da funcionalidade se esquecerem de clicar em um botão.
Design
A documentação de design detalha como todos os recursos funcionarão no
jogo, inclusive os seguintes:
• IU
• Ambiente multijogador
• Históricos e diálogos dos personagens
• Pontuação
• Designs das missões
• Esquema de controle
• Ações do jogador
• Enredo
• IA
• Armas, objetos especiais, power-ups
• Reconhecimento de voz
Os documentos têm de fornecer detalhes suficientes para um programa-

dor, artista, testador de QA ou outro designer lê-los e saber implementar o
recurso como projetado. Após o recurso ser implementado de acordo com as
especificações da documentação, poderá ter sua funcionalidade testada e ser
ajustado conforme apropriado. A documentação deve ser atualizada se hou-
ver alterações, já que é o principal recurso escrito do design do jogo.
É útil a criação de uma lista abrangente de toda a documentação e dos
protótipos que devem ser gerados para o jogo. Essa lista pode ser usada como
base para as tarefas de design do cronograma de produção. Consulte o Capí-
tulo 16, “Planejamento do jogo”, para obter mais informações sobre a criação
de um cronograma.
REDIGINDO DOCUMENTOS DE DESIGN

Ubisoft
A melhor prática para a redação de documentos de design úteis é mantê-los curtos, preci-
sos e técnicos; como essa frase. Toda a documentação de design também deve seguir exa-
tamente os mesmos padrões e formatos. Isso deve ser rigidamente imposto. Há uma hora
e um local para os artistas e designers serem criativos – a documentação não é um desses
locais. Você terá uma capa, um sumário e três páginas com espaço duplo … cada página
adicional reduzirá à metade o número de pessoas que lerão o documento. Se as pessoas
não estiverem lendo a documentação, primeiro um produtor ou um associado deve impor
a formatação dos documentos para assegurar que eles sejam curtos, precisos e técnicos.
Se forem, e mesmo assim não estiverem sendo lidos, esses facilitadores devem agrupar as
pessoas em salas de reunião e ler os documentos em voz alta. Elas aprenderão a lê-los por
sua própria conta rapidamente. Para concluir, quanto às pessoas entenderem o conteúdo
de um documento … se ele for curto, preciso e técnico, e tiver sido lido, o designer e o
implementador terão de conversar. É simples assim.
Arte
A documentação da arte também é necessária durante a pré-produção. Os ti-
pos de documentação artística criados pelo artista líder e/ou o diretor de arte
são os seguintes:
• Guia de estilo
• Lista de assets
• Instruções de ferramentas
O guia de estilo detalha a aparência do universo, dos objetos e dos per-

sonagens que são retratados no jogo. Inclui arte conceitual, paletas de cores e
outros exemplos visuais da aparência final do jogo.
A lista de assets é uma lista abrangente de todos os assets de arte que
devem ser criados para o jogo. Inclui modelos de personagens, níveis, cine-
mática, texturas e qualquer outro elemento visual do jogo. Como ocorre com
os recursos, a priorização dos assets de arte em três camadas assegura que os
mais importantes sejam concluídos primeiro e que assets adicionais sejam
incluídos conforme o tempo permitir. A lista de assets de arte também pode
ser usada como base do cronograma de produção artística.
As instruções de ferramentas são documentos técnicos que fornecem in-
formações sobre como usar as ferramentas artísticas no pipeline de produção,
como a ferramenta de iluminação, a ferramenta de construção de níveis ou a
ferramenta de conversão cinemática. Essa documentação deve ser escrita em
conjunto com os programadores que estiverem programando as ferramentas.
CRIANDO A DOCUMENTAÇÃO ARTÍSTICA

Pandemic Studios
A fase de pré-produção é um momento em que todos discutem o design do jogo e a visão

artística e assumem compromissos – muitas ideias podem ser exploradas e consideradas
para a arte conceitual e a prototipagem. Também há várias tarefas artísticas que devem
ser concluídas antes da produção plena de assets poder começar. A equipe artística básica
deve ser composta por um diretor de arte, um artista conceitual e um criador de assets.
O objetivo é o diretor de arte prever a aparência que o jogo terá e então pedir ao artista
conceitual e ao criador de assets que criem diferentes conjuntos de assets para dar suporte
à visão. A partir desses assets, a aparência final poderá ser determinada e o trabalho na
documentação artística poderá começar.
A bíblia artística detalha a arte conceitual e outras referências dos assets de arte. Ela
demonstra para a equipe e o publicador qual será a aparência do jogo. Enquanto estiver
sendo criada, os assets de arte poderão ser prototipados, adicionados ao mecanismo e
visualizados no jogo. Esse processo permitirá que o diretor de arte tenha uma ideia clara
do que funciona ou não no jogo. Grande parte da criação desse documento é composta
por pesquisa; se o jogo se passar na Segunda Guerra Mundial, a equipe de arte vai querer
pesquisar locais, armas, uniformes e o que mais evocar esse período.
O diretor de arte trabalha junto ao designer líder para determinar como será desen-
volvida a direção de arte com base no conteúdo da história. O conteúdo da história terá
um efeito direto sobre qual será a visão artística final do diretor de arte.
Também durante a pré-produção, o diretor de arte trabalha com o programador
líder nos recursos que serão necessários no pipeline de produção de assets de arte. Isso
inclui tomar decisões sobre os shaders que serão usados, quais serão os limites dos po-
lígonos, que tipo de ambientes o mecanismo suportará e assim por diante.
Técnica
A documentação técnica é redigida pelo programador líder e discute assuntos
como os seguintes:
• Padrões de codificação
• Design técnico
A documentação sobre os padrões de codificação inclui especificações de

convenções de codificação, especificações de hardware e software, convenções
de nomenclatura, tecnologias usadas (inclusive middleware), tipos de arquivos,
layout de dados e qualquer outra informação técnica necessária para o desenvol-
vimento do jogo. A documentação também deve fornecer uma visão geral do que
todas as funções e dados fazem e como interagem uns com os outros.
A documentação de design técnico é a contrapartida da documentação

de design. Os programadores lerão os documentos de design e fornecerão in-
formações técnicas sobre como os recursos serão codificados para o jogo. Essa
documentação será divulgada para os programadores apropriados da equipe
para implementação.
As instruções de ferramentas fornecem informações de como as ferra-
mentas devem ser usadas. Por exemplo, um programador e um designer tra-
balharão juntos para documentar como as ferramentas de script funcionam.
As instruções devem ser atualizadas quando alguma alteração for feita na fun-
cionalidade da ferramenta; caso contrário, a documentação se tornará rapida-
mente inútil e até obsoleta.
CRIAÇÃO DA DOCUMENTAÇÃO TÉCNICA

1st Playbale
Parte da responsabilidade do programador líder de um projeto é elaborar um documento

de design técnico (TDD, technical design document) que descreva os sistemas de software
necessários à produção do jogo, englobando tanto sistemas existentes quanto sistemas
que tenham de ser desenvolvidos. Geralmente, ele trabalha nesse documento em paralelo
aos documentos de design do jogo (GDD, game design document) que estão sendo redi-
gidos pelos designers.
Um GDD detalhado será extremamente útil para os programadores quando eles
começarem a trabalhar no TDD, já que os ajudará a identificar a lista de recursos in-game
e as necessidades dos pipelines de arte e design requeridas no desenvolvimento desses as-
sets e em sua integração ao jogo. Se algumas áreas estiverem faltando no GDD, isso pode
causar problemas para a engenharia, resultando em um recurso importante não sendo
incluído no planejamento antecipado do software ou nos programadores não entenden-
do bem como um recurso deve funcionar. Por exemplo, se um dos chefes (o inimigo no
fim de um nível ou missão) não tiver uma descrição detalhada de seu comportamento, os
programadores não saberão quanto tempo reservar para a implementação de sua IA, ou,
uma vez implementada, o chefe não se comportará como o designer previu.
Exemplos e modelos detalhados devem ser incluídos em toda a documentação, já
que apenas palavras com frequência não conseguem definir totalmente a funcionalidade
desejada. O uso de referências de outros jogos é extremamente útil, sobretudo para con-
ceitos complexos como o comportamento da câmera e o estilo artístico. Por exemplo, se
você estiver descrevendo como a câmera se moverá no jogo, inclua exemplos dos movi-
mentos de câmera desejados e indesejados. Também é útil usar um filme como referência
de como o personagem se moverá no mundo do jogo.
Para concluir, o TDD deve ser amigável, o que nesse caso significa poder ser facil-
mente examinado pelas equipes de arte e design e não apenas por outros programadores
de software. Geralmente, a redação do GDD e do TDD é um processo iterativo, ou seja,

as informações de um afetam o outro. Por exemplo, o planejamento de memória no TDD
afetará coisas como o número de níveis ou o número de IAs exclusivas. O envolvimento de
todas as áreas na verificação de cada documento ajudará a identificar qualquer elemento
que tiver sido esquecido e a sincronizar mais rapidamente o design do jogo com as restri-
ções técnicas.
15.7 Análise de risco
Após ter definido os requisitos do projeto, conduza outra análise de risco

detalhada com a equipe. Você encontrará novos riscos a serem evitados quan-
do a produção começar, e outros riscos identificados mais cedo poderão ser
neutralizados ou removidos. Consulte o Capítulo 14, “Conceito do jogo”, para
obter informações detalhadas sobre como conduzir uma análise de risco.
IDENTIFICANDO RISCOS

Activision
Quando consigo me envolver em um projeto suficientemente cedo, gosto muito de iden-

tificar proativamente qualquer recurso ou nova tecnologia do jogo que seja um risco ao
cronograma. Após ter identificado esses riscos específicos, defino etapas de proteção
para serem executadas se as coisas começarem a atrasar. A ideia é que você tenha um
plano A e um plano B elaborados antecipadamente para não precisar se exasperar e tomar
decisões reativas se algo der errado. Após identificar os recursos que estão correndo risco
e definir as etapas de seu plano B, é importante fazer um acompanhamento regularmente
para ajudar os recursos em risco a avançar e identificar os sinais de alerta se algo não
estiver saindo como planejado. Quando manipulado corretamente, esse método ajuda
a manter os recursos problemáticos sendo monitorados por todos, o que aumenta suas
chances de sucesso e, na pior das hipóteses, reduz o impacto da remoção do recurso se os
objetivos originais não forem atingidos.
15.8 Aprovação
Após os requisitos do jogo serem definidos, apresente-os para os stakeholders

para aprovação. Como na fase conceitual, os stakeholders podem ter um feed-
back que queiram ver implementado antes de aprovar os requisitos.
Você não precisa esperar todos os requisitos serem definidos para buscar
aprovação. Em vez disso, convoque reuniões periódicas para apresentar para
aprovação os produtos requeridos concluídos. Isso permitirá que entregue os
produtos de maneira escalonada. Se houver um feedback a ser incluído, re-
serve alguns dias para implementá-lo e, então, reenvie para aprovação. Isso
mantém o processo em andamento durante a pré-produção sem que surjam
gargalos na espera de aprovação da gerência. Consulte o Capítulo 18, “Técni-
cas de produção”, para obter informações sobre como definir um processo de
aprovação eficiente.
15.9 Descrição da fase de requisitos do jogo
requisitos. Ela foi baseada em um ciclo de desenvolvimento de dois anos.
Em um ciclo de desenvolvimento de dois anos, a fase de requisitos do jogo

levará cerca de dois ou três meses para ser concluída. No entanto, essa fase
não terá uma data inicial e uma data final fixas; você pode ter de projetar um
recurso adicional durante a produção, corrigir o pipeline ou iniciar a produ-
ção de alguns aspectos do jogo enquanto conclui a pré-produção de outros.
O objetivo da fase de requisitos é um maior detalhamento das necessi-
dades de design, arte e técnicas do jogo. Isso inclui a redação de documenta-
ção; a tomada de decisões sobre as ferramentas, o pipeline e os produtos das
etapas; e a condução de uma análise de risco. Todas essas informações serão
usadas na criação do plano do jogo em que essas tarefas serão agendadas e um
orçamento será criado. O próximo capítulo apresentará detalhes das tarefas
que devem ser concluídas durante a fase de planejamento do jogo.
Etapa Recursos Cronograma geral Tarefas

Definição dos recursos Designer líder 1-2 semanas Os recursos básicos do jogo são definidos. Os
NO SITE do jogo recursos secundários e terciários também.
Definição dos produtos Produtor Contínua – cada lista de Defina as etapas principais do projeto e que
das etapas produtos das etapas é produtos cada uma terá de gerar. Estimativas
concluída cerca de 4 aproximadas das etapas baseadas na data de
semanas antes da finalização desejada.
finalização oficial da
etapa.
Avaliação da tecnologia Programador líder 4-6 semanas Avalie as necessidades de tecnologia do jogo
e faça uma recomendação.
Definição de Programador líder 2-3 semanas Defina o pipeline de produção que gerará uma
ferramentas e do trabalha com outros build jogável com assets atualizados.
pipeline líderes
Criação da arte Artista líder 2-3 semanas Gere o conceito dos personagens e cenários
conceitual principais do jogo.
Documentação de Designer líder 6-8 semanas Documente os recursos-chave do jogo, inclua
design protótipos onde possível.
Documentação artística Artista líder 6-8 semanas Documente a aparência artística do jogo, gere
listas de assets e escreva instruções de como
usar as ferramentas de arte.
Documentação técnica Programador líder 4-6 semanas Documente os padrões de codificação, o design
técnico e as instruções de ferramentas do jogo.
Análise de risco Produtor Contínua durante a fase Avalie os riscos do projeto, determine a
de requisitos estratégia de solução, divulgue para a equipe.
Aprovação Gerência do estúdio, 2-3 meses após a fase de Apresente todos os principais elementos de
publicador requisitos começar. jogabilidade para a gerência para aprovação,
incorpore seu feedback.
Figura 15.5 Descrição da fase de requisitos do jogo.

16
PLANEJAMENTO DO JOGO
Neste capítulo
• Dependências • Orçamentos • Terceirização
• Cronogramas • Equipe • Middleware
16.1 Introdução
Após os requisitos serem determinados, o plano do jogo é criado. Ele define

o seguinte:
• O trabalho que deve ser feito.

• A ordem em que o trabalho será feito.
• Quem fará o trabalho.
• Quando o trabalho deve ser concluído.
Todas as informações geradas durante a fase de requisitos são necessá-

rias na elaboração de um plano de jogo preciso. Há muitos livros úteis de ge-
renciamento de projetos que fornecem informações detalhadas sobre a criação
de planos de projetos. A maioria dessas técnicas é aplicável ao desenvolvi-
mento de jogos, embora algumas modificações possam ser necessárias. Pro-
ject Planning Scheduling and Control, terceira edição, de Jim Lewis, é leitura
recomendada, já que fornece informações práticas e fáceis de entender sobre
a criação de planos e o gerenciamento de projetos.
Lembre-se de que os requisitos podem mudar após o plano inicial do
jogo ser concluído. Por exemplo, o plano pode mostrar que será caro de-
mais criar o jogo e alguns dos requisitos terão de ser adaptados para o cus-
to baixar. Após a conclusão do plano inicial do jogo, alterações devem ser
esperadas durante a produção. Para criarmos um plano de jogo sólido, é
258 Parte V • Pré-Produção
importante conhecer as dependências do cronograma, do orçamento e do

planejamento de pessoal.
16.2 Dependências
Se as necessidades do orçamento, do cronograma e de pessoal não forem pla-

nejadas durante a pré-produção, você não conseguirá gerenciar esses elemen-
tos de maneira eficiente durante o processo de desenvolvimento. Em alguns
casos, talvez o conjunto de funcionalidades do jogo tenha de mudar para aco-
modar uma alteração no cronograma, como uma solicitação do publicador
para a antecipação da data de lançamento. Portanto, saber distribuir, no tem-
po alocado (cronograma), a equipe e o orçamento disponíveis (recursos), o
conjunto de funcionalidades do jogo (funcionalidades) e a qualidade espera-
da, como os elementos gráficos de última geração (qualidade), é extremamen-
te importante na elaboração do planejamento do jogo.
A Figura 16.1 ilustra essa dependência entre o cronograma, os recursos,
as funcionalidades e a qualidade. Se um desses fatores mudar, isso afetará os
demais. Se todos esses fatores estiverem constantemente mudando durante
o ciclo de desenvolvimento, o projeto nunca será estável e estará sempre em
risco. Um dos maiores desafios do produtor ao gerenciar o processo de de-
senvolvimento do jogo é obter um equilíbrio entre o cronograma, os recursos,
as funcionalidades e a qualidade. Como mencionado no decorrer deste livro,
todas as equipes de desenvolvimento são diferentes e nunca têm exatamente
os mesmos processos definidos ou riscos para manipular, mas o objetivo final
do produtor continua sendo lançar um jogo de qualidade a tempo e conforme
(ou menor que) o orçamento. Se o produtor controlar cuidadosamente o equi-
líbrio entre o cronograma, o orçamento e a equipe, haverá uma chance muito
maior desse objetivo ser atingido.
S
DE
CR
IDA
ON
AL
OG
ION
RA
QUALIDADE
NC
MA
FU
RECURSOS
Figura 16.1 Dependências entre o orçamento, o cronograma e as funcionalidades.
16 • Planejamento do Jogo 259
Quando trabalhar em cronogramas, orçamentos e planejamento de pes-

soal, você deve lembrar sempre dessas dependências para que o plano do
jogo seja preciso. O cronograma é um bom ponto de partida, porque durante
a pré-produção são geradas muitas informações que podem facilmente ser
transformadas em um cronograma robusto.
TRABALHANDO COM EQUIPES PEQUENAS
Paul Leska, presidente

Sapphire Software. Inc.
Nossa principal plataforma são os jogos de celulares – todos nós temos outros empre-
gos e os jogos de celulares são suficientemente pequenos para conseguirmos gerenciá-
-los confortavelmente com um ciclo de produção de seis a nove meses. Temos uma
equipe principal de três pessoas, e quando há algo em que não temos experiência, geral-
mente terceirizamos o trabalho. Os principais papéis se resumem mais ou menos a um
produtor e um diretor técnico, mas todos executamos várias tarefas no projeto, como
programação, trabalho com testadores e contato com o publicador. Achamos melhor
nos dedicarmos como um grupo a um único projeto, em vez de tentar desenvolver vários
jogos. Se a equipe fosse maior e os projetos mais lucrativos, faria mais sentido desenvol-
vermos vários jogos.
Quando começamos um jogo novo, fazemos uma lista das tarefas que devem ser
executadas nele e o produtor gerencia o processo. O nível de formalidade sobe quando
a complexidade do jogo aumenta. Quando estamos trabalhando em um jogo complexo
que ainda não vimos no mercado, fazemos alguma pesquisa e desenvolvimento, e às vezes
criamos um protótipo. Em algumas situações, fazemos apenas um protótipo em papel
para descobrir se as regras fazem sentido. Em outras, fazemos um protótipo flash para
verificar o funcionamento dos botões e do layout da tela em um celular específico. Se o
protótipo for bem-sucedido, criaremos um plano de projeto iterativo. O desenvolvimento
é feito em incrementos e as builds incrementais são enviadas para testadores beta. Isso
nos permite identificar problemas mais cedo – o projeto sofreria atrasos significativos se
esperássemos o jogo chegar à versão beta para testá-lo em um telefone e então descobrir
que não está sendo instalado corretamente. Esse teste incremental também nos permite
inserir possíveis feedbacks.
No passado, tentamos adicionar outro nível de formalidade ao processo de plane-
jamento com cada um elaborando uma planilha de recursos básicos. No entanto, todos
sabem muito bem o que fazer no jogo de acordo com o protótipo; portanto, planejar,
construir um protótipo e iterar nele é um bom ciclo devido ao tamanho de nossa equipe.
Se tivéssemos uma equipe maior, talvez executássemos esse processo mais formal incluin-
do a definição dos requisitos e a criação de um plano de jogo.
16.3 Cronogramas
Um cronograma lista cada tarefa que deve ser concluída, estimativas de duração
das tarefas, quem está executando a tarefa e que tarefas dependem de tarefas
existentes. Considere o uso de algum tipo de software de criação de cronogra-
mas, já que isso facilita o rastreamento das tarefas. O software de criação de
cronogramas permite que o usuário inclua novas tarefas e datas para ver como as
mudanças afetariam o cronograma geral. O Microsoft Project® é um software de
cronogramas popular que é útil na criação de cronogramas detalhados. Mesmo
se as datas e os elementos entregues mudarem, a lista de tarefas básica do crono-
grama permanecerá essencialmente a mesma, a menos que o recurso seja cortado
do jogo. Por exemplo, a seção de construção de níveis do cronograma descreve
cada tarefa necessária à construção de um nível. Ela poderia incluir a criação de
um conceito, a prototipagem, a construção da geometria básica, a criação de tex-
turas, o polimento dos assets e a correção de bugs. O que devemos lembrar é que,
mesmo se as datas mudarem, as mesmas tarefas terão de ser concluídas.
Os cronogramas de desenvolvimento de jogos podem ser extremamente
difíceis de criar e acompanhar. Em primeiro lugar, o crescimento desenfreado
de recursos ocorre exageradamente no desenvolvimento de um jogo, o que di-
ficulta a criação de um cronograma inicial e seu uso no decorrer do processo
de desenvolvimento. Em um ciclo de desenvolvimento de dois anos, o cres-
cimento desenfreado tem um impacto enorme; as pessoas veem um recurso
funcionando no jogo e acham que há muito tempo para mudar ou adicionar
funcionalidades para melhorá-lo. É por isso que é útil agendar pequenas eta-
pas ao longo do processo que possibilitem um controle melhor sobre os re-
cursos que estão sendo implementados e solicitações de recursos adicionais.
Na criação do cronograma de desenvolvimento do jogo, podemos nos
sentir pressionados a programar de seis meses a dois anos de trabalho no
começo do projeto. É difícil saber todas as tarefas que serão executadas. Mas
não deixe que isso o impeça de criar um cronograma útil o mais cedo possível
no processo de desenvolvimento. Mesmo se o cronograma mudar, o que com
certeza ocorrerá, é muito melhor ter um cronograma inicial do trabalho esti-
mado do que não termos nada para comparar quando mudanças ocorrerem no
cronograma. Por exemplo, se não houver um cronograma e o publicador lhe
disser que o jogo deverá ser entregue três meses mais cedo, como você saberá
que tarefas terão de ser cortadas do cronograma ou quantas pessoas terão de
ser adicionadas à equipe para esse objetivo ser atingido?
Envolva a equipe inteira na criação do cronograma. Geralmente, quando
dizemos às pessoas apenas para concluírem todo o seu trabalho dentro de um
prazo específico, sem explicar como essa data foi determinada ou por que ela é
importante para o projeto, elas não se comprometem com a data tão seriamen-
te. Já que não sabem qual será o impacto exato quando perderem seus prazos,
podem tratar a data de vencimento mais como uma diretriz do que como um
prazo. Quando isso ocorrer, o cronograma pode sair rapidamente de controle.
Se os membros da equipe forem envolvidos na criação do cronograma,
terão uma maior sensação de responsabilidade sobre suas tarefas e tratarão os
prazos com mais seriedade. Além disso, saberão melhor o volume de trabalho
que realizarão em um dia e poderão lhe informar com mais precisão quanto
tempo levarão para concluir cada uma das tarefas atribuídas. Também pode-
rão apontar áreas em que tarefas cruciais estão faltando e identificar áreas de
risco alto, médio e baixo no cronograma.
Criando um cronograma
A criação de um cronograma demora um pouco, principalmente durante a pré-
-produção, quando muitos elementos do jogo ainda não são definitivos. O pro-
dutor deve esperar gastar vários dias ou até mesmo semanas na elaboração de um
cronograma completo e continuará a atualizá-lo no decorrer da produção. Em-
bora demorado, o cronograma não será tão difícil de criar se você se concentrar
nas tarefas que realmente devem ser concluídas. Evite criar um cronograma com
base no que acha que precisa ser feito em vez do que realmente precisa ser feito.
Uma maneira de determinar apropriadamente as tarefas que devem ser
concluídas é definir critérios de saída. Os critérios de saída são um conjunto
predefinido de condições que devem ser atendidas antes de uma tarefa ser
considerada concluída. Eles são compostos principalmente por recursos tan-
gíveis que sejam facilmente definidos. Por exemplo, os critérios de saída da
fase conceitual são os seguintes:
• Conceito inicial
• Análise competitiva
• Apresentação demonstrativa
• Análise de risco
• Aprovação do conceito
• Lançamento do projeto
Quando todas essas etapas forem concluídas, a fase conceitual terá ter-
minado. Envolva a equipe na determinação dos critérios de saída de cada
fase da produção, com o critério de saída final sendo uma versão gold master
aprovada que possa ser fabricada e enviada para as lojas.
CRIANDO UM CRONOGRAMA PARA A ARTE

Pandemic Studios
O diretor de arte e o artista líder poderão fornecer estimativas para cada tarefa artística e
definir quais serão seus produtos finais. Ao criar o cronograma artístico, divida as tarefas
em tarefas menores que possam ser atribuídas a artistas individuais. Além disso, será útil
se você programar grupos de artistas para trabalhar em assets semelhantes e designar
alguém como ponto de contato desse grupo. Por exemplo, você poderia ter um grupo tra-
balhando em todos os modelos de personagens e veículos e outro trabalhando em todos
os objetos Havok destrutíveis do jogo.
Cronograma inicial
Um cronograma inicial é criado na pré-produção e comunicado para a equipe
de desenvolvimento para o planejamento das datas-chave. Comece o proces-
so de criação do cronograma listando os principais critérios de saída de cada
área do jogo: produção, aprovações, arte, engenharia, design, áudio, localiza-
ção, QA, fornecedores externos e marketing. Mais critérios de saída poderão
ser adicionados à medida que o desenvolvimento progredir.
Após esses critérios serem determinados, atribua datas estimadas. A Fi-
gura 16.2 é um exemplo de cronograma inicial de produção. Os principais
critérios de saída de cada fase do jogo foram listados e prazos serão atribuídos
para cada fase. Atualmente, só a data de envio para o fabricante do console
foi estimada, já que esse título deve ser entregue no Natal. Portanto, o obje-
tivo geral do plano de jogo é o ajuste dos outros fatores do projeto (recursos,
funcionalidades e qualidade) para que cumpram a data de entrega. A partir
dessa data de envio, você pode determinar um prazo geral para as datas da
primeira versão jogável, versão alfa, congelamento do código, versão beta e
código candidato à liberação, o que pode ajudá-lo a avaliar melhor o trabalho
a ser concluído em cada etapa.
Unidade de Justiça Data Notas

estimada
Idiomas: inglês, alemão, francês, italiano, espanhol
Produção
Fase conceitual concluída
Fase de requisitos concluída
Plano inicial do jogo concluído
Primeira versão jogável
Alfa
Congelamento do código
Beta
Envio para a Microsoft para pré-certificação
Código candidato à liberação
Envio para a Microsoft para certificação
Aprovações
Aprovação do conceito
Aprovação dos requisitos
Aprovação do plano do jogo
Aprovação de licenças
Aprovação do fabricante do console
Design
Produtos concluídos para a fase conceitual
Produtos concluídos para a fase de requisitos
Documentação detalhada dos recursos do jogo
Documentos de personagens e da história concluídos
Roteiros de voiceover concluídos
Missão e cenários projetados
Protótipos de missão roteirizados
Playtest
Missões finais roteirizadas
Figura 16.2 Exemplo de cronograma inicial de produção. (Continua)

Arte
Protótipos concluídos
Nível da primeira versão jogável concluído
Efeitos especiais concluídos
IU concluída
Cinemática concluída
Engenharia
Ferramentas de arte e design concluídas
Pipeline de produção concluído
Protótipos de engenharia concluídos
Todos os principais recursos da jogabilidade implementados
Congelamento do código
Áudio
Designs de som concluídos
Protótipos de som concluídos
VO provisório gravado
VO final gravado
Música final implementada no jogo
Localização
Determinação das necessidades de localização
Organização de recursos para tradução
Integração dos recursos
Teste de funcionalidade
Teste linguístico
QA
Plano de testes concluído
Teste da primeira versão jogável concluído
Teste da versão alfa concluído
Playtest concluído
Primeiro código candidato à liberação enviado para a QA
Cinemática (fornecedor externo)
Entrega das especificações iniciais para o fornecedor
Storyboard do fornecedor
Animática do fornecedor
Corte bruto do fornecedor
Filme final do fornecedor (sem som)
Filme enviado para o designer de som
Filme final pronto para o jogo
Marketing
Build de demonstração
Build para E3
Preview code para jornalistas
Review code para jornalistas
Figura 16.2 Exemplo de cronograma inicial de produção.
Embora os cronogramas iniciais de produção forneçam uma boa diretriz

para o processo geral de desenvolvimento, um cronograma mais detalhado
deve ser criado à medida que as informações forem confirmadas. Esse cro-
nograma detalhado terá subtarefas para todas as tarefas básicas listadas no
cronograma inicial. Os critérios de saída das tarefas detalhadas são baseados

nos produtos da fase conceitual e de requisitos:
• Lista mestra de recursos dividida em camadas

• Listas de produtos das etapas
• Documentação artística
• Documentação de design
• Documentação técnica
Esses produtos incluem informações detalhadas de quantos níveis, perso-

nagens e objetos devem ser criados, que recursos de engenharia serão codifica-
dos, a quantidade de voiceover a ser gravada e tudo o mais que for relacionado
ao projeto. Para determinar melhor todas as pequenas tarefas a serem executa-
das, podemos dividir esses produtos e tarefas maiores em itens menores.
Estrutura de divisão do trabalho

As Estruturas de Divisão do Trabalho (Work Breakdown Structure – WBS)
são úteis na divisão de tarefas grandes em itens menores. Na divisão de uma
tarefa maior em tarefas incrementais específicas, uma lista mestra de tarefas
é criada. Inicialmente, o processo WBS envolve os produtores e líderes, com
sugestões sendo dadas pela equipe quando necessário. Aqui está um exemplo
de processo WBS para a determinação das tarefas necessárias à criação de um
nível passível de entrega:
1. O produtor e os líderes se reúnem e definem as etapas tangíveis específi-
cas necessárias à criação de um nível e de uma missão do início ao fim.
Todos os departamentos são envolvidos – produção, arte, design, enge-
nharia e QA.
2. Durante a reunião, o grupo discute todas as tarefas que podem ser con-
cluídas para um nível. Descreva as tarefas no tempo presente, com um
verbo ativo. Por exemplo, “projeta o layout inicial do nível”. Isso ajudará
o grupo a determinar as tarefas tangíveis a serem executadas.
3. As tarefas são agrupadas por departamento e então colocadas em ordem
cronológica aproximada.
4. Durações são definidas para cada tarefa pelo líder apropriado. (O artista
líder fornece estimativas da arte e assim por diante.)
A Figura 16.3 é o exemplo de uma WBS para a criação de um nível de
Unidade de Justiça passível de entrega.
Cronograma detalhado
Quando a WBS for concluída, peça à equipe para verificá-la novamente para
assegurar que nenhuma tarefa seja esquecida. Essa lista de tarefas é então
adicionada ao cronograma do projeto, dependências são incluídas e os mem-
bros da equipe recebem suas tarefas. Eles devem avaliar a duração original
estimada pelo líder. Cada tarefa não deve demorar mais do que de três a cinco
dias. O ideal é que cada tarefa demore de um a dois dias. Se o responsável
pela tarefa concordar com essa estimativa, ela será mantida. Se ele discordar,
fornecerá uma estimativa atualizada, que será adicionada ao cronograma do

projeto. Esse processo faz os membros da equipe se sentirem mais respon-
sáveis por suas tarefas, em vez de sentirem apenas que receberam um prazo
arbitrário que deve ser cumprido incondicionalmente.
Tarefas de arte (Covil do vilão) Duração

Cria protótipo 5 dias
Implementa feedback do protótipo 1 dia
Cria geometria do nível 20 dias
Adiciona texturas provisórias 3 dias
Corrige primeira rodada de bugs 3 dias
Cria objetos destrutíveis 2 dias
Adiciona texturas finais 10 dias
Cria mapa de referência do jogador 5 dias
Cria efeitos especiais 2 dias
Otimiza nível de acordo com as restrições do orçamento 5 dias
Aperfeiçoa o mapa 5 dias
Corrige rodada final de bugs 3 dias
Tarefas de design (Covil do vilão) Duração
Projeta layout inicial do nível 2 dias
Projeta roteiro inicial da missão 2 dias
Roteiriza protótipo 5 dias
Executa playtest no roteiro do protótipo 5 dias
Roteiriza primeira passagem do enredo da missão 5 dias
Roteiriza primeira passagem do enredo multijogador 2 dias
Revisa roteiro 1 dia
Roteiriza segunda passagem 5 dias
Verifica se todos os arquivos de suporte estão marcados corretamente 1 dia
Cria marcas de localização para o diálogo in-game 1 dia
Aperfeiçoa o roteiro 3 dias
Corrige rodada final de bugs 2 dias
Tarefas de som (Covil do vilão) Duração
Cria design do som 3 dias
Implementa protótipo de design do som 2 dias
Implementa feedback do protótipo 2 dias
Conclui primeira passagem de implementação do som 3 dias
Aperfeiçoa o som 2 dias
Corrige rodada final de bugs 1 dia
Tarefas de QA (Covil do vilão) Duração
Executa playtest no protótipo 1 dia
Testa navegação na geometria e terreno 7 dias
Verifica texturas 2 dias
Testa o roteiro inicial 1 dia
Testa o roteiro da segunda passagem 1 dia
Testa pela última vez toda a geometria e as texturas do nível 5 dias
Testa pela última vez o roteiro da missão 1 dia
Aprovações (Covil do vilão) Duração
Aprova layout inicial 1 dia
Aprova protótipo de arte inicial 1 dia
Aprova protótipo de design inicial 1 dia
Aprova design de som 1 dia
Aprova nível, roteiro e som finais 1 dia
Figura 16.3 WBS de conclusão do nível Covil do Vilão.

Se houver alguma dificuldade na determinação de quanto tempo uma

tarefa levará, o líder deve fazer uma estimativa baseada na experiência. Não
deixe a duração de nenhuma tarefa em branco, porque assim você não terá um
retrato verdadeiro do cronograma geral. É muito subjetivo estimar tarefas pre-
cisamente, mas é algo que costuma melhorar com a experiência. É aconselhá-
vel a criação de algum tempo extra no cronograma para acomodar tarefas que
acabem demorando mais do que o estimado originalmente. Algumas pessoas
gostam de adicionar esse tempo extra por tarefa, embora não seja recomenda-
do porque não fornece um retrato preciso do cronograma geral. No entanto, a
inclusão de alguma folga no fim do cronograma fornece um bom espaço para
a acomodação de uma demora maior nas tarefas.
Uma técnica que pode ser usada na estimativa de tarefas se chama time-
-boxing. Um time-box é um período de tempo fixo durante o qual alguém ten-
ta concluir uma tarefa claramente definida. A tarefa deve ter cada um de seus
requisitos priorizados do mais importante ao menos importante para que o
trabalho mais crucial seja concluído primeiro. Para usar essa técnica, atribua
datas de início e de fim a uma determinada tarefa, designe alguém para traba-
lhar nela e então meça quanto é concluído no tempo alocado. Após o período
acordado terminar sem que o recurso tenha sido totalmente implementado,
avalie o trabalho que foi concluído e determine se ele deve continuar, se é su-
ficiente ou se o recurso deve ser cortado porque o esforço despendido indica
que ele demorará muito para ser implementado no prazo dado. Esse método
pode ajudá-lo a ter mais controle sobre o cronograma em vez de apenas deixar
que um recurso continue ultrapassando o prazo.
Por exemplo, se o programador líder fizer uma estimativa de três sema-
nas para implementar o mapeamento das normais no pipeline gráfico, entre
em contato com ele regularmente para verificar seu progresso. No fim de três
semanas, veja quanto da funcionalidade de mapeamento normal foi imple-
mentado. Nesse momento, o recurso pode estar em um nível suficiente para
ser entregue ou pode ser necessário um esforço adicional. Se for pedir ao pro-
gramador que invista mais tempo no recurso, determine um novo conjunto de
prioridades e defina um novo time-box.
Quando as durações forem atribuídas ao cronograma, adicione um tem-
po para dias de licença por doença, feriados e férias. Você não pode presu-
mir que todos os envolvidos estarão no escritório durante todos os dias de
trabalho. E não programe horas extras. Essa é uma prática inadequada e fará
rapidamente com que você tenha uma equipe insatisfeita e, portanto, impro-
dutiva. Em vez disso, limite o escopo do projeto para que tudo possa ser con-
cluído em um período de tempo razoável. Na verdade, as durações das tarefas
devem ser baseadas na execução de cinco a seis horas de trabalho durante um
dia de trabalho normal de oito horas. As outras duas ou três horas por dia são
o tempo que as pessoas passam verificando e-mails, indo a reuniões e lidando
com serviços gerais não relacionados às tarefas.
Lembre-se de que as dependências das tarefas e os recursos atribuídos
podem afetar drasticamente um cronograma. Por exemplo, se a aprovação do
protótipo demorar vários dias, a produção do nível será interrompida, um

tempo valioso será perdido e um gargalo será criado. Além disso, se alguém
estiver sobrecarregado com muitas tarefas, não conseguirá manter o mesmo
ritmo de trabalho das outras pessoas envolvidas no processo de produção do
nível e causará atrasos. Portanto, é importante assegurar que as dependências
e alocações de recursos corretas sejam incluídas no cronograma. A relevância
dessa atitude é mostrada melhor nas Figuras 16.4, 16.5, 16.6 e 16.7.
A Figura 16.4 é um cronograma detalhado de produção do nível Covil do
Vilão. Ele não inclui nenhuma dependência das tarefas ou recursos atribuí-
dos. Com base nesse cronograma, todas as tarefas de arte, design, som, QA e
aprovação levarão 15 dias para ser concluídas.
Figura 16.4 Um cronograma de produção de nível sem dependências ou recursos

atribuídos.
A Figura 16.5 é o mesmo cronograma de produção de nível com recur-

sos atribuídos. Agora que os recursos foram atribuídos, podemos ver que a
conclusão do trabalho demorará 63 dias. Esse aumento ocorreu porque há
apenas um artista, um designer, um designer de som e um testador disponí-
veis para fazer todo o trabalho e eles só podem trabalhar em uma tarefa de
cada vez. Se as tarefas fossem atribuídas a vários artistas e designers, o tempo
poderia ser reduzido.
NO SITE
Figura 16.5 Um cronograma de produção de nível com recursos atribuídos.
A Figura 16.6 é o mesmo cronograma de produção de nível, apenas com

as dependências de tarefas adicionadas. Agora o tempo programado aumen-
tou para 77 dias. Isso ocorreu porque há várias tarefas aguardando outra tarefa
ser concluída. Por exemplo, na seção de QA, podemos ver que o departamen-
to de QA tem mais de três semanas de tempo improdutivo entre as tarefas 36 e
37. Em um ambiente de desenvolvimento de jogos real, vários níveis estariam
em produção ao mesmo tempo, portanto, provavelmente o departamento de
QA estaria testando outro nível durante essas três semanas.
NO SITE
Figura 16.6 Um cronograma de produção de nível com dependências.
A Figura 16.7 é o mesmo cronograma de produção de nível com os re-

cursos atribuídos e as dependências adicionadas. Agora o trabalho requer
81 dias para ser concluído. Esse tempo poderia ser reduzido em alguns
dias com a atribuição de outro artista e outro designer ao projeto por al-
guns dias.
Estruturas de divisão do trabalho e cronogramas detalhados devem

ser criados para cada aspecto do projeto. Se o produtor e os líderes se com-
prometerem com essas tarefas, os cronogramas podem ser muito úteis para
todos na equipe. Além disso, após passar todo esse tempo criando o crono-
grama, empenhe um esforço equivalente no seu acompanhamento e atua-
lização.
NO SITE
Figura 16.7 Um cronograma de produção de nível com recursos atribuídos e de-

pendências.
Se estiver trabalhando em um ciclo de desenvolvimento de dois anos,

não tente criar um cronograma detalhado para o processo inteiro. Em vez
disso, dedique-se à criação de cronogramas detalhados para cada etapa do
projeto conforme apropriado. Isso lhe dará mais flexibilidade no cronograma,

e ajustes poderão ser feitos facilmente quando necessário.
CRONOGRAMAS DE DESIGN

Ubisoft
Do ponto de vista do design, o tempo reservado para a pesquisa (quando há) nunca é
suficiente e o tempo existente entre o fim de uma fase de pesquisa (se houver uma) e o
começo da produção é muito longo. Os dois a três meses que gastei fazendo pesquisas
para Splinter Cell Chaos Theory foram importantíssimos. Recentemente tive a oportunidade
de examinar novamente a documentação e as notas geradas durante essa fase e pude ver
que foi aí que o jogo nasceu. Também pude ver que não estávamos realmente prontos
para sair dela e que os itens que ainda não tinham sido compreendidos no fim da fase de
pesquisa acabariam trazendo muitos riscos à produção.
Rastreando tarefas
É importante que você faça o acompanhamento do cronograma para saber se
está dentro do prazo ou prestes a se atrasar. Manter a equipe informada sobre
o progresso do cronograma também é importante pelas mesmas razões. Se a
equipe não for informada sobre o progresso do cronograma, será como se es-
tivessem trabalhando sem cronograma algum; não saberão se as tarefas estão
ocorrendo corretamente e se estão cumprindo os prazos das etapas conjunta-
mente como uma equipe.
Após o cronograma ser definido, designe alguém da equipe para ser o
monitor oficial. Há várias maneiras de monitorar cronogramas e cada pes-
soa pode ter uma preferida de fazê-lo. Se estiver usando o Microsoft Project,
você poderá monitorar o tempo real comparando-o com o cronograma e fazer
ajustes conforme apropriado. Se alguém terminar um recurso mais cedo ou
mais tarde, o Microsoft Project fará novos cálculos e criará outro cronograma.
Se quiser usar o Microsoft Project para monitorar o cronograma, vale a pena
o investimento de treinar alguém para se tornar especialista no uso desse
software.
Uma maneira de monitorar tarefas de cronogramas mais simples ou di-
retos é pela sua impressão e afixação nas salas da equipe. À medida que
as tarefas forem sendo concluídas, elas devem ser coloridas no cronograma;
quando o cronograma estiver todo colorido, o projeto terá terminado. Esse é
um método eficaz para a equipe visualizar seu progresso e pode motivar o
anseio de todas as tarefas receberem cores o mais rápido possível.
A Figura 16.8 é um exemplo de planilha que rastreia o progresso dos

níveis produzidos para o jogo. Essa planilha é uma versão resumida das in-
formações contidas no cronograma de produção. Ela só apresenta os prazos
principais de conclusão de um mapa e não os detalhes de um cronograma de
desenvolvimento típico, e pode ser rapidamente examinada para mostrar o
progresso. Quando uma etapa é concluída, a célula é preenchida. Novamen-
te, essa é uma forte pista visual do progresso que está sendo feito. Portanto,
mesmo se ninguém se importar em verificar as datas, será possível ver rapida-
mente o volume de trabalho concluído em cada nível.
Nome Geometria Término Término Término dos Status

Artista Roteirista Notas
do nível concluída da arte do design recursos sonoros da QA
NO SITE Sala de John Jane Doe 1o de 15 de 22 de 22 de novembro Playtest
Justiça Doe outubro novembro novembro concluído
Covil do Bob Betty 7 de 15 de 22 de 22 de novembro Passará pelo Data de conclusão original
Vilão Smith Smith outubro novembro novembro playtest em da geometria seria 1o de
15 de outubro outubro, mas foi adiada
para 7 de outubro porque
o artista ficou alguns dias
doente.
Última atualização: 7 de outubro, 2007
Figura 16.8 Exemplo de uma planilha de produção de níveis.
Se alguém estiver atrasado em seu trabalho em uma etapa crucial, terá de

informar o mais rápido possível à pessoa que monitora o cronograma. A maio-
ria das pessoas sabe quando está atrasada em relação ao cronograma, mas
acha sempre que consegue se recuperar para cumprir uma etapa. Embora isso
possa ocorrer em alguns casos, continua sendo importante o conhecimento
de qualquer atraso antecipadamente para que contingências possam ser pre-
paradas. Alguns atrasos são críticos, ou seja, grandes partes do processo de
desenvolvimento são interrompidas. Por exemplo, se a ferramenta de script
não estiver concluída quando os designers tiverem de começar a roteirizar os
níveis, o roteiro ficará em estado de espera até a ferramenta ser terminada.
Isso colocará o cronograma de design em risco e ele terá de ser ajustado para
acomodar esse atraso. Em outras áreas, o atraso será menos problemático; as
texturas artísticas finais do modelo do personagem ficarão atrasadas em al-
guns dias.
Se você for informado sobre os atrasos antecipadamente, terá uma opor-
tunidade melhor de elaborar um plano contingencial para mitigar os riscos
ao cronograma. Por exemplo, uma etapa está terminando e é esperado que
o jogo já esteja com todos os recursos e conteúdo provisório. Você descobre
com uma semana de antecedência que o Artista A acha que talvez não consiga
concluir seu nível. Já que obteve essa informação com antecedência, pode
atribuir um recurso adicional para ajudá-lo a se recuperar ou alterar o cro-
nograma de testes para que esse mapa seja o último a ser verificado no ciclo
de testes, ganhando os dias extras necessários à conclusão do nível. Consulte

o Capítulo 18, “Técnicas de produção”, para obter mais informações sobre
como manipular atrasos no cronograma.
Uma coisa é certa – o cronograma não se monitorará sozinho. Alguém
terá de fazer um acompanhamento com cada membro da equipe regularmente
e manter o cronograma atualizado com o trabalho de todos. Alterações tam-
bém devem ser adicionadas ao cronograma imediatamente; caso contrário, a
pessoa que estiver monitorando o cronograma não terá um retrato preciso de
onde é esperado que as pessoas estejam em suas tarefas.
A pessoa encarregada de monitorar o cronograma pode facilitar essa ta-
refa lembrando à equipe prazos iminentes. Por exemplo, e-mails podem ser
enviados para lembrar a equipe de etapas cruciais do projeto. Esses e-mails
devem ser curtos e simples. Essa pessoa também deve fazer um acompa-
nhamento com cada membro da equipe regularmente (pelo menos uma vez
por semana) para verificar o progresso. Se alguém estiver sempre perdendo
prazos, o monitor do cronograma deve estar com essa pessoa diariamente
e ajudá-la na organização de seu trabalho para que ela aprenda a gerenciar
melhor seu tempo.
PROGRAMANDO-SE PARA TRABALHAR

COM VÁRIAS PLATAFORMAS

Activision
Pela minha experiência, a melhor maneira de manipular lançamentos para várias plata-
formas é 95% da equipe se dedicar à plataforma principal e os 5% restantes manterem-se
algumas etapas atrás da equipe básica trabalhando em questões específicas das platafor-
mas. Um erro que muitos desenvolvedores cometem é não atribuir desenvolvedores talen-
tosos a plataformas específicas, esperando que algum dos talentos da equipe assuma a
tarefa. Na prática, isso nunca funciona, já que as pessoas talentosas ficam inevitavelmen-
te sobrecarregadas e as plataformas secundárias recebem menos atenção do que as prin-
cipais. Se você puder designar membros específicos da equipe às plataformas secundárias,
eles darão a atenção necessária à plataforma que lhes foi atribuída.
Outro aspecto de um lançamento para várias plataformas que com frequência é igno-
rado é o investimento em uma cadeia de ferramentas que dê suporte a todas as plataformas
envolvidas no desenvolvimento. Por exemplo, se você puder preparar ferramentas de arte
que permitam que os artistas trabalhem no nível máximo de detalhes suportado por sua
plataforma de console mais poderosa e então fazer as ferramentas ajustarem automatica-
mente os assets de arte para acomodar sua plataforma mais fraca, reduzirá muito o traba-
lho em casos especiais. Um pouco de pré-planejamento ajuda a reduzir o incômodo que
um lançamento multiplataforma poderia causar mais adiante no ciclo de desenvolvimento.
16.4 Orçamentos
Após o cronograma inicial ser criado, você poderá criar o orçamento. O orça-
mento deve estar em sintonia com a qualidade, o escopo e o cronograma para
que o jogo gere lucro ao ser lançado. O publicador também observa o resultado
com cuidado para assegurar que os custos de desenvolvimento sejam justi-
ficáveis e que o investimento no jogo seja lucrativo. Por fim, o produtor é o
responsável pelo gerenciamento dos custos. Se o desenvolvimento do jogo for
mal planejado, demandará mais tempo ou pessoal e, portanto, custará mais, re-
sultando em margens de lucro menores. Se for planejado de maneira eficiente,
será mais fácil identificar áreas com potencial para economia de custos.
Para determinar a provável lucratividade do jogo, o publicador cria um
demonstrativo de lucros e perdas (profit-and-loss statement – P&L). Um P&L,
que mede os lucros e as perdas gerais de um jogo, é uma planilha que faz
a comparação entre os custos de desenvolvimento, marketing, embalagem e
distribuição e as vendas projetadas. Se a estatística de vendas projetadas au-
mentar, haverá mais chances de lucro. Por exemplo, se ficar determinado que
20 mil cópias podem ser vendidas, o orçamento será menor do que para um
jogo cuja previsão de vendas for de 500 mil cópias. O P&L é usado na simula-
ção de diferentes cenários de lucratividade e na determinação de um equilí-
brio aceitável entre custos e possíveis lucros.
Já que o cronograma, o orçamento e o planejamento de pessoal depen-
dem uns dos outros, o orçamento pode mudar notadamente dependendo de
qual for seu cronograma e planos de pessoal. Portanto, ao criar um orçamento
inicial, esteja preparado para fazer ajustes nele e nos outros elementos quan-
do necessário. Após o orçamento ser estabelecido e aprovado, gerencie os
custos minuciosamente para não se desviar dele.
Haverá momentos em que surgirão custos inesperados – por exemplo,
você pode ter de comprar três computadores novos e três cópias do 3DS Max
–, portanto, não se desespere quando isso ocorrer. Talvez você consiga realo-
car alguma verba do orçamento para esses itens sem aumentar seu orçamen-
to geral. Se isso não funcionar, talvez possa realocar computadores de outro
projeto do estúdio e usá-los temporariamente. Apenas lembre-se de ficar o
máximo possível alerta para os custos quando esses problemas ocorrerem.
Criando um orçamento
Os orçamentos são compostos por todos os custos associados ao projeto, in-
clusive pessoal, custos indiretos (aluguel, serviços de utilidade pública e
taxas), hardware e software. Determine todos esses custos antecipadamente
para que não haja surpresas durante o processo de desenvolvimento.
Ao criar o orçamento, consulte os requisitos e o cronograma do jogo
para determinar os custos a serem planejados. Esses documentos fornecem
diretrizes sobre a verba necessária em certas áreas do jogo. Não suponha
automaticamente que o item mais barato é a melhor solução, já que isso

acabará afetando a qualidade do jogo. Por exemplo, se o jogo tiver de ser
concluído em um ano com qualidade máxima, provavelmente você não vai
querer fazer cortes de pessoal e contratar iniciantes. Vai preferir investir em
pessoas mais experientes que possam trabalhar de maneira eficaz dentro de
um cronograma apertado. No entanto, se tiver vários anos para concluir um
jogo, talvez queira contratar alguns iniciantes e treiná-los para que ganhem
experiência para o próximo projeto.
Decisões desse tipo são tomadas mais apropriadamente quando levamos
todos os elementos do jogo em consideração. A essa altura, os objetivos prin-
cipais do jogo já foram aprovados e os requisitos definidos, portanto, você
tem uma boa ideia de se o jogo será um título controlado por orçamento ou
se será de nível AAA. Além disso, os requisitos do jogo indicam a tecnologia
que está sendo usada; logo, você sabe quais são as necessidades de hardware e
software. O cronograma define o tempo disponível e quantas pessoas são ne-
cessárias. É claro que cada projeto terá um orçamento diferente dependendo
dos requisitos do jogo, mas há elementos comuns que devem ser planejados
em todos os orçamentos.
Comece criando uma lista de todos os principais itens que devem ser
considerados no orçamento – isso inclui tanto custos com pessoal quanto ou-
tros custos importantes. A Figura 16.9 lista alguns desses itens.
Custos com pessoal
NO SITE Profissionais de arte

Profissionais de design
Profissionais de engenharia
Profissionais de produção
Profissionais de QA
Profissionais de áudio
Outros custos importantes
Hardware
Software
Taxas de licenciamento de PI
Fornecedores externos
Alimentação
Expedição
Materiais de escritório
Custos indiretos (benefícios de RH, seguro, espaço no escritório etc.)
Figura 16.9 Principais itens do orçamento.
Em seguida, da mesma forma que manipulou as principais tarefas do cro-

nograma, faça a divisão em itens menores. Use as informações do cronograma
para determinar todas as necessidades de pessoal e as informações dos requi-

sitos para determinar todas as necessidades de hardware e software. A Figura
16.10 é um exemplo de custos de pessoal dividido em itens menores.
Após determinar todos os itens, crie seu orçamento. A Figura 16.11 é um
exemplo de orçamento dos custos de pessoal de um projeto. Nesse exemplo, o
número de pessoas de cada tipo é indicado na coluna “Número”, que é então
multiplicada pela “Taxa mensal” e pelo “Número de meses” necessários em
um projeto. Todos esses custos são somados para fornecer o total geral.
Profissionais de Arte
NO SITE Diretor de arte

Artista líder
Artista conceitual
Construtor de mundos
Criador de assets
Animador
Artista técnico
Artista de marketing
Profissionais de Design
Diretor de criação
Designer líder
Designer
Redator
Profissionais de Engenharia
Diretor técnico
Programador líder
Programador de rede
Programador de som
Programador de ferramentas
Programador de IA
Programador de jogabilidade
Profissionais de Produção
Produtor executivo
Produtor
Produtor associado
Profissionais de QA
Analista líder de QA
Testador
Figura 16.10 Divisão dos custos de pessoal.

Profissionais de Produção Número Taxa no de meses Custo

Produtor 1 US$8.000 24 US$192.000
NO SITE
Produtor associado 3 US$6.000 18 US$324.000
Profissionais de Arte
Artista líder 1 US$10.000 24 US$240.000
Artista técnico 1 US$8.000 24 US$192.000
Artista conceitual 2 US$6.000 10 US$120.000
Construtor de mundos 10 US$6.000 12 US$720.000
Artista de objetos 3 US$6.000 8 US$144.000
Artista de texturas 4 US$6.000 12 US$288.000
Artista de marketing 1 US$6.000 12 US$72.000
Animador 3 US$8.000 8 US$192.000
Profissionais de Engenharia
Engenheiro líder 1 US$10.000 24 US$240.000
Programador de rede 2 US$8.000 16 US$256.000
Programador gráfico 4 US$8.000 18 US$576.000
Programador de IU 1 US$8.000 12 US$96.000
Programador de IA 4 US$8.000 18 US$576.000
Programador de som 1 US$8.000 12 US$96.000
Programador de ferramentas 3 US$8.000 18 US$432.000
Programador geral 5 US$8.000 18 US$720.000
Programador de IA 2 US$8.000 12 US$192.000
Profissionais de Design
Designer líder 1 US$8.000 24 US$192.000
Designer 4 US$6.000 18 US$432.000
Designer de som 1 US$6.000 12 US$72.000
Redator 1 US$6.000 6 US$36.000
Profissionais de QA
Analista líder de QA 1 US$8.000 24 US$192.000
Testador 20 US$6.000 10 US$1.200.000
Total geral 80 US$7.792.000
Baseado em ciclo de desenvolvimento de 24 meses

As taxas mensais são somente um exemplo, não refletem as taxas reais
Figura 16.11 Exemplo de orçamento dos custos de pessoal de um projeto.
A Figura 16.12 é um exemplo de orçamento dos outros custos de um

projeto. Nesse exemplo, a coluna “Número” é usada para indicar o número de
aquisições de um determinado item – como 10 computadores. Ela é multipli-
cada pela coluna “Taxa” para que seja calculado o “custo” total de cada item.
Esses custos, por sua vez, são somados ao total geral.
Após o orçamento de desenvolvimento ser determinado, ele poderá ser
adicionado ao demonstrativo P&L do publicador para demonstrar se o título
gerará lucro. Se não gerar, você será solicitado a fazer ajustes no orçamento e
no cronograma até torná-los satisfatórios.
Gerenciando um orçamento
Como o cronograma, você terá de monitorar seu orçamento durante o proces-
so de desenvolvimento. A mesma pessoa que for designada como monitor do
cronograma também é um bom candidato a ser o monitor do orçamento. Qual-
quer gasto do orçamento deve ser controlado semanalmente, ou pelo menos
mensalmente.
Hardware Número Taxa Custo
NO SITE Computadores 80 $ 3.000 $ 240.000

Kits de desenvolvimento do console 40 $ 10.000 $ 400.000
Controladores 60 $ 100 $ 6.000
Placas gráficas 80 $ 300
Software
Perforce 76 $ 750 $ 57.000
3DSMax 19 $ 4.000 $ 76.000
Photoshop 4 $ 600 $ 2.400
MS Project 5 $ 1.000 $ 5.000
Unreal Engine 3.0 1 $ 1.000.00 $ 1.000.000
Visual C++ 23 $ 3.000 $ 69.000
Taxas de licenciamento
Royalties de Unidade de Justiça 1 $ 500.000 $ 500.000
Voiceover 1 $ 250.000 $ 250.000
Música 1 $ 50.000 $ 50.000
Cinemática 1 $ 300.000 $ 300.000
Localização 4 $ 50.000 $ 200.000
Outros
Viagens 24 $ 1.000 $ 24.000
Alimentação 24 $ 500 $ 12.000
Expedição/Postagem 24 $ 200 $ 4.800
Total geral $ 3.220.200

As taxas são somente um exemplo, não refletem as taxas reais
Figura 16.12 Exemplo de orçamento de outros custos.
O departamento de contabilidade do estúdio ou do publicador também

participará da monitoração do cronograma. Eles terão registros de todas as
despesas feitas – salários, compras de hardware e custos de fornecedores ex-
ternos – e alocarão esses itens de acordo com o seu orçamento para o jogo.
Serão uma boa fonte de informações se você precisar saber o total gasto no
jogo em um determinado momento.
Mantenha registros detalhados de qualquer despesa. Cada estúdio tem
um processo diferente para pagamento de despesas, portanto, verifique com
o departamento de contabilidade e a gerência do estúdio que formulários de-
vem ser preenchidos para comprar materiais, pagar um fornecedor ou contra-
tar novos membros para a equipe. Por exemplo, se você estiver pagando um
fornecedor externo, talvez tenha de pedir a ele uma fatura e uma declaração
de trabalho detalhada. Após recebê-los, pode ter de preencher um formulá-
rio de solicitação de cheque e enviá-lo para a contabilidade para pagamento.
Provavelmente, o formulário pedirá informações gerais sobre a despesa: se ela
estava prevista e a que parte do orçamento se aplica. Após toda a papelada ser
recebida, a contabilidade emitirá um cheque e o enviará para o fornecedor.
Se achar que o projeto está ultrapassando o orçamento, não ignore o pro-
blema porque ele não desaparecerá. Em vez disso, reserve algum tempo para
reavaliar o planejamento do jogo e determine se há algum ajuste que possa ser
feito no cronograma, na equipe ou no escopo do projeto.
16.5 Equipe
O cronograma detalha o trabalho que precisa ser feito e o plano de pessoal de-
termina quem o fará. Quando esses elementos são combinados, e os recursos
são adicionados ao cronograma, ele determina quando o trabalho estará total-
mente concluído. Portanto, é importante conhecer as fortes dependências entre
o plano de pessoal e o cronograma. O plano de pessoal também é afetado pelo
orçamento; se você tiver de contratar pessoas adicionais para concluir o traba-
lho, precisará de dinheiro do orçamento para fazer isso. Se não tiver condições
de contratar mais pessoas, terá de reduzir o escopo do trabalho para que as que
estão disponíveis possam concluí-lo a tempo e conforme o orçamento.
Seu plano de pessoal será em grande parte baseado nas tarefas que terão
de ser concluídas. Por exemplo, se o jogo demandar 10 modelos de persona-
gens e cinco níveis, você precisará de vários artistas para fazer esse trabalho.
Se o jogo estiver utilizando tecnologia de ponta, você vai querer ter programa-
dores suficientes no projeto para prototipar, codificar e depurar. No exemplo
de cronograma ilustrado na Figura 16.7, o cronograma pode ser adiantado em
alguns dias se mais artistas e designers forem adicionados ao projeto. Como
você pode ver, é útil adicionar ou remover pessoas no cronograma para saber-
mos o efeito que isso terá nos prazos. Após encontrar um bom equilíbrio entre
as tarefas a serem concluídas e as pessoas necessárias, você poderá definir seu
plano final de pessoal.
Em geral, a fase de pré-produção inclui um pequeno grupo de pessoas
que estarão no projeto até o fim. Durante a produção, pessoas entrarão e sai-
rão do projeto conforme apropriado. Na versão beta, a equipe estará reduzida
novamente a um pequeno grupo de pessoas que corrigirão bugs e liberarão
o código do jogo. Todas essas mudanças na equipe estarão refletidas em seu
cronograma de produção. A Figura 16.13 é um exemplo da lista de pessoal
parcial de um jogo com ciclo de desenvolvimento de dois anos. As informa-
ções foram extraídas do cronograma e contêm uma visão geral do período de
tempo durante o qual as pessoas serão necessárias no projeto.
Papel Duração Notas

Artista líder 24 meses Necessário na pré-produção, produção e liberação do código.
NO SITE
Artista conceitual 10 meses Necessário na pré-produção e em parte da produção.
Construtor de mundos 1 12 meses Necessário na produção.
Artista de texturas 1 8 meses Começa após a geometria da primeira rodada de níveis ter sido concluída.
Artista de texturas 2 8 meses Começa após a geometria da primeira rodada de níveis ter sido concluída.
Designer líder 24 meses Necessário na pré-produção, produção e liberação do código.
Designer 1 18 meses Necessário na produção.
Roteirista 1 8 meses Começará após a primeira rodada de níveis ser construída e texturizada.
Roteirista 2 8 meses Começará após a primeira rodada de níveis ser construída e texturizada.
Produtor 24 meses Necessário na pré-produção, produção e liberação do código.
Programador líder 24 meses Necessário na pré-produção, produção e liberação do código.
Programador – ambiente 16 meses Tem de começar logo após a pré-produção.
multijogador
Programador – ferramentas 18 meses Tem de começar logo após a pré-produção.
Analista líder de QA 24 meses Necessário na pré-produção, produção e liberação do código.
Testador 1 10 meses Meio expediente na versão alfa, tempo integral no congelamento do código.
Figura 16.13 Exemplo de lista de pessoal parcial.
16.6 Terceirização
A terceirização do trabalho para um fornecedor externo é uma boa maneira de

economizar tempo e possivelmente dinheiro do projeto. Se quiser, use uma
empresa de animação na criação do filme introdutório do jogo para que seus
artistas possam se dedicar à criação do conteúdo in-game. É claro que o uso
de um fornecedor externo economiza tempo da equipe de desenvolvimento
interna, já que esta não será responsável por concluir uma determinada seção
do trabalho. Dinheiro será economizado se o fornecedor fizer algo mais rapi-
damente e/ou com menos custos do que a equipe de desenvolvimento inter-
na, como as gravações de voiceover.
Há muitos tipos de serviços de desenvolvimento de jogos que você pode
terceirizar sem afetar a qualidade ou o cronograma do projeto. Essas áreas en-
volvem os assets de design e arte, já que eles tendem a ter conjuntos de tarefas
distintos que não dependem do trabalho de várias partes da equipe. Outras
atividades que podem ser terceirizadas são as seguintes:
• Cinemática e animação
• Captura de movimentos
• Voiceover
• Música
• Efeitos sonoros
• Redação
• Localização
A terceirização de tarefas de engenharia não é recomendada, porque elas

dependem mais umas das outras, e mesclagens de código podem ser demo-
radas, o que torna difícil fazer testes regularmente em códigos terceirizados.
Além disso, um fornecedor de serviços de engenharia precisará de acesso ao
código-fonte, que é altamente confidencial, e terá de preparar um ambiente de
desenvolvimento que se equipare exatamente ao que a equipe de engenharia
interna está usando.
Antes de contatar um fornecedor externo, defina claramente o escopo do
trabalho que será terceirizado. Quanto mais cedo o escopo do trabalho for defi-
nido, mais preparado ficará o fornecedor para estimar precisamente a carga de
trabalho e concluí-lo a tempo. Forneça também todas as informações necessá-
rias do jogo para o fornecedor, já que isso o ajudará a planejar melhor seu tra-
balho. Por exemplo, se estiver contratando um fornecedor externo para compor
música para o jogo, será útil mostrar a ele a arte conceitual, protótipos jogáveis,
o guia de estilo e qualquer outra coisa que possa ajudá-lo a ter uma boa ideia de
qual é a visão do jogo e que tipo de música combinará melhor com essa visão.
Como em qualquer projeto, há prós e contras em se trabalhar com forne-
cedores externos. Acima de tudo, o uso de um fornecedor pode economizar
tempo e recursos durante o processo de desenvolvimento, tornando mais pro-
vável que o jogo seja terminado a tempo. Outro benefício é que a equipe pode
se concentrar somente em suas tarefas no jogo e passar algum tempo adicional
balanceando a jogabilidade dos recursos, corrigindo bugs e polindo os assets
para o jogo ficar o melhor possível. Se você selecionar fornecedores altamente
especializados em uma área, a qualidade de seu trabalho será alta e contri-
buirá para a qualidade geral do jogo, deixando que os membros da equipe se
concentrem nas áreas em que são melhores.
Há algumas desvantagens em se trabalhar com um fornecedor, como os
custos adicionais envolvidos. Mas se o projeto for grande e complexo, o tem-
po e os recursos economizados nos esforços internos de desenvolvimento po-
dem compensar o custo do fornecedor externo. Outra desvantagem é que o
desenvolvedor perde a flexibilidade de reorganizar os produtos do projeto e
os prazos internos. No trabalho com um fornecedor, o desenvolvedor deve
ser organizado e confiar na habilidade da equipe em cumprir datas de etapas-
-chave. Ele tem de dar ao fornecedor os assets necessários quando necessário.
Por exemplo, um fornecedor de cinemática pode precisar dos modelos finais
dos personagens para concluir a versão final do filme. O fornecimento dessas
informações demandará que o desenvolvedor pense com meses de antecedên-
cia no ciclo de produção para dar estimativas precisas para o fornecedor.
Outro grande risco da terceirização é que o fornecedor pode não cumprir
seus prazos. Isso pode afetar gravemente o projeto se os prazos forem muito
apertados. Para diminuir esse risco, certifique-se de reservar um tempo amplo
no cronograma para encontrar um fornecedor. Além disso, após obter o crono-
grama do fornecedor, adicione a ele algum tempo extra para que haja folga se
necessário. Não é uma boa ideia marcar um prazo para o fornecedor que coin-
cida com o de conclusão de uma etapa importante. Por exemplo, não peça ao
fornecedor para entregar a cinemática ou a música final na data de conclusão

da versão beta; planeje a entrega pelo menos para uma semana antes.
Se o fornecedor estiver se atrasando em relação ao cronograma e todos os
assets e documentos necessários tiverem sido entregues a ele pela equipe de
desenvolvimento, estaremos com um problema. Para evitá-lo, programe pra-
zos regulares para o fornecedor também. Ele deve se habituar a fazer entregas
toda semana ou após alguns dias, dependendo do trabalho a ser realizado.
Se perder algum desses prazos, isso será um sinal de alerta de que pode estar
prestes a perder o prazo final, que é o mais importante.
Em alguns casos, o fornecedor pode convencê-lo de que tudo vai indo
bem e então perder o prazo final. Se a situação for assim tão ruim, talvez você
tenha de diminuir as perdas procurando outro fornecedor para concluir o tra-
balho ou executá-lo internamente designando alguém da equipe de desenvol-
vimento para terminá-lo. Essa não é uma situação ideal, já que significa que as
pessoas terão de fazer hora extra para terminar o trabalho.
Comunicação
Após o fornecedor externo ser contratado, o segredo para um bom relacio-
namento é uma comunicação eficaz. Se o desenvolvedor e o fornecedor não
estabelecerem o canal de comunicação antecipadamente, informações não
chegarão à outra parte e detalhes-chave serão perdidos. Uma comunicação in-
satisfatória também pode afetar a habilidade do fornecedor cumprir os prazos
propostos, principalmente se informações necessárias do desenvolvedor não
forem recebidas a tempo.
A maioria dos fornecedores externos tem um gerente de projeto que é res-
ponsável por gerenciar do início ao fim a parte do processo de desenvolvimen-
to que cabe ao fornecedor e atuar como contato primário com o desenvolvedor.
É importante que apenas uma pessoa da equipe de desenvolvimento seja
designada para ser o contato primário com o gerente de projeto do fornecedor.
Esses dois devem se comunicar diariamente, mesmo se for apenas para forne-
cer uma breve atualização de status do que ocorreu nesse dia com o projeto.
Se mais pessoas forem envolvidas na cadeia de comunicação, pode haver con-
fusão. Se for necessário que algumas pessoas da equipe de desenvolvimento
tenham contato com o fornecedor, como a que está cuidando do voiceover do
jogo, as linhas de comunicação devem ser claramente definidas para que não
haja confusão quanto às responsabilidades dos membros da equipe.
O contato interno da equipe de desenvolvimento é responsável por en-
tregar todos os assets e recursos necessários ao fornecedor e deve informar a
ele sobre qualquer mudança no cronograma que afete seus prazos. Se o forne-
cedor não for informado de um atraso no cronograma que afete seu trabalho,
você pode acabar pagando mais do que o necessário porque ele recebeu os
assets com atraso, teve de fazer hora extra ou contratou mais pessoas para
cumprir o prazo. Se o fornecedor for flexível, mudanças imprevistas no cro-
nograma poderão ser acomodadas.
INVESTIGANDO FORNECEDORES

Activison
Muitas vezes os melhores fornecedores são encontrados por referência, da mesma forma
que encontramos os melhores membros para trabalhar em tempo integral na equipe por
recomendação pessoal. Raramente contrato fornecedores sem uma recomendação pes-
soal, mas, quando isso ocorre, o melhor a fazer é investir algum tempo em uma investiga-
ção cuidadosa. Examinar trabalhos passados, assistir a demos, reunir-se com os fornece-
dores e verificar suas referências pode significar a diferença entre um parceiro produtivo e
um que você libere devido a diferenças criativas.
Como quase tudo na produção, o pré-planejamento e o raciocínio antecipado são
essenciais. A maioria dos desenvolvedores contrata profissionais autônomos mais tarde no
processo de desenvolvimento quando percebe reativamente que não tem os recursos que pre-
cisa para concluir o trabalho. Os melhores produtores são proativos e identificam a necessi-
dade de contratar recursos no início do desenvolvimento para poderem encontrar as pessoas
mais apropriadas, retê-las com antecipação suficiente para serem úteis e obter o melhor
acordo possível para a empresa quando esta não está sob pressão para contratar alguém.
16.7 Middleware
Na indústria de jogos, middleware se tornou um termo abrangente para um soft-

ware pronto para uso que possa ser modificado e empregado em um jogo. O mid-
dleware é usado em sistemas do jogo, como na IA, animação, física, renderização
e comunicação em rede. Por exemplo, os desenvolvedores podem licenciar o
mecanismo de física Havok e modificá-lo para ser usado em seu jogo, em vez
de programar algo a partir do zero. Mecanismos de jogo para várias plataformas,
como o Unreal3 da Epic, são considerados middleware, assim como outras fer-
ramentas de terceiros usadas em tarefas de desenvolvimento como modelagem,
texturização, rastreamento de bugs e gerenciamento de projetos.
RECURSOS DE MIDDLEWARE
A GameMiddleware.org – www.gamemiddleware.org – é uma organização que fornece uma

central de middleware para jogos. Ela mantém uma lista atualizada dos middlewares dispo-
níveis que podem ser usados no desenvolvimento de jogos, junto com as plataformas que
cada middleware suporta e um link para o site do fornecedor. Os middlewares são agrupa-
dos em várias categorias diferentes para facilitar a determinação do que cada um faz.
Um dos maiores benefícios do middleware é que teoricamente o desen-

volvedor pode passar mais tempo criando e polindo recursos exclusivos do
jogo, em vez de criar um recurso genérico mas necessário, como o suporte ao
lobby de um jogo on-line. Quando o desenvolvedor está familiarizado com
a tecnologia de middleware (por exemplo, ele a usou em jogos anteriores),
geralmente é uma decisão fácil usá-la novamente em outro jogo. No entanto,
se ele não conhecer o middleware, terá de se preparar para uma curva de
aprendizado que inicialmente pode retardar o tempo de desenvolvimento,
enquanto a equipe aprende a trabalhar com a tecnologia.
Provavelmente a maior desvantagem de se trabalhar com um middlewa-
re seja o custo – você terá de pagar uma taxa de licenciamento (e às vezes
royalties) ao fornecedor do middleware e, dependendo do produto, essa taxa
pode custar várias centenas de milhares de dólares. No entanto, você pode
descobrir que o custo compensa após elaborar o plano do jogo. Muitos for-
necedores de middleware custeiam seus produtos competitivamente e for-
necem um suporte técnico excelente, para facilitar para os desenvolvedores
decidirem-se pelo uso do middleware.
Uma vez que a licença for obtida (e em alguns casos antes), o fornece-
dor do middleware disponibilizará um Kit de Desenvolvimento de Software
(SDK, Software Development Kit) incluindo as APIs, ferramentas e documen-
tação. A maioria dos fornecedores de middleware oferece suporte técnico e
ajuda a resolver os problemas técnicos encontrados pela equipe na integração
da tecnologia de middleware ao pipeline de produção do jogo.
Após o middleware ser integrado ao jogo, o fornecedor pode solicitar
uma build para verificar como seu software foi implementado. O jogo pode
ter de atender um conjunto formal de requisitos técnicos antes que o fornece-
dor aprove a implementação do middleware. Isso assegura o funcionamento
da tecnologia como desejado e que não ocorram surpresas quando o jogo for
lançado. O processo de aprovação pode ser bom para o desenvolvedor, por-
que testadores familiarizados com os problemas comuns que podem ocorrer
na implementação do middleware verificarão o jogo e identificarão qualquer
problema que tiver de ser resolvido. Certifique-se de incluir tempo no crono-
grama de produção para esse processo de aprovação.
USANDO MIDDLEWARE
Amanda Rubright, produtora

Aspyr
Se estiver considerando o uso de middleware, inclua isso como parte da fase de planeja-
mento inicial do projeto. Se achar que o uso de middleware não é o caminho certo a se
seguir, decida antecipadamente para se certificar de alocar tempo e recursos à criação do
que o projeto precisa internamente.
Os benefícios do uso de middleware são enormes no que diz respeito ao tempo e à

utilização eficiente de um produto que você sabe que tem um histórico de sucesso. Com
frequência, optamos por usar middleware quando não faz sentido desenvolver a partir
do zero devido a restrições de tempo e aos riscos potenciais que podem ser encontrados
durante o desenvolvimento. Além disso, terceirizar algumas das tarefas que não são tão
divertidas deixa os desenvolvedores felizes porque permite que se dediquem ao lado diver-
tido do desenvolvimento!
As duas partes se beneficiam igualmente – costuma ser mais barato utilizar middlewa-
re do que desenvolver um sistema a partir do zero. Sistemas funcionais testados são sempre
menos arriscados do que criar algo novo que tenha de ser desenvolvido e depurado.
Em minha opinião, não há muitas desvantagens – só em cenários menos satisfató-
rios. Às vezes, o custo é alto e o desconhecimento do produto pode causar problemas.
O suporte técnico pode colocar o cronograma de produção em risco, se o fornecedor
não for rápido para esclarecer dúvidas. No entanto, geralmente não é isso que ocorre.
Conduzindo uma investigação cuidadosa dos fornecedores que deseja usar e solicitando
recomendações de seus pares na indústria, você pode mitigar muitas dessas desvantagens
e riscos. Pertencemos a um ramo pequeno, portanto, temos de nos ajudar.
Uma das principais coisas que devemos lembrar ao usar middleware é que devem
ser pagas taxas de licenciamento ao fornecedor do middleware. A maioria das licenças é
vinculada ao título e/ou plataforma. Por exemplo, se estiver trabalhando em versões PS3
e Xbox 360 do mesmo jogo, você pode ter de obter uma licença para cada plataforma ou
talvez possa comprar uma licença que englobe todas as plataformas do jogo. Você pode
até mesmo ter uma para idiomas adicionais, dependendo da abrangência do acordo de
licenciamento. Em alguns casos, você também pode ter de pagar royalties para o fornece-
dor por cada cópia vendida do jogo, portanto, certifique-se de se informar sobre os custos
de licenciamento ao fazer a investigação cuidadosa. Se estivesse trabalhando na sequên-
cia de um jogo, provavelmente também precisaria obter uma nova licença. No entanto,
alguns fornecedores permitirão o uso da licença sem nenhum custo extra se você estiver
lançando conteúdo adicional para o SKU principal do jogo. Alguns fornecedores podem
fazer acordos se você estiver trabalhando com vários títulos e plataformas, mas mesmo
assim todas as plataformas e SKUs têm de ser licenciados.
Normalmente o publicador paga o licenciamento, mas isso depende do projeto.
Quem irá pagar pelo que vai depender do contrato entre desenvolvedor e publicador. Por
exemplo, se o desenvolvedor estiver fazendo aquisições para um publicador, provavelmen-
te eles terão de arcar com as taxas de licenciamento de middleware. Nesse caso, é possível
o desenvolvedor pedir que o publicador reembolse essas taxas durante a negociação do
contrato, ou ele pode incluí-las no orçamento final solicitado ao publicador.
As negociações com os fornecedores com os quais trabalhei não demoravam. Geral-
mente, solicitamos o contrato de licenciamento ao fornecedor, o departamento jurídico o
examina, ele é assinado e devolvido com um cheque. Quando o fornecedor recebe o che-
que, libera o SDK para a equipe poder começar a trabalhar com ele. Em alguns casos, o
fornecedor entrega o SDK antes que o contrato seja finalizado, o que é muito útil quando
a equipe está trabalhando com um prazo apertado.
Normalmente é na integração do middleware que podemos ou não ter problemas.
Quanto sua equipe conhece desse middleware? Ela já o usou antes? Como ele funcionará
com o título para o qual está sendo usado? Como é o sistema de suporte desse midd-
leware? Os técnicos estarão disponíveis para nos orientar na integração e resolução de

problemas? Na verdade, a experiência e o talento de sua equipe de desenvolvimento é que
ditarão os tipos de problemas encontrados na integração.
Se você tiver problemas, poderá obter suporte técnico com o fornecedor do middle-
ware. A maioria dos fornecedores de middleware com os quais trabalhei forneceu um su-
porte excelente. A Demonware, a Quazal e a Unreal têm sites de suporte técnico com infor-
mações sobre seus produtos. Elas também têm um e-mail de suporte que é muito útil para
o esclarecimento de dúvidas. Todas foram muito responsivas e úteis ao responder pergun-
tas sobre desenvolvimento e integração. Geralmente, os problemas podem ser resolvidos
por e-mail, mas às vezes um telefonema é necessário no caso de problemas mais complica-
dos. Em alguns casos, os fornecedores de middleware enviam especialistas em integração
ao local para trabalharem com a equipe na integração de seu software antitrapaças.
Uma vez que você tiver integrado o middleware ao seu jogo, pode ter de enviá-lo
para o fornecedor para aprovação. Isso ocorre principalmente para ele verificar se a imple-
mentação está correta. O tempo de aprovação varia, portanto, procure informações com
antecedência para poder incluí-las em seu cronograma de produção. Já que o fornecedor
sabe que a equipe está trabalhando com um prazo apertado, ele será o mais flexível possí-
vel na execução do processo de aprovação. A maioria das aprovações de middleware pode
ocorrer simultaneamente com o desenvolvimento do jogo porque o fornecedor não estará
tentando aprovar as mesmas coisas que seu publicador. Ele também pode querer aprovar
a embalagem para verificar se seu logotipo e o texto legal estão sendo usados corretamen-
te (e conforme acordado no contrato).
16.8 Descrição da fase de planejamento do jogo
planejamento do jogo. Ela foi baseada em um ciclo de desenvolvimento de
dois anos.
O planejamento do jogo é um componente crucial da pré-produção, já que reú-

ne todos os requisitos e mostra como o trabalho pode ser concluído a tempo. O
cronograma, o orçamento e o plano de pessoal são os principais componentes,
e todos esses fatores flutuarão durante a produção. No entanto, se você passar
algum tempo na pré-produção criando um plano de jogo detalhado, terá uma
ideia melhor dos fatores que podem ser ajustados quando alterações ocorrerem
durante o processo de desenvolvimento. Este capítulo discutiu os aspectos bá-
sicos da determinação do cronograma, do orçamento e do plano de pessoal e
maneiras de você defini-los para planejar seu jogo. Após o planejamento do jogo
ser concluído, você terá uma ideia clara do que esperar durante a produção.
Etapa Recursos Cronograma geral Tarefas

Criação do cro- Produtor Ocorre em paralelo com a Crie o cronograma do projeto com as
nograma mestre fase de requisitos principais etapas e divida cada etapa em
tarefas gerais de arte, design, engenharia e QA.
Adicione seções para localização, voiceover e
outros trabalhos terceirizados. Inclua seções
para aprovações de terceiros.
Criação de cro- Produtor Ocorre em paralelo com a Quando as equipes de design, arte e
nogramas dedi- fase de requisitos engenharia determinarem os requisitos,
cados para fun- crie cronogramas para as funcionalidades
cionalidades bá- básicas para definir o escopo, o custo e os
sicas recursos das funcionalidades desejadas.
Determinação Produtor Ocorre em paralelo com a Faça suposições embasadas dos custos
do orçamento fase de requisitos estimados e crie um orçamento inicial.
Determinação Produtor Ocorre em paralelo com a Faça suposições embasadas das necessidades
das necessidades fase de requisitos estimadas de pessoal e crie um plano inicial.
de pessoal
Determinação Produtor Ocorre em paralelo com a Com base nas necessidades de pessoal, na
das necessidades fase de requisitos experiência da equipe e no orçamento, faça
de terceirização uma suposição embasada das áreas do jogo
que precisarão ser terceirizadas.
Pesquisa e sele- Produtor Ocorre em paralelo com a Pesquise possíveis fornecedores para ter uma
ção de fornece- fase de requisitos ideia de custo, qualidade e nível de confiança.
dores
Aprovação Gerência do estúdio, Ocorre em paralelo com a Apresente o orçamento, o cronograma e o plano
publicador fase de requisitos de pessoal para a gerência para aprovação.
Figura 16.14 Descrição da fase de planejamento do jogo.
A próxima seção começará com a discussão do que ocorre durante a fase

de produção, como a criação de assets, a preparação de builds e a execução
de testes. Se você elaborar um plano sólido durante a pré-produção, provavel-
mente não haverá surpresas inesperadas durante a produção.
Parte VI
PRODUÇÃO
S e tudo for planejado adequadamente durante a pré-produção, a fase de pro-

dução não deve apresentar surpresas. O objetivo da produção é implementar
o planejamento do jogo criado durante a pré-produção e enviar o jogo para as lojas.
Muitos elementos têm de ser gerenciados durante a produção, principalmente
o relacionamento entre arte, design, programação e QA. Esses departamentos esta-
rão trabalhando com capacidade plena durante a produção e devem operar bem uns
com os outros para manter o processo de desenvolvimento correndo sem problemas.
A produção é o ponto em que o projeto começa a se parecer com um jogo e
em que uma versão jogável está em funcionamento. Esta seção do livro apresentará
informações-chave sobre a fase de produção. Os tópicos são estes:
• Técnicas de produção
• Ciclos de produção artística, design e programação
• Criação de builds
• Classificação de software
• Localização
17
CICLO DE PRODUÇÃO
Neste capítulo
• Ciclo de produção • Ciclo de produção • Ciclo de produção de
do design artística programação
• Trabalho em conjunto
17.1 Introdução
Quando a pré-produção terminar, você terá uma ideia clara do jogo que está
em criação, da maneira como isso será feito, de quem vai fazer o trabalho e de
quanto tempo há para fazê-lo. É importante ressaltar que não existe um pon-
to preciso onde a pré-produção termina e a produção começa. A transição é
gradual. Por exemplo, quando as equipes de arte e programação começarem a
trabalhar nos recursos descritos na documentação básica de design, a equipe
de design ainda estará ocupada projetando os cenários das missões que apa-
recerão no jogo. A equipe artística também começará a produção de alguns
assets ao mesmo tempo em que prototipa outros. A programação começará a
codificar o jogo, mas ainda pode estar trabalhando em protótipos técnicos de
alguns recursos menores.
O importante na produção é que a equipe possa começar a implementar
o plano e ver o jogo tomar forma. Portanto, mesmo que alguns pequenos deta-
lhes ainda estejam sendo manipulados, a produção pode começar após os as-
pectos mais importantes do jogo serem definidos e aprovados. As principais
tarefas que ocorrem na produção são a implementação do plano, o acompa-
nhamento do progresso do jogo e a conclusão do trabalho. É responsabilidade
292 Parte VI • Produção
do produtor, durante a produção, gerenciar essas tarefas calmamente e lidar

com qualquer surpresa ou problema.
Todo produtor espera ter pensado, durante a pré-produção, em qualquer
contingência que possa ocorrer, e é na produção que esse plano é testado. No
entanto, em um jogo que leve dois anos para ser desenvolvido, é um pouco
otimista achar que um plano feito em janeiro de 2007 será totalmente válido
18 meses depois, em julho de 2008. Os jogos mudam e crescem com o tempo,
e um plano feito há mais de um ano pode não levar em consideração os no-
vos recursos gráficos que o marketing quer que sejam adicionados. É por isso
que o produtor deve ficar constantemente alerta quanto ao progresso do jogo
durante a produção, para que áreas de alto risco sejam identificadas e corri-
gidas e solicitações de recursos de alta prioridade sejam acomodadas quando
necessário.
Durante a produção, as tarefas do produtor envolverão interagir com os
líderes e a equipe diariamente, avaliar o progresso do jogo, verificar a joga-
bilidade, trabalhar com a equipe de QA, manter a gerência satisfeita, forne-
cer recursos para o departamento de marketing, trabalhar com fornecedores
externos, aprovar etapas, lidar com a burocracia e várias outras coisas. Cada
dia será diferente: em alguns, você pode ter vários incêndios para apagar; em
outros, poderá se dedicar a se atualizar. Seja como for, procure sempre manter
a produção no caminho planejado para que o jogo seja entregue a tempo. O
Capítulo 18, “Técnicas de produção”, discutirá algumas maneiras dos produ-
tores gerenciarem o ciclo de produção.
É claro que os departamentos de arte, design, programação e QA tam-
bém estarão ocupados durante a produção. Cada área estará trabalhando ar-
duamente nas tarefas que lhe foram atribuídas. As pessoas podem concluir
algumas tarefas por sua própria conta ou com a ajuda de alguém de sua área,
mas outras tarefas demandarão várias pessoas e áreas. Se a equipe estiver
motivada e disposta, não será difícil fazer seus membros trabalharem bem
entre si. Eles se envolverão nas tarefas uns dos outros, oferecerão feedback e
trabalharão juntos para o jogo ficar o melhor possível.
MANTENDO O PROJETO NO CAMINHO PLANEJADO
Jeff Matsushita, produtor executivo

Activision
Se um projeto estiver tendo problemas, você pode não ver nenhuma evidência tangível,
como prazos perdidos ou o esgotamento das pessoas, até ser tarde demais. A essa altura,
o projeto pode estar em uma situação tão desesperadora que levará muito mais tempo
e dinheiro para trazê-lo de volta para o caminho certo do que se a situação tivesse sido
identificada mais cedo. E, se não houver bastante tempo e dinheiro disponíveis para esses
ajustes serem feitos, e raramente há, é quase certo que a qualidade do jogo será afetada.
17 • Ciclo de Produção 293
Os produtores devem avaliar constantemente o progresso do jogo em cada nível

para garantir que tudo continue correndo conforme o cronograma e o orçamento. Isso
requer a disciplina de se concentrar no término do trabalho, o conhecimento de um
bom planejamento de projeto e a vontade de se ater a um plano. Após um plano ter sido
definido, é essencial que todos se comprometam com ele. É por isso que é importante
trabalhar com a equipe inteira na elaboração desses planos. Dessa forma, se as pessoas
não estiverem cumprindo as etapas que elas próprias definiram, trazê-las de volta ao
caminho antes que comecem a afetar a qualidade geral do projeto será encarado com
menos resistência. Se a equipe não estiver cumprindo os prazos porque o plano não fez
uma avaliação correta da banda larga ou as condições mudaram e o tornaram obsoleto,
ele deve ser redefinido e o processo deve começar novamente. É comum isso ocorrer vá-
rias vezes em um projeto. Ter de refazê-lo pode parecer muita sobrecarga, mas um plano
inválido é perigoso porque cria a ilusão de que o projeto está sendo gerenciado melhor
do que realmente está.
Uma maneira de avaliar o progresso é encorajar a criação de builds regulares do
jogo. Se uma equipe não puder fornecer builds como esperado, algo deve estar errado.
Pode significar que eles não estão fazendo um progresso adequado ou que há uma falta
de compreensão do valor do produto. De qualquer forma, é importante que o produtor
descubra o que está atrapalhando a build. Para estabelecer essa disciplina, os produtores
devem considerar a implementação de builds regulares desde cedo no processo de de-
senvolvimento. Comece com o hábito de criar builds uma vez por mês, com a frequência
das builds aumentando à medida que a produção avançar. Na versão alfa, builds diárias
devem ser a norma. Quantidades menores significarão que a equipe pode não ter os pro-
cessos e a disciplina para iterar com rapidez e eficiência suficientes e terminar o jogo a
tempo. Com builds frequentes disponíveis, o produtor terá um resultado tangível do tra-
balho para avaliar o progresso com o passar do tempo.
17.2 Ciclo de produção do design
Quando a produção começar, a equipe de design terá concluído a documen-

tação das partes principais do jogo. Eles passarão seu dia de produção imple-
mentando a jogabilidade na build, ajustando os recursos de jogabilidade exis-
tentes e dando feedback para os artistas e programadores sobre seu trabalho.
Além disso, um designer pode estar redigindo todo o diálogo de um jogo e
trabalhando com o produtor para organizar a tomada de voiceover.
O ciclo de produção do design também envolve muita iteração e a evolu-
ção dos recursos. Após um recurso ser implementado no jogo como original-
mente planejado, o designer continuará a ajustar e polir a implementação até
que fique perfeita. Isso inclui como o controle funciona, a pontuação, o diálogo,
os botões da IU e qualquer outra coisa que precise ser ajustada quando uma
versão jogável for avaliada. Em alguns casos, um recurso pode ser projetado
novamente se necessário. Um recurso ser projetado novamente não é algo cor-
riqueiro e precisa ter a aprovação do produtor e dos líderes antes de ser feito.
CONDUZINDO PLAYTESTS

Ubisoft
Você pode fazer várias coisas para criar playtests úteis. Em primeiro lugar, precisará de
pessoas de fora que possam olhar o jogo de maneira neutra. Também pode precisar de
pessoas dedicadas ao planejamento, agendamento, monitoração, registro e criação de
relatórios desses testes. É preciso conduzir os testes regularmente desde a primeira versão
jogável até chegar ao ponto em que você não terá tempo para implementar algo que seu
teste venha a revelar (o que costuma ocorrer perto da versão master). Você tem de execu-
tar os testes em pequenos grupos de três a seis jogadores e também terá de fazer vários
testes diferentes. Cada grupo deve testar o jogo o máximo que puder e as pessoas que
estiverem conduzindo o grupo de testes têm de saber exatamente o que podem e devem
testar em cada teste. Elas precisam coletar o máximo de dados que puderem e têm de sa-
ber como construir questionários e transformar os dados que coletaram em informações
úteis. As informações obtidas com 100 a 200 jogadores individuais serão inestimáveis
para a melhoria da qualidade geral do título.
O playtest também é uma parte extensa do ciclo de design. À medida que

a mecânica do jogo começa a funcionar, os designers conduzem playtests para
determinar se um recurso é divertido ou se é necessário trabalhar mais nele.
O ideal é que haja pessoas de fora da equipe de desenvolvimento que possam
ser testadores para o designer obter um feedback imparcial. No entanto, é uma
boa ideia envolver a equipe quando possível, já que isso melhora o relacio-
namento e dá às pessoas um senso maior de responsabilidade pelo jogo. Em
alguns casos, os publicadores conduzem testes beta abertos para obter infor-
mações diretamente com o público-alvo sobre o que funciona ou não no jogo.
O feedback é útil para os designers porque eles o obtêm diretamente com os
jogadores e não têm de adivinhar o que estes querem.
CONDUZINDO TESTES BETA
Erik Louden, testador beta
Participei de mais de 70 testes beta (tanto abertos quanto fechados) como testador de jo-
gos de PC. Acho muito gratificante porque tenho a oportunidade de jogar e dou feedback
e sugestões de melhorias antes do jogo ser lançado para o grande público.
O processo usado no teste beta varia para cada jogo, mas, em geral, o publicador
determina quais terão testes beta e quantos testadores serão necessários. Ele pode decidir
ter um teste mais livre em que os testadores não precisam seguir um plano de testes ou
responder um conjunto específico de perguntas, mas joguem respeitando condições do
mundo real. Em outros casos, pode haver um questionário para os testadores preenche-
rem, proporcionando um controle mais preciso de seu feedback sobre o jogo. Quando fui
testador beta na Activision, fóruns eram estabelecidos para os testadores fazerem comen-
tários e discutirem o jogo. De tempos em tempos, um membro da equipe de desenvolvi-
mento respondia perguntas no fórum e o mantinha atualizado sobre o progresso do jogo.
Antes de podermos testar algo, passávamos por uma triagem, éramos selecionados
para o teste beta e então assinávamos um NDA. Após sermos aprovados para o teste,
recebíamos uma build do jogo. Há alguns anos, antes da banda larga predominar, re-
cebíamos builds do jogo pelo correio. Com frequência elas incluíam um envelope com o
endereço de retorno para podermos devolver a build ao terminar o teste. Hoje, geralmente
fazemos o download da build diretamente do servidor de FTP seguro do publicador.
O tempo durante o qual um jogo passa por um teste beta também depende das
necessidades do publicador. Há casos em que os testes beta começam cerca de seis meses
antes do lançamento; em outros, podem demorar um ano (teste alfa). Os testes alfa cos-
tumam enfocar pequenas partes do jogo, já que a versão alfa não é totalmente funcional;
é solicitado feedback sobre recursos novos ou experimentais que são adicionados ao jogo.
Após o teste beta começar, normalmente testamos builds atualizadas do jogo até ele estar
quase pronto para ter o código liberado. Os testadores são diretamente responsáveis por
encontrar e relatar bugs e os desenvolvedores podem nos pedir para testar a mecânica do
jogo e dar sugestões sobre recursos e a jogabilidade.
Os desenvolvedores e publicadores podem fazer algumas coisas para tirar o máximo
de proveito de seus testes beta. Em primeiro lugar, é uma boa ideia usar duas equipes de
testadores. Uma equipe pode fazer um playtest direcionado, via plano de testes, e a outra
um teste de formato livre. A equipe do teste de formato livre não lerá a documentação,
,indo direto ao jogo. Com frequência, essa equipe descobre elementos que causam pro-
blemas e passam despercebidos durante um processo de testes mais formal. Por exemplo,
uma vez eu estava fazendo um teste beta em um jogo on-line. Havia uma tela da IU em
que era possível selecionar diferentes cidades. Decidi descobrir o que ocorreria se eu co-
meçasse a clicar rapidamente em todas as cidades, e acabei interrompendo o servidor. O
desenvolvedor me telefonou e relatei o bug para ele. Pude ouvir o líder de QA dizendo ao
fundo: “É por isso que temos testadores beta. Nunca teria pensado em testar isso”.
Outra coisa é garantir que os desenvolvedores estejam disponíveis, mesmo com ca-
pacidade limitada, para interagir com os testadores beta. Os testadores trabalham ardua-
mente, quase sempre sem receber pagamento, e é bom saber que estão sendo ouvidos e que
seu feedback está sendo levado a sério. Isso demandaria apenas que os desenvolvedores fi-
zessem postagens nos grupos de discussão ou jogassem um jogo on-line com os testadores.
Para concluir, tome cuidado ao selecionar testadores beta. Algumas pessoas ficam
mais interessadas em jogar uma versão gratuita do jogo do que em fornecer feedback
útil no playtest. É muito bom quando há uma equipe básica confiável de testadores beta
conhecida por fazer um bom trabalho. Esse grupo executa todo o teste beta e trabalha
em recursos que a concorrência não deve conhecer. O desenvolvedor pode então pedir
a outros testadores (secundários) que se dediquem a áreas menos confidenciais do jogo
se a situação exigir.
17.3 Ciclo de produção artística
O ciclo de produção artística lida com a criação de assets – os personagens, os

veículos, os objetos, as armas, o ambiente, a arte da IU e a cinemática são cria-
dos durante a fase de produção. Cada artista recebe a designação de produzir
algo em um prazo específico. Após o produto ser concluído e estar funcionan-
do na build, o feedback começa a ser recebido. Como ocorre no design, a equipe
de arte revisita então seu trabalho, implementa o feedback e aperfeiçoa os as-
sets até o jogo ficar em um estado passível de entrega. Já que cada jogo tem vá-
rios assets de arte, o artista líder também passa muito tempo acompanhando a
criação de assets e verificando se os artistas estão recebendo feedback a tempo.
A essa altura, a prototipagem ainda estará sendo feita. Mesmo se a lista
de assets estiver definida, a arte conceitual e a prototipagem serão necessárias
para assets específicos que estiverem sendo gerados. Além disso, um anima-
dor trabalhará com o produtor no planejamento da tomada de captura de mo-
vimentos se ela for necessária.
A equipe de arte passará algum tempo trabalhando com os programa-
dores para refinar o pipeline de produção artística. Geralmente, quando a
produção artística começa, algumas das ferramentas artísticas proprietárias
ainda estão sendo codificadas pelos programadores. É comum os artistas co-
meçarem a criar assets mesmo sem o pipeline estar pronto, principalmente
se a fonte dos assets for criada em um pacote de software comercial, mas eles
não poderão visualizá-los in-game até o pipeline ser concluído. É preciso ter
cuidado, pois qualquer atraso no funcionamento do pipeline produzirá um
impacto negativo sobre o cronograma geral. Se esses atrasos continuarem por
semanas, é possível que prazos sejam perdidos, ou a equipe de marketing não
terá builds do jogo visualizáveis para conferências e feiras importantes.
PROTOTIPAGEM

Pandemic Studios
A prototipagem é extremamente importante na criação dos assets de arte de um jogo.

Pensando nisso, o diretor de arte e o produtor devem se comprometer a fazer o que pu-
derem para ter protótipos de níveis, modelos, efeitos especiais e qualquer outro asset de
arte essencial funcionando in-game. Uma coisa que você pode fazer, se o mecanismo do
jogo ainda não estiver funcionando, é usar um mecanismo pronto para uso e um editor de
níveis (como o Unreal) para construir um mundo temporário. Se isso não for possível, crie
muita arte conceitual para transmitir a atmosfera, a sensação e o estilo do jogo. Embora a
arte conceitual não resolva desafios técnicos, pode ajudar a defini-los quando os recursos
de arte técnicos que precisam ser incluídos no jogo forem considerados.
A prototipagem e a arte conceitual também deixam a equipe entusiasmada com o

jogo. Quanto mais os membros da equipe puderem ver, mais poderão compartilhar a vi-
são do jogo uns com os outros. A conclusão da arte conceitual e de protótipos pode criar
muito entusiasmo e energia positiva em um projeto.
17.4 Ciclo de produção de programação
Durante a produção, a equipe de programação trabalha arduamente para co-

dificar e depurar os recursos do jogo. E quando usam middleware, trabalham
com um fornecedor de middleware para chegar a um código funcional. Além
disso, trabalham junto ao departamento de QA para identificar crash bugs e
correções de teste. Como as equipes de design e arte, a programação também
implementará qualquer feedback que for necessário.
A programação também é responsável por criar builds regulares do jogo e
fazer manutenções no pipeline de produção. Se a build não estiver funcionan-
do, certamente o programador líder e sua equipe terão de resolver o problema.
Os programadores podem passar muito tempo de produção depurando e
apagando incêndios. A tecnologia nunca funciona como se espera, portanto,
um recurso que foi originalmente planejado pode ter de ser cortado se a tec-
nologia não der suporte a ele. Às vezes, esses problemas não são percebidos
até a programação começar a produção e finalmente ver como as coisas fun-
cionarão no jogo.
17.5 Trabalho em conjunto
Como discutido no Capítulo 7, “Equipes”, é importante que todos na equipe

trabalhem juntos em direção a um objetivo comum. A equipe de arte deve
conversar com as de design e programação regularmente sobre o jogo, e as-
sim por diante. Se você tiver uma equipe em que arte, design, programação,
produção e QA não interagem, vai descobrir rapidamente que a comunicação
entre os departamentos é rara e que, quando ocorre, é para uns reclamarem
dos outros.
A interação entre arte, design, programação e QA é importante para o
jogo e a equipe. Se um programador reservar tempo para jogar alguma das
missões que os designers roteirizaram, pode ter sugestões sobre maneiras de
melhorá-la ou descobrir uma pequena alteração que possa ser feita na ferra-
menta de scripts para fornecer alguma funcionalidade de script adicional e
tornar as missões mais divertidas. Um feedback construtivo é sempre bem-
-vindo quando dado de maneira discreta e respeitosa.
DANDO UM FEEDBACK EFICAZ

Pandemic Studios
Não é difícil dar um feedback eficaz para um artista se você responder a duas perguntas:
“Gostou?” e “Por quê?”. O porquê é o mais importante para um feedback útil; se você
não conseguir explicar por que não gosta de algo, o artista não entenderá o feedback e
não saberá que mudanças fazer.
Qualquer feedback sobre assets de arte deve passar pelo diretor de arte, em vez de
ser dado diretamente ao artista que criou o asset. Assim, o diretor de arte poderá filtrar o
feedback para não haver confusão sobre as alterações que devem ser feitas. O diretor de
arte também pode reformular o feedback para torná-lo mais diplomático e fornecer infor-
mações úteis para o artista. Isso evita linhas de comunicação cruzadas, principalmente em
uma situação em que o designer líder e o artista líder podem ter um feedback conflitante.
Estabeleça um processo eficaz de rastreamento de todo o feedback. Por exemplo,
Alienbrain e Perforce exigem a inclusão de um comentário quando algo é inserido, o que é
uma boa maneira de rastrear as mudanças que foram feitas em um asset. Você também
pode rastrear essas mudanças em um log de controle de mudanças ou em uma área de-
signada no site da equipe.
FEEDBACK ÚTIL

Ubisoft
Infelizmente, todo mundo se acha no direito de opinar, e já que o design é algo que as
pessoas consideram fácil de manipular, elas parecem achar que podem dar feedback sobre
o assunto e fazer esse feedback ser integrado. Qual a melhor maneira de um artista, pro-
dutor, designer ou gerente dar feedback sobre um código? A resposta é: aprender como
programar, procurar um meio de alcançar a posição de líder, conduzir uma avaliação com-
pleta do código e apresentar esse feedback por escrito. Lamentavelmente, é verdade que,
devido ao design ser tão mal definido e a tendermos a não ser rigorosos, acabamos nos
sujeitando a esse tipo de intromissão de uma maneira que não ocorre aos programadores
ou produtores. É culpa nossa. Temos de desenvolver e melhorar nossas metodologias, traba-
lhar na formalização de nossa área e desenvolver a nós próprios e nossas habilidades até
chegarmos ao ponto em que um transeunte qualquer que por acaso goste de Quake não
tenha chances de ser tão bom ou melhor do que um designer ativo. Até alcançarmos o nível
em que haja um conjunto de habilidades mensurável que só os designers possuam, até
deixarmos de aplicar a abordagem “não seria interessante se…” ao design, sempre seremos
obrigados a integrar feedback de pessoas de outras profissões. Dito isso, programadores,
produtores e artistas podem dar um feedback valioso sobre design. É por essa razão que
se preocupam com problemas de design: são analíticos e sabem sobre o que estão falando
tanto quanto o designer médio. A melhor maneira de darem seu feedback é simplesmente
analisando e criticando o design utilizando o mesmo vocabulário do designer. Em outras
palavras, ao falar comigo na minha língua, você terá mostrado que entende da área. O
mesmo ocorre com a arte, a programação e a produção.
Pode ser um desafio fazer programadores, artistas e designers se comunicarem de
maneira eficiente uns com os outros. Ainda não temos um vocabulário formal completo
para falar sobre e, portanto, facilitar as tarefas de design. Esse é um dos principais objetivos
dos modernos designers de jogos. Leia livros, vá a palestras ou leia artigos de Doug Church,
Mark Leblanc, Harvey Smith, Chris Crawford, Raph Koster, Ben Cousins, Robin Hunicke –
ou qualquer designer que não fique conectado o tempo todo aos seus sites ou blogs. Então
começará a aprender como se comunicar com designers. Não chegará para um designer e
dirá: “Acho que seria mais interessante se…”. Quando puder fazer isso, se verá em uma entre
duas situações: ou conversando com um designer praticante dizendo “não seria interessante
se” – caso em que provavelmente seu projeto estará com problemas –, ou interagindo com
um designer que consiga se comunicar com você, caso em que todos ganharão. Os desig-
ners precisam ser mais profissionais; e quando se tornarem mais profissionais, também vão
esperar profissionalismo de quem quiser discutir design com eles.
Durante a produção, também é importante a equipe ficar alerta para as de-

pendências das tarefas e como os atrasos afetarão os prazos gerais. As pessoas
têm de se empenhar em conjunto, principalmente se vários departamentos es-
tiverem trabalhando no mesmo recurso. Cada membro da equipe deve reservar
alguns minutos todo dia para fazer uma verificação com seus colaboradores
sobre onde eles estão em seu trabalho. Também não devem ter medo de dar
avisos ou levar qualquer preocupação para seu líder ou para a produção.
Acima de tudo, a produção é um período pleno de atividades e a equipe
crescerá até seu tamanho máximo. As coisas estarão acontecendo rapidamen-
te, portanto, todos têm de se dedicar a concluir seu trabalho a tempo. Também
é quando horas extras se tornam necessárias, logo, certifique-se de se manter
alerta para a fadiga e outros possíveis problemas de pessoal. Já que tanta coisa
acontece durante a produção, ela será um dos períodos mais interessantes do
projeto se você tiver se planejado cuidadosamente durante a pré-produção.
A produção começa após o conceito e os requisitos do jogo serem definidos

na pré-produção. Se o plano do jogo for detalhado e bem organizado, ela cor-
rerá sem problemas. Durante a produção, as equipes de arte, design, progra-
mação, produção e QA se dedicam ao mesmo objetivo – entregar um jogo de
alta qualidade e divertido. Cada área terá prioridades diferentes para o jogo: a
equipe artística vai querer que o jogo tenha a melhor aparência possível, a de
design que tenha a melhor jogabilidade, e assim por diante. Mas todos traba-
lharão juntos para alcançar um equilíbrio entre os objetivos. Esses objetivos
são influenciados pelos playtests e feedbacks que ocorrem durante a produ-
ção. No próximo capítulo veremos algumas maneiras de manter o processo de
produção no caminho certo.
18
TÉCNICAS DE PRODUÇÃO
Neste capítulo
• Colocando o projeto • Relatórios de status • Estabelecendo
de volta no rumo certo semanais processos de
• Revisões de projeto • Reuniões aprovação
• Análise de estágios • Alocação de recursos • Forças-tarefa
cruciais • Evitando o crescimento
desenfreado
18.1 Introdução
Como produtor, é sua responsabilidade passar pelas várias fases do desen-

volvimento e conduzir um projeto com sucesso do conceito à conclusão.
Esse é um desafio enorme, mas não impossível, principalmente se você es-
tiver monitorando constantemente o processo de desenvolvimento para ve-
rificar se os objetivos do jogo estão sendo atingidos e se estiver procurando
ativamente maneiras de melhorar a qualidade e a eficiência do processo de
produção. Muitas técnicas de produção podem ser usadas para colocar o
projeto de volta no caminho certo, monitora o progresso e melhorar a efi-
ciência. Este capítulo discutirá algumas técnicas eficientes e fáceis de im-
plementar.
LIDANDO COM DESVIOS NO CRONOGRAMA

Activision
A verdade é que é difícil dizer quando um projeto começa a tomar outro rumo. Como
Frederick P. Brooks Jr. diz em seu livro The Mythical Man Month: “Como um projeto conse-
gue ficar um ano atrasado? Um dia de cada vez”. Desvios menores no cronograma são
difíceis de identificar e só se tornam mais aparentes quando o dano já ocorreu. A melhor
maneira de lidar com desvios no cronograma é estabelecer uma defesa contra eles desde
o início.
Um cronograma claro e conciso é essencial, assim como etapas mensais com defi-
nições precisas. Até mesmo o melhor cronograma não valerá o papel em que foi impresso
se a equipe de produção não acompanhar o progresso rigorosamente com regularida-
de. Só com uma análise realista do progresso da equipe é que os produtores conseguem
identificar desvios menores e fazer pequenas correções no curso após as etapas mensais
conforme apropriado.
Esperar até o desvio ficar óbvio facilita a identificação do problema e permite que a
equipe lide com ele mais agressivamente, mas a essa altura o dano já foi feito.
18.2 Colocando o projeto de volta no rumo certo
Para entender bem como variáveis do projeto como cronograma, recursos,

funcionalidades e qualidade se relacionam e afetam diretamente umas às ou-
tras, é útil visualizarmos um triângulo. A Figura 18.1 é um diagrama dessa
situação.
Os lados do triângulo correspondem aos recursos, ao cronograma ou às
funcionalidades necessários à conclusão de um determinado projeto. A área
interna do triângulo representa a qualidade do projeto. Se um desses fatores
mudar, afetará os outros; uma medida não muda em um triângulo sem afetar
as outras. Se todos esses quatro fatores estiverem constantemente mudando
durante o ciclo de desenvolvimento, o projeto nunca será estável. Isso dificul-
ta estimar quando o jogo estará concluído, quanto custará, quantas funciona-
lidades terá e a qualidade da versão final.
Por exemplo, se o cronograma for encurtado, mais pessoas serão adicio-
nadas, funcionalidades serão cortadas, a qualidade do produto diminuirá ou
alguma combinação dessas situações será necessária para o projeto ser con-
cluído a tempo. Se o número de pessoas for reduzido, mais tempo será adicio-
nado, funcionalidades serão cortadas ou a qualidade diminuirá para compen-
sar a redução de recursos. Jim Lewis explica conceitos como esses com mais
detalhes em seu livro Project Planning Scheduling and Control.
18 • Técnicas de Produção 303
S
DE
CR
IDA
ON
AL
OG
ION
RA
NC QUALIDADE
MA
FU
RECURSOS
Figura 18.1 Relacionamento das variáveis do projeto.
Obter equilíbrio entre o cronograma, os recursos, as funcionalidades e a

qualidade é um desafio para qualquer projeto. No entanto, ao nos depararmos
com um projeto que está saindo do rumo, temos quatro áreas básicas onde
procurar maneiras de fazê-lo voltar a avançar com sucesso:
Aumento do tempo programado: Mais tempo é algo que as equipes
sempre pedem em um projeto. Porém, tempo não é um luxo quando
o jogo tem de ser concluído antes das férias. A inclusão de tempo no
cronograma pode parecer uma solução fácil, mas certifique-se de que o
tempo adicionado seja usado de maneira eficaz. Se mais tempo for adi-
cionado e a equipe diminuir seu ritmo de trabalho, o tempo extra será
consumido rapidamente.
Aumento de recursos: O aumento de recursos também pode ser uma
maneira simples de trazer um projeto de volta ao que foi planejado, mas
é possível chegarmos a uma quantidade crítica em que a inclusão de
mais recursos na verdade aumente o tempo de conclusão das tarefas.
Quando mais pessoas forem adicionadas a um projeto, você terá de ofe-
recer tempo de treinamento, definir tarefas, instalar hardware e software,
acompanhar seu trabalho e assim por diante. Esses itens também toma-
rão tempo das pessoas que já estão trabalhando no projeto, principal-
mente se forem responsáveis pelo treinamento.
Corte de funcionalidades: Ninguém quer cortar funcionalidades, por-
que isso é visto como uma diminuição no valor do jogo. No entanto, exa-
mine o conjunto de funcionalidades para determinar que funcionalida-
des básicas devem ser preservadas para dar valor ao jogo e concentre-se
no corte das funcionalidades adicionais que possam ser usadas em uma
segunda versão. Concentre-se também na eliminação de funcionalidades
adicionais que terão um impacto positivo sobre as restrições mais rigoro-
sas dos recursos e do cronograma.
Redução da qualidade: Se as pessoas responsáveis insistirem que todo

o conjunto de funcionalidades deve ser implementado com a equipe e
o cronograma atuais, a qualidade do projeto diminuirá. Se for colocado
nessa posição, defina especificamente onde a qualidade será afetada e
explique por que para os responsáveis. Isso pode convencê-los de que é
importante adicionar mais tempo, dinheiro ou recursos para assegurar a
qualidade do jogo.
Se um projeto estiver extremamente fora do planejado – tiver se des-
viado muito do cronograma ou estiver com um custo muito alto –, pode ser
cancelado, principalmente se não houver chances de gerar lucros com seu
eventual lançamento ou se o tempo e os recursos puderem ser usados em
outro projeto com mais probabilidades de gerar lucros. Cancelar um projeto
nunca é uma tarefa agradável e não é algo bem visto pela gerência sênior. O
cancelamento de projetos significa possíveis demissões, perda do dinheiro e
do tempo gastos, e é um grande golpe na moral dos funcionários.
No entanto, essa decisão pode ser mais sensata a longo prazo, já que o
desenvolvedor pode direcionar esforços à melhoria da qualidade de outro
jogo em produção ou começar a trabalhar em um novo jogo e usar as lições
aprendidas com o projeto anterior. Se estiver em uma posição em que o can-
celamento do projeto está sendo seriamente considerado, certifique-se de co-
nhecer os prós e contras de todas as outras soluções propostas para verificar
se o cancelamento é realmente a melhor coisa a fazer.
COMO CONDUZIR UM PROJETO DE VOLTA

AO CAMINHO PLANEJADO

1st Playable
Quando um projeto está apresentando problemas, geralmente a comunicação é uma das

primeiras coisas que devem ser consideradas! As pessoas estão estressadas e cansadas, o
que, junto à comunicação conflitante, dificulta para elas pararem e olharem o que está
ocorrendo no projeto como um todo.
Uma técnica que você pode usar para fazer o projeto tomar rumo novamente é criar
uma lista das tarefas que ainda têm de ser implementadas. Quando uma equipe está tendo
problemas, com frequência os membros param de controlar quanto falta fazer e, portan-
to, têm apenas uma ideia conceitual, e não uma lista concreta, do trabalho que precisa
ser concluído. Trabalhe com a equipe para elaborar essa lista e certifique-se de que todos
concordem que ela está completa. Itens obrigatórios devem ser diferenciados de itens de-
sejados, e áreas de alto risco ou problemáticas serão mencionadas. Isso ajuda a criar um
conhecimento compartilhado dos problemas de escopo ou de implementação, o que é
necessário para a descoberta de uma solução eficaz para o problema.
Após a lista ser concluída, a equipe terá de mudar o processo para trabalhar ape-
nas no que entrou na lista. Se uma tarefa for esquecida (o que é comum nesse estágio),
adicione-a à lista. Dessa forma, todos estarão trabalhando conforme o mesmo plano
Nesse meio tempo, você pode pegar as tarefas faltantes para priorizar e planejar
o trabalho, com o objetivo de estimar o tempo e os recursos necessários à conclusão
do jogo. Se um jogo estiver atrasado, você poderá ver onde é útil incluir mais recursos e
identificar áreas em que o trabalho pode ter o escopo reduzido. A lista também ajudará
a equipe a identificar situações em que os membros podem achar que uma tarefa foi
concluída mas ainda há trabalho a ser feito, e assim por diante. Além disso, ela fornece
um meio de confirmação das especificações do trabalho que está em andamento e um
meio de acompanhamento do tempo real versus o tempo estimado, para que as estima-
tivas possam ser atualizadas apropriadamente. Essa pode ser uma ferramenta eficaz e
visível, já que você poderá afixar a lista em salas da equipe e riscar os itens quando eles
forem concluídos.
O mais importante nessa técnica é que ela faz os membros da equipe trabalharem
em conjunto em um plano que acham que podem cumprir. Ela também ajuda a colo-
car a gerência, a equipe e o cliente em sintonia. Você pode achar que um projeto está
tendo problemas e a equipe achar que as coisas estão indo bem; pode achar que um
recurso solicitado pelo cliente pode ser adicionado e a equipe achar que já está sobre-
carregada. O interessante na elaboração de uma lista de tarefas restantes é que quando
todos estiverem de posse dos mesmos dados, 99% das vezes vocês chegarão às mesmas
conclusões.
18.3 Revisões de projeto
Revisões de projeto regulares e abrangentes com a gerência são vitais na mo-

nitoração do progresso do desenvolvimento do jogo. A revisão requer a veri-
ficação do plano de desenvolvimento estabelecido e sua comparação com o
progresso atual do desenvolvimento do jogo. Além disso, a revisão apresenta
uma oportunidade para a identificação de problemas e a formulação de solu-
ções, porque possíveis sinais de alerta são expostos e podem ser neutraliza-
dos antes de se tornarem problemas.
Antes de começar uma revisão, verifique se todos estão preparados e
concentrados no objetivo. As revisões podem ser ineficazes e uma perda de
tempo pelas seguintes razões:
• Objetivos nebulosos/falta de foco

• Falta de preparo
• Pessoas erradas envolvidas
• Falta de continuidade
A continuidade é crucial, principalmente quando são discutidas solu-

ções para possíveis problemas. Se as soluções não tiverem continuidade e não
forem implementadas no nível da equipe, um pequeno problema rapidamen-

te se tornará maior.
Conduzindo uma revisão de projeto

Não é difícil conduzir uma revisão de projeto. Vários livros de gerenciamento
de projetos discutem o processo de revisão com detalhes. Consulte o Apên-
dice C, “Recursos”. Em primeiro lugar, defina as finalidades e objetivos da
revisão. Se eles não forem definidos antecipadamente, as informações apro-
priadas podem não ser apresentadas e a revisão não será benéfica para a equi-
pe ou qualquer outra pessoa envolvida. É importante que as pessoas certas
participem da revisão – a gerência do estúdio, os líderes do projeto, e talvez
alguém do publicador também tenha de participar. Essas são as pessoas com
maior responsabilidade no projeto e que podem autorizar mudanças.
Em segundo lugar, estabeleça um formato. O formato da revisão é im-
portante para o estabelecimento dos objetivos. Deve incluir os seguintes ti-
pos de informações:
Comparações: Compare o plano com o status atual do projeto. Isso in-
clui informações como as datas originais das etapas e quando elas foram
realmente concluídas, o conteúdo que foi planejado para ser criado ver-
sus o conteúdo que foi realmente criado e quanto havia originalmente no
orçamento e quanto foi realmente gasto.
Realizações: Liste o que foi concluído desde a última revisão. Essa ati-
vidade mostra o progresso concreto do desenvolvimento do jogo. Se não
houver realizações a serem listadas, o projeto deve estar tendo proble-
mas. As realizações incluem coisas como a gravação de todo o voiceover,
o envio de todos os assets para tradução e a conclusão de todos os mode-
los de personagens do jogo.
Riscos: Identifique qualquer risco em potencial e proponha soluções.
Os riscos podem ser priorizados como altos, médios ou baixos para dar-
mos uma noção melhor do impacto que eles podem ter sobre o projeto.
Obstáculos: Os obstáculos são qualquer coisa que impeça a equipe de
fazer progresso. Por exemplo, se a equipe ainda estiver esperando kits
de desenvolvimento do console, isso a impedirá diretamente de execu-
tar uma versão do jogo na plataforma correta. Um obstáculo é algo que
pode ser identificado e rapidamente removido para que o progresso
não seja interrompido.
Documentação de suporte: Inclui o cronograma atualizado do projeto,
listas de produtos, relatórios de status de cada área do jogo e qualquer
outro item que ilustre concretamente o progresso feito no jogo.
Recursos: Identifique qualquer recurso adicional necessário. Por
exemplo, você pode precisar de outro programador por dois meses
para ajudar a codificar uma nova funcionalidade que foi aprovada.
Um artista adicional pode ser necessário por duas semanas para criar
objetos para os níveis.
A inclusão dessas informações no formato estabelecido manterá a revi-
são focada.
Em terceiro lugar, reserve tempo suficiente para a revisão. A revisão
inicial pode levar várias horas, dependendo do tamanho do projeto. Após
a revisão inicial ser concluída, as revisões de acompanhamento não devem
ser tão longas. Mas não reduza o tempo. Se achar que está ficando sem tem-
po e a revisão não tiver terminado, reserve um tempo nos próximos dias
para concluí-la.
Em quarto lugar, tome notas na revisão e divulgue-as em todos os locais
– envie-as por e-mail para a equipe, publique-as no site e discuta-as durante
as reuniões da equipe. Qualquer decisão tomada ou solução proposta deve
ser anotada nas minutas da reunião. Certifique-se também de fazer o acom-
panhamento dos itens de ação. Consulte a seção posterior deste capítulo que
discute como conduzir reuniões para obter mais informações sobre minutas
de reunião e itens de ação.
Vantagens
As vantagens das revisões de projeto é que elas mantêm todos os envolvidos
focados no cenário maior do que precisa ser concluído durante cada fase do
projeto. Portanto, em vez do aprofundamento em pequenos detalhes, como
quantas armas o jogo terá, o foco é direcionado para quando todas as armas
têm de estar prontas e quem está trabalhando nelas.
As revisões também fazem as pessoas serem francas sobre a realidade do
projeto. Se o projeto for examinado integralmente em intervalos mensais, as
áreas problemáticas serão expostas e discutidas. Se você estiver participando
de uma revisão de projeto mensal e ficar tentado a encobrir os problemas,
não estará fazendo nenhum bem ao jogo ou à sua equipe. Os problemas não
podem ser resolvidos se não forem conhecidos e discutidos.
Uma revisão de projeto mensal mantém o produtor em contato regular
com os líderes e o status do projeto. Muitos produtores alegam que sabem o
que está acontecendo em seus projetos, mas quando solicitados a fornecer um
relatório de status abrangente, descobrem que não sabem tudo e têm de con-
sultar seus líderes sobre o status exato de muitos itens. Isso não significa que
o produtor está fazendo um trabalho ruim, apenas demonstra quantas pessoas
são necessárias no controle de todas as tarefas do projeto.
Embora revisões de projeto regulares não sejam uma norma no desen-
volvimento de jogos, elas estão se tornando mais populares à medida que as
equipes de desenvolvimento crescem e mais riscos são associados aos proje-
tos. Se você estiver trabalhando em um estúdio que atualmente não faça essas
revisões no nível da gerência e do publicador, poderá começar trabalhando
com os líderes de sua equipe em uma revisão mensal. Deve acabar trazendo
também a gerência para o processo, principalmente quando eles perceberem
que essa revisão está lhes dando informações pertinentes sobre o projeto.
18.4 Análise de estágios cruciais
A Análise de Estágios Cruciais (Critical Stage Analysis – CSA) é uma téc-

nica desenvolvida por Wolfgang Hamann para fornecer melhorias contínuas
no processo de produção pela verificação do progresso do jogo em estágios
cruciais do ciclo de desenvolvimento. Esse processo é descrito com detalhes
no artigo “Goodbye Post Mortems, Hello Critical Stage Analysis”, citado no
Apêndice C, “Recursos”.
A CSA é um processo simples que ocorre em intervalos regulares (normal-
mente todo mês) e envolve a equipe inteira na resposta a estas três perguntas:
• Você pode citar cinco coisas que deram certo durante o período de de-
senvolvimento passado?
• E cinco coisas que deram errado?
• Pode citar também cinco coisas que podem ser melhoradas em períodos
de desenvolvimento futuros?
Cada membro da equipe anota suas respostas e as classifica de acordo

com a importância. Não é importante o produtor ou os líderes concordarem
com os itens listados ou as classificações, porque na verdade essa é uma ava-
liação do que cada pessoa acha sobre o projeto nesse momento. As perguntas
devem ser respondidas de dois a três dias após a conclusão de uma etapa
crucial. O que é interessante nessa técnica é que ela fornece um instantâneo
do que cada pessoa acha sobre o estado atual do projeto.
Essas respostas são entregues ao produtor, que compila as informações
em um documento mestre. O documento é enviado por e-mail para os líderes
e uma reunião é marcada dentro de dois dias para discussão do que foi desco-
berto. Soluções são discutidas para as descobertas mais importantes, e os lí-
deres são incumbidos de implementar as soluções dos problemas no próximo
período de desenvolvimento.
Quando esse plano é finalizado, uma reunião com a equipe é marcada
e as descobertas e soluções são apresentadas para a equipe inteira. Durante
a reunião, todo o feedback e as soluções propostas são discutidos e pergun-
tas são respondidas. Em reuniões subsequentes com a equipe, são fornecidas
atualizações de status sobre o andamento da solução dos problemas. Prova-
velmente os cinco problemas principais serão resolvidos e, como consequên-
cia, o processo de desenvolvimento melhorará. O objetivo principal é enfati-
zar o lado positivo e mostrar à equipe que seu feedback é levado a sério.
18.5 Relatórios de status semanais
Relatórios de status semanais também são uma boa maneira de rastrear o pro-
cesso de desenvolvimento, mas não devem ser usados em substituição à re-
visão de projeto, que é mais abrangente. Se você estiver trabalhando em um
projeto pequeno que leve menos de dois meses para ser concluído, talvez
possa avaliar com precisão o progresso do desenvolvimento com um relatório

semanal, mas projetos que demorem mais do que alguns meses também pre-
cisam de revisões de projeto.
Os relatórios de status semanais demonstram o status atual do jogo para
a equipe de desenvolvimento e para a gerência. Muitas vezes, o produtor
pode esquecer que os membros da equipe de desenvolvimento trabalham ar-
duamente nas tarefas que lhes são atribuídas e não têm tempo de ficar a par
de tudo que está sendo feito durante a produção. Por exemplo, o programador
que está codificando o sistema de animação pode não saber que a cinemática
foi concluída ou que as primeiras missões estão prontas para o playtest. O
relatório de status semanal é um meio de dizer à equipe onde o projeto está.
Para a equipe de desenvolvimento

Relatórios semanais para a equipe de desenvolvimento são uma maneira po-
sitiva de mostrar o progresso que os membros estão fazendo como equipe.
Também são um bom fórum para informá-los sobre prazos cruciais, discutir
as últimas atualizações de marketing e introduzir novos membros. Os tipos de
informações a seguir podem ser incluídos.
Atualizações departamentais: Essa é uma boa maneira de manter todos
informados sobre o que os artistas, designers e programadores estão fa-
zendo no projeto. Se um novo tipo de jogo tiver sido adicionado, inclua
isso na atualização de design. Se novos caracteres estiverem sendo usa-
dos na build, certifique-se de adicioná-los à atualização do departamen-
to de arte. Inclua qualquer coisa que possa deixar a equipe entusiasmada
com o trabalho que eles e seus colegas estão fazendo.
Informações de marketing e RP: Inclua informações sobre feiras em que
o jogo será apresentado, os últimos artigos e entrevistas sobre o jogo, as
próximas press tours, o status atual de criação da embalagem e qualquer
outra coisa que o marketing estiver fazendo para o jogo. Isso mostrará à
equipe como outras partes da empresa estão trabalhando duro para pro-
mover o jogo.
Novos funcionários: À medida que a equipe for aumentando, novos
funcionários entrarão no meio da produção. Apresente essas pessoas e
forneça um histórico curto para facilitar para os outros membros da equi-
pe conhecê-las.
Prazos iminentes: É sempre uma boa ideia lembrar prazos iminentes e
os principais itens que devem ser concluídos para que eles sejam cum-
pridos. Se a equipe for constantemente lembrada de qualquer prazo imi-
nente, terá seu trabalho pronto a tempo.
Esses relatórios podem ser enviados por e-mail, postados no site da equi-
pe, apresentados verbalmente durante a reunião periódica ou tudo isso. É
bom as informações serem apresentadas de todas formas possíveis para que
todos as recebam.
Para a gerência
Normalmente, a gerência requer algum tipo de resumo semanal do status dos
projetos. Eles querem ficar a par do progresso que o jogo está fazendo, dos
riscos que podem atrapalhar o progresso e das áreas que não estão avançando
sem problemas. O relatório semanal também serve como um bom lembrete
para o produtor do que está ocorrendo no projeto. Os tipos de informações
que devem ser incluídos em um relatório de status semanal para a gerência
são os seguintes:
Atualizações departamentais: Incluem informações sobre o progresso
que os departamentos de arte, design e programação fizeram na última
semana.
Riscos: Cite as áreas que estão em risco e não se intimide. Se a gerência
não souber que algo está até mesmo um pouco em risco, não poderá
propor nenhuma solução. Além disso, se o risco aumentar, a gerência
vai querer saber por que não foi informada sobre o problema antes que
se agravasse.
Principais prazos e aprovações: Informe sobre prazos iminentes e se há
algum risco da etapa se atrasar. Se estiver esperando aprovações de algum
conteúdo ou recurso, inclua isso também como um item do relatório.
Recursos: Se você precisar de recursos adicionais no projeto – hard-
ware, software ou pessoal –, colocar isso no relatório é uma boa maneira
de chamar a atenção da gerência.
18.6 Reuniões
Se você for um líder ou um produtor, passará muito tempo em reuniões quan-

do estiver trabalhando em um jogo – reuniões da equipe, reuniões com a ge-
rência, reuniões de líderes, reuniões de QA e assim por diante. Você perce-
berá que está passando grande parte de seu tempo em reuniões, portanto, é
importante mantê-las produtivas e eficazes. Há algumas maneiras simples de
tornar as reuniões mais úteis.
• Defina a finalidade da reunião. Antes de marcar uma reunião, defina

especificamente os objetivos e o resultado desejado. Por exemplo, o obje-
tivo poderia ser dar feedback sobre o roteiro de uma das missões. Se não
conseguir decidir quais são esses objetivos, cancele a reunião.
• Publique uma pauta. Uma vez que tiver determinado o assunto da reu-
nião, publique uma pauta para todos os participantes. Isso os ajudará
a se preparar melhor e os manterá focados durante a discussão. Se os
participantes tiverem de estudar algo antes da reunião, indique isso na
pauta. Durante a reunião, atenha-se à pauta e postergue qualquer tópico
que não estiver listado nela.
• Atribua limites de tempo. Atribuir limites de tempo para cada tópico da

pauta fará a reunião avançar e assegurará que as pessoas não permane-
çam na discussão de um tópico infinitamente. É claro que alguns tópicos
precisam de mais tempo de discussão do que outros, mas se você definir
um limite de tempo geral na pauta, terá uma ideia muito melhor da quan-
tidade de assuntos que pode realmente abordar na reunião. Certifique-se
de incluir tempo no início da reunião para expor os objetivos para os par-
ticipantes e tempo no fim para resumir qualquer decisão tomada. Se não
tiver tempo para discutir um tópico específico, adie-o para outra reunião
ou continue a discuti-lo e adie os outros tópicos.
• Comece e termine as reuniões na hora certa. Gastamos muito tempo
para trazer pessoas para uma reunião e, com frequência, as reuniões co-
meçam após 10 ou 15 minutos porque ninguém chega no horário. Ha-
bitue-se a começar as reuniões na hora certa para que quem tiver che-
gado não fique entediado enquanto os outros não chegam. Terminar as
reuniões no horário também é uma boa prática – assim fica muito mais
fácil as pessoas marcarem algo para após a reunião e evita aquele tipo de
reunião que não acaba nunca quando nada é decidido.
• Não misture coleta de informações e tomada de decisões na mesma reu-
nião. As reuniões podem rapidamente sair do planejado se você tentar
misturar coleta de informações e tomada de decisões na mesma reunião.
As pessoas podem ficar presas na parte das informações e nunca chegar
a uma decisão ou podem querer tomar uma decisão rapidamente e não
considerar todas as informações pertinentes. Se esses tópicos forem dis-
cutidos em reuniões separadas, os participantes terão mais condições de
se concentrar nas informações.
• Designe um mediador. O mediador é um participante neutro cuja função
é manter a reunião de acordo com o planejado. Ele controla a pauta e
mantém as pessoas focadas no tópico para que a reunião possa começar e
terminar na hora marcada. Não se envolve na discussão, mas redireciona
a conversa se ela se desviar da pauta.
• Faça minutas da reunião. As minutas são um registro útil do que foi
discutido na reunião e das decisões que foram tomadas. Isso evita que
as pessoas esqueçam por que a reunião foi feita e as induz a dar prosse-
guimento às tarefas que foram atribuídas durante a reunião. As minu-
tas devem listar quem participou da reunião, os objetivos da reunião, a
agenda, os pontos-chave da discussão, as principais decisões e os itens
de ação. Os itens de ação devem ser atribuídos a uma pessoa específica
e ter um prazo definido para conclusão. Como no caso do mediador, de-
signe alguém que seja neutro para tomar notas para que ele não precise
se envolver ativamente na conversa.
• Acompanhe os itens de ação. Os itens de ação são importantes subpro-
dutos das reuniões e são necessários para que alguns dos tópicos discu-
tidos na reunião sejam resolvidos. Acompanhe-os nas minutas e certifi-
que-se de que sejam concluídos no prazo.
18.7 Alocação de recursos
De tempos em tempos, o jogo pode não ter pessoal suficiente para a conclusão
das tarefas cruciais a tempo. Isso pode ocorrer por várias razões: o trabalho
foi mal-estimado, as pessoas estão de licença por doença ou de férias, mais
recursos foram solicitados e assim por diante. Ao tentar resolver problemas
de pessoal, considere a realocação temporária de recursos.
Uma maneira é tirar pessoas de tarefas menos importantes para ajudar
nas importantes. Para fazer isso, você, como produtor, deve conhecer as ha-
bilidades de todos. A maioria dos membros da equipe não estará utilizando
todas as suas habilidades em uma determinada tarefa e ficará muita satisfeita
em se dedicar a outras tarefas quando necessário, se tiver tempo. Por exem-
plo, um criador de níveis pode saber usar o After Effects e ajudar tempora-
riamente a equipe de cinemática, ou talvez um programador de ferramentas
possa ajudar na codificação da IU.
Ao tirar pessoas temporariamente de suas tarefas, você deve marcar as
datas de início e fim para que elas saibam quando devem concluir sua atri-
buição temporária e voltar a trabalhar em suas tarefas principais. Se realocar
alguém, e essa pessoa acabar sendo necessária permanentemente na nova ta-
refa, designe outra para assumir as antigas tarefas.
Outra maneira, se você estiver trabalhando em um estúdio grande com
vários projetos em produção, é tirar pessoas temporariamente de outras equi-
pes de projeto para ajudar. A outra equipe pode ser afetada, mas se tiver mais
tempo em seu cronograma de desenvolvimento, talvez possa emprestar al-
guém temporariamente.
Para concluir, considere a contratação de fornecedores externos. Você
não vai querer usá-los em tarefas do caminho crítico, mas se já tiver realocado
recursos internos para as tarefas cruciais, os fornecedores podem trabalhar
nas tarefas não cruciais. Isso liberará os membros da equipe interna para se
deslocarem para onde for necessário.
18.8 Evitando o crescimento desenfreado
O crescimento desenfreado de funcionalidades ocorre quando mais funciona-

lidades são adicionadas sem o ajuste das outras variáveis do projeto (tempo,
recursos e qualidade) para a acomodação do trabalho extra. É algo contra o
qual os desenvolvedores sempre lutam, já que solicitações de recursos são fei-
tas regularmente pela equipe, a gerência do estúdio, o publicador, o departa-
mento de marketing, os fãs e assim por diante. Se o crescimento desenfreado
não for controlado, o projeto será colocado em risco e você pode perder a data
de entrega.
Algum nível de crescimento desenfreado é bom, já que torna o jogo final
mais divertido de jogar. Por exemplo, se o esquema de controle for implemen-
tado como projetado, novas solicitações de funcionalidades para melhorar a
usabilidade podem chegar após as pessoas terem a chance de jogar com elas.
Ou após a IU ser definida, algumas das telas e botões podem ter de ser proje-
tados novamente para serem mais intuitivos para o jogador. Portanto, os de-
senvolvedores não devem ignorar solicitações de funcionalidades adicionais.
Por outro lado, algumas solicitações de funcionalidades podem ser pre-
judiciais para o projeto – são completamente inviáveis dados os outros parâ-
metros do projeto, afetam grande parte do trabalho já feito ou são tão peque-
nas que não vale a pena colocar o projeto em risco para incluí-las. Quando
funcionalidades como essas são solicitadas, é função do produtor explicar
diplomaticamente por que elas não podem ser incluídas. Pode ser difícil fazer
isso, principalmente se você tiver de explicar a um vice-presidente sênior por
que sua funcionalidade favorita não pode entrar no jogo.
Uma boa maneira de explicar por que uma funcionalidade não pode ser
incluída é ilustrar o impacto que o acréscimo dessa funcionalidade terá so-
bre o custo, o cronograma e os recursos do jogo. Por exemplo, se o marketing
solicitar que um sistema de classificação on-line seja adicionado, o produtor
pode pesquisar quanto tempo levará para a funcionalidade ser projetada, im-
plementada e testada e quem estará disponível para executar essas tarefas. O
mais provável é que uma funcionalidade dessa natureza demande várias se-
manas e várias pessoas para ser implementada, requerendo uma mudança no
cronograma e nos recursos, o que afetará diretamente o trabalho já em anda-
mento no projeto. Essencialmente, se alguém pedir que uma nova funcionali-
dade seja adicionada após o jogo estar em produção, outra funcionalidade (ou
funcionalidades) deve ser removida para o jogo ser terminado sem mudanças
no cronograma, nos recursos ou na qualidade.
EVITANDO O CRESCIMENTO DESENFREADO

Activision
O crescimento desenfreado é difícil de manejar por muitas razões. Quando um projeto é

fechado e supostamente já está com seu conteúdo definido, o produtor enfrenta muitos
desafios. Em primeiro lugar, as pessoas que querem incluir funcionalidades adicionais
pós-fechamento são as mais influentes da equipe. Às vezes, o chefe do estúdio tenta in-
cluir uma funcionalidade da qual ele gosta muito, e outras chefias, como o diretor de
criação, podem fazer lobby de um último recurso que tornará o jogo excelente.
Fora a dificuldade que os produtores enfrentam em dizer não para membros-chave
da equipe, a simples identificação das funcionalidades também pode ser complicada. O
que para um produtor é uma funcionalidade que está sendo solicitada muito tardiamente
no projeto pode ser um ajuste de polimento ou até mesmo a correção de um bug na opi-
nião de outro membro da equipe. Só se o projeto tiver sido bem gerenciado desde o início
é que não haverá esse problema de quem está certo ou errado. Algumas funcionalidades
terão inevitavelmente de ser aprovadas após a versão alfa, e alguma tolerância terá de ser
permitida. A melhor defesa em um momento mais tardio do projeto é a definição de um

pipeline de aprovação de funcionalidades com verificações e avaliações que assegure que
qualquer coisa a ser adicionada ou rejeitada no jogo passe pelas pessoas apropriadas. O
pipeline de solicitação de funcionalidades deve incluir pessoas como o produtor executivo,
o diretor do projeto e o diretor de criação para garantir que todas as solicitações sejam ma-
nipuladas levando-se em consideração aspectos do negócio, do cronograma e de criação.
Priorizando funcionalidades
Se você se planejar antecipadamente para futuras solicitações de funcionali-
dades, talvez possa incluir algumas funcionalidades adicionais no jogo, sem
remover outra que tenha sido planejada. Quando alguém fizer uma solicita-
ção, avalie a funcionalidade e priorize-a. Consulte o Capítulo 15, “Requisitos
do jogo”, para obter informações sobre a priorização de funcionalidades. Em
seguida, examine o conjunto atual de funcionalidades para determinar se al-
gum recurso da camada um pode passar para a camada dois e assim por dian-
te. Dessa forma, a nova funcionalidade poderá substituir uma funcionalidade
existente que foi planejada e o crescimento desenfreado será reduzido.
Solicitações de mudança
As solicitações formais de mudança são outra maneira de monitoração e ras-
treamento das solicitações de funcionalidades. Essencialmente, quando al-
guém solicitar a mudança ou o aperfeiçoamento de uma funcionalidade, deve
preencher um formulário de solicitação. O formulário deve pedir o seguinte:
• Descrição da solicitação
• Razão da solicitação
• Impacto se a funcionalidade não for adicionada
• Alternativas recomendadas
• Análise de como isso afetará o cronograma, os recursos e a qualidade do
projeto
• Que funcionalidade existente pode ser removida para essa solicitação
ser aceita
• Quem deve ser notificado da possível mudança
Após o formulário ser preenchido, ele será enviado para o produtor para
verificação. O produtor vai querer confirmar os detalhes do formulário, prin-
cipalmente a análise do projeto, para assegurar que as pessoas certas sejam
consultadas sobre a funcionalidade proposta e ter estimativas precisas de
como isso afetará o trabalho. Após o produtor examinar o formulário, poderá
discutir a solicitação com as pessoas necessárias, como os líderes do projeto,
a gerência do estúdio ou o publicador.
Uma pessoa deve ser o principal ponto de contato para a aprovação ou

rejeição de uma mudança de funcionalidade. Quando uma decisão final tiver
sido tomada, todas as partes interessadas devem ser notificadas. Se a funcio-
nalidade for aprovada, certifique-se de que ela seja apropriadamente docu-
mentada e adicionada ao plano do projeto.
LIDANDO COM O CRESCIMENTO DESENFREADO
Wade Tinney e Coray Siefert

Large Animal Games
Quando um projeto se atrasa, geralmente reavaliamos o design e examinamos os recursos

que podem ser removidos. Podemos reduzir o número de níveis ou personagens, remover
parte da música ou reutilizar assets de um título anterior. Dessa forma, conseguimos pre-
servar as funcionalidades básicas e ter algo a adicionar na próxima iteração do jogo. Por
exemplo, em Rocketbowl, planejamos originalmente 10 níveis, mas acabamos entregando
sete níveis e oferecemos os três níveis finais como conteúdo para download.
Os desenvolvedores de jogos têm de ser proativos na resolução dos problemas de
um projeto. Isso é verdade principalmente na Large Animals porque somos uma pequena
desenvolvedora cujos projetos normalmente são concluídos dentro de seis a oito meses.
Ou seja, não podemos esperar um mês ou mesmo uma semana para lidar com um proble-
ma que ponha a data de entrega ou o projeto em risco. Se estivermos dois dias atrasados
na arte dos personagens, por exemplo, teremos de compensar esse tempo reduzindo o
tempo de trabalho artístico em outro aspecto do jogo.
18.9 Estabelecendo processos de aprovação
Desde a gerência do estúdio e descendo a hierarquia, muitas pessoas parti-

cipam do processo de desenvolvimento de jogos e precisam aprovar certas
partes do jogo antes da produção começar. Por exemplo, elas precisam pagar
contas e querem informações de como o dinheiro é gasto, ou são responsáveis
por codificar uma funcionalidade específica e têm de verificar se o design
proposto é compatível com a tecnologia. A definição de processos de aprova-
ção é útil para a apresentação das informações necessárias a todas as pessoas,
o controle das aprovações e o registro de feedbacks. Esses processos variarão
dependendo do tamanho do projeto, de quantas pessoas terão o direito de
aprovar e do volume de informações precisando de aprovação, mas há três fa-
tores importantes existentes em qualquer processo de aprovação: mantenha-o
simples, defina e publique, e centralize o controle.
Mantenha o processo simples

Mantenha o processo o mais simples possível. Elimine qualquer etapa des-
necessária e só envolva quem for absolutamente indispensável. Mais pessoas
podem significar mais gargalos na aprovação, portanto, com menos pessoas
envolvidas o tempo de aprovação é menor. Por exemplo, se o processo de
aprovação do design das missões envolvesse os chefes dos artistas, dos pro-
gramadores, dos designers, o artista que está trabalhando no nível, os pro-
dutores e a gerência, levaria semanas para algo ser aprovado. Embora seja
extremamente importante obter feedback de todas essas pessoas, elas não têm
necessariamente de ser responsáveis pela aprovação. Em vez disso, seu feed-
back pode ser incorporado no produto final apresentado para aprovação. Esse
processo de aprovação pode ser simplificado para incluir apenas a gerência
do estúdio, um produtor, um artista líder e um designer líder.
Defina e publique
Defina e publique o processo. Essa é uma etapa que com frequência é subesti-
mada, porque nunca há tempo suficiente para se redigir algo. No entanto, se
o processo for definido e publicado, terá mais chance de funcionar, porque
todos os envolvidos terão total conhecimento de suas obrigações. A definição
do processo permite que as pessoas vejam onde há probabilidade de ocorrer
gargalos e saibam melhor onde cada item se encontra no processo.
Centralize o controle
Designe uma pessoa para rastrear todas as etapas e assets do processo de apro-
vação. Dependendo do número de assets, essa pode ser uma função de tem-
po integral. A sua restrição a uma única pessoa criará um ponto de consulta
exclusivo do status de todas as aprovações. Também dará a um bibliotecário
o controle de todos os assets e produtos finais necessários no jogo. Por exem-
plo, pode surgir confusão se houver várias listas diferentes de assets de arte
a partir das quais as pessoas estão trabalhando, em vez de uma lista mestra,
porque ninguém saberá ao certo qual é a lista correta. O bibliotecário pode
criar a lista mestra de assets e ter a palavra final sobre os assets que serão
criados para o jogo.
18.10 Forças-tarefa
As forças-tarefa são grupos multidisciplinares incumbidos de examinar pro-

blemas, formular soluções e cuidar de sua implementação no jogo. Elas são
flexíveis e autônomas, ou seja, podem operar independentemente dentro da
equipe. Sua decisão é considerada definitiva. Por exemplo, uma força-tarefa
pode ser formada para determinar como os controles do jogo funcionarão,
como a IA funcionará ou como o sistema de pontuação multijogador será im-
plementado.
Cada força-tarefa deve ser composta por pelo menos um programador,
um artista, um designer e talvez um ou dois especialistas na funcionalidade
que está sendo manipulada. Uma pessoa é designada como líder e é respon-
sável por facilitar a execução das reuniões e pesquisas necessárias, coletar
os dados e fazer um resumo da decisão final para o resto da equipe. Quando
formar forças-tarefa, atribua um prazo específico e acompanhe seu progresso
regularmente.
As forças-tarefa são úteis porque fazem as pessoas se sentirem responsá-
veis pelo jogo. Elas têm permissão para trabalhar juntas como uma pequena
equipe sem precisar se preocupar com a hierarquia gerencial estabelecida.
Já que podem trabalhar livremente e não precisam do consenso da equipe
inteira para tomar uma decisão, as soluções podem ser implementadas rapi-
damente. Em alguns casos, as decisões iniciais da força-tarefa não funcionam,
portanto, é preciso reexaminar o problema e pensar em outra solução.
Este capítulo discutiu algumas técnicas de produção para melhorar o proces-

so de produção, a comunicação ou a habilidade de identificar riscos. Embora
essas técnicas não sejam a solução para tudo, certamente podem ajudar um
produtor a resolver alguns problemas comuns encontrados durante o proces-
so de desenvolvimento.
19
CRIANDO BUILDS
Neste capítulo
• Processo de build • Notas de build
• Builds multilíngues • Evitando a pirataria
19.1 Introdução
É importante que haja um processo definido para a criação de builds regular-

mente para que os recursos e assets possam ser verificados in-game. Se não
forem criadas builds regulares, a equipe de desenvolvimento não poderá fazer
verificações apropriadas na funcionalidade do jogo ou examinar se os assets
estão sendo exibidos corretamente in-game. Por exemplo, há uma diferença
visual perceptível no modo como os assets de arte de um jogo de console são
exibidos em um PC e como aparecem em uma televisão. Vários ajustes podem
ser feitos nas televisões – alguns fornecem exibições mais claras e outros uma
aparência mais escura –, todos podendo afetar o modo como algo é exibido
in-game. O desenvolvedor não verá essas diferenças a não ser que crie uma
build e examine os assets diretamente no jogo.
Se for difícil criar uma build, isso também pode indicar que há bugs no
jogo que estão impedindo o código de ser compilado. Os desenvolvedores
podem não perceber que esses bugs existem até tentarem criar uma build. Se
muito tempo se passar sem uma build ser criada, bugs críticos permanecerão
ocultos e o código será mais difícil de manipular à medida que o desenvolvi-
mento progredir.
19.2 Processo de build
Defina o processo de build na pré-produção e implemente-o assim que pos-

sível no ciclo de desenvolvimento (geralmente isso é feito quando há assets e
código disponíveis para serem usados na criação de uma build). Quanto mais
cedo uma build puder ser compilada, mais cedo você poderá começar a corri-
gir bugs e fazer melhorias no jogo. Se o estabelecimento do processo demorar
muito, ocorrerão atrasos no desenvolvimento durante etapas cruciais, porque
os programadores gastarão um tempo precioso tentando compilar a build re-
ferente à etapa em vez de codificar recursos e corrigir erros.
Um processo flexível permite que as builds sejam criadas sob demanda.
Por exemplo, o marketing pode solicitar uma build de demonstração para
uma conferência contendo apenas certos níveis e personagens disponíveis
para serem jogados. Ou a equipe de QA pode precisar de uma build especial
que limite o acesso à opção de jogador único do jogo para fazer um teste com
16 jogadores em uma firma de testes externa.
Defina um sistema para rastrear quando algo novo for adicionado à
build. Esse sistema será útil se um artista estiver esperando uma determinada
ferramenta ficar pronta ou se um designer estiver esperando um nível ser in-
serido no jogo para que ele possa roteirizá-lo. Uma maneira simples de fazer
isso é criar uma lista de endereços de e-mail chamada “Novo na Build”, dire-
cionada ao que for adicionado à build. Por exemplo, quando um programador
inserir um código de IA de veículo atualizado, enviará um e-mail para essa
lista informando o que acabou de inserir na build. Os artistas enviarão um
e-mail “Novo na Build” sempre que um asset de arte for inserido na build, e
assim por diante. Essas ações darão ao departamento de QA uma ideia melhor
do que esperar em cada build enviada para testes e tornarão muito mais fácil
para a equipe rastrear o que está sendo adicionado à build. Os e-mails “Novo
na Build” também fornecem uma boa base para a criação das notas de build,
que serão discutidas posteriormente neste capítulo.
A contratação de um gerente de dados para gerenciar o processo é muito
útil. O gerente de dados poderá dedicar o tempo e a atenção necessários à
automação do processo de build, à correção de erros e ao teste das builds an-
tes de elas serem entregues ao departamento de marketing, ao departamento
de QA ou à gerência sênior. Ele trabalhará com o departamento de QA para
definir o cronograma de entrega de novas builds e poderá trabalhar com a
equipe para determinar os processos que podem ser automatizados e otimi-
zar o processo de build. O ideal é que defina um processo para a compilação
de uma nova build diariamente, que será então armazenada em um arquivo.
Embora talvez você não precise de uma nova build diária, é bom que haja um
sistema de builds diárias para que você sempre tenha uma build pronta com
os últimos recursos. Ainda que o gerente de dados seja a principal pessoa a
supervisionar o processo, várias pessoas terão de saber como ele funciona
para o caso de o gerente estar indisponível por algum motivo.
19 • Criando Builds 321
Cronograma de builds
Após a produção começar, a build inicial deve ser criada o mais rápido possí-
vel – bem antes de uma primeira build jogável. Isso fornecerá uma referência
para a avaliação do progresso de futuras builds. E dará um prova do conceito
e da tecnologia para a equipe de desenvolvimento e a gerência do estúdio.
Quando o jogo estiver em um primeiro estágio jogável, as builds devem ser
criadas de duas a três vezes por semana. Na versão alfa, o ideal seria o hábito
de criar builds diárias.
Quando chegar o momento em que builds diárias estiverem sendo cria-
das, o departamento de QA trabalhará com a equipe para decidir a frequência
com que elas serão enviadas para testes. É improdutivo entregar ao depar-
tamento de QA uma nova build para testes diariamente. Eles têm de passar
vários dias com a mesma build para se certificar de testar integralmente todos
os aspectos do jogo. Provavelmente, o departamento de QA só vai querer exa-
minar uma nova build a cada três a quatro dias durante a versão alfa. A fre-
quência do envio de builds para o departamento de QA aumentará à medida
que o jogo for se aproximando da liberação do código. O cronograma de builds
manterá a produção em andamento. As pessoas poderão inserir seus assets e
saber quando a build estará pronta e será enviada para o departamento de QA.
Builds automatizadas
Geralmente, um processo de build automatizada é fácil de definir e economi-
za muito tempo de desenvolvimento. Se o processo for automatizado, a pes-
soa responsável por criar a build não precisará de mais tempo para concluir
manualmente todas as etapas necessárias à compilação da build. Todas as
tarefas de build podem ser automatizadas com a configuração de uma máqui-
na de “build” separada contendo um script de programação que a instruirá a
extrair todo o código e os assets atualizados do controle de sistema de versões
e compilá-los. Após a compilação, ela gerará a build mais recente e a copiará
em um local apropriado na rede de computadores. Esse script de programa-
ção pode ser configurado para ser executado regularmente. Por exemplo, ele
pode ser configurado para ser executado às 23h toda noite para que haja uma
nova build esperando a equipe pela manhã.
O processo de automação pode ser aperfeiçoado para reduzir o tempo
em outras áreas do desenvolvimento. Por exemplo, em certos dias, o script
de build poderia ser instruído a copiar a última build em todas as máquinas
do departamento de QA para que, quando os testadores de QA chegarem ao
trabalho de manhã, ele já possa ser testado. O processo também pode incluir
scripts que procurem erros na build, como arquivos com nome errado, as-
sets ausentes ou a formatação incorreta de arquivos. O log de erros pode ser
enviado automaticamente por e-mail para a equipe para que esta comece a
corrigir os erros antes da próxima build ser criada. O programador líder deve
trabalhar com a equipe de desenvolvimento para definir a melhor maneira de

automatizar o processo de build.
Um indicador visível publicamente pode ser adicionado para mostrar
quando a build não está funcionando. Clinton Keith, da High Moon Studios,
integrou lâmpadas de lava ao processo de build: “Quando um asset é inserido
no jogo, há um conjunto de testes automatizados que testa tudo que diz respeito
a arte e código e que é enviado para o pipeline. Se os testes determinarem que
um asset produziu uma falha, uma lâmpada de lava vermelha será acionada
para indicar que a build está com problemas. Se determinarem que o asset está
funcionando corretamente, uma lâmpada de lava verde será acionada. A lâm-
pada pode ser vista pela equipe inteira e é uma maneira divertida de lembrar às
pessoas de confirmarem a precisão de seu trabalho antes que ele seja integrado
à produção”.
19.3 Builds multilíngues
As versões master multilíngues contêm vários idiomas no mesmo disco mas-

ter. Essas versões master são mais baratas de replicar porque só uma versão
master é necessária para cobrir uma ampla variedade de territórios; e é mais
fácil rastrear uma versão master do que várias versões master com diferentes
idiomas. Se seu jogo for distribuído em versões master multilíngues, lembre-
-se destes problemas:
Espaço de armazenamento? O disco tem espaço de armazenamento su-
ficiente para conter vários conjuntos de assets – isso inclui a cinemática,
os arquivos de voiceover e os arquivos de texto traduzidos. Lembre-se de
que você pode ter de armazenar cinco idiomas completos em um único
disco (inglês, francês, alemão, italiano e espanhol).
Cronograma de lançamento flexível? Se as versões localizadas estive-
rem atrasadas, como afetarão a data de lançamento da versão principal?
Se houver alguma chance de a versão principal se atrasar porque o plano
preconiza a criação de uma única versão master multilíngue, o publi-
cador pode optar por separar o SKU principal das versões localizadas
no último minuto. Pensar nesse problema com antecedência dará tempo
para descobrir a maneira mais eficiente e correta de separar os idiomas
na última hora.
Seleção de idiomas? Como será determinado o idioma a ser exibido
quando o jogo for instalado? O jogador poderá selecionar o idioma que
prefere no menu de opções, durante o processo de instalação, ou o jogo
exibirá automaticamente o idioma correto com base nas configurações
de idioma do hardware?
19.4 Notas de build
Notas devem acompanhar as builds que forem enviadas para o departamento

de QA ou para alguém de fora da equipe. As notas de build descrevem infor-
mações importantes sobre a build, como o que está funcionando, o que não
está e que bugs foram corrigidos desde a última build.
As notas de build serão diferentes dependendo do público-alvo. Todas as
notas de build devem fornecer detalhes básicos sobre a data em que a build foi
criado e seu número de versão para que possam ser associadas à build correta.
À medida que o desenvolvimento progredir, nem todas as pessoas receberão
builds; portanto, a anotação da data e do número da versão permitirá que elas
saibam quanto tempo passou desde a última vez que viram uma build funcional.
Para a equipe de desenvolvimento

As notas de build da equipe de desenvolvimento devem enfocar o que é novo
na build. Isso inclui correções de crash bugs, novos recursos implementados,
alterações nos recursos existentes e qualquer asset de arte que tiver sido adi-
cionado ou alterado.
Esse tipo de informação é particularmente útil para o departamento de
QA, que saberá que bugs foram corrigidos. Eles regredirão esses bugs confir-
mando as correções na build atual e marcando-os como fechados no banco de
dados de rastreamento de bugs. Se o departamento de QA não receber notas
de build, pode perder tempo regredindo bugs que não foram corrigidos pela
equipe de desenvolvimento.
Para a gerência
As notas de build da gerência não precisam detalhar os números específicos
de bugs corrigidos desde a última build recebida, já que a gerência está mais
interessada no progresso do jogo.
Em vez disso, enfoque os recursos que foram implementados, os que
não foram, e qualquer mudança nos recursos ocorrida desde a última build
examinada por eles. Mencione também por que a mudança foi feita: foi uma
solicitação específica da gerência ou algo que a equipe mudou? Se a mudan-
ça no recurso tiver sido solicitada pela gerência, é bom isso ser mencionado
porque pode afetar produtos de etapas futuras, principalmente se um recurso
foi deixado de lado para acomodar a solicitação. As notas de build podem
fornecer um bom registro de todas as etapas do projeto e demarcar o histórico
do progresso do jogo.
Se um desenvolvedor independente estiver trabalhando com um publi-
cador, talvez este tenha um formato específico para as notas de build, que
pode ser baseado nas definições de etapas estabelecidas no cronograma. Isso
pode facilitar para o publicador verificar a exatidão e a perfeição do produto.
Outra informação importante que deve ser incluída nas notas de build
da gerência são instruções de como instalar e executar a build. Isso é particu-
larmente importante durante o processo de desenvolvimento, já que as builds
de PC não terão instaladores e as builds de console terão de ser copiadas em
um kit de desenvolvimento para serem visualizadas apropriadamente. Essas
informações devem ser básicas e escritas em linguagem para leigos para que
qualquer pessoa possa copiar a build e fazê-la funcionar. Se um software es-
pecial for necessário além da build, terá de ser incluído nele, junto com ins-
truções de como instalá-lo.
Para os departamentos de marketing e RP

As notas de build dos departamentos de marketing e RP não devem, de forma
alguma, mencionar números específicos de bugs que foram corrigidos. Em
vez disso, devem focar nos recursos-chave que estão funcionando e seu per-
centual de conclusão. Essas notas serão enviadas diretamente para jornalistas,
junto com builds de apresentação e revisadas, portanto, certifique-se de que a
argumentação seja positiva, até mesmo na discussão de bugs visíveis no jogo.
Inclua instruções específicas para a instalação e execução do jogo. Inclua
também informações básicas sobre a jogabilidade – o esquema do controlador,
a mecânica básica, o objetivo das missões e assim por diante. Essa é uma boa
chance para a equipe de desenvolvimento divulgar as áreas do jogo que pare-
cem boas e são muito divertidas de jogar. Se houver tempo, dicas e sugestões
de como jogar também podem ser incluídas.
Com frequência os jornalistas jogam builds que ainda estão em desenvol-
vimento, logo, não se preocupam com algo que foi listado nas notas de build
como incompleto ou com bugs. Se, dos 10 níveis do jogo, só cinco puderem
ser jogados, liste nas notas de build os níveis que devem ser examinados. Cer-
tifique-se de mencionar os níveis que não foram concluídos e os principais
itens que ainda estão sendo trabalhados no nível. Qualquer asset provisório
também deve ser mencionado nas notas.
19.5 Evitando a pirataria
Os publicadores estão sempre procurando maneiras de minimizar o impacto

que a pirataria, o ato de fazer e distribuir cópias ilegais do jogo, tem sobre o
produto final. De acordo com a Entertainment Software Foundation (ESA),
a pirataria custa à indústria de software de entretenimento dos Estados Uni-
dos vários bilhões de dólares por ano, e esse número aumenta para os jogos
distribuídos em mercados internacionais. Embora os jogos sejam protegidos
por direitos autorais, é muito fácil para os piratas de software criar e vender
cópias de jogos, principalmente em outros países. Uma maneira de reduzir,
mas não de eliminar, os jogos pirateados é implementando um esquema de
proteção contra cópias.
Esquemas de proteção contra cópias

Um esquema de proteção contra cópias impede que o usuário faça uma cópia
ilegal do software. Os fabricantes de consoles têm sistemas proprietários para
limitar a pirataria. Portanto, geralmente esses esquemas de proteção contra
cópias só são aplicados a jogos de PC. Esses esquemas são os seguintes:
Proteção contra cópias de terceiros: Há software disponível para a pro-
teção contra cópias de terceiros, como o SecuROM ou o StarForce. Uma
licença deve ser comprada, e pode ser exigido um pequeno royalty por
cada cópia vendida do jogo.
Chaves de CD: As chaves de CD são números seriais exclusivos que
vêm em cada disco e geralmente são impressas na caixa ou no manual do
jogo. Durante o processo de instalação, o jogador será solicitado a digitar
a chave para verificar se o disco é autêntico e não uma cópia pirateada.
Adaptadores: Um adaptador é uma peça de hardware que vem com o
software e deve ser conectada ao computador para que o programa seja
executado. Esse método é muito caro e não é usado para jogos. Normal-
mente é encontrado em pacotes de software high-end que custam milha-
res de dólares.
Esquemas proprietários de proteção contra cópias: Alguns publica-
dores desenvolveram seus próprios métodos de proteção contra cópias.
Esses métodos podem ser mais demorados de desativar porque os pro-
tocolos em que a proteção contra cópias se baseia não são conhecidos
pelas pessoas que tentam fazer cópias ilegais do jogo.
Esses esquemas de proteção contra cópias são eficazes em impedir que o
usuário casual faça uma cópia do jogo e a dê para um amigo, mas não são tão
eficientes contra profissionais. As redes de pirataria têm as ferramentas para
decifrar esses esquemas de proteção e criar grandes quantidades de cópias de
software que são então vendidas no mercado negro. A indústria de software
como um todo ainda está procurando maneiras de combater essa prática.
Um processo de build bem organizado faz o desenvolvimento de jogos correr

mais tranquilamente, e não é difícil definir um processo automatizado que
seja ainda mais eficaz. Este capítulo discutiu como podemos definir e au-
tomatizar o processo de build e por que isso é importante. Também incluiu
uma rápida discussão sobre os vários esquemas de proteção contra cópias que
ajudam a impedir a pirataria.
20
CLASSIFICAÇÕES DE SOFTWARE
Neste capítulo
• Classificações etárias • PEGI (Europa) • OFLC (Austrália)
de software • BBFC e VSC (Reino • CERO (Japão)
• ESRB (Estados Unido) • KMRB (Coreia)
Unidos) • USK (Alemanha)
20.1 Introdução
A maioria dos países tem uma junta para a atribuição de classificação etá-
ria software de entretenimento, da mesma forma que um filme recebe uma
classificação. O produtor deve estar ciente da classificação que deseja ao de-
senvolver um jogo. Por exemplo, se o público-alvo do jogo incluir crianças
de 13 anos ou mais velhas, o conteúdo deve respeitar as diretrizes etárias
apropriadas para adolescentes. Se um jogo exibir violência gráfica, uso de
drogas ou sexualidade, correrá o risco de ser banido de certos países – o que
definitivamente não é bom para as vendas. Este capítulo discutirá as juntas
internacionais de classificação de software e as diversas diretrizes que elas
usam para a classificação de jogos.
20.2 Classificações etárias de software
Os publicadores solicitarão uma classificação a cada país em que o jogo for

lançado. O procedimento normal é o publicador enviar uma versão beta ou
quase final do jogo, junto com a documentação, para a junta de classificação
apropriada. A junta então examinará os materiais e atribuirá uma classifica-
ção. Em alguns países, a classificação não é exigida por lei, mas muitos vare-
jistas não mantêm em estoque jogos não classificados; portanto, é interessante
para o publicador enviar todos os seus jogos para classificação. Em certos
países, como a Alemanha, a lei exige que o jogo receba uma classificação an-
tes que possa ser lançado para venda. Geralmente há uma taxa envolvida que
pode variar de várias centenas a alguns milhares de dólares.
Qualquer jogo lançado internacionalmente deve ser examinado pela junta
de classificação apropriada de cada país em que é lançado. Para um jogo ser lan-
çado nos Estados Unidos, Europa, Ásia e Austrália, ele terá de obter uma clas-
sificação no mínimo em seis juntas de classificação diferentes, e cada uma terá
um processo e um conjunto de diretrizes diferentes para a definição da classifi-
cação. Por exemplo, a Entertainment Software Ratings Board (ESRB) classifica
jogos que são lançados nos Estados Unidos, o Pan European Game Information
(PEGI) classifica jogos distribuídos em grande parte da Europa e o Office of Film
& Literature Classification (OFLC) classifica jogos lançados na Austrália.*
As diretrizes são bem subjetivas, portanto, pode ser difícil para os publi-
cadores determinarem que classificação um determinado jogo receberá. Por
exemplo, a ESRB não tem regras específicas sobre o que constitui uma classi-
ficação Teen (T) ou Mature (M). Eles oferecem de bom grado algum feedback
sobre a classificação que o jogo pode receber, mas nada é garantido até ele ser
oficialmente enviado e examinado pela junta de classificação. Outros países
têm diretrizes diferentes, e algo que é classificado como apropriado para ado-
lescentes pela ESRB pode ser classificado como inapropriado para adolescen-
tes pelo OFLC. Quando estiver na pré-produção, pense no público-alvo do
jogo, determine que classificações representam melhor esse público e então
desenvolva o jogo dentro de diretrizes aceitáveis.
Em geral, as juntas de classificação se preocupam com o comportamen-
to e as ações que aparecem no jogo e não necessariamente com o fato de o
jogo ser desafiador e divertido. O principal objetivo das juntas é evitar que as
crianças e adolescentes sejam expostos a conteúdo considerado inapropriado
* N. de R.T.: No Brasil, filmes, audiovisuais para TV, jogos digitais e livros de RPG preci-
sam ser categorizados pelo Ministério da Justiça, mais precisamente pelo Departamento
de Justiça, Classificação, Títulos e Qualificação (DEJUS), que também faz a Classificação
Indicativa de cada um, de acordo com o seguinte sistema:
L: livre para todos os públicos
10: não recomendado para menores de 10 anos
18: não recomendado para menores de 18 anos.
20 • Classificações de Software 329
para sua faixa etária. Como mencionado anteriormente, esse é um processo

subjetivo, mas os órgãos fazem um esforço conjunto para fornecer classifica-
ções racionais. As principais áreas de preocupação são:
• Violência
• Linguajar
• Uso de drogas
• Temas adultos
• Sexo e nudez
• Atos criminosos
As juntas de classificação não se opõem a jogos que contenham esses ele-

mentos; apenas preferem que a exibição desses temas ocorra de acordo com a
classificação etária. Por exemplo, o PEGI faz distinção entre violência contra
seres humanos reais e contra seres humanos irreais. Jogos que exibem forte
violência contra personagens humanos reais podem receber automaticamente
uma classificação etária para maiores de 18 anos. Jogos que exibem forte vio-
lência contra seres humanos irreais, como alienígenas ou personagens fantás-
ticos, geralmente recebem uma classificação etária para maiores de 16 anos.
Além da classificação geral, que indica o intervalo de idade para o qual
o jogo é apropriado, também há descritores de conteúdo que fornecem mais
informações sobre as áreas do jogo que afetaram a classificação. Por exemplo,
a ESRB tem uma lista de mais de 30 descritores que cobrem uma ampla varie-
dade de níveis relacionados a violência, sexualidade e drogas. Alguns desses
descritores são “Sangue”, “Sangue e Vísceras”, “Linguagem Chula”, “Referên-
cia a Tabaco”, “Tabaco” e “Brincadeira de Mau Gosto”. Por outro lado, o PEGI
tem menos de 10 descritores, entre eles “Violência”, “Medo” e “Discrimina-
ção”. Ícones para cada uma dessas categorias são apresentados próximos ao
logotipo de classificação etária.
Outros componentes do jogo também podem ter de ser enviados para a
junta de classificação, como:
• Demos
• Trailers do jogo
• Pacotes de expansão
• Conteúdo para download
• Conteúdo de bônus
Se o jogo não tiver uma classificação final e o publicador quiser lançar

uma demo ou um trailer, terá de enviar o conteúdo para a junta para verifica-
ção, e é provável que ele seja classificado com “esperando classificação” ou
alguma outra categoria equivalente. As juntas não usarão uma demo ou um
trailer para determinar a classificação final de um jogo; só uma versão com-
pleta pode ser usada na determinação da classificação.
Se o jogo for lançado em várias plataformas, a junta pode requerer que
cada plataforma seja enviada separadamente para classificação. Se o conteúdo
for exatamente o mesmo em todas as plataformas, a classificação também será
a mesma. No entanto, se uma plataforma tiver algum conteúdo adicional que
possa ser considerado para adultos, talvez essa versão do jogo receba uma
classificação etária mais alta do que as outras.
Reserve um tempo no cronograma de produção para enviar o jogo para
a junta de classificação. Uma vez que o jogo for enviado, ele pode levar de
10 a 45 dias (dependendo da junta) para receber uma classificação final. Se
quiser contestar a classificação e reenviá-lo, ele demorará mais 10 a 45 dias
para receber outra classificação. A maioria das juntas prefere examinar um
jogo na versão beta, ou seja, o conteúdo está completo e o jogo pode ser jo-
gado integralmente. Algumas juntas também exigem que o jogo tenha sido
totalmente traduzido antes de o examinarem. Para concluir, os fabricantes de
console exigem os certificados de classificação como parte do processo final
de aprovação e não permitem que nenhum jogo comece o processo sem ter as
classificações etárias apropriadas confirmadas.
20.3 ESRB (Estados Unidos)
Os publicadores de software de entretenimento estabeleceram a Entertain-

ment Software Rating Board (ESRB) como junta voluntária de classificação
etária para jogos distribuídos nos Estados Unidos. Não é exigido por lei que
os jogos sejam enviados para a ESRB, mas muitos varejistas de grande porte,
como a Target e a Walmart, não mantêm em estoque jogos não classificados.
As classificações dos jogos são:
• Crianças (EC, Early Childhood): Apropriado para pessoas de três anos

ou mais velhas. O jogo não contém nada que os pais possam considerar
inadequado para crianças mais jovens.
• Todos (E, Everyone): Apropriado para pessoas de seis anos ou mais ve-
lhas. O jogo contém brincadeiras duvidosas, violência mínima ou o uso
infrequente de linguajar moderado.
• Todos, de dez anos a mais velhos (E10+, Everyone Ten and Older): Ade-
quado para pessoas de 10 anos e mais velhas. O jogo contém brincadei-
ras de mau gosto, violência moderada e um linguajar moderado.
• Adolescentes (T, Teen): Apropriado para pessoas de 13 anos ou mais
velhas. O jogo contém violência moderada, linguajar excessivo ou temas
sugestivos.
• Adultos (M, Mature): Adequado para pessoas de 17 anos ou mais velhas.
O jogo contém muita violência, linguajar excessivo e/ou temas adultos.
• Somente Adultos (AO, Adults Only): Adequado para maiores de 18
anos. O jogo contém exibições gráficas de sexo e violência.
• Esperando Classificação (RP, Rating Pending): O jogo está esperando
uma classificação final da ESRB. Os jogos não podem ser publicados sem
obter uma classificação final.
Além disso, mais de 30 descritores de conteúdo são usados para comple-

mentar a classificação etária. A ESRB está sempre revisando suas políticas,
TRABALHANDO COM A ESRB
Patricia Vance, presidente

Entertainment Software Rating Board
Que materiais devem ser enviados para a ESRB para obtenção de uma classificação?
Para ter um jogo certificado com uma classificação da ESRB, os publicadores de
software devem responder a um questionário detalhado explicando o conteúdo exato do
jogo. Esse questionário é enviado para a ESRB junto com uma filmagem do jogo e mate-
riais complementares relevantes (por exemplo, trilhas sonoras, códigos de trapaça, rotei-
ros e assim por diante). Além da filmagem representar precisamente o produto final, ela
também deve mostrar o conteúdo mais extremo do jogo.
Como o sistema e o processo de classificação funcionam?

O sistema de classificação inclui duas partes iguais. A primeira é o símbolo da clas-
sificação, encontrado na frente da embalagem do jogo, que sugere a idade apropriada. A
segunda parte contém descritores de conteúdo, encontrados na parte de trás, declarando
claramente por que um jogo recebeu uma classificação específica ou indicando conteúdo
que pode ser de interesse ou preocupante.
Após um jogo ser recebido para classificação e de haver a confirmação de que ele foi
enviado em sua totalidade, no mínimo três avaliadores assistem independentemente ao ví-
deo de cada jogo e, para cada cena, assim como para o produto todo, recomendam uma
classificação e os descritores de conteúdo que considerarem mais apropriados. Ao classi-
ficar um jogo, os avaliadores devem considerar vários elementos do conteúdo, inclusive,
mas não apenas, violência, sexo, humor, linguajar e o uso de substâncias controladas.
Também devem avaliar outros fatores, como o controle do jogador, o realismo, o sistema
de recompensas, a frequência, o contexto e a intensidade geral.
A ESRB compara as recomendações de cada avaliador para verificar se há um con-
senso. Geralmente, os avaliadores concordam com uma classificação etária geral e sua
recomendação se torna a classificação final. No entanto, quando os avaliadores reco-
mendam classificações diferentes, avaliadores adicionais examinam o jogo em busca de
um consenso. Após ser obtido um consenso referente a uma classificação, a ESRB emite
um certificado de classificação oficial para o publicador do jogo. Se o publicador não
ficar satisfeito com a classificação dada, pode reenviar o jogo com alterações e o processo
começará novamente.
É importante ressaltar que os avaliadores da ESRB não têm vínculos com a indústria
e são treinados especialmente para avaliar jogos de vídeo e computador. A maioria dos
avaliadores da ESRB tem experiência anterior com crianças, como pais, responsáveis, ou
por trabalho e educação anteriores. São funcionários que trabalham em meio expediente
na ESRB e normalmente participam de uma sessão de avaliação de três horas por semana.
A ESRB tenta recrutar avaliadores demograficamente diferentes segundo a idade (devem
ter mais de 18), o estado civil, o sexo, a raça e o histórico cultural para que reflitam toda
a população dos Estados Unidos.
Para concluir, após um produto ser enviado para o varejo, a ESRB testa os jogos
aleatoriamente para verificar se houve a abertura completa do conteúdo durante o pro-
cesso de classificação. Quando a ESRB descobre conteúdo novo que teria afetado uma
classificação, toma medidas punitivas, envolvendo a imposição de multas significativas e/
ou ações corretivas (por exemplo, uma nova rotulagem ou um novo envio do produto).
Quanto tempo a ESRB demora para avaliar um jogo e atribuir uma classificação?
Quando os materiais enviados estão completos, a avaliação e a classificação do
jogo demoram uma média de cinco dias úteis.
Em que ponto do processo de desenvolvimento um jogo deve ser enviado para classificação?
Um jogo deve ser enviado quando todo o conteúdo pertinente estiver concluído,
inclusive os elementos gráficos, os efeitos sonoros, a música e o diálogo. Com frequência
o produto é enviado antes de ser testado, e essa é uma das principais razões para a ESRB
exigir que o conteúdo seja enviado em vídeo.
É requerida uma classificação da ESRB para que um software de entretenimento seja distribuído
nos Estados Unidos?
O sistema de classificação da ESRB é voluntário, mas praticamente todos os jogos
vendidos no varejo nos Estados Unidos e no Canadá são classificados por essa junta. Isso
ocorre, em parte, graças ao comprometimento dos maiores varejistas em não aceitar jogos
que não tenham sido classificados pela ESRB. A indústria de videogames criou a ESRB em
1994 como seu corpo autorregulatório para assegurar que pais e outros consumidores
tenham informações precisas e confiáveis sobre o conteúdo dos jogos antes de comprá-los.
Se os desenvolvedores quiserem obter uma classificação específica, a ESRB pode aconselhá-los

sobre o que precisa mudar para essa classificação ser obtida?
Após a ESRB informar à empresa que enviou o jogo qual foi a classificação dada,
refletindo o consenso dos avaliadores independentes, a empresa tem três opções:
• Aceitar a classificação atribuída.

• Considerar alterações no jogo e o reenvio dos materiais na tentativa de receber uma
classificação diferente.
• Solicitar formalmente a atribuição de uma classificação perante uma junta de ape-
lação apontada pela indústria.
A empresa solicitante pode pedir uma cópia do relatório original do consenso dos
avaliadores para saber que conteúdo do jogo resultou em uma classificação específica, e
qualquer alteração que decidir fazer no produto reenviado será por definição somente dela.
Há diretrizes específicas da ESRB sobre o que exatamente diferencia uma classificação “T” ou “M”?
Há diretrizes gerais e um senso de paridade sobre como certos tipos de conteúdo es-
tão relacionados a várias categorias de classificação, como cenas intensas e prolongadas
de violência, nudez, conteúdo sexual, linguagem chula, uso de substâncias controladas,
jogatina e assim por diante. Além desses tipos óbvios de conteúdo, há poucas regras fi-
xas quando se trata de classificar jogos. A maneira como um ato específico é exibido, o
contexto em que ele ocorre, a intensidade da imagem, o sistema de recompensas e o grau

de controle do jogador podem afetar muito a categoria da classificação e os descritores
de conteúdo que acabarão sendo atribuídos ao jogo. E os avaliadores devem usar seu
próprio julgamento referente ao conteúdo sobre o qual acham mais relevante dar infor-
mações aos consumidores.
Vale a pena ressaltar que, de acordo com uma pesquisa conduzida regularmente pela
Peter D. Hart Research Associates e encomendada pela ESRB, os pais quase sempre concor-
dam com as classificações atribuídas pela ESRB. Em 2004, em 83% das vezes eles concorda-
ram com as classificações da ESRB e em 5% acharam que eram muito rigorosas. Esse nível
de aceitação nos mostra que as classificações fornecem uma indicação precisa do conteúdo
do jogo e refletem os gostos e valores do americano comum e, mais importante, dos pais
que usam o sistema para ajudar a determinar os jogos que são apropriados para seus filhos.
portanto, se você precisar enviar um jogo para eles, é melhor contatá-los di-
retamente para saber as informações mais recentes sobre o processo de envio.
20.4 PEGI (Europa)
O Pan-European Game Information (PEGI), estabelecido em 2003, é um sistema

único de classificação para a maioria dos países europeus. O sistema PEGI é
usado em mais de 25 países da Europa, inclusive França, Espanha, Itália e Rei-
no Unido. Visite o site www.pegi.info para ver a lista atualizada de países. O
PEGI também tem um segundo componente de seu sistema para jogos on-line.
Mais informações sobre esse grupo podem ser encontradas em www.pegionli-
ne.eu. É bom ressaltar que a Alemanha não usa o PEGI, preferindo estabelecer
seu próprio sistema nacional de classificação, chamado Unterhaltungssoftware
SelbstKontrolle (USK). O sistema PEGI tem as seguintes classificações:
3+: Apropriado para idades de três anos ou mais. O produto não contém
nada que os pais possam achar inadequado para crianças mais jovens.
7+: Apropriado idades de sete anos ou mais. O produto contém material
que pode ser estressante ou assustador para crianças mais jovens, violência
ocasional contra personagens irreais ou nudez em um contexto não sexual.
12+: Apropriado para idades de 12 anos ou mais. O produto contém
violência gráfica contra personagens irreais, violência não gráfica contra
humanos ou animais reais, sexualidade moderada ou profanação branda.
16+: Apropriado para idades de 16 anos ou mais. O produto contém
violência gráfica contra humanos ou animais irreais, forte conteúdo se-
xual, uso ilegal de drogas ou apologia ao crime.
18+: Apropriado para idades de 18 anos. O produto contém exibições
gráficas de violência contra humanos ou animais reais, exibições gráficas
de atos sexuais, apologia ao uso de drogas, racismo ou informações deta-

lhadas sobre como cometer atos criminosos.
Ele também tem sete descritores de conteúdo: “Violência”, “Sexo”, “Dro-
gas”, “Medo”, “Discriminação”, “Linguagem Chula” e “Jogatina”. O site do
PEGI contém todas as informações mais recentes sobre como enviar um jogo
para classificação. Embora o sistema PEGI atenda a maioria dos países da Eu-
ropa, há exceções, como o Reino Unido e a Alemanha.
20.5 BBFC e VSC (Reino Unido)
Ainda que o Reino Unido use o sistema PEGI, alguns jogos também podem
ter de ser enviados para o British Board of Film Classification (BBFC) para
uma classificação adicional. Jogos com forte conteúdo adulto devem ser clas-
sificados pelo BBFC antes de poderem ser distribuídos legalmente no Reino
Unido. Uma entidade chamada Vide Standards Council (VSC) é responsável
por determinar se um jogo precisa ser enviado para o BBFC para classificação
adicional. Se um jogo tiver de ser enviado para o BBFC, mas o publicador não
concordar e lançá-lo mesmo assim, os publicadores e varejistas que tiverem o
jogo em estoque podem ser processados criminalmente. As classificações do
BBFC são as seguintes:
U: Classificação apenas informativa. Adequado para todas as idades.
PG (Parental Guidance): Classificação apenas informativa. A orienta-
ção dos pais é recomendada.
12: Restrição de idade. Ninguém com menos de 12 anos terá permissão
para comprar um produto classificado com o rótulo “12”.
para comprar esse produto.
para comprar esse produto.
Para obter informações mais atuais sobre o processo de envio para clas-
sificação, consulte o site do BBFC (www.bbfc.co.uk).
20.6 USK (Alemanha)
A Alemanha tem classificações de idade muito rigorosas que são atribuídas

e reguladas por sua junta nacional de classificação, a Unterhaltungssoftware
SelbstKontrolle (USK). Por exigência legal, os jogos devem ser enviados para
classificação. Se os publicadores de software não concordarem com isso, se-

rão processados. As classificações da USK são as seguintes:
• Nenhuma restrição de idade

• Adequado para 6 anos ou mais
• Inadequado para menores de 18 anos
A Alemanha é conhecida por suas classificações etárias restritivas que

não oferecem muitas pistas sobre que tipo de conteúdo é aceito e qual é ba-
nido. Se você estiver planejando lançar um jogo na Alemanha, é melhor ser
cauteloso ao tomar decisões sobre o conteúdo. Por exemplo, a Alemanha é
rigorosa com crimes e símbolos de ódio, principalmente os associados ao na-
zismo; além disso, costuma banir jogos contendo muito sangue e vísceras. Em
alguns casos, os desenvolvedores criam uma versão separada do jogo para ser
lançada na Alemanha com conteúdo alterado. Consulte o site da USK para
ver as informações mais recentes de como enviar um jogo para classificação
(www.usk.de).
20.7 OFLC (Austrália)
O Office of Film & Literature Classification (OFLC) é a junta de classificação

da Austrália que atribui classificações aos jogos. Essa junta é regulada pelo
governo australiano e todos os jogos têm de ser classificados antes de serem
lançados na Austrália. Suas classificações são as seguintes:
• G: Classificação informativa que indica que o produto é adequado para

todas as idades.
• G8+: Classificação informativa que indica que o produto é adequado
para crianças com 8 anos e mais velhas. A orientação dos pais é reco-
mendada para todos que tiverem menos de 15 anos.
• M15+: Classificação informativa que indica que o produto não é adequa-
do para crianças e adolescentes com menos de 15 anos.
• MA15+: Restrição de idade que indica que crianças e adolescentes com
menos de 15 anos não podem ver ou comprar o produto a menos que
estejam na companhia de um dos pais ou de um responsável.
• RC (Refused Classification): Indica que o produto teve a classificação
recusada. Qualquer jogo que exceder as diretrizes de uma classificação
MA15+ terá a classificação recusada e não poderá ser distribuído para
venda na Austrália.
Para obter informações atualizadas sobre como enviar um jogo para o

OFLC, visite seu site (www.oflc.gov.au).
20.8 CERO (Japão)
A Computer Entertainment Rating Organization (CERO) é a organização que

classifica jogos para lançamento no Japão. Suas categorias de classificação são
as seguintes:
• Todas as idades
• 12 anos e mais velhas
Além disso, tem nove descritores de conteúdo usados junto com essas
classificações: “romance”, “sexo”, “violência”, “terror”, “jogatina”, “crime”,
“álcool/tabaco”, “drogas” e “linguajar chulo”. Seu site (www.cero.gr.jp) con-
tém informações mais atualizadas sobre o processo de envio.
20.9 KMRB (Coreia)
A Korea Media Rating Board (KMRB) classifica jogos para lançamento na Co-
reia do Sul. São duas as categorias de classificação:
• Todos
• Maiores de 18
De acordo com seu site (www.kmrb.or.kr), eles se preocupam com con-

teúdo que possa ser indesejável pelas seguintes razões:
• Violação da ordem constitucional e democrática e desrespeito à honra

nacional.
• Exibições gráficas de violência ou outras áreas problemáticas que sejam
danosas à moral pública e possam perturbar a ordem social.
• Danos às relações diplomáticas e à identidade nacional, causando im-
pacto negativo sobre os interesses nacionais.
Os jogos são banidos na Coreia do Sul quando a junta considera o con-

teúdo ofensivo. Em 2004, Tom Clancy’s Ghost Recon 2 teve a classificação
recusada pela KMRB e depois foi banido. O enredo envolvia um perigoso
general norte-coreano que tentava consolidar seu poder na Coreia do Norte.
A junta de classificação achou essa história muito radical e delicada para o
mercado coreano.
Recursos de classificação de software

Aqui estão alguns recursos de acesso às juntas de classificação de software e outras asso-
ciações envolvidas na classificação de jogos.
Juntas de avaliação de software

• Entertainment Software Rating Board (ESRB) – www.esrb.org
• Pan-European Game Information (PEGI) – www.pegi.info
• PEGI Online – www.pegionline.eu
• Unterhaltungssoftware SelbstKontrolle (USK) – www.usk.de
• Office of Film & Literature Classification (OFLC) – www.oflc.gov.au
• Computer Entertainment Rating Organization (CERO) – www.cero.gr.jp
• Korean Media Rating Board (KMRB) – www.kmrb.or.kr
Juntas de classificação
• Video Standards Council (VSC) – www.videostandards.org.uk
• British Board of Film Classification (BBFC) – www.bbfc.co.uk
• Netherlands Institute for the Classification of Audiovisual Media (NICAM, Países
Baixos) – www.nicam.cc
Associações de publicação de software

• Entertainment Software Association (ESA, Estado Unidos) – www.theesa.com
• Interactive Software Federation of Europe (ISFE) – www.isfe-eu.org
• The Entertainment and Leisure Software Publishers Association (ELSPA, Reino Unido)
– www.elspa.com
• Syndicate des Editeurs de Logiciels de Loisirs (SELL, França) – www.sell.fr
• Associación Española de Distribuidores y Editores de Software de Entretenimiento
(ADESE, Espanha) – www.adese.es
As classificações etárias de software asseguram que o conteúdo do jogo seja

apropriado para o público-alvo. Jogos extremamente violentos ou controver-
sos só devem ficar disponíveis para adultos, e o conteúdo de jogos infantis
não deve conter tópicos inapropriados ou violência real. Este capítulo discu-
tiu o processo de envio de um jogo para classificação e apresentou informa-
ções sobre o tipo de conteúdo apropriado a cada classificação.
21
LOCALIZAÇÃO
Neste capítulo
• Criando conteúdo • Planejamento da • Testando
internacional localização • Envio para o fabricante
• Código favorável à • Organizando os assets do console
localização para tradução • Lista de verificação da
• Nível de localização • Integrando os assets localização
traduzidos
21.1 Introdução
À medida que os mercados internacionais continuam crescendo, há muitas

oportunidades para os publicadores lucrarem com os jogos traduzidos e loca-
lizados. Atualmente, é prática comum os publicadores lançarem versões de
um jogo em alemão, espanhol, francês e italiano ao mesmo tempo que a ver-
são em inglês. Outros idiomas, como o chinês, o japonês e o coreano, costu-
mam ser lançados alguns meses depois, dependendo do gênero e do conteúdo
do jogo. Além disso, os jogadores de outros países estão ficando cada vez mais
exigentes sobre o que constitui um título traduzido de qualidade e querem ter
a mesma experiência de jogo que seus pares internacionais.
Se não for planejada apropriadamente, a tradução e a localização podem
ser um processo frustrante e demorado para a equipe de desenvolvimento. No
entanto, se a equipe começar a planejar as localizações na pré-produção, muitos
problemas poderão ser corrigidos e eliminados para que as versões localizadas
tenham um impacto mínimo sobre o ciclo geral de desenvolvimento do jogo.
Este capítulo apresentará uma visão geral de como podemos planejar
uma localização bem-sucedida. O tópico localização é bem extenso, e não
faz parte do escopo do livro apresentar detalhes específicos. Para obter mais
informações sobre tradução e localização, consulte The Game Localization

Handbook, de Heather Chandler. Informações completas sobre este livro es-
tão disponíveis no Apêndice C, “Recursos”.
21.2 Criando conteúdo internacional
Ao desenvolver versões localizadas, considere como o conteúdo do jogo será

recebido em outros países e tente desenvolver um conteúdo que seja cultural-
mente respeitoso. Por exemplo, se o jogo for lançado na Alemanha, não inclua
referências a nazistas – o jogo será banido nesse país e isso gerará publicidade
indesejada. Tome cuidado com a maneira como o jogo usa humor e gírias, já
que esses elementos são difíceis de traduzir e podem acabar não tendo sen-
tido nas versões traduzidas. Descubra maneiras de personalizar o conteúdo
para os mercados internacionais. Por exemplo, alguns títulos esportivos in-
cluem jogadores de vários países diferentes e o jogo deve usar como padrão a
exibição das nacionalidades apropriadas a cada jogador – um jogador francês
verá uma equipe esportiva francesa quando o jogo começar, um jogador ale-
mão verá uma equipe alemã e assim por diante.
Durante a pré-produção é importante pedir a opinião de pessoas do país
do idioma em questão sobre o design e a história do jogo. Uma pessoa que
fale o idioma poderá aconselhar a equipe sobre algo que tenha de ser pensado
melhor na versão localizada. Essas pessoas também terão sugestões sobre o
tipo de conteúdo mais aplicável a jogadores internacionais. Há muitas ques-
tões culturais a serem consideradas, portanto, certifique-se de usar quaisquer
recursos disponíveis ao desenvolver conteúdo para o jogo.
21.3 Código favorável à localização
Um código favorável à localização é aquele que é fácil de traduzir e localizar.

Ou seja, o texto e outros assets do idioma podem ser facilmente integrados
ao jogo e as builds rapidamente compiladas para teste. O código favorável à
localização leva em consideração todas as necessidades técnicas, de tradução,
integração e teste. Mesmo se as localizações não forem planejadas desde o
início, é uma boa prática a criação de um código favorável à localização para
o caso do publicador decidir localizar o jogo em uma data posterior.
Muitos fatores são considerados no planejamento de um código favorá-
vel à localização, por exemplo:
• Como os assets de idiomas serão organizados?

• Que suporte será incluído para fontes e caracteres especiais?
• Como os teclados internacionais serão suportados?
• O jogo dará suporte a legendas?
21 • Localização 341
Se questões como essas (e outras) forem planejadas na pré-produção,

será fácil criar um código favorável à localização.
Não é recomendado fazer posteriormente ajustes no código para torná-
-lo favorável à localização; isso é demorado, difícil e introduz vários bugs.
Em situações como essas, mais tempo pode ser gasto na adaptação do que no
trabalho em uma localização a partir do código atual.
Assets de idiomas
Centralize e organize todos os assets de idiomas em um diretório separado
específico do idioma dentro do jogo. Isso torna o processo de tradução e inte-
gração mais eficiente. A Figura 21.1 é um exemplo desse tipo de organização
para vários idiomas. Em cada uma das pastas para Inglês, Francês e Alemão
temos subdiretórios para “Áudio”, “Cinemática” e “Texto”.
Figura 21.1 Estrutura de diretório para a organização de assets de idiomas.
Assets de texto
O jogo deve ser armazenado em um formato que seja fácil de acessar, traduzir
e integrar. Isso economizará tempo do desenvolvedor quando os assets tive-
rem de ser organizados e enviados para tradução. Várias coisas podem tornar
os assets de texto mais favoráveis à localização. Por exemplo, não embuta em
código nenhum texto do jogo. Em vez disso, torne-o totalmente acessível a
partir de tabelas de strings armazenadas no jogo. Esse método facilita muito a
organização, a integração e o teste da tradução, porque o desenvolvedor sabe
exatamente quais arquivos devem ser localizados.
Assets de arte
Sempre que possível, evite armazenar texto em assets de arte; em vez disso,
use o código do jogo para exibir todo o texto. Se o texto tiver de fazer parte
de um arquivo de arte, certifique-se de inseri-lo em uma camada separada do

arquivo-fonte para que possa ser facilmente substituído por texto traduzido.
Assets de voiceover
Como discutido no Capítulo 10, “Voiceover”, é importante definir uma con-
venção de nomenclatura de arquivos que permita que os arquivos de voi-
ceover sejam facilmente identificados. O mesmo é verdade para arquivos de
voiceover (VO) traduzidos – estabeleça uma convenção de nomenclatura que
permita que qualquer pessoa saiba rapidamente que idioma é usado para um
determinado arquivo de VO. A música, o voiceover e os efeitos sonoros tam-
bém devem ser armazenados em trilhas separadas para que o diálogo possa
ser facilmente substituído pelo VO traduzido.
Fontes e caracteres internacionais

O mecanismo tem de poder manipular versões em letras maiúsculas e mi-
núsculas de caracteres linguísticos especiais, como ä, Õ e Ç. Atualmente, o
Unicode é o padrão para a representação de caracteres de texto, já que fornece
um número para cada caractere independente da plataforma, do programa
de software ou da linguagem de programação. Isso dá ao código do jogo a
possibilidade de exibir mais de 65 mil caracteres exclusivos, inclusive asiá-
ticos e cirílicos. Lembre-se de que se o idioma usar uma fonte asiática ou
cirílica, o mecanismo tem de estar com o byte duplo ativado e poder exibir
texto bidirecional.
Selecione uma fonte que possa ser lida facilmente nas televisões e moni-
tores de computador. As televisões usam uma resolução menor na exibição,
portanto, não selecione fontes que serão difíceis de ler quando estiverem exi-
bindo caracteres internacionais. Lembre-se de que alguns idiomas, como o
japonês, são exibidos melhor em fontes maiores. No entanto, certifique-se de
que o tamanho da fonte não seja grande demais. Se for, haverá problemas de
sobreposição na exibição de outros idiomas.
Interface de usuário
A Interface de Usuário (IU) apresenta muitos desafios de localização. Geral-
mente o texto se sobrepõe ou é cortado, forçando o tradutor a usar abreviações
ou uma tradução alternativa que caiba melhor no espaço. Lembre-se dos itens
a seguir ao projetar uma IU favorável à localização:
• Deixe espaço na IU: Como regra geral, planeje o texto traduzido 25 a

30% mais longo do que o texto em inglês. Um espaço extra deve ser
adicionado à IU para acomodar as palavras mais longas. Isso também
assegurará que as telas da IU não tenham de ser redesenhadas posterior-
mente para exibir texto traduzido.
• Use elementos de IU escaláveis: Se os botões, menus suspensos, caixas

de texto e outros elementos da IU forem redimensionados automatica-
mente, o texto traduzido poderá ser acomodado mais facilmente.
• Use ícones: O uso de ícones reconhecidos universalmente é uma boa
maneira de evitar texto traduzido.
• Dê suporte a formatos internacionais de data e moeda: Exiba datas e
moeda nos formatos apropriados.
Entrada do teclado
Para jogos de PC, determine como os comandos serão mapeados para o te-
clado. Se os comandos do teclado forem mapeados por local (por exemplo, a
tecla da extrema esquerda da fila inferior recarregará uma arma), certifique-se
de que essa tecla funcione da mesma forma em todos os teclados internacio-
nais. Além disso, o redator do manual de cada idioma deve indicar as teclas
exatas no manual, já que o nome da tecla será diferente em cada país. Se os
comandos do teclado forem mapeados diretamente para as teclas (por exem-
plo, ~ mudará a arma que o jogador está usando), verifique se todas as versões
de teclado têm essa tecla disponível. Se não tiverem, será necessário selecio-
nar uma tecla diferente para mapear o comando nesse idioma.
PAL e NTSC
Se jogos de console estiverem sendo desenvolvidos, será importante que o
mecanismo do jogo dê suporte aos padrões de vídeo NTSC e PAL. O NTSC é o
padrão de exibição nos Estados Unidos e no Japão. Nesse formato, a imagem
do vídeo distribui 525 linhas de resolução a 60 half-frames (meio quadro) por
segundo. O PAL é o padrão de exibição na Europa e a imagem do vídeo distri-
bui 625 linhas a 50 half-frames por segundo.
Se o jogo não der suporte a padrões PAL, será exibido incorretamente em
monitores de vídeo PAL. Se uma imagem NTSC for exibida em um monitor
de vídeo PAL, ela parecerá ter barras pretas no topo e na base da tela, porque
o NTSC tem 100 linhas de resolução a menos. Além disso, a imagem tremerá
porque um jogo sendo executado a 60 half-frames por segundo estará sendo
exibido em um monitor que só pode suportar uma taxa de atualização de 50
half-frames por segundo.
Outras considerações técnicas

Você deve considerar vários outros aspectos técnicos ao criar um código favo-
rável à localização:
Legendas: O jogo terá a funcionalidade de exibição de legendas? Se ti-
ver, o publicador pode decidir legendar os arquivos de voiceover das
versões localizadas em vez de traduzi-los totalmente.
Sincronia labial: Como a sincronia labial será manipulada in-game e na

cinemática pré-renderizada? A maneira mais comum é a dublagem, em
que o diálogo traduzido substitui o diálogo original e o animador tenta se-
guir os movimentos da boca do personagem da melhor maneira possível.
Compatibilidade entre idiomas: Quando há um componente on-line do
jogo, geralmente usuários de diferentes países conseguem jogar uns con-
tra os outros. Se for esse o caso, as diferentes versões localizadas têm de
poder jogar umas contra as outras.
21.4 Nível de localização
O ponto até onde os assets do jogo serão traduzidos pode variar de um projeto
para outro, dependendo de quantos recursos estiverem disponíveis para se-
rem investidos na tradução e localização e do possível retorno sobre o investi-
mento. O processo é dimensionado de acordo com as necessidades e expecta-
tivas do jogo. Há três níveis principais para a tradução e localização de jogos:
Tradução da embalagem e do manual: A tradução da embalagem e do
manual do jogo, normalmente chamados de “caixa e documentos”, é um
dos níveis de localização. A versão original do código e do idioma do
jogo permanece inalterada, mas o manual, a embalagem e outros docu-
mentos de suporte são traduzidos para o idioma de destino.
Localização parcial: Uma localização parcial significa que só o texto in-
-game será traduzido, sem que isso ocorra com nenhum dos arquivos
de voiceover. Esse método é mais barato, já que não são gastos tempo e
dinheiro na tradução do texto do voiceover, na marcação de sessões de
gravação e na execução de outras tarefas necessárias à localização de
voiceovers. Em alguns casos, os arquivos de voiceover podem ser legen-
dados, mas só se o código der suporte a esse recurso.
Localização completa: Uma localização completa inclui a tradução do
texto, do voiceover, do manual e da embalagem. Ela pode ser cara e desa-
fiadora se o código do jogo não for favorável à localização e os assets não
estiverem bem organizados dentro do código.
21.5 Planejamento da localização
Antes de traduzir e localizar um jogo, trabalhe com a equipe de vendas para

determinar se as vendas projetadas representam uma tradução lucrativa. Co-
mece examinando quantos assets devem ser traduzidos, quanto custarão as
traduções e qual será o tempo de desenvolvimento necessário. Essas informa-
ções também serão necessárias para qualquer fornecedor externo que quiser
fazer uma proposta de produção de localizações.
A Figura 21.2 ilustra um formulário de visão geral de assets que é usado
na estimativa do número de assets a serem traduzidos. O desenvolvedor for-
nece as informações solicitadas e o envia para o tradutor para a estimativa de
custos. Esse formulário é um bom ponto de partida para a coleta de todas as
informações necessárias sobre as localizações. Como ele fornece uma visão
geral do projeto e é preenchido antes dos assets do jogo estarem concluídos,
as estimativas têm de servir.
Cronograma, orçamento e equipe

O cronograma de tradução e localização pode ser dividido em quatro áreas
principais:
• Organização de assets para tradução – Inclui o tempo necessário à con-

versão dos assets de texto para um formato com o qual os tradutores
possam trabalhar facilmente.
• Traduções – Inclui o tempo necessário à tradução e registro do VO tra-
duzido.
• Integração de assets traduzidos – Inclui o tempo necessário à integração
dos arquivos de arte, texto e VO e à compilação de builds.
• Testes – Inclui os testes tanto de funcionalidades quanto linguístico.
Assets de texto in-game no Formato de distribuição Comentários

Número de palavras a serem traduzidas
NO SITE Número de arquivos de texto a serem
modificados
Assets de arte
Número de palavras dos assets de arte
Número de assets de arte a serem
modificados
Assets de voiceover
Número de palavras do roteiro de VO
Número de arquivos de VO a serem
modificados
Número de personagens a serem gravados
Tempo total de VO (min:seg.)
ASSETS CINEMÁTICOS
Número de palavras do roteiro cinematográfico
Número de cinemáticas a serem modificadas
Número de personagens a serem gravados
Tempo total de diálogo com sincronia labial
Tempo total de cenas de corte (min:seg)
MATERIAIS IMPRESSOS
Número de palavras do manual
Número de elementos gráficos do manual a
serem modificados
Número de palavras do texto da caixa
Número de elementos gráficos da caixa a
serem modificados
Outros materiais impressos
Figura 21.2 Formulário de visão geral de assets.

É claro que cada projeto traduzido terá um cronograma diferente, mas

se as localizações forem planejadas antecipadamente e correrem de acordo
com o cronograma, espere gastar uma média de dois a três meses na pro-
dução da versão localizada. A Figura 21.3 é um exemplo de cronograma de
tradução e localização inicial com estimativas gerais. Crie esse cronograma na
pré-produção para a equipe de desenvolvimento poder se preparar com ante-
cedência para tarefas-chave. À medida que o desenvolvimento avançar, crie
um cronograma mais detalhado para rastrear com mais exatidão o progresso
das localizações.
Uma vez que o formulário de visão geral de assets e uma estimativa de
cronograma inicial estiverem concluídos, um orçamento poderá ser criado. Se
estiver usando tradutores externos, procure o melhor preço.
Lembre-se de incluir custos de todo o pessoal de desenvolvimento ne-
cessário – que geralmente inclui um programador, um artista e um produtor
associado em meio expediente e testadores. Provavelmente os custos de desen-
volvimento mais significativos serão os de testes, principalmente se o jogo for
complexo e com muito conteúdo. Designe uma única pessoa da equipe de de-
senvolvimento para gerenciar todos os aspectos da localização, inclusive forne-
cedores externos. Se essa pessoa for o contato principal para a resolução de to-
das as dúvidas sobre localização, o processo avançará sem maiores problemas.
Tarefa Idioma Recursos Duração Data inicial Data final

Congelar os assets de VO em inglês Francês Equipe de desenvolvimento 1 dia 5 de julho, 2009 5 de julho, 2009
Congelar os assets de texto em inglês Francês Equipe de desenvolvimento 1 dia 26 de julho, 2009 26 de julho, 2009
Organizar os assets de VO para tradução Francês Equipe de desenvolvimento 3 dias 6 de julho, 2009 9 de julho, 2009
Organizar os assets de texto para tradução Francês Equipe de desenvolvimento 3 dias 27 de julho, 2009 30 de julho, 2009
Texto in-game traduzido Francês Tradutor 2 semanas 30 de julho, 2009 13 de agosto, 2009
Roteiro de VO traduzido Francês Tradutor 2 semanas 9 de julho, 2009 23 de julho, 2009
Escalação de atores para o VO localizado Francês Estúdio de som 1 semana 9 de julho, 2009 23 de julho, 2009
Arquivos de VO localizado registrados e processados Francês Estúdio de som 3 semanas 23 de julho, 2009 13 de agosto, 2009
Arquivos de texto integrados Francês Equipe de desenvolvimento 1 semana 13 de agosto, 2009 20 de agosto, 2009
Arquivos de VO localizado integrados Francês Equipe de desenvolvimento 1 semana 13 de agosto, 2009 20 de agosto, 2009
Teste linguístico Francês Testadores de idiomas 4 semanas 27 de agosto, 2009 17 de setembro, 2009
Teste de funcionalidades Francês Testadores de funcionalidades 3 semanas 20 de agosto, 2009 17 de setembro, 2009
Aprovações de terceiros Francês Publicador externo 6 semanas 17 de setembro, 2009 29 de outubro, 2009
Data de entrega Francês n/a 1 dia 29 de outubro, 2009 29 de outubro, 2009
Figura 21.3 Cronograma inicial de tradução e localização.
21.6 Organizando os assets para tradução
Se as versões localizadas forem lançadas após o jogo principal ser entregue, um

kit de localização pode ser criado e enviado para o tradutor. Consulte o Capí-
tulo 25, “Kits de fechamento”, para obter mais informações sobre isso. Esse kit
conterá um conjunto completo de assets que já estão organizados para tradução.
Se as versões localizadas forem entregues simultaneamente com a versão
principal do jogo, um pipeline de localização terá de ser definido para o envio
de assets para tradução à medida que o conteúdo for sendo finalizado e inse-
rido no jogo. Um processo abrangente de rastreamento e atualização de assets
deve ser criado para o processo de localização avançar com o mínimo de pro-
blemas. Envolva o fornecedor de localização na criação desse processo para
que ele tenha um senso de responsabilidade e interesse pessoal pelo jogo. Se
o processo não for organizado, tempo será perdido para sabermos quais assets
e versões foram ou não enviados para tradução.
Os tradutores poderão traduzir o jogo de maneira mais apropriada se
entenderem integralmente o contexto do que lhes está sendo pedido para tra-
duzir. Isso pode ajudá-los a avaliar o tom geral das traduções, lhes dar tempo
para pensar nos padrões de fala dos personagens, e proporcionar uma com-
preensão completa do contexto do jogo. Os tradutores se beneficiam do rece-
bimento dos tipos de recursos e documentos a seguir:
• Versão jogável do jogo

• Documentos de design
• Trapaças/detonados
• Notas de escalação de voiceover
• Glossário
• Visão geral técnica – Inclui informações sobre os formatos de distribui-
ção de arquivos e qualquer ferramenta com as quais os tradutores tive-
rem de trabalhar.
Será muito simples organizar os assets de texto e arte para tradução se o

código do jogo for favorável à localização. Talvez o produtor possa criar um kit
de tradução contendo todos os assets organizados de uma maneira lógica. Se
os assets do jogo não forem organizados logicamente, o produtor terá de passar
todos os assets de arte e texto para um local central e criar uma planilha de
rastreamento para garantir que todos os arquivos sejam enviados para tradução.
Quando os assets de voiceover forem enviados para tradução, o forne-
cedor precisará de todos os recursos discutidos no Capítulo 10, “Voiceover”.
Além disso, o envio das versões originais em inglês dos arquivos de voiceover
pode ajudar no processo de escalação do elenco e fornecer uma referência
para o ator conhecer melhor o tom e o contexto da leitura de linhas. Se a sin-
cronia labial for usada na cinemática localizada, também será necessário en-
viar os códigos de tempo dos arquivos originais para os arquivos traduzidos
os seguirem o máximo possível.
Inclua tempo no cronograma para a tradução de qualquer outro recurso
que for necessário antes do jogo ser entregue, como:
• Embalagem (inclusive qualquer screen shot)

• Informações de suporte ao cliente
• Contrato de licença do usuário final
21.7 Integrando os assets traduzidos
A integração de assets envolve várias modificações nos arquivos e pode ser

muito demorada, principalmente se o processo não for automatizado ou or-
ganizado como parte do pipeline principal de produção. As equipes de de-

senvolvimento estão sempre procurando maneiras mais eficientes de criar os
assets localizados.
A facilidade da integração será afetada pela disposição dos assets no
jogo. Se o texto for embutido em código, será arriscado substituí-lo pelo texto
traduzido. Há uma grande probabilidade de bugs serem introduzidos no có-
digo se alguém tentar recortar e colar texto dentro do arquivo. Isso também é
muito demorado e não pode ser automatizado facilmente.
Se os assets a serem traduzidos e localizados forem separados em uma
pasta específica do idioma dentro do código do jogo, o texto será substituído
mais facilmente pelas traduções. Esse método também permite uma automa-
ção mais fácil do processo. Encontrar maneiras de automatizar a integração
do texto, com a criação de uma ferramenta proprietária ou o uso de software
existente, reduzirá o número de bugs linguísticos.
Basicamente, há dois processos de desenvolvimento preferenciais para a
integração de assets. Em um deles, são os próprios desenvolvedores que ma-
nipulam a integração de assets. As traduções são terceirizadas para falantes
nativos do idioma, mas a equipe é responsável por integrá-las ao jogo. Os be-
nefícios desse processo são que as dificuldades técnicas podem ser resolvidas
facilmente, a integridade dos assets é mantida e o desenvolvedor tem mais
controle sobre o cronograma e os recursos.
As desvantagens são que o desenvolvedor tem de alocar tempo de pro-
dução para essa tarefa, o que pode tomar o tempo gasto no polimento do jogo.
Também é gasto tempo na espera dos tradutores fornecerem correções de er-
ros linguísticos. Se o tempo de espera for muito grande, o desenvolvedor terá
de conter o ímpeto de buscar traduções em outros locais, que podem não ser
muito confiáveis. E com frequência o desenvolvedor tem de confiar em ter-
ceiros (geralmente do mercado internacional) para aprovar as versões finais.
Isso pode ser muito demorado se o responsável não souber lidar com erros
menores e segurar o lançamento do jogo.
Uma vez que um conjunto inicial de assets traduzidos tiver sido integra-
do, eles devem ser inseridos no sistema de controle de versões para poderem
ser facilmente rastreados durante o desenvolvimento. Se houver várias atuali-
zações na versão em inglês do jogo, elas terão de ser transpostas para os assets
traduzidos. Se não forem inseridas no controle de código-fonte, será muito
difícil implementá-las.
Após os assets serem integrados ao jogo, certifique-se de que o conjunto
correto de assets seja usado no idioma pretendido. A mistura de assets é um
erro comum, principalmente quando eles não são registrados em um sistema
de controle de versões. Em alguns casos, certas informações dos assets do
idioma de origem terão de ser atualizadas para cada território, como informa-
ções de registro de software e suporte ao cliente.
Outra opção de integração é a contratação de um fornecedor de locali-
zação para fazer a tradução, a integração e os testes. Isso é benéfico porque
grande parte do trabalho de localização é terceirizada para que a equipe de
desenvolvimento possa se dedicar ao jogo propriamente dito. O desenvolve-
dor precisará fornecer um kit de localização completo (discutido no Capítulo
25, “Kits de fechamento”) e ter alguém disponível para responder perguntas

ou resolver qualquer problema. A principal desvantagem é que o desenvolve-
dor tem menos controle sobre o processo e precisa confiar na capacidade do
fornecedor concluir o trabalho a tempo e sem erros. O custo também é outro
problema que deve ser considerado – os custos podem aumentar rapidamente
para incluir tradutores, testadores linguísticos e gerentes de projeto. Esses
custos crescerão velozmente se o fornecedor da localização encontrar algum
problema no uso do kit de localização.
21.8 Testando
Essa é uma tarefa demorada porque tanto o teste linguístico quanto o de funcio-
nalidades têm de ser feitos para a versão de cada idioma. Além disso, todas as
versões precisam ter a compatibilidade entre idiomas testada no ambiente mul-
tijogador. Podemos economizar tempo do cronograma de testes se houver pes-
soas suficientes para fazer testes concorrentes de idiomas e funcionalidades.
Teste de funcionalidades
O teste de funcionalidades procurará qualquer bug que tenha sido criado pe-
los assets traduzidos, cuja correção geralmente demanda uma alteração no
código. O ideal é que se for feita uma troca direta do asset, nenhum bug seja
introduzido na funcionalidade. No entanto, se os caracteres especiais e o au-
mento do tamanho do texto não tiverem sido considerados, alterações no có-
digo podem ser necessárias para a acomodação dos assets traduzidos.
O teste de funcionalidades pode ser manipulado pela mesma equipe de
QA que testou a versão principal do jogo – eles saberão melhor como testar
a funcionalidade do jogo. Mesmo se não falarem os idiomas que estiverem
verificando, podem encontrar estouros de texto, assets de idioma incorretos
e outros bugs de funcionalidades. Esses bugs devem ser registrados no banco
de dados central de rastreamento de bugs. Adicione um campo para informar
que idioma está sendo testado para que o banco de dados possa ser classifi-
cado por idioma, se necessário. Os bugs de funcionalidades encontrados nas
versões localizadas serão corrigidos pela equipe; é possível que também este-
jam presentes na versão principal do jogo.
Teste linguístico
O teste linguístico verifica todos os assets de idioma do jogo para examinar
se o texto não está em sobreposição, truncado, escrito errado ou gramatical-
mente incorreto. Também verifica se todos os arquivos de voiceovers traduzi-
dos estão sendo reproduzidos corretamente. O teste linguístico deve ser feito
por falantes nativos do idioma, já que eles estão mais qualificados para achar
erros na tradução e no contexto. Há vários fornecedores de localização que
oferecem serviços de teste linguístico.
Em alguns casos, principalmente em localizações mais complexas, os tes-

tadores linguísticos podem trabalhar in loco junto com a equipe de desenvolvi-
mento. Isso acelera muito o teste linguístico e o processo de correção de erros,
já que os testadores linguísticos podem fornecer traduções corrigidas imediata-
mente. Um planejamento antecipado deve ser feito se os testadores linguísticos
viajarem para trabalhar in loco com a equipe de desenvolvimento. Se essa ação
não for bem organizada, o tempo dos testadores não será tão proveitoso.
Os testadores linguísticos terão de se familiarizar com o jogo antes de
começar a testar. O plano de teste de funcionalidades também pode ajudá-los
a conhecer o jogo e todos os seus recursos.
Eles precisarão de um plano de teste de localização que lhes mostre que
locais das traduções devem ser examinados. Uma maneira de se fazer isso é
solicitar que comparem o texto do jogo com a planilha de tradução de texto
que fizeram. A Figura 21.4 é um exemplo onde mais informações foram adi-
cionadas à planilha de tradução para ajudar os testadores a examinar o jogo.
Local PORTUGUÊS FRANCÊS NOTAS

AI(M01) Um policial foi atingido! A missão falhou. Un officier de police a été abattu. Condição de falha que
NO SITE
Echec de la mission. aparece como mensa-
gem pop-up no jogo
M01 1. Desarmar o sistema de segurança 1. Désactivez le système de sécurité Aparece na tela de

inicialização, na tela
de instalação e no
menu “iniciar” in-game
Install Deseja que um atalho seja inserido na Souhaitez-vous créer un raccourci pour Aparece durante
área de trabalho para inicializar o jogo? pouvoir lancer le jeu à partir du bureau? a instalação
Uninstall Deseja remover a pasta do jogo inteira? Souhaitez-vous effacer complètement le Aparece durante
Isso excluirá a pasta em que o jogo foi dossier du jeu? Cela détruira l’ensemble a instalação
instalado e tudo que houver nela. du dossier dans lequel le jeu a été
installé et les éléments qu’il contenait.
Equip A principal arma atribuída é a M4, com Les armes assignées sont le M4, comme Aparece na tela de
uma pistola de 9 mm como arma arme principale, et le pistolet 9mm, ajuda de seleção de
secundária. Flashbangs são fornecidas comme arme secondaire. Les grenades equipamentos
para deter inimigos e um sensor de aveuglantes sont fournies pour éliminer
batimento cardíaco deve ajudar les ennemis. Le détecteur cardiaque
a localizá-los. devrait vous aider à les localiser.
IFF(M03) um guarda un garde Aparece quando
apontamos a mira
para um personagem
Figura 21.4 Exemplo de plano de teste de localização.
Determine antecipadamente como os erros linguísticos serão relatados.

Se o desenvolvedor não exigir que os erros sejam informados em um formato
específico, os testadores linguísticos podem não fornecer informações sufi-
cientes sobre o erro e como corrigi-lo. Isso é verdade principalmente quando
as correções são feitas por pessoas que não falam o idioma. A Figura 21.5 é
um modelo de relatório de erros linguísticos. Ele inclui informações sobre
Erro no Idioma Local do jogo Descrição do erro Texto incorreto Texto correto Status do erro
NO SITE 2 Alemão IU – Menu de opções Favor usar letras minúsculas. Schritt Nach Rechts Schritt nach rechts Fechado
4 Alemão IU – Menu de opções Texto não traduzido. Usar Item Gegenstand benutzen Corrigido
Figura 21.5 Modelo de relatório de erros linguísticos.
onde encontrar o erro, uma descrição do erro (geralmente uma tradução in-
correta) e a solução (que costuma ser a tradução correta).
21.9 Envio para o fabricante do console

No trabalho com títulos de console, as versões traduzidas e localizadas de um
jogo devem ser enviadas para a Microsoft, Sony ou Nintendo para aprovação.
Todos esses publicadores têm filiais na Europa e na Ásia que devem aprovar o
jogo antes dele ser lançado em seus respectivos países. Na maioria dos casos,
o desenvolvedor envia as versões para as filiais desses publicadores na Eu-
ropa, Ásia e Estados Unidos ao mesmo tempo, antes do lançamento mundial
do jogo. No entanto, isso não garante que as aprovações ocorram ao mesmo
tempo; um jogo pode ser aprovado para lançamento na Europa antes de ser
aprovado para lançamento nos Estados Unidos.
Para que o processo de envio ocorra sem problemas no caso de versões
localizadas, lembre-se do seguinte:
Requisitos técnicos: Certifique-se de atender qualquer requisito técnico
específico da localização.
Terminologia: A Sony, a Microsoft e a Nintendo têm uma terminologia
específica do console que deve ser padrão em todos os jogos. Por exem-
plo, a Microsoft exige o uso do termo “thumbstick”*. Essa lista de termos
é verificada durante a aprovação final, e se os termos corretos não forem
usados no jogo, ele não será aprovado. A lista de termos também inclui
traduções aprovadas para todos os termos.
Mensagens de erro: Os publicadores também verificarão todas as mensa-
gens de erro do jogo para saber se elas estão usando a terminologia exigi-
da. Pode ser difícil para os testadores linguísticos verificar as mensagens
de erro, já que eles não verão a maioria delas nem saberão as etapas neces-
sárias para ver uma mensagem de erro específica. Imprima as mensagens
de erro encontrados e envie-as para os testadores linguísticos antes que
eles comecem a testar o jogo. Eles poderão verificar o conteúdo das men-
sagens para saber se são compatíveis e estão linguisticamente corretas.
* N. de R.T.: Pequena alavanca analógica existente nos joysticks (por exemplo, do Xbox 360).
21.10 Lista de verificação da localização
A Figura 21.6 é uma lista de verificação da localização que descreve as princi-

pais tarefas a serem consideradas durante as fases de pré-produção, produção
e encerramento das localizações. Essa lista de verificação pode fornecer um
bom ponto de partida para você formular um plano de localização do início
ao fim. Para obter informações mais detalhadas sobre localizações, consul-
te The Game Localization Handbook, de Heather Chandler, publicado pela
Charles River Media.
Pré-produção S/N Notas

CONSIDERAÇÕES TÉCNICAS
NO SITE
O jogo dá suporte ao padrão Unicode?
Todos os assets de idioma estão em um diretório do jogo que pode ser facilmente acessado?
A funcionalidade de fornecimento de legendas será necessária?
Teclados traduzidos são suportados para as entradas do jogador?
Vários idiomas serão incluídos no mesmo CD-ROM?
As versões localizadas serão compatíveis com o ambiente multijogador?
As caixas da IU se redimensionam para acomodar strings de texto de tamanhos diferentes?
Algum software adicional é necessário para ajudar na localização?
Os formatos internacionais de moeda e data/hora são suportados?
Um sistema de controle de versões foi definido para as localizações?
O pipeline de localização foi definido?
OUTRAS CONSIDERAÇÕES
As versões localizadas virão simultaneamente com a versão em inglês?
O formulário de visão geral de assets foi preenchido e enviado para o tradutor?
Os idiomas foram determinados?
Fornecedores externos produzirão as localizações?
Se for esse o caso, os pedidos de propostas estão preparados?
O orçamento foi concluído e aprovado?
O nível de localização foi determinado para cada idioma?
O cronograma geral foi criado e finalizado?
Há recursos de desenvolvimento disponíveis para as localizações?
Foi determinado um método para a integração de assets de texto?
Foi determinado um método para a integração de assets de VO?
Foi determinado um pipeline para a correção de bugs?
As medidas apropriadas foram tomadas para atendermos todas as juntas de classificação
internacionais?
Os publicadores pertinentes foram informados sobre as versões localizadas?
O suporte ao padrão PAL será necessário para versões de console?
Há hardware suficiente para os testes de funcionalidades e linguístico?
Figura 21.6 Exemplo de lista de verificação da localização. (Continua)

PRODUÇÃO
Um cronograma detalhado foi concluído e divulgado para a equipe?
O documento de visão geral da localização foi enviado para o coordenador da localização
ou os tradutores?
Todos os documentos de pré-produção do jogo foram enviados para o coordenador da
localização ou os tradutores?
A última build em inglês do jogo foi enviada para os tradutores?
Os assets de texto foram organizados para tradução e enviados para o coordenador
da localização?
O roteiro de voiceover e as notas de escalação de personagens foram enviados para o
coordenador da localização?
Os arquivos finais de voiceover em inglês foram enviados para o coordenador da localização?
Todos os assets de arte a serem localizados foram enviados para o coordenador da localização?
Todos os assets cinemáticos e códigos de tempo foram organizados e enviados para o tradutor?
As traduções dos assets de texto foram concluídas?
Os arquivos de voiceover localizados foram gravados e processados?
Os arquivos de texto e voiceover foram integrados?
A cinemática foi localizada?
As versões localizadas foram enviadas para a junta de classificação apropriada para aprovação?
A versão master contém demos de outros jogos que foram solicitadas pelo departamento
de marketing?
O teste de funcionalidades foi concluído?
Todos os bugs de funcionalidades foram corrigidos e o código do jogo foi liberado?
O teste linguístico foi concluído?
Todos os erros linguísticos foram corrigidos e a aprovação final do idioma foi dada?
As versões localizadas foram enviadas para o replicador (PC) ou submetidas ao publicador
(consoles e celulares)?
ENCERRAMENTO
Uma demo localizada terá de ser produzida?
Capturas de tela localizadas foram obtidas para o manual e a caixa?
Um kit de fechamento foi criado para todas as versões localizadas?
Todos os patches foram localizados e disponibilizados? (Se necessário)
Figura 21.6 Exemplo de lista de verificação da localização.
Traduções e localizações de qualidade estão se tornando obrigatórias nos mer-

cados internacionais atuais. Os jogadores querem sentir que estão jogando um
jogo feito para eles, e não apenas um jogo qualquer traduzido às pressas com
dublagens fracas e erros nas traduções. Se os desenvolvedores planejarem
antecipadamente as localizações no início do processo de produção, poderão
criar localizações de alta qualidade para serem lançadas junto com a versão
principal do jogo. Este capítulo forneceu uma visão geral de como planejar
e executar localizações. A organização de assets para tradução e o teste das
versões localizadas também foram discutidos.
Parte VII
TESTES
O s testes começarão em algum ponto do ciclo de produção, geralmente per-

to do lançamento da versão alfa. Nesse ponto do desenvolvimento, vários
elementos do jogo devem ser verificados em busca de defeitos e crash bugs. Os
testes são parte integrante do desenvolvimento de jogos; portanto, é importante não
encurtar o cronograma de execução de testes à medida que a fase de produção for
chegando ao fim.
Os testadores de QA fornecem um serviço inestimável em todo o ciclo de pro-
dução, e seu líder deve ser incluído em decisões de todos os níveis sobre o jogo.
Após os testes começarem, haverá um tempo dedicado à procura de defeitos e a ga-
rantir que eles sejam corrigidos antes de o jogo ser entregue. Esta seção apresentará
informações-chave sobre a fase de testes.
• Criação de planos de testes

• Ciclo de testes
• Processo de liberação do código
• Processo de envio para o fabricante do console
22
TESTES
Neste capítulo
• Cronograma de • Plano de testes • Ciclo de testes
testes • Pipeline de testes • Testes externos
22.1 Introdução
Para muitas pessoas de fora da indústria de jogos, a execução de testes parece

um trabalho glamoroso. Afinal, o testador joga o dia todo! No entanto, se você
conversar com alguém que ganha a vida testando jogos, vai saber que essa
função é tudo menos glamorosa. Na verdade, a execução de testes é uma ta-
refa estressante e difícil. A maioria dos testadores passa pelo menos de cinco
a oito meses testando o mesmo jogo diariamente, procurando defeitos, con-
firmando correções de bugs e executando o playtest das missões. Isso passa
a ser muito tedioso após algumas semanas, independentemente de o jogo ser
divertido. Muitas vezes, os testadores não têm nem mesmo a chance de ape-
nas jogar e apreciar o jogo, já que estão procurando problemas específicos.
Outra coisa que aumenta o estresse da execução de testes é que rara-
mente os cronogramas de desenvolvimento de jogos alocam um bom tempo
para que tudo seja testado, ou seja, com frequência os testadores fazem mui-
tas horas extras (até tarde da noite, nos fins de semana e nos feriados) para
que o jogo seja testado e esteja pronto para a liberação do código. Uma das
razões pela qual isso ocorre é porque o teste é a última atividade do ciclo de
produção. Portanto, se as coisas atrasarem para as equipes de arte, programa-
ção ou design, esses atrasos afetarão os testes. Geralmente, o tempo para os
testes é o primeiro a ser cortado quando um período de produção adicional
é necessário.
358 Parte VII • Testes
O produtor deve trabalhar junto ao analista líder de QA para reduzir o

máximo possível os problemas nos testes. O analista líder de QA é respon-
sável por testar o jogo, fechar bugs e determinar se um jogo está pronto para
ter o código liberado. Envolva o analista de QA na pré-produção para que
ele possa opinar sobre qualquer recurso que apresente desafios de teste. Por
exemplo, se houver planos de incluir 200 opções no sistema de criação de
personagens, o analista de QA pode informar quanto tempo levará a testagem
de cada opção e as diferentes combinações. Só o tempo de testes pode ser ra-
zão suficiente para que as opções dessa funcionalidade sejam drasticamente
limitadas. Coisas como essa ajudarão a criar uma ligação mais forte entre a
equipe de desenvolvimento e a equipe de testes, o que pode gerar cronogra-
mas de testes melhor gerenciáveis.
22.2 Cronograma de testes
Já que o tempo de testes costuma ser encurtado para acomodar outros atrasos
no cronograma, crie um cronograma de testes sólido durante a pré-produção.
Isso assegurará que todos na equipe conheçam claramente o cronograma de
testes e quais são as expectativas. Se a equipe entender como seus atrasos po-
dem afetar negativamente os testes, terá mais cuidado para cumprir seus pra-
zos. Consulte o Capítulo 16, “Planejamento do jogo”, para obter informações
detalhadas sobre a criação de um cronograma.
Construa o cronograma de testes diretamente no cronograma de produ-
ção e mostre as dependências dos testes para que atrasos que afetem o ciclo
de testes possam ser imediatamente vistos e mitigados. Adicione também um
tempo para testes a cada etapa principal do jogo para que o departamento de
testes possa passar alguns dias com a mesma build e avaliar o progresso do
jogo em relação aos produtos da etapa. Consulte o Capítulo 15, “Requisitos do
jogo”, para ver detalhes sobre os produtos das etapas.
Outros itens que devem ser incluídos no cronograma de testes são os
seguintes:
Playtest: Durante a produção, certifique-se de reservar tempo para o
departamento de QA executar o playtest do jogo e dar feedback aos de-
senvolvedores. O ideial é que você conduza esses playtests com pessoas
que não tenham passado meses jogando, assim o feedback será baseado
principalmente no fator diversão do jogo.
Demo: O departamento de marketing vai querer uma demo e ela terá de
ser testada. Se a demo já estiver no cronograma, a equipe estará prepara-
da para atender essa solicitação quando o marketing a fizer.
Builds para o marketing: Se o marketing estiver distribuindo builds du-
rante a produção, reserve tempo para o departamento de testes verificá-
-las antes que deixem a empresa. Mesmo com os jornalistas sabendo que
22 • Testes 359
verão bugs e trabalho inacabado nessas builds, os testes podem revelar

erros críticos que terão de ser adicionados às notas de build.
Códigos candidatos à liberação: Após a versão beta, o objetivo prin-
cipal da equipe de desenvolvimento é corrigir os erros o mais rápido
possível e criar um código candidato à liberação (CRC). Reserve algumas
semanas no fim do ciclo de testes para o departamento de QA verificar
totalmente cada CRC de acordo com o plano de testes. Se tudo der certo,
o primeiro CRC passará nos testes sem problemas, mas é quase certo que
vários CRCs tenham de ser enviados e testados.
Durante a pré-produção, a equipe de testes é usada principalmente como
um recurso para executar o playtest do protótipo e dar feedback sobre as fun-
cionalidades propostas. Nesse ponto do cronograma de testes, o analista de
QA pode participar do projeto em meio expediente, contanto que dê feedback
sobre todos os produtos que estão sendo gerados. Se houver protótipos ou
builds jogáveis para serem verificados, ele deve se planejar para ter alguns
testadores disponíveis por alguns dias a tempo de testar esses produtos du-
rante a pré-produção.
É na produção que grande parte dos testes ocorre. O analista de QA par-
ticipará do projeto em tempo integral após a produção começar – trabalhando
no plano de testes, testando recursos da jogabilidade e trabalhando com os
líderes no gerenciamento do pipeline de produção. Alguns testadores serão
necessários por algumas semanas aqui e ali antes da versão alfa – uma equi-
pe de testadores em tempo integral não será realmente necessária até o jogo
alcançar a versão alfa. No entanto, se o jogo for muito grande e complexo,
pode haver muita coisa a ser testada antes de chegar à versão alfa. Lembre-se
de que, quanto mais cedo algo puder ser testado, mais rápido os bugs serão
descobertos e corrigidos. Em alguns casos, um bug difícil de corrigir, encon-
trado posteriormente no ciclo de desenvolvimento, poderia ser um bug fácil
de corrigir se encontrado mais cedo.
Na versão alfa, o analista de QA reunirá um grupo de testadores em tem-
po integral para testar os recursos à medida que forem sendo implementados.
Nesse ponto, é provável que a equipe de testes não alcance capacidade plena,
já que o jogo ainda não foi concluído. Após o congelamento do código, cer-
ca de três a quatro meses antes de sua liberação, o esperado é que haja um
grupo completo de testadores examinando o jogo até ele ser concluído. Se o
jogo tiver muito conteúdo, o grupo completo de testadores pode começar a
examiná-lo antes do congelamento do código.
22.3 Plano de testes
O departamento de QA segue um plano de testes para verificar integralmente

todas as áreas do jogo. O analista de QA baseará um plano de testes inicial
na documentação de design e então trabalhará com a equipe para mantê-lo
atualizado durante o processo de produção. Como discutido anteriormente,

é importante o analista de QA participar da equipe o mais cedo possível para
poder começar a identificar possíveis problemas nos testes e redigir o plano
de testes. Dependendo do escopo do jogo, o plano de testes pode ter centenas
de páginas. Geralmente ele é apresentado em algum tipo de formato “apro-
vado/reprovado” ou de lista de verificação. Por exemplo, uma lista de verifi-
cação pode incluir uma relação dos personagens jogáveis e o testador terá de
jogar o jogo e verificar quais personagens jogáveis aparecem. Em um formato
“aprovado/reprovado”, o testador pode ter de verificar cada botão da tela da
IU e mencionar se ele foi aprovado (significando que está funcionando como
esperado) ou reprovado (não está funcionando de forma alguma ou não fun-
ciona como esperado).
É crucial que o plano de testes seja atualizado para refletir as últimas
alterações no jogo e na documentação de design. Um tempo valioso da pro-
dução pode ser perdido se o departamento de QA estiver usando uma versão
desatualizada do plano de testes para verificar uma build. Por exemplo, o ar-
tista líder pode ter aprovado o corte de alguns dos personagens jogáveis, mas
não informou o departamento de QA ou atualizou as listas de personagens.
Um testador de QA começará a comparar a lista de personagens com o plano
de testes e verá que vários personagens estão faltando. Isso será registrado no
banco de dados como um bug que agora terá de passar pelo processo de testes
para verificarmos se o jogo está correto, mas é o plano de testes que precisa
ser atualizado.
A Figura 22.1 é um exemplo de plano de testes do tipo “aprovado/repro-
vado”. Nesse exemplo, o plano de testes foi criado no Microsoft Excel para
organizarmos melhor as informações a serem verificadas. Quando os testa-
dores jogarem o nível 1, verificarão os itens detalhados no plano de testes e
marcarão se eles foram aprovados ou reprovados. Se um item for reprovado,
o testador incluirá algumas notas informando a razão. Se o testador não pu-
der verificar um item específico, ele o marcará como “CNT”, que significa
“Não pode ser testado” (Can Not Test), e adicionará notas informando a razão.
Observe que cada nível é listado em uma planilha separada com objetivos e
inimigos exclusivos sendo listados no plano de testes. A Figura 22.2 é um
exemplo de plano de testes do tipo lista de verificação. Nesse exemplo, há
três personagens jogáveis e eles podem usar qualquer uma das armas listadas
na planilha. Cada arma tem até três níveis, com uma arma de nível 1 sendo
menos poderosa do que uma de nível 2, e assim por diante. O testador sele-
ciona um dos personagens jogáveis e uma arma e então percorre os níveis das
armas ao jogar. Ele marcará cada combinação ao concluí-la. Se houver algum
problema, o testador inserirá uma nota explicando-o e o item permanecerá
desmarcado.
22 • Testes 361
NO SITE
Figura 22.1 Exemplo de plano de testes do tipo “aprovado/reprovado”.
Os testes serão abrangentes, mas o departamento de QA não testará cada

build que receber usando todo o plano. Em vez disso, eles se alternarão em
certas seções do plano a cada build. Se receberem instruções específicas para
testar uma parte do jogo, consultarão o plano para obter informações de como
atender melhor essa solicitação de teste. Builds referentes às etapas principais
também devem ser verificadas respeitando o plano de testes inteiro, já que
essa é uma boa maneira de avaliar o progresso do jogo.
À medida que o jogo for chegando próximo da data de entrega, será mais
importante aplicar o plano de testes integralmente. Quando houver uma ver-
são gold master candidata a representante do jogo, será crucial reservar um
tempo de testes suficiente para que o departamento de QA possa executar o
plano de testes inteiro, do início ao fim, no candidato gold master. Os testa-
dores podem descobrir alguns pequenos erros que tenham de ser corrigidos
antes do jogo ser entregue.
NO SITE
Figura 22.2 Exemplo de plano de testes do tipo lista de verificação.
22.4 Pipeline de testes
Antes dos testes começarem, os testadores e a equipe de desenvolvimento têm

de determinar o pipeline de rastreamento e relato de bugs. Se ele não for esta-
belecido, haverá confusão em como os testadores relatarão os bugs e que bugs
a equipe de desenvolvimento terá de corrigir primeiro. Além disso, todos têm
de saber como acessar e usar o banco de dados de rastreamento de bugs.
Banco de dados de rastreamento de bugs

Um banco de dados centralizado é crucial para o rastreamento eficiente de
bugs. Não confie em e-mails como uma forma segura de rastrear bugs. Em vez
disso, instale um banco de dados de rastreamento de bugs, como o Bugzilla ou
o TestTrack da Seapine. Esses dois programas oferecem uma funcionalidade
robusta de rastreamento para o registro e o fechamento de bugs.
Após o banco de dados ser instalado, o analista de QA poderá ministrar
uma aula para ensinar a equipe a usá-lo. A equipe deve aprender a usar o
banco de dados corretamente para poder inserir bugs, comentá-los, alterar
o status dos bugs e basicamente entender o que deve fazer para manipular
seus bugs no banco de dados. Durante a aula, o analista de QA também pode
discutir definições de bugs, para que todos entendam da mesma forma as
diferenças entre crash bugs, bugs críticos, bugs menores e solicitações de
funcionalidades.
22 • Testes 363
Definições de bugs
Quando bugs forem adicionados ao banco de dados, certifique-se de que as
definições corretas sejam usadas para que eles possam ser corrigidos na or-
dem mais eficiente. Por exemplo, crash bugs devem ser manipulados bem
antes de bugs menores ou solicitações de recursos. Se o bug não for definido
apropriadamente no banco de dados, os crash bugs podem ficar sem solução
durante algum tempo e acabar sendo mais difíceis de corrigir à medida que a
produção avançar. Além disso, se as solicitações de recursos forem definidas
incorretamente como bugs, o crescimento desenfreado será introduzido antes
que você o perceba. As definições de bugs mais comuns são as seguintes:
Crash bug: Um crash bug é extremamente grave, já que impede o joga-
dor de progredir no jogo. Os crash bugs podem congelar o jogo ou, em
casos piores, excluir o jogador e exibir uma mensagem de erro. A “tela
azul” às vezes vista no Microsoft Windows é um crash bug.
Bugs críticos: O bug crítico é um problema grave na funcionalidade do
jogo, mas que não impede o jogador de progredir. Um bug crítico poderia
ser um nível sem nenhuma de suas texturas ou um dos recursos princi-
pais da jogabilidade não funcionar como projetado.
Bug menor: Um bug menor é aquele que o jogador percebe, mas que não
prejudica muito a experiência geral do jogo. Texturas esticadas e erros no
texto podem ser considerados bugs menores.
Solicitação de recursos: Uma solicitação de recursos não é um bug, por-
tanto, certifique-se de que todas as pessoas que estiverem inserindo bugs
no banco de dados entendam claramente a diferença. A solicitação de re-
cursos é uma funcionalidade adicional que seria interessante incluir mas
que não faz parte do conjunto de funcionalidades definido. Por exem-
plo, alguém pode solicitar a opção de ativação e desativação do Heads-
-up-display (HUD) in-game, mas se esse recurso não fizer originalmente
parte do escopo do design, será considerado uma solicitação de recurso
e não um bug. Se o usuário tivesse obrigatoriamente de poder ativar e
desativar o HUD e esse recurso não estivesse funcionando no jogo, então
isso seria um bug.
Quando registramos um bug, geralmente há uma seção para a inclusão
de informações sobre o tipo de bug que é. Consulte a seção “Registrando
bugs” mais à frente neste capítulo, para obter informações detalhadas sobre o
registro de bugs.
22.5 Ciclo de testes
O ciclo de testes de uma build começa quando a equipe de desenvolvimento

a envia oficialmente para testes. Como discutido no Capítulo 19, “Criando
builds”, mesmo havendo builds disponíveis diariamente na época da versão
alfa, não é útil o departamento de QA testar todas as builds, já que eles nunca
percorreriam o jogo inteiro antes de uma nova build estar pronta. Em vez dis-
so, se a build for estável, o departamento de QA pode passar alguns dias ou
uma semana com a mesma build e testar o máximo que puder.
À medida que o desenvolvimento avançar e o jogo ficar mais robusto,
o analista de QA testará diferentes seções de builds distintas. Por exemplo,
quando um criador de níveis inserir um novo nível, os testadores farão uma
verificação na geometria e nas texturas e enviarão qualquer bug encontrado
para o banco de dados. Esse nível não será testado novamente até o artista
corrigir todos os bugs e reenviá-lo para testes, o que pode levar várias sema-
nas. Nesse meio tempo, os testadores se dedicarão aos testes de outros níveis
e recursos de builds subsequentes enquanto esperam os bugs serem corrigi-
dos. Trabalhe com o analista de QA para agendar certas seções do jogo para
testes. Se estiver indicado no cronograma quando certas partes do jogo devem
estar prontas para o teste, a equipe de desenvolvimento poderá planejar me-
lhor seu trabalho para acomodar o cronograma de testes.
Após a build entrar em teste, o ciclo é bem simples. Os testadores per-
correrão o plano de testes, encontrarão bugs e os inserirão no banco de da-
dos. Quando os bugs estiverem no banco de dados, serão designados à pessoa
apropriada para correção. Essa pessoa corrigirá o bug e reenviará seu trabalho
para verificação em uma build futura. O testador verificará então a correção
na build e indicará se ela está pronta para ser tirada do banco de dados.
Registrando bugs
Uma vez que a produção e os testes estiverem em plena atividade, o banco de
dados central de rastreamento de bugs será o recurso mais importante para
o acompanhamento do progresso do jogo. Os membros da equipe de desen-
volvimento devem ser solicitados a inserir no banco de dados todos os bugs
que encontrarem, junto com qualquer solicitação de recursos, ou os feedbacks
que demandarem uma alteração no jogo. Embora as solicitações de recursos
ou os feedbacks não sejam bugs, é bom incluí-los no banco de dados para que
possam ser rastreados, resolvidos e verificados. Se uma solicitação de recur-
sos não for aprovada para inclusão, poderá ser marcada como solicitação de
recursos e destinada para futuros patches ou sequências do jogo. Durante um
congelamento de código, geralmente os programadores não fazem nenhuma
alteração no código, a menos que ela tenha sido especificamente registrada no
banco de dados de bugs e atribuída a alguém para fazê-la.
Já que a equipe terá tantas pessoas registrando e inserindo bugs no banco
de dados, é imperativo estabelecer um processo padronizado para o registro
de bugs e ensiná-lo a todos. Os bugs precisam conter as informações perti-
22 • Testes 365
nentes para que a equipe de desenvolvimento possa saber facilmente que bug
é esse, encontrá-lo no jogo e corrigi-lo. A maioria dos bancos de dados de
rastreamento de bugs tem um conjunto padrão de campos de informações a
serem preenchidos no registro de um bug. Esses campos são:
Versão: É a versão da build em que o bug foi encontrado. A versão é
útil para o acompanhamento do progresso do bug desde o momento em
que foi encontrado até ser corrigido e verificado. Se o bug surgir de novo
posteriormente no ciclo, o histórico de versões será uma informação útil
para o rastreamento da causa do bug.
Categoria: Indica se um bug é de arte, design ou programação. Geral-
mente isso é muito fácil de descobrir, mas para o caso de dúvida o tes-
tador terá uma noção melhor da categoria. Quando o líder apropriado
examinar o bug, talvez o troque de categoria.
Componente: Uma subcategoria de “categoria”. Oferece mais detalhes
sobre os comportamentos que o bug está exibindo. Por exemplo, as sub-
categorias de “programação” poderiam ser rede, IA, IU, física, carga/gra-
vação e assim por diante.
Resumo: Um breve resumo sobre o bug em uma frase. A equipe pode
estabelecer diretrizes específicas sobre como redigir o resumo para que
os bugs possam ser facilmente classificados. Por exemplo, todos os bugs
encontrados na arte da missão um têm de começar com “M01-Arte”.
Descrição do bug: A pessoa que estiver registrando o bug tem de des-
crever o que ocorreu. Em alguns casos, pode incluir informações sobre o
que esperava que ocorresse e o que ocorreu realmente. Isso permitirá que
a equipe identifique facilmente qualquer bug que não estiver se compor-
tando como esperado, ou, em alguns casos, recursos que estiverem funcio-
nando como esperado, mas por alguma razão são percebidos como bugs.
Gravidade: Indica se um bug é fatal, crítico, menor ou uma solicitação
de recursos. Bugs de Gravidade Um são corrigidos primeiro, já que ge-
ralmente são crash bugs que impedem o jogador de jogar ou progredir no
jogo. Bugs críticos são classificados como de Gravidade Dois e costumam
ser bugs que bloqueiam a jogabilidade. Normalmente, os bugs menores
são considerados como de Gravidade Três, enquanto uma solicitação de
recursos tem Gravidade Quatro.
Prioridade: Essa categoria é outra maneira de classificar bugs e indica quais
têm prioridade mais alta. Por exemplo, você poderia ter três crash bugs de-
signados como de Gravidade Um. No entanto, um dos crash bugs ocorre
no início do jogo, enquanto os outros dois ocorrem no final. O produtor ou
líder pode designar o crash bug que ocorre no começo do jogo como tendo
Prioridade Um e os outros como tendo Prioridade Dois. Isso ajuda a equipe
a tomar decisões sobre os bugs que devem ser corrigidos primeiro.
Passos a reproduzir: Fornece uma descrição passo a passo de como re-
produzir o bug (se ele for reproduzível). Se o bug não for reproduzível, o
testador deve anotar em ordem cronológica o que estava fazendo quando

o bug ocorreu. As pessoas devem se habituar a reproduzir o bug sempre
que possível.
Capturas de tela: A inclusão de uma captura do que estava ocorrendo
na tela no momento que o bug ocorreu é muito útil para a identificação
do local e da causa do bug.
Arquivos de log de interrupção: O programador pode criar um exe-
cutável de depuração que gere um arquivo de log sempre que o jogo
travar. O arquivo de log registrará em que linha de código a interrupção
ocorreu para que o programador tenha um bom ponto de partida para
rastrear o bug.
Atribuindo e fechando bugs

A atribuição de bugs é uma parte importante do ciclo de testes, porque o bug
tem de ser enviado para a pessoa certa para ser corrigido e verificado. O pro-
cesso de atribuição de bugs deve ser claramente definido e apresentado para a
equipe durante a aula de testes ministrada pelo analista de QA. O objetivo da
atribuição de bugs é que eles sejam corrigidos o mais rápido possível.
Um processo simples para a atribuição de bugs envolve o testador, o
analista de QA e o líder:
1. O testador encontra um bug no jogo que é registrado e enviado para o ban-
co de dados.
2. O bug é atribuído automaticamente ao analista de QA, que o examina
para ver se é realmente um bug ou uma ocorrência repetida. Ele também
verificará as informações do bug para saber se o problema foi registrado
claramente.
3. O analista de QA atribui o bug ao líder apropriado. O líder da equipe de
arte receberá todos os bugs de arte e assim por diante.
4. O líder examina o bug, verifica se foi atribuído à área apropriada e o atri-
bui à pessoa certa da equipe. Em alguns casos, um bug parece ser de um
tipo (por exemplo, de arte) e na verdade é de outro (pode ser de programa-
ção), e é por isso que é útil o líder examinar os bugs. Se o bug for fatal, o
líder pode solicitar que a pessoa o manipule imediatamente para que na
próxima build ele já esteja corrigido.
5. Após uma pessoa ser designada para corrigir o bug, ela implementará uma
correção e a devolverá para o analista de QA para verificação. Se o bug
não puder ser corrigido por alguma razão, ela deve adicionar um comen-
tário, explicando a razão, e devolver o bug para seu líder para verificação.
6. Após o analista receber um bug para verificação, ele atribuirá um testador
para examiná-lo na próxima build e ver se foi corrigido. Se o bug não tiver
sido corrigido, o testador adicionará um comentário e o processo começa-
rá novamente. Se o bug tiver sido corrigido, será fechado pelo analista.
Você não conseguirá corrigir todos os bugs do jogo, principalmente
quando estiver perto de liberar o código. A maioria dos desenvolvedores tem
22 • Testes 367
uma lista de bugs “não corrigidos” que permanecem no jogo quando este é
entregue. Alguns desses bugs podem ser corrigidos posteriormente com uma
atualização ou patch, mas a maioria não será. Bugs categorizados como “não
corrigidos” são bugs menores que não afetam perceptivelmente a experiência
do jogador. Alguns bugs podem ser cosméticos – pode haver uma textura es-
ticada ou uma brecha visível em um modelo 3D. Outros podem ser referentes
à jogabilidade, mas ter prioridade de baixo risco, e talvez não valha a pena
pôr em perigo a data de entrega para corrigi-los. Cada desenvolvedor terá um
padrão diferente para designar um bug como “não corrigido” tendo de obter
aprovação da gerência sênior para o que será incluído nessa lista.
Verificando requisitos técnicos

Como discutido no Capítulo 5, “Relacionamento entre o desenvolvedor e o
publicador”, cada fabricante de console tem um conjunto predefinido de re-
quisitos técnicos ao qual um determinado jogo tem de aderir. O fabricante do
console fornecerá uma lista de verificação completa com cada requisito que
o jogo deve atender e, em alguns casos, ferramentas que ajudarão a verificar a
conformidade do título aos requisitos apropriados. A não conformidade com
esses requisitos fará com que o jogo corra o risco de não ser aprovado pelo
fabricante do console. Se isso ocorrer, e o erro não for corrigido, seu jogo não
será aprovado para lançamento. Portanto, os testes de conformidade aos re-
quisitos são extremamente importantes. Consulte o Capítulo 23, “Liberação
do código”, para obter mais informações sobre o processo de aprovação pelo
fabricante do console.
Designe uma só pessoa da equipe de QA para ser a responsável por se es-
pecializar nos requisitos técnicos e em como testá-los no jogo. Se esse proces-
so for centralizado em uma pessoa, haverá menos probabilidade de ocorrerem
erros quando o jogo for verificado em relação aos requisitos. É muito frustran-
te quando um jogo não passa na aprovação porque uma terminologia incor-
reta foi usada ou uma mensagem de erro obrigatória não está presente. Esse
testador deve conhecer bem e saber interpretar os requisitos técnicos e será
o ponto de contato principal com o fabricante do console se houver alguma
dúvida sobre os requisitos. Para concluir, deve saber como usar as ferramen-
tas de desenvolvimento proprietárias fornecidas pelo fabricante do console e
usadas na automatização da verificação de vários requisitos. Sempre que um
bug de não conformidade for inserido no banco de dados, ele deve ser classi-
ficado como de alta prioridade e corrigido o mais rápido possível. Mesmo se
não for um crash bug, um bug de não conformidade é tão grave quanto aquele,
já que é possível que o jogo não passe na aprovação se o bug for encontrado
durante o processo.
22.6 Testes externos
Em algum ponto do projeto pode surgir a necessidade de terceirização dos

testes para um fornecedor externo. Geralmente isso ocorre quando o desen-
volvedor tem uma equipe de testes muito pequena e deseja mais pessoas tes-
tando integralmente todas as áreas do jogo. Os testes externos também ocor-
rem quando as versões localizadas do jogo precisam ser testadas por falantes
nativos de cada idioma. Para concluir, pode valer mais a pena investir em tes-
tes externos se houver uma área específica a ser testada que demande recur-
sos especializados. Por exemplo, a verificação da compatibilidade em vários
computadores, placas de vídeo e placas de som pode ser manipulada melhor
por um fornecedor externo que tenha um laboratório de verificação de com-
patibilidade já instalado para testes. Pode valer a pena contratar um fornece-
dor de testes com muita experiência na verificação de requisitos técnicos para
que seu jogo tenha chance de passar no processo de aprovação do fabricante
do console mais rapidamente.
Se estiver planejando usar fornecedores de testes externos, certifique-se
de fazer uma pesquisa sobre os fornecedores e obter opiniões de outros clien-
tes satisfeitos (ou insatisfeitos) quando possível. Você pode fazer as seguintes
perguntas ao fornecedor:
• Qual é a melhor maneira de mandar uma build do jogo? Eles criarão um

servidor de FTP para você usar ou será preciso enviar discos?
• Como o pagamento pelos testes é determinado? Eles cobram por hora ou
por dia?
• Com que antecedência eles terão de ser notificados se você quiser can-
celar os testes? São necessárias 24 horas de antecedência?
• Eles redigirão um plano de testes? Eles criarão sua própria versão do
plano de testes ou você terá de fornecer um? Se eles criarem o plano de
testes, pergunte quanto custa. Lembre-se também de que eles precisarão
da documentação de design e de builds jogáveis antecipadamente para o
plano de testes estar pronto quando começarem realmente a testar o jogo.
• Que custos adicionais são incluídos no pagamento dos testes? Eles co-
bram uma taxa de gerenciamento do projeto ou incluem um percentual
adicional do custo de testes total referente a custos indiretos? Você não
quer ter surpresas ao receber a conta.
• Eles podem fornecer uma estimativa de quanto tempo demorarão os
testes do jogo? Eles fazem uma avaliação gratuita da mecânica do jogo
para determinar o tempo de testes necessário à conclusão do trabalho?
• Quem será o principal ponto de contato? Eles fornecerão um gerente
de projeto que você possa contatar diariamente e que enviará relatórios
diários do progresso?
• Que software de rastreamento de bugs eles usam? Você terá de usar o
software deles ou poderá usar outros tipos de software de rastreamento
de bugs?
22 • Testes 369
Quando um fornecedor for selecionado, você também terá de fazer sua

parte para tirar o máximo de proveito dos testes. Por exemplo:
• Verifique as builds antes de enviá-las para o fornecedor para verificar
se elas estão sendo instaladas e carregadas corretamente. Se o fornece-
dor tiver de perder algumas horas consertando uma build defeituosa, os
custos podem subir rapidamente.
• Forneça uma orientação clara sobre o que precisa ser testado. Eles vão
se dedicar apenas aos requisitos técnicos do console ou também terão
de testar outras áreas do jogo? Devem verificar apenas a funcionalidade
para 16 jogadores ou também devem examinar a campanha de jogador
único? Devem se dedicar somente a regredir correções de bugs da build
anterior? Se for esse o caso, certifique-se de que o banco de dados indi-
que claramente quais bugs estão prontos para regressão.
• Estabeleça um cronograma para o envio de novas builds. Eles devem
testar uma build do início ao fim e então esperar até você estar pronto
para outra rodada de testes? Devem testar continuamente durante os pró-
ximos dois meses – se for esse o caso, com que frequência precisarão de
uma nova build (todo dia, toda semana)?
• Esclareça dúvidas o mais rápido possível. Se o fornecedor tiver uma per-
gunta, forneça para ele as informações necessárias assim que possível, já
que os testes podem ter de esperar até a pergunta ser respondida. Quanto
maior a espera, mais tempo de testes será perdido e mais dinheiro gasto.
Os testes são um aspecto demorado e estressante do desenvolvimento de jogos

digitais. Quando o jogo estiver prestes a ir para as lojas, talvez o testador en-
contre um crash bug que não foi descoberto anteriormente no desenvolvimen-
to. Quando isso ocorre, os ânimos se exaltam enquanto os desenvolvedores
lutam para preparar outro código candidato à liberação (CRC) o mais rápido
possível. Esse cenário pode surgir em algumas equipes de desenvolvimento
de jogos, mas se o produtor, os líderes e a equipe se lembrarem constantemen-
te das necessidades de QA durante a produção, há como ser evitado. Neste ca-
pítulo discutimos informações gerais sobre como trabalhar de maneira eficaz
com o departamento de QA da pré-produção à liberação do código. Os tópicos
abordaram o cronograma de testes, o ciclo de testes e o fechamento de bugs.
23
LIBERAÇÃO DO CÓDIGO
Neste capítulo
• Determinando a • Lista de verificação • Gold Masters
liberação do código para liberação do
código
23.1 Introdução
Quando o código de um jogo é liberado, isso significa que o conteúdo é defi-

nitivo, os bugs foram corrigidos e o disco master está pronto para ser replica-
do e embalado. Um processo de liberação do código deve ser definido para
verificarmos se tudo que tinha de ser feito no jogo foi concluído corretamente.
Esse processo envolverá reuniões diárias onde serão discutidos bugs, a lista
de verificação para liberação do código, procedimentos de envio para aprova-
ção de terceiros e informações sobre para onde o código deve ser enviado para
replicação. O código não é liberado da noite para o dia; o processo pode levar
de cinco dias a dois meses, dependendo da complexidade do jogo e de quem
tiver de aprová-lo antes da liberação.
23.2 Determinando a liberação do código
Defina um processo de liberação do código para que a equipe de desenvolvimen-

to e o departamento de QA entrem em acordo sobre o estado que determina que
um jogo está pronto para ter o código liberado ou para aprovação final se precisar
ser enviado para terceiros para aprovação. Trate-o como uma fase separada do
processo de testes e certifique-se de verificar o código candidato à liberação em
relação ao plano de testes inteiro e, se necessário, em relação às listas de verifi-

cação de requisitos técnicos da Sony, Microsoft ou Nintendo. Além disso, esse
é um momento ideal para confirmar se os direitos autorais e outras informações
legais estão corretos, se todas as classificações etárias adequadas foram obtidas
e se as versões localizadas do jogo foram aprovadas pelas pessoas apropriadas.
O principal objetivo do processo de liberação do código é verificarmos
se o disco master do jogo que está sendo enviado para replicação e fabricação
contém todo o código e os assets corretos. O processo tem de conseguir reve-
lar qualquer problema importante que precise ser resolvido antes do jogo ser
entregue. Deve incluir tempo suficiente para que todo o plano de testes e a lis-
ta de requisitos técnicos sejam percorridos pelo menos três vezes e adicionar
o tempo extra necessário para as aprovações da Sony, Microsoft e Nintendo
(geralmente de quatro a oito semanas). Uma folga adicional no cronograma de
liberação do código é necessária para a solução de qualquer problema encon-
trado nas versões gold master candidatas e a preparação de uma nova versão
gold master que possa então ser verificada.
Um código candidato à liberação (CRC) é uma versão do jogo em que to-
dos os bugs foram corrigidos, que está com todos os assets definidos e foi con-
siderada pronta para ser entregue pela equipe de desenvolvimento. Um jogo
tem vários CRCs durante o processo de liberação do código para que qual-
quer problema sério que venha a ser descoberto possa ser resolvido. Quando
a equipe de QA recebe um CRC, ela verifica o jogo conforme o plano de testes
e outros requisitos de liberação do código. Dependendo do tamanho do plano
de testes, isso pode levar de cinco a sete dias. Se quiser, aumente a equipe do
departamento de QA para percorrer o processo mais rapidamente, já que eco-
nomizar um dia ou dois no fim da fase de testes pode fazer a diferença entre
cumprir ou perder uma data de entrega.
Lembre-se de que qualquer jogo usado em hardware proprietário, como
um console ou celular, deve ser enviado para terceiros para aprovação. Cada
fabricante de hardware tem um conjunto de requisitos diferente que precisa ser
atendido para o jogo ser aprovado para replicação. Mais informações sobre o pro-
cesso de aprovação por terceiros serão discutidas posteriormente neste capítulo.
23.3 Lista de verificação para liberação do código

Crie uma lista de verificação para liberação do código para assegurar que os
requisitos de liberação sejam claramente definidos e entendidos por todos. A
Figura 23.1 é um exemplo de lista de verificação para liberação do código. Ela
fornece uma visão geral dos tipos de itens que incluem, adicionam ou modi-
ficam qualquer coisa relacionada ao seu jogo.
Além disso, se quiser, inclua na lista de verificação informações adicionais
sobre os itens a seguir, já que todos eles também devem ser confirmados no CRC:
Informações de direitos autorais: Geralmente listadas no jogo e na em-
balagem. Incluem a confirmação da colocação de todos os logotipos de
23 • Liberação do Código 373
Informações gerais A/R Notas adicionais

Todos os bugs foram corrigidos?
NO SITE Todos os bugs “não corrigidos” foram aprovados?
O jogo pode ser jogado do início ao fim?
O código de trapaça foi removido?
O software de depuração foi removido?
O jogo foi aprovado em todas as áreas do plano de testes?
As verificações de compatibilidade com PCs foram concluídas?
As informações corretas de suporte ao cliente estão sendo listadas?
Essa versão foi aprovada para envio para terceiros?
As classificações etárias e isenções de responsabilidade corretas estão sendo exibidas?
Aprovações de terceiros
Essa versão passou nas verificações de requisitos técnicos da Microsoft?
Essa versão passou nas verificações de requisitos técnicos da Sony?
Essa versão passou nas verificações de requisitos técnicos da Nintendo?
Localizações
O texto do jogo está sendo exibido no idioma correto?
Os voiceovers estão sendo reproduzidos no idioma correto?
Os manuais inclusos foram traduzidos corretamente?
O jogo recebeu aprovação linguística?
O texto legal e as informações de direitos autorais corretos estão sendo exibidos?
O jogo tem todas as classificações etárias necessárias?
Parte jurídica
Os licenciadores apropriados aprovaram o jogo?
Autorizações foram obtidas para todo o conteúdo licenciado (como a música)?
O jogo contém a versão correta do EULA?
As informações de garantia e suporte ao cliente estão corretas?
Embalagem
A embalagem contém informações legais e de direitos autorais?
Os logotipos e outros ícones da embalagem estão corretos?
O manual foi finalizado e aprovado?
Verificações das versões gold master
Foram procurados vírus nas versões gold master e elas foram consideradas livres de vírus?
A versão gold master é idêntica à versão gold candidata à liberação e aprovada?
A versão gold master foi instalada e verificada em hardware apropriado?
Figura 23.1 Lista de verificação para liberação do código.
terceiros, como fornecedores de middleware, desenvolvedores e outros

fabricantes.
Contratos de licença do usuário final: Geralmente incluídos no manual.
Jogos de PC também podem ter uma versão exibida durante o processo
de instalação.
Aprovação do licenciador: Se o jogo for baseado em uma licença es-
pecífica (como o de Harry Potter), certifique-se de obter as aprovações
apropriadas de todos os licenciadores.
Informações de suporte ao cliente: Incluem números de telefone e si-
tes. Versões internacionais terão informações de suporte ao cliente dife-
rentes.
Assets traduzidos: Confirme se os assets traduzidos estão sendo exibi-
dos corretamente no jogo.
Demos: Se incluir demos de outros jogos, certifique-se de que elas te-

nham as classificações etárias apropriadas dos territórios em que o jogo
for lançado.
Classificação do software: Verifique se o jogo tem a classificação apro-
priada de cada território em que for lançado e se tanto ele quanto a em-
balagem incluem os ícones e logotipos necessários.
Requisitos de envio para o fabricante do console: Examine o jogo se-
guindo a lista de verificação de requisitos técnicos da Sony, Microsoft e
Nintendo.
23.4 Gold Masters
A replicação e a embalagem de versões gold master de jogos de PC serão feitas

diretamente pelo publicador. O publicador selecionará um fornecedor de re-
plicação e enviará para ele o código final após este ter sido aprovado. Muitos
fornecedores têm um processo de envio eletrônico para o recebimento do có-
digo, enquanto outros demandam o envio de discos com a versão gold master.
Seja qual for o caso, informe-se sobre quem deve receber o código final e qual
o formato solicitado.
As versões gold master de console devem passar por uma etapa a mais
antes de serem enviadas para a firma de replicação. A Sony, a Microsoft e a
Nintendo precisam aprovar o jogo antes de ele ser liberado para um de seus
sistemas. Um gerente de conta é designado para trabalhar com o desenvolve-
dor e o publicador e é responsável por guiar o jogo pelo processo de aprova-
ção. Cada empresa tem um processo diferente, portanto, o gerente de conta é
um recurso inestimável para conhecermos os requisitos técnicos, as fases de
aprovação e os requisitos de embalagem. O gerente de conta trabalhará junto
à equipe para determinar quando o jogo deve ser enviado para cumprir a data
de entrega. Mantenha-se em contato próximo com seu gerente de conta duran-
te todo o processo de aprovação para passar por ele sem maiores problemas.
Reserve um tempo no cronograma para o processo de aprovação. Além
de o envio final ter de ser programado (em média, leva cerca de 10 a 20 dias),
outros envios também serão necessários durante o decorrer do desenvolvi-
mento. A maioria dos fabricantes de console requer que uma versão beta do
jogo seja enviada várias semanas ou meses antes do envio final. Essa versão
lhes dá a oportunidade de verificar o progresso do jogo e fornecer algum feed-
back sobre coisas que podem pesar na aprovação final. Considere isso como
uma investigação antecipada e uma chance de otimizar qualquer área do jogo
que possa afetar a aprovação final.
Quando o jogo entrar na fase de envio final, o fabricante do console pode
levar de 10 a 15 dias para tomar uma decisão. O ideal é que tudo corra bem e o
jogo passe na primeira tentativa. Embora alguns jogos passem na primeira ten-
tativa, isso não ocorre com frequência, portanto, é melhor presumir que o jogo
terá de ser enviado pelo menos duas vezes antes de receber a aprovação final.
23 • Liberação do Código 375
Se o jogo for reprovado no envio inicial, o fabricante do console gera-

rá um relatório detalhando a causa. Todas as reprovações são relacionadas a
itens da lista de verificação de requisitos técnicos, portanto, o relatório fará
referência ao requisito específico que não foi atendido. Dependendo da gravi-
dade dos problemas, a equipe de desenvolvimento pode ter de esperar alguns
dias ou semanas enquanto implementa as correções de bugs e os feedbacks
para então poder enviar o jogo para uma nova tentativa. Esperamos que os
problemas tenham sido resolvidos e o jogo seja aprovado.
A embalagem do console também tem de ser enviada para aprovação.
Na maioria dos casos, a embalagem tem um processo de envio que é separado
da versão gold master e costuma ser manipulado por alguém da equipe de
marketing ou dos serviços de criação. No entanto, adicione essa tarefa ao cro-
nograma de produção, porque se a embalagem não for enviada a tempo, a data
de entrega do jogo pode ser posta em risco, mesmo se o código já tiver sido
aprovado. A aprovação da embalagem leva cerca de 10 a 14 dias, e ela pode
ser enviada sempre que for finalizada pelo publicador.
Quando as versões gold master de PC e console forem aprovadas e esti-
verem prontas para fabricação, serão enviadas para o fornecedor de replica-
ção. Geralmente o fornecedor precisa de cerca de 10 dias para copiar os discos
e embalá-los. Isso presumindo que ele tenha recebido todas as partes impres-
sas a tempo e não encontre nenhum problema ao copiar os discos. Antes que
cópias em massa dos discos sejam criadas, o fornecedor fará algumas versões
master de teste (às vezes chamadas de “glass masters”) e pedirá a alguém do
publicador que verifique se os discos estão funcionando corretamente.
À medida que o projeto for chegando ao fim, mantenha as pessoas infor-
madas sobre qualquer alteração no cronograma de liberação do código, já que
isso também afetará a data de entrega. A Figura 23.2 fornece uma visão geral do
cronograma de produção e lançamento de um jogo de console. O cronograma co-
meça com o envio da versão beta do jogo ao fabricante do console para obtenção
de feedback em 2 de junho de 2008. A equipe tem aproximadamente mais seis
Figura 23.2 Cronograma de produção e lançamento de um jogo de console.

semanas para polir o código, implementar o feedback e preparar um CRC. O pro-

cesso do CRC começa em 28 de julho de 2008 e ele estará pronto para envio para
o fabricante do console 10 dias depois. Após terem sido programadas duas roda-
das de envio, ciclo do fabricante e datas de entrega, estima-se que o jogo chegue
às prateleiras das lojas em 7 de outubro de 2008. Observe que levou cerca de
dois meses após a liberação interna do código para que esse jogo de console fosse
entregue. É claro que cada projeto é diferente, mas você deve tomar cuidado com
todas essas fases para poder planejar com mais exatidão a data de entrega.
O processo de liberação do código é uma das etapas mais cruciais do desen-

volvimento de um jogo. É o ponto em que o desenvolvedor e o publicador
concordam que o jogo foi totalmente testado e está pronto para ser enviado
para o fabricante para replicação e expedido para as prateleiras das lojas. Se
o código de um jogo for liberado cedo demais, haverá o risco de um crash bug
ser descoberto após o jogo ser entregue, o que terá um impacto negativo sobre
as vendas. Este capítulo discutiu um processo de criação de builds para a
liberação do código que permite verificar se todos os detalhes foram conside-
rados e se o jogo está realmente pronto para ser liberado.
Parte VIII
PÓS-PRODUÇÃO
O processo de desenvolvimento de jogos não termina quando o jogo tem o

código liberado e é enviado para as prateleiras das lojas, embora esse seja o
momento que muitas equipes de desenvolvimento consideram como de conclusão
do projeto. Medidas importantes ainda devem ser tomadas para que a produção do
jogo seja encerrada oficialmente. Um kit de fechamento deve ser criado, para arqui-
vamento do código e dos assets do jogo para uso futuro, e um post-mortem tem de
ser conduzido com a equipe.
Esta seção discutirá as tarefas que devem ser concluídas antes do término ofi-
cial do ciclo de desenvolvimento do jogo. Os tópicos são os seguintes:
• Execução de um post-mortem
• Criação de kits de fechamento
24
POST-MORTEMS
Neste capítulo
• Finalidade de um • Conduzindo um • Documento de
post-mortem post-mortem lições aprendidas
24.1 Introdução
Geralmente, os post-mortems são conduzidos no final do ciclo de desenvol-

vimento do jogo porque fornecem o fechamento do ciclo como um todo. Eles
são uma oportunidade de você e sua equipe discutirem os pontos fortes e
fracos do projeto e como esse conhecimento pode ser aplicado à melhoria de
projetos futuros. Também são uma oportunidade de celebrarem a conclusão
do jogo. O post-mortem deve envolver o feedback da equipe inteira para ser
útil. Terminadas as reuniões de post-mortem, as informações provenientes
dessas discussões são resumidas em um documento de Lições Aprendidas
que deve descrever um plano para a implementação de alterações no proces-
so do próximo ciclo de criação de jogos. Este capítulo fornecerá informações
sobre por que um post-mortem é importante e como conduzi-lo com sucesso,
descrever um plano de ação e implementar alterações.
24.2 Finalidade de um post-mortem
O principal objetivo de um post-mortem é sabermos que métodos funciona-

ram ou não durante o desenvolvimento do jogo. Geralmente, esses itens estão
mais ligados ao processo de produção – cronograma, planejamento, imple-
mentação de recursos e assim por diante – do que aos recursos de design
380 Parte VIII • Pós-produção
do jogo. Embora sejam os sucessos e falhas do jogo os assuntos discutidos

nos post-mortems, eles costumam estar ligados a algo que foi feito correta ou
incorretamente no processo de produção. Por exemplo, se o jogo não estiver
com a jogabilidade balanceada corretamente, isso pode ter ocorrido porque
não alocamos tempo para isso, ou se os modelos de personagens estiverem
recebendo críticas muito boas, talvez seja porque o processo de produção in-
cluiu algumas etapas de validação que permitiram que os criadores de per-
sonagens tirassem o máximo de proveito das ferramentas e da tecnologia ao
criar assets. Um post-mortem também é diferente das revisões de projeto e da
análise de estágio crítico discutidas no Capítulo 18, “Técnicas de produção”,
porque enfocam como o processo de desenvolvimento do jogo foi executado
e não o conteúdo do jogo.
Os post-mortems tendem a ser subestimados no processo de desenvol-
vimento por várias razões, como não haver tempo suficiente, não ser de alta
prioridade ou as pessoas não estarem interessadas em melhorar o processo
(afinal, o jogo foi concluído, não foi?). No entanto, eles são uma maneira vi-
tal de aprendermos com os erros e validarmos novas ideias para a melhoria
do processo. Se não o fizerem, os desenvolvedores estarão negligenciando a
melhor fonte de informações concretas que eles têm de como tornar as coisas
mais eficientes, mais baratas e melhores em projetos futuros.
Para extrair esse conhecimento da equipe, os post-mortems devem tentar
responder as perguntas a seguir:
Atingimos os objetivos do jogo? Para documentar as respostas a essa
pergunta, você terá de preparar uma visão geral do projeto contendo
quais eram os objetivos originais e os objetivos que o jogo realmente atin-
giu. Por exemplo, digamos que os objetivos originais incluíssem quatro
classes de personagens para o jogador escolher e o jogo acabou tendo
apenas três. A finalidade dessa pergunta não é identificar onde a equipe
se desviou do objetivo e sim avaliar por que o objetivo não foi atingido,
como por uma mudança no escopo, uma alteração nas prioridades ou
um tempo limitado. Soluções para esses obstáculos podem ser examina-
das e implementadas para que isso não ocorra no próximo jogo.
O cronograma, os recursos, o conjunto de funcionalidades e as expecta-
tivas de qualidade eram realistas para os objetivos definidos? Ao discutir
essa pergunta, é recomendável que você exponha exemplos concretos de
onde essas áreas foram planejadas adequadamente e onde não foram. Essa
não é uma oportunidade para a equipe atacar pessoalmente outras pessoas
devido a suas falhas. Em vez disso, a discussão deve se concentrar nos fa-
tos que ocorreram para atrapalhar os objetivos do projeto. Por exemplo, as
pessoas podem dizer algo como o cronograma não levou em consideração
a correção de bugs nos níveis, portanto, três níveis foram cortados do jogo
para os outros serem terminados, ou o processo de aprovação demorou
demais e afetou o tempo disponível para a implementação de um recurso.
O que deu certo? O que deu errado? Essa é uma oportunidade para
a equipe trocar experiências pessoais quanto ao que funcionou ou não
24 • Post-mortems 381
no projeto. Ao discutir tanto os aspectos positivos quanto os negativos,

a equipe pode levar conhecimento para outros projetos sobre os proce-
dimentos que podem ser implementados e os que devem ser evitados.
Além disso, se um procedimento não funcionou, podem ser discutidas
soluções de como fazer algo diferente funcionar no próximo projeto com
os mesmos resultados desejados.
Que lições aprendemos? A equipe examina todas as informações coletadas
nas perguntas anteriores e determina as principais lições aprendidas du-
rante o desenvolvimento. Essas lições devem se concentrar mais nos itens
gerais e menos nos pequenos detalhes. Os detalhes podem ser usados como
métodos para a implementação da lição aprendida no próximo projeto. Por
exemplo, “divulgar os prazos claramente para a equipe” poderia ser uma
lição aprendida, enquanto os métodos para a divulgação desses prazos (e-
-mail, relatórios de status, reuniões semanais) forneceriam os detalhes de
como pôr isso em prática. Os post-mortems regulares apresentados na re-
vista Game Developer oferecem bons exemplos de lições aprendidas.
Se estiver trabalhando em um projeto que leve mais de um ano para ser
desenvolvido, tente agendar um pequeno post-mortem para cada fase impor-
tante do projeto: pré-produção, versão alfa, versão beta e liberação do código.
Dessa forma, poderá melhorar continuamente o processo de produção em vez
de ter de esperar o próximo projeto para fazer melhorias. Se estiver trabalhan-
do em um projeto que leve um ano ou menos, programe um único post-mor-
tem no final. Além disso, encoraje as pessoas a tomar notas durante o processo
de desenvolvimento sobre coisas a serem discutidas no post-mortem. Essa ati-
tude assegurará que os detalhes não sejam esquecidos e possam ser usados na
formulação de soluções para o documento de Lições Aprendidas.
24.3 Conduzindo um post-mortem
Inicialmente, pode parecer muito trabalho preparar e conduzir um post-mor-

tem, mas os benefícios compensam qualquer inconveniência, principalmente
se as lições aprendidas forem levadas a sério e implementadas na próxima
rodada de projetos. Se você estiver trabalhando em um local em que não se-
jam feitos post-mortems, ou onde eles sejam feitos mas nada mude, pode ser
interessante se reunir com a gerência do estúdio para descobrir o porquê dis-
so. Vocês podem trabalhar para adicionar essa ferramenta inestimável ao pro-
cesso de desenvolvimento.
Há várias maneiras diferentes de se fazer um post-mortem. Algumas são
bem simples e tomam pouco tempo; outras podem ser mais complicadas e
demoradas. O método usado depende do tempo disponível para execução,
do nível de detalhes esperados nas lições aprendidas e dos objetivos gerais.
Por exemplo, se estiver trabalhando em um local em que um post-mortem
nunca tiver sido feito, comece com algo descomplicado para que as pessoas
possam conhecer o processo. Elas podem se assustar se você tentar fazer um
post-mortem que aborde todos os aspectos do projeto e leve alguns dias para
terminar. No entanto, um post-mortem simples os ajudará a descobrir algumas
lições básicas a serem aplicadas ao processo de desenvolvimento. Por outro
lado, se estiver trabalhando em um local que faça post-mortems regularmente
e implemente com sucesso as lições aprendidas, pode ser recomendável usar
um processo de post-mortem mais robusto, já que provavelmente sua equipe
se beneficiará de um processo que ajude a melhorar não só o básico.
Há muitos livros de gerenciamento de projetos disponíveis que discutem
como conduzir um post-mortem. Consulte o Apêndice C, “Recursos”, para ver
uma lista completa. Além disso, o site www.projectreview.net, mantido por
Bonnie Collier, oferece um processo detalhado de condução de um post-mortem
completo. Independentemente de como você decidir executar o post-mortem de
seu jogo, há alguns aspectos básicos que devem ser seguidos.
Envolva a equipe inteira

A equipe inteira deve estar envolvida no processo – testadores de QA, pessoal
de produção, artistas, designers e programadores. Se a equipe for especialmen-
te grande (mais de 20 pessoas), talvez seja melhor fazer primeiro post-mortems
departamentais e então programar um post-mortem final em que a equipe in-
teira se reúna. O benefício de se fazerem post-mortems departamentais antes
do principal é que as pessoas podem discutir os aspectos positivos e negativos
de sua parte do projeto, formular alguns procedimentos novos para o departa-
mento (como um formato para a redação de documentos de design mais úteis)
e se preparar melhor para participar do post-mortem da equipe. Isso também
evita que o post-mortem da equipe seja prejudicado por problemas específicos
de design, programação e arte, já que eles já terão sido abordados. Se a equipe
for menor, provavelmente você não precisará agendar esses post-mortems de-
partamentais iniciais.
Prepare o post-mortem
Como nas revisões de projeto (discutidas no Capítulo 18, “Técnicas de produ-
ção”), uma preparação apropriada é essencial para o post-mortem ser o mais
produtivo possível. Antes de marcar a reunião, colete todas as informações
pertinentes do projeto, como seus objetivos originais, os objetivos reais, as lis-
tas de produtos, cronogramas, minutas de reunião, formulários de solicitação
de alteração, dados de horas extras e qualquer outra coisa que forneça evidên-
cias do que aconteceu durante o projeto. Compartilhe essas informações com
todos os membros da equipe e faça-os lerem antes da reunião.
Estabeleça um esboço do post-mortem e envie-o para a equipe algumas
semanas antes da reunião. Assim eles poderão tomar notas sobre as informa-
ções com as quais podem contribuir para o post-mortem e se preparar melhor
para a discussão. O esboço não precisa ser extremamente detalhado, mas deve
abordar os tópicos gerais que serão discutidos:
• Atingimos os objetivos do jogo?

• O cronograma, os recursos, o conjunto de funcionalidades e as expectati-
vas de qualidade eram realistas para os objetivos definidos?
• O que deu certo? O que deu errado?
• Que lições aprendemos?
Adicione perguntas abaixo desses tópicos para ajudar os membros da

equipe a descreverem como podem contribuir.
Essas perguntas devem personalizar a experiência de desenvolvimento
para cada membro da equipe, já que eles darão uma contribuição melhor se
falarem diretamente a partir da experiência pessoal. Por exemplo, faça per-
guntas como as seguintes:
• Os recursos do jogo que estavam sob sua responsabilidade foram con-

cluídos? O que ajudou ou impediu isso?
• Suas tarefas foram agendadas apropriadamente no decorrer do projeto?
• Você entendeu seu papel no projeto?
• Os pipelines de produção foram úteis para você? Como podem ser me-
lhorados?
• Você ficou satisfeito com sua contribuição para o jogo?
• Que processo funcionou melhor para você? E qual foi o pior?
• O que faria diferente no próximo projeto?
Para concluir, antes de confirmar a hora da reunião (ou reuniões, se es-

tiver fazendo post-mortems departamentais), defina um local apropriado. Se
o post-mortem for demorar mais de duas horas, considere fazê-lo fora da em-
presa. Provavelmente será mais confortável para as pessoas, principalmente
se a equipe for grande, e impedirá que elas se distraiam com seu trabalho.
Além disso, se o projeto foi especialmente exaustivo, um local fora da em-
presa fornecerá um ponto neutro para a reunião e talvez as pessoas se sintam
mais confortáveis para discutir suas experiências positivas e negativas.
Mantenha o foco
Quando sentar-se para fazer a reunião de post-mortem, mantenha a equipe
focada nos objetivos estabelecendo as normas de reunião discutidas no Capí-
tulo 18, “Técnicas de produção”:
• Defina uma agenda

• Designe um moderador
• Redija minutas
• Faça o acompanhamento dos itens de ação
A agenda pode ser baseada no esboço já enviado para a equipe. O mode-

rador deve ser alguém neutro, idealmente alguém não envolvido no projeto.
Se estiver fazendo um post-mortem completo ou não tiver um moderador ex-
periente, considere a contratação de um externo. O benefício é que ele saberá
mediar apropriadamente a discussão nesse fórum e manterá a reunião ob-

jetiva e transcorrendo de maneira eficiente. As minutas devem ser registra-
das e divulgadas para todos, mas elas não substituem o documento de Lições
Aprendidas gerado como produto final.
Embora seja inevitável que muitos aspectos negativos sejam discutidos
durante o post-mortem, a experiência geral deve ser positiva para todos os en-
volvidos. Estabeleça algumas diretrizes de participação para a atmosfera ser
positiva e as críticas construtivas. Algumas diretrizes básicas são as seguintes:
• Seja sempre profissional e não faça comentários pessoais sobre outros

membros da equipe.
• Não censure ou critique os comentários de outras pessoas.
• Mantenha uma atitude positiva visando a melhorias para o futuro.
• Aproveite a oportunidade para mostrar reconhecimento pelo trabalho
que vocês fizeram juntos como equipe.
Outras diretrizes podem ser adicionadas quando necessário e é útil di-

vulgá-las em um local visível na sala de reunião.
Após os objetivos serem reforçados e as pessoas serem lembradas das
diretrizes de participação, você estará pronto para começar a reunião. Siga a
agenda para cada ponto de discussão e certifique-se de que todos participem.
Alguns membros da equipe são naturalmente mais extrovertidos do que ou-
tros e, se não forem controlados, acabarão dominando a reunião e impedindo
que as pessoas mais tímidas participem. O moderador pode controlar o fluxo
de informações pedindo às pessoas que falem e interrompendo gentilmente
quem se desviar do tópico. Se o grupo for pequeno, comece com a primei-
ra pergunta da agenda e ouça o feedback de todos chamando-os individual-
mente. Se a equipe for maior, fique alerta para quem já falou e quem não disse
nada. Acima de tudo, mantenha a reunião focada na agenda e nos objetivos
definidos.
24.4 Documento de Lições Aprendidas
Além das minutas da reunião, o documento de Lições Aprendidas é um resul-

tado por escrito do processo de post-mortem. Como discutido anteriormente
neste capítulo, as lições aprendidas enfocam itens do cenário maior que po-
dem ser aplicados a projetos futuros. Por fim, o documento de Lições Apren-
didas será divulgado para a equipe, o estúdio e talvez até mesmo o publicador
para que todos possam se beneficiar das experiências de sua equipe.
A redação do documento de Lições Aprendidas não deve tomar muito
tempo, principalmente se as notas do post-mortem forem detalhadas e preci-
sas. As lições incluídas no documento serão as determinadas na reunião de
post-mortem. O autor do documento pode ser uma única pessoa, como o pro-
dutor, ou ele pode ter vários autores, como os líderes, dando sua contribuição
a cada seção para acelerar o processo de redação.
Limite a cinco o número de lições aprendidas do documento. Qualquer

quantidade maior do que essa será difícil de implementar, reduzindo a eficácia
da divulgação das lições. Inclua lições que tenham mais probabilidade de ser
implementadas. Por exemplo, uma lição poderia ser “reservar tempo para a
avaliação de riscos após cada fase do projeto”. Isso é algo que pode ser imple-
mentado muito facilmente e não requer nenhum investimento monetário ante-
cipado. Inversamente, uma lição do tipo “enviar todos os membros da equipe
para um treinamento em Processo de Desenvolvimento de Software em Equi-
pe” pode não ter uma chance real de ser implementada devido a restrições de
cronograma e orçamento. Mas lições como essas podem ser implementadas
se a empresa se comprometer com elas, portanto, devemos direcionar o docu-
mento de Lições Aprendidas a itens que a empresa possa querer implementar.
Forneça um exemplo que mostre por que as lições aprendidas são impor-
tantes. É aqui que a experiência pessoal da equipe ajuda realmente a definir
por que a mudança em uma determinada área é necessária. Se a inclusão de
tempo no cronograma para a avaliação de riscos for uma lição, adicione uma
situação que mostre que isso é importante. Por exemplo, se uma avaliação de
risco tivesse sido feita após a fase de pré-produção, a equipe teria percebido
que as pessoas necessárias à implementação dos recursos gráficos só estariam
disponíveis bem mais tarde no projeto, o que deixou a produção de níveis
correndo um grande risco de perder o prazo da versão beta.
Quando o documento estiver redigido, peça à equipe que o examine,
faça qualquer correção necessária e então divulgue-o para o resto do estúdio.
Você pode divulgá-lo postando-o no site da empresa, enviando-o por e-mail
para todos ou compartilhando-o em um local especificado da rede. Se seu
estúdio tiver vários post-mortems, centralize-os em um local para que fiquem
prontamente acessíveis a todos.
Para verificar se as lições estão sendo implementadas, acompanhe com a
equipe que alterações foram feitas. Por exemplo, antes de começar a produção
do próximo projeto, reúna-se com a equipe principal, examine as lições apren-
didas no último projeto e formule um plano de ação para implementá-las. Esse
plano de ação pode se tornar um dos produtos da pré-produção do projeto.

Se a equipe tiver trabalhado arduamente para concluir um projeto no decorrer
de seis meses ou três anos, um post-mortem será necessário para fornecer o
fechamento do processo de desenvolvimento. O post-mortem é uma oportu-
nidade para os membros da equipe se reunirem uma última vez para se para-
benizarem por um trabalho bem feito e aprenderem com os erros.
Um post-mortem bem-sucedido não precisa isolar cada pequeno detalhe
que saiu errado no jogo; em vez disso, deve focar em atitudes que deram certo
e atitudes que podem ser melhoradas em projetos futuros. Este capítulo dis-
cutiu como executar um post-mortem bem-sucedido e determinar lições que
possam ser aplicadas a outros projetos.
25
KITS DE FECHAMENTO
Neste capítulo
• Definindo os kits de • Organizando o • Lista de verificação do
fechamento conteúdo kit de fechamento
• Criando os kits de • Finalizando os kits de
fechamento fechamento
25.1 Introdução
Durante a pós-produção, uma tarefa importante é a organização de todos os

códigos e assets do jogo em um kit de fechamento e seu arquivamento para
consulta futura. Os arquivos serão necessários se for preciso remasterizar o
jogo, criar um patch ou uma atualização de conteúdo, portar o jogo para ou-
tra plataforma, traduzi-lo para outro idioma, desenvolver uma sequência ou
qualquer outro tipo de conteúdo que demande os assets, o código e as ferra-
mentas originais do jogo. Os publicadores podem enviar kits de fechamento
para os distribuidores que desenvolverem versões localizadas para distribui-
ção em seus países.
25.2 Definindo os kits de fechamento
Há três tipos básicos de kits de fechamento: completo, de localização e de tradu-

ção. Cada um desses kits serve a uma finalidade diferente, mas se houver tempo
para criar somente um, então o kit de fechamento completo é a melhor opção.
Um kit de fechamento completo é composto por todos os assets originais
descompactados (inclusive a arte, o código e o som), a documentação comple-
ta (inclusive de design, técnica e da embalagem), as ferramentas proprietárias
usadas no pipeline de produção e versões gold master (inclusive todas as
versões localizadas) do jogo que foi lançado. Se o kit completo tiver todos os
itens necessários, alguém de fora da equipe de desenvolvimento deve poder
reconstruir uma versão completa e jogável do jogo a partir do zero.
Um subconjunto do kit de fechamento completo é o kit de localização.
O kit de localização organiza todos os assets necessários à criação de versões
localizadas do jogo em um local central. Quando o código do jogo é favo-
rável à localização (consulte o Capítulo 21, “Localização”, para obter mais
informações), geralmente não é necessário que o kit de localização inclua o
código-fonte e um conjunto completo de assets descompactados. Esse kit é
menor do que o kit de fechamento completo e é enviado para fornecedores de
localização que com ele poderão traduzir, integrar e testar versões localizadas
do jogo sem a ajuda da equipe de desenvolvimento.
Se um fornecedor de localização externo estiver trabalhando em versões
de outros idiomas que serão entregues com a versão principal do jogo, será ne-
cessário criar um kit de localização antes da liberação do código. Essa não é a
situação ideal, já que o kit conterá assets que não são definitivos e podem mudar
drasticamente durante o resto do cronograma de produção. Nesse caso, a equipe
de localização terá de estar em contato constante com a equipe primária de pro-
dução para permanecer atualizada sobre qualquer alteração feita no jogo.
Um subconjunto do kit de localização é o kit de tradução. Esse kit con-
tém apenas o texto (e às vezes assets de arte) que deve ser traduzido. Versões
localizadas não podem ser criadas a partir desse kit. Esse é um kit ideal para
ser enviado para tradutores, porque é muito menor e menos complexo do que
um kit de fechamento completo. Essencialmente, o tradutor receberá apenas
arquivos de texto que devem ser traduzidos. Ele poderá atualizar esses ar-
quivos para o idioma apropriado e devolvê-los para a equipe de desenvolvi-
mento ou o fornecedor de localização, que então integrará os assets e criará
versões localizadas.
25.3 Criando os kits de fechamento
Os kits de fechamento são criados após o código do jogo ser liberado para
que os desenvolvedores possam incluir todo o código-fonte e os assets finais.
O conteúdo de um kit de fechamento inclui assets, documentação, ferramen-
tas e código. Se patches ou conteúdo adicional forem criados após o jogo ser
25 • Kits de Fechamento 389
lançado, será gerado um complemento do kit de fechamento original e os

dois kits serão arquivados juntos.
Assets
Inclua todos os assets de texto, arte e áudio do jogo no kit de fechamento. Os
arquivos-fonte originais desses assets também são necessários para que altera-
ções possam ser feitas facilmente em qualquer dos assets in-game. Isso é parti-
cularmente importante na criação de versões localizadas, porque as traduções
serão integradas a vários assets de texto, VO e arte. Os assets finais in-game
também são necessários, já que é útil compará-los com qualquer novo asset
criado a partir dos arquivos-fonte.
Assets de texto
Inclua os seguintes assets de texto no kit de fechamento:
• Assets de texto in-game em todos os idiomas

• Arquivos de ajuda e arquivos “leia-me”
• Strings de instalação
• Mensagens de erro
Assets de voiceover
Inclua os seguintes assets de voiceover no kit de fechamento:
• Arquivos de áudio descompactados (todos os idiomas)

• Roteiros de voiceover e cinemática
• Notas sobre o elenco
• Especificações técnicas de voiceover
• Planilha mestra de voiceover
Assets de arte
Os assets de arte a seguir devem ser incluídos no kit de fechamento:
• Assets de arte finais
• Arquivos-fonte de todos os assets de arte (inclusive logotipos)
Assets de cinemática
Inclua todos os assets de cinemática, junto com os arquivos-fonte:
• Cinemática final in-game

• Codecs de vídeo e movie players
• Cinemática descompactada
• Arquivos-fonte de cinemática
• Trilhas de áudio separadas e descompactadas de música, voiceover e
efeitos sonoros
Assets de localização
Se o jogo tiver sido localizado, inclua todos os assets da nova versão, entre
eles:
• O texto traduzido
• Arquivos de voiceover traduzidos (versão compactada e descompactada)
• Glossários de localização
Assets de embalagem
Insira o layout e os assets da caixa, do manual e outras partes impressas, ou seja:
• O layout da caixa (e todos os arquivos-fonte)

• O layout do manual (e todos os arquivos-fonte)
• Screen shots descompactadas usadas na embalagem
Ferramentas
As ferramentas são plug-ins de software de terceiros ou qualquer ferramenta
proprietária necessária na criação dos assets finais in-game. Por exemplo, o
plug-in usado na compactação das texturas dos modelos de personagens deve
ser incluído. Se software comercial específico for necessário na criação de
qualquer asset do jogo, todas as informações e a versão correta devem ser for-
necidas. Por exemplo, o jogo pode demandar uma versão específica do Maya
para a criação dos níveis, e se essa versão não for usada, o desenvolvedor não
poderá converter arquivos do Maya em assets usáveis do jogo. Alguns tipos
de ferramentas que devem ser incluídos são:
• Plug-ins que ampliem software de terceiros

• Ferramentas proprietárias criadas pelo desenvolvedor
• Ferramentas de localização usadas na integração de traduções
Código do jogo
O código-fonte é um componente muito importante do kit de fechamento.
Se estiver faltando, não será possível criar patches, atualizações de conteúdo
ou versões portáveis do jogo. Inclua os seguintes assets de código no kit de
fechamento:
• Gold masters – versões master são necessárias para todas as versões do jogo
• Código-fonte – inclua documentação sobre como compilar o jogo
• Código-fonte das ferramentas – posteriormente pode ser necessário mo-
dificar as ferramentas usadas no jogo, para uma sequência ou um novo
projeto
Documentação
A documentação é composta por qualquer documento gerado durante a pro-
dução do jogo. Ela inclui todos os documentos de design, técnicos, de ferra-
mentas e gerais do jogo. A área de documentação é crucial porque fornece
todas as informações necessárias de como usar o kit de fechamento e detalhes
de onde os assets estão localizados. Na raiz do primeiro disco, inclua um
sumário detalhando o que pode ser encontrado no kit de fechamento. O con-
teúdo deve incluir descrições da pasta principal e de subpastas.
Documentação do jogo
É útil incluir a documentação do jogo para que ela possa ser usada por pes-
soas que estiverem criando novo conteúdo ou uma versão portável. Alguns
tipos de documentação que devem ser incluídos são:
• Principais documentos de design

• Fluxograma descrevendo a IU
• Trapaças e detonados (cheats and walkthroughs)
• Planos de testes
Diretrizes técnicas
As diretrizes técnicas fornecem informações de integração de assets e sua
conversão para os formatos de arquivo específicos do jogo, além de descrever
especificações de hardware/software. Devem ser redigidas de maneira clara e
direcionadas a não participantes da equipe original de desenvolvimento. Os
tipos de diretrizes técnicas que devem ser incluídos são:
• Visão geral do pipeline de produção – detalha como converter os arqui-

vos-fonte para o formato usado pelo jogo
• Instruções de criação de builds – detalham como preparar o ambiente de
desenvolvimento e o processo de compilação da build
• Requisitos de software – é uma lista de software comercial ou proprietá-
rio necessário na definição de um pipeline de produção funcional
• Requisitos de hardware – uma lista do hardware necessário no desen-
volvimento, que inclui kits de desenvolvimento do console e informa-
ções sobre o SDK usado na compilação do jogo
• Instruções de ferramentas proprietárias – incluem como instalar e usar
as ferramentas (se algum tutorial tiver sido criado, inclua-o também)
Informações gerais do produto

As informações gerais do produto fornecem uma visão geral do jogo, como
a plataforma, os idiomas e informações de licenciamento. Certifique-se de
listar alguém como ponto de contato para o caso de surgirem dúvidas sobre o
conteúdo do kit de fechamento. Uma lista de bugs abertos e outros problemas
conhecidos também será útil se houver planos para um patch ou atualização.
25.4 Organizando o conteúdo
Organize os assets, o código, a documentação e as ferramentas do jogo em

pastas separadas. Consulte a Figura 25.1 para ver um exemplo dessa estrutura
de diretório básica. Um arquivo chamado “Conteúdo kit” na raiz do disco é
um documento que descreve o conteúdo do kit de fechamento. Crie subpastas
com nomes descritivos para organizar melhor os assets. Por exemplo, a pasta
“Documentação” contém as subpastas “Documentação do jogo”, “Informa-
ções gerais” e “Diretrizes técnicas”.
Se o kit for composto por vários discos, inclua a documentação e o sumá-
rio no primeiro disco para facilitar a consulta.
Figura 25.1 Estrutura de diretório de um kit de fechamento.
25.5 Finalizando os kits de fechamento
Quando o kit de fechamento definitivo estiver concluído, procure um desen-

volvedor de fora da equipe principal de desenvolvimento e peça a ele que
reconstrua o jogo e crie uma versão gold master. Essa é uma boa maneira de
encontrar erros nas orientações ou descobrir assets ausentes. Se os kits não
forem verificados antes de serem enviados para outros fornecedores, a equipe
de produção original pode ter de resolver problemas eventuais no kit, o que
tomaria tempo de suas outras tarefas de desenvolvimento (alguns membros
da equipe já podem estar trabalhando em novos jogos ou mesmo em uma

empresa diferente).
Cópias do kit devem ser criadas e armazenadas em vários locais – uma
cópia fica com o desenvolvedor, outra é arquivada no publicador e uma ter-
ceira é enviada para uma instalação de armazenamento remota.
Rotule cada disco com as informações a seguir:
• Nome do jogo
• Versão do jogo
• Plataforma de destino
• Data de criação
• Número do disco, escrito no formato “X” de “X” discos.
• Descritor de conteúdo (“documentação”, “cinemática”, “código-fonte” e
assim por diante)
Esses rótulos facilitam a localização das informações necessárias do kit e

ajudam a confirmar se todos os assets foram considerados e estão presentes. Se
patches ou conteúdo adicional forem gerados para o jogo após ele ser lançado,
crie um complemento do kit de fechamento original contendo todas as fontes
de assets do conteúdo extra. Certifique-se de incluir orientações de como inte-
grar o conteúdo adicional às informações do kit de fechamento original.
25.6 Lista de verificação do kit de fechamento
A Figura 25.2 é um exemplo de lista de verificação dos itens geralmente in-

cluídos no kit de fechamento. A primeira seção lista toda a documentação a
ser incluída no kit. Na seção seguinte, os assets necessários do jogo são lista-
dos. A última seção inclui algumas perguntas úteis que devem ser respondi-
das antes de você concluir o kit para assegurar que todos os itens necessários
sejam incluídos.
A criação do kit de fechamento é uma etapa importante da pós-produção.

Embora possa demorar um pouco reunir os assets e redigir a documentação, é
importante todos os arquivos-fonte e instruções de build do jogo estarem em
um local centralizado. Isso pode ser necessário na remasterização do jogo ou
se a equipe for solicitada a portá-lo para outra plataforma. Este capítulo for-
neceu informações detalhadas do que deve ser incluído no kit de fechamento,
junto com sugestões de como organizar, finalizar e armazenar o kit. O capítulo
termina com uma lista de verificação do que precisa ser incluído em um kit
de fechamento.
DOCUMENTAÇÃO S/N Notas

Conteúdo do kit de fechamento (na raiz do primeiro CD do
kit de fechamento)
NO SITE
Documentação de design, incluindo:
Documentos de design
Trapaças e detonados
Fluxograma da interface de usuário
Plano de testes
Documentação técnica, incluindo:
Instruções sobre a criação de builds (inclusive de versões localizadas)
Visão geral do pipeline de produção
Requisitos de software (inclusive números de versão)
Requisitos de hardware
Instruções de ferramentas proprietárias
Informações gerais do produto, incluindo:
Informações do jogo (plataforma, idiomas)
Informações de contato
Lista de bugs conhecidos
ASSETS DO JOGO
Texto
Assets de todos os arquivos de texto do jogo
Lista de verificação de todos os arquivos de texto do jogo
Voiceover
Arquivos de VO descompactados de todo o áudio do jogo
Roteiro mestre de voiceover
Notas sobre o elenco
Especificações técnicas do voiceover
Arquivos finais do VO in-game
Lista de verificação de todos os arquivos de VO do jogo
Arte
Todos os assets de arte do jogo
Arquivos-fonte das artes de logotipo
Lista de verificação de todos os assets de arte do jogo
Cinemática
Arquivos-fonte da cinemática descompactados
Cinemática descompactada
Cinemática in-game final descompactada
Codecs e movie player usados na cinemática
Trilha de áudio (música, efeitos sonoros e voiceover descompactados
em trilhas separadas)
Mixagem de áudio final
Lista de verificação da cinemática
Localização
Glossários
Embalagem
Arquivos-fonte do layout da embalagem
Arquivos-fonte do layout do manual
Capturas de tela descompactadas (inclusive de versões localizadas)
Lista de verificação da caixa e dos documentos a serem localizados
ASSETS DE CÓDIGO
Cópias da versão gold master
Código-fonte do jogo
Código-fonte das ferramentas
Arquivos de instalação
FERRAMENTAS
Plug-ins usados com software de terceiros (inclui especificações de software)
Ferramentas proprietárias (inclusive o código-fonte)
Ferramentas de localização (inclusive o código-fonte)
OUTRAS PERGUNTAS
O conteúdo do kit de fechamento foi claramente rotulado?
As orientações são claras e fáceis de entender?
Há algum arquivo faltando no kit?
O kit contém arquivos extras?
O kit contém a versão atual de todos os assets?
Os discos foram rotulados com o nome do jogo, o número da versão,
a plataforma, a data e o número do disco?
O kit foi verificado por alguém de fora da equipe de desenvolvimento?
Cópias do kit foram arquivadas na empresa e em um local remoto?
Figura 25.2 Lista de verificação do kit de fechamento.

Apêndice A
ESTUDO DE CASO – CICLO DE
PRODUÇÃO DE UM JOGO
Este apêndice é um estudo de caso do ciclo de produção de um jogo fictício

chamado Unidade de Justiça, desenvolvido pelo Supergame Studios e publi-
cado pela Digital Fun.
A.1 Introdução
A Digital Fun adquiriu recentemente os direitos de propriedade intelectual (PI)

para criar jogos baseados em uma franquia de filmes popular chamada Unidade
de Justiça. Eles pretendem aprovar um orçamento generoso para o jogo, mas
querem manter os custos sob controle onde puderem. Seu objetivo principal é
concluir o jogo em 24 meses para que ele possa ser entregue quando o próximo
filme for lançado. Eles enviaram uma solicitação de proposta (SDP) para vários
desenvolvedores de jogos independentes e receberam muitas respostas interes-
santes como resultado. A que interessou mais veio do Supergame Studios.
O Supergame Studios é um estúdio pequeno, mas bem estabelecido, que
se especializou em desenvolver jogos para as plataformas de console e PC.
Eles têm uma reputação na indústria de criar jogos de qualidade no prazo e
conforme o orçamento. É um estúdio de tamanho médio, com cerca de 60 a
80 pessoas, dependendo das necessidades de desenvolvimento, e geralmente
tem dois projetos em produção ao mesmo tempo. São desenvolvedores licen-
ciados pela Sony e pela Microsoft.
O Supergame Studios está ansioso para trabalhar em Unidade de Jus-
tiça e criou uma proposta que atingiu os principais objetivos da Digital Fun
para o jogo. A proposta mostrou que o Supergame Studios pode criar um jogo
para várias plataformas em 24 meses por aproximadamente 15 a 20 milhões
de dólares. O jogo será desenvolvido em ciclos iterativos para que haja algo
pronto em 18 meses, caso o lançamento do filme seja antecipado. Recursos
continuarão sendo adicionados à funcionalidade principal enquanto o tempo
permitir. Eles assinaram um contrato com a Digital Fun para criar um jogo
396 Apêndice A
para Unidade de Justiça, sabendo que ainda há muitas coisas a serem defini-
das sobre o jogo, como:
• Gênero
• Plataforma
• Planos de localização
• Cenário
• História
Esses itens e muitos outros serão definidos durante a fase de pré-produção

e apresentados à Digital Fun para aprovação final antes da produção começar.
A.2 Fase de pré-produção

A fase de pré-produção principal levará cerca de seis meses, começando em
outubro de 2007 e terminando em março de 2008. Durante esse período, a
equipe definirá o conceito e os requisitos e criará um plano para o desenvolvi-
mento do jogo de modo que ele esteja pronto para entrega em outubro de 2009.
Haverá fases de pré-produção adicionais durante o ciclo de desenvolvi-
mento de 24 meses para a manipulação de mais recursos, localizações, gra-
vações de voiceover e outros subprojetos que ocorrerão dentro do ciclo. A
equipe também sabe que a fase de pré-produção principal não terá uma data
final definitiva e que a produção começará em algumas partes do jogo antes
da pré-produção ter terminado em outras. A pré-produção é abordada com
mais detalhes nos Capítulos 14, 15 e 16.
Durante a fase de pré-produção, a equipe será composta por cinco pes-
soas: um produtor, um artista líder, um programador líder, um designer líder
e um líder de QA, todos em tempo integral. Eles trabalharão bem próximos
durante a pré-produção e solicitarão feeedback sobre as ideias do jogo a pes-
soas de fora quando necessário.
A.2.1 Conceito
A fase de conceito inicial foi agendada para começar em 1º de outubro de
2007 e terminar em 31 de outubro de 2007. Durante esse mês, a equipe exami-
nará a proposta original feita para Unidade de Justiça e tomará uma decisão
sobre o gênero, a plataforma e os recursos-chave do jogo. Além disso, fará
alguma pesquisa sobre a concorrência e elaborará tanto uma análise SWOT
quanto uma análise competitiva. Uma vez que essas informações tiverem sido
organizadas e apresentadas para a gerência para aprovação, a equipe conti-
nuará aprimorando o conceito.
O objetivo da equipe é aprimorar o conceito e criar alguns protótipos an-
tes das férias, já que o escritório estará fechado na última semana de dezembro
de 2007. Quando todos voltarem em janeiro de 2008, os protótipos e os docu-
mentos de design iniciais serão apresentados à gerência para aprovação. Nesse
momento, a fase conceitual do jogo estará perto de terminar. A Figura A.1 é um
Estudo de Caso – Ciclo de Produção de Um Jogo 397
cronograma estimado para a fase conceitual de Unidade de Justiça. Consulte o

Capítulo 14 para obter mais informações sobre a fase conceitual.
Todas as figuras deste apêndice podem ser encontradas no CD.
Estimativa Estimativa
Conceito inicial Recursos Cronograma geral Tarefas
de início de finalização
Brainstorm O produtor conduz as 1 semana 1o de outubro 5 de outubro Discuta os conceitos iniciais do jogo, inclusive
NO SITE sessões, a equipe participa. de 2007 de 2007 o gênero e a plataforma.
Conceito inicial Designer líder 1 semana 8 de outubro 12 de outubro Examine as notas do brainstorm. Defina o
de 2007 de 2007 conceito inicial, o gênero e a plataforma.
Incorpore o feedback da equipe.
Análise Produtor, marketing 2 semanas 15 de outubro 26 de outubro Examine a concorrência atual e potencial, execute
competitiva de 2007 de 2007 a análise SWOT com base no conceito inicial.
Aprovação do O produtor conduz a 2-3 semanas 29 de outubro 31 de outubro Apresente o conceito inicial, com o gênero e a
conceito inicial reunião, os líderes após a pré-produ- de 2007 de 2007 plataforma, para aprovação. Análise competitiva
participam. ção começar. inicial concluída. Incorpore o feedback da gerência.
Defina o conceito Recursos Cronograma geral Tarefas
Declaração da O produtor conduz as 1-2 dias 1o de novembro 2 de novembro Defina a declaração da missão do jogo.
missão sessões, a equipe participa. de 2007 de 2007
Cenário do jogo Designer líder, artista líder 3-5 dias 5 de novembro 9 de novembro Defina o cenário do jogo, inclusive a aparência.
de 2007 de 2007
Mecânica do jogo Designer líder 2-4 semanas 12 de novembro 6 de dezembro Crie a visão geral de como os principais elementos
de 2007 de 2007 do jogo funcionarão: desafios, recompensas, curva
de aprendizado, esquema de controle, elementos
de áudio, ambiente multijogador.
Sinopse da história Designer líder, redator 3-5 dias 10 de dezembro 14 de dezembro Crie a história de fundo do jogo, as biografias dos
de 2007 de 2007 personagens, a descrição geral de como a história
se desenrola no jogo.
Arte conceitual Artista líder, artista 3-5 semanas 12 de novembro 7 de dezembro Crie a arte conceitual do cenário, dos personagens
conceitual de 2007 de 2007 e dos objetos do jogo.
Elementos de Designer líder, designer 2-4 dias 17 de dezembro 21 de dezembro Crie a visão geral de como o voiceover, os efeitos
áudio de som de 2007 de 2007 sonoros e a música serão apresentados no jogo.
Prototipagem Designer líder, produtor 4-6 semanas 12 de novembro 21 de dezembro Crie protótipos dos principais elementos do jogo.
de 2007 de 2007
Análise de risco O produtor conduz as 2-3 dias 19 de dezembro 21 de dezembro Avalie os riscos do projeto, determine a estratégia
sessões, a equipe participa de 2007 de 2007 de eliminação, divulgue para a equipe.
Venda a ideia Produtor, líderes 2-3 meses após 2 de janeiro 4 de janeiro Apresente todos os principais elementos de joga-
a aprovação do de 2008 de 2008 bilidade para a gerência para aprovação,
conceito inicial incorpore seu feedback.
Lançamento do Produtor Após a gerência 7 de janeiro 7 de janeiro Reúna-se com a equipe para celebrar a aprovação
projeto aprovar a expo- de 2008 de 2008 do conceito. Se estiver trabalhando em um título
sição. de console, envie o conceito do jogo para o
fabricante do console para aprovação.
Figura A.1 Estimativa de cronograma da fase conceitual de Unidade de Justiça.
Conceito inicial
O conceito inicial do jogo se baseia no conceito inicial do filme: um grupo de
desajustados poderia se reunir como a Unidade de Justiça e salvar o mundo
de supervilões? À medida que a fase conceitual avançar, a equipe se baseará
nesse conceito inicial e definirá se o jogo deve recriar os eventos que ocorrem
no filme ou apresentar uma história diferente, e talvez um novo personagem
(vilão ou aliado).
O Supergame Studios fará um contato com o estúdio do filme que forne-
cerá o roteiro atualizado, as informações sobre o elenco e outras coisas relacio-
nadas ao filme que a equipe de desenvolvimento precisará na pré-produção.
Gênero
Há muito material a ser trabalhado em Unidade de Justiça, o que facilita a
criação de diferentes gêneros para o jogo. Por exemplo, Unidade de Justiça
poderia ser enquadrado em qualquer um dos gêneros a seguir:
398 Apêndice A
Jogo de luta: Se Unidade de Justiça fosse um jogo de luta para dois joga-
dores, poderia apresentar uma lista de super-heróis e vilões para serem
escolhidos. Os atrativos para a venda poderiam incluir personagens não
bloqueáveis, movimentos combinados e possivelmente um vínculo com
outra propriedade licenciada, como um herói de quadrinhos existente.
Estratégia em tempo real: Como um RTS (Real-Time Strategy), o jogo
apresentaria um exército de super-heróis lutando contra hordas de inva-
sores alienígenas.
Jogo de interpretação de personagens: Em um role playing game (RPG)
em primeira pessoa, o jogador assumiria o papel de um personagem, lu-
tando contra o mal em um universo de super-heróis com vilões mascara-
dos e combatentes do crime.
A equipe passará algum tempo discutindo os diversos gêneros e fazendo
alguns protótipos em papel se possível. O tipo do gênero será influenciado
pelo enredo do filme e também pela plataforma do jogo.
Plataforma
O publicador quer que o jogo seja lançado em várias plataformas – console,
PC e celular. O jogo será essencialmente o mesmo nessas plataformas, o que
reduzirá o tempo e o custo do desenvolvimento, mas cada plataforma terá de
apresentar algum recurso ou asset exclusivo que não esteja disponível nas
outras. Por exemplo:
PC: Uma versão de Unidade de Justiça baseada em PC apresentaria a ca-
pacidade de personalização como recurso primário porque os controles
do teclado permitem um alto grau de personalização e interação com o
mundo do jogo.
Celular: Como um jogo de celular, Unidade de Justiça teria uma IU sim-
ples e a mecânica do jogo enfocaria um recurso fácil de aprender, como
saltar em terraços ou coletar itens. Essa versão será a mais diferente das
versões de PC e console, já que os assets de arte terão uma resolução
mais baixa e a programação e o design serão menos complexos.
Console: Um jogo de console apresentaria jogabilidade e assets seme-
lhantes aos da versão de PC, mas teria mais inimigos e obstáculos para o
jogador enfrentar a fim de manter a ação excitante e com ritmo veloz. A
IU não será tão complexa quanto a da versão de PC. A versão de console
de Unidade de Justiça também incluirá um personagem exclusivo que
não aparece na versão de PC.
Análise SWOT
A Figura A.2 é um exemplo de análise SWOT para Unidade de Justiça que
analisa maneiras do estúdio lidar com um jogo rival chamado PostMortal, a
ser lançado ao mesmo tempo.
Análise SWOT
O principal concorrente de Unidade de Justiça é PostMortal, um jogo de atirador em primeira pessoa que se passa em um universo de
super-heróis.
Fatores internos Fatores externos
Nossos pontos fortes Como explorar Nossas oportunidades Como explorar
Comparado com o rival Enfatizar esses recursos no Unidade de Justiça será A promoção conjunta do jogo
PostMortal, Unidade de Justiça plano de marketing. lançado na mesma época e do filme cria uma história
apresenta uma forte da sequência cinematográfi- separada para o jogo que tem
experiência multijogador, ca, o que também chamará ligação com algumas tramas
incluindo um avatar atenção para o jogo. importantes do filme.
multijogador personalizável,
jogabilidade variada e muitos
mapas.
Nossos pontos fracos Como neutralizar Nossas ameaças Como neutralizar
Unidade de Justiça apresenta Deixe esse recurso de lado no PostMortal foi agendado para Crie o quanto antes uma
uma experiência de jogador plano de marketing e ressalte lançamento 2 meses antes de expectativa sobre o participante
único, não linear e de passeio os recursos multijogador. Unidade de Justiça e isso pode poder jogar como seu
livre que não suscitará as ter um impacto negativo personagem favorito da Unidade
mesmas emoções de sobre as vendas – as pessoas de Justiça. Patrocine a criação de
PostMortal, que é linear e segue podem comprar o jogo de uma competição entre inimigos,
rigidamente o roteiro. super-heróis PostMortal em vez em que o vencedor ganhe um
de Unidade de Justiça . encontro com o elenco do filme e
uma cópia antecipada do jogo.
Figura A.2 Análise SWOT de Unidade de Justiça.
Além disso, a equipe criará uma análise SWOT para examinar o gênero e
a plataforma que estão usando para o jogo. Eles querem identificar possíveis
problemas na criação de Unidade de Justiça como um jogo para várias plata-
formas e descobrir oportunidades interessantes de promoção do jogo.
O produtor agendará uma série de reuniões de brainstorm para discutir
as diversas análises SWOT. É importante ouvir a opinião de todas as pessoas
da equipe para as análises SWOT serem mais produtivas.
Análise competitiva
A equipe também trabalhará em uma análise competitiva de jogos que já fo-
ram lançados e de jogos que ainda serão lançados. Essas informações ajuda-
rão o Supergame Studios a determinar como diferenciar Unidade de Justiça
da concorrência. Vários jogos serão pesquisados para a análise competitiva.
A Figura A.3 é um exemplo de análise competitiva que discute PostMortal.
Outros jogos serão adicionados à análise à medida que a equipe continuar
pesquisando a concorrência.
A.2.2 Definição do conceito

Quando o conceito inicial for aprovado, o Supergame Studios o detalhará ainda
mais e começará a trabalhar na documentação e em um protótipo jogável. Con-
sulte o Capítulo 15 para obter mais informações sobre a definição do conceito.
Declaração da missão
A declaração da missão detalha o que está sendo feito e por quem. Seu obje-
tivo é definir sucintamente a essência principal do jogo. Ela passa a ser um
400 Apêndice A
Data de Crítica Estatísticas

Jogo Desenvolvedor Publicador Plataformas lançamento Resumo do jogo Recursos média de vendas
estimada
PostMortal Funtime A-1 Xbox Outubro PostMortal é uma -Avenger Boy é o n/a n/a
Studios Pu- 360, PS3 de 2009 nova IP sobre personagem
blishing super-heróis. É um principal do jogador.
jogo de -Novo IP que não
ação-aventura em tem apelo
terceira pessoa e o diversificado.
jogador assume o -Modos
papel de Avenger multijogador
Boy. Outros limitados, mas terá
super-heróis uma pequena
estarão no jogo, campanha de
mas o jogador só cooperação on-line.
controla um herói. -Ação-aventura
O jogo apresenta tradicional em
super-heróis terceira pessoa; a
vestidos exclusividade está
tradicionalmente nos cenários e
em um cenário de personagens.
1950. Avenger Boy -Cada personagem
se junta a outros tem um superpoder
heróis para exclusivo para usar
combater o Dr. No contra o inimigo. Ele
Good. auxiliará no jogo se
sua ajuda for
solicitada pelo
jogador.
Figura A.3 Análise competitiva de Unidade de Justiça.
padrão contra o qual os recursos e o cenário do jogo são avaliados – qualquer

item que não seguir a declaração não será incluído no jogo. A declaração de
missão inicial de Unidade de Justiça é:

controles otimizados. Foi planejado para fãs de quadrinhos e filmes de
super-heróis que queiram viver a aventura de ser um herói.
A declaração de missão inicial mudou um pouco na pré-produção após a

equipe receber feedback sobre o primeiro esboço do documento principal de
design. O publicador quer que a conexão entre o jogo e o filme seja mais forte
na declaração. A nova declaração de missão de Unidade de Justiça é:

controles otimizados. Foi planejado para fãs do filme Unidade de Justiça
e também para fãs de quadrinhos e outros filmes de super-heróis que
queiram viver as aventuras de seus heróis favoritos.
Cenário do jogo
O cenário do jogo está intimamente ligado ao cenário do filme. Por enquanto,
a equipe definirá o cenário em vários aspectos e tanto ele quanto o enredo
serão detalhados nos documentos de design no decorrer dos próximos meses.
O cenário de Unidade de Justiça é o seguinte:
O jogo se passa em um mundo clássico de vilões cruéis e assassinos

armados. A equipe do jogador é composta por heróis excêntricos com
superpoderes. Em um universo cheio de heróis e vilões impassíveis, a
Unidade de Justiça é um grupo de desajustados bizarros com estranhos
poderes e personalidades excêntricas. Unidade de Justiça é parte paró-
dia e parte tributo às superequipes clássicas dos anos sessenta, comple-
mentado por histórias de origem improvável e vilões poderosos.
Mecânica do jogo
A mecânica descreve como o jogador interagirá com o jogo. Por exemplo, como
o esquema de controle funciona, que tipos de modos multijogador estão dis-
poníveis ou que tipos de desafios o jogador encontrará e que estratégias serão
usadas no enfrentamento desses desafios. Embora o designer seja responsável
por documentar a mecânica do jogo, ele trabalhará junto aos outros líderes
para prototipar seus aspectos básicos e saber o que funcionará melhor no jogo.
A mecânica-chave de Unidade de Justiça se baseia nos poderes que os
super-heróis têm. Os poderes disponíveis no jogo corresponderão aos pode-
res exibidos no filme. Por exemplo, Bullet Point pode voar e essa habilidade
estará presente no jogo. O designer líder trabalhará com o programador líder
para criar um protótipo voador e determinar como o jogador controlará Bullet
Point quando ele estiver voando, e assim por diante.
Os designers passarão algum tempo da pré-produção bolando o resto da
mecânica principal do jogo. Os recursos da mecânica serão priorizados para
que os mais importantes sejam definidos e prototipados primeiro.
Sinopse da história
O Supergame Studios decidiu criar um enredo exclusivo para o jogo com alguns
vínculos com o filme. Eles não querem depender demais do conteúdo do filme,
já que sua versão final será diferente do roteiro original. O jogo se concentrará na
origem dos super-heróis e em como eles se tornaram a Unidade de Justiça.
A sinopse da história de Unidade de Justiça é a seguinte:
O executivo de marketing Mark Ferrier desenvolveu poderes surpreen-

dentes ao ser atingido por um raio durante uma apresentação. Inicial-
mente, os manteve em segredo, mas após testemunhar a Unidade de
Justiça em uma batalha intensa com o desprezível Wire Hanger, se uniu
a eles em sua defesa. A Unidade recrutou Ferrier, que escolheu o nome
Bullet Point. Junto com Montezuma, Rainha do Gelo, Major Malfunction
e Caribou, ele combate o crime e aqueles que o cometem.
Elementos de áudio
O design de som de Unidade de Justiça terá uma qualidade muito alta e su-
portará som Dolby Surround 5.1. Os super-heróis do jogo serão dublados pe-
los mesmos atores que os representam no filme. O design do voiceover será
muito complexo, já que pistas de voz são usadas para dar muitas informações
402 Apêndice A
para o jogador sobre a história, os personagens, as missões e a mecânica do

jogo. Cinquenta mil linhas de diálogo é uma estimativa aproximada para o
jogo. Cada plataforma pode apresentar algumas pistas de voz adicionais que
serão exclusivas dessa plataforma.
O Supergame Studios está planejando licenciar a música-tema do filme
para usá-la como música-tema principal da cinemática introdutória do jogo.
Eles também contratarão um compositor para criar algumas variações sobre
esse tema para serem usadas em todo o jogo. A música será adaptativa e mu-
dará de acordo com o que o jogador estiver fazendo. Por exemplo, se o jogador
estiver explorando o mundo, um tipo de música será tocado, e se ele entrar
em combate, outro tipo de música começará a tocar.
Unidade de Justiça usará um efeito sonoro exclusivo para cada poder
dos super-heróis. Isso permitirá que o jogador identifique facilmente quem
o está ajudando, até mesmo quando o super-herói estiver fora da tela. Efeitos
sonoros padrão serão usados para coisas como passos, sons ambientais e a
seleção de itens na tela da IU. O Supergame Studios está planejando usar para
os poderes dos super-heróis os mesmos efeitos sonoros usados no filme. O
designer de som do estúdio ficará em contato direto com alguém da equipe de
design de som do filme.
Prototipagem
Os poderes dos super-heróis são um dos aspectos-chave da mecânica do jogo.
A equipe de design trabalhará com a equipe de programação para prototi-
par pelo menos um superpoder de cada um dos personagens jogáveis. Por
exemplo, a Rainha do Gelo tem o poder de congelar qualquer coisa e já há
um trabalho sendo feito em um protótipo para que seja definido como será a
mudança do estado de um objeto de normal para congelado. Será desafiador
fazer isso com a água, principalmente água corrente. A habilidade de voar de
Bullet Point também será prototipada.
A equipe também usará alguns protótipos em papel para testar as esta-
tísticas da mecânica do jogo. Todos os superpoderes têm de ser equivalentes
para que um super-herói não se torne dominante no decorrer do jogo. É preci-
so que os designers trabalhem em um sistema que equilibre os superpoderes.
Inicialmente eles jogarão dados como uma maneira de prototipar em baixa fi-
delidade a potência de cada superpoder. Quando tiverem definido isso no pa-
pel, trabalharão com a programação para criar um protótipo digital funcional.
Análise de risco
Nesse ponto do projeto, antes dos documentos conceituais serem enviados
para a gerência sênior para aprovação, o produtor conduz uma análise de
risco. Ele continuará rastreando riscos durante todo o projeto para estar pre-
parado para qualquer circunstância inesperada. A Figura A.4 é um exemplo
de análise de risco para Unidade de Justiça.
Nesse momento, o número de riscos reais deve ser muito baixo. Esses
riscos aumentarão à medida que a equipe continuar a desenvolver a mecânica
do jogo e o enredo. A tecnologia usada na criação do jogo terá um grande im-
Probabilidade Impacto sobre Classificação

Risco Estratégias de mitigação
de ocorrência o projeto do risco
O licenciador proprietário da IP de Alta Alto 1 -Marcar uma reunião de lançamento
Unidade de Justiça pode não dar um com o licenciador no início da
feedback e a aprovação a tempo. pré-produção para examinar os
Se ele não aprovar o conteúdo da objetivos do projeto e restrições no
versão gold master, o processo de cronograma.
envio para o fabricante do console
sofrerá atrasos, o que pode afetar
a data de entrega.
O design tem de criar um sistema Baixa Alto 2 -Dedicar-se à prototipagem dos
de mecânica jogável em que os principais poderes de cada personagem
poderes dos super-heróis sejam para limitar o número de variáveis que
balanceados igualmente entre eles. devem ser balanceadas.
-Trabalhar com a programação para
obter um protótipo digital funcional o
mais rápido possível.
-Criar um sistema que permita que as
variáveis sejam facilmente alteradas e
testadas na mecânica do jogo.
-Continuar a discutir ideias de
superpoderes até os recursos principais
serem prototipados e aprovados.
Durante o ciclo de desenvolvi- Alta Baixo 3 -Treinar pelo menos 2 pessoas para
mento de 2 anos, alguns manipular tarefas específicas do projeto.
funcionários podem sair da -Reservar um tempo para a contratação
empresa. e treinamento de novas pessoas no
meio do projeto.
-Dedicar-se à criação de um ambiente
de trabalho positivo para aumentar a
retenção de funcionários.
-Estar alerta para qualquer mudança
repentina nos hábitos de trabalho dos
funcionários para poder identificar
pessoas insatisfeitas e aumentar sua
satisfação antes de elas começarem a
procurar outro emprego.
-Exigir que as pessoas documentem o
trabalho que estão fazendo e examinar
todos os assets no sistema de controle
de código-fonte no fim de cada dia.
A arte conceitual inicial do jogo Baixa Alto 4 - A arte conceitual deve se basear no
pode não descrever exatamente a documento de design de personagens
aparência dos personagens de fornecido pelo licenciador.
Unidade de Justiça. -O feedback do licenciador deve ser
implementado rapidamente até que ele
esteja satisfeito com os desenhos
conceituais.
-Assegurar que os artistas tenham
acesso a toda a arte conceitual
disponível de personagens do filme.
Figura A.4 Análise de risco de Unidade de Justiça.
pacto sobre os riscos, principalmente se for uma tecnologia nova com a qual
ninguém na equipe tenha trabalhado antes.
A.2.3 Definição dos requisitos

A fase de requisitos de Unidade de Justiça começa aproximadamente após a
gerência sênior aprovar a documentação conceitual e os protótipos. Eles de-
404 Apêndice A
ram feedback sobre os personagens e o cenário e também algumas sugestões

de como os poderes dos super-heróis podem ser balanceados. A equipe inte-
grará esse feedback ao jogo durante a fase de requisitos. Nesse momento, ela
começará a definir particularidades do jogo – inclusive o conjunto básico de
recursos, uma lista dos assets de arte necessários e um cronograma estimado
da entrega de produtos. O produtor também criará um planejamento detalha-
do para o projeto e trabalhará junto aos líderes para determinar quanto tempo,
dinheiro e pessoas são necessários para o jogo ser concluído. Consulte o Capí-
tulo 15 para obter mais informações sobre a definição de requisitos. A Figura
A.5 é uma visão geral da fase de requisitos de Unidade de Justiça.
Etapa Recursos Cronograma geral Est. de início Est. de fim Tarefas

Definição dos Designer líder 1-2 semanas 7 de janeiro 18 de janeiro Os recursos básicos do
recursos do jogo de 2008 de 2008 jogo são definidos. Os
recursos secundários e
terciários também.
Definição dos Produtor Contínua – cada lista Defina as etapas principais
produtos das de produtos das do projeto e que produtos
etapas etapas é concluída cada uma terá de gerar.
cerca de 4 semanas Estimativas aproximadas
antes da finalização das etapas baseadas na
oficial da etapa. data de finalização
desejada.
Avaliação da Programador líder 4-6 semanas 7 de janeiro 1o de fevereiro Avalie as necessidades de
tecnologia de 2008 de 2008 tecnologia do jogo e faça
uma recomendação.
Definição de Programador líder 2-3 semanas 4 de fevereiro 15 de Defina o pipeline de
ferramentas e trabalha com de 2008 fevereiro de produção que gerará um
do pipeline outros líderes 2008 build jogável com assets
atualizados.
Criação da arte Artista líder 2-3 semanas 1o de julho de 18 de julho de Gere o conceito dos
conceitual 2008 2008 personagens e cenários
principais do jogo.
Documentação Designer líder 6-8 semanas 21 de janeiro 14 de março Documente os
de design de 2008 de 2008 recursos-chave do jogo,
inclua protótipos onde
possível.
Documentação Artista líder 6-8 semanas 21 de janeiro 14 de março Documente a aparência
artística de 2008 de 2008 artística do jogo, gere
listas de assets e escreva
instruções de como usar
as ferramentas de arte.
Documentação Programador 4-6 semanas 18 de fevereiro 14 de março Documente os padrões de
técnica líder de 2008 de 2008 codificação, o design
técnico e as instruções de
ferramentas do jogo.
Análise de risco Produtor Contínua durante a 7 de janeiro 14 de março Avalie os riscos do
fase de requisitos de 2008 de 2008 projeto, determine a
estratégia de solução,
divulgue para a equipe.
Aprovação Gerência do 2-3 meses após a 17 de março 21 de março Apresente todos os
estúdio, fase de requisitos de 2008 de 2008 principais elementos de
publicador começar. jogabilidade para a
gerência para aprovação,
incorpore seu feedback.
Figura A.5 Visão geral da fase de requisitos de Unidade de Justiça.

A fase de requisitos começará no início de janeiro de 2008 e continuará até

meados de março de 2008. Os designers estarão ocupados definindo os recur-
sos básicos do jogo. Eles passarão muito tempo criando e refinando protótipos.
A programação avaliará vários motores de jogo possíveis. Há um motor de-
senvolvido internamente que pode ser usado, mas talvez essa não seja a melhor
opção para o tipo de jogo que está sendo criado. Eles examinarão outras opções
e passarão algum tempo avaliando os recursos e ferramentas de cada uma. As
taxas de licenciamento também são algo que afetará a decisão, mas o jogo tem
um orçamento alto, portanto, esse não será o principal fator de decisão.
A equipe de arte continuará trabalhando na arte conceitual e começará
a criar a lista de assets e definir quantos assets de arte serão necessários. Isso
inclui o número de níveis, objetos, personagens e assim por diante. A lista
não será definitiva até o meio de março, mas fornecerá um conjunto básico
dos assets que serão necessários para a obtenção de um protótipo funcional
com a arte quase finalizada.
Definição dos recursos do jogo

A equipe conduzirá algumas sessões de brainstorm para conversar sobre to-
dos os recursos que podem ser incluídos em Unidade de Justiça. Além dos
recursos in-game, também serão discutidos recursos que melhorarão os con-
juntos de ferramentas e os processos de produção do jogo. O produtor orga-
nizará esses recursos em uma planilha e atribuirá categorias a eles. A equipe
discutirá cerca de 100 recursos que deseja incluir no jogo. A Figura A.6 é a
lista parcial dos recursos iniciais de Unidade de Justiça.
Categoria Recurso
Jogabilidade objetivos dinâmicos para as missões
Processo o processo de revisão da missão também deve incluir níveis multijogador
Processo estabelecer um sistema para a circulação de documentos de design e de atualizações de documentos
entre a equipe
Jogabilidade interface de usuário fácil de entender
Jogabilidade missões que possam ser jogadas novamente
Produção melhoria das questões ligadas à física para que as explosões pareçam mais realistas
Jogabilidade possibilidade do jogador personalizar a aparência dos personagens
Produção suporte à funcionalidade de recortar e colar na ferramenta de script
Figura A.6 Lista inicial de recursos de Unidade de Justiça.
O brainstorm de recursos é feito para que tudo que possa ser incluído no
jogo seja considerado e a lista seja então filtrada e os recursos priorizados. A
equipe começará o processo de priorizar os recursos pedindo a cada líder do
projeto que os classifique em uma escala de 1 a 3, com 3 sendo “mais impor-
tante” e 1 “menos importante”. Em seguida, é calculada a média dessas clas-
sificações e os recursos são ordenados do mais importante ao menos impor-
tante. A Figura A.7 é um exemplo de lista de recursos classificada e ordenada.
Os membros da equipe de produção passarão algum tempo examinan-
do essa lista juntos e refinarão ainda mais as classificações. Por exemplo, o
406 Apêndice A
designer líder pode insistir que o recurso de menor classificação (o suporte à

funcionalidade de recortar e colar da ferramenta de script) na verdade teria de
ser movido para mais acima na lista, porque economizará muito tempo dos
designers no cronograma geral de design. Esse tempo pode ser gasto melhor
no playtest e no polimento do jogo. A programação concorda que esse recurso
pode ter uma classificação mais alta, já que só serão precisos dois dias para
um programador implementar a funcionalidade.
Cada um dos recursos é examinado de maneira semelhante até todos
terem sido categorizados como “necessário”, “desejado” ou “interessante”.
O produtor tentará limitar o número de recursos incluídos na “lista de itens
necessários” para 25% da lista total de recursos. Por exemplo, se houver uma
centena de recursos na lista, o número de itens “necessários” será limitado a
aproximadamente 25. O número de recursos “desejados” deve ser de aproxi-
madamente 35% da lista e todos os outros recursos serão priorizados como
“interessantes”. Ao limitar o número de recursos que podem ser listados em
cada categoria, a equipe é forçada a considerar realmente a importância de
um recurso e gerar um conjunto de recursos básicos bem definido e gerenciá-
vel dentro do cronograma.
Categoria Recurso Prod. Arte Design Eng. QA Média

Jogabilidade objetivos dinâmicos para as missões 3 3 3 3 3 3
Processo estabelecer um sistema para a circulação de documentos de 3 3 3 3 3 3
design e de atualizações de documentos entre a equipe
Jogabilidade interface de usuário fácil de entender 3 3 3 3 3 3
Processo o processo de revisão da missão também deve incluir níveis multijogador 3 3 3 2 3 2,8
Produção melhoria das questões ligadas à física para que as explosões pareçam mais 2 3 1 3 1 2
realistas.
Jogabilidade missões que possam ser jogadas novamente 2 2 2 1 2 1,8
Jogabilidade possibilidade do jogador personalizar a aparência dos personagens 1 2 3 1 1 1,6
Produção suporte à funcionalidade de recortar e colar na ferramenta de script 1 1 3 1 1 1,4
3 = necessário
2 = desejado
1 = interessante
Figura A.7 Recursos de Unidade de Justiça classificados.
Definição de etapas e produtos

Agora que os recursos básicos foram determinados, o produtor criará uma
visão geral inicial das etapas principais a seguir:
• Primeira versão jogável

• Versão alfa
• Congelamento do código
• Versão beta
• Liberação do código
• Envio para terceiros (somente no caso da plataforma console)
Data de entrega Envio para terceiros –

desejada: Primeira versão Congelamento Liberação SOMENTE NO
Alfa Beta
13 de outubro jogável do código do código CASO
de 2009 DE CONSOLE
Prazo Console: 27 de junho de Console: 27 de setembro Console: 27 de abril Console: 27de maio Console: 27 de julho Console: 17 de
estimado 2008 de 2008 de 2009 de 2009 de 2009 agosto de 2009
PC: 25 de agosto de PC: 25 de novembro de PC: 25 de junho de PC: 25 de julho de PC: 25 de setembro PC: n/a
2008 2008 2009 2009 de 2009
Cronograma 12-18 meses antes da 8-10 meses antes da 3-4 meses antes da 2-3 meses antes da Primeiro código can- Envio do código
geral liberação do código liberação do código liberação do código liberação do código didato à liberação candidato à libe-
disponível para o QA ração pelo menos
3 semanas antes do 8-12 semanas antes
prazo final de da data de entrega
liberação. desejada.
Programação Funcionalidade inicial de Funcionalidade básica da Código concluído Código concluído, Congelamento total Código final. Se for
alguns recursos-chave mecânica do jogo incluída para todos os só correção de bugs do código. Durante rejeitado, só bugs
incluída para demonstrar para todos os recursos. recursos. Só há desse ponto em essa fase só crash específicos como
uma jogabilidade muito Os recursos funcionam correção de bugs diante. bugs podem ser solicitado pelo
básica. como projetado, mas desse momento em corrigidos. Bugs fabricante serão
podem ser ajustados e diante. Nenhum críticos podem ser corrigidos para
alterados com base em recurso novo é corrigidos com reenvio.
algum feedback. O jogo é adicionado, a menos aprovação.
executado na plataforma que seja aprovado
de hardware pretendida. pela gerência sênior.
Arte De dois a três assets de Os assets estão 40-50% Os assets estão Todos os assets de Congelamento total Arte concluída. Se
arte são criados e podem concluídos, com assets 80-90% concluídos, arte estão concluí- da arte. Nenhuma for rejeitada, só
ser vistos na build. Os provisórios ocupando o com assets provisó- dos e funcionando correção na arte, a bugs específicos
assets demonstram a resto do jogo. rios ocupando o res- no jogo. Só corre- menos que esteja como solicitado
aparência da versão final to do jogo. ções maiores de relacionada a um pelo fabricante
do jogo. bugs ocorrem desse crash bug. serão corrigidos
ponto em diante. para reenvio.
Design Os recursos básicos estão Toda a documentação de O jogo está em um Todos os assets do Congelamento total Design final. Se for
definidos; a mecânica design foi concluída. A nível 80-90% jogável. design estão do design. rejeitado, só bugs
principal do jogo tem implementação dos O feedback do concluídos e Nenhuma correção específicos como
uma documentação recursos está em playtest está sendo funcionando no no design, a menos solicitado pelo
básica e um protótipo andamento; 40-50% das incorporado. jogo. Só correções que esteja fabricante serão
jogável se possível. tarefas de produção do maiores de bugs relacionada a um corrigidos para
design estão concluídas. ocorrem desse crash bug. reenvio.
As áreas principais do ponto em diante.
jogo podem ser jogadas Ajustes menores na
como projetado. mecânica podem ser
feitos, com base no
feedback do
playtest.
Som O som do jogo foi defini- 40-50% dos efeitos sonoros O voiceover final foi Todos os assets Congelamento total Som final. Se for
do, inclusive o voiceover, estão funcionando. O gravado e incluído sonoros finais do som. rejeitado, só bugs
a música e os efeitos design do voiceover está em no jogo. A música foram incluídos e específicos como
sonoros. Exemplos estão andamento e arquivos de final também foi estão funcionando solicitado pelo
disponíveis para VO provisórios estão sendo incluída. Os efeitos no jogo. fabricante serão
demonstrar como o som gravados. Música em sonoros foram 80- corrigidos para
é abordado no jogo. processo de composição. 90% implementados. reenvio.
Localização Trabalho com o Trabalho com o fornecedor Os assets de texto e Os assets de idioma Congelamento total Localização final.
publicador para para determinar o voiceover finais são finais são integrados da localização. Se for rejeitada, só
determinar que idiomas cronograma de entrega de enviados para ao jogo. O teste bugs específicos
são necessários. Selecione assets. Envie glossários, tradução. As linguístico é concluí- como solicitado
o fornecedor de códigos de trapaça e traduções são do. Envie builds pelo fabricante
localização e envie para detonados para o concluídas e para os conselhos serão corrigidos
ele os documentos de fornecedor. Teste o pipeline devolvidas para o de classificação para reenvio.
design e a primeira versão de localização para verificar desenvolvedor para etária apropriados
jogável. Defina o pipeline se as traduções estão sendo integração. para obter a classifi-
de localização. exibidas corretamente. cação final.
Produção Os requisitos básicos e o A produção plena As localizações As localizações Todas as tarefas de Fim da produção.
planejamento do jogo são começou. Os requisitos e começaram. O foram concluídas. produção foram Só é preciso
concluídos o planejamento do jogo manual está em Só correções de concluídas. Se for gerenciar o
são totalmente concluídos processo de redação. bugs ocorrem desse necessário enviar o processo de envio.
e aprovados. No caso de Os recursos de ponto em diante. O jogo para o
trabalho com licenças, marketing estão manual foi fabricante do
todas as licenças são sendo gerados. concluído. Os console, formulários
obtidas e um processo de fornecedores de envio já estarão
aprovação é definido. externos preenchidos e
terminaram seu prontos para seguir.
trabalho. Todas as
aprovações de
licenças foram
obtidas. A equipe
de desenvolvimento
pode começar a
finalizar o projeto.
QA Teste do jogo Agora o jogo pode ser O plano de testes foi Todos os aspectos Teste dos códigos Testes continuam
comparando-o com os jogado plenamente, 100% concluído. A do jogo podem ser candidatos à sendo feitos no(s)
produtos da etapa de embora talvez sejam funcionalidade testados e liberação em busca candidato(s) a envio
primeira versão jogável necessários alguns ajustes completa do jogo corrigidos. O de crash bugs que até o jogo receber a
definidos na fase de em uma ou outra pode ser testada e playtest continua impeçam o jogo de aprovação final.
requisitos. funcionalidade. O playtest corrigida. O playtest para a equipe de ser entregue.
pode começar. Teste do continua. Pode haver design dar o
jogo comparando-o com um teste envolvendo polimento final no
os produtos da versão alfa a lista de produtos jogo.
esperados para essa etapa. da etapa de
congelamento do
código.
Figura A.8 Visão geral das etapas de Unidade de Justiça.

408 Apêndice A
Já que a equipe sabe que o jogo tem uma data de entrega fixa que é em
13 de outubro de 2009, o produtor estimará alguns prazos gerais para a con-
clusão de cada uma dessas etapas principais. Ele também dará uma definição
inicial para o conteúdo de cada etapa e posteriormente criará listas mais deta-
lhadas dos produtos das etapas. Os prazos das etapas podem mudar um pou-
co durante a pré-produção e a produção, à medida que a equipe for tendo uma
ideia melhor do progresso que está fazendo em Unidade de Justiça, mas essa
visão geral inicial das etapas dá uma boa ideia de quando cada etapa deve ser
concluída. A Figura A.8 é uma visão geral das etapas de Unidade de Justiça.
Lista de verificação dos produtos das etapas

Uma vez que as etapas gerais forem determinadas, o produtor pode come-
çar a trabalhar nos produtos específicos de cada etapa. Os produtos incluirão
detalhes mais específicos, como que recursos serão concluídos, que assets
poderão ser jogados e quantas missões serão roteirizadas. A Figura A.9 é uma
lista de verificação parcial dos produtos da etapa alfa de Unidade de Justiça.
Essas listas de produtos das etapas não estarão totalmente concluídas du-
rante a pré-produção, já que ainda haverá muitas incertezas no projeto. Du-
rante a pré-produção, o produtor começará a trabalhar nessas listas e as au-
mentará conforme o desenvolvimento progredir. Informações mais detalhadas
poderão ser adicionadas quando o produtor concluir o cronograma e o plano
de pessoal. Essas listas serão usadas pelo departamento de QA e pelo publica-
dor quando testarem a build criada na etapa. A lista é o padrão que eles usarão
para medir o progresso do jogo. Se a lista de etapas não for definida e enviada
com a build para aprovação, será difícil rastrear o trabalho que foi feito.
O objetivo é que haja uma lista de produtos totalmente definida aproxi-
madamente de quatro a seis semanas antes da criação real dos produtos. Isso
dará bastante tempo para a equipe saber o que se espera da build referente
a uma etapa, e assim os membros poderão ajustar a lista de produtos com
base no tempo restante no cronograma. Também dará ao produtor tempo para
identificar riscos à etapa e áreas onde ela pode se desviar do planejado. A
Digital Fun quer as listas definidas com algumas semanas de antecedência
para estar preparada para verificar o conteúdo de cada etapa assim que for
concluída pelo Supergame Studios.
Pipeline
O programador líder avaliará que motores funcionam melhor no jogo e pensa-
rá na melhor maneira de estruturar o pipeline de produção. Ele está pensando
em usar um motor licenciado, porque há dinheiro no orçamento e isso poupa-
rá algum tempo a longo prazo, principalmente se for usado um motor que seja
estável e estabelecido e que tenha um bom programa de suporte ao cliente.
Há algumas modificações a serem feitas no motor licenciado. O programa-
dor líder quer assegurar que o licenciador do motor forneça suporte técnico
adequado para que qualquer problema com as modificações possa ser rapida-
Unidade de Justiça
Produtos da etapa alfa para 28 de setembro de 2008
Última atualização em 29 de agosto de 2008
Níveis
- Os níveis a seguir estarão com todos os assets e o roteiro da mecânica:
*Sala de justiça
*Covil do vilão
- Os níveis a seguir terão uma geometria básica e poderão ser vistos no jogo, mas não estarão com a mecânica
roteirizada:
*Prefeitura
*Complexo de escritórios
Personagens
- Os personagens a seguir terão todos os assets:
*Bullet Point
*Montezuma
- Os personagens a seguir poderão ser vistos no jogo, mas não terão as texturas finais
*Caribou
IU
- O esquema de cores e a fonte estarão concluídos e aprovados
- O fluxo da IU será prototipado no Macromedia Flash
- Telas básicas da IU que serão implementadas e estarão funcionando:
*Tela inicial
*Tela de perfis
*Tela de opções
- A IU in-game terá uma arte provisória com a funcionalidade básica de:
*Barra de saúde
*Inventário
Som
- Pistas de VO e designs de som provisórios serão implementados para os níveis a seguir:
*Sala de justiça
*Covil do vilão
- Designs de som serão concluídos para os níveis restantes do jogo
Programação
- Ferramentas de script concluídas e funcionando
- Ferramentas de arte concluídas e funcionando
- APIs de rede serão implementadas
- Processo de build finalizado e definido
Figura A.9 Lista de verificação de produtos de uma etapa de Unidade de Justiça.
mente resolvido. Ele recebeu SDKs de cada motor que está avaliando e pedirá
a opinião do artista e do designer sobre o design de níveis e as ferramentas
de script de cada um deles (se essas ferramentas estiverem disponíveis como
parte da licença).
Uma atenção especial deve ser dada à criação de um pipeline que permi-
ta que a equipe gere facilmente builds para várias plataformas. O ideal é que
seja criado um pipeline em que os artistas só precisem inserir um conjunto
de assets para ser usado em cada plataforma, em vez de terem de inserir três
conjuntos de assets – um para a versão de PC, outro para a versão de console e
410 Apêndice A
ainda outro para a versão de celular. O programador líder investigará o melhor

modo da conversão de assets ser manipulada para cada plataforma e espera
criar uma maneira do pipeline incorporar automaticamente os assets apropria-
dos do sistema de controle de versões para o build de cada versão do jogo.
O programador líder também quer ter um processo que seja fácil de mani-
pular, de modo que as pessoas possam inserir e extrair assets sem problemas.
E quer adicionar algumas verificações que sejam executadas sempre que algo
novo for inserido na build para que erros simples possam ser corrigidos ime-
diatamente. O programador planeja fazer uma recomendação sobre a estrutura-
ção do pipeline em algum ponto da pré-produção. Quanto mais rápido tomar a
decisão, mais cedo terá uma equipe de programação trabalhando no pipeline.
Documentação
Durante a pré-produção, o Supergame Studios gerará alguma documentação
de design, de arte e técnica. O líder de QA também trabalhará em alguns
planos de playtest e começará a elaborar o plano de testes principal. Os do-
cumentos serão planos ativos e mudarão no decorrer do processo de desen-
volvimento; portanto, o produtor criará uma área no wiki da equipe para pu-
blicá-los. Essa solução fornece uma maneira fácil de atualizar os documentos,
rastrear as mudanças e divulgá-las para a equipe. Todos os interessados serão
direcionados para o wiki da equipe para obter a versão atual dos documentos.
Quando mais pessoas forem adicionadas à equipe, uma pessoa de cada área
receberá a tarefa de verificar a documentação diariamente e assegurar que
todas as alterações sejam adicionadas ao wiki.
O designer líder é que terá mais documentos para redigir e, em algum
ponto durante a pré-produção, um designer adicional entrará no projeto para
ajudar na prototipagem, no playtest e na redação da documentação. A lista
de documentos de design necessários em Unidade de Justiça deve abordar os
itens a seguir:
• IU
• Ambiente multijogador
• Histórico e diálogo dos personagens
• Pontuação
• Design das missões
• Esquema de controle
• Ações do jogador
• Enredo
• IA
• Armas, objetos especiais, power-ups
• Reconhecimento de voz
O artista líder começará a trabalhar no guia de estilo no início da pré-

-produção. As listas de assets serão geradas e incluídas nas listas de produtos
das etapas. Outro artista entrará para a equipe na pré-produção para ajudar
na prototipagem e definição dos assets a serem entregues. As listas de assets
e instruções de ferramentas não estarão totalmente concluídas no fim da pré-
-produção. A equipe de arte continuará adicionando detalhes a esses docu-
mentos no decorrer da produção. A documentação de arte que Unidade de
Justiça demanda inclui:
• Guia de estilo
• Lista de assets
O programador líder também tem um conjunto de documentos para re-

digir durante a pré-produção. À medida que mais programadores forem sen-
do adicionados à equipe, eles terão de conhecer os padrões de codificação e
como a tecnologia funciona. A lista de documentos técnicos que Unidade de
Justiça demanda inclui:
• Padrões de codificação
• Design técnico
A.2.4 Criação do planejamento do jogo

Enquanto os líderes trabalham em suas tarefas de pré-produção, o produtor
estará ocupado criando o plano do jogo. Como os outros documentos gera-
dos na pré-produção, o plano do jogo continuará a ser atualizado durante a
produção. O objetivo da criação de um plano para o jogo na pré-produção é
haver um plano inicial servindo como ponto de partida do projeto. É muito
mais fácil determinar quanto se progrediu quando há um plano contra o qual
o progresso pode ser comparado. O plano também fornece uma boa ideia das
variáveis (cronograma, recursos ou funcionalidades) que devem ser ajustadas
para os objetivos do projeto serem atingidos. Consulte o Capítulo 16 para ob-
ter mais informações sobre a criação de um plano para o jogo.
A Figura A.10 é um cronograma estimado para a fase de planejamento
de Unidade de Justiça. Esse plano detalhará o orçamento, o cronograma e a
equipe necessários para o jogo ser concluído na data de entrega de 13 de ou-
tubro de 2009. A fase de planejamento do jogo começará no início de janeiro
de 2008 e terminará em meados de março de 2008.
Estimativa inicial do cronograma

Já que Unidade de Justiça deve ser entregue em 13 de outubro de 2009, o
produtor sabe que o prazo é o fator fixo do planejamento do jogo. Ou seja, o
412 Apêndice A
Etapa Recursos Cronograma Est. de início Est. de fim Tarefas

geral
Criação do Produtor Ocorre em 7 de janeiro 14 de março Crie o cronograma do projeto com as
cronograma paralelo com a de 2008 de 2008 principais etapas e divida cada etapa em
mestre. fase de tarefas gerais de arte, design, programa-
requisitos ção e QA. Adicione seções para
localização, voiceover e outros trabalhos
terceirizados. Inclua seções para
aprovações de terceiros.
Criação de Produtor Ocorre em 7 de janeiro 14 de março Quando as equipes de design, arte e
cronogramas paralelo com a de 2008 de 2008 programação determinarem os requisitos,
dedicados para fase de crie cronogramas para as funcionalidades
funcionalidades requisitos básicas para definir o escopo, o custo e os
básicas. recursos das funcionalidades desejadas.
Determinação do Produtor Ocorre em 7 de janeiro 14 de março Faça suposições embasadas dos custos
orçamento paralelo com a de 2008 de 2008 estimados e crie um orçamento inicial.
fase de
requisitos
Determinação Produtor Ocorre em 7 de janeiro 14 de março Faça suposições embasadas das
das necessidades paralelo com a de 2008 de 2008 necessidades estimadas de pessoal e crie
de pessoal fase de um plano inicial.
requisitos
Determinação Produtor Ocorre em 7 de janeiro 14 de março Com base nas necessidades de pessoal, na
das necessidades paralelo com a de 2008 de 2008 experiência da equipe e no orçamento,
de terceirização fase de faça uma suposição embasada das áreas
requisitos do jogo que precisarão ser terceirizadas.
Pesquisa e Produtor Ocorre em 7 de janeiro 14 de março Pesquise possíveis fornecedores para ter
seleção de paralelo com a de 2008 de 2008 uma ideia de custo, qualidade e nível de
fornecedores fase de confiança.
requisitos
Aprovação Gerência do Ocorre em 17 de 21 de março Apresente o orçamento, o cronograma e o
estúdio, paralelo com a março de de 2008 plano de pessoal para a gerência para
publicador fase de 2008 aprovação.
requisitos
Figura A.10 Visão geral da fase de planejamento de Unidade de Justiça.
prazo determinará quantas pessoas serão necessárias na equipe e qual será o

orçamento do jogo. Felizmente, Unidade de Justiça tem um ciclo de desenvol-
vimento de 24 meses, portanto, o produtor tem de conseguir criar um plano
para o jogo com um cronograma e um orçamento racionais.
Ao criar o plano do jogo, o produtor notou que alguns dos recursos secun-
dários (recursos “desejados”) podem ser movidos para a lista de recursos “inte-
ressantes”. Se o jogo não tivesse uma data de entrega fixa, ele poderia criar um
cronograma definido por quando os recursos desejados seriam concluídos, ou
seja, provavelmente o jogo não estaria pronto para entrega em outubro de 2009.
O produtor começará a trabalhar no plano do jogo criando uma estimati-
va inicial do cronograma. Já que ele sabe quanto tempo cada etapa deve levar,
criará o cronograma de desenvolvimento baseando-se na data de entrega e tra-
balhando de trás para frente para calcular estimativas de quando cada etapa
deve ser concluída. Por exemplo, normalmente um projeto de console leva oito
semanas para receber a aprovação final do fabricante do console, portanto, a
versão gold master do jogo deve estar pronta para envio pelo menos oito sema-
nas antes da data de entrega. O produtor quer agendar três semanas de testes
em códigos candidatos à liberação para que a versão gold master esteja pronta
para envio a tempo. Ele agendará prazos aproximados para as etapas restantes,
continuando a trabalhar regressivamente a partir do prazo da etapa anterior.
A Figura A.11 é uma estimativa inicial do cronograma de Unidade de Justiça.
Uma vez que o produtor tiver determinado os prazos das etapas, ele esti-
mará as datas de envio dos produtos para aprovação. Também trabalhará com
os líderes do projeto para estimar os prazos de conclusão de áreas-chave do
jogo. As datas reais serão um pouco diferentes quando o produtor criar um
cronograma detalhado, mas a estimativa inicial dá uma boa ideia de quando
as tarefas devem ser executadas.
Na Figura A.11 o produtor não listou prazos específicos para a cinemá-
tica. Antes ele quer criar um cronograma mais definido para determinar se a
cinemática deve ser terceirizada. Planeja adiar a tomada dessa decisão até o
início da produção. Há tempo suficiente no cronograma de desenvolvimento
para a espera dessa decisão. Mas ele listou a cinemática como um risco ao
projeto, principalmente para continuar lembrando às pessoas que uma deci-
são tem de ser tomada sobre se a cinemática deve ou não ser terceirizada.
No caso das seções de design, arte, programação, áudio e localização, o
produtor trabalhará com o líder apropriado para estimar prazos aproximados.
O líder determinará algumas tarefas-chave que possam fornecer pontos de
dados úteis para a avaliação do progresso do projeto. Após determinarem es-
sas tarefas iniciais e avaliarem a divisão do cronograma inicial, eles poderão
planejar melhor o conteúdo de cada etapa principal.
Estrutura de divisão do trabalho

Agora o Supergame Studios tem informações suficientes sobre o projeto para
criar estruturas de divisão do trabalho (WBSs) para as tarefas principais. Eles
decidiram usar uma WBS que envolva sugestões de todas as áreas básicas da
equipe de desenvolvimento do jogo. Isso permitirá que os departamentos de
arte, programação, design e QA entendam melhor como seu trabalho afetará
os outros departamentos e vice-versa. O produtor marcará reuniões para tra-
balhar em cada WBS. A equipe acha mais fácil chamar todas as pessoas neces-
sárias e apenas pedir que listem cada tarefa que elas devem concluir em uma
determinada parte do jogo. O produtor organizará então essas tarefas e traba-
lhará com o líder apropriado para estimar quanto tempo uma tarefa pode levar.
Uma vez que a WBS estiver concluída, ele determinará onde se encontram as
dependências das tarefas e criará um cronograma mais detalhado com todas as
informações pertinentes. A Figura A.12 é uma estrutura de divisão do trabalho
para a criação de um nível de Unidade de Justiça. Nesse exemplo, todos os
departamentos têm responsabilidades para fazer um nível funcionar no jogo.
Cronograma do nível
A Figura A.13 (pág. 417) é um cronograma detalhado que o produtor criou a
partir da WBS gerada pela equipe para a build de um nível (Figura A.12). Nesse
cronograma, o produtor adicionou as dependências e recursos. Essa versão do
cronograma lhe mostrou que a arte e o design dependem muito um do outro du-
rante esse processo. Em alguns dias, ele planeja criar outra versão do cronogra-
414 Apêndice A
Nome do jogo Data estimada Notas

Idiomas: inglês, alemão, francês, italiano, espanhol
Produção
Fase conceitual concluída 21 de dezembro de 2007 Concluída antes do período de férias (24 de dezembro – 2 de janeiro de 2009)
Fase de requisitos concluída 14 de março de 2008 A fase começa no início de janeiro de 2009
Plano inicial do jogo concluído 14 de março de 2008 O produtor trabalhará nessa tarefa em paralelo com a fase de requisitos
Primeira versão jogável 27 de junho de 2008 Quando o plano inicial for aprovado, serão agendados 3 meses para a prototipagem
da mecânica principal do jogo e a criação de uma primeira versão jogável com alguns
assets que representarão a qualidade da arte e a jogabilidade finais.
Alfa 27 de setembro de 2008 O desenvolvimento das versões de console e PC deve ser feito em paralelo, com
prioridade para o console, já que seu código deve ser liberado primeiro para ser
enviado para terceiros para aprovação.
Congelamento do código 27 de abril de 2009
Beta 27 de maio de 2009
Envio para a Microsoft para pré-certificação 27 de maio de 2009
Código candidato à liberação 27 de julho de 2009 Todas as plataformas, todos os idiomas prontos.
Envio para a Microsoft para certificação 17 de agosto de 2009
Data de entrega (todas as plataformas, todos 13 de outubro de 2009 Entrega simultânea com a Europa.
os idiomas)
Aprovações
Aprovação do conceito 7 de janeiro de 2008
Aprovação dos requisitos 21 de março de 2008
Aprovação do plano do jogo 21 de março de 2008
Aprovação de licenças Contínua Teremos de aprovar os documentos de design iniciais e cada etapa principal
concluída. Eles terão 10 dias para aprovar qualquer asset que lhes for apresentado.
Aprovação do fabricante do console 28 de setembro de 2009 Temos de obter aprovação nessa data para termos 3 meses para fabricar e entregar.
Design
Produtos concluídos para a fase conceitual 21 de dezembro de 2007
Produtos concluídos para a fase de requisitos 14 de março de 2008
Documentação detalhada dos recursos do jogo 27 de junho de 2008 A redação da documentação dos recursos básicos continuará até a primeira versão
jogável estar pronta no fim de junho de 2008. Nesse momento, determinaremos que
recursos secundários devem ser documentados e implementados.
Documentos de personagens e da história concluídos 27 de setembro de 2008 Concluídos na versão alfa para que haja muito tempo para a implementação de
qualquer feedback.
Roteiros de voiceover concluídos 27 de março de 2009 O VO provisório será gravado em janeiro de 2009 para testarmos as pistas de voz e
determinarmos o volume de conteúdo que precisa ser redigido.
Missão e cenários projetados 27 de setembro de 2008 A conclusão de todos os designs de missão deve ocorrer na versão alfa. Os designs de
missão terão entregas escalonadas entre abril de 2008 e setembro de 2008 para que a
roteirização de protótipos de cada missão possa estar concluída em dezembro de 2008.
Protótipos de missão roteirizados 21 de dezembro de 2008 Todos os protótipos de arte e design devem estar concluídos no fim do ano. Isso
permitirá que o playtest e o feedback ocorram em janeiro e fevereiro de 2009. Quando
um nível passar pelo playtest, a roteirização final poderá começar.
Playtest 27 de fevereiro de 2009 Todo o playtest deve ser concluído nesse prazo. Ele começará em janeiro de 2009.
Missões finais roteirizadas 27 de maio de 2009 A roteirização final das missões deve ser concluída na versão beta. Após essa data,
feedbacks menores referentes ao roteiro poderão ser implementados. Outras
alterações serão avaliadas caso a caso.
Arte
Protótipos concluídos 5 de dezembro de 2008 Os protótipos da arte devem ser concluídos no início de dezembro para que a equipe
de design tenha todos os assets de arte necessários à conclusão do roteiro em 21 de
dezembro de 2008. A prototipagem da arte começará em abril de 2008, após a equipe
de design concluir o cenário da primeira missão.
o de junho de 2008
Nível da primeira versão jogável concluído 1 A equipe de design deve entregar o cenário do nível em 1º de maio para a equipe
de arte ter o protótipo concluído nessa data. Esse prazo dá 4 semanas para a equipe de
design roteirizar o nível e para a equipe de arte continuar polindo-o e implementar o
feedback para a data da primeira versão jogável ser atingida em 27 de junho.
Efeitos especiais concluídos 27 de abril de 2009 Os efeitos especiais provisórios devem ser concluídos na versão alfa. Todos os efeitos
especiais devem estar concluídos no congelamento do código (27 de abril) para que
os artistas possam começar a executar o polimento final da IU.
IU concluída 27 de abril de 2009 A IU provisória deve ser concluída na versão alfa. Todos os assets de arte da IU
devem estar concluídos no congelamento do código (27 de abril) para que os artistas
possam começar a executar o polimento final da IU.
Cinemática concluída 15 de julho de 2009 A cinemática provisória deve ser concluída antes da versão beta (27 de abril de
2009) e a final em 15 de julho de 2009.
Figura A.11 Estimativa de cronograma inicial de Unidade de Justiça. (Continua)

Programação
Protótipos de programação concluídos 27 de setembro de 2008 A prototipagem da nova tecnologia deve ser concluída na primeira versão jogável.
O ideal é que a primeira versão jogável seja baseada em protótipos da tecnologia.
Ferramentas de arte e design concluídas 27 de setembro de 2008 A ferramentas devem estar concluídas no máximo na versão alfa para que a equipe de
design possa testá-las, dar feedback e ter tudo funcionando para começar a roteirizar
em janeiro de 2009.
Pipeline de produção concluído 27 de setembro de 2008 O processo de build deve estar correndo sem problemas na versão alfa. Quando a
equipe atingir a versão alfa, builds diárias serão geradas automaticamente.
Todos os principais recursos da jogabilidade 27 de março de 2009 Seria bom que todos os recursos estivessem implementados um mês antes do
implementados congelamento do código para termos tempo para dar feedback ou corrigir problemas
maiores antes do congelamento total.
Congelamento do código 27 de abril de 2009 O ideal é que o código possa ser congelado nesse momento. Consultaremos o
programador líder a respeito de qualquer solicitação de recurso que ocorra após esse
prazo.
Áudio
Designs de som concluídos 19 de dezembro de 2008 O design de som usará os documentos de design das missões como base. Notas sobre
o elenco e amostras de VO também estarão prontas nesse momento. Começaremos a
gravar o VO provisório.
Protótipos de som concluídos 27 de fevereiro de 2009 A equipe responsável pelo som pode continuar trabalhando em protótipos enquanto
o roteiro passa pelo playtest. Isso lhes dará mais tempo para terminar os designs de
som na versão beta (27/5).
VO provisório gravado 30 de janeiro de 2009 Trabalharemos com a equipe de design para gravar algum VO provisório para que ele
possa ser implementado nos protótipos de níveis e nos permita dar feedback. Também
usaremos o espaço reservado como uma maneira de testar diferentes tipos de vozes e
sotaques para vários personagens.
VO final gravado 27 de abril de 2009 O VO final deve estar gravado na época de congelamento do código para que o VO
localizado possa ser gravado. Podemos agendar uma sessão de avaliação no fim de
junho de 2009 se necessário.
Música final implementada no jogo 27 de maio de 2009 Podemos terceirizar a música para um fornecedor externo. Se fizermos isso, quero que
o fornecedor faça a entrega antes desse prazo para assegurarmos que não haja atrasos.
Localização
Determinação das necessidades de localização 27 de junho de 2008 O ideal é que na época da primeira versão jogável o publicador nos informe que
idiomas deseja. Fornecedores externos serão pesquisados e um será selecionado
nessa data.
Organização de assets para tradução 27 de março de 2009 A equipe de design terá os roteiros de VO e o texto in-game concluídos nessa data.
Podemos enviar os assets em lotes para tradução se algumas áreas de texto ainda não
tiverem sido totalmente finalizadas.
Integração dos assets 27 de maio de 2009 As traduções devem estar prontas no começo de maio de 2009. O VO localizado da
cinemática precisará de algum tempo adicional para integração.
Teste de funcionalidade 27 de junho de 2009 O teste funcional começa no fim de maio.
Teste linguístico 27 de junho de 2009 O teste linguístico começa no fim de maio. Isso dará tempo para enviarmos builds
localizadas para os conselhos de classificação para certificação. O teste linguístico
deve ser concluído na versão beta.
QA
Plano de testes concluído 27 de junho de 2008 Plano inicial concluído na primeira versão jogável. O plano continuará sendo
atualizado à medida que novos documentos de design e protótipos forem concluídos.
Teste da primeira versão jogável concluído 7 de julho de 2008 A equipe de QA começará a verificar a primeira versão jogável em relação aos
produtos das etapas em 30 de junho (no dia de trabalho seguinte à primeira versão
jogável ser concluída).
Teste da versão alfa concluído 3 de outubro de 2008 A equipe de QA passará 5 dias verificando a versão alfa no que diz respeito aos
produtos das etapas.
Playtest concluído 27 de fevereiro de 2009
Primeiro código candidato à liberação enviado 27 de julho de 2009
para QA
Liberação do código 17 de agosto de 2009
Cinemática (fornecedor externo)
Entrega das especificações iniciais para o fornecedor ??? É preciso determinar se a cinemática deve ser terceirizada.
Storyboard do fornecedor ???
Animática do fornecedor ???
Corte bruto do fornecedor ???
Filme final do fornecedor (sem som) ???
Filme enviado para o designer de som ???
Filme final pronto para o jogo ???
Marketing
Build de demonstração 6 de julho de 2009 A equipe de marketing quer uma demo totalmente aprovada em 7 de agosto de 2009
para que ela possa ser incluída no disco de capa da Official Xbox Magazine. A demo
deve ser enviada pelo menos 4 semanas antes dessa data para cumprir o prazo.
Preview code para jornalistas 27 de maio de 2009 Queremos enviar a build beta como preview code.
Review code para jornalistas 17 de agosto de 2009 A build enviada para a Microsoft para aprovação final será usada no review code.
Figura A.11 Estimativa de cronograma inicial de Unidade de Justiça.

416 Apêndice A
Tarefas de arte (Covil do vilão) Duração

Cria protótipo 5 dias
Cria geometria do nível 20 dias
Adiciona texturas provisórias 3 dias
Corrige primeira rodada de bugs 3 dias
Cria objetos destrutíveis 2 dias
Adiciona texturas finais 10 dias
Cria mapa de referência do jogador 5 dias
Cria efeitos especiais 2 dias
Otimiza nível de acordo com as restrições do orçamento 5 dias
Aperfeiçoa o mapa 5 dias
Corrige rodada final de bugs 3 dias
Tarefas de design (Covil do vilão) Duração
Projeta layout inicial do nível 2 dias
Projeta roteiro inicial da missão 2 dias
Roteiriza protótipo 5 dias
Executa playtest no roteiro do protótipo 5 dias
Roteiriza primeira passagem do enredo da missão 5 dias
Roteiriza primeira passagem do enredo multijogador 2 dias
Revisa roteiro 1 dia
Roteiriza segunda passagem 5 dias
Verifica se todos os arquivos de suporte estão marcados corretamente 1 dia
Cria marcas de localização para o diálogo in-game 1 dia
Aperfeiçoa o roteiro 3 dias
Corrige rodada final de bugs 2 dias
Tarefas de som (Covil do vilão) Duração
Cria design do som 3 dias
Implementa protótipo de design do som 2 dias
Implementa feedback do protótipo 2 dias
Conclui primeira passagem de implementação do som 3 dias
Aperfeiçoa o som 2 dias
Corrige rodada final de bugs 1 dia
Tarefas de QA (Covil do vilão) Duração
Executa playtest no protótipo 1 dia
Testa navegação na geometria e terreno 7 dias
Verifica texturas 2 dias
Testa o roteiro inicial 1 dia
Testa o roteiro da segunda passagem 1 dia
Testa pela última vez toda a geometria e as texturas do nível 5 dias
Testa pela última vez o roteiro da missão 1 dia
Aprovações (Covil do vilão) Duração
Aprova layout inicial 1 dia
Aprova protótipo de arte inicial 1 dia
Aprova protótipo de design inicial 1 dia
Aprova design de som 1 dia
Aprova nível, roteiro e som finais 1 dia
Figura A.12 Estrutura de divisão do trabalho de um nível de Unidade de Justiça.

Figura A.13 Produção de nível detalhado de Unidade de Justiça.
ma que adicione mais um artista e um designer em algumas dessas tarefas para

reduzir o tempo que leva concluir um nível para o jogo. Antes, porém, precisa
discutir essa ideia com o artista líder e o designer líder para saber que tarefas
podem ser dadas a uma segunda pessoa sem afetar o trabalho dos outros.
Planilha de produção de níveis

O produtor também criará uma planilha para rastrear o progresso geral do pro-
cesso de produção de níveis. Essa planilha resume as informações contidas no
cronograma detalhado e fornece uma fonte de consulta rápida sobre o progres-
so feito em cada nível do jogo. Ela será útil para qualquer pessoa que quiser um
instantâneo rápido de onde os níveis estão no processo de produção. O produ-
tor designará um produtor associado para mantê-la atualizada diariamente. A
Figura A.14 é um exemplo desse cronograma resumido de produção de níveis.
418 Apêndice A
Geometria Término Término Término dos

Nome do nível Artista Roteirista Status de QA Notas
concluída da arte do design recursos sonoros
Sala de Justiça John Doe Jane Doe 15 de janeiro 15 de fevereiro 1o de março 15 de março Playtest concluído A data de conclusão original da
Covil do Vilão Bob Smith Betty Smith 22 de janeiro 22 de fevereiro 8 de março 22 de março Passará pelo playtest geometria seria 15 de janeiro, mas foi
em 22 de janeiro adiada para o dia 22 porque o artista
ficou alguns dias doente.
Última atualização: 17 de janeiro, 2009
Figura A.14 Planilha de rastreamento de produção de níveis de Unidade de Justiça.
Orçamento
Quando o produtor estiver criando o cronograma, ele também terá de definir
o orçamento e o plano de pessoal. Como discutido no Capítulo 16, todos esses
elementos devem ser considerados conjuntamente na criação do plano do
jogo. O orçamento deve levar em consideração quantas pessoas serão necessá-
rias, mas isso não poderá ser determinado precisamente antes do produtor ter
uma ideia de qual será o cronograma.
A Digital Fun está querendo fazer um investimento significativo na con-
clusão do jogo e reservou uma verba entre 15 e 20 milhões para o orçamento.
Esse orçamento deve incluir os custos da música licenciada, do pessoal inter-
no e de hardware, fornecedores externos, testes e o que mais estiver direta-
mente relacionado à produção do jogo. Tendo isso em mente, o produtor cria-
rá um orçamento com uma equipe bem grande para poder cumprir facilmente
os prazos das etapas que estimou anteriormente na pré-produção.
A Figura A.15 é um orçamento estimado das pessoas necessárias à cria-
ção de Unidade de Justiça. O produtor estima que até 80 pessoas sejam neces-
sárias para o jogo ser concluído a tempo. Ele terá de elaborar um plano para
adicionar mais pessoas à equipe quando a produção começar e também para
tirar pessoas do projeto à medida que a produção for chegando ao fim.
Isso dará uma estimativa de quantas pessoas serão necessárias no proje-
to. A equipe pode mudar no decorrer do trabalho, dependendo do feedback
que o produtor receber sobre o orçamento. Se lhe pedirem que reduza o orça-
mento, ele também pode decidir reduzir a quantidade de pessoas novas que
serão adicionadas à equipe de produção do jogo.
A Figura A.16 é um orçamento estimado dos outros custos de produção.
Ele também inclui os fornecedores externos do voiceover, a música, a cinemá-
tica e a localização. Há um valor significativo pelo royalty da PI de Unidade
de Justiça que deve ser incluído no orçamento de produção. O orçamento
também inclui várias taxas de licenciamento. Esta seção do orçamento pode
ser mais barata se a equipe decidir usar um motor diferente com uma taxa de
licenciamento de custo menor.
Profissionais de Produção Número Taxa mensal no de meses Custo

Produtor 1 $8.000 24 $192.000
Produtor associado 3 $6.000 18 $324.000
Profissionais de Arte
Artista 1 $10.000 24 $240.000
Artista técnico 1 $8.000 24 $192.000
Artista conceitual 2 $6.000 10 $120.000
Construtor de mundos 10 $6.000 12 $720.000
Artista de objetos 3 $6.000 8 $144.000
Artista de texturas 4 $6.000 12 $288.000
Artista de marketing 1 $6.000 12 $72.000
Animador 3 $8.000 8 $192.000
Profissionais de Programação
Animador 1 $10.000 24 $240.000
Programador de rede 2 $8.000 16 $256.000
Programador gráfico 4 $8.000 18 $576.000
Programador de IU 1 $8.000 12 $96.000
Programador de IA 4 $8.000 18 $576.000
Programador de som 1 $8.000 12 $96.000
Programador de ferramentas 3 $8.000 18 $432.000
Programador geral 5 $8.000 18 $720.000
Programador de IA 2 $8.000 12 $192.000
Profissionais de Design
Designer líder 1 $8.000 24 $192.000
Designer 4 $6.000 18 $432.000
Designer de som 1 $6.000 12 $72.000
Redator 1 $6.000 6 $36.000
Profissionais de QA
Analista líder de QA 1 $8.000 24 $192.000
Testador 20 $6.000 10 $1.200.000
Total geral 80 $7.792.000

As taxas mensais são somente um exemplo, não refletem as taxas reais
Figura A.15 Orçamento estimado dos custos de pessoal de Unidade de Justiça.
Equipe
Como discutido anteriormente, o produtor está planejando usar uma equipe
grande nesse projeto para cumprir realmente a data de entrega desejada. Se o
orçamento não for aprovado como se encontra atualmente, o produtor pode
acabar procurando alternativas mais baratas para a construção da equipe ter-
ceirizando o trabalho para a Índia ou Ásia. Por enquanto, ele manterá o máxi-
mo possível de pessoas internas, já que assim terá um controle melhor sobre o
jogo e mais flexibilidade para adicionar ou mudar recursos.
Organograma da equipe
A Figura A.17 é o organograma da equipe de Unidade de Justiça. A equipe tem
cerca de 60 pessoas e o produtor trabalhou com os líderes para determinar como
ela será organizada. Eles decidiram que uma estrutura de equipe tradicional fun-
cionará melhor, com cada líder chefiando sua área. Ou seja, o diretor artístico
gerenciará todos os artistas, os programadores gerenciarão a si próprios e assim
420 Apêndice A
por diante. Todos os líderes se reportarão diretamente ao produtor e esse terá um

produtor associado que ajudará no gerenciamento diário do ciclo de produção.
Hardware Número Taxa Custo

Computadores 80 $3.000 $240.000
Kits de desenvolvimento do console 40 $10.000 $400.000
Controladores 60 $100 $6.000
Placas gráficas 80 $300 $24.000
Software
Perforce 76 $750 $57.000
3DSMax 19 $4.000 $76.000
Photoshop 4 $600 $2.400
MS Project 5 $1.000 $5.000
Unreal Engine 3.0 1 $1.000.000 $1.000.000
Visual C++ 23 $3.000 $69.000
Taxas de licenciamento
Royalties de Unidade de Justiça 1 $500.000 $500.000
Voiceover 1 $250.000 $250.000
Música 1 $50.000 $50.000
Cinemática 1 $300.000 $300.000
Localização 4 $50.000 $200.000
Outros
Viagens 24 $1.000 $24.000
Alimentação 24 $500 $12.000
Expedição/Postagem 24 $200 $4.800
Total geral $3.220.200

As taxas são somente um exemplo, não refletem as taxas reais
Figura A.16 Orçamento estimado de outros custos de produção de Unidade de Justiça.
Os líderes também selecionarão algumas pessoas da equipe para chefiar

subgrupos dentro de cada área, para melhorar o fluxo de comunicação e reduzir
o número de subordinados diretos que terão de gerenciar. Por exemplo, o líder
de programação criará subgrupos para rede, ferramentas, IA, som e elementos
gráficos – e cada um deles será chefiado por um programador experiente.
A.2.5 Concluindo a pré-produção

O Supergame Studios terminou a pré-produção e consultará sua lista de veri-
ficação para confirmar se todas as tarefas principais dessa fase foram concluí-
das. A Figura A.18 é a lista de verificação da pré-produção.
Produtor
Produtor
associado
Programador
Artista líder Designer líder Líder de QA
líder
Construtores Programadores Testadores

Designers
de mundos de rede de QA
Artistas Programadores Verificador

Redatores
conceituais de ferramentas de requisitos
Programador Designers
Artistas técnicos
de IA de som
Programador
Animadores Roteiristas
de som
Programador
gráfico
Figura A.17 Organograma da equipe de Unidade de Justiça.
Lista de verificação da pré-produção S/N Notas

Conceito
O conceito inicial do jogo foi definido?
A plataforma e o gênero foram especificados?
A declaração da missão foi concluída?
Os elementos básicos da jogabilidade foram definidos?
O protótipo foi concluído?
A exposição do conceito está pronta para aprovação?
Todos os stakeholders aprovaram o conceito?
O lançamento do projeto foi agendado?
Requisitos do jogo
Os recursos que “devem entrar”, “queríamos que entrassem” e “seria bom ter” foram definidos?
As restrições foram definidas e solucionadas nos conjuntos de recursos?
As etapas e produtos foram definidos?
A tecnologia foi avaliada em relação ao conjunto de recursos desejado?
As ferramentas e o pipeline foram definidos?
A documentação básica do design foi concluída?
A documentação técnica básica foi concluída?
Todos os stakeholders aprovaram os requisitos do jogo?
Planejamento do jogo
O orçamento foi concluído?
O cronograma inicial foi concluído?
O plano inicial de pessoal foi concluído?
Os membros da equipe primária aprovaram o cronograma e o plano de pessoal?
Todos os stakeholders aprovaram o planejamento do jogo?
Figura A.18 Lista de verificação da pré-produção.

422 Apêndice A
A.3 Produção técnica
Durante a fase de pré-produção, o produtor tomou algumas decisões sobre

como serão manipulados o voiceover, a música e a captura de movimentos
durante a produção. Ele vai terceirizar essas partes do projeto, mas elas ainda
terão de ser organizadas e agendadas dentro do ciclo de produção. O voiceo-
ver terá de ser gerenciado cuidadosamente, já que há muitos diálogos a serem
gravados e os atores do filme também dublarão os personagens do jogo.
A música-tema do filme será usada no jogo, portanto, a Digital Fun traba-
lhará com o estúdio do filme em um contrato de licenciamento. O Supergame
Studios está contratando um compositor para criar música original baseada
no tema, então o produtor terá de agendar isso para que toda a música esteja
pronta na versão beta.
O Supergame Studios quer capturar vários movimentos de combate dos
super-heróis, principalmente os que envolvem interação entre duas pessoas.
Movimentos de voo e de alguns dos outros superpoderes também serão gra-
vados para os animadores terem uma boa base para construir as animações.
Uma vez que o fornecedor de captura de movimentos for selecionado, o pro-
dutor pedirá ao produtor associado que trabalhe com o animador para geren-
ciar o processo de captura. Os Capítulos 10, 11, 12 e 13 contêm mais detalhes
sobre a produção técnica.
A.3.1 Voiceover
As necessidades de voiceover de Unidade de Justiça são grandes. Há cin-
co personagens principais e 30 secundários que terão diálogos gravados. O
projetista e o designer de som estimam que haverá cerca de 100.000 linhas
de diálogo. A sessão de gravação inicial levará várias semanas e um tempo
adicional será necessário para sessões de seleção do material.
O produtor começou a planejar as necessidades de voiceover na pré-pro-
dução. Ele criou um cronograma estimado de quando as principais tarefas de
voiceover devem ser concluídas durante o desenvolvimento. A Figura A.19 é
um cronograma estimado da conclusão do voiceover de Unidade de Justiça.
A tomada de voiceover foi agendada para abril de 2009. Ela foi agendada
o mais tarde possível no ciclo de desenvolvimento para a equipe de design e
de som ter mais tempo para polir o roteiro e determinar precisamente as ne-
cessidades de voiceover. O designer de som já implementou grande parte do
voiceover provisório, portanto, o produtor está confiante de que as pistas de
voiceover funcionarão como esperado no jogo. Além disso, já que as pistas de
voiceover provisório com os nomes de arquivo corretos já foram implementa-
das, o designer de som poderá inserir os arquivos de voiceover finais no jogo
sem muitos problemas. Se o voiceover provisório ainda não tivesse sido in-
tegrado ao jogo, as sessões de gravação teriam de ocorrer muito mais cedo na
produção para haver mais tempo para a verificação dos arquivos de voiceover
e a execução de qualquer alteração necessária.

Diálogo inicial escrito Redator 30 de janeiro de 2009
VO provisório gravado Designer de som 30 de janeiro de 2009
Envio de pedidos de orçamento para os estúdios de som Produtor 27 de fevereiro de 2009
Reserva de tempo para a sessão de gravação de VO Produtor 13 de março de 2009
Diálogo escrito atualizado Redator 27 de fevereiro de 2009
VO provisório adicional gravado Designer de som 27 de fevereiro de 2009
Teste com atores Estúdio de som 10 de abril de 2009
Escalação de atores Redator/Produtor/ 10 de abril de 2009
Designer de som
Diálogo final escrito Redator 27 de março de 2009
Diálogo gravado Redator/Produtor/ 27 de abril de 2009
Designer de som
Diálogo processado e pronto para a equipe de desenvolvimento Designer de som 20 de maio de 2009
Figura A.19 Cronograma estimado de voiceover para Unidade de Justiça.
O produtor pesquisa vários fornecedores de voiceover e lhes dá infor-

mações para fazerem uma proposta. A Figura A.20 é o exemplo de uma pro-
posta parcialmente concluída que será enviada aos fornecedores externos que
o produtor está considerando para Unidade de Justiça. Ele trabalha com o
projetista e o designer de som para obter uma contagem exata de personagens
e linhas para inserir na proposta.
O produtor seleciona o estúdio de gravação de voiceover que será usado
em Unidade de Justiça. Ele seleciona intencionalmente um fornecedor ba-
seado em Los Angeles que tenha experiência em trabalhar com vozes de cele-
bridades, já que isso tornará muito mais fácil agendar o tempo dos atores do
filme que também dublarão os personagens no jogo.
O estúdio solicita um conjunto de notas de atuação de todos os persona-
gens principais e secundários do filme. Embora os personagens principais já
tenham sido selecionados, é útil que haja resumos dos papéis para os atores
examinarem quando chegarem à sessão de gravação. Notas de atuação são
redigidas para os personagens secundários contendo a imagem do persona-
gem, o enredo e o histórico, informações sobre como a voz do personagem
deve soar e alguns exemplos de diálogo que os atores podem gravar durante
o processo de teste.
O estúdio de gravação começa o processo de registro de atuações em mar-
ço de 2009 para que as seleções finais possam ser feitas em meados de abril
de 2009. O Supergame Studios recebe um conjunto de arquivos de áudio para
examinar contendo cada personagem que terá de ser dublado no jogo. Já que
está tentando reduzir o custo com os atores de voiceover, o estúdio está selecio-
nando atores que consigam dublar distintamente três personagens diferentes. A
Figura A.21 é um exemplo das notas de atuação usadas em Unidade de Justiça.
O fornecedor reserva a sessão de gravação para o final de abril de 2009.
A sessão levará algumas semanas porque há muitos diálogos a serem grava-
dos. O fornecedor de voiceover manipulará a reserva e o agendamento dos
atores da maneira mais eficiente que puder para concluir a gravação o mais
rápido possível. As celebridades são agendadas antes, já que sua disponibili-
dade tem prioridade sobre qualquer outro ator.
Enquanto o fornecedor está organizando a sessão de gravação, o Superga-
me Studios está trabalhando no roteiro final de voiceover. O redator organiza
424 Apêndice A
todo o diálogo de voiceover em uma planilha e o examina com o designer e o

produtor. Já que a sessão de gravação está ocorrendo tão perto do fim do ciclo
de produção, só há tempo para uma única sessão. Uma sessão de seleção de
três dias é agendada para algumas semanas depois, mas, se possível, o produ-
tor quer evitá-la para economizar tempo e dinheiro. A Figura A.22 é a planilha
de voiceover que será usada em Unidade de Justiça.
Assets de voiceover
Alguma celebridade será usada? Inclua os nomes das Sim, os atores que fazem os personagens principais no filme também
celebridades na coluna “Notas” da tabela. farão suas vozes no jogo.
Sindicalizados ou não sindicalizados (versão em inglês) Sindicalizados
Profundidade de bits (ex: 8 bits, 16 bits etc.) 16 bits
Taxa de amostragem (ex: 22 kHz, 44 kHz) 44 kHz
Canais (mono/estéreo/5.1) Dolby 5.1
Processamento requerido. Liste qualquer efeito especial Edições básicas de estalos e cliques, nomes de arquivo de acordo com o
necessário. sistema de nomenclatura de arquivos fornecido pelo desenvolvedor.
Processamento requerido. Liste qualquer efeito especial Edições básicas de estalos e cliques, nomes de arquivo de acordo com o
necessário. sistema de nomenclatura de arquivos fornecido pelo desenvolvedor.
Masculino/
Personagem No estimado de linhas Idade Notas
Feminino
Bullet Point 5.000 M 25 É preciso contratar o ator que está
desempenhando esse papel no
filme.
Melanie Colie 5.000 F 26 É preciso contratar o ator que está
filme.
Caribou 3.000 M 24 É preciso contratar o ator que está

filme.
Professora 1.000 F 65 A atriz deve falar chinês e inglês.

Também pode fazer a voz de outros
personagens do jogo.
Sam 1.000 M 21 Ator também pode fazer a voz de

outros personagens do jogo.
Mulher 1 50 F No meio dos Essa atriz fará a voz de 3
quarenta personagens.
Mulher 2 75 F No início dos A voz é feita pela mesma atriz que

quarenta faz a Mulher 1.
Homem 1 50 M No meio dos Esse ator fará a voz de 3
quarenta persongens.
Homem 2 75 M No meio dos A voz é feita pelo mesmo ator que
trinta faz o Homem 1.
Figura A.20 Proposta de voiceover de Unidade de Justiça.

Nome Rainha do Gelo (nome real: Melanie Cole)
Histórico Nascida em 1979, Melanie cresceu em Virginia Beach, VA. Seu pai era arquiteto e sua mãe
trabalhava como recepcionista. Aluna mediana, Melanie estudou no Tidewater Community
College durante dois anos, antes de mudar para a Old Dominion University, onde se formou
em História em 2002. Os pais de Melanie morreram em 2004, quando sua sensibilidade se
manifestou. A rajada glacial destruiu três casas, matando sete pessoas. Horroriza-
da, Melanie fugiu, mas acabou sendo presa pela polícia. Mais tarde, nesse mesmo dia, seu
poder se manifestou novamente, destruindo a delegacia e matando vários policiais. Bullet Point
e Sensei foram chamados e conseguiram imobilizar Melanie. Ela foi levada para Masada,
onde a Divisão de Justiça pôde treiná-la no uso de seus poderes. Desde então, Melanie
aprendeu a controlar sua sensibilidade e se mostrou um membro valioso da Divisão de Justiça.
Personalidade Melanie é extremamente discreta e tem dificuldade para travar relações duradouras com as
pessoas. Embora tenha lutado ao lado de outros membros da Divisão de Justiça por dois anos,
ainda os chama por seus codinomes e evita se socializar fora do trabalho. Os membros da
Divisão de Justiça brincam dizendo que sua arma ofensiva mais poderosa é o olhar gélido. Ela
ainda sofre por sua família e sente um profundo remorso pelas vidas que tirou, mesmo sabendo
que as mortes foram acidentais. Apesar das centenas de horas de treinamento, Melanie teme
perder o controle de seus poderes, o que resultaria em mais mortes de inocentes.
Voz A voz de Melanie é baixa e firme. Ela só levanta a voz quando pune ou discorda de alguém.
Com frequência soa astuta ou condescendente, principalmente ao explicar algo para outras
pessoas, e pode parecer insensível ao dar más notícias. Fala inglês sem sotaque carregado.
Referências Gillian Anderson (Arquivo X)

Exemplo de diálogo “É realmente muito ruim, mas não é problema nosso. Estamos aqui para prender Zomborg e
isso é tudo em que estou interessada em conversar.”
“Que parte de ‘imediatamente’ você não entendeu? Você já estava sendo esperado. Entre lá e
faça seu trabalho.” “Não tenho tempo para lidar com isso. A Divisão também não tem.
Aguente ou desista.”
Figura A.21 Notas de atuação de Unidade de Justiça.

426 Apêndice A
Linha no Personagem Português Nível Tipo SfX Contexto Direção de voz Nome do arquivo
1 Vilão 13 Estamos na van, chefe. 1 Abertura Estática Os vilões estão tentando fugir da Séria 01_vil13_01.wav
Vamos despistar a polícia da missão de rádio polícia após roubarem um artefato
na interestadual. do museu.
2 Bullet Point Sam, eles estão fugindo! 1 Objetivo Bullet Point estava monitorando a Séria, voz alta 01_bp_01.wav
conversa no rádio e sabe o que os
vilões estão planejando.
3 Sam Eu os interceptarei. 1 Objetivo Sam recebeu o relatório de Séria, calma 01_sam_01.wav
Bullet Point e interceptará os
vilões na estrada.
4 Civil 3 Ajudem-me! 1 Personagem Esse civil foi atingido pelos vilões Assustada, 01_c3_01.wav
não jogador quando estavam tentando escapar. gritando
5 Sam Você ficará bem. Chamei 1 Cinemática Sam para de perseguir os vilões e Suave 01_sam-02.wav
a ambulância. ajuda o civil ferido.
Figura A.22 Planilha de voiceover de Unidade de Justiça.
O redator e o designer de som participarão da sessão de gravação. Um

diretor de VO profissional foi contratado para dirigir os atores de voiceover,
mas é útil o redator e o designer de som estarem no local para o caso de ha-
ver alguma alteração no roteiro ou um novo diálogo ter de ser escrito. Eles
também podem dar conselhos para o diretor e os atores sobre o contexto das
linhas do roteiro de VO e verificar se os desempenhos funcionam bem ao
serem implementados no jogo. E estarão disponíveis para selecionar as toma-
das que desejam para cada leitura de linha, o que economizará algum tempo
do fornecedor no processo de edição. Em vez de editar todos os arquivos de
VO, o fornecedor poderá se concentrar apenas na edição dos arquivos de alta
qualidade que serão usados no jogo. O fornecedor só é responsável pela edi-
ção básica dos arquivos – removendo artefatos sonoros e nomeando todos os
arquivos segundo a convenção de nomenclatura estabelecida. O designer de
som fará qualquer edição especial adicional.
O designer de som conseguiu implementar cerca de 90% das gravações
de VO provisório para testar a inserção das pistas de VO e ver como funcio-
nam no jogo. Já que ele conseguiu implementar a maioria dos arquivos de VO
provisórios, será fácil copiar os arquivos finais de VO para a build.
Quando as tarefas de voiceover terminarem, o produtor examinará a
lista da Figura A.23 para confirmar se tem tudo que é necessário para o voi-
ceover do jogo. Consulte o Capítulo 10 para ver mais informações sobre a
produção do voiceover.
A.3.2 Música
O Supergame Studios planeja licenciar o tema musical principal que está sen-
do usado no filme para que ele possa ser usado na sequência de abertura do
jogo. Acham que essa será uma boa maneira de vincular filme e jogo. Ela é a
única faixa que será licenciada e será tocada na sequência de abertura. O estú-
dio está contratando um compositor para criar música original para o resto do
jogo. O compositor poderá compor variações do tema principal se isso fizer
parte do design musical.
Lista de verificação do voiceover S/N Notas

Pré-produção
O design inicial do voiceover foi concluído?
As descrições iniciais dos personagens foram redigidas?
O cronograma inicial do voiceover foi criado?
O orçamento inicial do voiceover foi criado?
Notas de escalação de atores foram redigidas com exemplos de diálogos?
Solicitações de proposta foram enviadas para os estúdios de som?
Produção
O estúdio de som foi selecionado?
Foi tomada uma decisão final sobre o uso de atores sindicalizados ou não sindicalizados?
As datas de gravação foram reservadas provisoriamente com o estúdio de som?
O roteiro inicial de voiceover foi redigido?
O diálogo de espaço reservado foi gravado e implementado no jogo?
Testes foram agendadas?
Vozes de celebridades estão sendo usadas? Elas estarão disponíveis nas datas provisórias?
O roteiro de voiceover foi definido?
Os arquivos de teste estão disponíveis para os atores escutarem?
O guia de pronúncia foi definido?
O diretor de voz foi reservado para a sessão?
Pós-produção
O estúdio de som editou as tomadas finais de arquivos de áudio?
Os arquivos foram entregues no formato correto? Versões descompactadas estão
disponíveis?
O roteiro de voiceover foi atualizado com alterações feitas no diálogo e linhas
alternativas?
Figura A.23 Lista de verificação do voiceover.
O designer de som criou um plano para a música em fins de junho de

2008, quando a etapa de entrega da primeira versão jogável foi concluída. A
Figura A.24 é um cronograma estimado das tarefas de criação de música que
devem ser executadas. O designer quer enviar solicitações de proposta no fim
de setembro de 2008 e receber os arquivos musicais finais no fim de abril de
2009. O compositor entregará versões iniciais de toda a música alguns meses
antes de abril de 2009 para que haja mais tempo para a música ser verificada
no jogo e um retorno ser dado sobre as alterações que devem ser feitas.
O designer pode integrar algumas trilhas musicais existentes à build jo-
gável para ter uma ideia do tipo de música que funcionará melhor no jogo. Ele
enviará essas trilhas musicais de teste junto com as informações da proposta
para que os compositores tenham uma noção de como a música deve soar. A
Figura A.25 é um exemplo de proposta musical para Unidade de Justiça.
428 Apêndice A
Tarefa Recurso Prazo Cronograma geral

Design musical determinado Designer de som/ 27 de junho de 2008 Antes da produção começar
Programador de som
Produtos musicais iniciais definidos Designer de som 27 de setembro de 2008 Versão alfa
Enviar solicitações de proposta para compositores Produtor 27 de setembro de 2008 Versão alfa
(no caso de trabalho com compositores externos)
Começar a negociar direitos musicais Produtor 27 de setembro de 2008 Versão alfa
(no caso de licenciamento da música)
Adicionar música provisória ao jogo Designer de som 27 de dezembro de 2008 Antes da versão alfa
Primeiro conjunto de composições entregue pelo Compositor 27 de março de 2009 Cerca de 2-3 meses antes da versão
compositor beta
Compositor entrega mixagens musicais finais Compositor 27 de abril de 2009 Cerca de 1 mês antes da versão beta
Obter todos os direitos musicais finais Produtor 27 de abril de 2009 Cerca de 1 mês antes da versão beta
Implementar toda a música final no jogo Designer de som 27 de maio de 2009 Versão beta
Figura A.24 Cronograma estimado da música de Unidade de Justiça.
Quando o compositor for selecionado, receberá uma build jogável e a

documentação que descreve os personagens, o cenário e a história. Isso o aju-
dará a ter uma ideia melhor do jogo e a melhorar a qualidade da música que
estiver compondo. O compositor e o designer de som definirão um processo
em que o último examinará cada faixa quando o compositor tiver uma versão
inicial pronta. Quando o compositor receber o feedback, criará outra versão
para verificação. O designer de som e o compositor acham que geralmente
dois ciclos de feedback fornecem os resultados desejados para a música.
Como ocorreu com os arquivos de voiceover, o designer de som integrou
arquivos musicais provisórios ao jogo para que eles possam ser facilmente
substituídos pelos arquivos musicais finais quando esses estiverem prontos.
Já que o jogo dá suporte à música adaptativa, o designer de som também usará
esses arquivos musicais provisórios para testar como ela está funcionando.
Após o compositor entregar os arquivos musicais finais em abril de 2009,
o designer de som descobriu que precisa de mais um minuto de música para
ser repetida em segundo plano em algumas telas da IU. Ele decidiu reeditar
uma das faixas que o compositor enviou em vez de lhe pedir para criar um
minuto de música adicional. Já que o compositor tinha um contrato de traba-
lho por encomenda com o Supergame Studios, não há problemas no designer
de som reeditar ou usar amostras de qualquer arquivo musical entregue pelo
compositor. Na verdade, quando o compositor entrega os arquivos musicais,
ele também entrega todos os arquivos-fonte para o caso do estúdio precisar ou
querer fazer alguma alteração. Consulte o Capítulo 11 para obter mais infor-
mações sobre a música.
Necessidades Duração Detalhes da mixagem Local Formato Notas Prazo

musicais
Tema principal 120 Mixagem full Dolby 5.1 IU .wav Tema principal do jogo, será ouvido sempre 27 de
segundos que os jogadores estiverem nas telas de shell março, 2009
da IU. Deve combinar com a atmosfera
descrita no documento “Visão Musical”
incluso.
Loop 1 30 Estéreo In-game .wav Ouvido no jogo como peça musical repetida 27 de
segundos de segundo plano. Deve combinar com a março, 2009
atmosfera descrita no documento “Visão
Musical” incluso.
Loop 2 30 Estéreo In-game .wav Ouvido no jogo como peça musical repetida 27 de
segundos de segundo plano. Deve combinar com a março, 2009
atmosfera descrita no documento “Visão
Musical” incluso.
Cinemática 180 Estéreo, música + voiceover + Cinemática .wav Entrega das mixagens finais de música, VO e 27 de
inicial segundos efeitos sonoros, a música efeitos sonoros em trilhas separadas. abril, 2009
deve ser sincronizada com as
imagens.
Cinemática 60 Estéreo, só música, música de Cinemática .wav Entrega das mixagens finais de música, VO e 27 de
intermediária segundos segundo plano, sem efeitos sonoros em trilhas separadas. abril, 2009
sincronização.
Cinemática final 90 Estéreo, música + voiceover + Cinemática .wav Entrega das mixagens finais de música, VO e 27 de
segundos efeitos sonoros, a música efeitos sonoros em trilhas separadas. abril, 2009
deve ser sincronizada com
as imagens.
Figura A.25 Proposta musical estimada de Unidade de Justiça.
A.3.3 Captura de movimentos

O artista líder e os animadores querem capturar alguns dos movimentos de
combate e de poderes dos super-heróis para fazê-los parecer mais realistas no
jogo. O produtor trabalhará com o animador líder para criar um cronograma
de conclusão da captura de movimentos de Unidade de Justiça. O animador
gostaria de ter a tomada de captura de movimentos em outubro de 2008 para
ter tempo suficiente para melhorar os movimentos, incorporá-los aos perso-
nagens e colocá-los em ação no jogo. A Figura A.26 é um cronograma estima-
do da conclusão da captura de movimentos de Unidade de Justiça.
Tarefa Recurso Datas Cronograma geral

Lista inicial de captura de movimentos concluída Animador 27 de setembro de 2008 Cerca de 6-8 meses antes da versão beta.
Envio de solicitações de proposta para estúdio de Produtor 27 de julho de 2008 Cerca de 12-14 meses antes da versão beta.
captura de movimentos
Reserva de tempo para a tomada de captura de Produtor 27 de agosto de 2008 Assim que você tiver escolhido um estúdio.
movimentos
Teste de atores Estúdio de captura 15 de setembro de 2008 Cerca de 4-6 semanas antes da tomada de captura
de movimentos de movimentos (mais tempo no caso de escalação
de uma grande quantidade de atores).
Escalação de atores Animador/ 15 de setembro de 2008 Cerca de 4-6 semanas antes da tomada de captura
Produtor de movimentos (mais tempo no caso de escalação
de uma grande quantidade de atores).
Lista final de tomadas de captura de movimentos Animador 13 de outubro de 2008 Cerca de 2 semanas antes da tomada de captura de
concluída movimentos agendados.
Captura de movimentos gravada Animador/ 27 de outubro de 2008 Cerca de 6-8 meses antes da versão beta (mais tem-
Produtor po no caso de gravação de uma grande quantidade
de movimentos ou de movimentos complexos).
Movimentos processados e implementados no jogo Animador 20 de maio de 2009 Cerca de 1 semana antes da versão beta.
Figura A.26 Cronograma estimado de captura de movimentos de Unidade de Justiça.

430 Apêndice A
Uma vez que o produtor souber qual vai ser o cronograma de captura de
movimentos, ele trabalhará com o animador líder para criar uma solicitação
de proposta para enviar para estúdios de captura de movimentos. O animador
líder será o principal ponto de contato com o fornecedor de captura de mo-
vimentos quando eles começarem a trabalhar, portanto, o produtor quer que
ele seja envolvido na seleção do fornecedor. A Figura A.27 é a proposta de
captura de movimentos de Unidade de Justiça.
Após o fornecedor ser selecionado, o animador líder trabalhará com ele
para marcar uma hora para a tomada de captura de movimentos. Provavel-
mente, a tomada demorará cerca de três dias, já que há menos de 200 movi-
mentos a serem capturados. O animador participará da tomada de movimen-
tos e trabalhará com o diretor e os atores para obter os movimentos desejados
e selecionar as tomadas que deseja de cada movimento.
Antes da captura, o animador líder preparará a planilha final detalhando
todos os movimentos que serão gravados. A Figura A.28 é um exemplo de
planilha de captura de movimentos usada em Unidade de Justiça. O fornece-
dor fará algumas edições básicas nos arquivos de captura de movimentos e os
nomeará de acordo com a convenção de nomenclatura estabelecida. Quando
forem entregues para o animador, ele editará os movimentos e os incorporará
aos modelos dos personagens.
Formato de
Movimentos necessários no de movimentos Duração média Looping entrega de
arquivos
Movimentos de uma pessoa (masculino) 600 movimentos 2 segundos Looping necessário Arquivos .trc ou
para 500 .htr, totalmente
movimentos processados e
editados.
Movimentos de uma pessoa (feminino) 600 movimentos 2 segundos Looping necessário Arquivos .trc ou
para 500 .htr, totalmente
movimentos processados e
editados.
Movimentos de duas pessoas (masculino e 50 movimentos 5 segundos Sem looping Arquivos .trc ou
feminino) .htr, totalmente
processados e
editados.
Movimentos de duas pessoas (masculino e 20 movimentos 5 segundos Sem looping Arquivos .trc ou
feminino) .htr, totalmente
processados e
editados.
Serviço Quantidade Notas

Atores necessários 1 homem, 2 mulheres Precisará de escalação e pré-produção
Acessórios Mesa, cadeira, bola de basquete, rifle, Usados para o movimento de uma única
pistola pessoa
Prazos Tomada inicial agendada para 27 de Arquivos editados e processados a serem
outubro de 2008. devolvidos em lotes, com a entrega final
ocorrendo em 27 de novembro de 2008.
Figura A.27 Proposta de captura de movimentos de Unidade de Justiça.

Quando as tarefas de captura de movimentos terminarem, o produtor

examinará a lista de verificação da Figura A.29 para confirmar se tem tudo
que é necessário para a captura de movimentos do jogo. Consulte o Capítulo
12 para ver mais informações sobre captura de movimentos.
A.3.4 Marketing e RP
A Digital Fun designou um gerente de produto para trabalhar com o Superga-
me Studios no plano de marketing de Unidade de Justiça. O gerente de pro-
duto pretende visitar o estúdio após a etapa alfa ser concluída em setembro
de 2008. Quando o jogo estiver na versão alfa, a Digital Fun terá alguma noção
de como será a jogabilidade e ideias de um gancho de marketing para o jogo.
O bom nesse jogo é que ele se beneficiará do marketing do filme. No entanto,
a Digital Fun também quer construir uma campanha de marketing exclusiva
para enfatizar que esse é um jogo de qualidade e não apenas algo que foi criado
às pressas para aproveitar o lançamento do filme.
Durante a visita ao Supergame Studios, o gerente de produto passará
algum tempo discutindo ideias de marketing com a equipe. Ele tem algumas
opiniões sobre o jogo e uma boa ideia de como deve ser manipulada a manei-
ra do jogador controlar um super-herói voador. Também trabalhará junto ao
produtor para criar um cronograma de recursos de marketing. Esse cronogra-
ma detalhará que tipos de recursos o departamento de marketing precisará di-
retamente da equipe de produção e quando eles esperam recebê-los. A Figura
A.30 é um exemplo de lista de recursos de marketing.
ID no Posição base Descrição do movimento Duração Personagem Nome do arquivo

1 De pé Caminhando (movimento padrão) 3 segundos Bullet Point bp_up_walk_1
2 De pé Caminhando (movimento padrão) 3 segundos Montezuma mz_up_walk_1
3 Abaixado Caminhada abaixado, ao investigar 3 segundos Bullet Point bp_cr_walk_1
furtivamente
4 Abaixado Caminhada abaixado, ao investigar 3 segundos Montezuma mz_cr_walk_1
furtivamente
Figura A.28 Planilha de mocap para Unidade de Justiça.

432 Apêndice A
Lista de verificação da captura de movimentos S/N Notas

PRÉ-PRODUÇÃO
O design inicial da lista de animações foi concluído?
As animações da captura de movimentos foram identificadas?
O cronograma inicial da captura de movimentos foi criado?
O orçamento inicial da captura de movimentos foi criado?
Solicitações de proposta foram enviadas para os estúdios de captura de
movimentos?
PRODUÇÃO
O estúdio de captura de movimentos foi selecionado?
As datas foram reservadas provisoriamente com o estúdio de captura de
movimentos?
A lista inicial de captura de movimentos foi preparada?
A seleção final de atores foi concluída? Eles estarão disponíveis nas datas
provisórias?
SESSÃO DE GRAVAÇÃO
A lista de captura de movimentos foi definida?
O diretor foi reservado para a sessão?
PÓS-PRODUÇÃO
O estúdio de captura de movimentos editou as tomadas finais dos arquivos de
animação?
Os arquivos foram entregues no formato correto? Versões descompactadas
estão disponíveis?
Figura A.29 Lista de verificação da captura de movimentos.
O gerente de produto também discutirá os planos para uma demo, os tes-

tes do grupo de foco e a press tour. As demandas de marketing começarão no
início de 2009, quando o jogo for anunciado oficialmente na D.I.C.E. O produ-
tor e o gerente de produto estarão em contato regularmente no decorrer da pro-
dução. Consulte o Capítulo 13 para obter mais informações sobre marketing.
Nome do produto Data estimada Notas

Localizações: francês, alemão, espanhol, italiano
Produção
Primeira versão jogável 27 de junho de 2008 Quando o plano inicial for aprovado, serão
agendados 3 meses para a prototipagem da
mecânica principal do jogo e a criação de uma
primeira versão jogável com alguns assets que
representarão a qualidade da arte e a jogabilidade
finais.
Alfa 27 de setembro de 2008 O desenvolvimento das versões de console e PC
deve ser feito em paralelo, com prioridade para o
console, já que seu código deve ser liberado
primeiro para ser enviado para terceiros para
aprovação.
Congelamento do código 27 de abril de 2009
Beta 27 de maio de 2009
Envio para pré-certificação da Microsoft 27 de maio de 2009
Código candidato à liberação 27 de julho de 2009 Todas as plataformas, todos os idiomas prontos.
Envio para certificação da Microsoft 17 de agosto de 2009
Data de entrega (todas as plataformas, todos os idiomas) 13 de outubro de 2009 Entrega simultânea com a Europa.
Caixa e documentos
Primeiro rascunho do manual 22 de junho de 2009
Primeiro rascunho do manual com screen shots 10 de julho de 2009 É preciso assegurar que haja tempo suficiente para
o manual ser traduzido.
Layout da caixa e do manual para aprovação do 20 de julho de 2009 O marketing precisa que o desenvolvedor confirme
desenvolvedor se os recursos, logotipos e ícones corretos estão na
embalagem.
Recursos de marketing
Build de demonstração 6 de julho de 2009 A equipe de marketing quer uma demo totalmente
aprovada em 7 de agosto de 2009 para que ela
possa ser incluída no disco de capa da Official Xbox
Magazine. A demo deve ser enviada pelo menos 4
semanas antes dessa data para cumprir o prazo.
Primeira demonstração do código para jornalistas 27 de maio de 2009 Queremos enviar a build beta como preview code.
Nova demonstração do código para jornalistas 17 de agosto de 2009 A build enviada para a Microsoft para aprovação
final será usada no review code.
Cronograma de etapas de produção 21 de dezembro de 2007 O marketing dará um feedback sobre os
documentos conceituais iniciais.
Resumo do design 21 de dezembro de 2007 O marketing dará um feedback sobre os
documentos conceituais iniciais.
Lista de recursos 21 de dezembro de 2007 Precisaremos de listas de funcionalidades
atualizadas no decorrer do projeto para assegurar
que as funcionalidades sejam promovidas
corretamente.
Recursos do jogo para o site (som, arte) 1o de fevereiro de 2009 O site será lançado em meados de março de 2009.
Esboços conceituais do jogo 1o de fevereiro de 2009 Necessários para o site.
Imagens de alta resolução (para capas de revistas) 1o de março de 2009 Devemos publicar artigos sobre o jogo no começo
de março.
Filmagem da jogabilidade (para trailers) 1o de março de 2009 Filmagem inicial necessária em março.
Precisaremos de filmagens adicionais em agosto de
2009 para comerciais de TV. O marketing pode
gravar essas filmagens se receber uma build recente
do jogo com códigos de trapaça ativados.
Códigos de trapaça e detonados Varia Precisaremos deles sempre que o jogo for enviado
para previews e reviews e sempre que um evento de
RP for agendado.
Screen shots Screen shots devem ser distribuídas À medida que o jogo for chegando perto da data
a cada etapa de entrega, solicitaremos screen shots semanais.
Entrevistas com desenvolvedores Quando necessário Serão principalmente entrevistas por e-mail.
Press tour nacional Press tour agendada para setembro
de 2009
Press tour internacional Press tour agendada para setembro
de 2009
Figura A.30 Recursos de marketing necessários para Unidade de Justiça.

434 Apêndice A
A.4 Produção
Nesse ponto do desenvolvimento, o Supergame Studios está totalmente na

fase de produção de Unidade de Justiça. Os líderes criaram um plano deta-
lhado na pré-produção e todos os membros da equipe têm uma boa ideia das
tarefas que devem executar e do tempo para isso. O produtor assegurará que
todos tenham o que precisam para concluir seu trabalho. Ele também lidará
com qualquer problema que surgir para ser resolvido. A equipe de produção
interna está fazendo progressos no jogo e os fornecedores externos começa-
ram a pré-produção de seu trabalho. Os Capítulos 17, 18, 19, 20 e 21 contêm
informações mais detalhadas sobre a fase de produção.
A.4.1 Ciclo de produção

O produtor estará em contato próximo com o publicador em todo o ciclo de
produção e fornecerá relatórios de status semanais. A cada dois meses, ele
participará de uma revisão interna do projeto para avaliação do status do jogo.
A Digital Fun também se reunirá com o licenciador para obter qualquer apro-
vação que for necessária para Unidade de Justiça. Consulte o Capítulo 17 para
obter mais informações sobre o ciclo de produção.
Todo mês, o Supergame Studios entregará uma etapa concluída para a
Digital Fun, como definido em contrato. O publicador levará cerca de cinco
dias para examinar cada etapa e a aprovará como está ou dará um feedback
com uma lista de mudanças necessárias. Quando o estúdio implementar esse
feedback, enviará a build referente à etapa para a Digital Fun novamente para
aprovação. A Digital Fun costuma aprovar as etapas no primeiro envio, mas
pode haver algum feedback sobre itens que ela queira implementados no pró-
ximo envio de uma etapa.
A.4.2 Processo de build

Durante a pré-produção, o programador líder definiu um processo de build
automatizado. Ele designou um gerente de dados como encarregado pelo pro-
cesso de build e pela criação dos scripts e processos adicionais que forem ne-
cessários para tornar a automação eficiente. Por exemplo, o gerente de dados
criou roteiros que verificam extensões, nomes e tamanhos de arquivos. Essas
verificações impedirão que alguém prejudique a build se inserir um arquivo
que não siga os padrões estabelecidos.
Quando houver uma primeira build jogável, o gerente de dados come-
çará a criar builds diariamente. Ele instruirá o processo para começar a com-
pilar e criar a build à meia-noite para que uma nova build esteja pronta de
manhã bem cedo. No começo do dia, antes da nova build ser examinada por
outra pessoa, o gerente de dados verificará os logs para saber se há algum
erro que precise ser corrigido. Se não houver nenhum erro a ser corrigido, ele
executará a build para verificar se está sendo carregada e então a arquivará na
rede. Em seguida, o programador líder decidirá se essa build deve ser enviada
para o departamento de QA para testes.
Uma vez que o jogo chegar à versão beta, o departamento de QA solicitará
que novas builds estejam disponíveis duas vezes por semana – às segundas e
quintas. Isso lhes dará tempo suficiente entre as builds para verificar correções
e procurar novos bugs. Se precisarem de builds com uma frequência maior,
farão uma solicitação ao programador líder com um dia de antecedência.
Quando as pessoas inserirem assets e códigos na build, elas terão de en-
viar um e-mail à lista de correspondência “notas de build”. Esse e-mail deve
detalhar o que foi inserido – novos códigos e assets ou correções de bugs que
terão de ser verificadas pelo departamento de QA. As notas de build são úteis
para o departamento de QA porque detalham as alterações que foram feitas
na versão atual da build. Quando as etapas principais forem entregues para
o publicador para aprovação, o produtor redigirá um conjunto completo de
notas de build detalhando todas as alterações e melhorias importantes que
foram feitas desde a última etapa. A Digital Fun usará essas notas de build
para comparar o que foi entregue na etapa com o que foi definido no contrato
(consulte a Figura A.9 para ver um exemplo de como o produto de uma etapa
é definido no contrato). Consulte o Capítulo 10 para obter mais informações
sobre a criação de builds.
A.4.3 Localização
Inicialmente, Unidade de Justiça será localizado para o francês, alemão, ita-
liano e espanhol. As versões localizadas serão distribuídas junto com a versão
em inglês. Uma única versão master multilíngue será criada com todos os
idiomas. O produtor começou a planejar as localizações na pré-produção para
assegurar que elas não atrasem a versão final do jogo.
Ele preparou um formulário de visão geral dos assets para ser enviado
para possíveis fornecedores para que estes pudessem criar uma proposta. Sua
intenção era encontrar um fornecedor que pudesse manipular o trabalho de
localização para todos os idiomas em vez de encontrar um fornecedor separado
para localizar cada idioma. Se conseguisse encontrar um fornecedor mutilíngue
de alta qualidade, o processo de localização seria mais dinâmico e eficiente, já
que seu produtor associado só terá de lidar com um fornecedor. Um dos forne-
cedores traduziu o roteiro do primeiro filme de Unidade de Justiça, portanto,
conhece bem a franquia e já tem uma ideia de como alguns dos termos especí-
ficos do mundo do jogo devem ser traduzidos. A Figura A.31 é o formulário de
visão geral de assets de Unidade de Justiça. Durante a pré-produção, o produtor
teve de fazer suposições de quantos assets teriam de ser localizados; logo, ele
fez uma estimativa para mais em todas as áreas. Esse formulário de visão geral
foi enviado para os fornecedores para eles poderem começar a criar uma pro-
posta. O produtor examinou todas as propostas e selecionou o fornecedor que
conhece a franquia Unidade de Justiça. Havia propostas mais em conta, mas os
fornecedores não eram tão experientes. Além disso, ele pediu referências dos
fornecedores antes de tomar a decisão final e viu que muitas pessoas deram
boas referências do fornecedor que foi sua primeira escolha.
436 Apêndice A
Assets de texto in-game no Formato de distribuição Comentários

Número de palavras a serem traduzidas 100.000 Arquivo .xls Teremos de usar em Unidade de Justiça os mesmos
glossários localizados que foram usados em
traduções anteriores para assegurar que os nomes
dos personagens e termos especiais sejam
traduzidos corretamente.
Número de palavras a serem traduzidas 0 n/a O desenvolvedor manipulará toda a integração do
texto.
Assets de arte
Número de palavras dos assets de arte 0
Número de assets de arte a serem modificados 0
Assets de voiceover
Número de palavras do roteiro de VO 10.000 Arquivo .xls
Número de arquivos de VO a serem modificados 600 Arquivos .wav
(qualidade de DVD)
Número de personagens a serem gravados 25 Enviaremos detalhes completos dos personagens
em breve. A estimativa são 15 masculinos e 10
femininos.
Tempo total de VO (min:seg.) 60 min.
Assets cinemáticos
Número de palavras do roteiro cinematográfico 500
Número de cinemáticas a serem modificadas 2 Só as seções inicial e final contêm VO que tem que
ser localizado.
Número de personagens a serem gravados 3 2 masculinos, 1 feminino – teremos que usar as
celebridades aprovadas equivalentes aos atores
americanos.
Tempo total de diálogo com sincronia labial 30 seg. O desenvolvedor fornecerá os códigos de tempo
exatos.
Tempo total de cenas de corte (min:seg) 5 min.

Materiais impressos
Número de palavras do manual 5.000
Número de elementos gráficos do manual a serem 10 Teremos de fornecer screen shots traduzidas e
modificados localizadas para substituir as capturas em inglês
do manual.
Número de palavras do texto da caixa 500
Número de elementos gráficos da caixa a serem 0 O marketing fornecerá os logotipos traduzidos
modificados apropriados. As capturas de tela da caixa não
exibirão elementos da IU, exibirão a tela inteira.
Outros materiais impressos n/a
Figura A.31 Formulário de visão geral de assets de Unidade de Justiça.
O produtor designou um produtor associado (PA) para gerenciar o pro-

cesso de localização. Ele começará a criar um kit de localização inicial em
março de 2009. O PA desenvolverá um sistema para o envio de lotes de texto a
serem traduzidos e integrados ao jogo. O primeiro lote será enviado no fim de
março de 2009 e o último alguns dias depois da criação da versão beta.
O texto é organizado em uma planilha para os tradutores. A Figura A.32
é uma planilha de tradução para Unidade de Justiça. Esse é o formato mais
fácil para os tradutores manipularem. Já que a equipe de produção planejou
as localizações antecipadamente, conseguiu criar um pipeline de localização
para pegar facilmente todo o texto que precisa ser traduzido e organizá-lo em
uma planilha. As traduções são adicionadas à planilha e a equipe tem uma
ferramenta que permite extraí-las e integrá-las facilmente ao jogo.
Local Português Francês Notas

AI(M01) Um policial foi atingido! A missão falhou. Un officier de police a été abattu. Echec de la Condição de falha
mission. que aparece como
mensagem pop-up no
jogo
M01 1. Desarmar o sistema de segurança 1. Désactivez le système de sécurité Aparece na tela de
inicialização, na tela de
instalação e no menu
“iniciar” in-game
Install Deseja que um atalho seja inserido na área de Souhaitez-vous créer um raccourci pour pouvoir Aparece durante a
trabalho para inicializar o jogo? lancer le jeu à partir du bureau? instalação
Uninstall Deseja remover a pasta do jogo inteira? Isso Souhaitez-vous effacer complètement le dossier du Aparece durante a
excluirá a pasta em que o jogo foi instalado e jeu? Cela détruira l’ensemble du dossier dans instalação
tudo que houver nela. lequel le jeu a été installé et les éléments qu’il
contenait.
Equip A principal arma atribuída é a M4, com uma Les armes assignées sont le M4, comme arme Aparece na tela de
pistola de 9 mm como arma secundária. principale, et le pistolet 9 mm, comme arme ajuda de seleção de
Flashbangs são fornecidas para deter inimigos e secondaire. Les grenades aveuglantes sont fournies equipamentos
um sensor de batimento cardíaco deve ajudar a pour éliminer les ennemis. Le détecteur cardiaque
localizá-los. devrait vous aider à les localiser.
IFF(M03) um guarda un garde Aparece quando
apontamos a mira
para um personagem
Figura A.32 Planilha de tradução de Unidade de Justiça.
O processo de integração de todos os idiomas leva cerca de uma semana

e as primeiras builds totalmente localizadas ficam prontas perto do fim de
junho de 2009. Isso dá tempo suficiente para fazer algumas semanas de testes
de funcionalidades e linguístico. O teste linguístico também é manipulado
pelo fornecedor de localização. Os testadores linguísticos preenchem um for-
mulário de relatório de erros e o Supergame Studios será responsável por
implementar as correções. A Figura A.33 é um exemplo de relatório de erros
de Unidade de Justiça. Os testes levam cerca de cinco semanas e envolvem
três ciclos de teste. Quando terminam, o trabalho de localização é examinado
e aprovado pelo publicador, a Digital Fun.
Status
Erro no Idioma Local do jogo Descrição do erro Texto incorreto Texto correto
do erro
2 Alemão IU – Menu de opções Favor usar letras minúsculas. Schritt Nach Rechts Schritt nach rechts Fechado
4 Alemão IU – Menu de opções Texto não traduzido. Usar Item Gegenstand benutzen Corrigido
Figura A.33 Exemplo de relatório de erros linguísticos de Unidade de Justiça.
Concluindo a localização
Consulte o Capítulo 21 para obter mais informações sobre a localização. O
Supergame Studios terminou a localização e consultou sua lista de verificação
para confirmar se todas as tarefas principais dessa fase foram concluídas. A Fi-
gura A.34 (que se encontra mais adiante) é a lista de verificação da localização.
A.4.4 Cenários da produção

A seguir temos dois problemas de produção que podem ocorrer durante o
ciclo de desenvolvimento de Unidade de Justiça. Consulte o Capítulo 18 para
ver algumas técnicas de produção específicas que lidam com esses cenários.
438 Apêndice A
Cenário 1
A equipe de design está pronta para começar a roteirizar os níveis, mas aca-
bou de descobrir que a funcionalidade “recortar e colar” ainda não foi adi-
cionada à ferramenta. Esse é um recurso que a programação concordou em
adicionar à ferramenta de script porque economizaria muito tempo dos de-
signers. O designer líder baseou o cronograma de design na suposição de que
essa funcionalidade estaria na ferramenta. Já que ela não foi implementada,
os designers vão precisar de 25% mais tempo para roteirizar os níveis do jogo.
Isso terá um impacto negativo sobre o cronograma geral e definitivamente
prejudicará a data de entrega. O designer líder levou esse problema ao produ-
tor para poderem achar uma solução.
Primeiro o produtor vai até o programador líder para saber quando essa
funcionalidade pode ser adicionada e quem está disponível para fazer o tra-
balho. O programador líder quer que a equipe de programação termine um
trabalho no motor gráfico antes e então diz que terá um programador disponí-
vel que poderá concluir o recurso em dois dias. Ele estima que a ferramenta
estará com o recurso funcionando em cerca de duas semanas.
O produtor passa essa informação para o designer líder e eles examinam
o cronograma de design para ver se há alguma outra tarefa em que os desig-
ners possam trabalhar enquanto isso. O designer líder decide manter metade
da equipe de design nas tarefas originais de roteirização de níveis e designa
outros designers para trabalharem no próximo conjunto de detonados de mis-
sões. Isso lhes permite ficar dentro do prazo, porque quando a ferramenta de
script estiver finalmente pronta para uso, mais de metade das missões estarão
projetadas em papel e prontas para a roteirização do protótipo. O designer
líder também solicita um designer adicional no projeto. Se ele puder trazer
alguém para o projeto durante os últimos seis meses de produção, o tempo
perdido será facilmente compensado.
Cenário 2
Unidade de Justiça está na versão beta e recebeu todos os assets. O jogo está
dentro do prazo de envio final para a Microsoft. A Digital Fun informa o Su-
pergame Studios que está perto de finalizar um contrato com a Coca-Cola para
uma propaganda in-game. Eles querem adicionar placas de Coca-Cola a todos
os níveis do jogo e possivelmente construir uma barraca de refrigerantes onde
o personagem possa comprar Coca-Cola para melhorar a saúde. Esse contrato
vale 1 milhão de dólares em pagamento por propaganda para a Digital Fun;
portanto, eles estão se esforçando para fechá-lo, mas, por outro lado, também
precisam que o jogo seja entregue a tempo.
Pré-produção S/N Notas

O jogo dá suporte ao padrão Unicode?
Todos os assets de idioma estão em um diretório do jogo que pode ser
facilmente acessado?
A funcionalidade de fornecimento de legendas será necessária?
Teclados localizados são suportados para as entradas do jogador?
Vários idiomas serão incluídos no mesmo CD-ROM?
As versões localizadas serão compatíveis com o ambiente multijogador?
As caixas da IU se redimensionam para acomodar strings de texto de tamanhos
diferentes?
Algum software adicional é necessário para ajudar na localização?
Os formatos internacionais de moeda e data/hora são suportados?
Um sistema de controle de versões foi definido para as localizações?
O pipeline de localização foi definido?
Outras considerações
As versões localizadas virão simultaneamente com a versão em inglês?
O formulário de visão geral de assets foi preenchido e enviado para o tradutor?
Os idiomas foram determinados?
Fornecedores externos produzirão as localizações?
Se for esse caso, os pedidos de propostas estão preparados?
O orçamento foi concluído e aprovado?
O nível de localização foi determinado para cada idioma?
O cronograma geral foi criado e finalizado?
Há recursos de desenvolvimento disponíveis para as localizações?
Foi determinado um método para a integração de assets de texto?
Foi determinado um método para a integração de assets de VO?
Foi determinado um pipeline para a correção de bugs?
As medidas apropriadas foram tomadas para atendermos todas as juntas de
classificação internacionais?
Os publicadores pertinentes foram informados sobre as versões localizadas?
O suporte ao padrão PAL será necessário para versões de console?
Há hardware suficiente para o teste de funcionalidades e linguístico?
Pré-produção
Um cronograma detalhado foi concluído e divulgado para a equipe?
O documento de visão geral da localização foi enviado para o coordenador da
localização ou para os tradutores?
Todos os documentos de pré-produção do jogo foram enviados para o coordenador
da localização ou para os tradutores?
A última build em inglês do jogo foi enviada para os tradutores?
Os assets de texto foram organizados para tradução e enviados para o coordenador
da localização?
O roteiro de voiceover e as notas de escalação de personagens foram enviados para o
coordenador da localização?
Os arquivos finais de voiceover em inglês foram enviados para o coordenador da
localização?
Todos os assets de arte a serem localizados foram enviados para o coordenador da
localização?
Todos os assets cinemáticos e códigos de tempo foram organizados e enviados para
o tradutor?
As traduções dos assets de texto foram concluídas?
Os arquivos de voiceover localizados foram gravados e processados?
Os arquivos de texto e voiceover foram integrados?
A cinemática foi localizada?
As versões localizadas foram enviadas para a junta de classificação apropriada para
aprovação?
A versão master contém demos de outros jogos que foram solicitadas pelo
departamento de marketing?
O teste de funcionalidades foi concluído?
Todos os bugs de funcionalidades foram corrigidos e o código do jogo foi liberado?
O teste linguístico foi concluído?
Todos os erros linguísticos foram corrigidos e a aprovação final do idioma foi dada?
As versões localizadas foram enviadas para o replicador (PC) ou submetidas ao
publicador (consoles e celulares)?
Encerramento
O texto da caixa e do manual foi enviado para tradução?
Uma demo localizada terá de ser produzida?
Capturas de tela localizadas foram obtidas para o manual e a caixa?
Um kit de fechamento foi criado para todas as versões localizadas?
Todos os patches foram localizados e disponibilizados? (Se necessário)
Figura A.34 Lista de verificação de localização de Unidade de Justiça.

440 Apêndice A
O produtor discute essa solicitação com os líderes da equipe para ter

uma ideia do volume de trabalho necessário à implementação do recurso da
forma como foi pedido pelo departamento de marketing. A inclusão de placas
de Coca-Cola em todos os níveis não levará muito tempo se a equipe conse-
guir obter assets de arte pré-renderizados com o tamanho e a resolução cor-
retos. Se a equipe tiver de criar as placas, essa atividade ocupará um artista
durante cinco dias. Além disso, a equipe precisa de instruções específicas
de onde as placas devem ser inseridas no nível e informações sobre quantas
placas têm que ser adicionadas a cada nível. O cronograma está bem aperta-
do, portanto, mesmo os poucos dias necessários à implementação de algumas
placas 2D no nível afetarão o grau de polimento do jogo.
A solicitação de construção de uma máquina de Coca-Cola para melho-
ria da saúde é mais complexa e afetaria os cronogramas de programação, arte
e design. Já que o jogo ainda não inclui uma bebida para melhoria da saúde,
a equipe de design terá de passar algum tempo prototipando essa funciona-
lidade para saber como fazê-la funcionar. A equipe de arte tem de prototipar
algumas máquinas e refrigerantes e a de programação tem de definir como
implementar a funcionalidade no jogo. Além disso, o animador pode ter de
criar uma nova animação de ingestão de um líquido e uma animação de um
personagem tirando um refrigerante da máquina.
Após examinar o cronograma de produção, o produtor redige uma pro-
posta detalhando a solicitação de recurso e o impacto que sua implementação
teria sobre o jogo. Ele conclui que a inclusão de três placas 2D em dez níveis,
embora inoportuna, poderia ser executada sem colocar o cronograma em ris-
co. Seria necessário:
• O publicador ou o licenciador enviar os assets de arte finais das placas

até 27 de junho de 2009. A equipe de arte não tem tempo no cronograma
para criar esses assets.
• Obter a aprovação final da inserção do logotipo in-game em cinco dias
úteis. O Supergame Studios terá uma build pronta para verificação perto
de 15 de julho de 2009 e precisará das aprovações rapidamente para que
o jogo esteja pronto para o processo de liberação do código.
Se a equipe não receber os assets de arte apropriados do licenciador, é

muito provável que essa solicitação de recurso não possa ser acomodada. Nesse
caso, talvez a equipe de produção tenha de criar uma tela inicial com o logotipo
da Coca-Cola para ser exibida enquanto as missões estão sendo carregadas.
A solicitação de uma máquina de refrigerante não pode ser acomodada
nesse momento sem causar um grande impacto sobre a jogabilidade e o cro-
nograma. Esse é um recurso que pode ser considerado na próxima versão do
jogo. Se ele for absolutamente obrigatório, a equipe terá de cortar uma missão
do jogo para liberar um designer e terá de tirar um programador e um artista
da correção de bugs. Ou seja, o jogo final não ficará tão polido como deveria e
não haverá garantias de que a máquina de refrigerante funcionará corretamen-
te e será concluída a tempo. Dados todos esses fatores, o produtor recomenda
veementemente que esse recurso não seja incluído agora.
A.4.5 Concluindo a produção

O Supergame Studios terminou a produção e consultará sua lista de verifica-
ção para confirmar se todas as tarefas principais dessa fase foram concluídas.
A Figura A.35 é a lista de verificação da produção.
Lista de verificação da produção S/N Notas

O planejamento do jogo foi claramente comunicado para a equipe?
O planejamento do jogo está em um local publicamente acessível?
O planejamento pode ser facilmente atualizado com mudanças feitas pelo produtor?
Todas as pessoas da equipe têm os recursos necessários para fazer seu trabalho?
Há um processo definido para o controle do crescimento desenfreado?
A avaliação de risco está ocorrendo regularmente em toda a produção?
Há um processo definido para o gerenciamento das dependências de tarefas?
Há um planejamento de jogo no qual o rastreamento do progresso possa se basear?
Há um processo definido para o produtor rastrear o progresso de todas as tarefas?
O progresso é afixado em áreas visíveis nas salas da equipe?
Conclusão de tarefas
Cada tarefa tem critérios de saída claramente definidos?
Esses critérios de saída estão publicamente disponíveis para a equipe?
Todos os stakeholders estão de acordo sobre quais serão os critérios de saída?
Figura A.35 Lista de verificação da fase de produção de Unidade de Justiça.
A.5 Fase de testes
O Supergame Studios começará os testes com uma pequena equipe de QA na

época da versão alfa. O líder de QA está no projeto desde a pré-produção, por-
tanto, conhece o jogo e redigiu o plano e outros documentos de testes. Mais
alguns testadores serão adicionados à equipe a cada etapa principal, e quando
o jogo atingir o congelamento do código, haverá uma equipe completa de QA
verificando-o. O processo de liberação do código foi agendado para começar
em 27 de julho de 2009 e o jogo foi agendado para estar com o código libera-
do em 17 de agosto de 2009. Os testes são abordados com mais detalhes nos
Capítulos 22 e 23.
A.5.1 Testes
O líder de QA criou um plano de testes detalhado para o jogo. Ele trabalhou
em um esboço do plano na pré-produção. À medida que o desenvolvimen-
to avançar, o plano será atualizado. Os documentos de design são a base do
plano de testes e ele também trabalhou com os outros líderes para esclarecer
qualquer dúvida sobre o jogo para que todos possam assumir suas responsa-
bilidades no plano.
442 Apêndice A
O líder de QA também criou uma documentação sobre como registrar

corretamente os bugs do jogo. Ele a usará para treinar novos testadores de
QA. Além disso, trabalhará com os líderes para estabelecer um processo bem
definido para a correção e regressão dos bugs. O processo de correção de bugs
se dará mais tranquilamente se todos entenderem como um bug é inserido no
banco de dados, corrigido pela equipe e devolvido para o departamento de
QA para a correção ser verificada. Para concluir, ele está envolvido em um
trabalho com o produtor para a criação de listas de verificação das etapas.
Essas são as listas de verificação de QA usadas na comparação entre as etapas
e a lista de produtos do produtor. A equipe de QA precisa saber o que é espe-
rado em cada etapa para então confirmar se o jogo atendeu ou não todos os re-
quisitos. A execução de testes é abordada com mais detalhes no Capítulo 22.
O plano de testes é redigido em duas partes. A parte um é um plano
criado no formato aprovado/reprovado. Isso é útil para verificarmos se os ní-
veis estão sendo carregados corretamente, se a música e o som estão sendo
reproduzidos de maneira adequada e assim por diante. A Figura A.36 é um
exemplo de plano de testes do tipo aprovado/reprovado para Unidade de Jus-
tiça. A parte dois é criada em formato de lista de verificação e é útil na verifi-
cação das várias combinações de personagens, armas e níveis de dificuldade
do jogo. A Figura A.37 é um exemplo de plano de testes do tipo lista de veri-
ficação para Unidade de Justiça.
A.5.2 Código candidato à liberação

O processo de liberação do código é abordado com mais detalhes no Capítulo
23. A data de 27 de julho de 2009 é quando o produtor planeja ter o primeiro
código candidato à liberação (CRC) pronto para verificação. Só o CRC da ver-
são de console precisa estar pronto nessa data, porque ele ainda terá de passar
pelo processo de envio para o fabricante do console. O CRC de PCs não pre-
cisa estar pronto para verificações finais antes de 25 de setembro de 2009. No
entanto, onde possível, o produtor está tentando manter todas as plataformas
seguindo um cronograma semelhante para que as pessoas possam descansar
um pouco e então começar a trabalhar em outro projeto.
O departamento de QA tem um plano e um processo de testes completo
definido para os códigos candidatos à liberação. Esse processo verifica o có-
digo, os assets e a jogabilidade da versão gold master candidata. Ele também
verifica se os idiomas corretos estão sendo exibidos para as localizações, se as
informações de suporte ao cliente adequadas estão sendo listadas em todas as
versões e se todo o texto legal e outras informações estão certas. A Figura A.38
é uma lista de verificação de liberação do código que detalha as principais
áreas que o departamento de QA revisará nesse processo.
A equipe envia o primeiro CRC em 27 de julho de 2009. Primeiro o de-
partamento de QA verifica se todas as áreas principais do jogo estão sendo
carregadas e se as localizações estão corretas. A equipe de QA começa então
Figura A.36 Plano de testes do tipo aprovado/reprovado de Unidade de Justiça.
a percorrer o plano de testes. Enquanto os testadores de QA verificam o jogo

em relação ao plano de testes, o analista de QA associado começa a verificar a
documentação, o texto legal, o logotipo e as informações de suporte ao cliente
para ver se tudo está tudo correto e pronto para prosseguir. Todos esses itens
estão em ordem, portanto, a equipe de QA continuará seguindo o plano.
Enquanto o departamento de QA verifica o CRC, a equipe de produção
continua verificando a build. O produtor bloqueou a entrada no controle de
fontes para impedir que alguém insira uma alteração ou correção de bug no
jogo. A equipe de produção não está planejando fazer nenhuma correção de
bug adicional, a menos que o departamento de QA encontre um problema no
código candidato à liberação. Um dos designers encontrou alguns pequenos
erros de digitação em parte do texto in-game e quer implementar o texto correto
se um segundo código candidato à liberação for necessário. O produtor aprovou
essa correção, já que ela é uma alteração de baixo risco em um arquivo de texto.
Os artistas encontram alguns problemas na maneira de um dos efeitos
especiais funcionar no jogo e também perguntam se podem implementar uma
correção em um segundo CRC. Após discutir o problema com os artistas e
programadores, o produtor decide não fazer essa correção. Ela é um pouco
arriscada, já que parte do código teria de ser alterada e alguns assets de arte
precisariam de atualização. Esse problema é superficial e não tem um gran-
de impacto sobre a jogabilidade, portanto, o produtor decide que é arriscado
demais fazer essa alteração em um segundo código candidato à liberação. No
444 Apêndice A
entanto, se o departamento de QA encontrar um crash bug maior no jogo que

demande uma alteração no código, o produtor considerará a solicitação de
correção do efeito especial novamente. Se de qualquer forma o código tiver
de ser alterado para a correção de um bug, talvez não seja tão arriscado imple-
mentar uma alteração para corrigir o efeito especial.
Figura A.37 Plano de testes do tipo lista de verificação para Unidade de Justiça.
No terceiro dia de testes (29 de julho de 2009), o departamento de QA en-

controu um bug maior no jogo que acha que deve ser corrigido. Embora não seja
um crash bug, ele impede o jogador de progredir no jogo. O bug é reproduzível
e a equipe de QA consegue isolar as etapas exatas para reproduzi-lo. Enquanto
investigam o bug, determinam que pelo menos 25% dos jogadores encontrarão
esse problema e que ele deve ser corrigido no jogo final. O líder de QA também
recomendou que três outros bugs sejam corrigidos agora – eles não são proble-
mas grandes, mas as alterações têm baixo risco e melhorarão a jogabilidade final.
A equipe de produção começa a trabalhar em um segundo código candi-
dato à liberação e o departamento de QA continua testando o primeiro CRC
para ver se algum outro problema é encontrado. Felizmente, eles não acham
nenhum outro problema durante as verificações de liberação do código. A
equipe leva três dias para gerar outro CRC e o envia para o laboratório de QA
em 3 de agosto de 2009. O produtor apresenta uma lista detalhada de cada al-
teração feita nos bugs para o líder de QA. O líder de QA testa essas alterações
para confirmar se as correções foram feitas e estão funcionando. Quando as
alterações são confirmadas, o departamento de QA passa a seguir o plano de
testes e a lista de verificação de liberação do código novamente.
Informações gerais A/R Notas adicionais

Todos os bugs foram corrigidos?
Todos os bugs “não corrigidos” foram aprovados?
O jogo pode ser jogado do início ao fim?
O código de trapaça foi removido?
O software de depuração foi removido?
O jogo foi aprovado em todas as áreas do plano de testes?
As verificações de compatibilidade com PCs foram concluídas?
Essa versão foi aprovada para envio para terceiros?
As classificações etárias e isenções de responsabilidade corretas estão sendo exibidas?
Aprovações de terceiros
Essa versão passou nas verificações de requisitos técnicos da Microsoft?
Essa versão passou nas verificações de requisitos técnicos da Sony?
Essa versão passou nas verificações de requisitos técnicos da Nintendo?
Localizações
O texto do jogo está sendo exibido no idioma correto?
Os voiceovers estão sendo reproduzidos no idioma correto?
Os manuais inclusos foram traduzidos corretamente?
O jogo recebeu aprovação linguística?
O texto legal e as informações de direitos autorais corretos estão sendo exibidos?
O jogo tem todas as classificações etárias necessárias?
Parte jurídica
Os licenciadores apropriados aprovaram o jogo?
Autorizações foram obtidas para todo o conteúdo licenciado (como a música)?
O jogo contém a versão correta do EULA?
As informações de garantia e suporte ao cliente estão corretas?
Embalagem
A embalagem contém informações legais e de direitos autorais?
Os logotipos e outros ícones da embalagem estão corretos?
O manual foi finalizado e aprovado?
Verificações das versões gold master
Foram procurados vírus nas versões gold master e elas foram consideradas livres de vírus?
A versão gold master é idêntica à versão gold candidata à liberação e aprovada?
A versão gold master foi instalada e verificada em hardware apropriado?
Figura A.38 Lista de verificação para liberação do código.
O segundo CRC fica em teste durante quatro dias e outro grande proble-
ma é encontrado. No fim do dia 6 de agosto de 2009, o líder de QA pede a
equipe para criar um terceiro CRC. A equipe trabalha no fim de semana para
ter o terceiro CRC pronto para testes na manhã de segunda, 10 de agosto de
2009. No terceiro CRC, a equipe de produção só trabalha nas correções espe-
cíficas solicitadas pelo departamento de QA.
O terceiro CRC entra em teste na manhã de segunda-feira. A equipe de
QA faz turnos extras para verificar o terceiro CRC o mais rápido possível. O
prazo de envio para o fabricante do console está se aproximando rapidamente
e a equipe de QA tem certeza de que o terceiro CRC estará pronto para seguir.
Trabalhando em turnos extras, o departamento de QA consegue concluir to-
das as verificações de liberação do código no fim do dia 13 de agosto de 2009.
Eles aprovam o terceiro CRC para envio.
446 Apêndice A
Cronograma de liberação do código

Para cumprir a data de entrega da versão de console em 13 de outubro de
2009, o produtor trabalha com a Microsoft e a Sony para se certificar de que
o jogo seja aprovado a tempo. Geralmente, o processo de aprovação final leva
de seis a oito semanas quando o código está relativamente livre de bugs, o
jogo não tem maiores problemas e todos os requisitos técnicos são atendidos.
O Supergame Studios tem muita experiência no trabalho em títulos de conso-
le; assim, confiam na sua habilidade em atender os requisitos técnicos e obter
aprovação do jogo em não mais do que dois envios.
A Figura A.39 é um cronograma geral de liberação do código de Unidade
de Justiça. Esse cronograma permite que o jogo seja enviado para pré-certifi-
cação, passe por dois ciclos de aprovação no processo final de certificação e
cumpra a data de entrega desejada. O envio para pré-certificação foi agendado
para 27 de maio de 2009. Nesse período, o jogo está basicamente na versão
beta e todos os requisitos técnicos foram implementados. Os fabricantes do
console verificam os requisitos técnicos e redigem um relatório detalhado
sobre o que deve ser corrigido antes do processo final de certificação. A equi-
pe recebe o relatório no início de junho, o que lhes dá bastante tempo para
implementar os feedbacks e as alterações necessárias.
Figura A.39 Cronograma de liberação do código de Unidade de Justiça.
A certificação final do fabricante do console foi agendada para 17 de

agosto de 2009. A equipe consegue enviar o jogo três dias antes, em 14 de
agosto de 2009. Isso acabou sendo bom porque eles esqueceram de enviar
o certificado de classificação de software do PEGI e a Microsoft retardou a
aprovação até o certificado ser enviado em 17 de agosto. Havia alguma proba-
bilidade da data de entrega atrasar se demorasse alguns dias para o certificado
ser enviado para a Microsoft. O produtor criou uma folga no cronograma de

envio para lidar com pequenos atrasos inesperados.
A Microsoft começa a examinar a última versão em 17 de agosto de 2009,
e após 10 dias ela é reprovada porque em algumas áreas o jogo não estava
seguindo os requisitos técnicos corretamente. Eles também encontraram um
crash bug reproduzível.
A equipe examina o relatório e investiga o crash bug. Eles levam cerca de
cinco dias para corrigir e testar o bug e fazer alguns ajustes em como os requi-
sitos técnicos são implementados no jogo. Enviam o jogo novamente em 7 de
setembro de 2009. Dessa vez, a versão é aprovada em 18 de setembro de 2009.
O jogo é enviado imediatamente para replicação e fabricação.
Já que há tempo de sobra para o replicador prensar os discos e embalar o
jogo, a data de entrega é atingida facilmente em 13 de outubro de 2009. Se o
processo de aprovação demorasse mais, o publicador teria trabalhado com o re-
plicador para reduzir o tempo do cronograma reservado para embalagem e en-
trega do jogo. Por um pagamento adicional, o publicador pode pedir ao replica-
dor que apresse o pedido e trabalhe no fim de semana – o que pode economizar
de 7 a 10 dias no cronograma. O publicador também poderia pagar custos adi-
cionais de entrega para enviar o produto para as lojas em dois dias, em vez dos
cinco a sete dias normais. Felizmente, o Supergame Studios conseguiu concluir
o jogo a tempo; logo, o publicador não precisou negociar com o distribuidor ou
fazer um pagamento adicional para enviar o jogo para as prateleiras das lojas.
A.5.3 Concluindo os testes

O Supergame Studios terminou a fase de testes e consultará sua lista de veri-
das. A Figura A.40 é a lista de verificação da fase de testes.
Lista de verificação dos testes S/N Notas

O plano de testes foi criado?
O plano de testes foi atualizado para o departamento de QA?
O plano de testes foi atualizado com qualquer alteração que tenha sido feita no
planejamento do jogo?
As etapas de testes foram consideradas no cronograma?
O software de rastreamento de bugs foi disponibilizado para os testadores e a equipe
de desenvolvimento?
Todas as áreas do jogo foram testadas?
Todos os bugs foram regredidos e fechados?
A equipe de desenvolvimento enviou um código final candidato à liberação?
Há tempo suficiente no cronograma para o departamento de QA concluir o plano de
testes no código candidato à liberação candidato?
O departamento de QA aprovou o produto para liberação do código?
Somente no caso de console: O jogo que teve o código liberado foi enviado para o
fabricante do console para aprovação?
Somente no caso de console: O fabricante do console aprovou o jogo para replicação
final?
Figura A.40 Lista de verificação da fase de testes.

448 Apêndice A
A.6 Fase de pós-produção
A pós-produção é abordada com mais detalhes nos Capítulos 24 e 25. A equipe

trabalhou muito em Unidade de Justiça e está ansiosa para descansar um pou-
co após o projeto ser concluído. No entanto, antes de tirarem férias, o produtor
quer conduzir um post-mortem e criar um kit de fechamento. Essas tarefas não
demorarão mais do que cerca de uma semana para serem executadas.
A.6.1 Post-mortem
O produtor pediu à equipe que se prepare para o post-mortem listando cinco
coisas que funcionaram e cinco que não funcionaram no projeto. Algumas
pessoas previram que haveria um post-mortem no fim do projeto e fizeram
essas anotações no decorrer do trabalho. Outras começaram a pensar nesses
itens no fim do projeto.
Cada pessoa terá uma lista um pouco diferente dos aspectos bons e ruins
– por exemplo, os artistas podem se ater mais a coisas que afetem diretamente
o ciclo de produção de arte e os programadores enfocarão os aspectos de pro-
gramação –, mas esses itens terão alguns elementos em comum. O produtor e
o produtor associado organizam os itens de todos os membros em categorias
amplas e então marcam uma reunião para discutir as informações. Cada cate-
goria é discutida durante cerca de 10 a 15 minutos. No fim da reunião, a equi-
pe seleciona três categorias que podem ser melhoradas no próximo projeto. O
produtor redige um documento resumido de lições aprendidas para essas três
categorias e o divulga para a equipe. O objetivo da equipe é se concentrar na
melhoria desses três itens no próximo projeto.
Os outros itens da lista não são considerados menos importantes, mas o
produtor achou mais eficaz se concentrar em três áreas de melhorias em um
determinado momento e não na lista inteira. Quando a equipe tiver imple-
mentado com sucesso as três primeiras lições aprendidas no projeto, o produ-
tor trabalhará com ela para divulgar as lições aprendidas nos próximos três
itens da lista. Em intervalos de alguns meses, a equipe trabalhará na integra-
ção de novas melhorias no processo de desenvolvimento. Consulte o Capítulo
24 para obter mais informações sobre post-mortem.
A.6.2 Kit de fechamento

Quando o jogo for aprovado pelos fabricantes do console e a versão gold
master para PC for concluída, o Supergame Studios terá de criar um kit de
fechamento para o projeto. Eles arquivam todo o código, os assets e a docu-
mentação e criam três cópias. Uma cópia é armazenada in loco, a outra é en-
viada para o publicador e a terceira é arquivada em um local remoto. O líder
trabalhará com o resto da equipe para concluir isso em uma semana para que
todos possam descansar antes de começar seu próximo projeto. O Capítulo
25 contém informações mais detalhadas sobre como criar kits de fechamento.
A.6.3 Concluindo a pós-produção

O Supergame Studios terminou a pós-produção e consultará sua lista de veri-
das. A Figura A.41 é a lista de verificação da pós-produção.
Lista de verificação da finalização S/N Notas

Plano de Arquivamento
O kit de fechamento foi concluído?
Aprendizado por meio da experiência

O post-mortem foi concluído?
O post-mortem foi publicado para o estúdio de desenvolvimento inteiro?
Figura A.41 Lista de verificação da pós-produção.

Apêndice B
GLOSSÁRIO
AFTRA (American Federation of Television and Radio Artists) – Sindicato

que representa jornalistas e outros artistas que trabalham na mídia de entre-
tenimento e notícias.
API (Application Programming Interface) – As APIs são conjuntos de pro-
tocolos e ferramentas para a programação de software. Software que usa a
mesma API tem uma interface de usuário semelhante.
cinemática – Filmes pré-renderizados ou in-game que fazem parte da jogabi-
lidade. São usados para dar mais realidade à história no decorrer da expe-
riência de jogar.
codec – Tecnologia de software que compacta e descompacta dados. Co-
decs específicos são usados para isso. Alguns players de mídia, como o Qui-
ck Time®, já têm codecs instalados e podem exibir qualquer dado compacta-
do com eles. Há codecs que não são incluídos automaticamente no player de
mídia e devem ser baixados e instalados.
códigos de tempo – É a cópia da hora inicial e final da cinemática para o diá-
logo do personagem poder ser sincronizado com a maior fidelidade possível
em relação aos movimentos de sua boca.
entrega simultânea – A prática de entregar as versões localizada e em inglês
simultaneamente.
ESRB (Entertainment Software Ratings Board) – Entidade nos Estados Uni-
dos que atribui classificações etárias a jogos.
estrutura de divisão do trabalho (work breakdown structure – WBS) – Pro-
cesso de gerenciamento de projetos em que tarefas grandes são divididas em
tarefas menores.
EULA (End User License Agreement) – Um contrato legal entre o publicador
e o comprador do jogo.
favorável à localização – Código de jogo que foi desenvolvido visando à cria-
ção de localizações eficientes e fáceis de fazer. Todos os aspectos que ajudam
a internacionalizar o código foram considerados, o que inclui coisas como
permitir a funcionalidade de byte duplo no mecanismo e usar ícones na in-
terface de usuário.
FIGS – Acrônimo que normalmente se refere à localização de um jogo em
francês, italiano, alemão e espanhol.
452 Apêndice B
fingerprinting – O processo de marcar a construção de um jogo com um iden-

tificador exclusivo. Isso permite que os desenvolvedores rastreiem a fonte de
qualquer build não autorizada que for replicada ou postada na Internet.
gold master – A versão final do jogo cujo código é liberado e enviado para
fabricação.
HUD (Heads Up Display) – Elementos comuns na interface de usuário de um
jogo interativo. Geralmente esses elementos indicam estatísticas do persona-
gem do jogador, como a saúde, o tempo decorrido, o status das armas e assim
por diante.
IA – Abreviação de Inteligência Artificial.
interface de usuário (IU) – Áreas do jogo em que o usuário pode inserir ou
receber informações. Por exemplo, o usuário pode selecionar um personagem
em uma lista de opções ou obter informações sobre a saúde de seu persona-
gem em um indicador da barra de saúde.
kit de fechamento – Consulte pacote de assets.
liberação do código – Termo que descreve um produto que foi totalmente
testado, teve os bugs corrigidos e é considerado pronto para entrega pelo pu-
blicador.
localização – O processo de adaptar um jogo a um país específico. Inclui a
tradução, a integração e o teste dos assets localizados.
NDA (Non-Disclosure Agreement) – Um documento legal usado para proteger
informações patenteadas.
NTSC (National Television System Committee) – As televisões dos Estados
Unidos usam padrões de exibição NTSC, ou seja, a imagem de vídeo distribui
525 linhas de resolução a 60 half-frames por segundo. Os jogos de console dos
Estados Unidos são desenvolvidos de acordo com esses padrões para serem
exibidos em televisões NTSC e outros monitores de vídeo compatíveis com o
NTSC.
OEM (Original Equipment Manufacturers) – São fabricantes de complemen-
tos de hardware para computadores, como placas de vídeo, fones de ouvidos
e joysticks.
P&L (Profit and Loss) – Declaração de lucros e perdas gerada pelo publicador
para determinar se um produto será lucrativo. Custos de produção, marketing
e distribuição são comparados com a receita gerada pela venda projetada do
jogo.
pacote de assets – Outro termo para kit de fechamento. Um pacote de assets
contém todos os assets, a documentação e o código-fonte necessários para a
reconstrução de um jogo a partir do zero sem ajuda do desenvolvedor origi-
nal.
PAL (Phase Alternating Line) – As televisões europeias usam padrões de exi-
bição PAL, ou seja, a imagem de vídeo distribui 625 linhas de resolução a 50
half-frames por segundo. Os jogos de console europeus são desenvolvidos de
acordo com esses padrões para serem exibidos em televisões PAL e outros
monitores de vídeo compatíveis com o PAL.
patch – Trecho de código do jogo criado para lidar com bugs existentes em
um produto já entregue. O patch modifica arquivos do jogo na unidade de
disco rígido do usuário para corrigir qualquer bug crítico que tenha seguido
Glossário 453
inadvertidamente com o jogo. Geralmente o patch é oferecido para download

na Internet.
PEGI (Pan European Game Information) – Entidade europeia que atribui
classificações etárias a jogos interativos.
plataforma – O tipo de hardware necessário à execução de um jogo. Alguns
exemplos são PC, Nintendo DS, Sony PSP, Xbox.
produtor desenvolvedor (PD) – Um produtor que chefia uma equipe de de-
senvolvimento interna composta por artistas, programadores e designers.
produtor publicador (PP) – Produtor que trabalha para o publicador e intera-
ge com equipes de desenvolvimento externas.
propriedade intelectual – Ideias protegidas por lei federal, o que inclui tra-
balhos, conceitos, descobertas e invenções garantidas por direitos autorais.
SAG (Screen Actors Guild) – Sindicato que representa atores que trabalham
na mídia de entretenimento.
SDK (Software Development Kit) – Um SDK é um pacote de programação que
pode ser usado no desenvolvimento de software. Geralmente o SDK inclui
APIs, ferramentas e documentação. Se você estiver trabalhando com midd-
leware, o fornecedor lhe fornecerá um SDK com todas as informações perti-
nentes.
sistema operacional (SO) – O sistema operacional executa tarefas básicas do
computador, como o reconhecimento de entradas do mouse, a exibição de saí-
das no monitor e o fornecimento de uma base para a execução de aplicativos.
Também gerencia dispositivos periféricos, como impressoras e scanners. O
SO é específico do idioma e pode detectar que idiomas devem ser exibidos na
execução de aplicativos. O aplicativo precisa ter essa capacidade programada
no código antes do SO detectar a configuração de idioma correta.
software proprietário – Software que é criado pelo desenvolvedor e pertence
a ele. Não é autorizado para uso público e o código-fonte não fica disponível
publicamente. Por exemplo, o desenvolvedor pode criar um software proprie-
tário para converter arquivos .bmp em um formato de arquivo gráfico reco-
nhecido pelo jogo.
Unicode – Código padronizado internacionalmente para a representação de
letras e símbolos na forma de números a fim de que os dados possam ser facil-
mente transferidos de um computador para outro.
Apêndice C
RECURSOS
Livros
Bennis, Warren, On Becoming a Leader, Addison-Wesley Publishing

Company, 1989.
Bethke, Erik, Game Development and Production, Wordware Publishing,
Inc., 2003.
Brooks, Frederick P., Jr., The Mythical Man-Month, Anniversary Edition,
Addison-Wesley Publishing Company, 1995.
Buckingham, Marcus and Curt Coffman, First Break All the Rules: What
the World’s Greatest Managers Do Differently, Simon and Schuster, 1999.
Carter, Ben, The Game Asset Pipeline, Charles River Media, 2004.
Chandler, Heather Maxwell, The Game Localization Handbook, Charles
River Media, 2004.
Covey, Stephen R., The 7 Habits of Highly Effective People, Free Press,
1989.
DeCarlo, Doug, Extreme Project Management, Jossey-Bass, 2004.
DeMarco, Tom and Timothy Lister, Peopleware: Productive Projects and
Teams, Second Edition, Dorset House Publishing Co., 1999.
Drucker, Peter F., The Essential Drucker, Harper Business, Division of
Harper Collins, 2003.
Esselink, Bert, A Practical Guide to Localization, John Benjamin’s Pu-
blishing Company, Microsoft Press, 2000.
Festinger, Jon, Video Game Law, LexusNexus Canada, 2005.
Kano, Nadine, Developing International Software for Windows® 95 and
Windows NTTM, Microsoft Press, 1995.
Koster, Raph, A Theory of Fun for Game Design, Paraglyph Press, 2005.
Kouzes, James M. and Barry Z. Posner, The Leadership Challenge, Jos-
sey-Bass Publishers, 1997.
Kroeger, Otto with Janet M. Thuesen, Type Talk at Work, Dell Publishing,
1992.
Landsberg, Max, The Tao of Coaching, Harper Collins, 1996.
456 Apêndice C
Laramée, François Dominic, editor, Secrets of the Game Business, Se-

cond Edition Charles River Media, 2005.
Lewis, James P., Mastering Project Management, McGraw-Hill, 1998.
----------, Project Leadership, McGraw-Hill, 2003.
----------, Project Planning Scheduling and Control, Third Edition, Mc-
Graw-Hill, 2001.
----------, Team-Based Project Management, American Management As-
sociation, 1998.
Litwak, Mark, Litwak’s Multimedia Producer’s Handbook, Silman-James
Press, 1998.
Liverman, Matt, The Animator’s Motion Capture Guide: Organizing, Ma-
naging, and Editing, Charles River Media, 2004.
McConnell, Steve, Rapid Development, Microsoft Press, 1996.
Mencher, Marc, Get in the Game: Careers in the Game Industry, New
Riders Publishing, 2003.
Michael, David, The Indie Game Development Survival Guide, Charles
River Media, 2003.
Schwaber, Ken and Mike Beedle, “Agile Software Development with
SCRUM”, Prentice-Hall, 2001.
Schuh, Peter, Integrating Agile Development in the Real World, Charles
River Media, 2005.
Wysocki, Robert K., Effective Project Management, Third Edition, Wiley
Publishing, Inc., 2003.
Artigos
Ahearn, Luke, “Budgeting and Scheduling Your Game”, disponível on-

-line em http://www.gamasutra.com/features/20010504/ahearn_01.htm,
maio de 2001.
Buscaglia, Thomas H., Esq., “Completing Your Contract Arsenal – NDAs,
Employee, and Consultant Agreements”, disponível on-line em http://game-
devkit.com/gamearticle3.html, 2005.
---------, “Initial Legal Issues”, disponível on-line em http://gamedevkit.
com/gamearticle1.html, 2005.
---------, “Just What Are These Games Made Of … Legally Speaking?”,
disponível on-line em http://gamedevkit.com/gamearticle2.html, 2005.
Dowling, Patrick, “Localizing for Lands Beyond the Wild Frontier”, dis-
ponível on-line em http://gamasutra.com/features/production/19980828/lo-
calization_01.htm, 1998.
Gonzalez, Lauren, “When Two Tribes Go to War: A History of Videogame
Controversy”, disponível on-line em www.gamespot.com/features/6090892/
index.html, 2004.
Hamann, Wolfgang, “Goodbye Post Mortems, Hello Critical Stage Analy-
sis”, disponível on-line em www.gamasutra.com/resource_guide/20030714/
hamann_01.shtml, 2003.
Recursos 457
Hefter, Laurence R. and Robert D. Litowitz, “What Is Intellectual Proper-

ty?”, disponível on-line em http://usinfo.state.gov/products/pubs/intelprp/,
1999.
International Game Developers Association, “Quality of Life in the Game
Industry: Challenges and Best Practices”, disponível on-line em www.igda.
org/qol/whitepaper.php, 2004.
Käpyaho, Jere, “Internationalisation in Operating Systems for Handheld
Devices”, disponível on-line em http://www.cs.uta.fi/research/theses/mas-
ters/Kapyaho_Jere.pdf, Master’s Thesis, 2001.
Jassin, Lloyd J., “Working with Freelancers: What Every Publisher
Should Know About the ‘Work for Hire’ Doctrine”, disponível on-line em
http://copylaw.com/new_articles/wfh.html.
Marcus, Aaron and Emilie W. Gould, “Cultural Dimensions and Global
Web Design: What? So What? Now What?”, disponível on-line em http://
www.amanda.com/resources/hfweb2000/AMA_CultDim.pdf, 2001.
Meltzer, Max, “Managing an International Remote Development Team”,
disponível on-line em www.gamasutra.com/resource_guide/20030714/melt-
zer_01.shtml, 2003.
Pavlina, Steve, “Conducting a Project Postmortem”, disponível on-line
em www.gamedev.net/reference/articles/article977.asp, 2000.
Puha, Thomas, “Eurospeak: Localizing Games for the European Market”,
disponível on-line em www.gamasutra.com/features/20010403puha.htm,
2001.
U.S. Copyright Office, “Circular 9: Works Made for Hire Under the 1976
Copyright Act”, Library of Congress, disponível on-line em http://www.co-
pyright.gov/circs/circ9.html, 2004.
Sites
Academy of Interactive Arts and Sciences (AIAS) – www.interactive.org

Agile Game Development – www.agilegamedevelopment.com
American Federation of Television and Radio Artists (AFTRA) – www.
aftra.org
Blues News – www.bluesnews.com
Consumer Electronics Show (CES) – www.cesweb.org
Develop – www.developmag.com
Electronic Entertainment Expo – www.e3expo.com
The Escapist – www.escapistmagazine.com
Gamasutra – www.gamasutra.com
GameDev.net – www.gamedev.net
Game Developers Conference – www.gdconf.com
Game Development Search Engine – www.gdse.com
Game Developer Magazine – www.gdmag.com
Game Rankings – www.gamerankings.com
International Game Developers Association (IGDA) – www.igda.org
458 Apêndice C
Metacritic – www.metacritic.com
Moby Games – www.mobygames.com
Next-generation – www.next-gen.biz
Personal Software Process (PSP) – www.sei.cmu.edu/tsp/psp.html
Project Review – www.projectreview.net
Screen Actors Guild – www.sag.com
Scrum – www.controlchaos.com
SIGGRAPH – www.siggraph.org
Tom Sloper – www.sloperama.com
Sugestões de Sites Nacionais
SBGames – www.sbgames.org
Abragames – www.abragames.org
ACIGames – www.acigames.com.br
Apêndice D
BIOGRAFIAS
As pessoas a seguir foram entrevistadas para este livro. Seu conhecimento e

visão da indústria de jogos forneceram informações úteis que são apresenta-
das ao longo do livro.
Karin Groepper Boosman é uma profissional de gerenciamento de projetos

certificada que atualmente trabalha como gerente de projetos na Aspyr Media,
Inc., uma publicadora de jogos baseada em Austin, Texas. Karin se envolveu
no gerenciamento de projetos com equipes internacionalmente distribuídas
há mais de oito anos. Sua carreira na criação de jogos começou na SimBin AB
e na Blimey! Games, trabalhando na premiada série GTR antes de ingressar
na Aspyr como gerente de projetos em 2006. A experiência que ganhou ao
gerenciar equipes diversificadas e distribuídas com o uso de metodologias
formais de gerenciamento de projetos forneceu uma base sólida a partir da
qual ela pôde criar e aperfeiçoar um pipeline de localização arrojado para a
Aspyr, assegurando o lançamento de jogos internacionais no prazo, com alta
qualidade e dentro do orçamento. Ao longo de sua carreira, Karin trabalhou
em uma ampla variedade de títulos, entre eles: GTR, GT Legends, GTR 2, a
série The Sims, Civilization IV: Warlords, Prey, Never Winter Nights 2, Quake
Wars: Enemy Territory, Supreme Commander, Guitar Hero III, Call of Duty4 e
outros. Karin está engajada na melhoria da indústria de jogos de dentro para
fora, utilizando os melhores e mais modernos processos e filosofias de geren-
ciamento de projetos.
Tom Buscaglia
Tom Buscaglia, o advogado dos jogos, exerce a advocacia em todo o mundo

de seus escritórios em Miami, Flórida (www.gameattorney.com). Tom se de-
460 Apêndice D
dica à indústria de computadores e jogos, ajudando os desenvolvedores em

todos os aspectos de suas necessidades legais e empresariais, e representa
os desenvolvedores de jogos desde 1991. É membro do Board of Directors e
coordenador da seção da International Game Developers Association (www.
igda.org) no sul da Flórida. Publicou vários artigos para ajudar pessoas que
querem fundar seu próprio estúdio de desenvolvimento de jogos e recente-
mente lançou o site www.GameDevKit.com para ajudar ainda mais os desen-
volvedores de jogos iniciantes. Tom sempre se apresenta na Conferência Anu-
al de Desenvolvedores de Jogos, na Indie Games Com e em diversas outras
conferências relacionadas a jogos. Também é diretor executivo do Interactive
Entertainment Institute, dos apresentadores do G.A.M.E.S. Synergy Summit
(www.SynergySummit.com) e do Games Florida (www.Games-Florida.org).
Como FaTe[F8S], joga on-line regularmente com o FaTe’s Minions, e aprecia e
entende a indústria de jogos como jogador (www.f8s.com).
Melanie Cambron
Desde 1997, Melanie Cambron trabalha em recrutamento para líderes da in-

dústria de jogos, como a THQ, a Ubisoft e a Turbine. Presente em livros como
Game Design: Secrets of the Sages, Game Creation and Careers, The Fat Man
on Game Audio, Get in the Game! Careers in the Game Industry e Secrets of
the Game Business por seu conhecimento da indústria de jogos, ela também
escreveu o prefácio do bem-sucedido livro Game Programming with Direct X
7.0 e seu sucessor. Melanie é palestrante convidada popular nas universida-
des e escolas secundárias e é entrevistada com frequência na mídia, como no
Dallas Morning Review, no GIGnews e no Salon.com, por sua experiência na
indústria. Também foi mediadora e participou de mesa-redonda na e3 e na
GDC. Aparece creditada em vários jogos como consultora de RP/marketing.
Carey Chico
Carey Chico trabalha na indústria de jogos desde 1996, quando se formou

na UCLA com grau de bacharel em design. Sua entrada na indústria de jogos
começou ao ingressar no Activision Studios como animador em Planetfall.
Daí em diante, foi subindo como artista líder em Battlezone e, então, como
membro fundador do Pandemic Studios, onde concluiu Battlezone 2 como
diretor artístico. Após trabalhar novamente como diretor artístico em Star
Wars: The Clone Wars, subiu para o posto de diretor artístico do estúdio para
supervisionar interesses artísticos mais globais e de longo prazo. Alguns dos
títulos mais recentes sob sua supervisão são Full Spectrum Warrior, Battle-
front, Mercenaries e Destroy All Humans.
Biografias 461
Don Daglow
Don Daglow trabalha como presidente e CEO do Stormfront Studios desde

que fundou a empresa em 1988. No Emmy Awards for Technology and En-
gineering de 2008, recebeu o prêmio pela criação de Neverwinter Nights, o
primeiro jogo de interpretação de personagens multijogador em massa (mas-
sively multiplayer online role playing game – MMORPG), e em 2003 recebeu
o CGE Award por “realizações de ponta que moldaram a indústria de videoga-
mes”. A Electronic Games o chamou de “um dos produtores mais conhecidos
e respeitados da história desse segmento”. Os maiores sucessos da Stormfront
são The Lord of the Rings: The Two Towers (baseado no filme de Peter Jack-
son), Nascar Racing e Madden NFL Football da EA Sports, e o Neverwinter
Nights original da AOL.
Antes de fundar a Stormfront, Don atuou como diretor de desenvolvi-
mento de jogos Intellivision para a Mattel, como produtor na Electronic Arts
e como chefe da divisão de entretenimento e educação da Broderbund. Ele
projetou e programou o primeiro jogo de baseball para computador em 1971
(atualmente registrado no Baseball Hall of Fame em Cooperstown), o primei-
ro jogo de RPG para computadores mainframe (“Dungeon” para mainframes
PDP-10, 1975), o primeiro jogo de simulação (Utopia para Intellivision, 1981)
e o primeiro jogo a usar vários ângulos de câmera (World Series Major League
Baseball para Intellivision, 1983). Don coprojetou o título do Computer Game
Hall of Fame Earl Weaver Baseball (1987), assim como o Neverwinter Nights
original da AOL (1991-97). Foi eleito para o conselho de diretores da Acade-
mia de Artes e Ciências Interativas em 2003, e novamente em 2007. No pas-
sado, também venceu a competição de criação de peças teatrais New Voices
da National Endowment for the Humanities. Faz palestras frequentes sobre
design de jogos, mídia interativa e a indústria de videogames, e já fez con-
ferências essenciais no Canadá, Alemanha, Reino Unido e Estados Unidos.
Don obteve o BA em Composição Literária no Pomona College e um Ed.M. na
Claremont Graduate University.
Stephanie O’Malley Deming
Stephanie é uma produtora de desenvolvimento de software com mais de 10

anos de experiência em produtos educacionais e de entretenimento premia-
dos mundialmente de empresas que incluem a Activision, a Electronic Arts
e a 2K Games. É especializada em localizações e distribuiu simultaneamente,
com sucesso, versões multiplataforma e multilíngue de títulos de destaque
como a série Call to Power®, a série Guitar HeroTM, Rock Band, NBA 2K8 e
TM
vários títulos Tony Hawk . Com sua sócia, Stephanie fundou a XLOC, Inc.
(www.xloc.com), uma empresa que oferece aplicativos baseados na Web para
o gerenciamento fácil de localizações, e trabalha como consultora para em-
presas de jogos interativos.
462 Apêndice D
Jamie Fristrom
Jamie Fristrom tem um histórico na indústria que data de 1991 – embora nun-
ca tenha ocupado o cargo de “produtor”, trabalhou em projetos grandes e pe-
quenos assumindo papéis que incluem programação, direção técnica, geren-
ciamento de projeto, design e direção de criação. Atualmente é sócio, diretor
técnico e designer da Torpex Games, onde ajudou a criar o jogo Schizoid para
Xbox Live Arcade. Antes de Schizoid, Jamie foi diretor técnico e designer
no jogo Spider-Man 2, momento em que chegou mais perto da fama por ter
inventado seu dinâmico sistema de física de oscilação. Outros jogos em que
trabalhou são Spider-Man 1 para PS2, Xbox e GameCube, Tony Hawk para a
Dreamcast, Die By The Sword para PC e a série Magic Candle de RPGs. Jamie
escrevia a coluna “Manager in A Strange Land” para o Gamasutra e é recor-
dista mundial de redação de post-mortems de desenvolvimento de jogos no
Gamasutra e na revista Game Developer.
Tracy Fullerton
Tracy Fullerton é uma designer, educadora e escritora da área de jogos com

mais de uma década de experiência profissional. Atualmente é professora as-
sistente na Divisão de Mídia Interativa da USC School of Cinema-Television,
onde trabalha como codiretora do novo Electronic Arts Game Innovation Lab.
Tracy também é a autora de Game Design Workshop: Designing Prototyping
and Playtesting Games, um livro sobre design que está sendo usado mundial-
mente na programação de jogos.
Antes de ingressar na faculdade USC, foi presidente da desenvolvedora
de jogos interativos para televisão Spiderdance, Inc. Entre os jogos da Spider-
dance estão o Weakest Link da NBC, o webRIOT da MTV, o No Boundaries
da WB, o History IQ do History Channel, o Inquizition da Sony Game Show
Network e o Cyber Bond da TBS. E antes de começar na Spiderdance, Tracy
foi membro fundadora da firma de design R/GA Interactive em Nova York.
Como produtora e diretora de criação, criou jogos e produtos interativos para
clientes que incluem a Sony, Intel, Microsoft, AdAge, Ticketmaster, Compaq
e Warner Bros., entre muitos outros. Seus projetos de destaque são os jogos
multijogador Jeopardy! e Wheel of Fortune da Sony e o NetWits do MSN, o
primeiro quiz on-line multijogador.
O trabalho de Tracy recebeu vários prêmios na indústria, inclusive me-
lhor jogo para tabuleiro/família da Academy of Interactive Arts & Sciences, o
Interactive Design Review da ID Magazine, o Communication Arts Interactive
Design Annual, vários prêmios New Media Invision, o iMix Best of Show, o
Digital Coast Innovation Award, o Nombre D’Or da IBC e o Best of the Web da
Time Magazine. Em dezembro de 2001, apareceu na edição “Women in Enter-
tainment Power 100” da Hollywood Reporter.
Biografias 463
Raymond Herrera
Baterista e produtor de Los Angeles, Raymond Herrera passou os últimos 14

anos compondo, gravando e viajando com suas bandas Fear Factory, Brujeria
e Kush. Raymond é cofundador da 3volution Productions e da Kool Arrow
Records. Produziu e atuou como supervisor musical em muitas trilhas sono-
ras de videogames e filmes. Ganhou três discos de ouro, um disco de platina e
o California Music Award de melhor performance de hard rock.
Clint Hocking
Clint obteve um MFA (Master of Fire Arts) em redação criativa na University

of British Columbia, onde concluiu sua tese ao mesmo tempo em que traba-
lhava em Splinter Cell e Splinter Cell: Chaos Theory. Junto com o escritor J.T.
Petty, Clint foi premiado por seu trabalho no primeiro Splinter Cell com o
primeiro Game Developers’ Choice Award for Excellence in Scriptwriting da
GDC 2003. Clint faz parte da junta consultiva do IGDA de Montreal e também
da junta consultiva do programa de graduação em jogos eletrônicos e desen-
volvimento interativo do Champlain College em Vermont. Atualmente está
trabalhando como diretor de criação na Ubisoft em Montreal, onde vive feliz
com sua noiva Anne-Marie e seu cão.
Lee Jacobson
Lee praticamente não cresceu como uma criança normal, programando seu
primeiro videogame com 16 anos em seu computador Atari 400 (ele não po-
dia comprar o modelo 800) entre sessões noturnas mexendo na programa-
ção do Ultima e do Wizardry. Em 1988, participou da fundação de uma das
primeiras empresas de propaganda baseada em mídia interativa em Dallas,
Texas, que foi comprada em 1990.
Ele então rumou para o oeste para gerenciar o desenvolvimento empre-
sarial na Virgin Interactive Entertainment/Viacom em Irvine, California, e
posteriormente ingressou na Midway Games, Inc., em 1998, onde atua como
vice-presidente de desenvolvimento empresarial e aquisições. A carreira de
Lee abrange mais de 15 anos na indústria do entretenimento e inclui o geren-
ciamento da criação de produtos/negócios, aquisições, licenciamento domés-
tico/internacional e planejamento estratégico para a Midway.
464 Apêndice D
Todd Keister
Todd Keister deu um viés “renascentista” tanto à sua carreira quanto à sua
vida em geral, por sua experiência profissional não só em jogos on-line, como
também em várias outras funções, que incluem professor, músico clássico e
técnico de automóveis. Começando oficialmente na área de jogos como co-
ordenador de eventos on-line no estúdio Wolfpack para o jogo Shadowbane,
Todd percorreu diferentes áreas do desenvolvimento, das comunidades à ga-
rantia da qualidade, da execução de uma versão beta ao gerenciamento de
builds, atuando tanto em publicação quanto em desenvolvimento, o que le-
vou a papéis de produtor nas duas áreas. Após trabalhar em MMOs na NCsoft,
Todd planejou a volta ao desenvolvimento e tem passado exclusivamente de
um projeto de MMO para outro. Atualmente, está trabalhando como produtor
na ZeniMax Online em um MMO não anunciado.
Clinton Keith
Clinton Keith passou da indústria da defesa para a indústria de jogos no início

da década de 1990 como programador de ferramentas para o Angel Studios.
Lá ele acabou liderando as equipes que desenvolveram a primeira geração de
jogos de corrida Angel (Midtown Madness, Midnight Club e Smugglers Run) e
chefiando todo o desenvolvimento de produtos. Nos últimos três anos, passou
para o High Moon Studios (antes conhecido como Sammy Studios), primeiro
liderando a equipe de mecanismos e ferramentas, e atualmente é o CTO.
Paul Leska, Jr.
Paul é cofundador e presidente da Sapphire Software Inc., uma empresa de

jogos casuais baseada em Minnesota (www.SapphireOnline.com). A Sapphire
Software cria jogos para os mercados baseado na Web e móvel e é mais conhe-
cida por seus títulos populares de Sudoku – Sudoku Savant e Sudoku Sensei.
Sudoku Sensei foi indicado para melhor software do ano pela Smartphone
and Pocket PC Magazine em 2006. Como diretor de um pequeno estúdio de
desenvolvimento, Paul teve a oportunidade de desempenhar várias funções,
entre elas produtor, designer e diretor técnico, além de testador, diretor de
criação e zelador.
Paul tem mais de 18 anos de experiência trabalhando para várias empre-
sas como instrutor, arquiteto, desenvolvedor e conselheiro. Ele é especializa-
do em arquitetura e metodologia de desenvolvimento de software. Escreveu
vários artigos sobre metodologias de desenvolvimento de software para diver-
sas revistas técnicas especializadas.
Biografias 465
Erik Louden
Erik Louden tem mais de 10 anos de experiência profissional em testes de

videogames. Erik executou testes beta em quase 50 jogos, inclusive em títulos
como Bad Mojo, Wizards & Warriors, Fighter Squadron: The Screaming De-
mons over Europe, M.A.X.X., Planet Side, Shadow Bane, Vampire: The Mas-
querade, Ever Quest e Ultima On-Line, entre outros. Foi membro original do
Activision’s Visioneers, um programa externo de testes beta, e atualmente é
membro do grupo de testes da Atari.
Jeff Matsushita
Jeff Matsushita é um veterano com 10 anos de vivência no negócio de video-

games. Após ganhar experiência na área de produção por meio de trabalhos
em filmes, vídeos, TI e na então emergente Internet, ingressou na Activision
em Tóquio, onde ajudou a localizar títulos norte-americanos para o mercado
japonês. Voltou para os Estados Unidos, onde continuou trabalhando para
a Activision como produtor associado de desenvolvimento. À medida que
a indústria foi separando a publicação do desenvolvimento, decidiu trazer
essa experiência para o lado da atividade referente à publicação, onde su-
pervisionou vários títulos desenvolvidos externamente tanto como produtor
quanto como produtor sênior, antes de passar para a função de aprovação na
Activision, ajudando a assegurar a continuidade de todos os títulos em de-
senvolvimento. Atualmente atua como produtor executivo supervisionando
o desenvolvimento da franquia Guitar Hero da RedOctane.
Lucien Parsons
Lucien Parsons, diretor de produção do ZeniMax Online Studios, uma empre-

sa da ZeniMax Media, tem 14 anos de experiência na produção de software
em quatro continentes. Após muitos anos na indústria de software financei-
ro, obteve um MBA na Wharton School, Universidade de Pensilvânia, e um
no Johns Hopkins SAIS em International Economics and Technology Policy
antes de entrar na indústria de jogos. Atualmente está construindo com Matt
Firor as equipes principais de tecnologia, arte e design de um novo MMO não
anunciado.
466 Apêndice D
Jay Powell
Jay entrou na DigiRonin Games com 10 anos de experiência na indústria e

um diploma da University of North Carolina. Ele começou a trabalhar na in-
dústria de jogos com a Octagon Entertainment como um agente que repre-
sentava desenvolvedores em todo o mundo. Durante seu tempo como agente,
negociou inúmeros contratos para seus clientes. Viu praticamente de tudo, de
contratos de distribuição na Europa a acordos de desenvolvimento em várias
plataformas. Nos últimos anos, supervisionou o desenvolvimento de mais
de uma dúzia de títulos baseados em várias licenças, como Garfield, Holly
Bobby, Strawberry Shortcake e um amplo grupo de personagens da Disney.
Esses títulos abrangem o Nintendo GBA e DA, Microsoft Xbox 360 e PCs.
Jay desenvolveu e continua mantendo relações com empresas como a Disney,
Cartoon Network, MTV, Nickelodeon e Microsoft.
Stuart Roch
Stuart Roch trabalha há 12 anos na indústria interativa nas áreas de garantia

da qualidade, design e produção. Na Shiny Entertainment, atuou nas áreas de
design e produção em Wild 9, R/C Stunt Copter, Messiah e no aclamado pela
crítica Sacrifice. Stuart liderou a equipe da Shiny na produção de Enter the
Matrix, que foi lançado em 2003 e acabou vendendo mais de seis milhões de
unidades em todo o mundo. Como produtor executivo na Treyarch, ingressou
tarde na equipe de desenvolvimento para ajudar a concluir Ultimate Spider-
-Man. Em 2007, começou a trabalhar no lado externo da produção, quando
passou da Treyarch para a matriz Activision, onde agora gerencia um variado
grupo de lançamentos futuros.
Amanda Rubright
Amanda Rubright ingressou na equipe de produção da Aspyr na primavera de

2006. Desde então, liderou a produção de Supreme Commander (Xbox 360),
Turok (PC), The Shield (PC), TopSpin 2 (PC) e Save the Dinos (PC), ajudou no
design dos jogos Sims Pets Stories e Sims Castaways e deu apoio ao departa-
mento interno de TI da Aspyr no desenvolvimento de demonstrações. Embora
atualmente esteja se empenhando para obter sua certificação PMP no Project
Management Institute, Amanda também está ocupada chefiando a produção
de Guitar Hero 3 Encore: Aerosmith (PC/Mac) e Guitar Hero 4 (PC/Mac). An-
tes de trabalhar com a Aspyr, ela passou os oito anos anteriores como desig-
ner de jogos e níveis para a Ubisoft Entertainment (Tarzan Untamed), Retro
Studios (Metroid Prime), Amaze Entertainment (Shrek 2 PC) e Edge of Reality
(Shark Tale, Fear & Respect) desenvolvendo títulos AAA tanto para console
Biografias 467
quanto para PC. Além de liderar equipes, supervisionou o fluxo de trabalho

de design em muitas dessas empresas, fornecendo procedimentos de design
eficientes e comunicativos. Seu sólido conhecimento das bases do desenvol-
vimento de jogos, associado à sua liderança e experiência no design de jogos
e níveis, levou a uma transição natural para a produção.
Tobi Saulnier
Tobi Saulnier é a CEO da 1st Playable Productions, um estúdio independente

de desenvolvimento de jogos localizado em Troy, NY, que se especializou
na criação de jogos para entretenimento e aprendizado. Anteriormente, em
seus cinco anos como vice-presidente de desenvolvimento de produtos da
Vicarious Visions, Tobi foi responsável pela distribuição de mais de 60 tí-
tulos, que variaram de Blues Clues GBC a Doom III Xbox, com equipes de
quatro a mais de 60 pessoas e cronogramas de projeto abrangendo de dois
meses a dois anos. Ela também atuou como produtora e contribuiu no design
de vários desses títulos, com um interesse particular em jogos para públicos
não tradicionais. Antes de ingressar na indústria de jogos, Tobi gerenciou a
área de pesquisa e desenvolvimento em sistemas embutidos e distribuídos no
departamento de P&D da GE. Tobi é Ph.D., M.S. e B.S. em engenharia elétrica
pelo Rensselaer Polytechnic Institute.
Coray Seifert
Coray Seifert é produtor associado no Kaos Studios da THQ e está trabalhan-

do em seu 24° título, Frontlines: Fuel of War. Coordenador da seção de Nova
Jersey da International Game Developers Association desde 2002, também foi
cofundador do IGDA Game Writers Special Interest Group Quarterly Report
e continua a trabalhar com o SIG como membro do comitê e autor colabo-
rador em sua série de livros Game Writing. Coray desenvolveu jogos como
redator, designer e produtor para empresas como Large Animal Games, Creo
Ludus Entertainment e para o Departamento de Defesa dos Estados Unidos;
apareceu na Gamasutra.com, Forbes.com, NY1, Game Developer Magazine, e
participou de vários eventos da indústria de jogos como editor, entrevistado,
palestrante ou anfitrião. Defensor dos aspirantes a desenvolvedores de jogos,
Coray também ensina design como professor convidado no Bloomfield Col-
lege e no New Jersey Institute of Technology. Quando não está distribuindo
gratuitamente “high-fives” e fazendo piadas com o Dungeous and Dragons,
Coray vive em Summit, NJ, com sua maravilhosa esposa Katie e seus dois
gatos altamente excêntricos.
468 Apêndice D
Tom Sloper
Tom Sloper está na indústria de jogos desde 1979. Ele produziu, projetou ou
deu sua contribuição para a conclusão de 120 produtos, ganhando seis prê-
mios. Seus jogos pertencem a uma ampla variedade de plataformas de video-
games e computadores, do Atari 2600 até o Nintendo DS, sem falar nos jogos
para relógios e calculadoras e o clássico sistema Vectrex. Tom trabalhou para
a Sega Enterprises (designer de jogos), Atari Corporation (diretor de desen-
volvimento de produtos) e Activision (produtor sênior, produtor executivo e
diretor de criação). Produziu jogos com desenvolvedores de todo o mundo e
é jogador internacional de Mah-Jongg. Fazendo negócios sob o nome Slopera-
ma Productions, atualmente está prestando consultoria, escrevendo e dando
palestras sobre jogos.
Wade Tinney
Wade ajudou a fundar a Large Animal Games (www.largeanimal.com) com o

sócio Josh Welber em 2001. Desde então, a Large Animal desenvolveu mais de
45 jogos para várias plataformas, inclusive a Web, dispositivos móveis e PCs.
Eles criaram jogos promocionais baseados na Web para clientes como LEGO,
MTV, Cartoon Network e Mattel, e seus títulos originais para download são
distribuídos nos principais portais de jogos casuais. O jogo de puzzle da Lar-
ge Animal, AlphaQUEUE, foi finalista no 2004 Independent Games Festival
(IGF), e RocketBowl ganhou o 2005 IGF Award. Wade é um membro ativo da
International Game Developers Association, contribui regularmente em seus
artigos anuais sobre jogos para download e da Web e é editor fundador do
Online Games Quarterly da IGDA. Também ensina design de jogos na Parsons
School of Design e na New York University.
Patricia Vance
Patricia Vance foi designada presidente do Entertainment Software Rating

Board (ESRB) em novembro de 2002. Como presidente, ela é responsável por
supervisionar e impor as práticas autorregulatórias da indústria de jogos de
computador e outras plataformas. Isso inclui assegurar que os consumidores
de videogames tenham ferramentas eficazes para tomar decisões de compra
embasadas.
Antes de ingressar no ESRB, Patricia se estabeleceu como verdadeira ve-
terana da mídia interativa e líder do segmento. Passou 18 anos na Disney/
ABC, com a responsabilidade de alavancar propriedades da ABC desenvol-
vendo e gerenciando um amplo conjunto de novas iniciativas de mídia e
mercado. Essas iniciativas incluíram a Internet (ABC.com, ABCNEWS.com,
Biografias 469
Oscar.com, Oprah.com), a publicação de CD-ROMs (Creative Wonders, ABC

Interactive), a distribuição de filmes e vídeos educativos (entre eles os do
ABC News Interactive), a resposta direta ao mercado de videocassetes, entre-
tenimento em aeronaves, vídeo caseiro e TV a cabo.
Antes da ABC, Patricia era responsável pelo planejamento de aquisições
de filmes para o Movie Channel. Ela também ocupou posições de gerente sê-
nior no Princeton Review como vice-presidente executiva e gerente geral de
serviços de admissão e, antes disso, como presidente e CEO do HalfthePlanet.
com, uma rede de recursos on-line para pessoas com deficiências.
Patricia obteve o grau de B.A. em International Relations/Russian da
Washington University em St. Louis.
ÍNDICE
A Benefícios de um MBA, 96-98

A comunicação e o desenvolvimento de jogos, Best Buy, 38
134 Brainstorm, 30, 217-218, 237-238
Adaptadores, 325 Bug crítico, 363-364
Alocação de recursos, 312 Bugs menores, 363-364
Análise competitiva, 261 Bugzilla, 362-363
Análise de risco, 5-6, 231-234, 252-253, 261, 306, Build da equipe, 109-119
310 Conhecendo uns aos outros, 111-114
Aprendendo a trabalhar em uma equipe, 101-102 Definição de papéis, 113-115
Aprendendo com a experiência, 14-15 Formas de agrupamento, 115-117
Apresentação demonstrativa, 261 Reuniões da equipe, 116-118
Aprovação do conceito, 261 Site da equipe, 117-119
Aprovação do licenciador, 373 Treinamento cruzado, 114-116
Aprovações de jogos por terceiros, 86-87 Builds automatizadas, 321-323
Arquivos de áudio, 154-156 Builds de marketing, 358-359
Arquivos de log de interrupção, 365-366 Builds do jogo, 209-211
Arquivos de música, 181 Diários dos desenvolvedores, 210-211
Arte conceitual, 227-228 Entrevistas, 210-211
Arte da caixa, 206 Feiras, 210-211
Arte de alta resolução, 25, 208-210 Press tours, 209-211
Assets, 389-390 Trabalhando com a equipe de relações públi-
Assets de arte, 341-342 cas, 209-210
Assets de áudio in-game, 160 Builds multilíngues, 322-323
Assets de idiomas, 339-341, 349-350
Assets de marketing, 208-210 C
Assets de texto, 341-342 Captura de movimentos (motion capture), 192-199
Assets de voiceover, 341-342 Capturas de tela (screen shots), 25, 205, 208-210,
Assets localizados, 373 365-366
Ato de direitos autorais, 60 Caracteres e fontes internacionais, 341-342
Atrasos no cronograma, 302 Cartões de referência do teclado, 206
Atribuindo e fechando bugs, 365-367 Cenário do jogo, 225-226
Atualizações departamentais, 310 CERO, 336
Aumentando a motivação da equipe, 124-126 Certificação PMP, 51-53
Avaliando desenvolvedores, 80-82 Chaves de CD, 324-325
Avalie a tecnologia, 245-246 Ciclo de produção, 3-5, 43
Ciclo de produção artística, 295-297
B Ciclo de produção de engenharia, 296-298
Banco de dados de rastreamento de bugs, 362-363 Ciclo de produção do design, 293-296
Bases, 184 Ciclo de testes, 363-368
BBFC, 333-334 Atribuindo e fechando bugs, 365-367
472 Índice
Registrando bugs, 364-366 Contratos de publicação, 60

Verificando TCRs, 366-368 Contratos legais, 63-67
Classificação de recursos, 238-239 Contrato por encomenda, 64-66
Classificações de software, 374 Contratos de confidencialidade (NDAs), 65-66
Classificações etárias de software, 328-331 Contratos de desenvolvimento, 65-67
Código favorável à localização, 339-344 Contratos de empregado/consultor, 63-65
Assets de arte, 341-342 Contratos de lincença do usuário final (EULA),
Assets de idiomas, 340-341 66-67
Assets de texto, 341-342 Convenção de nomenclatura de arquivos, 156
Assets de voiceover, 341-342 Cortando recursos, 303-304
Caracteres e fontes internacionais, 341-342 Crash bug, 362-364
Entrada do teclado, 342-343 Crescimento desenfreado, 9-10, 240-241, 260
Interface de usuário, 341-343 Criando a documentação artística, 251
Outras considerações técnicas, 343-344 Criando builds, 319-325, 391
PAL versus NTSC, 342-343 Criando conteúdo internacional, 339-340
Código-fonte, 390-391 Criando documentação técnica, 251-253
Código-fonte de ferramentas, 391 Criando kits de fechamento, 388-392
Códigos candidatos à liberação (CRC), 13, 241, Assets, 389-390
359, 372, 375 Código do jogo, 390-391
Códigos de trapaça, 203 Diretrizes técnicas, 391
Colocando um projeto novamente no rumo, 302-305 Documentação, 391
Como colocar um projeto novamente no rumo, Ferramentas, 390
304-305 Informações gerais de produção, 391-392
Como demonstrar um jogo, 74-75 Criando o pipeline, 247-249
Como o produtor constrói uma equipe, 105-106 Criando protótipos, 230-232
Comparações, 306 Criando um cronograma, 261-273
Compatibilidade entre idiomas, 343-344 Cronograma detalhado, 264-271
Compiladores, 28 Cronograma inicial, 262-264
Compositores, 182-184 Estrutura de divisão do trabalho, 264
Comunicação não verbal, 132-133 Rastreando tarefas, 270-273
Comunicação oral, 130-132 Criando um cronograma artístico, 261
Comunicação por e-mail, 130 Criando um orçamento, 274-277
Comunicação por escrito, 130 Critérios de saída, 11-12, 261-262, 264
Concatenação, 154-155 Cronograma da cinemática, 183
Conceito do jogo, 5-7 Cronograma de builds, 320-322
Conclusão de tarefas, 11-12 Cronograma de captura de movimentos, 194-196
Conduzindo playtests, 293-294 Cronograma de etapas do desenvolvimento, 202
Conduzindo testes beta, 294-296 Cronograma de localização, 346
Conduzindo um post-mortem, 380-384 Cronograma de produção de níveis, 267-270
Envolva a equipe inteira, 382 Cronograma de produção detalhado, 264-265,
Mantenha o foco, 383-384 269-271
Prepare o post-mortem, 382-383 Cronograma de produção e liberação de jogo de
Conduzindo uma revisão de projeto, 306-307 console, 375
Configurações de PC, 13 Cronograma de produtos musicais, 184
Construindo uma equipe forte, 112-114 Cronograma de testes, 358-359
Contratando talentos, 92-98 Cronograma e equipe de voiceover, 160-162
Dando feedback, 97-98 Cronograma inicial de produção, 262-263
Entrevistando talentos, 95-98 Cronogramas, 260-273
Filtrando currículos, 93-95 Criando um cronograma, 261-271
Contrato por encomenda, 64-66 Cronograma detalhado, 264-271
Contrato publicador-desenvolvedor, 12 Cronograma inicial, 262-264
Contratos de confidencialidade (NDAs), 65-66, 204 Estrutura de divisão do trabalho, 264
Contratos de desenvolvimento, 65-67, 282 Rastreando tarefas, 270-273
Contratos de empregado/consultor, 63-65 Cronogramas de desenvolvimento do jogo,
Contratos de licença do usuário final (EULA), 260-273
66-67, 373 Cronogramas de design, 270-271
Índice 473
D Dirigindo atores, 173-175

Dando feedback, 97-98 Disney, 67-68
Dando más notícias, 135-137 Divisão em grupos, 148-149
Dando suporte à documentação, 306 Documentação, 248-253, 391
Dando um feedback eficaz, 136-138, 297-298 Arte, 250-251
Declaração da missão, 5-6, 224-226 Design, 249
Definições de bugs, 362-364 Técnica, 251-253
Definindo etapas, 243-244 Documentação artística, 264
Definindo etapas e produtos, 240-244 Documentação de design, 7-8, 26, 264
Definindo ferramentas e pipeline, 245-249 Documentação do jogo, 391, 202-203
Definindo kits de fechamento, 388 Documentação técnica, 264
Definindo o conceito do jogo, 224-229 Documento de design do jogo (GDD), 84, 251-253
Arte conceitual, 227-228 Documento de design técnico (TDD), 84, 251-253
Cenário do jogo, 225-226 Documento de lições aprendidas, 383-385
Declaração da missão, 224-226
Elementos de áudio, 227-229 E
Mecânica do jogo, 225-227 EB Games, 38
Sinopse da história, 226-227 Elementos da história, 32
Definindo qualidade de vida, 125-126 Elementos da IU, 205, 341-343
Definindo recursos do jogo, 237-241 Elementos da jogabilidade, 5-6, 73, 237-238
Demonstrativo de lucros e perdas (P&L), 274 Elementos de áudio, 227-229
Demos, 206-208, 373, 358 Elementos gráficos de próxima geração, 257-258
Demos de console, 207-208 Embalando, 204-206, 343-344
Demos localizadas, 208 Arte da caixa, 206
Planejando uma demo, 206-207 Cartões de referência do teclado, 206
Demos de console, 207-208 Manuais, 204-206
Demos localizadas, 208 Engajamento e motivação da equipe, 118-126
Departamento de QA, 12-14 Atacando os sinais de alerta,121-123
Dependências, 257-259 Compartilhando a visão, 122-124
Depuradores, 28 Mostrando satisfação, 122-123
Desafiando personalidades, 110-111 Pesquisa na equipe, 123-126
Desafios da comunicação, 134-138 Sinais de alerta, 119-122
Dando más notícias, 135-137 Engenharia do jogo, 26-27
Dando um feedback eficaz, 136-138 Enraizamento, 146-147
Resolvendo conflitos, 134-136 Entrada do teclado, 342-343
Descrição do conceito, 235-236 Entrevistando talentos, 92, 95-98, 210-211
Descrição do planejamento do jogo, 285-286 Equipe, 279-283
Descrição dos requisitos do jogo, 254 Comunicação, 282-283
Descrições de personagens, 167, 173-174, 203 Terceirizando, 280-282
Desenvolvedor exclusivo do publicador, 84-86, Equipe artística, 23-26
216 Animador, 25
Desenvolvedor independente, 12, 60-61, 65-66, Artista conceitual, 23-24
72-74, 79-84 Artista de marketing, 25
Desenvolvedores externos, 20 Artista líder, 23-24
Design da música, 180-181 Artista técnico, 25
Design do voiceover, 154-155 Construtor de mundos ou designer de níveis,
Determinando a liberação do código, 371-372 23-25
Detonados, 203 Criador de assets, 25
Diálogo provisório, 159-160 Diretor de arte, 23-24
Diários dos desenvolvedores, 210-211 Experiência e treinamento, 25-26
Direitos de propriedade intelectual, 60-64, 77-81 Equipe com estrutura grande, 36
Direitos autorais, 60-61 Equipe da empresa, 37-38
Marcas registradas, 60-63 Marketing e relações públicas, 37-38
Patentes, 63-64 Serviços de criação, 38
Segredos comerciais, 62-64 Vendas, 38
Diretrizes técnicas, 391 Equipe de desenvolvimento, 18
474 Índice
Equipe de design, 30-32 F

Designer, 30-32 Fase de pós-produção, 14-15
Designer líder, 30-31 Aprendendo com a experiência, 14-15
Diretor de criação, 30-31 Condução de um post-mortem, 14-15
Experiência e treinamento, 32 Lista de verificação da pós-produção, 15
Redator, 32 Plano de arquivamento, 15
Equipe de estrutura pequena, 36 Fase de pré-produção, 4-9, 143-150
Equipe de produção, 18-23, 147-150 Conceito do jogo, 5-7
Experiência e treinamento, 21-23 Equipe de produção, 147-150
Produtor, 19-21 Lista de verificação da pré-produção, 8-9
Produtor associado, 21 Planejamento do jogo, 7-9
Produtor executivo, 19 Questões artísticas, 146-148
Equipe de programação, 26-28 Questões de design, 145-147
Diretor técnico, 27 Questões de tecnologia, 143-146
Experiência e treinamento, 28 Requisitos do jogo, 7-8
Programador, 27-28 Fase de produção, 8-12, 149-151
Programador líder, 27 Conclusão de tarefas, 11-12
Escalando atores, 165-173 Implementação do plano, 9-11
Preparando descrições de personagens, 168 Lista de verificação da produção, 12
Selecionando e reservando o tempo de atores, Rastreando o progresso, 11
172-173 Fase de requisitos do jogo, 7-8, 255, 286-287
Sindicalizados ou não sindicalizados, 166-167 Fase de testes, 12-14
Testes, 168-171 Liberação do código, 13-14
Vozes de celebridades, 167 Lista de verificação dos testes, 14
Especificações dos arquivos de som, 157 Validação do plano, 13
Esquema de controle, 5-6, 30-31, 203 Fazendo reuniões, 310
Esquemas de proteção de direitos autorais, 324-325 Feedback útil, 298-299
Esquemas proprietários de proteção contra có- Feiras, 210-211
pias, 325 Ferramentas, 390
ESRB, 330-333 Ferramentas de script, 26
Estabelecendo normas de comunicação, 133-134 Filmagem da jogabilidade, 208-210
Estabelecendo processos de aprovação, 315-317 Filtrando currículos, 93-95
Centralize o controle, 316-317 Finalidade de um post-mortem, 379-381
Defina e publique, 316-317 Finalizando kits de fechamento, 392-393
Mantenha simples, 316-317 Fluxo contínuo de áudio, 181
Estratégia em tempo real, 218-219 Forças-tarefa, 316-317
Estrutura de divisão do trabalho (WBS), 264-265, Formato de roteiro da cinemática, 159
269-270 Formatos de áudio, 182
Estrutura de equipe com produtor executivo, 37 Formulário de visão geral de assets, 344-346
Estúdios de som, 162-165 Fornecedor de localização, 388
Etapa alfa, 241 Fornecedores externos, 281-283
Etapa beta, 241
Etapa da primeira versão jogável, 240-241 G
Etapa de congelamento do código, 241
Gênero do jogo, 5-6, 154-155, 218-219
Etapas comuns do desenvolvimento, 242
Gerência do estúdio, 18, 21, 92
Etapas do desenvolvimento, 83-84, 203
Gerenciando assets, 154-155
Evitando a pirataria, 324-325
Gerenciando o relacionamento desenvolvedor-pu-
Esquemas de proteção de direitos autorais,
blicador, 74-86, 82-84
324-325
Desenvolvedor exclusivo do publicador,
Evitando o crescimento desenfreado, 312-315
84-86
Priorizando recursos, 314
Desenvolvedor independente, 79-84
Solicitações de alterações, 314-315
Gerenciando um orçamento, 277-279
Evitando o crescimento desenfreado, 313-314
Gerente de projeto (GP), 85-86
Expondo um jogo para um publicador, 7, 71-75,
Glass masters, 375
234-235, 261
Gold masters, 374-376, 388, 390
Grade de classificação de risco, 232-233
Índice 475
Gráficos de burndown, 42 Jogos de PC, 13, 66-67, 205, 219-220, 374

Gravando voiceover, 172-176
Dirigindo atores, 173-175 K
Preparando uma sessão de gravação, 172-174 Kit de desenvolvimento de software (SDK), 284
Produtos de áudio, 175-176 Kit de fechamento, 14-15, 387-393
Selecionando tomadas, 174-176 Kit de localização, 388
Grupos, 109-110 Kit de tradução, 388
Grupos de foco, 203-204 KMRB, 336
Grupos de processos e áreas de conhecimento do
PMI, 53-56 L
Guia de estilo, 250 Lançamento do projeto, 234-235, 261
Guias de estratégia, 38 Layouts de níveis, 30-31
Legendas, 343-344
H
Licenças, 66-69
Harry Potter, 66-67 Licenciando música, 180, 186-189
Heads-Up Display (HUD), 363-364 Lidando com atrasos no cronograma, 302
Hierarquia da equipe, 35 Lidando com o crescimento desenfreado, 315
Líder de testadores de QA, 34-35
I Liderança do projeto, 106-108
Identificando riscos, 252-253 Líderes eficazes, 109-110
Implementação do plano, 9-11 Lista de assets, 9-10, 250
Informações de direitos autorais, 60-61, 372 Lista de produtos das etapas, 264
Informações de suporte ao cliente, 373 Lista de recursos, 203
Iniciando o processo de desenvolvimento de Lista de tomadas de captura de movimentos, 194
jogos, 216-224 Lista de verificação da liberação do código,
Análise competitiva, 222-223 372-374
Análise SWOT, 219-222 Lista de verificação da localização, 351-353
Aprovação, 223-224 Lista de verificação da pós-produção, 15
Brainstorm, 217-218 Lista de verificação da pré-produção, 8-9
Conceito inicial, 218-219 Lista de verificação da produção, 12
Gênero, 218-219 Lista de verificação de assets, 210-212
Plataforma, 219-220 Lista de verificação de captura de movimentos,
Instruções de ferramentas, 250-252 198
Integração de assets, 347-348 Lista de verificação de voiceover, 175-176
Integrando assets traduzidos, 344-345, 347-350 Lista de verificação do kit de fechamento,
Interfaces de programação de aplicativos (API), 392-394
28 Lista de verificação dos testes, 14
International Game Developers Association Lista mestra de recursos, 238-239
(IGDA), 126-127 Lista mestra de recursos em camadas, 265
Investigando fornecedores, 283 Localização, 21, 205, 339-353
Localização completa, 343-344
J Localização da embalagem e do manual, 343-344
Jogo “jogador versus ambiente” (PvE), 146-147 Localização parcial, 343-344
Jogo “jogador versus jogador” (PvP), 146-147
Jogo de combate, 218-219 M
Jogo de representação de papéis (RPG), 218-219 Mantendo a equipe feliz, 100-101
Jogo do tipo time to market, 237-238 Mantendo o projeto no rumo, 292-293
Jogo on-line massivo multijogador (MMO), Manuais, 204-206
141-151, 154-155, 220-221 Manuais eletrônicos, 205
Equipe de produção, 147-150 Marcação de software, 209-210
Pós-produção, 151 Marcando builds, 209-210
Pré-produção, 143-146 Marcas registradas, 60-63
Produção, 150-151 Marketing e relações públicas, 37-38
Questões artísticas, 146-148 Material de divulgação do jogo, 38
Questões de design, 145-147 Mecânica do jogo, 225-227
Jogos de celular, 219-220 Microsoft, 86-87, 208, 219-220, 351-352, 372, 374
476 Índice
Microsoft Excel, 11 Cronograma e pessoal, 182-184

Microsoft Project, 11, 260, 270-271 Design da música, 180-181
Middleware, 7-8, 144-146, 148-149, 251-252, Solicitações de propostas, 184-185
283-286 Planejando o voiceover, 154-162
Modelo com produtor executivo, 36-37 Considerações técnicas, 154-156
Modelo de combate, 30-31 Cronograma e pessoal, 160-162
Modelo produtor-chefe, 35-36 Design do voiceover, 154-155
Moral da equipe, 120-122 Formatos de arquivos, 156-157
Motivação da equipe, 121-123 Roteiro de voiceover, 158-159
Música in-game, 180 Voiceover provisório, 159, 160
Música provisória, 182 Planejando uma demo, 206-207
Plano de arquivamento, 15
N Plano de localização, 344-346
Negociando salários, 92 Cronograma, orçamento e pessoal, 344-346
Nintendo, 86-87, 208, 219-220, 351-352, 372, Plano de pessoal, 279-280
374 Plano de testes da localização, 350
Nível de detalhes (LOD), 147-148 Plano de testes do tipo aprovado/reprovado,
Nível de localização, 343-344 360-363
Notas de build, 322-325 Planos de testes, 359-363
Para a equipe de desenvolvimento, 323-324 Playtest, 30, 293-296, 358
Para a gerência, 323-324 Polinização entre equipes, 148-149
Para marketing e RP, 323-325 Postando aberturas de vagas, 92
post-mortems, 14-15, 379-385
O Preparando descrições de personagens, 168
Obstáculos, 306 Preparando tomadas de captura de movimentos,
OFLC, 334-336 192-193, 196-198
Orçamentos, 274-279 Preparando uma sessão de gravação, 172-174
Criando um orçamento, 274-277 Press tours, 209-211
Gerenciando um orçamento, 277-279 Priorizando recursos, 314
Orçamentos de voiceover, 163-167 Problemas legais e a produção, 60
Organização da equipe, 33-37 Processo de build, 320-323
Organizando assets para tradução, 344-345 Builds automatizadas, 321-323
Organizando conteúdo, 391-392 Cronograma de builds, 320-322
Processo de liberação do código, 371-372
P Processo de software em equipe (TSP), 44-45
Padrões de codificação, 251-252 Processo pessoal de software (PSP), 41-47
PAL versus NTSC, 342-343 Processos de aprovação, 315-317
Papel do gerente de projetos, 85-86 Processos de engenharia de software, 42-43
Patentes, 63-64 Produtor desenvolvedor (PD), 20-21, 75-76, 85
PEGI, 332-334 Produtor publicador (PP), 20-21, 75-76, 85-86
Personagens não jogadores, 32, 146-147 Produtos de áudio, 175-176
Pipeline de produção, 7-8, 246, 391 Programador de IA, 28
Pipeline de teste, 362-364 Programador gráfico, 28
Banco de dados de rastreamento de bugs, Programando-se para trabalhar com várias plata-
362-363 formas, 273
Definições de bugs, 362-364 Project Management Body of Knowledge
Planejamento do jogo, 7-9 (PMBOK), 51-52
Planejamento do projeto, 9-10 Project Management Institute (PMI), 42, 51-56
Planejando a captura de movimentos, 192-196 Propostas de captura de movimentos, 195-196
Cronograma, 194-196 Propostas musicais, 184-185
Lista de tomadas de captura de movimentos, Proteção contra cópias de terceiros, 324-325
194 Prototipagem, 30-31, 228-232, 295-297
Requisitos de captura de movimentos, Protótipo experimental, 228-229
193-194 Protótipo exploratório, 228-229
Planejando a música, 180-185 Protótipos, 5-7, 35
Considerações técnicas, 181-182 PSP e TSP, 44-47
Índice 477
Publicidade, 38 Sistema de pontuação, 30-31

Sócio de publicação, 72-73
Q Software de criação de cronogramas, 260
Qualidade de vida, 125-128 Software Engineering Institute, 44
Questões artísticas, 146-148 Solicitação de propostas, 73
Questões de design, 145-147 Solicitações de alteração, 314-315
Questões de tecnologia, 143-146 Solicitações de recurso, 363-364
Sony, 86-87, 208, 351-352, 372, 374
R StarForce, 324-325
Rastreamento do progresso, 11
Rastreando o progresso, 11 T
Recursos de middleware, 283 Taxa de amostragem, 157
Recursos humanos (RH), 55, 92 Taxa de bits, 157
Redigindo diálogos, 30 Teorias de jogos, 32
Redigindo documentos de design, 250 Terceirizando, 280-282
Registrando bugs, 364-366 Teste de foco, 203-204
Regras básicas de jogabilidade, 203 Teste de funcionalidades, 349-350
Relacionamento desenvolvedor-publicador, 76-77 Teste de garantia da qualidade, 34-35
Relações públicas (RP), 37-38, 167 Experiência e treinamento, 35
Relatórios de status semanais, 308-310 Líder de testadores de QA, 34-35
Para a equipe de desenvolvimento, 309-310 Testador de QA, 35
Para a gerência, 309-310 Teste linguístico, 349-352
Representação de papéis, 154-155 Testes, 344-345, 349-352
Reprodução, 157 Teste de funcionalidades, 349-350
Requisitos de captura de movimentos, 193-194 Teste linguístico, 349-352
Requisitos de envio para o fabricante do console, Testes de voiceover, 168-169
35, 351-352, 374 Testes externos, 367-369
Requisitos de hardware, 391 TestTrack, 362-363
Requisitos de software, 391 The Essential Drucker, 105-106
Resolvendo conflitos, 134-136 Time-box, 265-266
Responsabilidades do desenvolvedor e do publi- Tiros em primeira pessoa (FPS), 218-219
cador, 77-80 Trabalhando com atores de captura de movimen-
Restrições do design, 224 tos, 197-198
Retendo talentos, 98-101 Trabalhando com equipes pequenas, 258-259
Reunião de exposição, 234-235 Trabalhando com o ESRB, 330-333
Revisões de projeto, 305-307 Trabalhando com o marketing, 202-204
Benefícios, 307 Cronograma de etapas do desenvolvimento,
Conduzindo uma revisão de projeto, 306-307 202
Roteirizando missões, 30 Documentação do jogo, 202-203
Roteiro de voiceover, 158-159 Grupos de foco, 203-204
Trabalhando com publicadores, 82-83
S Trabalhando com recrutadores, 98-99
Scrum, 41-52 Trabalhando com um compositor, 185-189
Desvantagens do Scrum,49-51 Trabalhando com um estúdio de captura de movi-
Scrum e desenvolvimento de jogos, 47-50 mentos, 195-196
SecuROM, 324-325 Solicitações de propostas, 195-196
Segredos comerciais, 62-64 Trabalhando com um licenciador, 68-69
Selecionando líderes, 107-110 Trabalhando com vários ciclos de produção, 4-6
Selecionando tomadas de voiceover, 174-176 Trabalhando com vozes de celebridades, 167
Selecionando um estúdio de som, 162-165 Traduções, 343-344
Solicitações de proposta, 163-165 Tradutores, 347
Serviços de criação, 38 Treinamento, 100-104
Shell da interface de usuário (IU), 180 Conferências e feiras, 102-103
Sincronia labial, 343-344, 347 Informações gerais da indústria de jogos,
Sinopse da história, 226-227 103-104
Sistema de criação de personagens, 30-31, 358 Organizações, 102-103
478 Índice
Recursos de desenvolvimento de jogos, 102-103 Verificando TCRs, 366-368

Treinamento em gerenciamento de pessoas, 22 Vídeos da jogabilidade, 25
Treinamento em gerenciamento de projetos, 22 Visão geral do áudio, 228-229
Trilhas sonoras personalizadas, 181-182 Voiceover provisório, 159-160
Volumes de colisão, 25
U Vozes de celebridades, 167
Unreal, 26, 283 VSC, 333-334
Usando middleware, 284-286
USK, 334-335 W
Walmart, 38
V
Validação do plano, 13 X
Vendas, 38 Xbox 355, 219-220
Guia completo para a produção de jogos digitais, este livro traz todas as infor-
mações que um produtor, um líder de equipe ou um gerente de estúdio precisa
para desenvolver um jogo, do conceito à pós-produção. São apresentados tópicos
gerais – como pré-produção, testes e liberação do código –, bem como tópicos
específicos – como gravações de voiceover e motion capture, tradução e locali-
zação e fornecedores externos. Depoimentos de especialistas da indústria dis-
cutem experiências de profissionais da área e dão exemplos de situações reais. Ao
final do livro, um projeto de jogo fictício ilustra em detalhes o ciclo de produção, a
documentação e muitos outros conceitos do desenvolvimento de jogos digitais.
Alguns tópicos abordados: CONTEÚDO ONLINE

> Os papéis existentes na equipe de produção
> Métodos de gerenciamento de projetos Visite a área de Conteúdo Online do livro
> Informações legais em nosso site, www.bookman.com.br,
> Contratação de pessoal e organização de equipes para acessar livremente os modelos
> Marketing e Relações Públicas apresentados.
> Conceitos, requisitos e planejamento do jogo
> Ciclos de produção
> Kits de fechamento
TI/DESENVOLVIMENTO
www.grupoa.com.br

Manual de Producao de Jogos Dig - Heather M. Chandler

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

Manual de Producao de Jogos Dig - Heather M. Chandler

Enviado por

Direitos autorais:

Formatos disponíveis

PrefAcio de Tom Sloper

C355m Chandler, Heather Maxwell.

Editado também como livro impresso em 2012.

1. Computação. 2. Jogos digitais – Gerenciamento de

Catalogação na publicação: Natascha Helena Franz Hoppen – CRB 10/2150

Capa: Maurício Pamplona

Leitura Final: Sandro Andretta

Gerente Editorial – CESA: Arysinha Jacques Affonso

Editora responsável por esta obra: Mariana Belloli

Editoração eletrônica: Techbooks

Reservados todos os direitos de publicação, em língua portuguesa, à

É proibida a duplicação ou reprodução deste volume, no todo ou em parte, sob quaisquer

Unidade São Paulo

SAC 0800 703-3444 – www.grupoa.com.br

Heather Maxwell Chandler começou a trabalhar na indústria de jogos em 1996. Sua

Heather Maxwell Chandler

Com frequência o papel do produtor é ignorado, não só na promoção do jogo, mas,

Parte I: Visão Geral da Produção 1

Capítulo 1 Visão Geral da Produção de Jogos 3

Capítulo 2 Papéis Existentes na Equipe 17

Capítulo 3 Métodos de Gerenciamento de Projetos 41

Parte II: Informações Comerciais 57

Capítulo 4 Informações Legais 59

Capítulo 5 Relacionamento entre o Desenvolvedor e o Publicador 71

Parte III: Gestão de Pessoas 89

Capítulo 6 Contratando e Mantendo Talentos 91

Capítulo 7 Equipes 105

7.3 Seleção de líderes 108

Capítulo 8 Comunicação Eficaz 129

Parte IV: Produção Técnica 139

Capítulo 9 Jogos On-line Multijogador em Massa 141

Capítulo 10 Voiceover 153

Capítulo 11 Música 179

Capítulo 12 Captura de Movimentos 191

12.4 Preparando uma tomada de captura de movimentos 196

Capítulo 13 Marketing e Relações Públicas 201

Parte V: Pré-produção 213

Capítulo 14 Conceito do Jogo 215

Declaração da missão 225

Capítulo 15 Requisitos do Jogo 237

Capítulo 16 Planejamento do Jogo 257

Parte VI: Produção 289

Capítulo 17 Ciclo de Produção 291

Capítulo 18 Técnicas de Produção 301

Capítulo 19 Criando Builds 319

Capítulo 20 Classificações de Software 327

Capítulo 21 Localização 339

Parte VII: Testes 355

Capítulo 22 Testes 357

22.5 Ciclo de testes 364

Capítulo 23 Liberação do Código 371

Parte VIII: Pós-produção 377

Capítulo 24 Post-mortems 379

Capítulo 25 Kits de Fechamento 387

Apêndice A Estudo de Caso – Ciclo de Produção de Um Jogo 395

Apêndice B Glossário 451

Apêndice C Recursos 455

Apêndice D Biografias 459

A lgumas pessoas podem estar se perguntando quais são exatamente as respon-

• Visão geral da produção de jogos

1.2 Ciclo de produção

Figura 1.1 Ciclo básico de produção de jogos.

um terceiro ciclo criando e adicionando qualquer recurso e asset extra, como

Figura 1.2 Vários ciclos de produção para um único projeto.