deV( )id Games | because we're tired of no return;

TAG | Pixel Art

Bom, demorou um pouco mais do que eu esperava a princípio–graças, em parte, à adaptação para celular–mas aqui está, para quem quiser saber detalhes nus e crus de como é desenvolver um one-button-two-days-game 🙂

Ah! Espere! O jogo agora tem uma versão que roda em Androids que suportam Flash! Veja no Kongregate Mobile! E aqui está um QRcode bonito para você que não quer copiar um link gigante pro celular: Scroll Loc MobileOk, agora que você perdeu mais 10 minutos da sua vida se divertindo com Scroll Lock (não esqueça de dar estrelas pro jogo!) podemos voltar à nossa programação normal.

 

O que deu certo

1) O conceito. Tudo bem que essa aqui é um pouco de roubo, porque eu simplesmente acordei no domingo com o jogo pronto na minha cabeça. Agora acredito quando lembro da J.K.Rowling falando que isso aconteceu com todo o universo de Harry Potter em uma viagem de trem! Mas enfim, é claro que não surgiu do nada. Tudo começou alguns dias antes, quando o Denilson twittou a respeito do / ESCAPE \, um one-button game que só usava a tecla Esc do teclado, em um trocadilho onde você controlava uma criatura que tinha que fugir de uma torre vertical com espinhos nas paredes e um laser mortal que subia a torre logo atrás de você.

Achei o jogo bem divertido (apesar de não conseguir ganhar a badge difícil =/ ), e fui olhar os comentários a respeito. Um deles era bastante interessante…

“Next game: Scroll Lock Please? I have to use this useless thing.”

Minha mente de desenvolvedor, obviamente, ligou na hora, e pensou em como criar um jogo em que o gameplay central consistisse em um trocadilho com a tecla Scroll Lock (e fosse controlável somente por ela). Não demorou muito para pensar que a idéia seria que o pressionamento da tecla “travasse” a “rolagem” de alguma coisa.

Tá, mas e aí?

Bom, não sei. Digo, não sabia. Então isso foi ficando meio de lado ao longo da semana. Até que acordei no domingo com a idéia de um boneco palito em uma esteira da morte com pistões que o ameaçavam. Mais do que a idéia, me veio de súbito a imagem do jogo completo, com toda a direção de arte (que foi algo que também deu certo, veja mais pra frente), o que foi muito bom para manter ao longo do desenvolvimento uma visão clara de como eu queria que o jogo ficasse.

 

2) O desafio. Junto com a visão de como o jogo ficaria, veio a realização de que ele seria razoavelmente simples de fazer. Talvez simples o suficiente para que eu fizesse sozinho (que era algo que eu queria e sabia que precisava: fazer um jogo sozinho do começo ao fim). Talvez simples o suficiente para ser feito em um ou dois dias.

No fim das contas, eu estabeleci um desafio, quase como um Ludum Dare pessoal: fazer um jogo sozinho em dois dias, com o protótipo de gameplay funcional na noite do primeiro dia.

Para garantir que nada atrapalharia a experiência, eu não comentei a respeito do projeto com ninguém (nem com o Yanko!) exceto o Denilson, porque ele foi a origem da idéia original, tem um bom senso crítico a respeito de jogos, e eu queria ter alguém para ajudar a opinar (como jogador) a respeito de alguns detalhes do gameplay.

No final das contas, não acho que manter contato e mostrar o trabalho em progresso para uma pessoa em especial tenha atrapalhado o objetivo ou ajudado o jogo a ficar pronto em dois dias (corrompendo assim o desafio), dado que não me fez ter MENOS trabalho em momento algum. Apenas serviu para ajudar o jogo a ficar mais divertido, e foi uma ótima experiência em playtesting contínuo 🙂

E enfim, o desafio foi atendido. O gameplay estava totalmente pronto na primeira noite, e o dia seguinte consistiu basicamente de polimento e adição de detalhes como a API do Kongregate e o botão do Twitter.

 

3) A direção de arte. Ok, convenhamos: como artista gráfico, eu sou um ótimo programador. Talvez até conseguisse aprender a ser um artista meia-boca se corresse atrás de material para isso e aprendesse a usar um Photoshop da vida, mas o fato é que nunca o fiz.

Eu queria fazer um jogo sozinho em dois dias,  e a única ferramenta gráfica que eu sabia usar era o Paint do Windows. E, como ele não serve pra muita coisa além disso, a definição da direção de arte se criou na minha frente: o jogo haveria de ser feito em Pixel Art.

Não por acaso, este é o único estilo de arte que eu realmente estudei (informalmente) por algum tempo, analisando sprites de vários jogos antigos e como a colocação cuidadosa de cores e pontos pode fazer nosso cérebro inferir mais informação do que a imagem realmente contém, da forma que o artista quer. Acredito que essa pequena experiência tenha ajudado os gráficos do jogo a irem do “QUE BOSTA LOL PARECE UM RAGECOMIC FEITO NO PAINT POR UM 12YR OLD” para “ei, esse pistão é bem maneiro”.

 

4) A linguagem/biblioteca. O jogo foi feito em Flash (ActionScript 3.0) e, para quem não sabe, usando a biblioteca Flixel e a IDE FlashDevelop. Não por acaso, este é o mesmo ambiente que foi usado pelo Yanko pra fazer o Corrida Presidencial, em cujo desenvolvimento eu também não me envolvi diretamente, então não tinha aprendido nada a respeito dele.

Então me vi deparado com uma escolha: aprender AS3+Flixel e fazer o jogo no que parecia ser um framework bem adequado para o conceito do jogo (afinal o próprio Canabalt foi feito com ela!) ou fazer em Unity, que eu já conhecia, mas seria matar uma formiga com um canhão de íons.

Acabei decidindo, no final, pela Flixel, mesmo tendo em mente que tudo teria que estar pronto em no máximo 2 dias. Hey, era um desafio! Se era pra ser desafiador E uma experiência em aprendizado condensado, melhor aproveitar que já estava na chuva e aprender uma linguagem e framework novos.

Esta escolha se mostrou extremamente certeira, porque a Flixel é realmente muito simples de aprender e usar, e AS3 é bastante parecido com as linguagens com as quais estamos acostumados (C/C++, Java e Javascript). Além disso, todas as ferramentas necessárias são gratuitas independentemente de quaisquer fatores–coisa que a Unity, por exemplo, não é–e inclusive para publicação em várias plataformas: em especial Android (que já tem uma versão web otimizada para ele) e iOS, que estão nos planos para um futuro próximo 😉

Considerando que com Unity a publicação para mobile custaria $1500 pela Unity Pro e mais $1500 para cada plataforma… é, financeiramente foi uma ótima escolha!

Ilustração artística da relação entre os custos de publicação com Flixel e Unity. Sim, foi feita no Paint.

 

5) A data de lançamento. Não sei bem explicar essa, então vai ser rápida. Mas foi simplesmente muito bom lançar o jogo numa terça-feira! Não sei se porque todo mundo tava entediado com o trabalho e queria um motivo pra passar o tempo jogando algo novo na véspera do feriado, mas a popularidade do jogo aumentou bem rápido, dentro e fora dos nossos círculos sociais.

 

Bom, como eu disse lá em cima, o desenvolvimento do jogo no fim das contas foi um sucesso, então não acho que nenhuma decisão tenha sido, em si, errada e não me arrependo de nenhuma delas. Mas vou comentar um pouco sobre algumas decisões que causaram pequenos problemas, por motivos na maioria das vezes fora do meu controle.

 

O que deu errado

1) A linguagem/biblioteca. Pois é, irônico repetir um ponto que era muito forte na lista do que deu certo. Mas a maior fonte de problemas durante o desenvolvimento foi a Flixel. Explico: ela é realmente boa, tem exatamente a complexidade necessária, e uma API simples e direto ao ponto.

O problema é que essa API muda o tempo todo.

Observe que a API da Flixel é totalmente instável, e a cada versão classes novas são adicionadas, métodos são modificados, e o pior–muitos métodos e classes simplesmente são removidos (sim, REMOVIDOS, não só deprecados), sem nenhuma observação na documentação.

A consequência óbvia disso é que A Internet não sabe mexer com Flixel: metade dos recursos que se encontra (além da documentação oficial) sabe mexer apenas com a versão passada da biblioteca. Mesmo no próprio fórum da Flixel havia muita informação conflitante, e eu cheguei a achar que estava ficando louco por não encontrar na minha distribuição uma classe que o mundo parecia concordar que existia (para constar, era a FlxKong, para acessar a API do Kongregate).

 

2) A integração com a API do Kongregate. Uma das coisas que eu queria desde o momento zero era publicar o jogo no Kongregate, e integrar com a API de stats de lá. Mais pra ser fácil de gerenciar o jogo, já que eles já têm uma plataforma pronta, e porque eles também te dão uns trocados em propaganda, o que nunca é demais 🙂 Além disso, seu jogo tem que implementar a API de stats para ter chance de ganhar badges um dia, o que faz com que ele seja muito mais jogado.

Bom, isso causou dois problemas graves: um durante o desenvolvimento, e um no dia do lançamento, com o jogo já publicado.

O primeiro foi a grande dificuldade para descobrir como usar a API do Kong com Flixel. Os exemplos na documentação para desenvolvedor do Kong supõem que você está usando Flash direto, e a Flixel encapsula a maioria das coisas, inclusive algumas que eu teria que acessar. Enquanto isso, teoricamente existia uma classe na Flixel, a FlxKong, que faria a comunicação, mas aparentemente essa classe foi descontinuada. Acabei encontrando um snippet de código pronto para fazer essa comunicação–mas isso demorou umas boas horas.

O segundo problema foi que o backend de stats do Kongregate aparentemente estava meio instável no dia em que o jogo foi lançado (pelo que eu pude testar em outros jogos), então muita gente sofreu atrasos grandes para ter suas pontuações computadas, e muitas simplesmente foram perdidas. Tudo voltou ao normal no dia seguinte, sem mudar nada no meu código, então suponho que o problema nada tinha a ver comigo. Ainda assim, isso chateou algumas pessoas, e imagino que posa ter influenciado negativamente no rating do jogo.

 

3) O botão do Twitter. Não, sério. Eu perdi umas quatro horas só pra fazer esse maldito botão funcionar direito. Sempre em algum momento alguém parecia estar corrompendo a URL da requisição pro Twitter–ou eu mesmo, ou o Flash, ou o Kong, ou o navegador, ou o próprio Twitter–e o twit chegava lá corrompido, com partes da URL no texto e todo tipo de bizarrice.

No fim das contas a página do jogo no Kong já tinha um botão de Twitter, então eu acho que essa poderia ser uma dor de cabeça evitável–mesmo se quisesse ter um botão mais visível, acho que eu poderia usar magias de JavaScript pra simular um clique no botão da página–mas eu queria que o Score da pessoa aparecesse no Twitter junto. Acabei sendo cabeça-dura com isso naquele espírito inicial de aprendizado, mas foi bem desagradável no fim das contas!

 

Enfim, acho que é isso. Poderia continuar falando mais sobre pequenos acertos e pequenos problemas, mas aí ninguém leria esse post (que já está gigante!). Se alguém tiver alguma dúvida ou curiosidade sobre qualquer parte do desenvolvimento que eu não comentei a respeito aqui, fique à vontade para deixar um comentário ou me mandar uma mensagem no GTalk/GMail/Facebook/Twitter 🙂

· · · ·

Theme Design by devolux.nh2.me