Aplicação de Modelos Ágeis e Prescritivos de Processo no

Desenvolvimento de Jogos Eletrônicos: Existe um Melhor?

Abel Bruno Nascimento Silva1
1
Faculdade de Computação
Universidade Federal do Pará (UFPA)
Belém – PA – Brasil
abelbruno@hotmail.com

Abstract. Game development is a non-trivial task, since it is a software

category with a set of specific requirements and singular technological
demands. Several models of development have been found to be more efficient
in the area of electronic games; this paper has the intention make a
comparison between such models to establish the most efficient solution to the
problem in question.

Resumo. Desenvolvimento de jogos eletrônicos é uma tarefa não-trivial, por

se tratar de uma categoria de software com um conjunto de requisitos
específicos e demandas tecnológicas singulares. Diversos modelos de
desenvolvimento têm sido apontados como mais eficientes na área de jogos
eletrônicos; este artigo tem como intuito realizar uma comparação entre tais
modelos a fim de estabelecer a solução mais eficiente para o problema em
questão.

1. Introdução
A crescente busca por entretenimento digital tem sido o motor que impulsiona a rápida
expansão da indústria dos jogos eletrônicos, ou games. Segundo pesquisa da DFC
Intelligente, a receita global da indústria dos games, que foi de US$60,4 bilhões em
2009, passará a valer aproximadamente US$ 77,1 bilhões em 2015 [Reuters 2010].
Tamanho investimento tem tornado o desenvolvimento de jogos cada vez mais
complexo e custoso, fazendo com que jogos modernos e rentáveis necessitem de um
processo de produção que envolva uma equipe especializada para cada área do projeto.
O processo de desenvolvimento de um jogo pode ser segmentado em etapas bem
definidas, como propõe os modelos prescritivos, de análise, projeto, implementação e
teste [Reis 2002]. Por outro lado, os modelos ágeis afirmam que um processo rígido não
se adéqua à natureza subjetiva dos jogos, especialmente os requisitosdo projeto. Assim,
este artigo tem como objetivo realizar uma análise de como tais modelos podem se
aplicar no processo de desenvolvimento de jogos eletrônicos, e com base nesta análise
realizar uma comparação entre os modelos a fim de se estabelecer qual se aplica de
forma mais eficiente ao contexto dos jogos eletrônicos.
O restante do artigo encontra-se organizado como segue. No tópico 2 são
mostradas as principais fases no desenvolvimento de jogos eletrônicos. Os tópicos 3 e 4
enfocam como tais fases podem ser modeladas de formas prescritivas e ágeis
respectivamente, e o tópico 5, por sua vez, realiza uma comparação entre tais modelos.

2. O Processo de Desenvolvimento de Jogos Eletrônicos

Para se construir software de alta qualidade é importante percorrer um processo que
descreva a estrutura das atividades necessárias para tal, trazendo assim controle,
estabilidade e organização para uma atividade que pode, facilmente, tornar-se caótica
[Pressman 2010].
Um jogo eletrônico também é um produto de software, uma aplicação voltada
para o entretenimento digital; e como qualquer outro software complexo, passa por certo
número de fases para o seu desenvolvimento. Segundo Reis et al [2002], as principais
fases do processo de criação dos jogos eletrônicos podem ser definidas da seguinte
maneira:

2.1. Design
Semelhante à fase de análise nos processos prescritivos, a fase de design de um jogo
eletrônico tem como objetivo elucidar as características e requisitos do produto, mas
sem se aprofundar em questões técnicas e de implementação. A grande dificuldade no
levantamento de requisitos para um jogo eletrônico é o problema de constante
volatilidade, ou seja, constantes mudanças e adaptações nos requisitos causadas pelo
avanço tecnológico ou pelo lançamento de outros jogos.

2.2. Projeto
Nesta fase de desenvolvimento a implementação é detalhada e são estabelecidos os
algoritmos, estruturas de dados e tecnologias que serão utilizados no software. A
escolha da tecnologia é uma característica que diferencia os games, pois os seus tipos de
requisitos fazem com que os desenvolvedores busquem constantemente por tecnologias
muito novas.

2.3. Codificação
Geralmente, em todos os projetos de software a fase de codificação exige do
programador conhecimento e capacidade técnica. No caso do programador de jogos
eletrônicos são necessárias algumas características adicionais como: fácil adaptação com
novas tecnologias e saber lidar bem com outros profissionais do projeto como designers,
artistas e escritores.
A utilização de tecnologia de ponta faz com que o desenvolvimento de jogos se
torne um verdadeiro laboratório, onde o programador pode ser obrigado a eliminar
grande parte do seu trabalho devido a não obtenção de um resultado satisfatório.

2.4. Teste
A fase de teste de um game não se limita à busca por erros, mas envolve também testar a
jogabilidade e verificar a aceitação do jogo por parte dos usuários. Para tal, são
utilizadas técnicas de teste como o playtest, onde testadores previamente selecionados
são utilizados. Uma vantagem dessa técnica é que os testadores, além de apontarem os
erros, podem dar informações detalhadas e sugestões de como solucionar o problema.
2.5. Manutenção
Muitas vezes são necessárias atualizações do game, já comercializado, para que defeitos
sejam reparados. Nos jogos para console são poucas as alternativas de atualização; mas
como essas plataformas apresentam poucas variações de hardware e software, uma
extensa fase de testes pode evitar inconvenientes no lançamento de um game. No caso
de jogos para computadores pessoais, mesmo com uma intensa fase de testes, problemas
de compatibilidade acabam aparecendo devido à grande variedade de dispositivos de
hardware e software, fazendo com que seja comum o lançamento de atualizações para
correção neste ambiente.

3. Modelos Prescritivos de Processo no Desenvolvimento de Jogos

Segundo Pressman, na tentativa de colocar ordem no caos do desenvolvimento de
software, foram propostos os modelos prescritivos; e a história indica que a aplicação de
tais métodos no desenvolvimento de software tem trazido resultados razoavelmente
satisfatórios para a engenharia de software. Em um processo prescritivo, os tópicos
dominantes são a ordem e a consistência do projeto.
Mas a aplicação de modelos que buscam ordem e estrutura seria apropriada ao mundo
do software em que as mudanças são quase inevitáveis? Por outro lado, optando por um
processo menos ordenado, seria possível manter certo controle e organização nesse
mundo que está no “limite do caos”? [Nogueira 2000].
A construção de um software complexo, sem um mínimo de controle, tende a
tornar-se caótica até um ponto em que o projeto acaba se tornando inviável. O relatório
Chaos Report feito pelo Standish Group em 2009 indicou que, 24% dos projetos de
software foram cancelados antes de serem finalizados e apenas 32% foram finalizados
no prazo, dentro do orçamento e com escopo completo [Standish 2009]. No caso dos
games a situação não é diferente.
Mesmo que um modelo seja prescritivo, não significa que ele seja estático; os
modelos prescritivos devem ser adaptados à equipe, ao problema e ao projeto para que
possam funcionar de forma satisfatória [Pressman 2010]. Apesar de vários modelos de
processo, os modelos prescritivos geralmente apresentam fases, muito similares ao
processo de um jogo eletrônico, de Análise, Projeto, Implementação e Teste.

3.1. Prototipagem
Muitas vezes o cliente tem uma idéia geral das características e funcionalidades do jogo,
mas muitos requisitos ou detalhes ainda estão incertos ou vagos. O modelo de
prototipagem então, a partir de uma iteração rápida do processo, cria um protótipo do
game que então é avaliado pelo cliente para que os demais requisitos sejam esclarecidos.
O modelo de prototipagem, apesar de ser considerado como outro modelo, pode ser
adaptado a outros modelos.
Os desenvolvedores devem ter conhecimento de que um protótipo tem como
finalidade definir os requisitos, e deve ser descartado logo que seu objetivo tiver sido
alcançado. O que muitas vezes ocorre é a tentativa de fazer com que um protótipo
malfeito se torne um software executável, fazendo com que a qualidade do produto
sofra.
3.2. Rapid Application Development (RAD)
O modelo RAD enfatiza a programação em componentes e permite a uma equipe
desenvolver um sistema dentro de pouco tempo (30-90 dias) [Pressman 2010]. Como os
outros modelos, o processo RAD engloba as fases de desenvolvimento já citadas, sendo
que a fase de implementação utiliza-se de componentes pré-existentes e geração de
código automático.
A fim de que tal modelo seja aplicado no desenvolvimento de um jogo, o game
deve ser modularizado; assim, cada componente do sistema pode ser implementado por
diferentes equipes de programadores; no final deve ser feita a integração de todos os
componentes implementados no sistema. Equipes trabalhando em vários componentes
ao mesmo tempo diminuem o tempo de implementação, possibilitando uma rápida
entrega do software.

3.3. Espiral
O modelo em espiral combina uma natureza iterativa com as fases sistemáticas dos
modelos prescritivos, fornecendo uma base para o desenvolvimento rápido de versões
cada vez mais completas [Pressman 2010].
Utilizando o modelo espiral, uma equipe desenvolve uma versão do software a
cada iteração. Nas primeiras iterações, as versões desenvolvidas podem ser modelos no
papel ou protótipos. Nas últimas iterações já são produzidas versões mais completas e
próximas da versão final. O modelo espiral é uma abordagem mais realista do
comportamento evolucionário do software; ele mantém as fases sistemáticas dos
modelos prescritivos clássicos e os incorpora em uma abordagem iterativa
evolucionária.
Uma boa aplicação desse modelo são os jogos eletrônicos que ao longo de sua
vida irão possuir diversas versões, onde cada volta (ou mais de uma) na espiral poderia
ter como produto uma nova versão do game. A natureza evolucionária do modelo
também facilita na criação de protótipos que podem, na fase de testes, trazer
rapidamente um feedback sobre a jogabilidade e aceitação do jogo que direcionaria o
projeto.

4. Modelos Ágeis de Processo no Desenvolvimento de Jogos

Os métodos ágeis foram criados no esforço de contornarem os problemas encontrados
no desenvolvimento prescritivo de software. Na economia moderna em que o mercado
muda rapidamente, novas tecnologias surgem e ameaças de competição emergem sem
alerta, é praticamente impossível prever o comportamento de um sistema baseado em
computador [Pressman 2010]. Como afirma Jacobson [2002], modificações estão no
coração e na alma do software. Mudanças de requisitos, tecnologias, mercado e de todo
o tipo que possam influenciar no desenvolvimento do software; e uma equipe ágil é
capaz de se ajustar adequadamente a tais mudanças.
Métodos ágeis são frequentemente criticados por supostamente dispensarem a
documentação do software, que é o fundamento da metodologia prescritiva. Na verdade,
o que ocorre é a maior valorização do software funcionando em vez de documentação
abrangente, e da resposta a modificações em vez de se seguir um roteiro [Beck 1999].
Com relação às mudanças, podemos dizer que enquanto os modelos prescritivos tentam
predizer e se precaver, os métodos ágeis se adaptam a elas [Kasperavicius 2008]. Tal
característica fazem com que o emprego de métodos ágeis no desenvolvimento de jogos
eletrônicos seja bem atraente, pois como visto anteriormente, o problema de volatilidade
ocorre com frequência na construção de games.

4.1. Extreme Programming (XP)

O modelo XP é um método ágil que irá, por meio de constante acompanhamento e
ajustes durante o desenvolvimento, desenvolver softwares com requisitos vagos ou em
constante mudança. Seus princípios básicos são feedback rápido, simplicidade,
mudanças incrementais, abraçar mudanças e trabalho de qualidade [Kasperavicius
2008]. Pressman [2010] divide o processo XP da como mostrado na Figura 1:

Figura 1. Fluxograma de um processo XP adaptado de [Pressman 2010].

A atividade de planejamento começa com a criação de histórias que descrevem

as características e funcionalidades do software. Os clientes elaboram histórias e
atribuem prioridades a elas; histórias podem ser criadas ou excluídas a qualquer
momento do projeto. Os membros da equipe XP, junto com os clientes, avaliam como
as histórias podem ser inseridas no próximo incremento do software. A fase de design
de um game se encontra nessa atividade; as histórias conteriam os requisitos do jogo,
com a vantagem de poderem ser adicionados, modificados e excluídos.
Na atividade de projeto XP, um projeto simples é sempre preferível a uma
representação mais complexa. Como o projeto produz pouco ou nenhum produto de
trabalho, ele é visto mais como um artefato provisório que pode e deve ser alterado no
decorrer de todo o processo, sendo feitos, assim, aperfeiçoamentos no projeto. Essa
política aplicada em projetos de games mais sofisticados pode se tornar muito perigosa,
pois se houver uma perda do controle das modificações no projeto, associada a uma
falta de documentação, o projeto pode tornar-se confuso, prejudicando todas as outras
atividades do desenvolvimento.
O modelo XP utiliza um conceito bastante interessante na atividade de
codificação que é a programação em pares, em que os programadores são divididos em
pares e trabalham juntos em uma estação de trabalho de computador para
desenvolverem o código de uma história; quando terminado, o código é integrado ao
trabalho dos outros pares e uma versão para testes é criada. A programação em pares
pode ser facilmente inserida no desenvolvimento de games, cujo código apresenta
diversos módulos que precisam ser integrados; produzindo rapidamente uma versão para
ser testada.
O XP encoraja que testes unitários (testes onde um componente do software é
focado na tentativa de que erros para esse componente sejam encontrados) sejam feitos
antes da atividade de codificação [Pressman 2010]. À medida que os testes unitários são
automatizados e sequenciados, testes diários de integração e validação do sistema
podem ser feitos. Quando uma nova versão é criada pelo processo, a fase de teste de um
game pode ser aplicada, e o feedback pode ajudar no aprimoramento do projeto e das
histórias.
A fase de manutenção no processo de desenvolvimento de um jogo só será
executada quando uma versão do jogo for liberada (release). O projeto de um jogo
geralmente termina quando a versão final do produto é alcançada, mas o projeto de
muitos jogos para computadores pessoais e alguns para consoles pode continuar sendo
aperfeiçoado para outras versões ou extensões.

5. Comparação Entre Modelos: Existe um Melhor?

Como observado, todos os modelos, prescritivos e ágeis, apresentam características que
podem contribuir para desenvolvimento de softwares e características que podem se
tornar prejudiciais ao projeto. Segundo Pressman, o melhor modelo de processo é aquele
que se aproxima da equipe que realizará a engenharia de software; ou seja, uma equipe
deve adaptar um modelo de processo segundo a sua realidade, e não adaptar-se a um
modelo. Para realizar a comparação, será examinado como os dois tipos de métodos se
comportam em relação aos principais problemas enfrentados no desenvolvimento de
jogos eletrônicos: a volatilidade de requisitos e a desorganização do processo.

5.1. O Problema de Volatilidade de Requisitos

Os modelos prescritivos, com sua documentação consistente, fornecem uma base
sólida para que a organização e o controle sejam mantidos ao longo do
desenvolvimento; mas sua rigidez pode ser danosa caso a equipe de desenvolvedores
tente adaptar-se ao modelo, em vez de adaptar o modelo à sua realidade. A necessidade
de requisitos bem definidos faz com que, no caso de jogos eletrônicos onde o problema
de volatilidade é constante, modelos prescritivos dificilmente sejam utilizados [Reis et
al 2002].
Dada a natureza subjetiva de um game, modelos ágeis que adotam a política de
adaptar-se e abraçar mudanças são muito mais aplicados no projeto do software. Outro
fator que faz com que desenvolvedores optem por processos ágeis são os requisitos de
tempos cada vez menores [Kasperavicius 2008]. Tantas semelhanças entre os requisitos
de um game e os de um software, que os modelos ágeis se propõem ser aplicáveis,
vagos e inconsistentes, indicam o porquê de uma maior aceitação de modelos ágeis por
desenvolvedores de jogos eletrônicos.
5.2. O Problema de Desorganização do Processo
Apesar de tantas semelhanças, a importância que os modelos ágeis dão à escrita
do código em detrimento das atividades de análise e projeto pode ser crucial no processo
de desenvolvimento de um game. Uma abordagem ideal, para o caso de jogos
eletrônicos, seria um processo que mescle a natureza iterativa e a organização do
modelo espiral com as idéias de programação aos pares e maior interação com os
interessados proveniente do modelo XP. Agilidade com um pouco de disciplina
[Pressman 2010]. Tal processo poderia criar uma boa documentação que serviria de
estrutura para todo o projeto e permitir o rápido desenvolvimento de protótipos e
versões para avaliação dos clientes e usuários finais.

6. Considerações Finais
Diante da problemática envolvendo o desenvolvimento de jogos eletrônicos em curto
prazo e que satisfaçam requisitos não bem definidos, percebe-se que tal problema
necessita de modelos de desenvolvimento diferentes dos tradicionalmente empregados.
A partir do raciocínio adotado foi possível estabelecer uma relação entre metodologias
ágeis e prescritivas, indicando que uma possível melhor solução seria uma mescla de
qualidades presentes em ambas as metodologias. Muitas pesquisas voltadas para a área
de engenharia de software têm sido realizadas a fim de estabelecer novos métodos de
desenvolvimento mais eficientes, e espera-se que venham a solucionar os problemas
relacionados ao desenvolvimento de jogos eletrônicos.

7. Referências
Kasperavicius, L. et al. (2008) “Ensino de Desenvolvimento de Jogos Digitais Baseado
em Metodologias Ágeis: o Projeto Primeira Habilitação”. In XXVIII Congresso da
Sociedade Brasileira de Computação – Belém, PA
Jacobson, I. (2002) “A Resounding „Yes‟ to Agile Processes – But Also More”. Cutter
IT Journal, vol .15, n. 1, jan.
Pressman, R. S. (2010), Engenharia de Software, tradução Rosângela Ap. D. Penteado,
6ª edição, Porto Alegre: AMGH.
Reis, A. S., Nassu, B. T. e Jonack, M. A. (2002) “Um Estudo Sobre os Processos de
Desenvolvimento de Jogos Eletrônicos (Games)”. Universidade Federal do Paraná –
Departamento de Informática.
Beck, K. et al. (1999) “Manifesto for Agile Software Development”, disponível em:
<http://agilemanifesto.org>, último acesso em: 16 de Junho de 2010
Nogueira, J., Jones, C. e Luqi (2000) “Surfing the Edge of Chaos: Applications to
Software Engineering”. Command and Control Research and Technology
Symposium, Naval Post Graduate School, Monterey, CA. Disponível em:
http://www.dodccrp.org/events/2000_CCRTS/html/pdf_papers/Track_4/075.pdf
Reuters (2010) “Indústria mundial de games movimenta US$ 60 bi por ano”, disponível
em: <http://br.reuters.com/article/internetNews/idBRSPE65E08R20100615>, último
acesso em: 13 de Junho de 2010.
Standish Group (2009) “Chaos Report 2009”, disponível em:
<http://standishgroup.com/newsroom/chaos_2009.php>, último acesso em: 16 de
Junho de 2010.