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 | ||
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.
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).
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).
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.
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.
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;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.
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.
