Metodologia do projeto Brasilia

Tropicalis
A metodologia documentada neste artigo esta sendo usada no desenvolvimento do
Brasilia Tropicalis.

As principais práticas da metodologia adotada estão documentadas a seguir.

Contents
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.
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.

Unity iPhone 1.5.1, middleware base do game;

Subversion 1.6, controle de versão para código e arte;
FogBugz 7.2, software para gerência de projeto online;
SCons 1.2, ferramenta para build do game;
TextMate 1.5, editor de código para Mac OS X;
Versions 1.0, cliente subversion para Mac OS X;
Mac OS X 10.6.2 (Snow Leopard), sistema operacional pré-requisito para Unity iPhone;
Adobe Photoshop CS4, criação e edição de imagens;
Autodesk 3ds Max 2010, autoria de conteúdo 3d.

As principais linguagens de programação adotadas serão:

C# 2.0, programação de gameplay e etc, porém sujeito as idiossincrasias do Unity

iPhone;
Objective-C ≤ 2.0, linguagem nativa da plataforma iPhone;
Python 2.6, scripts de build e etc;
Java 1.6, 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.

A Olympya Software - www.olympya.com.br - é também a representante exclusiva no

Brasil e Portugal da FogCreek, http://www.fogcreek.com.br empresa fundada pelo
Joel Spolsky

Você pode usar gratuitamente por 45 dias o produto FogBugz, totalmente web, para
gerencia de projetos e outras funcionalidades, visitando o link http://try.fogbugz.com
Para treinamento em como fazer melhores softwares você pode aprender mais sobre
um outro produto da FogCreek, já lançado em Português:

visitando: : http://www.scribd.com/doc/29112680/Make-Better-Software-V1