análise de metodologias de desenvolvimento software para jogos

8/12/2019 Anlise de Metodologias de Desenvolvimento software para jogos

1/69


2/69

Anlise de Metodologias de Desenvolvimento de Softwareaplicadas ao Desenvolvimento de Jogos Eletrnicos

2Centro de Informtica - UFPE

Assinaturas

Este Trabalho de Graduao resultado dos esforos do aluno Raphael

Lima Belm de Barros, sob a orientao dos professores Alexandre Marcos Linsde Vasconcelos e Geber Lisboa Ramalho, sob o ttulo de Anlise de Metodologias

de Desenvolvimento de Software aplicadas ao Desenvolvimento de Jogos

Eletrnicos. Todos abaixo esto de acordo com o contedo deste documento

e os resultados deste Trabalho de Graduao.

______________________________________________

Alexandre Marcos Lins de Vasconcelos (Orientador)

______________________________________________Geber Lisboa Ramalho (Co-orientador)

______________________________________________Raphael Lima Belm de Barros(Autor)


3/69



Dedico este trabalho a toda aminha famlia. Em especial aos meuspais, Volney e Elmira por todo o amor,ateno e carinho incondicionais. E a

Luciana pelo amor, amizade ecompanheirismo. Agora e sempre.


4/69



Resumo

O desenvolvimento de jogos eletrnicos tornou-seuma atividade lucrativa e bem-sucedida. Enquanto os

nmeros alcanados provocam otimismo, muitasempresas, principalmente as de pequeno e mdioporte ainda encontram dificuldades em produzir jogosatravs de projetos bem-sucedidos. Isto , projetosque respeitem restries de escopo, cronograma eoramento. Este Trabalho de Graduao prope umaAnlise de Metodologias de desenvolvimento de jogosexistentes na Literatura e utilizadas por EmpresasLocais. Como resultado desta Anlise, ser propostoum Manual de Boas Prticas para Desenvolvimento

de Jogos, que poder ser utilizado por empresas dedesenvolvimento de jogos, principalmente asiniciantes.

Palavras-chave: Engenharia de Software,Metodologias de Desenvolvimento de Software,Entretenimento Digital e Jogos eletrnicos.


5/69



Abstract

The development of video games became a lucrativeand successful activity. While the reached numbers

provoke optimism, a lot of companies, mainly smalland medium companies still have difficulties inproducing games through successful projects. That is,projects on scope, schedule and budget constraints.This Work of Graduation proposes an Analysis ofDevelopment Models for games, existents in theLiterature and used by Local Companies. A GoodPractices Manual for Development will be proposedas a result of this Analysis. This Manual can be usedby Development Game Companies, Specially the

Rookies.

Key words: Software Engineering, SoftwareDevelopment Models, digital entertainment, videogames


6/69



Agradecimentos

Primeiramente, agradeo a Deus por tudo que me foi dado. Sem Elenada somos.

Agradeo a meus pais, Volney e Elmira, por todo amor e apoiooferecidos durante toda a minha vida, em especial durante esse tempo deminha graduao. Agradeo tambm a minha irm, Juliana, por todo o carinhoe companheirismo e a toda a minha famlia, avs, tios e primos.

Agradeo a minha namorada Luciana, por todo respeito, amor ecompreenso. Obrigado por me animar nos momentos de fraqueza.

Agradeo a Alexandre Vasconcelos e Geber, meus orientadores, pelos

ensinamentos passados durante a graduao. Estendo esses agradecimentosa todos os professores do Centro de Informtica.

Agradeo a Joo Paulo, Domingos, Ramonzinho, Roberto, Mozart,Cesar, Diego, Shirley, Grasi, Chico, Antonio, Andrea, Ernani e muitos outrosverdadeiros amigos que formei durante a Graduao. Alm desses, agradeo atodos os outros companheiros de turma, pelas alegrias e dificuldadescompartilhadas.

Peo perdo a todos os outros amigos que no foram citados aqui, por

esquecimento de minha parte.

A todos vocs, um muito obrigado!


7/69



Sumrio

1. Introduo ................................................................................................. 101.1. Objetivos............................................................................................ 101.2. Estrutura do Trabalho ........................................................................ 11

2. Jogos Eletrnicos...................................................................................... 122.1. Evoluo ............................................................................................ 122.2. Mercado de Jogos.............................................................................. 17

3. Projetos de TI............................................................................................ 203.1. Cenrio .............................................................................................. 20

4. Caractersticas Gerais do Desenvolvimento de Jogos.............................. 234.1. Ciclo de Vida de Projeto de Jogos ..................................................... 23

4.1.1. Concepo.................................................................................. 244.1.2. Pr-Produo.............................................................................. 244.1.3. Produo .................................................................................... 254.1.4. Ps-Produo ............................................................................. 254.1.5. Ps-Lanamento......................................................................... 26

4.2. Papis envolvidos .............................................................................. 274.2.1. Produtor ...................................................................................... 274.2.2. Artista.......................................................................................... 274.2.3. Game Designer........................................................................... 284.2.4. Programador ............................................................................... 284.2.5. Engenheiro de udio .................................................................. 294.2.6. Engenheiro de Qualidade ........................................................... 29

5. Metodologias de Desenvolvimento de Jogos............................................ 305.1. Game Waterfall Process .................................................................... 305.2. Extreme Game Development............................................................. 315.3. Game Unified Process ....................................................................... 345.4. Scrum................................................................................................. 35

5.5. Anlise Comparativa.......................................................................... 386. Anlise de Uso na Prtica......................................................................... 416.1. Introduo.......................................................................................... 416.2. As Questes ...................................................................................... 41

7. Consolidao da Anlise........................................................................... 507.1. Anlise de Presena .......................................................................... 507.2. Resultado da Anlise ......................................................................... 51

7.2.1. Artefatos Sugeridos .................................................................... 517.2.2. Prticas sugeridas ...................................................................... 527.2.3. Papis Sugeridos........................................................................ 55

7.3. Pontos em divergncia....................................................................... 568. Concluso ................................................................................................. 58

8.1. Concluses ........................................................................................ 588.2. Trabalhos Futuros.............................................................................. 60

Referncias ...................................................................................................... 62Apndice A Glossrio.................................................................................... 65Apndice B Rational Unified Process............................................................ 66


8/69



ndice de Figuras

Figura 1. Tennis for Two .................................................................................. 13Figura 2. Space War! ....................................................................................... 13

Figura 3. Odyssey ............................................................................................ 14Figura 4. Super Mario Bros. ............................................................................. 15Figura 5. Playstation......................................................................................... 16Figura 6. Sega Saturn...................................................................................... 16Figura 7. Nintendo 64....................................................................................... 16Figura 8. Nintendo DS...................................................................................... 17Figura 9. PSP................................................................................................... 17Figura 10. Tipos de Jogos mais vendidos para consoles................................. 18Figura 11. Tipos de Jogos mais vendidos para computadores. ....................... 18Figura 12. Crescimento do Montante de Vendas (em US$) nos USA.............. 19Figura 13. Chaos Report 94, projetos quanto a sua Resoluo. ...................... 21Figura 14. Extreme Chaos 2001, projetos quanto a sua Resoluo. ............... 22Figura 15. Fases do Ciclo de Vida e Artefatos gerados. .................................. 23Figura 16. Modelo 3D criado no 3D Studio Max ........................................... 28Figura 17. Engine Torque Game Builder, da Garage Games. ......................... 29Figura 18. Fases do Modelo Cascata Tradicional e Adaptado para Jogos ...... 30Figura 19. Prticas do Extreme Programming.................................................. 33Figura 20. Viso Geral do Scrum. .................................................................... 38Figura 21. Grfico de utilizao de artefatos nas empresas ............................ 42Figura 22. Grfico da presena de papis nas empresas ................................ 42Figura 23. Verses de jogos............................................................................. 43Figura 24. Uso de Publicadoras ....................................................................... 43Figura 25. Presena dos Patrocinadores ......................................................... 44

Figura 26. Tamanho das Equipes ................................................................... 44Figura 27. Nmero de Projetos Iterativos......................................................... 45Figura 28. Durao dos ciclos de projetos iterativos........................................ 45Figura 29. Ocorrncia de reunies de retrospectivas de iteraes .................. 46Figura 30. Ocorrncia de Stand-up Meetings................................................... 46Figura 31. Utilizao de profissionais com funes especializadas. ................ 47Figura 32. Presena de equipes auto-organizadas .......................................... 47Figura 33. Momento de realizao de testes no projeto................................... 48Figura 34. Utilizao de UML na modelagem de projetos................................ 48Figura 35. Uso de software de controle de verso ........................................... 49Figura 36. Ferramentas de auxlio comunicao........................................... 49Figura 37. Arquitetura do RUP ......................................................................... 67


9/69



ndice de Tabelas

Tabela 1. Viso Geral do Documento .............................................................. 11Tabela 2. Viso Geral do Documento (Continuao) ....................................... 12

Tabela 3. Princpios do Extreme Game Development...................................... 32Tabela 4. Prticas do Extreme Game Development........................................ 33Tabela 5. Prticas do Extreme Game Development (continuao).................. 34Tabela 6. Artefatos do Scrum........................................................................... 36Tabela 7. Quadro Comparativo Metodologias de desenvolvimento .............. 39Tabela 8. Presena de prticas nas metodologias estudadas ......................... 50Tabela 9. Presena de prticas nas empresas pesquisadas ........................... 51Tabela 10. Quadro-resumo das boas prticas selecionadas............................ 54Tabela 11. Quadro-resumo dos papis identificados. ...................................... 56Tabela 12. Quadro-resumo dos pontos divergentes. ....................................... 58Tabela 13. Disciplinas do RUP......................................................................... 68Tabela 14. Fases do RUP. ............................................................................... 69


10/69



1. Introduo

Na dcada de 70, o desenvolvimento de software no era capaz de

acompanhar o crescimento da demanda e a complexidade dos problemas a

serem resolvidos por este meio [WIKI III]. Surgia ento, como reao a esteacontecimento, a chamada Engenharia de Software, que tinha por objetivo

estabelecer mtodos, tcnicas e mtricas para auxiliar o desenvolvimento e

validao de sistemas.

Hoje, a Engenharia de Software se encontra estabelecida em diversas

reas. Sejam elas mais tradicionais ou recentes, cujo domnio pouco

conhecido ou altamente mutvel. neste ltimo contexto que se insere o

desenvolvimento de jogos eletrnicos.

Apesar de possuir diversas caractersticas inerentes ao desenvolvimento desoftwares e sistemas habituais, o desenvolvimento de jogos possui

caractersticas singulares, a comear pela equipe multidisciplinar que

desenvolve projetos, composta, em sua maioria, por artistas e no apenas

projetistas de software e programadores.

Para atender as necessidades particulares do desenvolvimento dessa

categoria de software, algumas metodologias criadas especialmente para o

domnio, ou adaptada de outras j estabelecidas [FLOOD], so utilizadas por

empresas especializadas em jogos ao redor do mundo.

1.1. Objetivos

O trabalho de graduao a ser desenvolvido tem por finalidade realizar uma

anlise das metodologias de desenvolvimento de jogos eletrnicos utilizadas

por empresas pernambucanas e estrangeiras.

Em um primeiro momento, sero realizadas pesquisas bibliogrficas sobre

as metodologias mais utilizadas pelas empresas que desenvolvem jogos forado Pas. Abordando suas diversas caractersticas, mas mantendo o foco nas

principais prticas realizadas em cada metodologia.

Em seguida, aps coletadas as principais caractersticas das metodologias

utilizadas por empresas a nvel mundial, ser feita uma verificao da adeso a

essas metodologias por parte de algumas empresas presentes no Porto Digital.


11/69



Para isso, ser aplicado um questionrio baseado nos dados coletados na

pesquisa bibliogrfica s empresas de jogos situadas no Porto Digital.

Por fim, as informaes coletadas nas pesquisas bibliogrficas e os

resultados dos questionrios aplicados sero confrontados, gerando assim um

Manual de Boas Prticas para o desenvolvimento de jogos eletrnicos.

1.2. Estrutura do Trabalho

As tabela 1 e 2 abaixo apresentam uma rpida descrio dos captulos

deste documento:

Captulos Nomes Descries

1 Introduo

Introduz ao problema e ao documento

proposto, apresentando seus objetivos e

uma sntese de suas sees.

2 Jogos Eletrnicos

Apresenta uma introduo histrica aos

jogos eletrnicos, do incio ainda em

meados do sculo 20 at os dias atuais.

Ainda neste mesmo captulo so

apresentados nmeros que comprovam a

importncia e relevncia econmica dos

jogos eletrnicos.

3 Projetos de TI

Este captulo ilustra a importncia da

adoo de metodologias no

desenvolvimento de softwares de uma

maneira geral, comprovando inclusive,

atravs de nmeros da indstria de

software.

4

Caractersticas Gerais

do Desenvolvimento

de Jogos

Como o prprio nome sugere, neste

captulo so apresentadas caractersticas

gerais de projeto de desenvolvimento de

jogos. Nele so apresentados papis,

fases e artefatos citados em literatura.

Tabela 1. Viso Geral do Documento


12/69



Captulos Nomes Descries

5

Metodologias de

Desenvolvimento de

Jogos

Aqui sero realizadas anlises sobre

algumas metodologias de

desenvolvimento de jogos encontradas

em bibliografia.

6 Estudo de Caso

Aps terem sido mapeadas, no captulo 5,

hora de verificar se os papis, prticas e

artefatos sugeridos na literatura

correspondem ao praticado nas empresas

do cenrio local de Recife.

7 Consolidao daAnlise

Captulo que sintetiza o estudo realizado

nos 2 captulos anteriores. Neste captulo

so sugeridos os papis, prticas e

artefatos que devem compor o projeto de

desenvolvimento de um jogo.

8 ConclusoConcluses do trabalho e possibilidades

de trabalhos futuros.

Tabela 2. Viso Geral do Documento (Continuao)

2. Jogos EletrnicosEste captulo apresenta, dentro de um contexto histrico, o surgimento e a

evoluo dos jogos eletrnicos at os dias atuais. Alm disso, sero

apresentadas algumas anlises mercadolgicas sobre esta forma de

entretenimento. Todas essas informaes devero servir para uma

contextualizao da rea na qual este trabalho se concentra. Mais ainda para,

auxiliar na ratificao da relevncia deste trabalho.

2.1. Evoluo

Em meados do sculo passado, a iniciativa militar era a principal, e talvez

nica responsvel pela evoluo dos computadores, como conhecemos hoje.

Foi nesse contexto em que surgiu o primeiro jogo eletrnico de que se tem

conhecimento. Tratava-se do Tennis for Two, criado no laboratrio de


13/69



pesquisas militares Brookhaven National Laboratory, nos Estados Unidos. O

jogo era uma simplificao do tnis e era apresentado em uma tela de

Osciloscpio. [WIKI I]

Figura 1. Tennis for Two

Entre 1961 e 1962, um grupo de estudantes do MIT1, liderados por Steve

Russel, desenvolveu um jogo chamado de Space War!. Tratava-se de um jogo

que simulava uma batalha de naves, no espao. O jogo foi desenvolvido no

DEC PDP-1, um computador que custava milhes de dlares na poca.

Embora o esforo despendido e o custo tenham sido grandes, seus criadores

ainda no viam o jogo como uma oportunidade de negcios.

Figura 2. Space War!

1Massachusetts Institute of Technology.


14/69



Com os avanos tecnolgicos evoluindo em grande velocidade, o

Engenheiro Ralph Baer da Sanders Associates comea a criar um jogo que

pudesse sair dos laboratrios e ser jogado em lares comuns. Trabalhando na

idia desde a dcada de 50, apenas em 1971, Ralph consegue firmar um

acordo com a Magnavox, que comea ento a desenvolver o primeiro vdeogame a ser conectado em um televisor, o Odyssey.

Figura 3. Odyssey

Enquanto isso, Nolan Bushnell, percebendo que Main Frames eram muito

caros e grandes, comea a adaptar o jogo Space War! de Russel, criando um

computador dedicado chamado Computer Space. Com o sucesso da idia,

Bushnell comea a comercializar o que se considera hoje como o primeiro

arcade da histria. Mais tarde Bushnell seria o fundador da Atari. [WIKI I]

J na Atari, Bushnell lana o Pong e posteriormente o Tank, ttulos de

bastante sucesso na poca. E ainda na dcada de 70, a Atari viria a ser uma

das maiores empresas de jogos eletrnicos de todos os tempos, principalmente

aps a segunda metade, quando os consoles domsticos comearam a se

tornar populares, com a chegada do Atari2600 ao mercado.

Entre final da dcada de 70 e os primeiros anos da dcada seguinte, outras

empresas passaram a tambm produzir jogos para Arcades e para o Atari2600.

Foi nessa poca que surgiram clssicos como o Space Invaders, Pac-maneDonkey-Kong, apresentando ao mundo empresas como a Midway, Namco,

Sega, SNK e a Nintendo, que viriam ter grande sucesso nas dcadas

posteriores.


15/69


16/69



levou a melhor, principalmente pelo apoio de grandes Softhouses3e pelo fato

da Nintendo ter apostado no antigo formato de cartuchos, enquanto seus

concorrentes utilizavam os cds como mdia.

Figura 5. Playstation Figura 6. Sega Saturn Figura 7. Nintendo 64

J no incio do sculo XXI, chegava ao mercado a 6 gerao de

consoles, os de 128 bits. O primeiro a ser lanado foi o Sega Dreamcast, em

2000. Ele obteve bons resultados at que a Sony anunciou o lanamento do

seu novo console: o Playstation2.

No ano seguinte, a Sega tomou uma importante deciso: abandonou o

mercado de consoles para se dedicar apenas ao desenvolvimento de jogos

para as plataformas existentes. A Sony havia lanado o seu Playstation 2 no

final do ano anterior, continuando a saga de sucesso do seu antecessor. A

Nintendo lana o seu Game Cube, que por medo de pirataria, foi lanado o

Mini-DVD, diferente do playstation2 que utilizava o DVD comum. Ainda nesse

ano, a maior empresa de softwares do mundo entra no mercado de games. A

Microsoft apresenta o seu XBox, tambm compatvel com os DVD e possuindo

tambm um Disco Rgido (HD), que permitia que jogos e msicas fossem

salvos. [WIKI I]

Hoje, o mercado de consoles est em sua 7 gerao. Lanado em 2005, o

XBox 360 da Microsoft inaugura a era. No ano seguinte, o Wii da Nintendo

inaugura uma nova forma de interao em jogos, fazendo com que os

movimentos dos usurios possam ser detectados pelo jogo. A Sony tambm

lana seu novo console, o Playstation 3, que amarga o ltimo lugar em vendas,principalmente pelo alto preo.

Com o crescimento exponencial da Internet, as fabricantes de jogos

apostam tambm na interatividade entre os jogadores, permitindo que

jogadores joguem simultaneamente e de forma cooperativa. So os chamados

3Empresas que desenvolvem jogos.


17/69



Jogos Massivos para Mltiplos jogadores (Mutiplayer Massive Online Role-

Playing Games). O jogo de maior destaque desse segmento o World of

Warcraft.

O terceiro segmento do mercado de jogos, o de consoles portteis, tambm

segue em crescimento. Aqui a disputa se d entre o Nintendo DS e PSP daSony. At o momento, o console da Nintendo vem vencendo facilmente essa

disputa, dentre outras coisas, devido ao baixo preo e a funo Touch Screen,

que permite novas formas de interao entre jogos e jogadores.

Figura 8. Nintendo DS Figura 9. PSP

Como possvel observar, o Mercado de jogos encontra expanso e cada

vez mais, jogadores das mais variadas faixas etrias tem aderido ao

seguimento. A prxima seo apresentar alguns nmeros que apontam a

relevncia deste lucrativo negcio

2.2. Mercado de Jogos

Como dito anteriormente, o mercado de

jogos encontra-se segmentado basicamente e

3 categorias: consoles, computadores,

portteis. E, apesar das altas taxas de

crescimento nas duas ltimas categorias, o mercado de consoles ainda omais lucrativo.

Anualmente, publicada uma pesquisa feita pela Entertainment Software

Association (ESA), associao composta pela maioria das gigantes do setor,

que busca identificar os mais relevantes aspectos com relao ao

desenvolvimento de software voltado para o entretenimento. Na edio de

The video game industry is entering a newera, an era where technology and creativitywill fuse to produce some of the moststunning entertainment of the 21st Century.Decades from now, cultural historians willlook back at this time and say it is when thedefinition of entertainment changed forever.

Douglas Lowenstein, President,EntertainmentSoftware Association


18/69



2006 do ESA Facts foram apresentadas algumas caractersticas acerca do

Mercado de Jogos Eletrnicos. [ESA06]

Nessa pesquisa, dentre outros, foram identificados os estilos de jogos mais

vendidos para consoles e computadores.

Figura 10. Tipos de Jogos mais vendidos para consoles

Figura 11. Tipos de Jogos mais vendidos para computadores.

Ainda na mesma pesquisa, foram apresentados resultados do montante de

vendas de jogos nos ltimos anos, para consoles e computadores, apenas nos

Estados Unidos.


19/69



Figura 12. Crescimento do Montante de Vendas (em US$) nos USA.

Esses e outros nmeros demonstram a relevncia de um mercado que

faturado mais que o de cinema h vrios anos seguidos, nos Estados Unidos.

No Brasil, o mercado segue a mesma tendncia de crescimento.

Em 1995, foi criada a primeira empresa brasileira dedicada exclusivamente

a jogos: a Perceptum. Em 2004, foi criada a Associao Brasileira de

Desenvolvedoras de Jogos (ABRAGAMES) que passou a atuar junto ao

governo e outras empresas para promover o mercado de jogos no pas. De

acordo com levantamento desta, em 2005 o Brasil contava com um quadro de

55 empresas atuando no ramo. A maior parte (77%) das empresas brasileiras

pequena e contam com no mais de 19 funcionrios [SOFTEX].

O faturamento em 2003 foi de R$ 2,39 milhes. Em 2004, este valor subiu

para R$ 4,2 milhes; ou seja, apresentando um crescimento de 79% em

relao ano anterior, mostrando a potencialidade do mercado nacional.

Os dados apresentados neste captulo s reforam a importncia no que diz

respeito gerao de negcios, do segmento de jogos. Apesar dos nmeros

serem impressionantes, as empresas de jogos, principalmente as pequenas e

mdias ainda cometem diversos de execuo em seus projetos. A maioria

destes erros conhecida, inerente do desenvolvimento de softwares..


20/69



3. Projetos de TI

Um projeto de software pode ser comparado ao projeto de uma ponte.

Partindo-se da premissa que o projeto de uma ponte sempre entregue dentro

do cronograma e oramento previstos, portanto bem sucedido. [CHAOS04]Por que o mesmo no acontece aos projetos de Software?

Uma das principais razes para isso o tempo gasto na fase de

planejamento do projeto. Mas a maior de todas so os 3000 anos de

experincia na construo civil, contra cerca de 50 anos do desenvolvimento

de softwares. Alm disso, quando uma ponte cai, as causas da falha ocorrida

so investigadas. Enquanto que, em software, quando um erro ocorre, nem

sempre suas causas so investigadas. Fazendo com que os mesmos erros

sejam cometidos outrora. [CHAOS04]

3.1. Cenrio

Segundo Friedrich Ludwig Bauer, "Engenharia de software a criao e a

utilizao de slidos princpios de engenharia a fim de obter software de

maneira econmica, que seja confivel e que trabalhe eficientemente em

mquinas reais4.

A Engenharia de Software pode ser vista como a aplicao de tecnologias e

prticas multidisciplinares voltadas para a especificao, desenvolvimento e

manuteno de sistemas e softwares. [WIKI II]

Essas tecnologias e prticas vm se desenvolvendo pela dificuldade de

atingir o sucesso em projetos de software. As causas para tamanho estorvo

vo desde a prpria imaturidade da Engenharia de Software como cincia at a

prpria natureza dinmica do domnio.

Observando essas dificuldades encontradas no desenvolvimento de

projetos de software bem-sucedidos, o Standish Group International5

desenvolve, desde 1994, um relatrio sobre projetos de software. Apontando,

dentre outras coisas, a taxa de projetos bem-sucedidos e as principais causas

para o sucesso destes projetos.

4Retirado de: http://pt.wikipedia.org/wiki/Engenharia_Software5http://www.standishgroup.com


21/69



Um dos dados mais relevantes deste relatrio foi a determinao do status

dos projetos de software, em empresas Norte-Americanas. Esses projetos

analisados foram divididos em 3 categorias:

I. Bem-sucedidos: Projetos desenvolvidos com as funcionalidades

planejadas e entregues dentro do oramento e prazos previstos;II. Comprometidos: Projetos que desrespeitaram o escopo,

cronograma ou oramento do projeto;

III. Fracassados: Projetos que foram cancelados em algum ponto de

seu ciclo de desenvolvimento.

No primeiro relatrio, publicado em 1994, foram analisados cerca de 175 mil

projetos e os resultados encontrados foram os seguintes:

16,2%

52,7%

31,1%

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

Bem-sucedidos

Comprometidos

Fracassados

Figura 13. Chaos Report 94, projetos quanto a sua Resoluo.

Em 2001, em seu novo relatrio, o Extreme Chaos, o Standish Group

apresentou novos valores para os cerca de 280 mil projetos analisados:


22/69



28,0%

49,0%

23,0%

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

Bem-sucedidos

Comprometidos

Fracassados

Figura 14. Extreme Chaos 2001, projetos quanto a sua Resoluo.

Analisando os dados apresentados possvel observar que houve uma

melhora no percentual de projetos bem-sucedidos, mesmo que o percentual de

projetos que, de alguma forma, falham em alguma das dimenses planejadas

ainda seja alta (72%).

Esse comportamento se deu pela evoluo de metodologias e ferramentas

de auxlio ao desenvolvimento, pela diminuio da complexidade dos projetos,

dentre outros. importante observar tambm que, alguns desses projetos

podem mascarar os reais resultados apresentados. Na pesquisa realizada

para o relatrio de 2001, alguns gerentes de TI entrevistados afirmaram que,

aps realizar sua melhor estimativa para o projeto, multiplicavam o resultado

por 2 e somavam mais da estimativa. [EXTREME]

A realidade apresenta dados alarmantes em relao ao desenvolvimento de

softwares e o desperdcio de recursos em projetos fracassados. Desde que

foram observados, ainda no sculo passado, diversos problemas que podem

ocorrer no desenvolvimento de um software, tem se investido, dentre outras

coisas, em metodologias e/ou processos especficos de desenvolvimento.

As empresas de jogos tambm caminham para o amadurecimento, neste

sentido. Investindo em criao e/ou adaptao de metodologias especficas

para projetos de desenvolvimento de jogos eletrnicos. Antes de fazer uma

anlise de algumas metodologias para jogo, preciso entender melhor quais

as caractersticas gerais de projetos desta categoria de software.


23/69



4. Caractersticas Gerais do Desenvolvimento de Jogos

Os dados apresentados no captulo anterior demonstram a necessidade de

definio e evoluo de metodologias e ferramentas que auxiliem de alguma

forma o correto desenvolvimento de projetos de software. Tratandoespecificamente do desenvolvimento de jogos, os problemas so

potencializados devido extrema dinamicidade dos fatores de influncia e a

multi-disciplinaridade do domnio.

Neste captulo ser apresentado o ciclo de vida geral de um projeto de

desenvolvimento de jogos e as principais abordagens utilizadas no

desenvolvimento de jogos ao redor do mundo. Analisando, inclusive, os pontos

fracos e fortes de cada uma.

4.1. Ciclo de Vida de Projeto de Jogos

Durante o processo de produo de um jogo, existem 5 fases principais que

compem o seu ciclo de vida: Concepo, Pr-produo, Produo, Ps-

Produo, Ps-Lanamento. [SLOPER]

Figura 15. Fases do Ciclo de Vida e Artefatos gerados.


24/69



4.1.1. Concepo

Na concepo, aps decidir pelo desenvolvimento de um jogo, a empresa

que planeja desenvolv-lo realiza um estudo para atestar a viabilidade

operacional, tcnica, econmica e de cronograma para o projeto. O principal

objetivo desta fase , baseado no conhecimento prvio da empresa

desenvolvedora e caractersticas mercadolgicas, definir o conceito de um jogo

que seja Mercadologicamente bem-sucedido. [SLOPER]

As decises tomadas nesta fase so apresentadas no chamado Documento

Conceitual (Conceptual Document). Aps o Documento Conceitual ter sido

aceito por todas as partes envolvidas o momento de iniciar a fase de

produo propriamente dita. Esta fase costuma ser dividia em 3 outras: Pr-

Produo, Produo e Ps-Produo.

4.1.2. Pr-Produo

Nesta fase so definidos os elementos necessrios para o desenvolvimento

do jogo. aqui que a equipe de desenvolvimento alocada, que termos de

confidencialidade e no-divulgao so assinados e so desenvolvidos 2 dos

principais artefatos necessrios para o desenvolvimento do jogo: o Documento

de Game Design (Game Design Document) e o Documento de Design Tcnico

(Technical Design Document).No documento de Game Design so apresentadas as caractersticas

principais do jogo, como por exemplo, detalhes da dinmica e caractersticas

udio-visuais do jogo. Alm disso, no Game Design que definido um plano de

desenvolvimento para o jogo. No documento de Design Tcnico so

especificados detalhes tcnicos das idias apresentadas do documento de

Game Design. Essa especificao tcnica deve seguir como guia para a

atividade de programao do jogo, identificar os desafios e dificuldades que

podem ser encontradas e as ferramentas de desenvolvimento a serem

utilizadas. Por fim, estas informaes presentes nos 2 documentos citados

devem servir como base para a definio das atividades do processo de

produo do jogo.


25/69


26/69



4.1.5. Ps-Lanamento

Nesta fase so monitoradas as reaes do pblico ao jogo, j presente no

mercado. As aes realizadas nesta fase podem ser divididas em 5 grupos

[CARVALHO]:

1. Suporte s Vendas: O varejista pode ter questionamentos a cerca do

jogo oriundas dos consumidores. Alguns destes questionamentos

podem voltar para a Empresa Publicadora e devem ser respondidos e

analisados. Estes questionamentos podem indicar ameaas e

oportunidades para o jogo e para o modelo de negcio.

2. Suporte ao Consumidor: comum o consumidor final ter dvidas

sobre como usar o jogo. Podem ser dvidas em relao a elementos deconfigurao e instalao. A Empresa Publicadora deve criar canais

para estas dvidas flurem dos consumidores at a Publicadora. Estes

questionamentos podem indicar, por exemplo, falhas na criao do

manual do jogo.

3. Mais verses: A partir da reao do mercado ao ttulo produzido, o

desenvolvedor e a Publicadora podem decidir produzir novas verses do

jogo para outras lnguas (localizao) ou at mesmo para outrasplataformas.

4. Expanses:Para alguns tipos especficos de jogos, o desenvolvedor e

a Publicadora podem aumentar o retorno financeiro de um ttulo ao criar

novas misses, cenrios e personagens para este.

5. Seqncias:Caso o jogo faa um grande sucesso com o pblico-alvo,

talvez seja interessante explorar a idia do jogo em seqncias.


27/69



4.2. Papis envolvidos

Na seo anterior foram apresentadas as principais etapas que compem o

ciclo de vida do desenvolvimento de um jogo. Aps uma rpida descrio das

fases que compem esse ciclo, ficou clara a heterogeneidade de uma equipede desenvolvimento desta categoria. Assim, aqui sero apresentados os

principais papis, no total de 6, assumidos por colaboradores durante o

desenvolvimento de um jogo eletrnico.[OLSEN]

4.2.1. Produtor

O produtor tem um papel semelhante a um gerente de projetos. Ele o

responsvel por planejar e acompanhar o desenvolvimento do projeto,

envolvendo-se em todas as reas e fases do projeto. Ou seja, o Produtor oresponsvel direto pelo sucesso do projeto. Neste caso, entende-se por um

projeto bem-sucedido aquele que termina dentro do escopo previsto,

respeitando restries de custo e de cronograma, satisfazendo ao fim, seu

cliente. [PMBOK]

Por ter responsabilidades semelhantes s de um gerente de projetos, o

produtor costuma ser o responsvel por alocar recursos, estabelecer o

cronograma do projeto, garantir a comunicao da equipe de desenvolvimento,

etc. O Produtor participa ativamente de todas as fases do projeto,

principalmente na fase de Concepo, onde atua ativamente na produo do

Documento Conceitual (Conceptual Document).

4.2.2. Artista

O artista o responsvel por produzir o contedo de arte 2D e 3D do jogo.

Logo, dependendo da especialidade do artista dentro da equipe de

desenvolvimento, ele pode desempenhar atividades como a concepo de

personagens, modelagem 3D, desenho de texturas, etc. Representando a

maioria de uma equipe de desenvolvimento de jogos, os Artistas so os

responsveis por produzir material artstico em adequao ao Documento de

Game Design, proposto na fase de Pr-Produo. [CARVALHO]


28/69



Figura 16. Modelo 3D criado no 3D Studio Max

4.2.3. Game Designer

O Game Designer o responsvel por descrever a histria, os elementos,

caractersticas e fluxos do jogo a ser desenvolvido. Essa atividade requer

criatividade e um grande conhecimento dos jogos existentes. tambm

responsabilidade do Game Designer fazer com que todos os elementos do jogo

sejam dispostos de forma coerente. Todos esses elementos criados pelo Game

Designer so apresentados do Documento de Game Design.

4.2.4. Programador

O programador o responsvel por codificar os elementos responsveis

pela execuo do jogo. Diversas atividades de subreas distintas podem ser

atribudas aos programadores dentro de um jogo: codificao da parte grfica

do jogo, codificao da dinmica/fsica do jogo, codificao do sistema de som

do jogo, etc. Atualmente, as atividades dos programadores tem sido facilitada

pelo uso de Enginese Frameworks.


29/69



Figura 17. Engine Torque Game Builder, da Garage Games.

4.2.5. Engenheiro de udio

O Engenheiro de udio o responsvel por criar as trilha sonora e osefeitos sonoros do jogo. Atuando juntamente com a equipe de artistas, o

Engenheiro de Som responsvel por dar identidade udio-visual ao jogo,

baseando-se no contedo descrito no documento de Game Design.

4.2.6. Engenheiro de Qualidade

O Engenheiro de Qualidade o responsvel por garantir que o jogo

produzido ao final de um projeto possua o nvel de qualidade exigido pelo

Mercado. Ele realiza atividades ligadas a testes de codificao, de usabilidade,

de jogabilidade, etc. Este papel tem ganhado destaque tanto em

desenvolvimento de jogos, quanto no desenvolvimento de outros tipos de

software. Isso se deve, principalmente, pela necessidade de diminuir o nmero

de falhas e conseqentemente, custos de produo.

Aps apresentadas informaes gerais sobre o ciclo de vida, papis e

artefatos de um projeto de desenvolvimento de jogos eletrnicos, ser feito, no

prximo captulo, um estudo mais detalhado das metodologias existentes na

literatura. Sero apresentadas caractersticas peculiares de algumas

metodologias, j que, no geral, todas elas so aderentes s caractersticas

apresentadas neste captulo.


30/69



5. Metodologias de Desenvolvimento de Jogos

Neste captulo sero apresentadas algumas metodologias de

desenvolvimento de jogos, encontradas em literatura. A maioria destas

metodologias surgiu de adaptaes de outras metodologias pr-existentes,como o Extreme Programming e o Rational Unified Process (RUP). Esta

necessidade de adaptao se deve principalmente a 2 aspectos que

concernem projetos de jogos eletrnicos:

I. As equipes de projetos de jogos costumam ser multidisciplinares, onde

programadores e artistas, por exemplo, ento inseridos;

II. Os projetos de desenvolvimento de jogos costumam ser bastante

dinmicos, e altamente susceptveis a mudanas do ambiente e do

negcio;

5.1. Game Waterfall Process

O Processo Cascata para Jogos uma verso adaptada do tradicional

processo de desenvolvimento de sistemas denominado Cascata. Ele foi

batizado com este nome em aluso a uma cascata, onde o fluxo de gua tem

um nico sentido. Assim, analogamente, no modelo Cascata todas as

atividades envolvidas com a produo de um sistema ocorrem de forma

seqencial.

No Processo Cascata adaptado ao desenvolvimento de jogos possvel

observar uma relao direta entre as fases de desenvolvimento previstas no

modelo original e as suas. A figura a seguir apresenta a relao:

Figura 18. Fases do Modelo Cascata Tradicional e Adaptado para Jogos


31/69



Apesar de ainda ser bastante utilizado, tanto o modelo tradicional quanto o

modelo adaptado apresenta srios problemas relacionados produtividade,

manutenibilidade e reposta a mudanas. Isso porque, devido a sua estrutura

seqencial, problemas que poderiam ser resolvidos em fases iniciais do projeto

acabam crescendo e trazendo mais transtornos por serem detectadostardiamente. Esses problemas costumam levar projetos ao fracasso, seja pela

no adequao ao escopo acordado ou pelo estouro de prazo e custos.

5.2. Extreme Game Development

O Extreme Game Development (XGD) uma metodologia gil de

desenvolvimento de jogos, baseado no Extreme Programming (XP).

Basicamente, todos os princpios e a maioria das prticas do XP se aplicam

tambm ao XGD. Mas ento, por que no usar simplesmente o XP? A resposta

simples: como o Extreme Programming foi criado por programadores,

algumas prticas precisam ser adaptadas para os outros papis que compem

uma equipe de desenvolvimento de jogos. (artistas, engenheiros de som, etc.)

A principal motivao que levou ao surgimento do XGD foram os constantes

atrasos presentes no desenvolvimento de jogos em conjunto com as altas

penalidades impostas pelas publicadoras sobre os atrasos. Isto faz com que a

equipe de desenvolvimento trabalhe sobre grande presso e aumenta as

chances da entrega de milestonesinstveis. [CARVALHO]

Assim como o Extreme Programming, o Extreme Game Development se

baseia em 5 princpios ou valores:


32/69



Valor Descrio

Comunicao

A comunicao entre os integrantes da equipe de

suma importncia. Comunicao auxilia na soluo de

problemas e aumenta o sentimento de cooperao

entre a equipe. Alm disso, comunicao direta deveser feita em detrimento a documentos formais.

1 + 1 = 21 + 1 = 21 + 1 = 21 + 1 = 2

SimplicidadeSimplicidade talvez o principal valor do XGD. A lei do

XP e do Extreme Game Development : Faa o item

que funcione, da forma mais simples possvel.

Feedback

Mudanas algo que ocorre durante o projeto.

Feedback o cliente comunicar ao desenvolvedor algo

de novo que ele aprendeu sobre o problema, o

desenvolvedor comunicar ao cliente estimativas, riscos

e melhorias do projeto. A idia que o quo mais cedo

voc sabe, o quanto antes voc pode adaptar. [BECK]

Coragem

Coragem ter aes efetivas para superar

dificuldades. Quando combinada com outros valores,

torna-se uma arma poderosa: coragem para

comunicar, para manter simples e para ouvir o

feedback[BECK].

Respeito

Toda a equipe de desenvolvimento precisa ter respeito

com os demais. preciso que cada um se importe com

o projeto; caso contrrio, no ter como este no

fracassar. Assim como no Extreme Programming, no

Extreme Game Development todos so responsveis

pelo projeto. [BECK]

Tabela 3. Princpios do Extreme Game Development

Para executar o trabalho visando utilizao desses valores, o Extreme

Programming possui um conjunto de prticas. Na prtica, nem todas as

prticas so utilizadas em um mesmo projeto, apenas um subconjunto delas.


33/69



Figura 19. Prticas do Extreme Programming

Assim, o Extreme Game Development manteve algumas dessas prticas,

com poucas ou nenhumas alteraes em relao a sua base, no Extreme

Programming. A tabela abaixo apresenta algumas dessas prticas que foram

mantidas:

Prtica Descrio

Whole Team A equipe deve permanecer coesa em comunicao. A

equipe um todo, e no a soma de foras individuais.

Incremental Design As tarefas (assets) de um jogo devem ser feitas da

forma mais simples possvel, que funcionem

corretamente.

User Stories So pequenas descries das funcionalidades do

jogo, descritas normalmente pelo cliente. Muitas

vezes, que tem esse papel de cliente so as

Publicadoras (Publishers).Weekly Cycle O projeto organizado e planejado para ser

executado em ciclos de curta durao.

Tabela 4. Prticas do Extreme Game Development


34/69


35/69



No projeto que serviu para a gnese do processo, os diversos grupos

existentes na produo do jogo (desenvolvedores, artistas, etc.) utilizaram

diferentes prticas, tanto do XP quanto do RUP. Na prtica, a principal

proposta do GUP unir o foco em iteraes curtas do XP ao foco em iteraes

longas do RUP. Adaptando cada um desses focos s equipes multidisciplinaresenvolvidas no desenvolvimento de um jogo.

5.4. Scrum

O Scrum um processo gil, iterativo e incremental que foca na aceitao

das mudanas que podem ocorrer, principalmente em contextos pouco

definidos. Ele foi primeiramente descrito por Takeuchi e Nonaka em seu

trabalho chamado "The New Product Development Game" e embora no seja

exatamente uma metodologia de desenvolvimento especfica para jogos, vem

sendo usada por algumas empresas ao redor do mundo.

Essa premissa de aceitao das mudanas que podem ocorrer e adaptao

s mesmas vai de encontro a metodologias preditivas, como o RUP. Estas

metodologias, ditas preditivas consideram que possvel prever todas as

necessidades de um processo, antes do mesmo ser executado. [SCHWABER]

Na execuo do Scrum, h um facilitador chamado de Scrum Master.Ele

responsvel basicamente por monitorar a execuo da metodologia e servir

como mediador entre a equipe de desenvolvimento e o Product Owner. Este

ltimo o responsvel, dentro da equipe do projeto, por representar o

patrocinador do projeto. Assim, ele o responsvel por priorizar e acompanhar

as funcionalidades a serem desenvolvidas no projeto.

Alm de definir papis, o Scrum prev tambm a confeco de alguns

artefatos que auxiliam o gerenciamento do projeto. So eles:


36/69



Artefato Descrio

Product Backlog

uma lista das funcionalidades que o produto

deve ter. Estas funcionalidades so priorizadas

pelo Product Owner.

Sprint Backlog

Lista de tarefas a serem realizadas em cada

iterao (sprint) do projeto. Essa lista

normalmente definida em negociao pelo

Product Owner e a equipe de desenvolvimento

Impediment List

Esta lista contm todos os empecilhos

encontrados pela equipe de desenvolvimento,

que a impede de alcanar seus objetivos. Estes

problemas devem ser resolvidos pelo Scrum

Master.

Product Backlog Burn Down

Relatrio contendo as funcionalidades que j

foram completadas. Permite a visualizao do

statusdo projeto como um todo.

Sprint Backlog Burn DownRelatrio contendo as funcionalidades que j

foram completadas em um Sprintespecfico.

Tabela 6. Artefatos do Scrum

Por ltimo, no Scrum, o projeto divido nas seguintes fases: Preparao: Nesta fase so feitas as definies iniciais do projeto

como, por exemplo, o Product Backlog;

Sprint:

o Encontro de Planejamento do Sprint (Sprint Planning

Meeting): Este o primeiro encontro de um Sprint. Aqui o

Product Owner prioriza as funcionalidades presentes no

Product Backlog e define o que deve ser entregue no Sprint

(Incremento do Produto);

o Encontro Dirio do Scrum (Daily Scrum Meeting): Estes

encontros dirios servem para que todos da equipe possam

apresentar ao outros integrantes em que trabalharam, o que


37/69


38/69



A figura abaixo apresenta uma viso geral do Scrum:

Figura 20. Viso Geral do Scrum.

5.5. Anlise Comparativa

Segundo Arajo, em seu trabalho sobre o desenvolvimento de uma

Metodologia gil para Advergames, algumas mtricas podem ser utilizadas

para avaliar metodologias de desenvolvimento de jogos. Em seu trabalho,

essas mtricas foram selecionadas pela adequao e necessidade ao

desenvolvimento desta categoria de jogos, ditos jogos para propaganda. As

mtricas utilizadas foram as seguintes: [ARAJO]

I. Flexibilidade: Qualidade de se adaptar a ambientes dinmicos,

complexos e sujeitos a mudanas do ambiente. Essas caractersticas

representam bem projetos de jogos;

II. Comunicao: Capacidade de manter todos os stakeholders (equipe

de desenvolvimento, patrocinadores, etc.) do projeto em constante

comunicao e focados no objetivo, utilizando para isso mecanismos

eficazes;

III. Suporte Multidisciplinaridade: Capacidade de dar suporte a

equipes compostas por pessoas de formaes e especialidades

diferentes. Como equipes de desenvolvimento de jogos;


39/69



IV. Gerenciamento Descentralizado: Trata-se da capacidade de

distribuir, algumas vezes, o gerenciamento do projeto entre os

colaboradores com maior conhecimento em determinada atividade

ou rea do projeto;

V. Tratamento de Riscos: Capacidade de antever riscos e de possuirum planejamento para os casos em que este risco se concretiza,

podendo responder aos mesmos;

VI. Valor: Qualidade do projeto de apresentar um resultado de valor aos

interessados no projeto, antes de sua finalizao;

VII. Suporte ao Desenvolvimento: Trata-se da capacidade de prover

boas prticas de desenvolvimento para as diversas reas envolvidas

em projetos de jogos.

Game

Waterfall

Process

Extreme Game

DevelopmentScrum

Game Unified

Process

Flexibilidade * **** **** **

Comunicao * **** **** **

Suporte Multidisciplinaridade ** *** *** ***

Gerenciamento

Descentralizado* *** **** **

Tratamento de Risco * ** ** ***

Valor * **** *** **

Suporte aoDesenvolvimento * * * **

*Fraco **Regular ***Bom ****timoTabela 7. Quadro Comparativo Metodologias de desenvolvimento


40/69



Resumo:

I. Game Waterfall Process:apesar de trazer a inovao de prever alguns

artefatos caractersticos do desenvolvimento de jogos, ainda sofre do

engessamento caracterstico do Modelo Cascata original;

II. Extreme Game Development: traz consigo prticas e valores do

Extreme Programmingoriginal. Com isso, apesar de muitas qualidades,

o que a credencia para projetos de desenvolvimento de jogos, algumas

deficincias ainda permanecem. Algumas delas: pouco ou nenhum

planejamento de riscos, prticas no adaptadas aos no-

programadores do projeto, etc.

III. Scrum: outra metodologia gil, esta teve a avaliao bastantesemelhante ao Extreme Game Development, divergindo apenas no

quesito valor, j que, na descrio oficial, as iteraes do Scrum so

mais longas, o que pode representar, em alguns casos, demora na

entrega ao cliente.

IV. Game Unified Process: Apesar do criador desta metodologia afirmar

que esse processo de desenvolvimento une boa prticas do Extreme

Programminge do Rational Unified Process (RUP), no fica claro quaisprticas se aplicam em cada caso, dentro do projeto. Assim sendo, seu

julgamento levou em considerao uma mdia das qualidades e defeitos

de cada metodologia.

Aps terem sido analisadas algumas metodologias presentes na literatura

hora de verificar se essas informaes coletadas se aplicam s empresas

brasileiras, mais especificamente empresas do cenrio Recifence. O prximo

captulo apresenta uma anlise da aderncia dessas empresas s prticas

observadas nas metodologias analisadas neste captulo.


41/69


42/69



Figura 21. Grfico de utilizao de artefatos nas empresas

b) Quais os seguintes papis costumam fazer parte da equipe de

desenvolvimento dos jogos de sua empresa?

Anlise:Nesta questo, as empresas entrevistadas foram quase

unnimes no que diz respeito aos papis presentes em seus

projetos. A observao fica por parte do papel do Produtor, que

para muitos tem a mesma funo de um Gerente, em projetos de

jogos. Assim, possvel considerar que Gerente de Projeto e

Produtor so os mesmos papis, o que garante 100% de

presena nas empresas analisadas.

Figura 22. Grfico da presena de papis nas empresas


43/69



c) Os jogos desenvolvidos por sua empresa costumam sair em que

verses, antes da verso final?

Anlise: Verses Beta e Alpha de jogos diferenciam-se

basicamente pelo fato de que a primeira testada por alguns

jogadores externos, e no apenas pela equipe dedesenvolvimento. A figura 23 abaixo apresenta o resultado.

Figura 23. Verses de jogos

d) O lanamento dos jogos de sua empresa costuma ser feito por

Publicadoras (Publishers)?

Anlise: Publicadoras costumam ser canais de comunicao

nos casos em que empresas de jogos locais desejam lanar seus

jogos no Mercado Internacional. Como a prpria rea fim de

umas das empresas entrevistadas o desenvolvimento de jogos

publicitrios, coerente que uso de Empresa Publicadoras no

sejam uma unanimidade entre os entrevistados.

Figura 24. Uso de Publicadoras


44/69



e) Qual destas frases descreve melhor a participao dos patrocinadores,

durante o processo de desenvolvimento dos projetos realizados em sua

empresa?

Anlise:Ponto crtico no desenvolvimento de softwares em geral,

a participao ativa dos patrocinadores (stakeholders) pode serdeterminante para o sucesso do projeto. A figura 25 apresenta os

resultados das respostas coletadas. Esses resultados

demonstram certa dificuldade em inferir o grau de interao ideal

com os patrocinadores do projeto. Via de regra, quanto maior o

contato com o patrocinador/cliente, maiores so as chances de

sucesso de um projeto.

Figura 25. Presena dos Patrocinadores

f) As equipes de projeto de sua empresa costumam ser compostas por

quantos integrantes?

Anlise:Os dados apresentados pela figura 26 demonstram que

todas as empresas de jogos locais trabalham com equipes

pequenas.

Figura 26. Tamanho das Equipes


45/69



g) Os projetos realizados em sua empresa costumam ser feitos de forma

de forma iterativa? (por exemplo, vrios ciclos de desenvolvimento e

testes)

Anlise: Como era previsto, a maioria das empresas realizaprojetos de forma iterativa. Essa caracterstica se mostra

importante pela necessidade de rpidas respostas a mudanas

que possam ocorrer durante o desenvolvimento.

Figura 27. Nmero de Projetos Iterativos

h) Se voc respondeu Sim para a questo anterior, responda essa: os

ciclos dos projetos da sua empresa costumam ter que durao?

Anlise: Aqui a anlise foi realizada de forma qualitativa. Isso

leva a crer que a percepo da durao dos ciclos de execuo

do projeto pode variar de empresa para empresa. Assim, de umaforma genrica, os ciclos devem ser de curta a mdia durao.

Figura 28. Durao dos ciclos de projetos iterativos


46/69



i) Se voc respondeu Sim na questo g, responda essa: Aps cada

ciclo de desenvolvimento, costumam ocorrer reunies retrospectivas?

(onde os pontos positivos e de possibilidade de melhorias so

discutidos)

Anlise: Reunies de Retrospectivas so importantes para quesejam coletados os pontos positivos e negativos de cada

iterao, para que os acertos so sejam repetidos e os erros

corrigidos nas iteraes seguintes. Todas as empresas

entrevistadas realizam essas reunies.

Figura 29. Ocorrncia de reunies de retrospectivas de iteraes

j) Em sua empresa, so comuns reunies dirias? (stand-up meetings)

Anlise: Mais um tipo de reunio analisada. das empresas

entrevistadas realizam estas reunies, que servem para,rapidamente, manter toda equipe coesa e em comunicao.

Figura 30. Ocorrncia de Stand-up Meetings


47/69


48/69



m) Em que momento do projeto de sua empresa, os testes costumam ser

feitos?

Anlise: unnime a noo de que testes so necessrios para

todo e qualquer software. A figura 33 apresenta resultados que

comprovam apenas que todas as empresas realizam testes noapenas no final do projeto, como no modelo Cascata.

Figura 33. Momento de realizao de testes no projeto

n) Sua empresa costuma utilizar o UML para criar modelos para o projeto?

Anlise:UML tem se mostrado ineficiente para modelar conceitos

de jogos. Em alguns casos, diagramas de estados e de classes

ainda so aplicados. O fato de que, 75% das empresas no

utilizam o UML s comprovam o essa afirmao.

Figura 34. Utilizao de UML na modelagem de projetos


49/69



o) Sua empresa costuma utilizar algum software para controle de verso

(ex.: SVN, CVS, etc.)?

Anlise:Unanimidade entre as empresas de desenvolvimento de

software. Aqui, todas as empresas entrevistadas afirmaram

tambm utilizarem softwarespara controle de verso.

Figura 35. Uso de software de controle de verso

p) Sua empresa costuma utilizar que ferramentas para facilitar a

comunicao da equipe?

Anlise: Todas as empresas se valem de algum artifcio para

manter um canal ativo de comunicao entre seus

colaboradores. O que varia aqui so esses tipos de artifcios

(ferramentas).

Figura 36. Ferramentas de auxlio comunicao


50/69



7. Consolidao da Anlise

Neste captulo sero apresentados os resultados dos estudos apresentados

anteriormente. No captulo 5 foram apresentadas anlises de metodologias de

desenvolvimento de jogos encontradas em bibliografia. J no captulo 6 foramapresentados os resultados de uma pesquisa realizada junto s empresas de

jogos Pernambucanas, a fim de confrontar as prticas observadas nas

metodologias estudadas junto s prticas utilizadas por essas empresas.

Espera-se por tanto, que seja possvel apresentar as prticas mais utilizadas

por empresas de jogos de uma forma geral. Por outro lado, deve-se tambm

apresentar prticas observadas de forma singular em algumas empresas,

justificando, quando cabvel, a no incluso delas no conjunto de boas prticas.

7.1. Anlise de Presena

Nesta seo ser apresentada, de forma concisa, a presena de prticas

nas metodologias estudadas e nas empresas entrevistadas. As tabelas abaixo

apresentam os resultados.

MetodologiasPrticas

GWP XGD Scrum GUP

Desenvolvimento

iterativo

Ausente Presente Presente Presente

Design Incremental Ausente Presente Presente Presente

Stand-up Meetings Ausente Presente Presente No relatado

Integrao contnua Ausente Presente Presente Presente

Cdigo compartilhado No relatado Presente No relatado Presente

Lista de Requisitos7 Presente Presente Presente Presente

Encontro deretrospectiva8

Ausente Ausente Presente Ausente

Testes contnuos Quaseinexistente

Presente ParcialmentePresente

ParcialmentePresente

Envolvimento contnuo

do cliente

Quase

inexistente

Presente Presente Parcialmente

PresenteTabela 8. Presena de prticas nas metodologias estudadas

7 Em algumas metodologias pode ser conhecido como User Stories ou Product Backlog(normalmente presente no Game Design Document).8Encontrado normalmente em metodologias iterativas.


51/69


52/69



II. Documento de Game Design:Este documento define um plano de

desenvolvimento de um jogo e caractersticas udio-visuais do

mesmo. Esse talvez o mais importante artefato desenvolvido para o

projeto de desenvolvimento de um jogo.

III. Documento de Design Tcnico9: Especifica detalhes tcnicos de

implementao das idias descritas no documento de Game Design.

Nele so apresentadas abordagens e ferramentas utilizadas, alm de

possveis dificuldades durante o desenvolvimento do cdigo-fonte do

jogo.

IV. Documento de Arte: Neste documento so apresentados equipe

de arte, detalhes sobre cenrios, personagens e objetos que devem

ser desenvolvidos para o jogo.

V. Documento de Som:Como o anterior apresenta ao Engenheiro de

som ou o responsvel direto pelo som do jogo, detalhes da trilha

sonora e efeitos sonoros que devem ser desenvolvidos para o jogo.

7.2.2. Prticas sugeridas

Ser apresentado a seguir o conjunto de prticas sugeridas como as mais

indicadas para o desenvolvimento de jogos. Vale salientar que, a indicao

dessas prticas no exclui a incluso de outras prticas julgadas

individualmente como necessrias, dentro de uma empresa de jogos.

I. Desenvolvimento iterativo-incremental: Este tipo de

desenvolvimento se caracteriza pela existncia de iteraes de

desenvolvimento do projeto. Ou seja, ao invs do projeto ser em

fases seqenciais ele realizado em rodadas com planejamento,

execuo, testes e integrao. A caracterstica incremental fica por

conta de que, ao fim de cada iterao do projeto, um incremento do

produto final deve ser produzido. Em outras palavras, ao fim de cada

iterao, novas funcionalidades foram acrescidas ao produto.

9Tambm conhecido como Tech Doc.


53/69



II. Stand-up Meetings:Essas reunies de carter rpido ocorrem para

que haja uma maior comunicao entre equipe de desenvolvimento

do projeto. Nela cada integrante da equipe divulga para os demais,

que tarefas foram completadas, que tarefas sero realizadas a seguir

e que impedimentos podem ocorrer.

III. Integrao Contnua: Esta prtica sugere que a integrao das

partes do projeto que foram desenvolvidas deve ser feita de forma

contnua e no apenas ao final de fases de mdio e longo prazo.

Essa prtica faz com que todos trabalhem na verso do projeto mais

atual possvel, fazendo que os integrantes tenham uma melhor viso

do projeto como um todo. Alm de diminuir os riscos de uma

integrao tardia, que costuma ser bastante problemtica.

IV. Lista de Requisitos: Conhecido de formas diferentes nas diversas

metodologias, uma listas das funcionalidades/ caractersticas que o

jogo deve possuir devem ser claras para a todos os stakeholdersdo

projeto. Essas informaes costumam estar contidas no Documento

de Game Design.

V. Encontros de Retrospectiva: Essas reunies tm por objetivo a

troca de experincias entre todos os integrantes da equipe de

desenvolvimento. Nelas, cada integrante descreve os fatos que

considera como pontos positivos ocorridos durante a execuo de

suas tarefas, referentes iterao que acabara de terminar. Alm

disso, so apontados pontos passveis de melhoria para a execuo

das iteraes e projetos subseqentes.

VI. Testes a cada iterao:Caracterstica do desenvolvimento iterativo,

a realizao de testes a cada iterao deve ser tomada comopremissa. Assim, antes de integrar ao projeto, cada indivduo deve

realizar, seguindo aos padres estabelecidos pela empresa, testes

para se certificar que a poro desenvolvida est correta.


54/69



VII. Verso Beta:A verso beta de jogos um releaseanterior a entrega

final do projeto. Nela so realizados tanto teste funcionais quanto

testes de aceitao do jogo. Nesta fase os testes so realizados

tanto pela equipe de desenvolvimento quanto pelos clientes e alguns

potenciais consumidores.

VIII. Uso de softwares para controle de verses: Prtica quase que

unnime em empresas de desenvolvimento de software, o uso de

softwares controle de verso facilitam o controle das diversas

verses de artefatos desenvolvidos durante o projeto. Alm de

permitir que os diversos integrantes da equipe de desenvolvimento

atuem em um mesmo artefato, trabalhando colaborativamente.

IX. Uso de ferramentas de apoio a comunicao: Diversas

ferramentas na Web servem para diminuir fronteiras entre pessoas

interessadas em interagir. Assim o uso dessas ferramentas a fim

tornar a comunicao entre a equipe de um projeto se faz

necessrio. Alguns exemplos dessas ferramentas: Instant

Messengers, ferramentas de vdeo-conferncia, Wiki, blogs, etc.

A tabela 8 abaixo apresenta um resumo das prticas selecionadas.

Prticas

Desenvolvimento iterativo-incremental

Stand-up Meetings

Integrao Contnua

Lista de Requisitos

Encontros de Retrospectivas

Testes a cada iterao

Verso Beta

Uso de softwares de controle de verso

Uso de ferramentas de apoio a comunicao

Tabela 10. Quadro-resumo das boas prticas selecionadas.


55/69



7.2.3. Papis Sugeridos

Por ltimo, aps o estudo, foram identificados alguns papis que devem

assumidos por indivduos de uma equipe de desenvolvimento de jogos. So os

seguintes:

I. Gerente de Projeto (Produtor):Ele o responsvel por planejar e

acompanhar o desenvolvimento do projeto, envolvendo-se em todas

as reas e fases do projeto.

II. Game Designer:O Game Designer o responsvel por descrever a

histria, os elementos, caractersticas e fluxos do jogo a ser

desenvolvido. Essa atividade requer criatividade e um grande

conhecimento dos jogos existentes. tambm responsabilidade doGame Designer fazer com que todos os elementos do jogo sejam

dispostos de forma coerente. Todos esses elementos criados pelo

Game Designer so apresentados do Documento de Game Design.

III. Lder Tcnico: Lder da equipe de programadores. normalmente

responsvel pela definio das abordagens a serem seguidas, para o

desenvolvimento das funcionalidades do jogo.

IV. Programador: o responsvel por codificar os elementos

responsveis pela execuo do jogo. Esses elementos podem ser:

parte grfica do jogo, simulao de fsica, sistema de som, etc.

V. Lder de Arte: Semelhante ao Lder Tcnico responsvel pela

definio das abordagens a serem seguidas, para o desenvolvimento

do contedo de arte do jogo.

VI. Artista:O artista o responsvel por produzir o contedo de arte 2De 3D do jogo. Logo, dependendo da especialidade do artista dentro

da equipe de desenvolvimento, ele pode desempenhar atividades

como a concepo de personagens, modelagem 3D, desenho de

texturas, etc.


56/69



VII. Engenheiro de udio: O Engenheiro de udio o responsvel por

criar as trilha sonora e os efeitos sonoros do jogo. Atuando

juntamente com a equipe de artistas, o Engenheiro de Som

responsvel por dar identidade udio-visual ao jogo, baseando-se no

contedo descrito no documento de Game Design.

A tabela 9 abaixo apresenta um resumo dos papis identificados.

Papis

Gerente de Projeto (Produtor)

Game Designer

Lder Tcnico

Programador

Lder de Arte

Artista

Engenheiro de udio

Tabela 11. Quadro-resumo dos papis identificados.

7.3. Pontos em divergncia

Aps confrontar as informaes coletadas na pesquisa bibliogrfica e no

questionrio foram encontrados alguns pontos de divergncia quanto sprticas, artefatos e papis que devem fazer parte de um projeto de

desenvolvimento de jogos. Essas divergncias fizeram com que algumas

prticas, ditas candidatas a serem inseridas no manual de boas prticas da

seo 7.2, fossem excludas. Em outros casos, apenas houve um equivoco em

relao definio e nomenclatura de alguns pontos. Seguem abaixo os

chamados aqui como pontos de divergncia:

I. Presena de um Produtor: Durante a resposta de alguns

questionrios foram obtidas respostas de que no havia o papel deProdutor na empresa em questo. Porm, segundo a definio, o

produtor tem responsabilidades bastante semelhantes ao dos

Gerentes de Projeto, podendo inclusive, serem considerados

semelhantes. Assim, todas as empresas possuem Gerentes de


57/69



projeto, porm algumas respondero no possurem. Isso apresenta

um simples equvoco de nomenclatura.

II. Dimenso dos ciclos: No questionrio aplicado s empresas foi

levantada a dimenso das iteraes nas empresas de formaqualitativa. Na ocasio as possveis respostas para a dimenso eram

curta, mdia e longa durao. Porm essa percepo temporal

relativa a cada empresa. Na literatura, sugere-se que as iteraes

no sejam muito longas. Porm, o que para algumas empresas, uma

iterao curta tem 1 ms, para outras pode ter a durao de apenas

1 semana.

III. Postmortem: O Documento de Postmortem apresenta, ao final doprojeto, os pontos positivos, negativos e lies aprendidas durante o

projeto. Esse documento deve servir para que, em projetos

posteriores, o nmero erros seja minimizado e o de acertos

maximizado. A maioria das empresas no produz este artefato ao fim

de um projeto, deixando a experincia apenasnas mentes dos seus

participantes. Isso pode se tornar um problema quando um desses

colaboradores resolve sair da empresa.

IV. Documento de Conceito, de Arte e de Som: Durante o

questionrio, muitas empresas afirmaram no possuir alguns desses

documentos. Contudo, o que ocorre algumas vezes que essas

informaes encontram-se inseridas no documento de Game Design.

V. Plano de Testes: Apesar de sugerido da literatura, as empresas

locais no desenvolvem um plano de testes para o jogo a ser

desenvolvido. Normalmente os testes so realizados apenas deforma exploratria, o que pode tornar bastante ineficaz esta prtica.

VI. Verso Alpha: Novamente apenas um problema de nomenclatura.

Todas as empresas afirmaram realizar testes durante a fase de

desenvolvimento. Os testes realizados apenas pela equipe de

desenvolvimento o que caracteriza as verses Alpha de jogos.


58/69



VII. Uso do UML para modelagem do jogo:Mais uma prtica sugerida

na literatura e consagrada em algumas metodologias de

desenvolvimento de software que no comumente aplicada a

empresas de jogos. O no uso do UML se d principalmente pelacaracterstica gil desses projetos e pela prpria deficincia no

modelo, quando utilizado para a modelagem de jogos.

A tabela 10 abaixo apresenta um resumo dos pontos de divergncia

identificados.

Pontos de Divergncia

Presena de um Produtor

Dimenso dos ciclos

Post Morterms

Documento de Conceito, de Arte e de Som

Plano de Testes

Verso Apha

Uso do UML para modelagem do jogo

Tabela 12. Quadro-resumo dos pontos divergentes.

8. Concluso

Este captulo discute as concluses obtidas a partir deste trabalho e sugere

possveis melhorias futuras para tornar este trabalho melhor e mais completo.

8.1. Concluses

O Mercado de jogos eletrnicos um dos mais lucrativos atualmente. Os

bilhes de dlares faturados a cada ano comprovam este fato. Atualmente,alguns projetos de jogos chegam a custar 500 mil dlares, representando um

ponto crtico para o sucesso de algumas organizaes. Assim, torna-se

necessria a implantao de medidas que elevem o nvel de qualidade de

jogos e diminua a taxa de erros de projetos dessa natureza.


59/69



Buscando entender melhor deste notvel Mercado, este trabalho de

graduao foi idealizado para realizar uma anlise de uma abordagem j

consagrada na elevao da qualidade de produtos e servios: processos e

metodologias. Assim, o objetivo deste trabalho a realizao de uma anlise

destas metodologias.No 1 captulo deste documento foram apresentados dados histricos sobre

a indstria de jogos, como surgiram e sua evoluo at os dias atuais. Isso

para tornar o leitor, mais interado sobre o universo de jogos. No captulo

seguinte, foram apresentados dados mercadolgicos sobre a indstria de

jogos. Lendo este captulo, possvel ter uma noo da magnitude deste

mercado bem-sucedido, que vem, por exemplo, faturando mais que a indstria

do Cinema Americano h alguns anos.

No esquecendo que um jogo eletrnico uma categoria de software, o

terceiro captulo apresenta dados que mostram os problemas encontrados em

projetos de jogos em geral. Este captulo, junto aos dois anteriores, justifica a

realizao deste trabalho, mostrando a relevncia da rea de pesquisa e a

necessidade de realizar um trabalho que ele eleve a qualidade de projetos de

desenvolvimento de jogos eletrnicos.

Aps entender aos razes para a realizao deste trabalho, hora de situar

o leitor no universo dos projetos de jogos. O captulo 4 realiza esse trabalho de

introduo, at chegar ao captulo seguinte, onde so analisadas metodologias

de desenvolvimento de jogos existentes em literatura. Aps analisadas estas

metodologias, observando papis, fases, artefatos, dentre outros, hora de

checar se as empresas de jogos nacionais, mais especificamente

pernambucanas esto aderentes s prticas observadas. O sexto captulo

apresenta resultados os questionrios aplicados juntos a estas empresas.

Ao final destas anlises realizadas via literatura e questionrios, foi

realizada uma consolidao dos resultados observados. O stimo captulo

apresenta um Manual de Boas Prticas para o desenvolvimento de jogos.

Este conjunto de prticas o principal produto deste trabalho, tendo o objetivo

de fornecer as empresas de jogos, principalmente as iniciantes, um guia que

pode auxiliar a realizao de projetos bem-sucedidos.

Assim, como principais contribuies deste trabalho podemos enumerar:


60/69


61/69



4. Analisar no somente algumas das prticas, consideradas indicadas

por empresas do setor. E sim realizar tambm, um estudo para

entender melhor o porqu do fato que, algumas das prticas

consagradas no desenvolvimento de softwares de uma forma geral,

no se aplicam a projetos de jogos.


62/69



Referncias

[FLOOD] FLOOD, K. Game Unified Process. Disponvel em:

. Acesso em: 12abr. 2007.

[ARAUJO] ARAJO, A. R. S. Agile Game Process Metodologia gil para

Projetos de Advergames. 2006. 130p. Trabalho de Graduao (Graduao em

Cincias da Computao). Universidade Federal de Pernambuco.

[WIKI I] Wikipdia A Enciclopdia Livre. Histria do Videogame.

Disponvel em: .

Acesso em: 28 abr. 2007

[SOMMERVILLE] SOMMERVILLE, I. Engenharia de Sofware. Addison-

Wesley Press. Edio: 6. Ano: 2003.

[CARVALHO] CARVALHO, G. H. P. Um Modelo Preditivo para

Desenvolvimento de Jogos de Computador. 2006. 102p. Trabalho de

Graduao (Graduao em Cincias da Computao). Universidade Federal de

Pernambuco.

[ESA06] 2006 Essential Facts about Computer and Video Game Industry.

Pesquisa publicada pela Entertainment Softwar

análise de metodologias de desenvolvimento software para jogos

Documents