Postmortem · Game Developer

Postmortem: Call of Coronga

Sat, 01 Aug 2020 00:00:00 +0000

Pouco mais de 2 anos se passaram desde o último postmortem que publiquei aqui no blog. Desta vez, recebi um texto do Luiz Felipe da Silva Marian, que criou sozinho o jogo Call of Coronga. Inspirado na pandemia do COVID-19, o jogo está disponível no Steam para PC. Confira abaixo o que deu certo e o que deu errado em seu desenvolvimento, e leia também os outros postmortems postados aqui no blog.

Olá, eu sou "Luiz Felipe da Silva Marian", tenho 19 anos e desde muito novo sou fascinado por criar novas coisas. No universo da programação achei um mundo perfeito para dar vida as minhas ideias, o desenvolvimento de jogos e softwares é incrível, pois não existem limites, tudo que você imaginar é possível ser criado dessa maneira você fica a mercer da sua imaginação.

Postmortem : Call of Coronga
#

A ideia surgiu no inicio da pandemia, eu como um grande fã da franquia "Call of Duty" de maneira rápida se acendeu na minha cabeça uma lâmpada "por que não criar um jogo inspirado no modo Zumbi?" melhor ainda ao invés de zumbis os vilões seriam pessoas infectadas.

O objetivo era trazer um pouco de humor e alegria nessa infeliz pandemia. Todo o jogo foi projetado em torno do modo Gripados no qual é inspirado no modo zumbi, porém eu queria mais, não apenas esse estilo, eu queria homenagear as vítimas do vírus e ao mesmo tempo criar um história macabra sobre a origem do mesmo, então surgiu o modo História. Produção:

Criar um jogo das dimensões que é "Call of Coronga" sozinho foi uma tarefa extremamente difícil e desgastante, felizmente meu foco foi todo destinado apenas na parte gráfica da interface e nos milhares de códigos escritos, pois todos os modelos 3D eu comprei ou usei os próprios fornecidos pela UNITY, mesmo assim a construção dos cenários com a riqueza de detalhes que eu queria me custaram dezenas de horas cada pedra tinha que estar no local certo, a configuração do cenário é muito desgastante, a correta interconexão entre códigos e objetos 3D é fundamental para um jogo não conter bugs, desta maneira estou muito satisfeito com todos os grandes cenários e animações que eu criei para cada parte do jogo.

Problemas / Dificuldades
#

Criação dos cenários

Um dos problemas mais cansativos foi dar vida ao ambiente do jogo, pois foi preciso que eu construísse mais de 10 cenários do zero, desde uma pedrinha no chão até o reflexo do sol tudo tinha que estar no local correto, ao mesmo tempo o cenário tinha que ser rico em detalhes e divertido para a jogabilidade ser fluída. Como o jogo é feito em Low poly, os modelos 3D não se encaixavam muito bem toda hora surgia uma falha na colisão que lhe jogava para o eterno limbo.

Animações

Uma parte realmente chata! Para desenvolvedores independentes esta etapa é um "pé no saco" para cada ação do player deve existir uma animação, fazer essas animações me custaram realmente muitas horas.

Pouco público e divulgação

Apesar do grande esforço para divulgar meu jogo, até o presente momento tenho um público muito pequeno e enxuto, como disse antes é muito difícil fazer sucesso com um jogo independente principalmente sem financiamento destinado para a divulgação paga.

Online

Sem sombra de dúvidas, tirando a construção do cenário, essa foi a parte mais árdua de todo o projeto, criar um jogo online é extremamente complexo a sincronização dos códigos em diferentes redes pelo mundo me custaram dezenas de horas, para piorar cada modificação que eu fazia no código eu tinha que criar uma nova BUILD do jogo para poder testar, cada build demora em torno de 15 minutos.

Sucesso / Aprendizado
#

Modelos 3d comprados

Como eu usei modelos 3D comprados ou disponibilizados gratuitamente na unity, isso me proporcionou uma economia de tempo absurdamente relevante, com isso não precisei modelar e texturizar os assets.

Meu primeiro jogo online

Mesmo enfrentando as maiores dificuldades que já tive em um projeto, o Call of Coronga foi o estopim para meu aprendizado em relação aos recursos de rede, após este jogo me sinto capaz de criar qualquer outro jogo online.

Códigos já escritos

Como eu uso a unity a muito tempo, eu tinha um grande acervo de scripts, os quais usei como modelo ou guia para os novos scripts do Call of Coronga.

O baixo custo do projeto

Para a conclusão do projeto eu gastei relativamente bem pouco, utilizei modelos 3D já comprados a algum tempo, o único valor considerável que eu investi foi os 100 dólares para poder publicar o jogo na steam.

O sentimento de satisfação

Não existe nada mais satisfatório que dar vida a algo e realmente acreditar que sua criação ficou boa, os diversos feedbacks que recebi foram muito gratificantes para mim, ver pessoas jogado meu jogo e curtido foi uma das melhores sensações que já tive.

Conclusão
#

A experiência adquirida na produção do projeto desde o inicio até o fim, foi incrível em todos os aspectos, com certeza diversos erros foram cometidos, mas também muitos acertos me possibilitaram disponibilizar o jogo para o público em apenas 3 meses de desenvolvimento.

Por fim, eu quero deixar claro que se você tem um sonho, objetivo ou meta corra atrás, pois apenas seus esforços e seus méritos serão capazes de lhe proporcionar a conclusão do seu objetivo, seja ele qual for, dedique-se, aprenda a analisar as críticas positivas e negativas para sempre melhorar e evoluir, pois o mundo está em completa evolução, e nós seres humanos não podemos ficar para trás.

Obrigado. Luiz Felipe da Silva Marian Email: mushroomangelsgames@gmail.com

Postmortem: Where's my helmet?

Fri, 02 Feb 2018 00:00:00 +0000

Eu arrisco dizer que esta é a primeira vez que recebo um postmortem de um jogo lançado no Steam pelo Greelight, pelo menos lançado quando recebi o postmortem. Where's my helmet? é um jogo desenvolvido pelo Mega Boss Game Studio, e no texto abaixo há um pouco sobre o desenvolvimento do jogo que foi lançado em 2016. Senti falta de compartilhar detalhes sobre o lançamento do jogo no Steam, mas acredito que o postmortem foi mais focado no desenvolvido do que na publicação. Leiam também os outros postmortems postados aqui no blog.

Where’s My Helmet? é um jogo de plataforma inspirado nos antigos clássicos. Porém ele traz uma mecânica diferenciada, que permite que o jogador desenvolva maneiras diferentes de avançar as fases. O jogador controla Axel, um viking que teve seu capacete trocado por um boné, ele utiliza dois machados que possuem tempo de recarga ao serem arremessados, eles podem serem usados para atacar os inimigos ou como auxílio indispensável para subir nas plataformas. O jogo foi lançado para Steam em Maio de 2016

Concepção
#

Nós estávamos por volta de um ano e meio desenvolvendo alguns jogos menores para mobile, então resolvemos que estava na hora de fazer algo um pouco mais complexo e com mais tempo de desenvolvimento. Aproveitamos também para explorar a plataforma Steam, já que tem um público um pouco diferente e nos faria encarar o projeto com mais seriedade. Escolhemos o gênero de plataforma por ser mais amigável e possível de fazer um projeto legal com pouco recurso.

Desenvolvimento
#

Começamos a prototipar como seria a mecânica de arremessar os machados, quanto tempo levaria para re-aparecerem, como seriam lançados, se funcionaria nos combates e etc. Durante esse mesmo período também foi criado um rascunho do GDD e uma concepção do personagem e do visual do jogo. Trabalhamos todos remotos e no tempo livre de cada um, fazíamos conferências semanais, e reuniões presenciais mais ou menos a cada 45 dias. Como já havíamos feito outros jogos juntos, o workflow funcionava bem.

O Visual
#

Como o personagem utilizava machados, achamos que casaria muito bem se ele fosse um viking, e utilizássemos elementos da cultura nórdica. Porém, não queríamos que fosse apenas mais um viking, queríamos algum elemento que ajudasse a destacar o personagem e deixá lo mais cativante, e com isso veio o boné e o título Where’s my Helmet? como desculpa.

Level Design
#

Iniciamos definindo qual seria o tamanho do personagem na tela e qual a altura do seu pulo, assim ficaria mais fácil de decidirmos o tamanho dos obstáculos e onde seria necessário ou não utilizar os machados. Depois disso, o level designer criou um rascunho de uma fase para que fosse possível listarmos um pack inicial de assets de obstáculos para serem produzidos e replicados nas outras fases.

Dificuldades
#

Mesmo tendo feito outros jogos anteriormente, nunca havíamos feito um projeto desse tamanho, desse gênero e para essa plataforma. Isso dificulta em acertar um escopo e deadline mais correto.

Publicação e Divulgação
#

Nossa principal estratégia para gerar um público antes da data do lançamento, foi divulgar desde o início algumas imagens do desenvolvimento na nossa fanpage e em grupos relacionados. A participação no Greenlight também fazia as pessoas verem o seu jogo antes do lançamento. Além disso, distribuímos algumas keys para canais do Youtube e blogs, que nos resultou alguns reviews bem interessantes.

Erros e Acertos
#

Playtest: Acredito que o nosso maior erro foi não ter realizado testes externos, principalmente no início do projeto. Ficamos um pouco fechados nas nossas decisões, e não enxergamos alguns caminhos diferentes que poderiam ser seguidos.

Levels: Optamos por fazer um jogo mais enxuto e com poucas fases. Porém não nos atentamos que a curva de aprendizagem que o jogador deveria fazer precisava ser mais suave, e com isso alguns jogadores se frustraram muito rápido.

Refinamento: Nós não tínhamos muita ideia do quanto de refinamento um jogo desse tipo precisaria no final, e nem dos updates após a publicação. Optamos por encerrar o projeto na data estipulada e sacrificar um pouco de refinamento, algo que hoje em dia nos programamos melhor para essa etapa.

Plataforma: Desenvolver para Steam nos deu outra visão de desenvolvimento e nos ensinou muita coisa, o público dela é muito mais engajado e participativo. Além de ser muito mais rentável para nós do que a Playstore.

Mecânica e Temática: Apesar dos problemas que tivemos em relação a dificuldade do jogo e controles, a aceitação do público em relação a mecânica principal e o visual do jogo, foram muito bem aceitas. O jogo se torna bem divertido quando o jogador entende a variedade de opções que ele tem para avançar pelas fases.

Conclusões finais
#

Where’s my Helmet? é um jogo que temos muito orgulho, e desenvolver para Steam nos trouxe uma grande realização pessoal e acredito que mais credibilidade. Essa experiência nos mostrou o quanto é importante o planejamento para melhorias, updates, e colher feedback do público desde o início do projeto. Este Postmortem serve justamente para que seja possível nós analisarmos o jogo como um todo, e tomar melhores decisões nos próximos projetos. Esperamos que assim como nos ajudou, te ajude de alguma forma a estruturar melhor os seus projetos e tirá los do papel de forma mas efetiva. Muito obrigado por lerem até aqui.

Informações Gerais
#

Desenvolvedor: Mega Boss Game Studio

Data de Lançamento: Maio de 2016

Plataforma: Steam

Time: 3 integrantes fixos mais 1 contribuinte

Tempo de Desenvolvimento: 6 meses

Ferramentas: Construct 2, Spriter, Adobe Photoshop

Where’s my Helmet?: https://www.facebook.com/wheresmyhelmet/

Mega Boss Game Studio: https://www.facebook.com/Mega-Boss-Game-Studio-709739855717025/

Postmortem: Deathfense

Sun, 28 Jan 2018 00:00:00 +0000

Faz um bom tempo que não publico um postmortem de um leitor aqui no blog, e desta vez é o jogo Deathfense feito pelo Lucas Meneses durante o 365 Indies Jam 2017. O texto abaixo foi postado no blog dele chamado Game Indie Developer. Leiam também os outros postmortems postados aqui no blog.

Descrição
#

Deathfense é um jogo 2D para browser do gênero tower defense, onde o jogador assume o controle da Morte que deve impedir que hordas de almas fujam do submundo. O jogo consiste em uma única fase contendo 6 hordas, cada horda possuindo uma quantidade definida de almas a serem ceifadas e cada alma uma determinada quantia de hit points. Para ceifar as almas o jogador conta com três opções, o Ataque Automático que tira apenas 1 hit point, o Ataque Forte que tirar 3 hit points, porém é necessário esperar um timer de 10 segundos e por ultimo, mas não menos importante, o Especial que ceifa todas as almas que estiverem em volta da Morte, mas também é preciso esperar um timer, nesse caso de 60 segundos.

O jogo foi desenvolvido entre os dias 15 e 25 de setembro para a 365 Indies Jam 2017 que teve como tema a frase “A morte é útil”. Ficando no rank 22 de 101 jogos onde foram avaliados jogabilidade, acabamento e fidelidade ao tema. A engine utilizada no projeto foi o Contruct 2, tendo como principal critério de escolha a facilidade e rapidez que ela oferece. A equipe foi composta por 4 integrantes, sendo eles os irmãos Gabriel e Augusto Santana que fizeram a arte e animação, Bettina Calmon que fez a musica tema e, por fim, eu, Lucas Meneses, que fiquei com o game design e a programação.

Para conferir o jogo CLIQUE AQUI.

Pontos negativos
#

Movimentação

Esse foi um ponto negativo que acabou se tornando positivo. Mas mesmo assim achei que seria interessante compartilha-lo com vocês. A ideia inicial era fazer a movimentação usando as setas do teclado com o behavior 8 Moviments.

(Arte do personagem usada apenas para o protótipo)

Logo percebi que a movimentação com as setas tornava o jogo um pouco lento e esse não era o objetivo. Fiz alguns testes aumentando a velocidade do personagem, mas mesmo assim sentia o gameplay travado. Fiquei uns dois dias pensando em como resolver esse problema até que me veio a ideia de usar o mouse como input invés do teclado o que deixaria o jogo mais rápido e ágil. A solução que encontrei para fazer isso foi utilizar o behavior de movimento Pathfinding, que geralmente é usado para fazer AI de inimigos que perseguem o jogador, só que no caso usei o clique do mouse como alvo para a trajetória do personagem. O resultado foi bem satisfatório e eu acredito que deixou o gameplay mais divertido.

Balanceamento

Foram vários os motivos que fizeram o jogo não ter um polimento melhor no quesito balanceamento. O principal deles foi o fato de ter sido ‘gasto’ mais tempo do que o esperado com a programação, mais especificamente corrigindo os vários bugs que foram aparecendo. O que acarretou em um gameplay que transita do fácil para o difícil de uma forma muita brusca, podendo até mesmo frustrar o jogador.

Hordas

O sistema de hordas foi feito usando algumas variáveis que fazem a contagem de almas ceifadas.

A horda 1 possui 10 almas, logo ela termina e a horda 2 começa quando o placar de almas ceifadas for igual a 10. A horda 2 possui 20 almas e tem o termino quando o placar for igual a 30, porque são somadas as 10 almas da horda anterior. E assim segue até a ultima horda. O problema estava ocorrendo na horda 5, quando o placar deveria marca 200 almas, mas, por algum motivo que não sei explicar, sempre faltava uma alma fechando o placar em 199 almas. Esse resultado impedia o progresso do jogo, já que a quantidade de almas é o gatilho que aciona as hordas. A única forma que encontrei de driblar o problema foi alterando a quantidade de almas na horda 5 para 190. O bug não foi totalmente resolvido, mas pelo menos assim o jogo funciona.

Limitações da Engine

Sem sombra de duvidas, esse foi o ponto que mais trouxe dificuldade e retrabalho ao projeto. Fazer um jogo usando apenas os 100 eventos da versão free do Construct 2 é no mínimo de se admirar. O termo Keep It Simple, Stupid nunca fez tanto sentido para mim. Tudo tinha que ser bem pensando, feito da forma mais eficiente possível para economizar os tão preciosos eventos. A ideia era fazer no mínimo 15 hordas e um boss no final, mas o máximo que consegui foram 6 hordas sem o boss. Muitas coisas tiveram que ser cortadas e as que ficaram foram alteradas para se encaixarem nas limitações impostas pela engine.

Bug na Musica

Esse foi um erro que só percebi depois do lançamento do jogo, quando o Gabriel reclamou que a musica não estava tocando no Google Chrome e como eu uso o Vivaldi não notei esse bug. Pesquisando um pouco e conversando com algumas pessoas descobrir que o possível motivo desse problema está relacionado com o formato do arquivo de áudio, que no caso é o OGG.

Pontos Positivos
#

Experiencia

É incrível a quantidade de conhecimento que é possível adquirir em uma game jam, ainda mais se você for um aspirante a desenvolvedor de jogos assim como eu. O tempo limitado te faz buscar soluções criativas que, talvez, não seriam possíveis em uma situação onde os prazos não fosse um problema.

Trabalho em equipe

Foi muito divertido e gratificante trabalhar ao lado de pessoas tão talentosas, que sem elas esse projeto não seria realidade. A comunicação entre os membros aconteceu de forma bem fácil, o que tornou o desenvolvimento mais assertivo e com menos erros.

Realização

Ver o meu primeiro jogo publicado em uma game jam foi algo que mexeu comigo. Há mais de 2 anos venho pesquisando sobre game design, engines, metodologias, entre outras coisas, só que nunca tinha finalizado um projeto. Foram raras as ideias que viraram um protótipo, as vezes não saiam nem dos esboços inicias. Mas após concluir esse jogo me sinto muito mais confiante em prosseguir na carreira de desenvolvedor de jogos. Esse foi apenas o primeiro passo de muitos que ainda viram.

Postmortem: Geometry World

Tue, 16 Aug 2016 00:00:00 +0000

Eu sempre recebo e-mails pedindo para divulgar jogos, porém isto é algo que decidi desde o início do blog não fazer. Eu acho importante divulgar, mas fazer um post falando de um jogo não é o tipo de conteúdo que eu quero para o blog, por isso sempre respondo falando que não faço reviews ou divulgação de jogos, mas sempre ofereço uma oportunidade para divulgação do jogo através de um postmortem. Desta forma o desenvolver ganha sua divulgação, e os leitores deste blog ganham uma história sobre o desenvolvimento de um jogo.

Isto é importante por que é possível aprender muito apenas lendo o que outras pessoas fizeram e deu certo, e também o que deu errado. Já vi muita gente falando que aprendeu com os postmortems publicados aqui, por isso fico feliz em sempre ter este espaço para todo desenvolver que tem seu jogo publicado (esta é a única regra). Não importa se o texto é longo e detalhado, ou curto e objetivo, sempre podemos aprender a partir da experiência dos outros.

Desta vez vamos ver como foi o desenvolvimento do jogo Geometry World do Eder Gabriel. Muito obrigado por enviar o texto abaixo e parabéns pelo jogo publicado!

Geometry World

Olá! Sou o Eder, designer do Geometry World. Abaixo a descrição dele, compartilhando alguns pontos que percebi durante a criação do game.

Descrição do game

Geometry World é um puzzle em que o jogador tem como objetivo colocar a caixa em um determinado lugar do cenário. O jogo tem cinquenta níveis divididos em cinco mundos com características particulares, por exemplo, o segundo mundo tem as colunas deslizantes. Apenas posicionando a caixa na posição determinada, o jogador desbloqueia os primeiros quarenta níveis do jogo. O último mundo é desbloqueável coletando as medalhas de conquista disponível de acordo com o objetivo dos 40 níveis anteriores.

Para controlar a caixa, o jogador deve segurar na tela e direcioná-la para a direção em que ele queira. Os principais desafios são conseguir todas as conquistas dos cinquenta níveis e se acostumar com a física do jogo.

Por eu estar mais preocupado com os aspectos funcionais do jogo, criei o design dele mais minimalista para diminuir o tempo de criação do jogo. Essa foi uma dúvida que eu fiquei por um tempo, de como alinhar uma arte funcional para o game, sem gastar muito tempo. Um requisito meu nesse projeto foi o de não usar palavras nas ações do jogo, apenas ícones.

Conforme fui mostrando para os amigos mais próximos, reparei em alguns pontos que não ficaram claros o suficiente e provavelmente, eu crie em novas formas de apresentar isso nas futuras versões. Esses mesmos testes também me fizeram a dar um maior valor a como ensinar as pessoas a jogar nas telas iniciais.

Pontos Negativos

Tive um atraso para concluir o game porque num teste com o iPod Touch, alguns cenários não estavam com a resolução ideal, porque o jogador não conseguia fazer o movimento correto para alcançar um determinado lugar.

Por se tratar de um jogo mais longo, pude aplicar alguns conceitos de level design. Mas sempre tem alguns pontos que ficam pendentes, por eu não ter ninguém para testar e discutir quando eu estava definindo como seriam os níveis.

Tem um erro que não descobri o que faz com que ele não reconheça a posição do jogador quando ele posiciona no lugar correto. Ele é bem inconstante, nas próximas versões, vou ter que inventar uma outra forma de validação, porque quando é reiniciado o app e concluindo a mesma fase, o erro desaparece.

Uma outra dificuldade foi colocar e testar o aplicativo na AppStore, por ser bem rígido o controle deles são necessários diversos certificados no iMac e no iTunes Connect que fui descobrindo e sempre acabava atrasando a publicação.

Tenho pesquisado algumas formas de propaganda, mas o mais difícil é convencer alguém que não me conhece a pagar pelo jogo e criei um flyer para divulgar por aí.

Pontos Positivos

Descobri o Corona SDK em uma pesquisa na faculdade, por ter uma curva de aprendizado menor em relação aos outros, acabei utilizando ele. Depois de alguns testes e a criação do meu primeiro game mobile, o Moving Kart, percebi que era possível criar algo mais complexo, que a comunidade do Corona é bem ativa e as minhas dúvidas sempre foram explicadas de algum jeito. Fiquei surpreso com o tamanho final do meu app para um jogo de 50 níveis (menos de 9MB).

Sempre tive o interesse em criar um aplicativo na AppStore para tentar deixar o meu portfolio mais interessante e consegui depois de 10 meses de produção e alguns meses que ficou congelado o projeto.

E o aprendizado que ganho com isso é enorme, principalmente, por ter que planejar todas as possibilidades do game, já que fiz sozinho, esse projeto me ajudou a ser mais analítico com qualquer sistema que eu crie no futuro.

Links

Download pela App Store

Página no Facebook

Postmortem: HueShark

Wed, 02 Mar 2016 00:00:00 +0000

Este é o décimo postmortem publicado aqui no blog. Fiquei muito feliz com este projeto em especial pois, diferente dos demais que entraram em contato depois do projeto estar pronto, o João Paulo comentou sobre este jogo em alguns posts do blog. É muito legal ver um leitor do blog (e sua equipe) desenvolvendo e publicando um jogo, e ainda mais contando a história do desenvolvimento aqui para encorajar outros desenvolvedores a publicar seus jogos.

Olá, meu nome é João Paulo Santos e sou um dos programadores do jogo HueShark que está 100% gratuito e pronto para download na GooglePlay no link acima. Abaixo irei especificar tudo que ocorreu durante todo o desenvolvimento, as nuances e mostrar o que realmente é positivo e negativo no desenvolvimento de um jogo de pequeno porte como HueShark.

Descrição do Game

HueShark conta a história de 2 casais (Pai, Mãe, Filho e Nora) que ganham uma viagem da empresa a qual prestam serviços por serem excelentes funcionários. Todos são especializados em engenharia e conhecem muito de mecânica e tecnologia. Ao irem com um Iate para o mar (Iate locado pela empresa) eles sofrem com as intemperanças do mar, em meio a viagem uma forte tempestade atinge o Iate que eles estão e eles são levados pela correnteza forte. O navio acaba parando em uma ilha deserta, tendo seu motor e parte elétrica destruídos.

O grupo pensa em como sobreviver e como voltarem para casa e a saída para isto era colocar um navio pesqueiro que também estava na ilha ancorado bem próximo a ilha e tentar consertar o motor/rádio deste barco novo que acharam na ilha para funcionar e assim serem recuperados ou irem para casa. Misteriosamente o barco pesqueiro tinha alguns esqueletos e marcas de "chifradas" no casco. Apesar de ainda estar em bom estado gerou curiosidade aos tripulantes que com esforço conseguiram levar o barco para bem próximo da ilha e ancora-lo ali mesmo. A ideia deles era ir a ilha sempre que possível em um bote para pegar alimento e procurar suprimentos para ajudar o grupo a sobreviver.

Abaixo segue uma descrição InGame:

Um jogo desafiador que faz com que o player tenha total atenção com o status de cada player e com a bag com recursos do navio. Cuide da Nutrição, Humor e Cansaço de cada personagem para evitar que eles trabalhem com penalidades na movimentação e tempo de cumprimento de tarefas.

Pesque, crie armadilha para o HueShark, mantenha o tanque de peixe sempre cheio para evitar danos ao navio. Chuvas ocorrem continuamente para renovar a reserva de água do barco.

Tente "fisgar" gaivotas para criar armadilhas para o tubarão (sim, gaivotas + vidro + putrefação = dor de barriga no HueShark).

Existem 3 formas de vencer:

1 - Gaste o máximo de suprimentos (supplies) no motor e você vencerá o game indo para casa com o motor novo;

2 - Gaste o máximo de suprimentos (supplies) no rádio e você vencerá o game sendo resgatado por um helicóptero da marinha;

3 - Vá o máximo de vezes possíveis para ilha e use o sinalizador para atrair a guarda costeira e você será salvo por um helicóptero da marinha.

Obrigado por apreciar nosso jogo, ele é FREE e é uma honra para nós compartilharmos o nosso esforço com vocês.

Início

O game antes mesmo de ser desenvolvido foi pensado no público de smartphones Android. Pensamos no Gdd entre o final de junho de 2015 e o começo de julho 2015 e juntamos 4 pessoas neste projeto inicialmente (tinha por data final de entrega 7 de dezembro de 2015), ressaltando que era um projeto de Universidade (Projeto Integrador). O Gdd foi idealizado em 1 dia, tendo quase tudo o que o projeto final tinha em seu documento original (poucas coisas mudaram). Abaixo irei especificar coisas técnicas, pontos positivos e pontos negativos.

Especificações Técnicas do Projeto

Engine: Nenhuma, usamos AS3 + Flash Builder + Starling + GreenSock (AS3). Plataforma: Android Estilo de Jogo: Survivor Comic Jogabilidade: Point and Click Ferramenta para Gráficos: Photoshop CC 2015 Animação: Photoshop CC 2015 (frames animados via código) Estilo: PixelArt Controle de Versão: Git (BitBucket) + Sourcetree + DropBox Técnica para Gestão: Scrum + Trello

Pontos Negativos

Aqui é aonde moram os perigos de qualquer projeto. Vamos dividir por partes:

1 – Procure pessoas que realmente estão motivadas

É muito fácil ouvir “estou contigo”, “contigo comigo para o que der e vier” e coisas do gênero quando se está em um mercado tão variável e tão lucrativo como o de game design. Porém, quando é hora de arregaçar às mangas e trabalhar de verdade pouco percebe-se de tal entrega por parte de alguns. Provavelmente o principal motivo disto foi a não identificação com o projeto ou com a área do projeto. É como pensar na Blizzard, imagine que eu como programador fosse trabalhar na área de rigging ou modelagem, além de ser um desastre para companhia provavelmente seria um ponto de desmotivação para mim. Certifique-se de que quem vai entrar no projeto com você realmente quer fazer e está disposto a quase tudo para ver o release do game oficial acontecer. 1 Erro na conta do projeto!

2 – Certifique-se que todos estão na área correta

No final do semestre 2 membros do grupo (éramos 4) saíram do projeto, mas apenas no final foi deixado claro que ambos não estavam na área que queriam, a saber desenho (pixel art).

Lembro-me bem do primeiro dia quando sentamos juntos e estabelecemos o que cada um faria, ou seja, 2 programadores e 2 designers, todavia recebemos bastante elogio na parte de código (não por sermos revolucionários, mas por termos produzido muito em pouco tempo), mas na parte visual não recebemos honrarias. Antes de começar qualquer projeto estripe todos os componentes para saber se realmente é aquela área que ele atuará que será sua “paixão no projeto”. Mais 1 Erro na conta do projeto!

3 – Motive o tempo todo, mas tenha parcimônia em poupar exclusões

Esse é um ponto grave de qualquer projeto que se não houver cautela ou falta de pulso seu projeto afunda! Veja bem, imagine o caso aonde uma pessoa não está produzindo (produzir != volume de coisas entregues, na verdade é qualidade) o proposto por ela mesma na semana/dia, se a resposta é NÃO avalie TODAS as coisas do ambiente ao qual ela faz parte (saúde dela/de familiares, emprego ameaçado, relacionamento acabado e etc), se realmente há algo grave ocorrendo respeite-a, mas se não há nada grave/desmotivador fora do projeto ocorrendo e o integrante não cumpre os backlogs propostos por ele mesmo está na hora de reavaliar o componente e se através de reuniões/diálogos privados e outras coisas não houver desprendimento mande um kick e assuma a função, é melhor fazer o seu melhor a não fazer NADA (mesmo que você não seja bom naquela área). Por causa desta falha de tolerar demais tivemos severos problemas com o cronograma assim como resultado negativo, 2 kicks. +1 Erro na conta do projeto!

4 – Tenha todos componentes com capacidade ou motivação extrema em sua área

Esse ponto é importante, pense comigo, você não vai achar o programador do Diablo 3 disponível para um projeto indie, vai? Claro que não, mas também não é aceitável um cara que ainda está estudando como se comenta múltiplas linhas em C# na Unity fazer parte de um projeto como programador (pelo menos com tempo de entrega cravado e não mutável). A coisa gira em torno disto, procure pessoas que conhecem do assunto (não precisa ser expert) e se tal pessoa não puder cumprir algo complexo na área dela dê tempo, uma pessoa motivada produz muito (e o bom é que ocorre um aprendizado forte). Colocar pessoas porque são “amigos, chegados, parceirões” é FURADA, corra! +1 Erro na conta do projeto!

Pontos bem positivos

1 - O verdadeiro líder

Como um mero aprendiz de liderança fui colocado como cabeça do projeto e isto me colocou uma responsabilidade de 1 tonelada nas costas. Como programador do projeto (também) decidi que a melhor forma de cobrar era fazer, ou seja, programar o máximo de linhas possíveis no menor tempo possível para poder mostrar um “olha caras, minha parte fiz bacana por isso estou pedindo que façam as suas partes” com cabeça fria e tranquila. Isso se mostrou mais que positivo, percebi que gera frutos (para componentes interessados no projeto), todos se sentem devedores de “entregar coisas” no projeto ao verem 1 componente fazendo isto. Lembro-me de “competir” com o outro programador quando fazíamos algoritmos bem legais para sanar problemas e ficávamos zoando um do outro no projeto para ver que fazia algo mais bem elaborado e isso gerou mais qualidade no projeto (perdi na maior parte das vezes kkkkkkk)...

2 – Redescobrindo seus limites

Uma das coisas mais legais que ocorreram foi chegar além do meu limite físico. Lembro-me que para cumprir um backlog precisei varar 3 dias e meu corpo já não aguentava mais e o new metal + cafeína + energético sustentaram juntamente com a motivação de maneira louvável os meus sentimentos e persistência. Uma das coisas mais legais que você descobre em um projeto com cronograma a ser seguido é que seus limites podem ser rompidos e positivamente ampliados. Cheguei a adoecer em detrimento disto, mas valeu a pena, ganhei o respeito de alguns da sala e da universidade que tomaram conhecimento do esforço dos programadores envolvidos no projeto.

3 – Achar motivação aonde não tem

Se não há dinheiro em jogo (projeto acadêmico), como fazer algo dando o melhor de si? Aí foi o bacana da história, pensar em superar a si mesmo e competir consigo mesmo tornam esse ponto uma resposta clara, Ultrapasse VOCÊ MESMO! Pise em você mesmo! Humilhe você mesmo por resultados melhores e você mesmo terá um crescimento forte!

4 – Quem está na chuva é para se molhar!

Quando houveram os kicks em detrimento do desinteresse/descumprimento de “Brothers” pensamos (os 2 devs): O que iremos fazer sem designers? Como vamos codar e desenhar? E a resposta foi: Vamos romper nossos limites, se for necessário não dormiremos mais! Temos data certa para encerrar este sofrimento ← Esse ponto é o legal porque aqui abre o leque para se romper limites, tenho até o momento os psds com históricos de edições pixel a pixel assim como o outro programador, aonde superamos a nós mesmos! Supere a si mesmo e se houver algum acomodado tome a frente, não deixe o barco afundar porque não há gente que leva a sério seu trabalho ou simplesmente pulou do barco, META A MÃO E FAÇA!

Considerações finais

Integrantes no início: 4 (2 devs/2 designers), Integrantes no fim: 2 (2 devs), Cronograma e Conclusão estimada: 5 meses, Conclusão do projeto: 8 meses, Rendimento estimado da matéria: 100%, Rendimento alcançado na matéria: 100%.

Agradecimentos

Quero agradecer ao portal gamedeveloper.com.br por ceder este espaço, é uma honra estar aqui postando meu primeiro game oficial e espero repetir este processo de post-mortem mais vezes, será mais que uma honra para mim. Obrigado, Bruno, você é Show!

Quero também agradecer a Deus que em 10 dias me possibilitou o aprendizado de um framework tão formidável como o Starling.

Postmortem: Teharth Prologue - The Resources Dissolution

Wed, 30 Dec 2015 00:00:00 +0000

Este é o primeiro postmortem de um jogo de RPG publicado aqui no blog. Teharth Prologue – The Resources Dissolution é o terceiro jogo do Maurílio Eudes Okamoto, que já publicou os jogos Sou Sustentável e Manual do Skate, e o primeiro do Teharth Studios. Confira aqui um resumo de como foi o desenvolvimento deste projeto as dificuldades que a equipe encontrou para terminar e publicar o jogo e clique aqui para fazer o download do jogo.

Descrição do jogo O jogo tem como gênero um RPG de ação 2D, com bastante uso de metaficção (quebra da quarta parede), um pouco de humor com paródias e non-sense. E trata-se de apenas um Prólogo do que está por vir futuramente, possui cerca de 1 hora de jogo.

A história se passa em Baghdah, um país localizado no extremo leste do continente. Gray um aventureiro iniciante, decide explorar todo o mundo de Teharth. Sua primeira parada foi nas Misteriosas Ruínas de Abyadh, onde ele encontra um ser lendário chamado Azazil. Esse ser tem o poder de dissolver os recursos do jogo, como a aparência física, os sons e os mecanismos de seres e objetos de Teharth.

O jogador possui o poder de evoluir de volta os recursos do jogo, auxiliando assim o Gray a conseguir atingir seus objetos e a resolver os quebra-cabeças. Pois Gray não consegue fazer muita coisa sem os recursos dele e o jogador não pode interagir diretamente com os elementos de Teharth. O jogador está participando do jogo como entidade jogador e não personificando o protagonista.

Postmortem Dessa vez fiz o postmortem um pouco diferente, em vez de separar em pontos positivos e negativos, vou citar pontos “importantes” que acreditamos que podem ser interessantes. O motivo de não fazer essa separação é porque nesse projeto tivemos muitos pontos que são tanto positivos quanto negativos.

O Projeto Nasceu de Um Problema No Teharth Studios, até poucas semanas atrás, nosso maior problema era falta de artistas, para fazer a parte gráfica/arte dos jogos. Na época, em março, pensamos em tentar fazer um projeto um pouco mais simples e que pesasse menos em arte.

Foi então que nasceu a ideia de evoluir o jogo de protótipo para final durante a jogada. Como gostamos de tentar inovar e colocar metaficção, colocamos o poder de evoluir o jogo no jogador, sendo um co-protagonista do jogo.

Desse modo, conseguimos dar um tempo maior para os artistas, pois as artes mesmo só seriam usadas na segunda metade do projeto. E também tivemos mais tempo para recrutar novos artistas.

Então de um problema, conseguimos um projeto e novos membros. Porém isso também gerou um outro problema. No começo do ano estávamos desenvolvendo outro projeto e tivemos que pausar ele, pois manter dois projetos seria um pouco complicado.

Inexperiência da Equipe Gerou Experiência Começamos projetar algumas coisas em 2014, porém só conseguimos começar algo efetivamente em janeiro de 2015. Ao longo de 2015 começamos estabilizar a equipe. Porém o grande problema era que a maioria não havia criado nenhum outro jogo completo anteriormente, por mais simples e curto que seja. Então decidimos fazer 1 ou outro prólogo, seriam projetos não necessariamente simples, mas curtos para a equipe começar ganhar mais experiência prática.

O problema de alguns era falta de conhecimento em áreas específicas, outros tinham conhecimento, mas não sabiam direito como aplicar em jogos. Então vimos que um prólogo poderia ser perfeito para iniciar as coisas, mesmo porque a maioria dos membros não se conheciam entre si, seria um bom jeito de aumentar o engajamento e o trabalho em equipe.

Como é geralmente comum em equipes pequenas, muitas pessoas acabam tendo que participar de várias áreas diferentes. Por um lado ruim isso diminui o foco, por outro lado melhora a comunicação entre os membros. Ao aprender e entender mesmo que bem pouco uma outra área de desenvolvimento. Faz você entender melhor o que os outros membros passam, que não é tão fácil ou não é tão difícil fazer tal tarefa daquela área.

Então a inexperiência gera experiência, de certa forma isso é meio óbvio, porém somente é verdade quando a pessoa corre atrás para evoluir.

Objetivo do Projeto: Velocidade X Qualidade Colocamos em mente que nosso objetivo principal seria o ganho de experiência e o projeto deveria ser algo breve. Como citado no item 1, existe outro prólogo que estava em desenvolvimento. Então a ideia era terminar logo esse projeto para continuar o “prólogo de verdade”.

O lado ruim disso é que o jogo não foi lapidado até o final, poderíamos ter melhorado muitas coisas, como deixar a mecânica ainda mais divertida, melhorar o roteiro que foi feito as pressas, criar animações melhores, algumas delas estão meio estranhas. Muitos desses problemas são consequências de a gente não ter sentado para fazer o GDD do projeto direito, já saímos desenvolvendo sem uma planejamento bem definido.

Porém de forma positiva esse objetivo manteve melhor o nosso foco e conseguimos concluir o projeto e o objetivo dele. Com uma qualidade final razoável e uma ideia de jogo bacana, com potencial a ser explorado.

Basicamente o desenvolvimento desse jogo foi um treino para fazer o próximo. Absorver os feedbacks positivos e negativos para fazer melhor futuramente.

Mudanças Este item é consequência dos outros três anteriores. Começamos o projeto “do nada”, nós acreditávamos que a ideia era boa, mas precisávamos ver como aplicar isso. Sabemos que muitas mudanças geram diversos problemas, como retrabalho, frustração, conflitos, entre outros. Porém pode deixar o projeto ainda melhor. Abaixo segue um breve histórico do projeto.

Abril de 2015: Pelo nosso foco em velocidade, decidimos fazer um jogo 2D do gênero plataforma. Arte 100% minimalista, com evolução do jogo apenas em mecânicas. Chegamos a criar um GDD simplificado as pressas e um protótipo. Porém pensamos depois, que poderíamos evoluir arte e áudio também, temos artistas (mesmo que pouco) e músicos. O gênero plataforma é um dos mais usados em jogos indies, tanto brasileiro quanto de fora. O feedback que mais recebemos na época foi que parece muito com Evoland ou DLC Quest. Mas a gente não achava isso, não estávamos apresentando a ideia de jeito certo. Como gostamos de tentar fazer diferente, cancelamos o projeto.

Maio de 2015: Mas como a gente achou a ideia da evolução muito bacana e queríamos testar como o público iria reagir. Então pensamos em outro projeto usando essa ideia. Aqui o jogo passou a ser um RPG de ação 2D, com evolução de arte e áudio além da mecânica, deixando o projeto 5 vezes mais complexo que o anterior, indo contra o objetivo inicial. Porém o foco do grupo Teharth Studios é fazer RPG ou pelo menos híbridos com RPG, mais especificamente JRPGs. Após criar um novo GDD simplificado e um protótipo dele, vimos que o jogo não ficaria muito bom, com o tempo e equipe que temos. Aí cancelamos o projeto novamente. Pois, só o fato de ter RPG na descrição do projeto já fazia tudo ficar mais complexo.

(Em junho e julho o responsável da equipe e projeto, teve que mudar de casa, que demorou muito para terminar e teve a perda de um irmão. Com isso o projeto acabou ficando de lado, sem ele a equipe não se sustenta direito.)

Agosto de 2015: Decidimos então fazer algo ainda usando a ideia da evolução, mas seria um jogo de puzzles (quebra-cabeças), sem batalha e roteiro.. Algo por fases em vez de contínuo, algo bem mais casual e possivelmente para mobile. Ficamos o mês todo rabiscando algo, mas o projeto não dava aquela motivação de querer desenvolver ele.

Setembro de 2015: Ficamos na dúvida e basicamente não fizemos nada em setembro. Somente no final do mês, decidimos voltar na ideia de maio, era ela que a gente achava gostava, decidimos tentar mesmo sabendo que poderia dar errado. Podemos dizer que o projeto começou efetivamente no final desse mês.

Outubro de 2015: O velho problema da falta de artistas pesou novamente. Porém decidimos fazer o projeto mesmo assim, qualquer coisa ficaria com menos evoluções de arte. Porém no final do mês conseguimos ajuda de 3 novos artistas e conseguimos fazer tudo que estava dentro do planejado. Nessa época um dos músicos teve que sair, ele que faria a orquestração das músicas, com isso as músicas ficaram um pouco menos lapidadas, mas ainda ficaram bacanas. Depois disso o projeto finalmente fluiu bem.

Dezembro de 2015: Tivemos alguns atrasos aqui, pois a maioria dos membros fazem faculdade e estavam em final de semestre com provas e tudo mais. Aí a fase final do projeto que era testar e lapidar o projeto, durou bem menos tempo que o previsto. Mas conseguimos corrigir os problemas que encontramos e melhorar algumas coisas.

Conclusão Apesar de o projeto não ter ficado tão bom quanto queríamos, cumprimos os objetivos com ele. Observamos que temos conhecimento para fazer algo bem melhor, se fizermos com calma e um melhor planejamento. Até agora já recebemos bastante feedback e em sua grande maioria foram positivos, então foi bastante gratificante desenvolver esse jogo.

Para terminar, agradeço novamente ao Bruno Cicanci, pelo espaço e oportunidade de postagem de um postmortem por aqui, no Game Developer. E obrigado a todos que leram, aguardem que em 2016 quando atingirmos nossa meta iremos dobrá-la. Hahaha.

Acompanhe-nos:

– Site: http://teharthstudios.wix.com/home
– Facebook: https://www.facebook.com/teharth.studios
– Twitter: https://twitter.com/teharthstudios

Postmortem: Insect

Thu, 24 Sep 2015 00:00:00 +0000

Eu fico muito feliz quando outros desenvolvedores independentes e até estudantes tem o interesse de publicar um postmortem sobre o projeto aqui no blog. Neste post, o desenvolvedor Aleksiam de 17 anos do Rio de Janeiro conta como foi criar e publicar seu primeiro game no Google Play usando Unity.

Esta é mais uma história que mostra que o único impedimento para criar um jogo é você mesmo. Tente criar um jogo em seu tempo livre e publicá-lo, ou participe de game jams para se forçar a desenvolver um projeto. Gostaria muito de ver mais jogos publicados pelos leitores do blog e suas histórias contadas aqui.

Descrição
#

Insect é um jogo casual, onde seu objetivo é sobreviver com um dos insects. Com a mecânica simples, onde seu dedo controla a personagem, desviando dos obstáculos mais rápido possível.

Sendo muito desafiador, o torna muito divertido. Você deve acumular estrelas para poder comprar Power-ups, ou então os personagens na loja.

No shop você vai encontrar uma variedade de itens, como o +5, que acrescenta 5 segundos no seu tempo atual, ou o raio, que destrói rapidamente os obstáculos. Nele, você também pode achar personagens carismáticos, como, a abelha rockeira, ou a libélula do reggae. Ganhando mais estrelas é possível dar upgrade nos seus personagens, e deixá-los mais legais.

No modo Zen você pode usar os Power-ups, como o míssil, causando grande estrago, ou a bolha que lhe deixar imune aos obstáculos. A velocidade dos obstáculos é alternada, então ele pode estar indo muito devagar e de repente aumenta sua velocidade, é um grande desafio.

No World você entra numa aventura fantástica, passando por fases até completar esse mundo e sendo muito bem recompensado. Para passar as fases você deve sobreviver 30 segundos, assim vai conseguir fechar o mundo dos insects.

O modo Run tem níveis diferentes, como, easy, medium, hard, extreme, que você escolhe, e ao passar o tempo a velocidade vai aumentando. É quase impossível ficar 30 segundos no extreme, é o modo mais difícil do jogo, sem dúvida você tem que ter muita habilidade.

Abra um presente e fique muito surpreso, podendo ganhar Power-ups ou até 85 estrelas de uma vez só, mas também pode ter azar e não ganhar nada, vai depender apenas da sua sorte!

Dificuldades e Problemas
#

Inexperiência
#

A minha falta de experiência com a Unity foi um grande problema, já tinha feito um jogo antes que ficou pela metade o Round, era de plataforma e bem legal, também fiz outros em outras engines como Construct 2, Game Maker, Game Salad, mas não quis dar continuidade nos jogos feitos nessas plataformas, talvez porque não gostasse tanto do jogo, fazendo assim minha desistência, era amar eles um dia e no outro o odiar.

Resoluções
#

Já no termino do jogo veio esse grande problema, adaptar o jogo em diferentes telas, tive pelo menos uns 3 dias de dor de cabeça para resolver essa questão, já que usava sprites, demorei um tempo para resolver, li mais sobre telas de celulares aprendi bastante, crie um algoritmo para os sprites se adaptarem e assim resolvi esse problema.

Tempo
#

Tive que fazer o Insect em um tempo limitado, já que estudo de manhã e à noite, então nesse tempo tirava para estudar sobre a engine, e confesso que perdi várias vezes para a preguiça, quando chega no PC assistia várias series, ou então estudava mais sobre redes, pentest, vulnerabilidades, física teórica entre outros assuntos diversos que não é necessário informar.

Sozinho
#

Quando estava fazendo o Insect tive algumas ajudas para testar e avaliar o jogo, infelizmente foi apenas esse tipo de ajuda que tive, não pode contar com outro programador ou um game designer, então isso me deixou limitado, a falta de outra pessoa também traz o desânimo.

Testes em celulares
#

Eu não tenho um celular bom, e para testar os arquivos apk era muito complicado, isso trouxe uma dependência de um grande amigo, que fez vários testes para mim, mas a passagem do arquivo e sempre demorada e quando você quer saber o resultado rapidamente isso é um grande problema.

Tamanho
#

O Insect é consideravelmente grande para um jogo casual e ocupa muita memória, isso realmente não consegui solucionar, o que deixa meu app com uma desvantagem enorme.

Pontos Positivos
#

Um grande aprendizado
#

O Insect é foi um imenso aprendizado. Para trabalhar com a Unity tive que aprender uma nova linguagem o C#, já conhecia muito bem a linguagem Java, então o aprendizado de C# foi bem rápido, com todo conhecimento que tenho hoje sobre a Unity irei fazer mais jogos, que em breve estará neste ótimo blog.

Custo baixo
#

O Insect teve um custo muito baixo os únicos gastos que tive foi com a pen tablet, e a taxa da Play Store, usei todas as ferramentas grátis o que deixou o jogo com pouco custo.

Conclusão
#

Insect um jogo muito divertido de se jogar e de fazer, me trouxe um pouco de dor de cabeça mas valeu muito a pena, a experiência que tive foi ótima por passar todas as partes de um desenvolvedor.

Créditos
#

Sou muito grato a minha família que sempre apoia tudo que eu faço, aos amigos Luís Felipe Nunes, Ivan da Silva Junior e Yan Cavalcanti Santos, que me motivaram a continuar ou ajudando a testar meu jogo, também quando não estava muito confiante com meu jogo, a todos eles meu agradecimento.

Aleksiam Gutenberg Ferreira Junior

Postmortem: Hungrymons

Sat, 06 Jun 2015 00:00:00 +0000

Há alguns meses um amigo conversou comigo e disse que queria começar a desenvolver jogos. Hoje, algum tempo depois, ele e seu amigo formaram um estúdio de jogos independentes e lançaram seu primeiro jogo para dispositivos móveis.

Fico muito feliz por terem publicado o jogo e por contar neste postmortem um pouco sobre o projeto, o que deu errado e o que deu certo durante seu desenvolvimento.

POSTMORTEM HUNGRYMONS
#

por Marcelo Vitoria e João Arthur Navarro

1) INTRODUÇÃO
#

Hungrymons é um game casual para iOS e Android. Nele, um robô flutuante (HungryBot) arremessa comidas no ar em diferentes direções, e o jogador precisa mover os monstros (Hungrymons) na tela na direção das comidas para alimentá-los, ganhando pontos por isso. O objetivo é fazer a maior quantidade de pontos possível. O jogador perde quando ele fica sem monstros para alimentar, sendo contabilizada a pontuação final.

O game foi desenvolvido por mim e por meu amigo e sócio João Arthur Navarro, sob a alcunha de CodeRogue Studio. Este é o nosso primeiro projeto, e o tempo total de desenvolvimento foi de 9 meses, entre Julho de 2014 e Março de 2015, tendo o game sido publicado nas app stores em Abril de 2015.

2) DETALHES DO GAMEPLAY
#

O jogador só precisa tocar no monstro e mover horizontalmente na direção das comidas lançadas. Com o tempo, a quantidade de comidas vai aumentando, assim como a velocidade com que elas são arremessadas, além de serem introduzidos elementos que não podem ser ingeridos, como frascos de veneno, que impedem o monstro de comer, e bombas, que eliminam o monstro imediatamente. Além disso, é possível realizar combos que multiplicam a pontuação, e controlar dois monstros ao mesmo tempo.

3) PROPOSTA
#

A idéia era fazer um game casual para plataformas mobile, com controles simples, objetivo claro, e que pudesse ser jogado em sessões curtas, de um a três minutos.

4) O QUE DEU CERTO?
#

4.1 Engine
#

Utilizamos o Corona SDK como plataforma de desenvolvimento, o que aumentou nossa produtividade e possibilitou que testássemos nossas decisões de design de forma rápida e objetiva. Além disso, o fato de podermos utilizar o mesmo código para ambos os SOs facilitou a escolha por esta engine, já que ela lida muito bem com as diferentes resoluções e tamanhos de tela (principalmente no Android).

4.2 Perfis dos desenvolvedores
#

No time tínhamos um programador e um designer, e essa divisão clara de responsabilidades e habilidades foi de grande valia durante todo o processo de desenvolvimento, e garantiu que cada um tivesse que se preocupar quase que única e exclusivamente com uma dessas duas tarefas. Isso ajudou a manter o foco, e fez com que o resultado final ficasse um pouco acima das nossas expectativas iniciais.

4.3 Comunicação
#

Como todos sabem, a comunicação eficiente, o debate e a rápida resolução de conflitos são pontos importantíssimos em qualquer equipe, de qualquer tamanho. Durante o processo de desenvolvimento, as dúvidas, idéias e problemas eram compartilhados, discutidos, e o consenso era alcançado sem desgaste. O fato de não termos um deadline para entrega, ou comprometimento com terceiros, contribuiu para a harmonia e a fácil comunicação.

5) O QUE DEU ERRADO?
#

5.1 GDD (e a falta dele)
#

Mesmo sendo um game pequeno, com poucas mecânicas, controles e game design simples, houve momentos em que estávamos em um ponto avançado do desenvolvimento e nos deparamos com dúvidas e dilemas sobre algum aspecto do game que, se devidamente documentados, teria nos poupado tempo e evitado o desvio de foco.

A falta de um GDD evidenciou que não tínhamos pensado como queríamos que tudo funcionasse, desde o inicio. Nós tínhamos um conceito inicial em mente, basicamente relacionado ao gameplay, e trabalhamos em torno disso para que todo o resto atendesse a ideia principal. Entendo que, mesmo que tivéssemos um documento, ele também seria alterado eventualmente, e evoluiria para o que se tornou o produto final, mas a presença dele serve de direção para o trabalho realizado, e te faz pensar em todos os aspectos do game antecipadamente, definindo um ponto de referência para futuras discussões.

5.2 Planejamento
#

O game foi desenvolvido inteiramente em nosso tempo livre, concorrendo com trabalho em tempo integral, relacionamento, família, etc. Nessas situações, é imprescindível que haja um planejamento das atividades de acordo com estimativas (mesmo que superficiais), e um controle rígido do tempo gasto no projeto. Nós não nos planejamos devidamente para o projeto em nenhum dos aspectos mencionados.

Como não tínhamos um documento que guiasse o desenvolvimento, muitas vezes o trabalho era paralisado até que se pudesse discutir algum ponto importante ou tomar decisões sobre qual caminho seguir. Não tivemos um calendário definido de reuniões iniciais, e essas discussões muitas vezes causava retrabalho.

O uso de ferramentas de controle de atividades, como Trello, minimizou o impacto na produtividade, mas entendo que, se tivesse havido um melhor planejamento, teríamos feito mais em menos tempo.

5.3 Poucas features
#

Sem dúvida, não conseguimos colocar no game tudo o que gostaríamos, como animações mais elaboradas, diferentes cenários, mini games, mais personagens, tutorial interativo, trilha sonora personalizada, e muito mais.

A verdade é que o projeto demorou bem mais do que imaginávamos, e tivemos que deixar muitas coisas de lado para garantir que tivéssemos no resultado final os conceitos principais, e não estendêssemos ainda mais o tempo de desenvolvimento.

6) CONCLUSÃO
#

Por ser nosso primeiro projeto, naturalmente enfrentamos muitas dificuldades durante o processo: falta de planejamento e documentação, curva de aprendizado da engine escolhida, dificuldade de conciliar as atividades do dia-a-dia com o tempo dedicado ao projeto, e diversas outras coisas.

Olhando para o produto final, podemos dizer que ficamos satisfeitos com o resultado, que condiz com a proposta inicial, com um conceito aderente às plataformas escolhidas, e um nível de “polimento” razoável, que não faz frente à grandes estúdios do mercado, mas nos deixou orgulhosos por termos começado com o pé direito.

Claro que gostaríamos de ter feito muito mais, mas conseguimos manter o foco no objetivo de fazer nosso primeiro game da melhor forma possível em um tempo aceitável. Muitos desenvolvedores cometem o “erro” de começar com projetos muito grandes, sem passar por experiências intermediarias que lhes dêem confiança e tempo para acumular as habilidades necessárias para criar games cada vez melhores. Felizmente, conseguimos fugir desse estigma e começar bem, com um sentimento de satisfação pessoal, e vontade de fazer muito mais!

7) DADOS
#

Desenvolvedor:

CodeRogue Studio (http://www.coderoguestudio.com/);

Plataformas:

iOS: https://itun.es/i6Lh3sB

Android: http://goo.gl/xX3GFu

Time:

Marcelo Vitoria (@MarcVit [https://twitter.com/marcvit]);

João Arthur Navarro (@Litsoh_Navarro [https://twitter.com/litsoh_navarro]);

Tempo de desenvolvimento:

9 meses;

Ferramentas e Linguagens:

Corona SDK (Lua), utilizando Sublime Text;

Git e GitHub, controle de versão e repositório de código;

Photoshop;

Audacity, PremiumBeat.com, OpenGameArt.org;

Trello (task manager);

Siga o exemplo do Marcelo e do João e faça um jogo simples e publique. Pela experiência deles (e de outros desenvolvedores publicados aqui) fica claro que mesmo um jogo simples pode ser complexo de fazer por vários motivos. É muito legal comparar a experiência dos desenvolvedores e ver que as vezes algo que um acerta o outro erra, e isso é bem comum mesmo.

Muito obrigado ao Marcelo e ao João por terem dedicado um tempo em escrever e compartilhar a experiência deles, e parabéns pelo ótimo jogo que desenvolveram e publicaram! Se você já fez um jogo e publicou, e quer compartilhar sua experiência, é só entrar em contato comigo que eu publico seu texto neste seção do blog.

Postmortem: Cat-Fly

Tue, 21 Jan 2014 00:00:00 +0000

Neste postmortem conheça o jogo independente brasileiro Cat-Fly para Android e conheça os desafios enfrentados pelo desenvolvedor Cláudio Rainho para publicá-lo.

Como escrevi neste post, se você não publicou um jogo, você não fez um jogo. Apenas um jogo publicado tem uma história para contar em um postmortem, e só assim um desenvolvedor aprende todo ciclo de vida de um jogo como um produto. Leia abaixo o texto enviado pelo Cláudio e veja mais um exemplo de que não é fácil criar um jogo, e que publicar faz parte do processo.

1. Descrição do Jogo

Cat-Fly é um game casual desenvolvido para Android, o jogador pode escolher dentre vários gatinhos o seu preferido, a base dos acontecimentos do jogo acontece em volta de uma situação inusitada, o seu gatinho bebeu um leite um tanto quanto ruim e a dor de barriga apertou, ele corre para o banheiro mas algo estranho acontece, o banheiro ” Explode ” e o seu gatinho sai voando pelos ares, voe o mais alto possível com seu gatinho ” até mais alto que a Lua”

Mecanica do jogo.

A mecânica é simples você movimenta o seu gato de um lado para outro, precisa apenas recolher moedas e desviar de objetos que estão caindo, você possui um arsenal de powerUps que vão ajudar você a ir o mais alto possível. Dentro do jogo é possivel, comprar personagens, poderes e fases.

O jogo esta disponível gratuitamente na PlayStore para Tablets e Smartphone com Android. Baixe o jogo aqui: https://play.google.com/store/apps/details?id=com.crgamestudio.tut.catflyfree.

2. Dificuldades e Problemas

Desempenho

Bom, quem desenvolve para dispositivos sabe bem como isso é complicado,em Cat-Flyexistem objetos que se quebram, existem muitas partículas,e eu queria boas texturas com objetos 3D, no começo foi dificil adaptar o jogo para celulares moveis, dive que diminuir muito a qualidade dos objetos, as resoluções das texturas, e tirar objetos do jogo, tive que remodelar objetos das cenas diversas vezes, deus sabe o como isso foi cansativo, mas no final o jogo ficou razoável, porem não como eu esperava.

Desenvolver sozinho.

Eu particularmente gosto de fazer sozinho, mas não posso negar que isso da um trabalhão, eu como desenvolvedor indie não sei tudo e tudo que sei não é 100% mas nesse jogo tive quetrabalhar como tudo, desde desenho,animações,programação até a edição de áudio, o que mais me deu trabalho foi os efeitos sonoros e as musicas, e vou aproveitar o espaço para dar uma dica, porque tive dificuldade de achar bons efeitos sonoros e musicas que de fato fosse gratuitas, mas achei um site que permite a comercialização dos sons disponíveis nele, o nome do site é freesound.com, outros problemas em relação a trabalhar sozinho é o fato de que com o tempo você passa a odiar o seu jogo de tanto que teve que testa ele, mas faz parte.

Resoluções de aparelhos.

Eu estou desenvolvendo para Android faz pouco tempo mas, o que mais me deu trabalho foi trabalhar com resoluções,os aparelhos Android possuem uma grande variedade de resoluções e isso atrapalha um pouco,então tive que limitar meu jogo para aparelhos com uma tela maior ou igual a 4″, agora para o próximo projeto eu estou mais preparado para lidar com as resoluções .

Publicidade

Esse sim é um grande problema, eu como desenvolvedor independente sou um tremendo de um durango, não tenho recursos financeiros para investir em propaganda, então a parte de publicidade do jogo foi um grande problema,minha unica solução foi recorrer as redes sociais, entrei em todos os foruns e grupos relacionados a jogos e android, e divulguei neles mas isso me consumiu um bom tempo, e ainda sim não vai dar um retorno satisfatório, é como o meu pai sempre fala “Propaganda é a alma do negocio” eu demorei para entender isso.

3. Pontos Positivos

Aprendizado

O Aprendizado foi sem duvida o maior ponto positivo, aprendi tantas coisas novas nesse jogo que me sinto pronto para fazer outro jogo e melhor, atualmente eu tenho apenas dois jogos lançados oficialmente, mas dezenas espalhados pela internet, mas é possível reparar a evolução que tive de um jogo para outro foi incrível,em Cat-Fly eu me desafiei em algumas mecânicas do jogo,coisas que deram um trabalho danado mas foi incrivelmente proveitoso e o fato de ter ganhando experiência,, agora posso ver claramente os erros que cometi no primeiro e ja vejo outros erros que cometi no Cat-Fly e esses erros serão evitados nos próximos projetos.

Satisfação Pessoal

Sem duvidas a Satisfação Pessoal é grande, eu desenvolvo games desde os meus 13 anos mas nunca fiz nada completo, agora com o segundo jogo lançado na PlayStore me sinto ótimo e pronto para outro.

Novas Ideias

O que Cat-Fly mais rendeu foi novas ideias, o desenvolvimento do jogo me obrigou a pesquisar diversas coisas que me geraram um bom conhecimento e bagagem para um próximo game também relacionado a animais, e a experiencia que eu tivo junto com os conselhos que recebi, estou convencido a investir meu tempo em um projeto mais comercial, seguindo a tendencia, infelizmente não posso falar dele mas quem quiser ficar por dentro é só curtit essa pagina nofacebook: https://www.facebook.com/crgamestudio

Download do Cat-Fly FREE

https://play.google.com/store/apps/details?id=com.crgamestudio.tut.catflyfree

Para finalizar,quero agradecer o ao Bruno Cicanci, muito obrigado pelo espaço e oportunidade e agradeço a todos que leram.

Claudio Rainho

Esta é uma sessão do blog dedicada a mostrar exemplos de pessoas que conseguiram tirar sua ideia do papel e fizeram um jogo, o texto é escrito pelo desenvolvedor e publicado aqui da mesma maneira que recebo. Se você já publicou um jogo e tem interesse de contar como foi o processo de desenvolvimento entre em contato para saber mais sobre o postmortem.

Postmortem: Manual do Skate

Fri, 20 Dec 2013 00:00:00 +0000

Depois de alguns postmortems de jogos digitais enviados pelos desenvolvedores, este é o primeiro de um jogo de tabuleiro e mostra algumas diferenças na criação de um jogo analógico.

Este é o segundo postmortem de um jogo desenvolvido pelo Maurílio Eudes Okamoto, que já tinha me enviado o postmortem do seu jogo Sou Sustentável. Confira abaixo o que deu certo e errado na criação deste jogo analógico. No final do texto há o link para download do jogo, é só imprimir e jogar!

1. Descrição do Jogo

É um jogo de tabuleiro, onde você se torna um skatista profissional e é um participante finalista de uma competição de skate. O jogo consiste em uma fase de treinamento rápido, na qual abrange analisar o skatepark e escolher quais manobras você irá usar na competição. Na segunda fase a de competição propriamente dita. Cada jogador tem o seu turno, onde escolhe-se em qual direção irá tomar dentro do skatepark, qual será o local onde o jogador irá usar as manobras e como irá combiná-las.

2. Dificuldades e Problemas

Definição do Tema
Esse projeto fez parte de um projeto da faculdade, com isso tínhamos quatro limitações, o projeto deveria ser de tabuleiro/cartas, com o tema esporte, prazos de entrega e o jogo deveria ser útil, tentar passar algo através do jogo para os jogadores.
O maior dificuldade inicial era a utilidade do jogo. Entre idéias e discussões, chegamos a começar fazer um jogo sobre Tiro Esportivo, onde iríamos mostrar as regras, curiosidades e passar que o esporte não é algo ligado a violência apesar de usar armas.
Porém um dos responsáveis pela idéia acabou desistindo do curso e a utilidade do jogo na prática estava ficando meio duvidosa. Decidimos voltar para uma idéia que sugeri no começo, na qual era sobre skate usando cartas. A utilidade ficou definida como ensinar algumas regras, manobras, combinações e uma abstração de uma competição.

Equipe
Manual do Skate não foi uma exceção, assim como muitas equipes recém criadas houve também problema com a equipe. A saída de um dos membros da equipe foi o primeiro, ele era um dos que mais ajudava. Um segundo membro não ajudava em nada. E por fim os outros dois tentavam ajudar, porém a qualidade não estava ficando boa.
Com isso no fim tive que fazer toda parte gráfica também, na qual era responsabilidade dos outros membros. Minha parte era inicialmente o Game Design.

Prazo e Conseqüências
Com o troca troca de tema, acabamos perdendo muito tempo e o prazo ficou apertado. Com isso acabamos não fazendo muitos testes de mecânica e a versão final ficou com alguns ajustes pendentes.
Um dos ajustes pendentes foi o tamanho do tabuleiro, como o jogo era praticamente só de cartas, decidimos fazer uma caixa pequena, com isso tabuleiro ficou pequeno. É um pouco difícil de ler os escritos dele, porém dava para ter aumentando os escritos sem aumentar o tabuleiro, mas isso acabou ficando de lado para dar prioridade a outros problemas.
E o outro ajuste pendente é que demora um pouco para chegar o próximo turno de cada jogador. Como o jogo é para um total de 5 pessoas e cada um tem que ficar pensando qual lugar vai ir, quais manobras e combinações vai fazer, isso demora um pouco.

Outros Problemas
Tempo de jogo, o jogo estava demorando cerca de 2 horas e isso é bastante num jogo voltado a utilidade. Porém conseguimos arrumar isso, descartando metade da mecânica. Ela era inicialmente mostrar toda carreira de um skatista até chegar na primeira competição. No final ficou apenas a competição.
Qualidade da Gráfica, a gráfica que fomos imprimir o jogo para apresentar depois, fez um trabalho bem ruim. Escolhemos ela pois, estávamos sem tempo, a gráfica tinha prazo de entrega rápido e aparentemente não era cara. Porém, as cartas ficaram todas tortas e não só as cartas com o todo resto ficou mal cortado. Com algumas reclamaçõe s o resultado ficou mediano, estava “bom” pelo tempo que eles levaram para fazer tudo, menos de um dia.

3. Pontos Positivos

Nova Experiência
Desde que comecei a fazer jogos, a cerca de 2 anos, não tinha pensando em fazer jogos de tabuleiro, acabou sendo uma boa experiência. Apesar de ambos serem jogos tabuleiro e eletrônicos, é um pouco diferente na hora de criar, principalmente pelo fato da interação entre jogo e jogadores e também de jogadores com jogadores é diferenciada. Toda parte de testes é um tanto diferente também.
E não menos importante foi o primeiro projeto que fui o Graphic Designer, como eu fiz Ciência da Computação antes, meu cargo nos projetos de jogos era sempre programador.

Satisfação Pessoal
Apesar de todos os problemas foi bastante gratificante por causa do feedback positivo que recebemos. Dentre eles, a mecânica bem projetada, apesar de demorar para chegar a vez de cada jogador jogar. Bom aspecto visual, apesar da qualidade de impressão e trabalho da gráfica. E pontualidade com os prazos, mesmo com todos os problemas, fomos o único grupo a apresentar 100% dentro do prazo.

Download do Manual do Skate (imagens e manual de regras para imprimir): http://okamotoprojects.wix.com/site#!manual-do-skate/c101n

Para terminar, muito obrigado ao Bruno Cicanci, pelo espaço e oportunidade de postagem do meu segundo postmortem e o primeiro de um jogo de tabuleiro. E obrigado a todos que leram o/

Maurílio Eudes Okamoto

Postmortem: Sou Sustentável

Mon, 11 Nov 2013 00:00:00 +0000

Mais um postmortem de um jogo produzido por desenvolvedores independentes no Brasil, desta vez vamos conhecer o que deu certo e o que deu errado durante a criação do jogo Sou Sustentável, desenvolvido pelo Okamoto Game Productions.

O jogo, desenvolvido com a game engine Unity 3D, possui três mini-games diferentes, todos com temática de sustentabilidade. O postmortem abaixo, escrito pelo Maurílio Eudes Okamoto, mostra as dificuldades e problemas e os pontos positivos da experiência de criar um jogo do zero até o fim.

Postmortem: Sou Sustentável

1. Descrição do Jogo

Sou Sustentável é um jogo para as plataformas Android, WebPlayer e Windows (PC). É um jogo educativo com o tema sobre sustentabilidade. Possui 3 minijogos, com fácil aprendizado e englobam conhecimento e situações que envolvam o tema sustentabilidade. O primeiro minijogo, é para coletar os lixos recicláveis, onde o jogador controla uma lixeira. O segundo é sobre reaproveitamento de água da chuva, onde o jogador precisa ligar os canos para formar a tubulação que irá levar a água da chuva da calha para uma cisterna. E o terceiro minijogo envolve reflexos, o nome de um tipo de lixo reciclável irá aparecer na tela e o jogador precisa apertar o botão referente a aquele tipo de lixo.

2. Dificuldades e Problemas

Pouco Empenho de Alguns Membros da Equipe
Dos 5 membros da equipe, dois deles eu conheci pela internet e outros dois eram amigos de vários anos. O interessante desse projeto é que deixou bem claro para mim, algo que um grande amigo meu dizia “Trabalho e amizade são coisas diferentes.” depois disso venho passando essa frase para as pessoas. Pois vejo muita gente levando um problema de trabalho/projeto para o lado pessoal e perdendo amizades. E ter mais cuidado em criar a equipe, bons amigos não quer dizer que vão ser bom desenvolvedores.

Arte Gráfica
O Graphic Designer sabe bem desenhar no papel, mas no computador “dava para o gasto”, mas a arte não ficou ruim. O grande problema da arte era o tamanho em bytes que as imagens ficavam. Outro problema enfrentado por ele foi a falta de conhecimento em ferramentas gráficas, isso fez com que a criação das imagens demorassem muito mais.

Bugs e Problemas de Implementação
Felizmente (ou infelizmente) houveram poucos problemas no fim do projeto. Os dois maiores problemas foram de desempenho, na qual causa lentidão (lag) em alguns aparelhos Android no primeiro minijogo. Outro problema foi com a chave da versão Android, que fez com que não conseguíssemos colocar o jogo no Google Play. Um outro problema considerável foi a qualidade das imagens no jogo, como elas eram naturalmente pesadas, nós tivemos que comprimir mais piorando bastante a qualidade inicial delas.

3. Pontos Positivos

Arte Sonora
Em questão de músicas e efeitos sonoros, o Sound Designer do grupo fez um ótimo trabalho. As músicas e efeitos sonoros combinavam bem com o estilo do jogo, com cada minijogo. Foi um ponto positivo bem considerável, mas houve alguns improvisos.

Aprendizado de Novas Ferramentas e Tecnologias
Esse projeto foi focado para o aprendizado da game engine Unity 3D usando Javascript. E foi justamente isso o que eu aprendi nesse projeto, desenvolvimento de jogos no Unity 3D com Javascript. Também aprendi mais sobre a criação de um Game Design Document (GDD), que abrangeu a área de Game Design e Level Design.

Ganho de Experiência em Diversas Áreas
Esse foi o segundo projeto de jogo que eu desenvolvi, ao contrário do primeiro que eu fui um participante mediano na equipe. Nesse projeto eu fui o que mais participou, apesar da pouca participação de alguns membros, a experiência que adquiri em um único projeto foi bem considerável.
Foi a primeira vez que fui gerente de projeto e de equipe, foi o primeiro GDD que fiz que saiu do papel. Também foi a primeira vez que fui um Lead Programmer, programação é algo que sempre tive dificuldade.

Satisfação Pessoal
Além dos fatores já citados, foi bem bacana trabalhar com pessoas inicialmente desconhecidas e o projeto fluir bem e terminar. Foi bastante divertido aprender a desenvolver no Unity 3D, antes disso só havia mexido em Android sem game engine. É tudo mais fácil e flui melhor, fora a economia de tempo que isso deu. O projeto demoraria pelo menos 5 vezes mais sem o Unity 3D, ou no pior caso ele nem sairia do papel.
Resumidamente foi muito bom pelo aprendizado e experiência. Não menos importante é o segundo jogo que criei e foi o primeiro que eu projetei e gerenciei sozinho. Afinal uma das melhores sensações para um desenvolvedor de jogos é terminar um jogo, mesmo se for simples e feio.

Download do Sou Sustentável: http://okamotoprojects.wix.com/site#!sou-sustentavel/cz1

E para terminar obrigado ao Bruno Cicanci pela oportunidade de postagem do meu primeiro postmortem. E obrigado a todos que leram o/

Maurílio Eudes Okamoto

Obrigado por compartilhar sua experiência Maurílio, e parabéns pelo jogo! Lembrando que os postmortems publicados são escritos pelos desenvolvedores do jogo, contando as coisas que deram certo e que deram errado durante a produção do game. Se você também produziu um jogo e quer compartilhar com os leitores, entre em contato comigo pelo email que está na seção contato.

Postmortem: Combo Nuts

Tue, 24 Sep 2013 00:00:00 +0000

Mais um postmortem exclusivo para o blog, e desta vez é um jogo que eu participei do desenvolvimento como programador. Sabia como foi o precesso de produção do jogo Combo Nuts!

Combo Nuts é um jogo independente da Aplay Studios para iOS e Android, que foi desenvolvido por uma equipe formada por ex-funcionários de grandes empresas, como Ubisoft, Glu Mobile e Electronic Arts.

Este postmortem é muito especial para mim por que eu participei do desenvolvimento deste jogo em sua fase final e no primeiro update para ambas as plataformas.Toda a experiência com desenvolvimento de jogos da equipe foi empregada na produção de Combo Nuts, um jogo muito divertido e viciante!

Eu aprendi bastante, principalmente sobre o processo de publicação do jogo na App Store e no Google Play, mas isto é um assunto para outro post. Muito obrigado Sandro pelo postmortem e pela oportunidade de participar deste projeto! Alias, este jogo está concorrendo a Melhor Jogo Completo e Melhor Jogo Mobile na SBGames 2013, que acontece mês que vem em São Paulo.

Postmortem: Combo Nuts
#

Descrição
#

Combo Nuts é um endless casual game com uma jogabilidade simples e intuitiva, com partidas rápidas e emocionantes.

O jogador controla Albert Squirrel, um esquilo voador que deve recolher as nozes que caem do céu roubadas pelos irmãos Wrong. A melhor maneira de recolher um grande número de nozes é através das sequências de nozes que aparecem, dessa maneira o jogador pode fazer diversos “combos”, recolhendo mais nozes e ganhando mais pontos.

O jogo é freemium e as formas de monetização implementadas foram através de propagandas e vendas de in-app purchases.

O jogo foi lançado para iOS e Android.

Links para download:

iOS: http://bit.ly/combonuts_ios

Android: http://bit.ly/combonuts_android

Equipe
#

No início do projeto a equipe consistia em 3 pessoas, um game designer, um artista e um programador. Trabalhamos de forma remota, a principal forma de comunicação foi através de e-mails e reuniões via Skype e com encontros presenciais esporádicos. Ao final do projeto, mais 2 programadores nos auxiliaram para finalização do jogo.

Conceito
#

A idéia era criar um jogo casual no estilo endless com uma jogabilidade simples e divertida, onde as partidas fossem rápidas e dinâmicas.

Analisamos o mercado e o público alvo que gostaríamos de atingir. Estudamos os estilos de jogo e gameplay que gostaríamos de produzir, que fosse algo simples, divertido, bonito e original onde cada membro da equipe aprenderia algo de novo em sua respectiva área.

Estrutura para produção
#

Para a definição, organização e compartilhamento dos trabalhos utilizamos as seguintes ferramentas:

Google Docs: criação e organização dos documentos e tabelas (www.docs.google.com);

Trello: Definição das tasks e prazos (www.trello.com);

Dropbox: Armazenamento dos assets de arte, plugins, GDD etc (www.dropbox.com);

BitBucket: repositório online para o projeto (www.bitbucket.com);

Engine: Unity (http://unity3d.com/);

TestFlight: Serviço para teste de builds remotamente (https://testflightapp.com/).

Prototipagem
#

Desenvolvemos o Game Design Document (GDD) com o detalhamento inicial do gameplay principal do jogo, com as principais guidelines a respeito da mecânica do jogo para iniciarmos o quanto antes a prototipagem.

Com o decorrer da prototipagem e testes, fomos definindo na engine os editores que precisaríamos para criação e ajustes de todos os elementos do jogo como: posição, tamanho e velocidade do aparecimento dos objetos, criação dos padrões de sequência de objetos, controle dos intervalos de tempo e dos objetos para termos controle da curva de aprendizado e dificuldade etc.

Estudos iniciais
#

Paralelamente, fomos desenvolvendo o estilo artístico do jogo, estudando a melhor forma para a implementação dos elementos gráficos levando em conta a otimização dos recursos técnicos da engine e a beleza e composição da arte.

Nesse momento foram feitos estudos de animação na engine e nos principais devices para encontrar um equilíbrio entre otimização dos recursos técnicos e resultado artístico desejado.

Game Design Document
#

No GDD foram detalhadas todas as mecânicas necessárias para implementação no jogo, funcionamento da câmera, personagem e controle, comportamento de todos os elementos do jogo, progressão de jogabilidade, signs e feedbacks, fluxograma das telas e das ações, interface de usuário, conteúdo do jogo, detalhamento do funcionamento da “loja” do jogo etc.

A medida que os elementos eram implementados e testados, ajustes eram feitos e essas informações eram atualizadas no GDD para manter a organização do projeto.

Produção
#

Durante a produção do jogo adquirimos os efeitos sonoros e música que seriam implementados no jogo através do site http://www.premiumbeat.com/

Além dos in-app purchases foi adotado como método de monetização as propagandas dentro do jogo, nós utilizamos 2 serviços para isso:

AdMob: serviço de banner in-game do Google (www.admob.com);

Chartboost: serviço de banners intersticiais (www.chartboost.com).

No nosso projeto, o serviço do Chartboost é o mais efetivo e com maior retorno financeiro.

Foi comprado também diversos plugins para a Unity para facilitar a implementação de diversos elementos no jogo como integração com Game Center da Apple, Chartboost, AdMob, Flurry etc, os plugins foram adquiridos no site: http://prime31.com/plugins

Na fase final do projeto, contamos com mais 2 programadores para ajudar na implementação desses plugins.

Balanceamento, QA, bug fixes e polimento
#

O balanceamento do jogo foi constantemente executado durante o jogo, de todos os objetos, inimigos, itens especiais etc, com o objetivo de encontrar o melhor equilíbrio entre diversão e o estilo de gameplay com sessões rápidas e dinâmicas.

O QA (quality assurance) é o momento onde verificamos a integridade do jogo, se todos os elementos estão funcionando de acordo com o planejado e onde podemos melhorar para tornar melhor a experiência para o jogador. Fizemos sucessivos testes a fim de descobrir erros no jogo e solucioná-los.

Depois de implementado os principais itens do jogo iniciamos o procedimento de bug fixes, categorizando em 3 níveis, do mais ao menos crítico que influenciasse o gameplay e a experiência do jogador.

Nesse momento iniciamos o polimento do jogo, analisando o fluxo das telas e ações do jogo, colocando os assets de arte finais, revisando textos, melhorando signs e feedbacks etc.

Validação e divulgação
#

Após os últimos testes, enviamos as builds finais para a validação do projeto, para iOS a validação levou 10 dias e para Android cerca de 3 horas.

Para a divulgação de nosso jogo, preparamos os seguintes meios:

Website: http://www.aplaystudios.com/games.html

Press release: http://www.mediafire.com/?zsvd8o2njdjed

Facebook Fan Page: https://www.facebook.com/combonuts?fref=ts

Twiiter: https://twitter.com/aplaystudios

Canal no YouTube: https://www.youtube.com/user/aplaystudios/feed

Trailer do jogo:

> - Vídeo mashup com a banda He Saike:

> > No lançamento, entramos em contato com diversos sites e blogs, nacionais e internacionais, especializados na cobertura e análise de jogos mobile, para apresentar o jogo. > > ## Downloads, Feedbacks, métricas e updates > > Durante a primeira semana de lançamento foram muitos downloads para iOS e Android, e no decorrer das próximas semanas esse número diminui e estabilizou até uma certa média. Porém os números do Android continuam a subir e atualmente já ultrapassou, e muito, os números de downloads do iOS. > > Após o lançamento nos atentamos para os feedbacks dos jogadores através da área de comentários das lojas App Store e Google Play e das redes sociais. > > Analisamos os números e estatísticas do jogo através de sites como App Annie ([http://www.appannie.com/](http://www.appannie.com/)) e Distimo ([http://www.distimo.com/](http://www.distimo.com/)) para > > O Flurry ([http://www.flurry.com/](http://www.flurry.com/)) é uma ferramenta para analisar o comportamento do usuário em relação a seu aplicativo e/ou jogo. Através dele verificamos quais são os itens e ações mais e menos acessados e executados pelos jogadores o que nos auxilia a melhorar o nosso jogo nos próximos updates. > > Após avaliarmos a série de feedbacks que recebemos, nos organizamos e definimos quais são os mais importantes para o primeiro update. > > ## Problemas / Dificuldades > > **1) Ritmo de produção** > > O ritmo de desenvolvimento não foi constante, algumas vezes não conseguíamos nos dedicar todos os dias e ficamos período sem produzir nada no projeto o que comprometeu no número de iterações que gostaríamos para melhorar características e mecânicas do jogo. > > **2) Balanceamento inicial** > > No primeiro balanceamento a dificuldade do jogo estava muito alta, foi uma decisão tomada conscientemente, com o objetivo de tornar as partidas mais rápidas e dinâmicas, mas através dos feedbacks percebemos que poderíamos melhorá-lo nesse ponto oferecendo ao jogador 3 tentativas ao invés de apenas uma. Melhoramos isso no primeiro update que lançamos. > > **3) Pouco divulgação** > > Apesar dos esforços para divulgarmos nosso jogo, tivemos pouco exposição a respeito dele. Não tínhamos condição de investir nenhum valor nesse sentido, no que refletiu no baixo número de downloads do jogo. Uma característica interessante são os números do Android que, mesmo sem divulgação, mantém-se num número interessante e estável. > > ## Sucesso / Aprendizado > > **1) Experiência no processo de desenvolvimento** > > Sem dúvida nenhuma, o principal ponto positivo do projeto foi a experiência adquirida em todo o processo necessário para lançar um jogo, desde a criação do conceito inicial, organização e produção para execução do projeto, cadastramento e processo de validação de um jogo, conhecer e trabalhar no processo de divulgação de um jogo, análise dos downloads, métricas e feedbacks gerados pelo jogo. > > Diferente de experiências anteriores, onde todos os membros da equipe já trabalharam em empresas de jogos em suas áreas específicas, em nosso projeto tivemos que aprender e trabalhar em diferentes áreas como produção, marketing, análise de métricas etc, e todo esse conhecimento serviu para melhorar a nossa percepção em relação a produção de um jogo. > > **2) Custo direto relativamente baixo** > > O principal investimento do projeto foi o tempo de cada membro da equipe. Como utilizamos equipamentos próprios e a maioria das ferramentas eram grátis, conseguimos produzir um jogo sem custos muito elevados. > > Os principais gastos foram em licenças para a engine, cadastramento para ser desenvolvedores nas lojas, efeitos sonoros e música, plugins e manutenção do site para divulgação. > > **3) Uso da Unity no projeto** > > Produzir o jogo desde no início utilizando a Unity nos ajudou e muito no processo. > > Com um grande número de usuários, documentações e plugins disponíveis, e com a possibilidade de compilar o jogo para diferentes plataformas (iOS e Android na primeira fase) foi a melhor opção para produzirmos nosso jogo. > > ## Conclusão > > A experiência em produzir um jogo do início ao fim foi o melhor aspecto de todo o projeto. > > Muitos erros foram cometidos e aprendemos bastante a respeito de outras áreas tão importantes além do desenvolvimento direto na produção dos jogos, como análise dos números e métricas do jogo, criação de uma estratégia de marketing para otimizar a divulgação etc. > > A criação de jogos envolve diversos setores distintos e a oportunidade de trabalhar e conhecer esses diferentes setores foi uma parte muito importante para a execução do projeto. > > O objetivo agora é aplicar todo o conhecimento adquirido nos nossos próximos jogos, para que essa experiência e conhecimento possam nos ajudar a criar jogos cada vez melhores. > > Obrigado pelo o seu tempo e atenção lendo esse Post Mortem e um obrigado especial para o Bruno Cicanci que ofereceu esse espaço para compartilharmos a nossa experiência, e pela ajuda direta em nosso jogo também, muito obrigado. > > **Sandro Junki Morishita** > > e-mail: [sandromorishita@aplaystudios.com](mailto:sandromorishita@aplaystudios.com) > > portifólio: [www.junki1978.com](http://www.junki1978.com)

Postmortem: Happy Star Adventures

Sun, 11 Aug 2013 00:00:00 +0000

Este é o segundo postmortem de um jogo brasileiro que recebo para postar aqui no blog, desta vez é um jogo para o publico infantil desenvolvido com a Unity pelo Andre Dantas e publicado para Android. Confira os desafios que o Andre enfrentou em publicar seu primeiro jogo abaixo. Se você também fez um jogo e publicou em algum lugar, e quer publicar um postmortem aqui, entre em contato!

Happy Star Adventures é um jogo casual, direcionado para crianças, mas também é divertido para pessoas de todas as idades. Trata-se das aventuras de uma estrelinha que deve acumular pontos e fugir dos perigos entre céu, terra e mar.

Para vencer a aventura o jogador deve alcançar 1000 pontos em menos de 3 minutos ajudando a estrelinha a coletar itens e fugir dos vilões. Para guiar a estrela é preciso apenas deslizar o dedo pela tela do dispositivo, ou tocar no local onde deseja que a estrela se desloque.

Boa aventura!

SOBRE

Este é o primeiro jogo para plataformas móveis, desenvolvido por mim. A primeira versão foi desenvolvida em dez dias, logo após o nascimento da minha filha. Desde então, o jogo já recebeu cinco atualizações, e novas aventuras foram adicionadas. O game está disponível para Android e, em breve, para iOS.

Quem estiver interessado em jogar o jogo, antes de ler o Post Mortem abaixo, é só acessar os links:
https://play.google.com/store/apps/details?id=com.TOPgames.Happy_Star_Adventures
http://happystar-adventures.tumblr.com/

CONCEITO

A idéia do jogo veio durante os meus estudos de Unity, para desenvolvimento de jogos para celulares. Eu havia ativado a licença grátis do Android para o Unity3d (versão 3.5) para publicar os jogos para esta plataforma. Os meus jogos anteriores haviam sido desenvolvidos para WEB (Heli Escape e Pale Blue) então eu não sabia se seria tão fácil desenvolver jogos para Android, já que várias funções são específicas das plataformas móveis.

Decidi fazer um cubo seguir o meu toque. Onde eu tocasse, o cubo deveria ir. Parece ser uma tarefa fácil, mas como o Unity trabalha com um espaço 3D, e as diferentes resoluções e proporções de tamanho de tela (Aspect Ratio) devem ser consideradas, demorei algumas horas para resolver este problema.

Com este problema resolvido, comecei a imaginar um jogo, onde pudesse utilizar esta funcionalidade. No fim, pensei num jogo onde as pessoas devessem deslizar o dedo pela tela, coletando alguns itens e evitando tocar em outros.

No desenvolvimento do Happy Star Adventures, encontrei algumas dificuldades e aprendi algumas lições, que irei compartilhar aqui.

PROBLEMAS/DIFICULDADES

Iniciar o jogo sem um Game Design Document (GDD)

Como parti de uma ideia não muito concreta, terminei por desenvolver um jogo completamente sem projeto/planejamento. Agora, aprendi que isto um erro grave, pois se o desenvolvedor não tem ideia do que pretende fazer, não saberá quando acabou e durante o andamento do projeto, terá inúmeras ideias que poderão ser difíceis de incluir durante o projeto já iniciado.
Por exemplo, a minha ideia inicial era de fazer apenas uma fase, sem inimigos. Apenas uma estrela passeando enquanto coisas se moviam no background, e os itens para coleta não davam pontos para o jogador. Mostrando aos amigos e familiares, todos sentiram falta de um sistema de pontuação e de algum tipo de perigo a ser evitado. Para implementar estas sugestões, desenvolvi um sistema de pontuação e perigos que, quando tocavam na estrela, subtraíam pontos do jogador. Consequentemente, precisei desenvolver algo que mostrasse se o jogador venceu ou não a partida. Então, limitei o jogo a 3 minutos, no quais o jogador deveria atingir 1000 pontos, ou perderia a partida.

Nada destas funções estavam previstas incialmente e me tomou um bom tempo para inserir tudo isso num projeto em andamento.

“Fracasso” de Público

Apesar deste item não ter sido um erro técnico, adicionei ele neste Post Mortem, pois impacta diretamente no sucesso de um jogo.

No começo do projeto, pesquisei em alguns fóruns e vi que o retorno financeiro de jogos grátis, utilizando propagandas internas ao jogo, chegaria a US$1000 facilmente, mesmo em jogos mais simples. Porém, para chegar a esse valor, a quantidade de downloads do jogo deve ultrapassar 10.000 (estimativa).

Dei continuidade ao projeto, e após o lançamento… a frustração. Após 2 meses, apenas 100 pessoas baixaram o meu jogo e a receita das propagandas somavam US$1,33.

Apesar de eu ter feito este projeto como aprendizado, sem expectativas grandes de ganhar dinheiro com isso, eu não achava que o resultado seria tão ruim assim. Comecei a questionar se deveria continuar desenvolvendo jogos ou não.

Um ponto importante para este problema é que o jogo é direcionado para o público infantil. Mas esse problema eu não poderia resolver mais neste jogo, então precisei procurar outra solução.

Vamos lá. Cada fracasso gera uma nova oportunidade. Não desanimei e comecei a pesquisar mais sobre como fazer um jogo ter uma maior quantidade de downloads. Aprendi que a coisa não é tão fácil quanto me diziam. É extremamente importante planejar uma estratégia de marketing antes mesmo de começar a desenvolver um jogo. Monte o seu site/blog, entre em contato com outros desenvolvedores para opinarem, escreva sobre o andamento do seu projeto, coloque versões Betas para todos verem, mande press releases para sites especializados em jogos… Tudo isto tem que ser feito para aumentar as suas chances de sucesso após o lançamento.

Antes de começar a colocar esta estratégia em prática, achei que um dos problemas para a falta de popularidade do jogo é que ele possuía apenas uma fase (no Espaço) e resolvi desenvolver uma nova fase (no Campo), lançada 2 meses depois da data de lançamento do jogo.

Estranhamente, 10 dias antes do lançamento da nova fase, a quantidade de downloads começou a aumentar ligeiramente e logo depois, disparou rapidamente, atingindo uma média do último mês de aproximadamente 35 downloads por dia. As instalações totais, que demoraram 2 meses para chegar a 100, em mais 2 meses, atingiram 1800. As receitas com propagandas já atingem US$61,76.

A criação da terceira fase (no fundo do mar) já não elevou a quantidade de downloads consideravelmente, como ocorreu no lançamento da segunda fase.

A minha expectativa inicial ainda não foi atingida, mas pelo menos o resultado já não é tão frustrante quanto no início.

Falta de Fluidez no Jogo

Depois de um tempo notei que, mesmo em dispositivos mais poderosos, o jogo ficava travando rapidamente, prejudicando a fluidez nos movimentos da estrela.

Pesquisando sobre o assunto, achei duas possíveis causas para isto: Excesso de uso do Instantiate (Criação de um objeto durante o jogo) e o uso de planos com múltiplas faces no mesh, para as texturas.

Para resolver o problema do Instantiate, mudei a estratégia de CRIAR e depois DESTRUIR os objetos de jogo várias vezes, para fazer apenas o reposicionamento deles. Quando um objeto sair da tela, ele volta à posição inicial, sem precisar ser destruído e depois recriado. Esta estratégia melhorou a fluidez parcialmente.

Em relação aos planos, utilizei um plano criado no Blender, com apenas 1 face (2 triângulos) para substituir o plano nativo do Unity, com 100 faces (200 triângulos). Com isso, reduzi a quantidade de triângulos de aproximadamente 40 mil para 400, otimizando o processamento e melhorando mais ainda a fluidez do jogo.

Diferenças nas Telas dos Dispositivos

Este problema tirou o meu sono várias vezes. Mesmo já tendo chegado a uma solução, sempre que eu tentava fazer ajustes, os objetos ficavam desproporcionais dependendo do Aspect Ratio utilizado, e eu tive dificuldades para entender totalmente como o Unity tratava estas mudanças.

Inicialmente, por meio de programação, fazia cálculos baseado no comprimento (x) e altura (y) da tela. Descobri uma constante que deveria ser aplicado ao tamanho dos objetos, e multiplicava este valor pelo tamanho atual do objeto, fazendo todos os elementos do jogo aumentarem ou diminuírem, dependendo do Aspect Ratio utilizado. Que loucura!

Após a segunda atualização do jogo, decidi estudar mais este problema. Descobri que o Unity ajusta automaticamente o tamanho da câmera do jogo, dependendo do tamanho da tela em Pixels. Mas se o Aspect Ratio for diferente o tamanho da câmera deve ser ajustado via programação. Assim, descobri qual a fórmula que deveria ser utilizada para ajustar o tamanho da câmera e não precisei mais alterar o tamanho dos objetos. Ficou perfeito para o meu caso, mas esta solução apenas funciona para uma câmera em modo Ortográfico, modo comum em jogos 2D.

SUCESSOS/APRENDIZADO

Unity e Playmaker

Sem a game engine Unity, eu acho que não teria condições de fazer este jogo, já que eu não tenho muitas habilidades de programação e o Unity permite que muitas funções sejam realizadas por funções já pré-programadas na engine. Sua capacidade de exportar um mesmo jogo para várias plataformas diferentes, praticamente sem configuração extra, torna o desenvolvimento ainda mais fácil. E o melhor, a licença Indie para o Unity é gratuita.

Como não sei programar muito bem, o Playmaker foi indispensável para que eu conseguisse programar o jogo. O Playmaker é um plugin que permite que a programação seja realizada por meio de diagramas de blocos, substituindo a necessidade de programar diretamente nas linguagens do Unity (Javascript ou C#). O Happy Star Adventures foi totalmente desenvolvido com o Playmaker, sem a necessidade de digitar uma linha de código. Foram os US$45 mais bem gastos da minha vida!

Arte Vetorial

As minhas habilidades artísticas deixariam uma criança de 6 meses com inveja. Por isso, decidi me aprimorar tecnicamente, aprendendo a utilizar um programa de desenho vetorial (Inkscape) e usar figuras como modelos para fazer as texturas do jogo. Desta forma, não precisei desenvolver minhas habilidades artísticas, mantendo a arte simples o suficiente para não fazer a minha incompetência aparecer.

Apesar de saber que um artista de verdade faria algo muito melhor, estou satisfeito com o resultado final. Ficou bem melhor do que eu esperava.

Dinheiro!

Como já falei, estou recebendo bem menos do que esperava, mas já foi o suficiente para aprender algumas coisas sobre como ganhar dinheiro com aplicativos e jogos grátis.

Eu utilizo o AdMob (do Google) para colocar as propagandas no meu jogo e o AdMob me paga por cada clique que algum usuário dá nestas propagandas.

Depois que a quantidade de usuários dos Estados Unidos, Canadá e Austrália começaram a baixar mais o meu jogo, descobri uma coisa interessante. O valor pago pelo AdMob por clique nestes países chega a ser 6,3 vezes maior que o que me pagam por clique de brasileiros. Então, definitivamente, façam seus jogos também em inglês e se preocupem em divulgar seus jogos em sites e blogs estrangeiros.

Outra coisa que aprendi é que, se o jogo for curto, as pessoas não terão tempo suficiente para clicar nas propagandas. Por isso é importante planejar o jogo desde o início para que ele dure o máximo possível para ser terminado.

Rapidez e Simplicidade

Por ter mantido o jogo simples desde o início, consegui terminar a primeira versão em apenas 10 dias e já publicá-lo no Google Play.

Se o jogo levar muito tempo para ser desenvolvido, principalmente se for o seu primeiro, vai dar a você muita dor de cabeça e o fará querer desistir várias vezes durante o processo. Você ainda estará aprendendo a usar as ferramentas e se encontrar um desafio maior, após tanto ter batalhado para chegar aonde chegou, pode colocar tudo a perder, achando que nunca poderá fazer um jogo do início ao fim.

Felizmente, não senti esta pressão neste jogo e pude, logo após o lançamento da primeira versão, aprender rapidamente onde havia errado e já partir para encontrar as soluções necessárias.

Algumas pessoas não acreditam, mas quem nunca fez um jogo do início ao fim, não tem muita ideia de como é difícil fazer um jogo sozinho. Terminar este primeiro jogo te dará moral para conseguir um emprego na área ou para conseguir se unir a uma equipe maior e começar a fazer jogos ainda melhores.

CONCLUSÃO

Cada vez que começo um projeto deste tipo, me impressiono com a quantidade e complexidade de ferramentas e habilidades que temos que dominar do início ao fim, sem perder o foco. Ao fim, no entanto, a satisfação de ver o seu jogo disponível para todo o mundo é maior do que jogar todos os jogos de uma vez só.

Mas para que isso aconteça, se prepare, seja humilde, aprenda com os erros dos outros e se dedique ao máximo.

Caso alguém tenha algum questionamento adicional, pode me contatar pelo e-mail localizado no final do site: http://happystar-adventures.tumblr.com/

Para finalizar, gostaria de agradecer a todos os que me apoiaram durante o desenvolvimento deste jogo, e ao Bruno Cicanci por publicar este Post Mortem em seu blog.

Abraços para todos.

Postmortem: Come On Rio

Tue, 25 Jun 2013 00:00:00 +0000

As vezes recebo emails de desenvolvedores independentes brasileiros mostrando seus jogos recém lançados, e as vezes perguntam se eu posso divulgar. Como este blog é sobre desenvolvimento de jogos, e também meu portfólio, sempre respondi falando exatamente isso. Até que um dia recebi mais um emails desses, do Bernardo Dias, e dessa vez tive uma ideia diferente, que seria interessante para o blog, e também uma forma de divulgar o jogo: pedi para ele me enviar um postmortem do jogo.

Um postmortem é um documento muito importante de pós-produção, ou seja, é feito após o jogo ter sido lançado. O principal objetivo desse documento é contar as coisas que deram certo e errado, para que todos da equipe possam aprender e melhorar para próximos projetos.

Por ser um documento que tem como objetivo ensinar, e não é “confidencial” como um documento de game design, muitas empresas divulgam esses documentos após o término do projeto. No site Gamasutra existem muitos publicados, de empresas gigantes e grupos independentes pequenos. Este é o documento mais incrível que podemos conhecer sobre um jogo, pois nele podemos aprender tudo que foi feito para o jogo ser um sucesso, e tudo que não deu certo.

Para iniciar essa nova categoria aqui no blog, convidei o Bernardo para escrever um postmortem do seu primeiro jogo lançado para Android e iOS, o Come On Rio. O texto abaixo foi escrito por ele, contanto suas experiências e, até mais do que isso, a realização pessoal de fazer um jogo.

Olá, sou Bernardo Dias, criador de Come On Rio para iOS e Android, um jogo de lógica que tem como tema a cidade do Rio de Janeiro. Estou escrevendo esse artigo para mostrar um pouco do meu primeiro projeto de jogo, como também partilhar um pouco da experiência que pude adquirir e apontar alguns pontos que deram certo e outros que deram errado.

Primeiramente, acho importante mencionar que se você pretende desenvolver um jogo de maneira independente, esteja preparado para enfrentar dificuldades que se originam em questões completamente divergentes uma da outra, ou seja, o que quero dizer é que, por exemplo, quando a questão financeira estiver te atrapalhando, aparecerá outro problema diferente, como uma parte da programação que não está funcionando como você desejaria, etc.

É possível pensar depois de ler o parágrafo anterior: “isso é normal e acontece em qualquer tipo de projeto”, ok, mas já parou para pensar em todos esses problemas caindo apenas sobre uma cabeça: a sua, ou então, no máximo na cabeça de cinco ou seis pessoas? É bem complicado… imagina ter que pensar em todo o design do jogo (enredo, GDD, etc), criar toda a arte visual e sonora, a arquitetura e a usabilidade, programar o jogo, corrigir bugs, entre outros, e ainda ter todos esses problemas a sua volta? Isso sem citar os problemas que enfrentamos na vida, no trabalho…

Outro fator que quero citar é a mudança que o projeto vai sofrer conforme o mesmo for se desenvolvendo, claro que ele não ficará completamente diferente do conceito aplicado inicialmente, porém você terá um projeto bem modificado devido a diversos fatores, como otimização por exemplo. Mas acredite, isso é muito bom porque se trata de um fator essencial no refinamento do projeto, fazendo com que no final você perceba que algumas de suas idéias iniciais eram simplesmente bizarras.

Para aproveitar o fator das mudanças, citarei algumas que aconteceram na minha experiência de desenvolvimento em Come On Rio através de algumas coisas que deram certo e outras que não foram tão bem assim.

• Coisas que deram certo:

A realização de um sonho.
Independente do dinheiro ou do sucesso que seu jogo poderá adquirir, acho que nada mais gratificante e importante que você ter uma ideia, trabalhar em cima dela, enfrentar diversos obstáculos para no final, aleluia, você ver o seu jogo disponível para download em todos os continentes do mundo e para milhares de pessoas. Nada mais prazeroso do que estar num local, olhar para o lado e ver uma criança que você não conhece, jogando o seu jogo! Acredito que no final; para o seu primeiro projeto, aquele que vai te colocar dentro do sonho de criar um jogo; não importa se você não ficou milionário com ele ou se ele não fez sucesso mundial, seu jogo não foi um fracasso e sim um vitória! Ele é seu primeiro projeto concluído com êxito que te dará experiência e força para outros futuros projetos.

Sem qualquer tipo de censura.
Diante de tantos jogos que abordam tiros, sangue, violência ou zumbis, como escolha pessoal, queria que meu primeiro projeto pudesse abordar um tema que não houvesse qualquer tipo de censura, que pudesse ser jogado desde uma criança de sete anos, até uma senhora de sessenta anos sem qualquer tipo de preconceito. No final das contas, percebi que essa ideia principal seguiu ao meu lado até o fim.

Tema único e originado de uma maneira diferente.
Por vontade própria, eu não queria fazer um jogo clichê de corrida, zumbi ou de arma (apesar de gostar muito de todos esses). Penso que a ideia de um jogo que se passa nos principais pontos turísticos da cidade, presente em Come On Rio, nunca foi utilizada antes. Engraçado que tudo surgiu naquele dia abençoado em que num simples passeio de carro pela cidade, olhando para o maravilhoso Pão de Açúcar à minha esquerda, houve o momento em que uma pessoa que estava comigo definiu a cidade do Rio de Janeiro da melhor maneira que eu já escutei: “o Rio é a cidade mais linda do mundo, pois em nenhum outro lugar há uma harmonia tão grande entre o urbano e a natureza como há nela”. Bem, uniu a vontade de criar um jogo com uma ideia originada a partir de uma definição perfeita para mim: a harmonia entre o urbano e a natureza presente no Rio de Janeiro.

Se divertir e aprender ao mesmo tempo.
Engajando no ponto citado anteriormente, com o surgimento da ideia de um jogo sobre o Rio de Janeiro, acho que consegui completar outro objetivo que eu tinha para o projeto após a definição do tema. Penso que foi possível fazer as pessoas se divertirem aprendendo, foi possível passar um pouco de cultura e um pouco da cidade de uma maneira diferente.

• Coisas que deram errado

Vários jogos em um só.
Pois é, a princípio a minha ideia era em que cada ponto turístico que a pessoa acessasse, fosse possível jogar um jogo diferente. Bem, isso era simplesmente inviável por causa de diversos problemas como o tamanho final do jogo, otimização e tempo que o projeto levaria, sem contar o fato de fazer todos esses diversos jogos com atenção e cuidado total. Por isso no final, optei por fazer apenas um e poder dar total atenção, cuidado, vontade, etc a ele.

Terminar o projeto em meses.
Quando finalmente coloquei a mão para trabalhar em Come On Rio, pretendia termina-lo em alguns meses, porém só consegui finaliza-lo depois de um pouco mais de um ano. Acredite, o seu projeto vai demorar muito mais do que você espera. Você não tem 100% do seu tempo para se dedicar ao jogo pois tem que trabalhar ou estudar, como também você não tem milhões de reais para investir em uma equipe e em uma estrutura que vá acelerar o andamento do projeto.

Criar o jogo exatamente igual em todas as plataformas em que eu lançasse.
Apesar de não afetar a parte do jogo em si e sim a parte mais informativa de Come On Rio, não foi possível (pelo menos por enquanto) disponibilizar as fotos dos pontos turísticos para o projeto no Android, como é disponibilizado no iOS. Por querer atingir o máximo número de dispositivos Android possíveis, por questão de otimização, foi necessário retirar a parte informativa que mostrava lindas fotos do Rio de Janeiro.

Ficar rico
Pois é, pelo menos por enquanto eu não fiquei rsrsrsrs. Realmente é extremamente difícil no primeiro projeto, com pouquíssimos recursos, você conseguir captar muito dinheiro com ele. Você não tem fundos para investir em propagandas em diversos lugares e a única coisa que te resta é trabalhar muito, mas muito mesmo, para tornar o seu jogo famoso.

Como dito no início do artigo, se você conseguir ter uma ideia, trabalhar em cima dela e no final você ver essa sua ideia obtendo êxito, parabéns, você é um vitorioso! Você conseguiu superar todos os obstáculos e está iniciando seu caminho onde você sempre sonhou caminhar: desenvolvendo jogos. Uma vez li um artigo sobre desenvolvimento de jogos onde Chet Faliszek (roteirista de Half-Life 2, Portal e Left 4 Dead) deu a sugestão para quem quer trabalhar com jogos: apenas faça um. Lembro de ter lido que para ele não tem mistério, basta criar um jogo, todo dia que chegar em casa após o seu trabalho, continue o seu projeto, faça isso até que ele fique pronto e depois coloque-o disponível para venda. Eu fiz isso durante meu projeto e acredito realmente que esse seja o segredo e então sigo-o totalmente todos os dias da minha vida.

Esse foi o meu primeiro projeto onde foi possível adquirir bastante experiência no desenvolvimento de um jogo para em breve começar a lançar uns projetos em 3D usando a Unity ou outra engine que eu venha a me adaptar melhor. Só para concluir, acredite em uma coisa, você não conseguirá criar um projeto totalmente sozinho. Apesar de ter sido eu a colocar toda a mão na massa para criar tudo em Come On Rio, tive ajudas essenciais para o sucesso do mesmo, primeiramente Deus por me dar forças e recuperar minhas energias todos os dias, um grande amigo que me ajudou criando algumas artes e idéias, uma irmã que simplesmente fez um trabalho fenomenal em passar o jogo todo para inglês,familiares apoiando, e outros grandes amigos que foram beta testers por diversas vezes, inclusive alguns da faculdade que paravam de fazer o que estavam fazendo para me ajudar.

Bem, espero que esse artigo seja útil para quem quer desenvolver um jogo, e que minhas palavras tenham ajudado de alguma maneira. Obrigado a todos e principalmente ao Bruno Cicanci que me deu a excelente ideia de criar esse artigo.

Quem se interessar em ver como é o jogo, basta baixa-lo gratuitamente nos links abaixo:

Android: https://play.google.com/store/apps/details?id=com.brevo.comeonrio
iPhone/iPod/iPad: https://itunes.apple.com/br/app/come-on-rio/id595551098?l=pt&ls=1&mt=8

Página do jogo: http://www.comeonrio.com
Página do facebook: http://www.facebook.com/comeonrio

Abraços,
Bernardo Dias

Eu gostei bastante do texto, e o jogo é divertido. Clique nos links acima para baixar, e confira o trailer abaixo. Bernardo, muito obrigado por compartilhar suas experiências e boa sorte nos seus próximos projetos.

A partir de agora, sempre que eu receber algum email de sobre jogos, vou sugerir de fazer um postmortem para ser publicado aqui desta mesma forma. Se você, leitor, tem algum jogo publicado e quer compartilhar suas experiências contanto o que deu certo e errado n seu projeto, envie um email para mim (está em Contato).

Postmortem · Game Developer

Postmortem: Call of Coronga

Postmortem : Call of Coronga #

Problemas / Dificuldades #

Sucesso / Aprendizado #

Conclusão #

Postmortem: Where's my helmet?

Concepção #

Desenvolvimento #

O​ ​Visual #

Level​ ​Design #

Dificuldades #

Publicação​ ​e​ ​Divulgação #

Erros​ ​e​ ​Acertos #

Conclusões​ ​finais #

Informações​ ​Gerais #

Postmortem: Deathfense

Descrição #

Pontos negativos #

Pontos Positivos #

Postmortem: Geometry World

Postmortem: HueShark

Postmortem: Teharth Prologue - The Resources Dissolution

Postmortem: Insect

Descrição #

Dificuldades e Problemas #

Inexperiência #

Resoluções #

Tempo #

Sozinho #

Testes em celulares #

Tamanho #

Pontos Positivos #

Um grande aprendizado #

Custo baixo #

Conclusão #

Créditos #

Postmortem: Hungrymons

POSTMORTEM HUNGRYMONS #

1) INTRODUÇÃO #

2) DETALHES DO GAMEPLAY #

3) PROPOSTA #

4) O QUE DEU CERTO? #

4.1 Engine #

4.2 Perfis dos desenvolvedores #

4.3 Comunicação #

5) O QUE DEU ERRADO? #

5.1 GDD (e a falta dele) #

5.2 Planejamento #

5.3 Poucas features #

6) CONCLUSÃO #

7) DADOS #

Postmortem: Cat-Fly

Postmortem: Manual do Skate

Postmortem: Sou Sustentável

Postmortem: Combo Nuts

Postmortem: Combo Nuts #

Descrição #

Equipe #

Conceito #

Estrutura para produção #

Prototipagem #

Estudos iniciais #

Game Design Document #

Produção #

Balanceamento, QA, bug fixes e polimento #

Validação e divulgação #

Postmortem: Happy Star Adventures

Postmortem: Come On Rio

Postmortem : Call of Coronga
#

Problemas / Dificuldades
#

Sucesso / Aprendizado
#

Conclusão
#

Concepção
#

Desenvolvimento
#

O Visual
#

Level Design
#

Dificuldades
#

Publicação e Divulgação
#

Erros e Acertos
#

Conclusões finais
#

Informações Gerais
#

Descrição
#

Pontos negativos
#

Pontos Positivos
#

Descrição
#

Dificuldades e Problemas
#

Inexperiência
#

Resoluções
#

Tempo
#

Sozinho
#

Testes em celulares
#

Tamanho
#

Pontos Positivos
#

Um grande aprendizado
#

Custo baixo
#

Conclusão
#

Créditos
#

POSTMORTEM HUNGRYMONS
#

1) INTRODUÇÃO
#

2) DETALHES DO GAMEPLAY
#

3) PROPOSTA
#

4) O QUE DEU CERTO?
#

4.1 Engine
#

4.2 Perfis dos desenvolvedores
#

4.3 Comunicação
#

5) O QUE DEU ERRADO?
#

5.1 GDD (e a falta dele)
#

5.2 Planejamento
#

5.3 Poucas features
#

6) CONCLUSÃO
#

7) DADOS
#

Postmortem: Combo Nuts
#

Descrição
#

Equipe
#

Conceito
#

Estrutura para produção
#

Prototipagem
#

Estudos iniciais
#

Game Design Document
#

Produção
#

Balanceamento, QA, bug fixes e polimento
#

Validação e divulgação
#