DICAS

Introdução

Como vocês já devem saber, infelizmente devido a alguns desentendimentos com o Pedro Paiva eu encerrei minha participação no projeto do Macaco Grande.

Não foi uma decisão fácil, após cerca de 1 ano no processo de desenvolvimento houve bastante progresso em partes separadas do projeto (mesmo sem a liberação de um demo jogável).

No meio do caminho cometi muitos erros e alguns acertos que gostaria de compartilhar para ajudar outros desenvolvedores (uma espécie de postmortem mesmo sem o projeto estar finalizado).

Tenho certeza de que a lista será muito útil para outros desenvolvedores (e quem sabe até inspiradora); é um texto um pouco longo mas vale a pena.

O que deu certo

Desde o início o jogo começou bem: conceito conhecido, arte única (retrô) e bem executada, gênero com diversos fãs e bem conhecido (massificado), sem novidades.

Outra característica que ajudou bastante no início foi a criação minha de um design doc (que não havia sido feito pelo designer original do jogo), o que permitiu essencialmente começar bem o desenvolvimento e resolver algumas ambiguidades.

A ferramenta de desenvolvimento escolhida (a Unity 3d) também foi um ponto forte (ao invés de criarmos nossa própria engine do zero). A tecnologia permitia a exportação para todas as plataformas que desejávamos.

Tudo começou bem e ouve progresso rápido no início (como todo bom projeto), então começaram a aparecer os problemas.

O que deu errado

Os principais problemas iniciais que agravaram o projeto foram essencialmente:

• falta de tempo;
• falta de comunicação.

A falta de tempo se deu a uma fase em que passei no meu trabalho em que era necessário um esforço maior do que o habitual, isto impactou diretamente na produção do jogo (que se extendeu durante meses).

Assim, o desenvolvimento foi marcado por períodos de pequenos progressos, intercalados com poucos períodos onde eram feitas muitas funcionalidades e mais um período inativo (desenvolvimento inconstante).

Este ritmo de desenvolvimento inconstante contribuiu para alterar a motivação de se trabalhar no projeto (o que alterava diretamente o desempenho).


Meu conselho: pegue projetos pequenos para serem feitos se você não possui o tempo necessário (a não ser que você queira fazer sacrifícios gigantescos em prol do projeto, mas isto já é outra história).


A falta de comunicação se deu entre todas as partes envolvidas, mas foi mais direta por parte do designer: apesar do talento, comunicação com certeza não é um dos talentos do Pedro, juntando isto mais o pouco tempo que havia disponível para se desenvolver impactou que as iterações no projeto demoravam para ocorrer.

Ainda houve outros problemas menores como o Pedro não poder rodar o projeto na máquina dele durante um bom tempo do desenvolvimento (por causa de drivers de vídeo) que também causaram problemas nos tempos de iteração.

Apesar de poucos pontos, estes foram os que mais contribuiram para o não andamento completo do trabalho (tirando outros pontos que não compensa comentar).


Lição aprendida: motivação constante e iterações frequentes são a chave a conclusão de um projeto. As iterações frequentes aumentam a motivação, consequentemente se trabalha mais quando o projeto está efetivamente "nos trilhos" e o progresso sempre é visto. O documento de design também é MUITO IMPORTANTE para definir as bases do game.

Unity 3d

A Unity é uma excelente engine para se desenvolver jogos 3d. Entretanto quando o assunto é 2d foi necessário uma preparação maior.

O motivo principal de ter escolhido a Unity para este projeto em detrimento de outras foi sua capacidade multiplataforma. Eu não possuia nenhuma experiência anterior com a Unity, por isto tive que aprender enquanto desenvolvia o jogo (o que custou em tempo de desenvolvimento).

Depois que se aprende os conceitos na ferramenta e seu fluxo, tudo fica muito mais fácil (passado a curva de aprendizagem inicial).

A Unity não possui nativamente facilidades para se trabalhar com sprites (apesar de isto ser contornável), então utilizei uma solução chamada "Sprite Manager 2", que economizou um tempo enorme nas animações.

Olhando em retrospecto, se eu fosse desenvolver o jogo, por exemplo, apenas para a Web, utilizaria a Flixel em Flash. Ou se fosse para desktop, utilizaria a biblioteca Allegro mesmo (que já tenho bastante familiaridade); se fosse apenas para iPhone: com certeza cocos2d.

Lição aprendida: cada ferramenta possui seus prós e contras (a melhor muitas vezes é aquela que você conhece a fundo) para determinados tipos de jogos e plataformas. Não existe uma solução mágica para todos os casos e um dos principais custos de se aprender uma ferramenta é o tempo. Mudar de ferramenta no meio do caminho também é muito dispendioso, por isso uma análise criteriosa no início do projeto é fundamental (se não houver experiências anteriores com a ferramenta, o que era o meu caso).

Em meus próximos projetos com certeza utilizarei as ferramentas que possuo mais familiaridade (2011): Unity 3d para jogos comerciais, web, etc e Allegro com C++ para demos e artigos do VSoftGames.

O porting

O processo de porting do jogo mereceu uma parte no artigo por conter alguns "gotchas": inicialmente foi combinado que o jogo seria lançado simultaneamente para iPhone, iPad, Web, PC e Mac (utilizando toda a capacidade de portabilidade da Unity).

Entretanto no meio do caminho aprendi algumas lições valiosas:

• o processo de port deve ser pensado desde o início: muitas características mudam de plataforma para plataforma; o consumo de memória, tamanho das texturas e sons, otimizações, jogabilidade, tudo deve ser levado em conta em um port;
• no meio do caminho podem ocorrer problemas não planejados;
• determinadas decisões de projeto iniciais acabam impactando no port mais para frente (como por exemplo a resolução das texturas e jogabilidade do gênero que as vezes precisa ser retrabalhada em uma nova plataforma);
• é muito mais fácil focar em apenas uma plataforma com qualidade do que tentar portar para outras já no processo de desenvolvimento;
• utilizando-se a Unity, o processo mais trabalhoso de porting se deu na conversão entre PC-iPhone. O port para mac praticamente não sofria alterações.

Olhando em retrospecto eu deveria ter me concentrado em deixar uma plataforma 100% antes de tentar desenvolver para todas de uma vez (iria acelerar muito o desenvolvimento e aumentar a qualidade inicial).

Dicas pessoais

Gostaria de ressaltar algumas dicas que aprendi errando muito (erros que com certeza não cometerei mais para frente na medida do possível).

Estes itens e os próximos considero os mais importantes do artigo:

• aproveite ao máximo o tempo que você tem: antes uma hora bem aproveitada e focada do que três horas dispersas em redes sociais e coisas do gênero;
• saiba seus pontos fortes (dica repetida em artigos anteriores, mas sempre é bom lembrar);
• desenvolva do seu jeito (a melhor solução em muitos casos, melhor do que seguir um determinado exemplo ou técnica, pois sua maneira é de acordo com suas capacidades, conhecimentos e tempo (o resultado pode não ser o melhor possível mas sempre aparece.))
• existem momentos em que não se compensa atualizar as bibliotecas e ambientes do projeto para inserir novos recursos não testados com a base que você já tem: apenas finalize o jogo;
• muitas coisas se aprendem apenas com a prática no meio do processo e por vezes não há tempo de voltar atrás para aprimorar o trabalho (a realidade é dura);
• quando há pressa, algumas soluções no código do jogo são resolvidos puramente através de "força bruta";
• durante o projeto aprendi minhas limitações: o que é possível fazer com o tempo e conhecimento que tenho disponíveis (muito importante para novos projetos).

Durante o desenvolvimento

Algumas dicas e conselhos aprendidos por experiência durante o processo de desenvolvimento:

• todo jogo tem uma quantidade grande de código (não é trivial em nenhum sentido, são MILHARES de pequenos detalhes, até mesmo os jogos "mais fáceis");
• geralmente em um projeto de aprendizado = código inicial confuso não seguindo melhores práticas;
• qualquer alteração em gameplay exige muitos testes;
• a melhor abordagem é sempre ir resolvendo um pequeno problema de cada vez;
• diminuir o escopo ajuda a finalizar o projeto;
• coisas "mundanas" às vezes levam um tempo gigantesco (a importação das texturas na Unity me veio a mente);
• às vezes se quebra muito tempo a cabeça com coisas simples sem saber que a solução tambem é simples (diferente do que se imagina);
• é muito importante consistência (acelera o desenvolvimento) e uma estrutura e base sólidas (que vem com diversos projetos);
• em um jogo, soluções mal feitas fazem você pagar muito caro ao longo do tempo;
• foco e tempo são muito importantes para o desenvolvedor independente (jogos demoram MUITO tempo para serem feitos (geralmente não dá para apressar sem perder a qualidade));
• subestimei o trabalho que dava para desenvolver o projeto.

Conclusões

Apesar de não concluir o projeto em si (o que de uma maneira geral me deixou MUITO chateado), foi um excelente aprendizado que me deixou preparado para novos projetos (sempre se aprende errando).

A principal lição que aprendi foi: se possível faça as coisas por si mesmo (falando em desenvolvimento), não dependa muito dos outros (por mais talento que eles tenham, se não são confiáveis e não sabem se comunicar não adianta nada, não espere consideração de quem não te conhece pessoalmente).

Boa sorte e sucesso ao Pedro que continuará a empreitada.

Obrigado por terem acompanhado até aqui e que venham novos projetos.