Se você trabalha com jogos ou até mesmo desenvolvimento de softwares, já deve ter ido ao menos uma vez em alguma palestra que dá dicas de sucesso para o seu game. “Nosso título estourou por causa disso e daquilo Siga dessa forma e você tem uma garantia de qualidade” é algo comum de ser ouvido.
Entretanto, o que as empresas que enfrentaram o fracasso, a baixa quantidade de vendas e críticas negativas nas análises têm a dizer? Às vezes, exemplos do que não fazer são tão bons quanto as dicas de sucesso, demonstrando que mesmo equipes experientes podem não observar erros óbvios.
Na semana passada, durante a Game Developers Conference 2015, quatro desenvolvedores subiram ao palco para contar suas experiências negativas com jogos mobile visando aumentar a visão de negócios de quem está começando agora.
Não se apegue demais a suas ideias
Please Stay Calm foi um jogo muito bem recebido e criado pela desenvolvedora Massive Damage. Com tamanha fama, era certo que a equipe produziria novos games no futuro. E foi aí que surgiu a ideia de criar Pocket Mobsters, um jogo que misturava a temática da série adulta da HBO Boardwalk Empire com a estética casual do pixel art.
Porém, o jogo não se saiu bem nas vendas. Apesar de ter sido baixado mais de 200 mil vezes em seus cinco meses de vida, o retorno de investimento não foi bom. O CEO da empresa Ken Seto explica que o público que gosta do tema de máfia não é fã de um visual fofinho, contrastando as temáticas apresentadas.
Outro problema grande foi Pocket Mobsters ter sido feito inteiramente em cima da estrutura do título anterior, Please Stay Calm. É normal que desenvolvedores utilizem código pronto de outros projetos, pois economiza um bom tempo de trabalho. Entretanto, Seto explica que a equipe pequena dependeu demais do que já estava feito e teve dificuldades para fazer alterações no código pronto.
Conhece a expressão “o barato sai caro”? Pois foi justamente o que aconteceu. A equipe levou mais tempo para alterar as mecânicas do jogo do que teria gasto se tivesse começado tudo de novo. O CEO dá o conselho de não se apegar demais às ideias e decisões: se algo estiver dando errado, corte de uma vez e continue em frente. Apesar de ter amado o jogo, a desenvolvedora retirou Pocket Mobsters do ar poucos meses após seu lançamento.
Foque o desenvolvimento na ideia inicial
A East Side Games queria fazer um game em que a ideia fosse combinar puzzles com lutas de robôs. E, desse conceito, surgiu MightyBots, um título de combate baseado em tempo. Ou seria ele baseado em turnos? Esse foi o maior problema da criação do jogo.
A equipe passou por uma produção caótica, com ciclos de seis semanas de desenvolvimento que precisavam demonstrar resultados enormes de avanço. Contudo, mesmo depois de muito tempo de programação, ainda não estava decidido se MightyBots teria combate baseado em tempo ou em turnos.
A decisão veio depois, e baseado em tempo foi a escolha da East Side. O problema não seria muito grande se a decisão fosse mantida. Entretanto, depois de gastar recursos e tempo em desenvolver essa forma de combate, a direção optou por trocar a mecânica de combate para ser baseada em turnos.
Esse vai e vem do que produzir gerou custos altos. O resultado foi o lançamento do app incompleto, gerando esforço extra no período de produção. Apesar de o jogo ter sido nomeado para a Canadian Video Game Awards, o retorno de investimento foi pequeno. O CEO Joshua Nilson diz que aprendeu que, se a mudança for drástica demais, é melhor fazer outro jogo.
Pesquise seu público-alvo antes de criar o jogo
Ok, você quer fazer um jogo de robôs e descobriu que o público que gosta dessa temática tem a faixa etária entre 16 e 25 anos e é muito ativo em redes sociais e lojas de aplicativos – isso é apenas um exemplo fictício. Tudo parece certo para o título deslanchar, mas ele fracassa. Depois de lançado, você descobre que não há um único game com esse tema nos 200 aplicativos mais baixados da App Store.
E foi exatamente isso o que aconteceu com Gizmonauts, jogo produzido pela Backflip Studios. Mas esse foi apenas um dos erros da desenvolvedora. O CEO Bryan Mashinter explica que a equipe amou tanto os elementos do jogo anteriormente produzido, DragonVale, que não conseguiu pensar fora da caixa.
Em outras palavras, Gizmonauts copiou quase tudo o que DragonVale já oferecia, mas de uma forma pior. A expectativa em cima do novo título contribuiu para a experiência negativa. Bryan diz que prometer coisas melhores nem sempre é uma boa estratégia, pois, apesar de garantir bons números no lançamento, o sucesso despenca com o passar do tempo.
Publishers nem sempre são a luz no fim do túnel
A Owlchemy Lab foi a desenvolvedora por trás de Jack Lumber, um game muito criativo e que conquistou um sucesso relativamente alto. O jogo estava sendo produzido no tempo certo e recebendo um ótimo feedback dos fãs. Logo seria publicado pela própria desenvolvedora, sem a mão de investidores ou publishers.
A qualidade de Jack Lumber ganhou a atenção da Sega, que procurou a equipe para fazer um acordo comercial. De uma forma resumida, a publisher seria a responsável pelo marketing e a publicação para iOS do game, ganhando uma porcentagem das vendas na plataforma da Apple.
No final das contas, a Sega apenas escreveu uma divulgação para a imprensa – que estava com informações erradas e precisou ser reescrita pela Owlchemy – e utilizou um material de divulgação próprio para divulgar Jack Lumber, sem as artes oficiais. O resultado foi uma baixa quantidade de downloads da versão de iOS e trabalho e dinheiro desperdiçados.
Os reviews foram ótimos e logo a desenvolvedora portou o título para Android, Windows Phone e Steam, garantindo um bom lucro. Apesar de a Sega não ter feito nada desastroso, também não fez nada que contribuísse com o sucesso de Jack Lumber. O CEO Alex Schwarts disse na GDC que é preciso levar em conta o melhor momento e as condições certas para adotar uma publisher no desenvolvimento.
Aprender com os próprios erros é uma forma de crescer e melhorar o seu trabalho. Apesar das dicas de sucessos serem boas, conhecer as falhas de quem já passou por situações ruins também pode ser muito útil para a equipe. O que você achou dessas ideias?
Categorias
