BlowThemAll e o GIIEditor

Estou trabalhando no desenvolvimento de um jogo online open source do mesmo gênero que Bomberman chamado BlowThemAll. Recentemente consegui finalizar o editor que será utilizado para a criação de personagens, blocos e bombas (sim, o jogo será completamente customizável).

Antes de falar sobre o editor, acho que devo discutir sobre o problema que ele ajuda a resolver.

O problema

No jogo é possível encontrar vários objetos (personagens, bombas e blocos) que possuem animações. No entanto, existem alguns problemas em criar as animações para o jogo, pois elas possuem características próprias. Nessa seção vou detalhá-las.

O caso de animação mais simples entre os objetos do jogo é a bomba, que segue a mesma lógica de um GIF animado, uma animação estática, em que existe uma sequência de imagens que são processadas sequencialmente, com um intervalo definido entre uma imagem e outra.

Mas não podemos usar imagens GIFs, pois nem todas as animações do jogo seguem a mesma lógica. Como exemplo há os blocos, que, diferente das bombas, se mantêm estáticos, até o momento em que são explodidos e então uma animação ocorre. Diferente das bombas, a animação do bloco é dinâmica, pois pelo menos uma de suas propriedades (nesse caso o tempo em que ele fica estático), só pode ser conhecida depois que o jogo inicia.

Ainda no exemplo do bloco, podemos dizer que sua animação, apesar de dinâmica, é até simples, pois ela é linear, já que sempre segue a mesma sequência. Mas nem todos os objetos do jogo possuem animações que possuem essas características. Há o personagem, por exemplo, cuja animação segue uma sequência não-linear (em um dado momento ele pode estar em um estado de animação que simule o movimento na direção norte, e em outro momento um estado que simule o movimento em outra direção). Normalmente seria possível simular uma animação não-linear com uma animação linear, mas no caso do objeto do personagem, essa parte da animação também é dinâmica, eliminando essa possibilidade.

Princípios que a solução deve seguir

Além de resolver o problema, a solução que devemos adotar deve cumprir algumas promessas, que a adeque as regras de desenvolvimento utilizadas no jogo. Alguns pontos importantes em nosso caso são:

  • Lógica e funcionalidade devem ser separadas de arte e design: Então quando o desenvolvimento iniciar, o designer/artista deve ter liberdade de mudar muitos aspectos da animação sem que seja necessário esforço em conjunto dos desenvolvedores
  • As animações devem utilizar imagens vetoriais e padrões aberto: Queremos que o jogo rode nas principais plataformas disponíveis hoje, então devemos favorecer o uso de padrões abertos. Além disso, o uso de imagens vetoriais é interessante para permitir que o jogo funcione bem em diferentes resoluções de forma eficiente.
  • Deve ser possível armazenar, enviar e trocar o conjunto de animações para cada objeto: Assim cada jogador pode criar um personagem com identidade própria e usar essa identidade visual ao jogar durante as partidas, sejam elas locais ou online.

A solução

A solução que eu criei se apoia em três recursos. O primeiro é um esquema para arquivos INI descreverem o conjunto de animações do objeto. Para descrever essas animações, estados são definidos, e cada estado tem sua própria sequência de imagens, período de transição e ação ao término da animação (que é sempre uma referência a um novo estado ou começo dele próprio). Para permitir o dinamismo necessário no jogo, os estados possuem nomes, permitindo que acontecimentos no jogo mudem o estado do objeto usando esse nome como referência.

O segundo é um conjunto é um conjunto de arquivos de imagens vetoriais armazenadas no formato SVG.

O empacotamento do arquivo INI e dessas imagens compõe o terceiro recurso. O formato de empacotamento que utilizaremos no jogo é o rcc.

A implementação para essa solução foi algo rápido e seu código já encontra-se no repositório do jogo. O vídeo abaixo demonstra o uso dessa tecnologia:

O editor

Para o artista, porém, é algo inconveniente usar técnicas com as quais o programador está acostumado. Eu não conheço muitos artistas que gostariam de trabalhar editando arquivos descritivos e de marcação e usando programas que possuem uma interface de linha de comando para gerar o resultado final.

Para resolver esse outro problema, eu criei um editor com interface gráfica que possui, entre outras, as seguintes características:

  • Gerencia as imagens que serão incluídas no arquivo final
  • Gerencia os estados dos objetos, permitindo que vários estados sejam abertos simultaneamente, agrupados em abas
  • Pré-visualiza a animação do estado particular
  • Suporte a zoom
  • Além de compilar o resultado final, permite criar e salvar projetos
  • Permite criar um projeto vazio ou usando um dos modelos incluídos como base
  • Possui uma interface bastante intuitiva

Um vídeo que eu havia feito durante um dos estágios de desenvolvimento da ferramenta:

Caso queira utilizar essa ferramenta, baixe o código e compile-o usando os comandos:

Em breve devo colocar no repositório AUR para facilitar a vida dos usuários do Archlinux e algum dos outros desenvolvedores deve compilar uma versão para windows e distribuir o executável.

Para quem usa Archlinux: Coloquei o giieditor no AUR: http://aur.archlinux.org/packages.php?ID=51991.

NOTA: Para a funcionalidade “compilar” funcionar, você deve ter o rcc (aplicativo distribuído junto com o Qt) instalado e acessível pelo PATH.

Tags:,

Comentários (with MarkDown support)

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: