Metodologia de-desenvolvimento-do-game-bt

165 views

Published on

Desenvolvimento de games e outras ferramentas

Published in: Education
  • Be the first to comment

  • Be the first to like this

Metodologia de-desenvolvimento-do-game-bt

  1. 1. Metodologia de desenvolvimento do game Brasilia Tropicalis Metodologia de desenvolvimento do game Brasília Tropicalis Autor: Paulo Mattos Empresa: www.olympya.com.br
  2. 2. Metodologia de desenvolvimento do game Brasilia Tropicalis Metodologia: A metodologia documentada neste artigo esta sendo usada no desenvolvimento do game Brasilia Tropicalis. As principais práticas da metodologia adotada estão documentadas a seguir. Itens 1. Gerência do projeto 2. Game design & Arte digital 3. Engenharia de software 4. Negócios & Marketing 5. Softwares & Linguagens Gerência do projeto As principais práticas gerênciais estão documentadas a seguir. Core developers. O núcleo do projeto será composto pelos seguintes desenvolvedores: Programador líder; Artista líder; Game designer líder; Gerente de projeto. Visando maximizar a eficiência deste núcleo, as seguintes condições serão impostas (aos 4 membros acima): trabalho essencialmente presencial na Olympya Software - www.olympya.com (na Barra da Tijuca); checkpoints presenciais a cada dois dias (na Olympya Software); dedicação exclusiva ao projeto nos primeiros 90 dias (no mínimo). Os demais membros estarão divididos entre UFF, Aiyra e AZMT. Cronogramas online e adaptáveis. As inúmeras tarefas necessárias durante todo o ciclo de desenvolvimento (ex., novas funções, registro de problemas, etc) serão definidas e acompanhadas com auxílio de uma ferramenta dedicada. A ferramenta escolhida foi o FogBugz, viabilizando a publicação online de tais tarefas e conferindo transparência ao processo de desenvolvimento. Reuniões semanais da staff. A cada semana será realizada uma reunião, na sede da Olympya Software, para discussão de issues técnicos do desenvolvimento do projeto. Idealmente, toda equipe técnica deveria comparecer a tal reunião. (Visando simplificar a logística, a reunião ocorrerá sempre num dia de semana fixo, a ser definido.) Reuniões quinzenais da staff e coordenadores. A cada 15 dias será realizada uma reunião, também na sede da Olympya Software, para discussão de issues significativos/macros do projeto, além da completa exposição do estado atual do produto. Idealmente, toda equipe técnica assim como os coordenadores deveriam comparecer a tal reunião. Nesta ocasião, o último build quinzenal também será distribuído (e instalado) para todos os envolvidos (em seus respectivos iPhones e/ou iPods touch). Esta reunião poderá ser executada num dia diferente da reunião semanal explicada anteriormente, visando assim aumentar a qualidade/rendimento da mesma. (A empresa Olympya Software já dispõe de uma sala de reunião com capacidade para 10-15 pessoas, logo infra-estrutura física não será problema.) Game design & Arte digital As principais práticas de design e artes estão documentadas a seguir. Design document. Todas as informações de game design (ex., mecânicas, personagens, fases, etc) estarão documentadas num conjunto interligado de wikis dentro do FogBugz. Tal documentação será a base do projeto, devendo assim estar sempre atualizada.
  3. 3. Metodologia de desenvolvimento do game Brasilia Tropicalis Comentários e sugestões sobre o game design deverão ser registradas em cases individuais (do FogBugz) e delegadas para o game designer. Já as discussões mais amplas deverão, preferencialmente, serem conduzidas no fórum FogBugz do projeto. Em especial, tal prática evitaria a acumulação de ruído nos cases do projeto. Art bible. Os principais elementos artísticos do game (ex., concepts, cores, etc) deverão ser explicitamente documentados. Estes documentos também serão mantidos em wikis do FogBugz, capitalizando assim nas mesmas vantagens mencionadas anteriormente. Feedback contínuo. Todo release interno expressivo do produto será informalmente apresentado a um pequeno grupo de entusiastas (representativos do público alvo). Engenharia de software As principais práticas técnicas estão documentadas a seguir. Especificações técnicas de alto-nível. Assim como os design docs, todos os elementos técnicos de alto- nível (ex., arquitetura técnica, modelos matemáticos, algoritmos especiais, etc) serão documentados em wikis. Especificações técnicas de baixo-nível. Todos os módulos do software terão atributos bem definidos de documentação técnica embutidas (i.e., comentários especiais dentro do código). A documentation tool usada para tal será o Doxygen. A geração de tal documentação estará integrada ao processo de builda utomático. Convenções de programação. Curto documento resumindo as principais convenções a serem seguida em cada uma das linguagens de programação adotadas no projeto. Um exemplo (externo) deste documento poder ser consultado aqui. Builds automáticos. Parte expressiva dos passos necessários para geração de um novo build deverão ser automatizadas a medida do possível. A build tool usada para tal será o (amazing!) SCons. Testes automáticos. Todos os módulos do software serão acompanhados de uma bateria de unit tests,os quais serão re-executados a cada novo build do software (de forma automática). Em particular, tal prática visa a detecção automática de erros regressivos, conferindo robustez aos builds quinzenais mencionados a seguir. Builds quinzenais internos. A cada 15 dias, no máximo, um novo build do software será liberado para validações/testes internos. Em particular, será função do game designer aferir constantemente a usabilidade e jogabilidade do game a cada novo build. Nestes builds o game designer também terá oportunidade de verificar a fidelidade artística do produto quando comparada aos art concepts originais, e ajustá-los quando necessário. Negócios & Marketing As principais práticas/estratégias de negócios estão documentadas a seguir. Releases comerciais intermediários. Além do release comercial planejado para o final do projeto, tentaremos também atingir versões intermediárias, funcionalmente estáveis e completas, que poderão eventualmente serem liberadas na App Store. Além da possibilidade de receita, a outra motivação aqui é viabilizarmos um mecanismo de feedback contínuo, prática esta já explicada anteriormente, porém em escala global controlável. Fomentação da comunidade online. Será papel contínuo do game designer incitar interesse pelo produto ao longo de todo seu ciclo de desenvolvimento. Em especial, tentaremos capitalizar na crescente relevância das redes sociais no público alvo do produto (ex., Orkut, Facebook, Twitter, etc). Softwares & Linguagens Os principais softwares a serem usados ao longo do desenvolvimento estão listados (e brevemente justificados) a seguir.
  4. 4. Metodologia de desenvolvimento do game Brasilia Tropicalis Unity iPhone, middleware base do game; Subversion , controle de versão para código e arte; FogBugz , software para gerência de projeto online; SCons , ferramenta para build do game; TextMate , editor de código para Mac OS X; Versions , cliente subversion para Mac OS X; Mac OS (Snow Leopard), sistema operacional pré-requisito para Unity iPhone; Adobe Photoshop , criação e edição de imagens; Autodesk 3ds Max, autoria de conteúdo 3d. As principais linguagens de programação adotadas serão: C# , programação de gameplay e etc, porém sujeito as idiossincrasias do Unity iPhone; Objective-C , linguagem nativa da plataforma iPhone; Python , scripts de build e etc; Java , componentes para backend do game. Estratégia de TI. Parte razoável da infra-estrutura de TI do projeto, usada no desenvolvimento, será delegada para fornecedores especializados, visando assim minimizar a ocorrência de erros operacionais ao longo da execução do projeto. Click aqui e Veja os Produtos e Games da Olympya Software Click aqui no slide share e veja dados e recomendações Segurança, Produtividade e Bugs o desafio da nossa era Dica não relacionada a produtos e ou serviços da Olympya: Ganhe dinheiro na internet sem sair da sua cadeira e sem nenhum gasto inicial ! Não perca tempo comece a ganhar hoje mesmo! http://www.e-mai.net/prcm29

×