Artigos Engenharia de Software Desenvolvimento de Jogos: Como documentar seu código

Ter bom conhecimento de uma linguagem específica de programação, ser capaz de escrever códigos de alta complexidade, convenção de nomes, classes, variáveis, etc. são pontos importantes para um profissional da área de criação ou manutenção de software. Além dessas características, é necessário que o profissional tenha outras qualidades que farão grande diferença durante o andamento de um projeto, saber documentar desde a proposta até a entrega do projeto, expor as ideias através de diagramas e fluxos. Elementos estes que ajudaram durante os passos de uma equipe durante o início do desenvolvimento ou durante uma possível manutenção, são importantes no desenvolvimento de qualquer tipo de sistemas, e claro, não poderiam deixar de ser importantes no desenvolvimento de jogos. Neste artigo mostraremos alguns elementos relevantes para uma boa documentação de projeto voltado para jogos, uma breve representação da parte inicial de um projeto a partir da proposta, passando por uma descrição de alguns diagramas e chegando ao início da codificação. O objetivo desse documento não é um detalhamento de uma linguagem específica, de um banco específico e sim as aptidões necessárias para um bom andamento de um projeto de jogo, práticas e situações que são consideráveis no desenvolvimento de qualquer sistema.

Conforme o decorrer desse jogo, cada fase alcançada ficará mais difícil, o jogo tem um perfil de aventura com foco educativo; será para plataforma web com elementos do mundo real. Este jogo é para fins acadêmicos e não comerciais. Serão implementadas funcionalidades como ranking de jogadores e para isso será necessário conexão com um bando de dados.

A principal vantagem desse jogo é que será de fácil entendimento e jogabilidade simples, onde o único objetivo é fazer com que o personagem resgate o máximo de livros com suas limitações de andar para frente, para trás e saltar.

Relato do Processo de Desenvolvimento

A primeira etapa de um projeto é a proposta, momento onde é exposta para o cliente qual a intenção que levou a necessidade do desenvolvimento de um sistema. No PMBOK, que é um manual que descreve um universo de conhecimentos para gerenciamento de projetos, o documento que representa esse momento é o “project charter”. Vamos elencar os passos que fazem parte desse documento.

Passo 1 - Designação: onde são mostradas as responsabilidades e competências de cada envolvido no projeto, onde deve ser descrito exatamente como vai ser sua participação no projeto, exemplo, quem é o gerente do projeto, como ele vai integrar toda equipe, como ele vai cumprir os prazos, etc.

Passo 2 - Escopo: descreve o objetivo metas e custos de todo o projeto. O objetivo é descrever exatamente qual intenção do jogo e o que o jogador terá que fazer para chegar aos limites do jogo. Nas metas, descrever custos e prazos necessários para a gerência, requisitos, desenvolvimentos, testes e encerramento do projeto.

Passo 3 - Premissas: informa o que é indispensável para a realização de todo o trabalho. Exemplo: equipamentos, infraestrutura, softwares e licenças necessárias.Passo 4 - Riscos: a seguir, temos uma tabela simplificada com grupos de risco, suas descrições, e seus níveis (Tabela 1).

Grupo de Riscos Descrição de riscos Nível do Risco
Organização Falta de dedicação total dos funcionários envolvidos no projeto Alto
Análises e capturas de informações erradas fornecidas pelo cliente Baixo
Fundos Exceder o valor estimado para a conclusão do projeto Baixo
Solicitação de empréstimos Baixo
Pessoal Perda de colaboradores relacionados ao projeto Médio
Eliminação de pessoas de nível hierárquico da empresa Alto
Tempo Tempo suficiente para a homologação do Projeto Médio
Riscos do Negócio E se os fundos para o projeto estiverem comprometidos "O que pode garantir fundos adequados"? Baixo
Não foram realizados os pré-requisitos para a implantação do sistema Baixo
Riscos Técnicos O escopo do projeto continua sendo aumentando. Baixo
Solicitação de customizações de programas durante o período de adaptação do sistema Alto
Interface de difícil administração e visualização Baixo
Falta de preparo técnico dos funcionários na utilização do sistema Médio
A solução de o sistema ser muito complexa para a organização. Baixo
Riscos da Tecnologia Danos físicos aos equipamentos de tecnologia Médio
Dependência de suporte técnico de equipamentos com contrato de manutenção Médio
Riscos de dependência externa Suporte com contrato de manutenção não possui componentes para substituição Alto
Legalização de licenças de softwares Baixo
Comprometimento de entrega do hardware com os fornecedores Alto
Tabela 1. Descrição de Grupos de Risco no Desenvolvimento do Jogo (Project Management Docs, 2013 - http://www.projectmanagementdocs.com/)

Passo 5 - Principais fases do projeto: são descritas na Tabela 2 as atividades e o prazo para finalização de cada uma. Assim podemos identificar o início, como está o andamento, se houve atrasos ou não e a finalização de todo o projeto.

Descrição das Atividades propostas para o desenvolvimento do jogo
Tabela 2. Descrição das Atividades propostas para o desenvolvimento do jogo

Passo 6 - Principais envolvidos: indicação da participação de cada envolvido- quem é o gerente, o responsável pelos custos, pelo escopo, riscos, qualidade, etc. Para cada área deve ser indicado o nome do principal envolvido.

Passo 7 - Comentário: breve descrição sobre o desenvolvimento do projeto, no caso desse documento trata-se da prática em projetos de jogos - “O jogo possui uma série de controles e processos que serão desenvolvidos dentro de um curto espaço de tempo e com grande qualidade e tecnologia para exceder as necessidades do patrocinador (sponsor) controlando de forma ágil o processo e proporcionando maior agilidade e qualidade dos participantes do jogo”.

Passo 8 - Cenário: conjunto de informações que darão uma primeira visão do sistema, por exemplo, na interface do sistema devem ser apresentadas as primeiras interfaces, momento onde os patrocinadores terão suas primeiras percepções no que diz respeito ao jogo.

Passo 9 - Diagrama de casos de uso: neste caso demonstraremos um diagrama de casos de uso para a proposta de desenvolvimento de um jogo. Esse diagrama mostra as atividades de um ator dentro do ambiente do jogo, detalha quais as funcionalidades dele e o que o jogador poderá fazer dentro do jogo em questão (Figura 1).

Diagrama de Casos de Uso desenvolvido no contexto do jogo
Figura 1. Diagrama de Casos de Uso desenvolvido no contexto do jogo

Passo 10 - Diagrama de classes: representa as classes necessárias para o desenvolvimento do sistema, muito útil para o programador, pois simplifica a escrita do código e incrementa as funcionalidades descritas no diagrama de casos de uso. No início do desenvolvimento de qualquer sistema, isso é uma fase muito importante, é uma ótima representação gráfica dos códigos em orientação a objetos, e também um primeiro esboço das funcionalidades de um programa, e claro, não poderia deixar de ser menos importante no desenvolvimento de um jogo (Figura 2).

Diagrama de Classes desenvolvido no contexto do jogo
Figura 2. Diagrama de Classes desenvolvido no contexto do jogo

Passo 11 - Tabela de requisitos: trata-se da tabela com informações e requisitos necessários para o funcionamento correto do sistema (Tabela 3). Funcionalidades estas que envolvem a segurança do sistema (controle de acesso, validação de usuário, etc.), funcionalidades de configuração, etc.

Definição de Requisitos Funcionais e Não-Funcionais Associados no Contexto do Jogo
Tabela 3. Definição de Requisitos Funcionais e Não-Funcionais Associados no Contexto do Jogo, baseado no Processo Unificado – UP (Wazlawick, 2013)

Passo 12 - Um sistema geralmente tem conexão com um bom banco de dados. O projeto inicial de um BD é feito através do Diagrama Entidade Relacionamento (DER). Com esse diagrama em mãos é possível entender o processo de normatização do banco. Na Figura 3 temos um simples DER com script SQL. No caso de um jogo simples, geralmente essas informações só dizem respeito à parte de controle de acesso e andamento do jogo. Na figura consta a parte de usuário e navegação no contexto do jogo.

Diagrama Entidade Relacionamento desenvolvido no contexto do jogo
Figura 3. Diagrama Entidade Relacionamento desenvolvido no contexto do jogo

Na Listagem 1 temos um script SQL para banco de dados MySQL, que implementa o diagrama entidade relacionamento (DER) descrito anteriormente. 


 CREATE SCHEMA IF NOT EXISTS `DBJogoEscola` DEFAULT CHARACTER SET utf8
 COLLATE utf8_general_ci ;
 USE `DBJogoEscola` ;
 
 CREATE TABLE IF NOT EXISTS `DBJogoEscola`.`estagio ` (
 `idestagio ` INT NOT NULL,
 `fase` VARCHAR(8) NOT NULL,
 `pontuacao ` INT NOT NULL,
 `vidas ` INT NOT NULL, PRIMARY KEY (`idestagio `))
 ENGINE = Inno DB;
 
 CREATE TABLE IF NOT EXISTS `DBJogoEscola`.`save` (
 `idsave` INT NOT NULL,
 `data` DATETIME NOT NULL,
 `descricao` VARCHAR(20) NOT NULL,
 `idestagio ` INT NULL,
 PRIMARY KEY (`idsave`),
 INDEX `fk_save_estagio_idx` (`idestagio` ASC),
 CONSTRAINT `fk_save_estagio `
 FOREIGN  KEY (`ides tagio `)
 REFERENCES `DBJogoEsco la`.`estagio` (`idestagio `)
 ON DELETE NO ACTION
 ON UPDATE NO ACTION)
 ENGINE = Inno DB;
 
 CREATE TABLE IF NOT EXISTS `DBJogoEscola`.`usuario` (
 `idusuario ` INT NOT NULL,
 `nome` VARCHAR(10 ) NOT NULL,
 `ids ave` INT NULL, 
 PRIMARY KEY (`idus uario `),
 INDEX `fk_usuario _save_idx` (`idsave` ASC),
 CONSTRAINT `fk_usuario_save`
 FOREIGN KEY (`idsave`)
 REFERENCES `DBJogoEscola`.`save` (`ids ave`)
 ON DELETE NO ACTION
 ON UPDATE NO ACTION)
 ENGINE = InnoDB;
 
 SET SQL_MODE=@OLD_SQL_MODE;
 SET FOREIGN_KEY_CHECKS=@OLD_FO REIGN_KEY_CHECKS; 
 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
Listagem 1. Script SQL para criação das tabelas de banco de dados do jogo

Passo 13 - Para finalizar, na Figura 4 temos um fluxograma que trata-se de uma prática que auxilia na programação. Basicamente envolve a lógica do funcionamento do sistema através de um diagrama.

Fluxograma representando o funcionamento do jogo
Figura 4. Fluxograma representando o funcionamento do jogo

Uma boa documentação reduz riscos em momentos iniciais do projeto e facilita a manutenção, é útil também na integração de novos profissionais. Boas práticas no desenvolvimento de qualquer sistema são sempre bem vindas e lógico que as técnicas não param por aqui, existem muitas outras técnicas e benefícios relacionados a cada um dos itens que discutimos aqui; este artigo dá apenas uma visão de uma pequena parte das práticas necessárias para um bom desenvolvimento de um projeto.