430 likes | 611 Views
Desenvolvimento de Jogos Um Processo Criativo de Engenharia de Software. Gustavo Henrique ghpc@cin.ufpe.br Nacha Costa ncb@cin.ufpe.br 13 / 07 / 2005 – CIn – UFPE. Jogo: Pacman [1] Plataforma: Atari 2600 (~ $249 – 1977) [9]. Jogo: Super Mario World [3]
E N D
Desenvolvimentode JogosUm Processo Criativo de Engenharia de Software Gustavo Henrique ghpc@cin.ufpe.br Nacha Costa ncb@cin.ufpe.br 13 / 07 / 2005 – CIn – UFPE
Jogo: Pacman [1] Plataforma:Atari 2600 (~ $249 – 1977) [9] { ghpc, ncb } @ cin.ufpe.br
Jogo: Super Mario World [3] Plataforma:Super Nintendo (~ $199 – 1991) [2] [9] { ghpc, ncb } @ cin.ufpe.br
Jogo: Need for Speed [4] Plataforma:Playstation I (~ $299 - 1995) [2] [9] { ghpc, ncb } @ cin.ufpe.br
Jogo: Dead to rights II – Hell to pay [6] Plataforma:Playstation II (~ $299 - 1995) [5] [9] { ghpc, ncb } @ cin.ufpe.br
Jogo: Forza Motorsport [8] Plataforma:Xbox (~ $299 - 2001) [7] [9] { ghpc, ncb } @ cin.ufpe.br
Jogo: Gears of War [8] Plataforma:Xbox 360 (~ $400 - 2005) [3] [9] { ghpc, ncb } @ cin.ufpe.br
Jogo: Killzone 2 [6] Plataforma:Playstation 3 (?? – 2006) [3] [9] { ghpc, ncb } @ cin.ufpe.br
Jogo: Battlefield 2 [6] Plataforma:PC { ghpc, ncb } @ cin.ufpe.br
Algumas Empresas [10] { ghpc, ncb } @ cin.ufpe.br
Desenvolvimento de Jogos [11] Faturamento: US$ 17 bilhões em 2003 [14]Obs.: Maior do que a indústria de cinema. { ghpc, ncb } @ cin.ufpe.br
Cadeia de Valor [15] Subcontratados Dinheiro Desenvolvedor Designer Artista Arquivos de música / arte / etc. Animador Programador Publisher Jogo Relações Públicas Marketing Testador Eng. de som Produção Distribuição Dados para o jogo Dinheiro Detentor de Licenças = Financiador Dados para marketing = Processo criativo { ghpc, ncb } @ cin.ufpe.br
Processo de Desenvolvimento [16] METODOLOGIA DE DESENVOLVIMENTO QUALIDADE PLANEJAMENTO & GERÊNCIA Game Design Desenvolvimento Testes { ghpc, ncb } @ cin.ufpe.br
Processo de Desenvolvimento [16] METODOLOGIA DE DESENVOLVIMENTO QUALIDADE PLANEJAMENTO & GERÊNCIA Game Design Desenvolvimento Testes { ghpc, ncb } @ cin.ufpe.br
XGD [17] • XGD = Extreme Game Development [21] • Uma adaptação do XP para jogos • Foco: criar um produto (jogo) funcional • Várias empresas já utilizam esta metodologia [18] • Motivação: elevado índice de atrasos no desenvolvimento de jogos vs. penalidades severas impostas pelos Publishers [19] • Atrasos [20] • Tecnologia muda muito rapidamente • Freqüentemente os desenvolvedores querem fazer “O” jogo • Publishers freqüentemente mudam seus anseios • XGD: uma maneira de minimizar os atrasos { ghpc, ncb } @ cin.ufpe.br
XGD [17] • Os valores do XP precisam ser preservados no XGD • Simplicidade, comunicação, feedback, coragem • Estórias: ajudam a estimar e identificarrequisitos do jogo • Pequenas descrições de funcionalidades do jogo • Exemplo (PACMAN): • Ao iniciar o jogo, o jogador verá um labirinto, fantasmas dentro deste labirinto, um score na parte inferior do vídeo e a quantidade de vidas (abaixo do score). • Algumas estórias específicas podem ser traduzidas em casos de uso • É possível utilizar UML para modelar unidades críticas do jogo (caso de uso, diagramas de seqüência, diagramas de classes, etc.) • Dificuldades em traduzir práticas do XP para XGD: • Pair-programming (artistas) { ghpc, ncb } @ cin.ufpe.br
XGD [17] { ghpc, ncb } @ cin.ufpe.br
Processo de Desenvolvimento [16] METODOLOGIA DE DESENVOLVIMENTO QUALIDADE PLANEJAMENTO & GERÊNCIA Game Design Desenvolvimento Testes { ghpc, ncb } @ cin.ufpe.br
Qualidade [22] • Documentar o que se espera por qualidade (do processo, do produto, das pessoas) • Utilizar parâmetros mensuráveis • Qualidade do Processo • Documentar o processo de desenvolvimento de jogos • Estabelecer padrões de documentação • Qualidade do Produto • Inspecionar o código durante o desenvolvimento • Realizar testes (unitários, funcionais, de jogabilidade, de usabilidade, etc.) • Qualidade das Pessoas • Prover um ambiente de desenvolvimento confortável • Não deixar o desenvolvedor confundir criar jogos com jogar { ghpc, ncb } @ cin.ufpe.br
Processo de Desenvolvimento [16] METODOLOGIA DE DESENVOLVIMENTO QUALIDADE PLANEJAMENTO & GERÊNCIA Game Design Desenvolvimento Testes { ghpc, ncb } @ cin.ufpe.br
Planejamento & Gerência [23] [24] [25] • Gerenciar / Planejar é uma atividade extremamente crítica no desenvolvimento de jogos • Altograu de interdependência entre recursos e pessoas • É fácil gerar atrasos • Prazosrígidos (planejamento de marketing do Publisher) • Multas severas para atrasos • Programador: implementar movimentação do player • Precisa: do modelo animado do personagem (animador) • Animador: animar o personagem • Precisa: do modelo estático do personagem (modelador) • Modelador: modelar o personagem • Precisa: da arte conceitual do personagem (artista) { ghpc, ncb } @ cin.ufpe.br
Planejamento & Gerência [26] • Essencial: planejar os riscos • Desenvolver jogos depende de • Conhecimento técnico (OpenGL, Processamento Gráfico, etc.) • Alto grau de especialização (Engenheiro de som, etc.) • Subjetividade / intuição (O que irá prover diversão, etc.) vários fatores que potencializam riscos { ghpc, ncb } @ cin.ufpe.br
Planejamento & Gerência [27] • Essencial: organizar asinterdependências [A] Graphics Engine[B] Sound Engine[C] Music Engine[D] Input Engine[E] Gameplay/general programming[F] Physics [G] 2D Artwork[H] 3D Artwork[I] Sound effects[J] Music recording[K] Level Design { ghpc, ncb } @ cin.ufpe.br
Processo de Desenvolvimento [16] METODOLOGIA DE DESENVOLVIMENTO QUALIDADE PLANEJAMENTO & GERÊNCIA Game Design Desenvolvimento Testes { ghpc, ncb } @ cin.ufpe.br
Game Design [15] [28] [29] • Espinha dorsal de projetos de desenvolvimento de jogos • Descrição das características do produto final (jogo) • Objetivos • Apresentar o jogo para o publisher • Motivar e dar objetivos à equipe de desenvolvimento • Unificar a visão da equipe • … • Game design: expressa a visão do jogo, descreve suas características e apresenta um plano de implementação • Essencial produzir um documentoexplicativo e bem estruturado • Documento continuamente atualizado { ghpc, ncb } @ cin.ufpe.br
[31] [32] Game Design [28] [29] [30] • Introdução • Motivação do documento • Objetivos do documento • Público-alvo do documento • Concepção do Jogo • Introdução do jogo • Background do jogo • Descrição do jogo • Principais características • Plataformas (restrições) • Arte conceitual { ghpc, ncb } @ cin.ufpe.br
Estágio 1 Estágio 2a Estágio 2b Estágio Especial Estágio Final Difícil Estágio Final Fácil GameOver Final Game Design [28] [29] [30] • Proposta do Jogo • Análise da concepção do jogo • Análise de mercado • Análise técnica • Análise legal • Custos e projeções de venda • Especificação Funcional • Mecânica do jogo • Fluxo do jogo • Atuação do jogador • Física, IA • GUI • Arte, efeitossonoros e música { ghpc, ncb } @ cin.ufpe.br
Processo de Desenvolvimento [16] METODOLOGIA DE DESENVOLVIMENTO QUALIDADE PLANEJAMENTO & GERÊNCIA Game Design Desenvolvimento Testes { ghpc, ncb } @ cin.ufpe.br
Desenvolvimento [15] [33] • Diablo II [31] • Desenvolvedores (full-time): 40 / Tempo de desenvolvimento: 3 anos • Lançamento: 28 de Junho de 2000 / Plataformas: PC e Macintosh • Tom Clancy's Splinter Cell [34] • Desenvolvedores (full-time): 76 / Tempo de desenvolvimento: 5meses • Lançamento: 28 de Março de 2003 / Plataforma: PlayStation 2 • Final Fantasy VII [15] • Custo: US$ 40milhões / Tempo de desenvolvimento: 3 anos • Asheron’s Call [15] • Tempo de desenvolvimento: 4 anos / Linhas de código: 2 milhões • Não há mais espaço para romantismo no desenvolvimento. • Especificação técnica: classes, padrões de codificação, etc. { ghpc, ncb } @ cin.ufpe.br
Desenvolvimento [35] Design criativo(Planejamento) Design criativo + Estórias Game Design Design técnico (Planejamento) Design técnico Documentode Projeto FIM ImplementaçãoTestes Obs.: O pessoal de arte também está trabalhando! { ghpc, ncb } @ cin.ufpe.br
Desenvolvimento [35] Descrevem tecnicamente como o jogo irá “look, feel, play” Overview Temática Interface Storyboards Protótipos Mecânica do Jogo Design criativo Análise de requisitos Arquitetura do sistema Especificação de módulos Design técnico { ghpc, ncb } @ cin.ufpe.br
Postmortem [36] • Realizar uma análise crítica sobre o processo de desenvolvimento do jogo • Boas práticas vs. Práticas equivocadas • Propagar acertos e não insistir nos erros • Definir um formato padrão • Introdução / Processo de Desenvolvimento / Time de Desenvolvimento / Ferramentas Utilizadas / Práticas certas / Práticas erradas / Dados Numéricos do Projeto / Conclusão • Diablo II [31] Boas Práticas Práticas Equivocadas - Tecnologias vs. Modelos - Grau de detalhes de cada jogador { ghpc, ncb } @ cin.ufpe.br
Critical Stage Analysis (CSA) [37] • "What's wrong with the games that are out there today?“ • Wolfgang Hamann • Postmortem • No final do projeto • Não oferece possibilidade de resolver erros no projeto atual • Ninguém é responsável por corrigir os erros apontados pelo postmortem • Costuma lidar com problemas de alto nível • CSA: busca melhorar o jogo atual examinando o seu progresso em estágios críticosdurante o seu ciclo de desenvolvimento • 5 pontos positivos • 5 pontos negativos • 5 pontos que podem ser melhorados { ghpc, ncb } @ cin.ufpe.br
Processo de Desenvolvimento [16] METODOLOGIA DE DESENVOLVIMENTO QUALIDADE PLANEJAMENTO & GERÊNCIA Game Design Desenvolvimento Testes { ghpc, ncb } @ cin.ufpe.br
Testes [38] • “Sometimes I think of making a videogame as an endless process of fixing thousands of bugs.” • Jamie Fristom Early Alpha Late Alpha Beta { ghpc, ncb } @ cin.ufpe.br
Testes [39] • Jogabilidade + Level Design • Usabilidade • A experiência do jogador está intimamenterelacionada com a usabilidade do jogo • Grande gama de jogos dentro de ummesmo estilo • Jogos de corrida Classificação de problemasde usabilidade [40] { ghpc, ncb } @ cin.ufpe.br
Testes [39] Tipo: Severo Descrição: o player semove muito devagar Tipo: Severo Descrição: não háfeedback indicandoque não é possível pegar algum item Tipo: Severo Descrição: o player pegou uma arma e não notou Tipo: Catastrófico Descrição: uma cor possui vários significados no mapa { ghpc, ncb } @ cin.ufpe.br
Conclusões • Atualmente o mercado de jogos exige um processo criativo de engenharia de software para possibilitar o desenvolvimento de jogos mais complexos e com melhor qualidade • Um processobem definido de desenvolvimento é um diferencial entre consolidar uma empresa de jogos no mercado e a falência • É difícil enunciar um processo único / geral • Cada empresa precisa adaptar a sua realidade / as suas necessidades • Mas o processo nãopodedeixar de sercriativo! [6] { ghpc, ncb } @ cin.ufpe.br
A Referência [16] { ghpc, ncb } @ cin.ufpe.br
Referências • [1] www.answers.com • [2] www.cyberiapc.com • [3] www.gamespot.com • [4] www.vidgames.com/ps/screens/screens.html • [5] www.us.playstation.com • [6] www.finalboss.com • [7] http://xbox-codes.com • [8] http://screenshots.teamxbox.com • [9] www.ps3portal.com/?page=history • [10] http://en.wikipedia.org/wiki/Category:Computer_and_video_game_companies • [11] The State of Game Development in Eastern Europe • [12] U.S. Department of Labor Bureau of Labor Statistics, May 2003 National Occupational Employment and Wage Estimates • [13] 2003 Game Development Salary Survey, CMP Media Inc. • [14] The Economist 2003 • [15] Slides da disciplina de Projeto e Implementação de Jogos 2D do CIn – UFPE • [16] Jeannie Novak, Game Development Essentials: An Introduction { ghpc, ncb } @ cin.ufpe.br
Referências • [17] Thomas Demachy, Extreme Game Development: Right on Time, Every Time • [18] James Fristrom, Treyarch's Spider-Man, Game Developer Magazine, Aug 2002 • [19] Jim Charne, Time is of the Essence, Famous Last Words IGDA column, Dec 2001 • [20] Gamasutra PostMortem Collection • [21] http://www.extremegamedev.org/cgi-bin/wiki.pl • [22] Phillip DeRosa, Top 10 Tips on How to Improve a Game Quality Assurance Department • [23] Jamie Fristrom, Manager In A Strange Land: Dependencies, Part One – Gamasutra Article • [24] Jamie Fristrom, Manager In A Strange Land: Dependencies, Part Two – Gamasutra Article • [25] Tim Ryan, Controlling Chaos in the Development Process • [26] Timothy Ryan, Risk Management With Development Schedules • [27] Jack Hoxley, Critical Path Analysis and Scheduling for Game Development • [28] Tim Ryan, The Anatomy of a Design Document, Part 1 • [29] Tim Ryan, The Anatomy of a Design Document, Part 2 • [30] Documento de game design do jogo Exordium implementado na disciplina de jogos • [31] Postmortem: Blizzard Entertainment's Diablo II • [32] Postmortem: SWAT3: Close Quarters Battle { ghpc, ncb } @ cin.ufpe.br
Referências • [33] Erik Bethke, Structuring Key Design Elements • [34] Postmortem: Tom Clancy's Splinter Cell • [35] Gordon Walton, Bringing Engineering Discipline to Game Development • [36] Gamasutra Postmortem Guidelines • [37] Wolfgang Hamann, Goodbye Postmortems, Hello Critical Stage Analysis • [38] Jamie Fristrom, Production Testing and Bug Tracking • [39] Sauli Laitinen, Better Games Through Usability Evaluation and Testing { ghpc, ncb } @ cin.ufpe.br
Desenvolvimentode JogosUm Processo Criativo de Engenharia de Software Gustavo Henrique ghpc@cin.ufpe.br Nacha Costa ncb@cin.ufpe.br 13 / 07 / 2005 – CIn – UFPE