Voltar

Diário de bordo Strings Fighter: tecnologia

Em Diários de bordo | 08/10/2010 01:26

Em mais esta parte do Diário de Bordo do projeto de jogo Strings Fighter, discutirei sobre a tecnologia empregada na construção do jogo e em como as escolhas do time ajudaram o projeto a ser entregue no prazo estipulado (embora não fosse um projeto comercial, a faculdade estipulou uma data para apresentação) com boa parte dos elementos que havíamos previsto.

XNA: a primeira tentativa

XNAProva de conceito de animação no XNA.

Inicialmente, o projeto seria feito em XNA para apresentação de multiplayer entre Xbox 360 e PC e também por conta da grande familiaridade de parte do time com a plataforma. Um protótipo chegou a ser feito, com movimentação de personagens e animações simples para prova de conceito. Todavia, por conta de o XNA no Xbox 360 somente permitir multiplayer a partir da Live e da não possibilidade de execução de scripts Lua (o Compact Framework no qual o XNA é baseado não suporta execução de códigos não .Net), além de o framework não ser multiplaforma (executar o projeto em Linux era algo que tínhamos em mente, mas não como prioridade), fizeram com que buscássemos outra plataforma de desenvolvimento.

E, através de pesquisas de nosso artista, Gabriel Roque, chegamos ao Slick.

Slick: a segunda (e certeira) tentativa

SlickProva de conceito do jogo multiplayer no Slick.

Depois de uma breve prova de conceito para conhecermos os primeios passos com a plataforma, percebemos que Slick era claramente uma ferramenta poderosa. Rodando em Java sobre a biblioteca OpenGL LWJGL, o Slick é na prática muito similar ao XNA em termos de codificação, além de leve, multiplataforma e capaz de geração de gráficos 2D com excelente qualidade. E como a biblioteca possui diversos objetos de apoio, a programação se mostrou muito fácil e enxuta, permitindo a criação de códigos concisos e organizados.

E como tínhamos experiência de programação em Java, estávamos em terreno conhecido: poderíamos usar Sockets com facilidade e executar scripts Lua a partir da ótima bibiloteca LuaJava sem maiores temores.

A parte gráfica

BlenderBlender: o modelador oficial
do jogo Strings Fighter!

Nosso artista é especialista em Blender, então essa foi nossa ferramenta de modelagem de personagens/cenários/whatever principal. Além dele, foram utilizados o editor de gráficos vetoriais Inkscape para composição de sprites e o editor de imagens GIMP para tratamento final dos gráficos do projeto. De minha parte, usei muito o simplório PhotoFiltre para redimensionamentos e pequenos retoques nos sprites e outras imagens utilizadas no jogo.

Para aqueles que querem compreender melhor o projeto gráfico do game, ao final do artigo há uma apresentação do jogo em formato PDF que contém maiores detalhes.

Servidor multiplayer

Para armazenarmos estatísticas dos usuários e gerenciar as salas de jogo criadas, foi utilizado um web service ASP.Net com o ORM Yamapper atuando em banco de dados MySQL. Embora a quantidade de tabelas fosse pequena (apenas 5), o web service continha mais de 20 métodos para extração e manipulação desses dados.

Para facilitar a integração do web service com o jogo, utilizamos o conjunto de plugins do Eclipse Web Tools Plataform, o qual permitiu fácil geração das classes proxy e consequente simplficação do acesso ao web service a partir de métodos Java.

Arquitetura

A arquitetura do jogo foi baseada em cenas, as quais representavam cada uma das principais partes do jogo (seleção de idiomas, menu e jogo em si).

Para carregamento de tais cenas, foi criada uma classe principal que se encarregava de inicializar e gerenciar a cena que estivesse em execução, além de realizar a troca de cenas quando aplicado. Tal classe também continha diversas propriedades estáticas para armazenamento de informações compartilhadas por outras partes do jogo.

Hitbox CreatorHitbox Creator, ferramenta para criação de pontos de colisão.

O sistema de colisão, baseado em hitboxes (retângulos que indicam áreas de dano/ataque), foi algo que muito tirou o sono do time. Embora o conceito de se ter figuras geométricas representando os pontos de colisão soe simples e de fácil implementação, garantir que o jogo rode a 60 fps sem perda de quadros com todos os cálculos matemáticos ocorridos na luta consumiu muitas horas de planejamento e otimização. Além disso, criar todos esses pontos de colisão usando apenas coordenadas era uma tarefa no mínimo hérculea.

Para facilitar a criação das hitboxes, foi criada uma aplicação em C# que permitia a edição visual dos retângulos de colisão. A partir do carregamento de um script Lua de personagem e um sprite, a pequena aplicação permitia ao Game Designer projetar todos os pontos de colisão de forma visual, com cores distinguindo cada uma das diferentes hitboxes interpretadas pela engine, salvando todas as coordenadas no script Lua previamente selecionado. Tais facilidades contribuíram para a definição de pontos de colisão que garantissem o correto balanceamento entre danos e ataques dos personagens.

Porém, a grande dificuldade na elaboração da arquitetura não estava no carregamento ou manipulação de objetos ou mesmo no sistema de colisão, mas sim na execução on-line multijogador.

A primeira abordagem para troca de mensagens via sockets teria sido um sucesso total se não fossem os ocasionais problemas de sincronização decorridos da grande complexidade da arquitetura criada. Por conter muitas classes, a organização dos objetos gerava um emaranhado de ações que apenas complicavam o entendimento e manutenção dos processos multijogador.

Diagrama 1Versão 1 da Socket Processor Architecure, com toda a sua complexidade e problemas de sincronização.

Então, buscando eliminar os problemas de sincronização e para simplificar os objetos envolvidos na comunicação multijogador, uma segunda versão da arquitetura foi criada, a qual fazia com que todo o processamento de jogo fosse realizado apenas na máquina host, promovendo a máquina cliente a um básico interpretador de comandos. Tal abordagem garantiu que todas as ações dos jogadores fossem corretamente processadas e quaisquer problemas de sincronização eliminados, além de reduzir a quantidade de mensagens trocadas, aumentando por consequência o desempenho do jogo.

Diagrama 2Versão 2 da Socket Processor Architecure, muito mais simples.

Palavras finais

Entender exatamente qual é a experiência que se deseja trazer ao jogador foi algo que muito ajudou o time a focar não só em como a jogabilidade seria executada, mas também em como a tecnologia deveria ser aplicada.

A correta escolha das tecnologias, aliada à integração de ferramentas e à criação de aplicações de apoio garantiram que o jogo pudesse ser criado com a máxima qualidade possível dentro do prazo estipulado (3 meses).

Se fica uma lição disso tudo, é que planejar e prototipar são peças-chave para a criação de um bom game - além de muita paciência e dedicação, claro!

Arquivos

Comentários
Comentar
Campos marcados com * são obrigatórios. Seu e-mail não será exibido.
*
*
*
Captcha *
CATEGORIAS AO TOPO E ALÉM LUGARES PARA IR
Topo

“The more a cultivated reason gives itself over to the aim of enjoying life and happiness, the further the human being falls short of true contentment.” - Immanuel Kant