OPÇÕES E OBJETIVOS

Relato de uma experiência real

Este trabalho fala sobre técnicas para o desenvolvimento de jogos, aplicando-as a realidade de pequenas equipes de desenvolvedores. Essas incluem o desenvolvimento do documento de Game Design, a Engenharia de Software no domínio de jogos digitais e algumas práticas para manter a produtividade da equipe. Este artigo foi escrito especialmente para aqueles que desejam começar, ou que já começaram, a se aventurar no mundo dos Jogos, pois sabemos o quanto é difícil encontrar um caminho nesta área

Atualmente, a realidade dos grupos de desenvolvimento de jogos no nosso país é a de pequenos grupos multidisciplinares, onde existem de três a cinco pessoas trabalhando em um projeto. Vimos que muitas das metodologias (um roteiro de atividades que norteiam a equipe durante o processo de desenvolvimento) apresentadas em livros não se aplicam, ou se aplicam apenas parcialmente a pequenos grupos de desenvolvedores.

Em virtude destas observações, decidimos adaptar estas idéias para pequenos times, utilizando-as no desenvolvimento de um jogo feito por nosso grupo, com três pessoas. E, agora, com o objetivo de expandir ainda mais os conhecimentos na área de desenvolvimento de jogos e estimular a produção acadêmica no assunto, apresentamos este trabalho que mostra uma orientação para pequenas equipes desenvolvedoras de jogos. Desse modo, este artigo apresenta um resumo de como projetar e implementar jogos, sem fazer uso de técnicas que demandem uma grande quantidade de pessoas, sendo escrito especialmente para aqueles que desejam começar, ou que já começaram a se aventurar no mundo dos Jogos, pois sabemos o quanto é difícil encontrar um caminho nesta área.

Metodologias mais rigorosas exigem uma maior quantidade de recursos humanos, principalmente para gerenciar a documentação do sistema, requisitando um maior custo e mais tempo ao desenvolvimento do software. Por isso optamos por utilizar uma variação de uma metodologia ágil (Extreme Game Development - XGD), pois é direcionada a pequenos times e possui uma maior facilidade para o gerenciamento de mudanças de requisitos durante o desenvolvimento do projeto.

A principal documentação durante a implementação do sistema é o documento de Game Design. Tal documento é explorado continuamente como fonte de requisitos para o jogo a ser desenvolvido, pois fornece base para todo o projeto, atuando como uma planta baixa que orienta a equipe da apresentação até o teste final. Embora tudo seja descrito nesse documento, naturalmente podem ocorrer modificações neste durante o progresso de implementação, acrescentando ou removendo itens do documento.

Apesar de ser o principal documento para implementação de jogos, o Game Design deve sempre estar aberto a mudanças, uma vez que mudanças nos requisitos são comuns. Para tanto o documento deve ser compartilhado por toda a equipe. Especificamente, para a nossa pequena equipe, optamos por manter o documento na internet, gerenciando as suas mudanças através de informes aos integrantes sempre que fosse preciso. Outra alternativa sugerida por [SCHUYTEMA] é de manter o documento como um wiki.

Formas de organizar o documento de Game Design são apresentadas em [SCHUYTEMA] e [BATES]. Particularmente, organizamos o nosso documento com base no que foi apresentado em ambos, mesclando algumas partes e retirando outras de menor importância. A proposta utilizada é descrita a seguir e pode ser modificada de acordo com as necessidades do projeto e da equipe desenvolvedora:

• Visão Geral: deve descrever de forma breve a essência do jogo. Contém um resumo da história do jogo, falando sobre os aspectos fundamentais que estão ligados a jogabilidade, sua ambientação, gênero, especificações, etc. Esta parte deve ser objetiva, pois oferece embasamento para os outros pontos do Game Design e será lida por quase todos envolvidos no processo da criação do jogo.
• Contexto do jogo: aqui, o foco é descrever a história do jogo e os ambientes por onde ela se desenrola. Deve-se falar toda a história, de maneira clara e concisa, para garantir o entendimento do que se deseja passar.
• Objetos Essencial: nesta parte, o texto será voltado aos personagens e armas/habilidades. Os personagens são separados em: personagem do jogador, o personagem principal que representa o alter-ego do jogador; personagens aliados, aqueles que contribuem como o jogador durante a história; inimigo principal, o principal personagem que é contra o jogador; sub-chefes, aqueles que aparecem em menor quantidade durante os cenários e representam obstáculos significativos ao jogador; inimigos, são os inimigos comuns que surgem durante o desenrolar da história; NPCs, são os personagens que não atuam diretamente sobre a história do jogador. As armas e habilidades são descritas com todas as especificações de uso e aquisição.
• Conflitos e Soluções: o foco desta seção é como acontecem as interações entre os objetos descritos na seção anterior. Também é levantado como o jogador percebe as interações e os seus resultados. É aconselhável separar os objetos em grandes grupos, por exemplo, no caso de várias habilidades ou armas causarem o mesmo efeito em personagens aliados, este efeito poderia ser descrito de uma maneira geral, sem se prolongar nem repetir o texto.
• Inteligência Artificial: descreve-se o comportamento dos personagens controlados pelo computador. Esta seção do documento não exige que o Game Designer saiba programar a IA, apenas descreve o que ele espera que aconteça em determinadas situações. No entanto, é importante que o Game Designer conheça sua equipe de IA e saiba avaliar o que pode ser possível ou não na implementação.
• Controles: basicamente, deve ser descrito como funcionarão os controles do jogo. Esta descrição vai desde os controles durante o jogo em si, até a seleção de opções no menu.
• Interface: é descrito como será organizada a interface do jogo, tanto os menus iniciais, como a interface de inventários e etc. A interface deve ser coerente, informativa, de fácil acesso e óbvia. Quanto mais simples a interface, melhor ela será. Mostre somente informações vitais sobre o jogo, para facilitar a visão do jogador.
• Nível: o objetivo é descrever os níveis do jogo, seus cenários, arquitetura, objetivos, etc. Aqui é descrito quais inimigos e itens podem ser encontrados no nível e onde eles estarão dispostos. Materiais de abertura e encerramento que sejam necessários devem ser descritos aqui, como vídeos de abertura, notas, músicas, etc.

Uma vez concluído estes tópicos, deve-se sempre conferir se o que está sendo produzido está de acordo com o que foi planejado, se atende as expectativas dos clientes e usuários. Com sua conclusão, também é facilitada a construção de requisitos e características do software, estes por sua vez são organizados e apoiados por técnicas de processos de desenvolvimento de software e modelos de ciclo de vida existentes na área da Engenharia de software.

Segundo Friedrich Ludwig Bauer, Engenharia de Software “é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, confiável (…)”. Algumas das principais deficiências na produção de um software são: o mesmo é produzido por pessoas, os requisitos normalmente são bastante mutáveis e metodologias mais rigorosas necessitam de uma grande quantidade de recursos humanos. Neste contexto, o Extreme Programming (XP) surge com valores de comunicação, simplicidade, feedback e coragem, fornecendo uma abordagem mais ágil e adaptável às dificuldades do desenvolvimento de um software.

De acordo com [PRESSMAN], o processo do XP pode ser resumido em:

• Planejamento: a atividade começa com a criação de um conjunto de histórias (também chamada de histórias de usuário) que descrevem as características e funcionalidades requeridas para o software a ser construído. No domínio de jogos, essas histórias são retiradas, de forma incremental, do documento de Game Design.
• Projeto: o projeto XP segue rigorosamente o princípio KIS (keep it simple – mantenha a simplicidade). Um projeto simples é sempre preferível em relação a uma representação mais complexa. Se um problema de projeto difícil é encontrado como parte do projeto de uma história, o XP recomenda a criação imediata de um protótipo operacional daquela parte do projeto, a intenção é diminuir o risco quando a implementação verdadeira começar. O XP encoraja a refabricação – uma técnica que é também uma técnica de projeto. Especificamente, refabricação pode ser definida como o processo de modificar um sistema de software sem alterar o comportamento externo do código, mas aperfeiçoando a estrutura interna.
• Codificação: O XP recomenda que depois que as histórias forem desenvolvidas e o trabalho preliminar de projeto for feito, a equipe não avance para o código, mas, em vez disso, desenvolva uma série de testes unitários que exercitem cada uma das histórias que devem ser incluídas na versão atual (incremento do software).
• Teste: o teste unitário visa testar uma única classe. Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem. Mas o que seriam as classes de teste unitário? São classes que simulam o uso do sistema, informando dados de entrada e recebendo respostas do mesmo. Basicamente é comparado se a resposta obtida é a esperada.

Porém o XP visa apenas à parte da programação em si, tratando-se de jogos, temos duas frentes de desenvolvimento: o software e o conteúdo. Baseado nesta diferença, a utilização de uma variação do XP é mais adequada.

Outra opção seria utilizar a metodologia Extreme Game Development (XGD). Embora seja uma metodologia muito recente, o XGD estende o XP para trabalhos com equipes multidisciplinares. Estas diferenças estimulam a especialização de papéis do XP, como:

• Produtor: é o equivalente ao cliente em XP, pois é o produtor do jogo quem fornece os requisitos e pode decidir sobre o escopo e a data das versões.
• Desenvolvedores: engloba todos os profissionais da área técnica (game designers, level designers, artistas 2D/3D, animadores e programadores).
• Coach: aparentemente com o mesmo nome de um dos papéis XP, o coach em XGD é o gerente do projeto.
• Distribuidor: ou “Publisher”. É o patrocinador do projeto.

No XGD há também uma modificação no processo de desenvolvimento, incluindo:

• Projeto de interface: oferece capacidade ao software de permitir que o usuário alcance suas metas de interação com o sistema.
• Testes de game design: testes de jogabilidade, de design, balanceamento, harmonia visual entre outros.
• Postmortem prematuro: de acordo com [BASTOS], trata-se de uma reflexão de como o sistema está sendo desenvolvido a cada iteração, permitindo estratégias de venda, mudanças de requisitos e melhoria do software.

As metodologias ágeis abrem mão de uma gama de documentação do software a fim de simplificar o processo. Desse modo, boas práticas são utilizadas para manter o controle de qualidade do processo:

• Design Incremental: Todo o projeto flui de forma iterativa e incremental. A partir disso é necessário definir prioridades para cada iteração. Assim evita-se que quando estivermos implementando uma classe, necessitemos de outra que ainda não foi implementada.
• Ambiente Informativo: Um ambiente informativo é aquele onde as informações sobre o andamento do projeto estão expostas no ambiente de trabalho para que qualquer pessoa envolvida possa se manter informada de forma fácil.
• Ciclo Semanal: A cada semana é realizada uma iteração. Esta prioriza um pequeno conjunto de funcionalidades do software, ao fim de cada iteração o cliente tem a oportunidade de utilizar e avaliar o que foi produzido. Isso permite que a implementação não fuja do que foi especificado no game design e até mesmo uma reavaliação das especificações.
• Programação em Par: Qualquer código deve ser produzindo por dois programadores em um mesmo computador, revezando-se no teclado. Isso aumenta a produtividade e diminui os defeitos, pois existem duas pessoas resolvendo problemas e analisando os possíveis erros no código.
• Sentar-se Junto: Toda a equipe deve estar em uma mesma sala, trabalhado e se comunicando. Algumas vezes também é necessário se isolar um pouco para se concentrar em um problema.

Não é incomum, equipes fazendo horas-extras e perdendo a folga para atingir o prazo. Esse é um caminho perigoso, pois à medida que ficamos cansados aumenta a nossa falta de atenção e conseqüentemente os bugs no código. Assim, o XP possui algumas técnicas para manter um ritmo de trabalho constante:

• Integração Contínua: Deve existir uma base de dados unificada com as últimas versões de cada arquivo. As mudanças devem ser integradas e testadas.
• Trabalho Energizado: Não ultrapassar o limite dos profissionais através da quantidade de horas semanais. Isto mantém uma produtividade boa em toda a equipe.
• Folga: Algumas iterações do projeto devem ser mais fáceis e rápidas de implementar. Isso gera um tempo a mais para implementar códigos atrasados ou adiantar o trabalho da próxima iteração.

Entretanto, com uma equipe pouco experiente nem sempre práticas e bons princípios fornecem segurança ao desenvolvimento de um jogo. Em contrapartida a esta dificuldade, optamos por utilizar documentações-chave:

• Modelo base: contém classes e suas relações possíveis, representando o modelo para o sistema que vai ser desenvolvido. Embora este modelo não seja detalhado e nem sempre seguido à risca, fornece uma orientação para modelagem do sistema durante todas as iterações.
• Documentação sobre modificações no código: visto que nossa equipe não é uma empresa, separar responsabilidades sobre o código a ser desenvolvido é fundamental. Porém, alterações de código constantes podem causar problemas de integração. Visando suprir essa deficiência, optamos por documentar as modificações feitas frequentemente.

Um jogo utilizando essas idéias foi apresentado como projeto de conclusão da disciplina Programação Estruturada e Orientada a Objetos. Ao concluirmos o trabalho, fizemos um apanhado geral das técnicas e de como as adaptamos. Então apresentamos as nossas idéias em forma de uma palestra ao corpo acadêmico do Curso de Ciência da Computação na Universidade Estadual do Ceará.

Este artigo apresentou um resumo de como projetar e implementar jogos, sem fazer uso de técnicas que demandem uma grande quantidade de pessoas. Todas os métodos aqui descritos foram utilizadas por nossa equipe: Marcos, o GameDesigner (Artista e programador auxiliar), Fernando (o “Coach”, Líder Técnico e Designer de Iterações) e Eduardo (Programador Principal, e escritor da história).

Este artigo foi feito especialmente para aqueles que desejam começar, ou que já começaram a se aventurar no mundo dos Jogos, pois sabemos o quanto é difícil encontrar um caminho nesta área.

BASTOS, Abelmon de Oliveira. Mapeamento do Processo de Modelagem em Extreme Programming no domínio de jogos: monografia.

BATES, Bob. Game Design, segunda edição.

Improve it, Práticas do XP

PRESSMAN, Roger. Engenharia de Software, 6ª edição

SCHUYTEMA, Paul. Design de Games, uma abordagem prática.

Wikipedia, Engenharia de Software

Wikipedia, Crise do software

Bugzilla

	Marcos Antonio Moura Brizeno Filho, Graduando em Ciências da Computação pela Universidade Estadual do Ceará – UECE, localizada em Fortaleza, Ceará. Integrante do PET (Programa de Educação Tutorial) de Ciência da Computação e da Célula de Desenvolvimento de Jogos Lemniscata. Experiência em Game Design, Engenharia de software, Programação, Design e Arte Digital 2D.
	Fernando Leonardo Martinez Figueiredo, Graduando em Ciências da Computação pela Universidade Estadual do Ceará – UECE, localizada em Fortaleza, Ceará. Integrante Líder da Célula de Desenvolvimento de Jogos Lemniscata. Experiência em Engenharia de software, Programação, Design, Arte Digital 3D e Engenharia de Som.
	Paulo Eduardo Santos de Sousa, Graduando em Ciências da Computação pela Universidade Estadual do Ceará – UECE, localizada em Fortaleza, Ceará. Integrante da Célula de Desenvolvimento de Jogos Lemniscata. Experiência em Programação e Design.

Esta é uma publicação eletrônica da Sociedade Brasileira de Computação – SBC. Qualquer opinião pessoal não pode ser atribuída como da SBC. A responsabilidade sobre o seu conteúdo e a sua autoria é inteiramente dos autores de cada artigo.