Bow and Arrow em Ruby com Shoes

Quando o professor da faculdade pediu um projeto para ser apresentado na cadeira de Linguagem de Programação 2 (que na minha faculdade é considerado orientação a objetos, ensinado com Java), eu perguntei se poderia fazer o projeto em outra linguagem que não fosse Java, e felizmente o professor aceitou.

Decidi então programar em Ruby, sobre o projeto, eu não tenho muita criatividade para softwares esporádicos, então minha decisão foi fazer um remake de um antigo jogo para windows 95, o "Bow and Arrow" (ou barrow para os mais chegados =P). Decidi que seria um bom desafio e me ajudaria a entender melhor o Ruby (já estudo Ruby a cerca e 1 ano, mas nunca fiz mais do que pequenos scripts e testes).

Depois de roubar todos os sprites do jogo original, eu comecei a programar, para criar a camada visual eu decidi utilizar o Shoes, porque eu ja tinha algum conhecimento sobre o mesmo, e também porque tem muito jogo feito com ele, então a comodidade me fez ficar nele.

Antes de começar eu decidi ler algums fontes de jogos feitos com Shoes, baixei vários jogos no shoesbox para ver como as pessoas estavam lhe dando com frame-rate, sprites animados... Infelizmente essa parte da missão não teve muito resultado, pouquissimas aplicações utilizavam algum tipo de engine para seus jogos e as soluções não tinham nada de muito sofisticado, a única conclusão foi que todo mundo usada o metodo "animate" para o main loop do jogo.

No começo do desenvolvimento eu fiz tudo em apenas um arquivo Ruby, apenas para fazer alguns testes, nesse ponto era possível controlar o arqueiro com o mouse, e atirar as flechas (que eram imediatamente repostas após atiradas). Depois de vários testes feitos eu vi que era hora de organizar aquela bagunça, então comecei a criar uma engine própria para o jogo.

A primeira parte era deixar o arquivo principal o mais enxuto possível, então deixei ele apenas iniciando a aplicação em Shoes, criando uma instância da classe do jogo, iniciando o "animate" e chamando o loop do jogo a cada iteração do animate. Eu sabia que eu precisaria separar as fases do jogo, mas eu decidi começar o desenvolvimento pelos elementos do jogo, então comecei pela classe básica dos elementos, essa classe não tinha muita coisa, apenas definição de variáveis básicos do elemento (x, y, largura, altura), teste de colisão (que também fiz a sobrecarga do operador & para testar colisão entre objetos, hehehe), e um método draw vazio. Sem muitas delongas, a partir dessa classe eu fiz a classe do herói, das flechas e dos balões.

Para o herói de inicio a coisa foi um pouco mais complicada, a inicar pelo problema de "estados", afinal o herói deveria poder ter vários "estágios":

• stand -> estágio padrao, onde ele pode puxar a flecha para atirar
• armed -> estágio armado, onde ele está preparado para atirar uma flecha
• waiting -> estágio de aguardo, onde ele tem que aguardar um tempo para poder voltar ao stand para poder atirar novamente

Se eu estivesse em outra linguagem eu provavelmente teria feito um "switch/case" (ou case/when para ruby =P) dentro do método draw que iria fazer um teste para cada estado. Mas, eu to no mundo do Ruby, e eu já sabia que eu precisaria controlar estados em vários objetos diferentes. Então eu fui a lugar para criar uma StateMachine.

A idéia básica era simples, seria um módulo, onde teria métodos de classe para adicionar estados (onde os parâmetros seriam o nome do estado e um bloco para a execução do estado), e também o módulo já deveria sobrever o método draw para acionar o estado correto, e por final, métodos para ler/modificar o estado atual.

A idéia não teve problemas... já para implementar... Eu gastei umas 3 horas para fazer essa classe, não por ser difícil ou trabalhosa, mas por não conhecer direito essa parte do Ruby. Depois de alguns estudos eu vi que o correto seria usar algo do tipo:

module StateMachine
  def self.included(base)
    base.extend ClassMethods
  end

  module ClassMethods
  # aqui vem os métodos da classe
  end
end

Até ai tudo bem, mas meu primeiro erro foi conceitual, em não pensar na classe como uma instância, isso me "comeu" algum tempo, quando eu me dei conta disso, então eu sabia que deveria salvar os estados no "objeto da classe" e depois acessa-los a partir das instâncias. Depois de várias e várias tentativas, eu descobri que poderia fazer isso usando variáveis de instância dentro do ClassMethods, e acessando elas atravez de self.class dentro da instância (até agora não sei se foi o caminho mais correto, mas funcionou).

detalhe traumatizante: o Shoes não existe mensagens no console padrão, e quando tinha algum erro de execução ele simplesmente deixava a tela branca ou travava o jogo, sem dar nenhuma mensagem de erro... so depois de desenvolver cerca de 70% do projeto eu descobri que apertando "alt+/" o Shoes abre um console onde apareciam as mensagens de erro... agora imagina testar recursos de linguagem que você não conhece sem conseguir ver mensagens de erro (é algo parecido como depurar JavaScript em IE 6)

Depois disso a StateMachine ficou ok, e usei ela para implementar os estados no herói. Outro detalhe legal nesse ponto foi o uso de um hook, pois existiam ações do herói que eram comuns a todos os estados, então para resolver isso fiz um alias para o método draw da StateMachine, e redefini o método draw executando as ações padrão e depois chamando o draw do StateMachine (agora chamado de old_draw). Com isso eu já tinha feito várias coisas do jogo, tava indo tudo bem, então eu fui desenvolver usando o "Hackintosh" do meu notebook (tenho windows e leopard no meu HP), então me dei conta de um problema, no Mac o jogo estava rodando mais rápido... Isso significava que o "animate" do Shoes não garantia o frame-rate (oque pra mim até o momento era verdade...). Com isso foi nescessário a criação de calculos sobre tempo, eu fiz isso dentro do loop principal do jogo, calculanto o tempo passado entre o atual momento e a ultima iteração, tive que mudar muita coisa no jogo inteiro para sair passando esse "tempo passado" por entre todas as classes (em verdade... ontem depois de ter o jogo pronto eu pensei seriamente se não deveria ter deixado isso numa variável global ou em um ponto de acesso geral, para não ficar repassando isso por todo mundo, mas agora ja foi, que sabe num próximo refactoring?), e fora isso também foi nescessário mudar os cálculos de velocidade (que já estavam sendo usados nas flechas e nos balões) para trabalharem de acordo com o tempo.

Timing ok agora, o jogo no windows rodava com um FPS menor que no Mac, mas a velocidade do jogo era a mesma :)

Outro detalhe no herói, eu decidi que nessa versão não seria nescessário clicar com o botão direito do mouse para recarregar a flecha (nunca gostei desse detalhe no jogo original), mas para também não ser uma "metralhadora ambulante" eu coloquei um pequeno delay para ele poder atirar uma nova flecha (a troca entre os estados). Oque estava me incomodando era a implementação desse delay... no momento salvava o tempo ao entrar no estado de waiting, e no estado de waiting verificava o tempo passado a cara iteração até passar o tempo nescessário para então voltar ao estado stand. Me lembrei então do método setTimeout do Javascript, que me seria extremamente conveniente nesse caso, mas que não existe no Ruby. Então foi a hora de criar uma TimerMachine!

Como eu já tinha o dado do tempo passado a cada ciclo isso não seria difícil de implementar, e de fato não foi. Quando pronto, era apenas incluir o módulo TimerMachine, e dentro do ciclo do objeto deveria ser chamado o método update_timers(elapsed) para atualizar o tempo dos timers. Para utilizar era apenas fazer "add_timer(time, repeats, &block)", e o bloco seria executado após o tempo (em segundos). O repeats por padrão era 1 (executar apenas 1 vez) e em caso de 0 seria repetido indefinidamente. Essa implementação já estava adequada, mas me liguei que poderia ir mais longe :)

Como por padrão o método de update de todos os objetos era draw (de fato essa era a interface para o acesso externo), então eu criei um hook automático no módulo do TimerMachine, que verificava se a classe onde o mesmo foi incluido tinha o método draw definido, e em caso de sua existência, ele mesmo ja criava o hook chamando o update_timers automaticamente (Ruby's Magic!!)

Acho que posso dizer que depois desse ponto o desenvolvimento ficou mais fácil, basicamente eu criei a abstração para as fases e separei a parte básica do jogos dos níveis, fui criando as fases 1 a 1, sempre fazendo refactoring quando nescessário até o projeto sair.

Para quem quizer ver "mais de perto" os problemas que falei, por favor veja o histórico de código do projeto: http://github.com/wilkerlucio/bow_and_arrow/tree/master

O projeto também foi enviado para o ShoesBox (coleção de aplicações feitas em Shoes): http://the-shoebox.org/apps/139

Quem quizer dar uma olhada no gameplay do jogo eu enviei um vídeo para o youtube:



Para rodar o jogo é preciso ter o Shoes instalado na maquina, você pode baixar o Shoes em: http://www.shoooes.net/

Com o shoes instalado, apenas faça um clone do projeto na sua maquina, e rode com: shoes bow_and_arrow.rb

Como ainda me considero iniciante em Ruby, programadores mais experientes podem encontrar várias coisas no código que poderiam ter sido melhor implementadas com Ruby (tenho certeza que existem muitos pontos assim no codigo...), mas mesmo assim acho que pode ser útil para quem quizer dar uma estudada ;)

Quem quizer dar mais algum progresso para o jogo (eu ainda não implementei todas as fases do jogo original, como por exemplo a fase do Bull's Eye onde você tem que acertar o meio do alvo) por favor usem o GitHub como várias de vocês já devem conhecer ;)

Espero ter conseguido contribuir com algo para a comunidade, qualquer dúvida sobre o jogo podem perguntar pelos comentários ;)