Arquivo da tag: game development

Criando um Jogo Multiplataforma, Flash/Android, Usando a Flixel

Para esse meu primeiro tutorial resolvi mostrar o que já andei mexendo na Flixel para criar jogos em Flash e Android.

Pré-Requisitos / Ambiente de Desenvolvimento

  • Android SDK – Se você ainda não o tiver instalado, siga o passo-a-passo no link ao lado. Não é complicado, talvez só demore um pouco para baixar o SDK e as plataformas escolhidas
  • FlashDevelop – Esta vai ser a IDE que vou usar, em princípio você pode usar qualquer uma, até mesmo o bloco de notas. Mas o FD é gratuito e resolve muito bem, se não o conhecer, pode baixar que eu recomendo
  • Flex/Air SDK – Esta é a nossa principal plataforma de desenvolvimento. Se você escolher usar o FlashDevelop, pode optar para que ele instale, e configure, automaticamente o Flex/AIR durante a instalação. Não tem mistério e ele já deixa tudo pronto
  • Flixel – Esta API proverá a nós toda base de código para criarmos o nosso jogo. Ela é gratuita e open-source
  • Template da Flixel para o FlashDevelop – Depois de ter instalado o FlashDevelop, clique duas vezes veste arquivo que o template será instalado

Eu não pretendo falar aqui como configurar todo esse ambiente, mas quem quiser, neste link tem um tutorial bem simples e ilustrado. Confere lá e depois volta aqui. 🙂 Continuar lendo

Etiquetado , , , , ,

[Desnv_Multp] A Vez do Flash

Bem, a minha intenção era ter começado pela MOAI, mas por ocasião do concurso de desenvolvimento que mencionei semana passada, acabei indo tirar a poeira do meu ActionScript 3 e ir brincar com a Flixel, pra ver se dá pra encarar ou não (ainda não decidi).

Depois de algumas horas de trabalho já consegui fazer quase tudo. Tenho uma splash screen, o menu principal, a tela de jogo e o gameplay (sem ajustes de level design), incluindo pontuação e condições de derrota. Mas ao invés de seguir as especificações que eu havia dito, resolvi trabalhar com o gênero “lobos e ovelhas”, que é consiste basicamente em separar dois grupos de personagens que vão aparecendo na tela (um bom exemplo desta mecânica é o minigame com os Bob-ombs que existe no Super Mario 64 para Nintendo DS).

Bom, o meu foco, por enquanto, é fazer para o desktop/web, e não me preocupar muito com  as plataformas móveis. Porém, como consegui fazer o protótipo rapidamente, aproveitei que o processo para gerar o build para Android é bem simples com o FlashDevelop e dei uma testada.

De cara não consegui rodar o jogo num Galaxy Ace, mas não sei bem porque, pois o aparelho, em teoria, suporta o Air Mobile e tem um processador ARM11. Porém, também testei com um Galaxy S III e lá funcionou, apesar de que eu percebi um certo lag na hora de tocar e arrastar os personagens.

Ao chegar em casa pude testar em um G-Tablet e a coisa ficou séria. A responsividade do toque está péssima, não dá pra jogar, apesar de não dar nenhuma engasgada, eu imagino que seja problema de alocação da objetos. De toda forma, não pretendo parar para otimizar agora, só depois que o jogo estiver concluído, afinal, o importante é terminar o jogo, os ajustes ficam para depois.

Sobre o código do jogo, uma coisa que me ajudou bastante foi o uso da Flixel Power Tools, um plugin para a Flixel que adiciona várias funcionalidades bem úteis. As que usei até agora foram o componente FlxButtonPlus (que dá uma incrementada no botão padrão), o FlxExtendedSrpite (para usar a função de drag-n-drop) e o FlxBitmapFont (para usar no placar).

Ainda que não seja prioridade, uma coisa legal para a parte Android que estou usando no FlashDevelop é o seguinte, o meu projeto Air Mobile tem apenas a classe de ponto de entrada (document class) e todo o resto do código está referenciado como uma biblioteca, na pasta do meu projeto original.

Desta forma não preciso duplicar o código, e qualquer alteração no código do jogo está disponível para ambas as plataformas. Além disso, por ter pontos de entrada diferentes é possível fazer caminhos alternativos até começar o jogo para, por exemplo, configurar a resolução e o posicionamento dos elementos na tela. Inclusive achei até um código que faz justamente isto:

http://forums.flixel.org/index.php/topic,6031.msg34096.html#msg34096

Por fim, eu sei que o problema da performance é do meu código porque enquanto eu procurava dicas para usar a Flixel em Android, acabei esbarrando em alguns jogos feitos desta forma, e que rodaram muito bem no G-Tablet:

Etiquetado , ,

JS13KGames – Competição de Jogos HTML5

E nós temos mais uma competição de desenvolvimento rolando.

Porém, desta vez não são jogos em Flash, mas sim jogos em HTML5:

Clique para acessar

A competição começou no último dia 13, e vai até o dia 13/Set. Não é muito tempo, eu sei, mas como cada jogo só pode ter no máximo 13K de tamanho, não podemos esperar jogos muito grandes, não é mesmo? 🙂

Inclusive, a única restrição é o tamanho dos jogos, pois até o tema, o número 13, não é obrigatório, apenas desejável. A premiação inclui licenças da ImpactJS, livros sobre o tema e muitas outras coisinhas.

Aproveito para deixar a dica de um blog que eu acompanho, apesar de ainda não ter me aventurado em HTML5, e que gosto bastante do conteúdo: http://www.html5gamedevs.com/ que é mantido pelo pessoal da Photon Storm, que dentre outras coisas criou e mantém a biblioteca Flixel Power Tools, essencial para quem trabalha com a Flixel.

Etiquetado , ,

Desenvolvimento Multiplataforma, Parte 1

Depois da minha decepção com a AndEngine, eu resolvi apostar em desenvolvimento multiplataforma.

Tomei esta decisão porque eu queria fazer algo para plataformas móveis, mas ainda acredito muito na plataforma web, existem vários casos de sucesso nela, e na pior das hipóteses é um excelente mercado para trabalhar a marca e aumentar o buzz em cima do seu jogo.

A primeira coisa a fazer é pesquisar as opções disponíveis. Eu comecei, na verdade, procurando alternativas à AndEngine, pois no começo mesmo a ideia era achar uma nova abordagem par ao curso de jogos para Android. Só que em pouco tempo comecei a ver que as alternativas ofereciam mais do que Android/iPhone.

A lista até agora está assim:

  • MOAI
    Licenças free e paga, linguagem Lua, gráficos 2D e plataformas Android, iOS e Chrome
  • EMO
    Licença free, linguagem Squirrel, gráficos 2D e plataformas Android e iOS
  • libGDX
    Licença free, linguagem Java, gráficos 2D e plataformas Android, Windows, OSX, Linux e HTML5
  • Papaya
    Licença free, linguagens Python/AS3, gráficos 2D e 3D e plataformas Android e iOS
  • Cocos2D
    Licença free, linguagem Java, gráficos 2D e plataforma Android (o porting para iOS não seria tão traumático)
  • Flixel
    Licença free, linguagem ActionScript 3, gráficos 2D e plataformas Android, iOS, Windows, OSX, Linux e Chrome
  • Unity3D
    Licença free e paga, linguagens JavaScript e C#, gráficos 2D e 3D e plataformas Android, iOS, Windows, OSX, Linux e Chrome

Bem, agora é a hora de começar a estudar cada uma delas e analisar seus custos e benefícios. Eu deixei a Flixel e a Unity por último por que sei que elas funcionam muito bem e já tenho experiência com elas, e não quero ser tendencioso.

Fiquem ligados que estarei relatando aqui os meus avanços e impressões!

Etiquetado , ,

Desistindo da AndEngine

Recentemente lecionei um curso de desenvolvimento de jogos para Android na Coresoft (João Pessoa/PB). Nós escolhemos usar a AndEngine, uma engine para jogos escrita em Java e em cima do Android Application Framework, pois queríamos passar conhecimentos básicos de Android aos alunos, e também deixá-los a vontade no ambiente nativo da plataforma.

Pois bem, passado o curso eu posso dizer que não gostei da AndEgine. No começo eu estava estranhando um pouco, mas à medida que o curso foi avançando e eu fui a estudando mais, pude confirmar minhas suspeitas.

Antes que me atirem pedras, tenho que admitir que a engine é bem feita, implementa o modelo entidade-componente de forma legal, e tem muitas, mas muitas funcionalidades mesmo. São tantas classes utilitárias que o desenvolvedor se perde fácil no meio delas, e só vai descobrir mais tarde algumas soluções já prontas para problemas que ele resolveu de outra forma.

Mas apesar destes pontos positivos, existem pontos negativos que pesaram bastante pra mim.

O primeiro foi a quantidade de código que é preciso escrever, algum desse código é consequência da abordagem em cima do OpenGL ES (principalmente no carregamento de imagens, nunca vi coisa mais tosca). Mesmo depois de adquirir certa fluência com a AndEngine, você ainda tem que escrever muita coisa para poder colocar um sprite controlável na tela.

Tudo bem que neste ponto eu acabo fazendo uma comparação com a Flixel. Eu sei que esta última é feita em ActionScript 3, que o framework do Flex é mais simples que o OpenGL ES, mas no fim não importa. A curva de aprendizado é bem mais suave do que com a AndEngine. E a proficiência vem mais facilmente, e com ela a velocidade para prototipar é bastante alta.

O segundo ponto é a documentação. Ou a falta dela no caso. A AndEngine não possui uma documentação centralizada, o código-fonte não é bem comentado, e você acaba precisando procurar pelos fóruns da vida. Pra piorar, o desenvolvimento dela é bem ativo e se você utilizar a versão mais recente (o que é recomendado) você vai acabar sem achar nada e ter que perguntar diretamente ao autor, Nicholas Gramlich. O que não é tão ruim, pois ele costuma se dar bem com a comunidade, mas nem por isso o processo não deixa de ser um entrave.

Enfim, depois dessa experiência eu decidi tentar, mais uma vez, tocar um projeto pessoal e quero tentar algo para dispositivos móveis.

E que de preferência fosse multi-plataforma…

(Continua em um próximo post :))

Etiquetado , , ,