Publicidade
Apertando o passo

Construindo seu Jogo – Parte III – Boas Práticas

O jogo começa na sua cabeça, mas isso é só o start
Gostou? Compartilhe!
Publicidade

Introdução

Dando continuidade à série de artigos sobre a construção de um jogo no meu artigo anterior, falei sobre as principais ferramentas que os profissionais podem utilizar em seus jogos. Neste novo artigo vamos abordar alguns métodos simples para você manter o projeto em execução.

Veja também:

    Muitos jogos de iniciantes se perdem devido a falta de um foco e uma continuidade, levando assim ao “engavetamento” da ideia. Isso acontece quando um projeto é super dimensionado e está além do nível de experiência do novato.

    Isso gera frustração e deixa o desenvolvedor bastante triste, contudo este primeiro erro serve como aprendizado para a formação de um fluxo de trabalho e evitar que futuramente estes mesmos problemas ocorram, levando a um loop constante de início, meio e não finalização de um jogo.

    Continua depois da Publicidade

    Este artigo tem como objetivo dar algumas dicas sobre boas práticas e vamos pincelar metodologias ágeis para você começar a fazer seu jogo e finalizá-lo.

    E fazendo as palavras do Mestre Galileu da Galileia, as nossas, é hora dizer que: “Vamos cair de cabeça nisso”.

    Os 80/20 do Pareto

    Não se trata de Luiz Pareto do lendário Trote da Telerj, e sim a regra de Pareto 80/20, também chamada “do princípio de Pareto” ou curva ABC, foi criada em 1897 por Joseph Moses Juran. Esta regra foi uma homenagem ao sociólogo e economista italiano Vilfredo Pareto que publicou um estudo sobre a distribuição de renda.

    Neste estudo foi constatado que a distribuição das riquezas não era uniforme, sendo que 80% estavam da riqueza estava apenas com 20% da população. Pareto com o avanço de seus estudos observou também que essa relação está presente em diversos outros ramos da ciência.

    Contudo foi Joseph M. Juran que desenvolveu a regra 80/20 que afirma que: 80% dos problemas podem ter relação com apenas 20% das causas dos destes. Mas o que diabo isto tem a ver com fazer jogos?

    A Microsoft já respondeu isso para você. As equipes de dev da empresa notaram que corrigir os primeiros 20% dos bugs mais relatados, 80% dos erros e panes relacionadas a um sistema/aplicativo seriam eliminados. Ou seja se você começar a trabalhar o seu jogo em pequenos blocos (20%) você reduzirá os problemas em até 80%.

    Mas como eu faço isso?

    Que tal falarmos de metodologias ágeis?

    Scrum, que diabos é isso?

    Scrum (desenvolvimento de software) - Wikipédia, a ...
    O Scrum em sua essência.

    Os metodologias ágeis vieram da indústria de Tecnologia da Informação para resolver problemas comuns a gerenciamento de projetos como:

    • Etapas de produção muito longas e sem entregas definidas;
    • Problemas na comunicação entre as equipes de dev;
    • A falta de alinhamento entre equipe de desenvolvimento e o cliente final;
    • Problemas de gerenciamento/alocação de recursos

    Várias metodologias foram adotadas, sendo a mais comum a ser utilizada no desenvolvimento de software o Scrum. O Scrum é uma metodologia ágil para gerenciamento de projetos, desenvolvimento de produtos complexos e extremamente dinâmica e o menos burocrática possível.

    MUITO a grosso modo falando (recomendo acessar o link no artigo) baseia-se em dividir o projeto em pequenas fases (ou Sprints) de 1 a 4 semanas e ali naquele intervalo, delegar as tarefas para a(s) equipe(s) para a sua execução. Existem uma série de outras coisas, mas o que importa é o seguinte: é rápido e efetivo e dá resultados.

    Tony, mas como eu posso trazer isso para a metodologia de de desenvolvimento de meu jogo?

    Simples: quebre o desenvolvimento em partes.

    Você pode começar a criar sprints semanais com o que você deseja fazer para desenvolver o seu game. Por exemplo se eu fosse fazer um pong eu faria os seguintes 4 sprints:

    Semana 1 – Mecânica básica do pong para dois jogadores humanos

    Semana 2 – Sistema de pontuação e de vitória

    Semana 3 – Telas de menu: Entrada, tela de vitória e game over.

    Semana 4 : Polimento e testes.

    No final da semana 4 eu teria um jogo simples para dois jogadores funcionando. Se eu quisesse agora melhorar o meu Pong. Eu faria mais 5 sprints para o seguinte:

    Semana 1 – Implementação da IA do jogo para 1 jogador

    Semana 2 – Testes e polimento da IA

    Semana 3 – Colocação de sprites animados dos jogadores e sprite da quadra de pong.

    Semana 4 : Melhorias de interface (opção jogo solo) e polimentos de sons e imagens

    Semana 5 : Testes e polimentos finais.

    Repare que desta maneira eu tenho um controle maior e posso detectar problemas no desenvolvimento, além de dividir bem as tarefas e as torná-las bem claras. Nesse caso eu utilizei o Scrum para ajudar no meu desenvolvimento.

    E se eu me atrasar ou me adiantar?

    Provavelmente na primeira vez que você for implementar a metodologia ágil vai errar em uma coisa: tempo. A noção de tempo para realizar uma tarefa você só conseguirá determinar de maneira correta, a pós a realização de alguns projetos. Isso faz parte do aprendizado.

    Se você se adiantar poderá já dar um polimento melhor a tarefa da semana, colocando algo que possa melhorar ou até mesmo valorizar o trabalho feito (isso é mais raro). Em projetos muito grandes mesmo que você se adiante é muito comum rever o código e suas funcionalidades.

    A primeira dica que eu te dou: utilize seu tempo com sabedoria e aproveite muito em caso de sobra, para rever seu código e as implementações daquele sprint.

    Princípio do KISS (Keep It Simple, Stupid)

    O princípio do KISS, deveria ser uma regra obrigatória para qualquer iniciante na área. Todo mundo que começa quer fazer um jogo gigante, complexo que nunca sai da cabeça (em muitos casos nem vai para o papel). Por isso pense as seguintes coisas:

    • “Entidades não devem ser multiplicadas além do necessário” (Johannes Clauberg)
    • “Simplicidade é o último grau de sofisticação”(Leonard Thiessen)
    • Tudo deve ser feito da forma mais simples possível, mas não mais simples que isso” (Albert Einstein)
    • A perfeição é alcançada não quando não há mais nada para adicionar, mas quando não há mais nada que se possa retirar”(Antoine de Saint-Exupéry)

    Resumindo, comece com projetos simples (já falei isso em diversos artigos meus) e a partir dele vá construindo projetos mais complexos, baseado em metodologias ágeis. Uma ferramenta que pode te ajudar e muito, além de permitir o trabalho em equipe é o Trello.

    E jamais confunda simples com simplório há uma abismo enorme entre estas duas palavras. O grande problema de muitos desenvolvedores é este: não saber a diferença dos dois e assim cair na armadilha da complexidade, sem necessidade. E para finalizar uma imagem final, que não vale só para o desenvolvimento de jogos, mas para muitos outros projetos:

    O cliente: trabalhar com ele e não para ele. Comunicar ...

    Até nosso próximo artigo!

    Tony Garcia é Game Designer, Educador, Gamification Designer, Especialista em Manufatura Aditiva e em Tecnologias Educacionais.
    Tem mais de 80 jogos desenvolvidos e trabalhou com mentoria em mais de 30 startups de jogos. Atuou em projetos de jogos educacionais e gamificação
    .

    CONTEÚDO RELACIONADO