[6 - Personagens]

Conheça algumas das características dos personagens em Beat'em Bots. Nas próximas postagens um pouco mais sobre seus Backgrounds. Jogue e confira!

[5 - Concluindo]

Depois de mais ou menos 1 ano de muito trabalho e dedicação, é com muito orgulho que apresentamos a segunda etapa do Beat'em Bots. Inclusive já temos o jogo para baixar na sessão de downloads.

Quero agradecer aos novos colegas que entraram nesse semestre para nos ajudar a concluir esse grande trabalho, Gabrielly Gomes e Tomás Campos, e também a pareceria desde o início do projeto de Harrison Dias, e por último e não menos importante a mim o "poster guy" dessa postagem, Thiago Gonçalves ;)

Joguem e comentem! 

[4 - Regiões Inteligentes]

É claro que vocês perceberam (Perceberam, certo?) que deixamos de fazer alguns posts. Eram as semanas finais para a primeira entrega (dia 13/05) então focamos no projeto e ficamos sem tempo de atualizar o blog. Parando com a enrolação e indo ao que interessa.

Como descrito no post anterior os inimigos serão gerenciados por uma IAManager, ela determina quantos inimigos podem interagir com o jogador, evitando que todos os inimigos ataquem o jogador ao mesmo tempo, por exemplo. Depois de bastante tempo quebrando a cabeça, conseguimos implementa-lá, e não é que o trem ficou legal. Dá uma olhada em um teste que fizemos:

No jogo cada fase pode ser dividida em várias regiões, existem três tipos de regiões, são elas: Free, Spawner e Checkpoint.

• Free: Na região Free o personagem possuí movimentação livre e a câmera o segue.
• Spawner: Na região Spawner é onde o personagem irá enfrentar os inimigos, podendo movimentar-se apenas dentro da região, a câmera fica travada em um ponto específico, e o personagem só consegue sair da região quando derrotar todos os inimigos.
• Checkpoint: A região Checkpoint possuí as mesmas características da região Free, porém sempre que o personagem entrar nela, o jogo será salvo, caso o jogador morrer ele voltará na última região com Checkpoint.

Divisão das regiões de uma das fases do jogo.

[3 - Itens dos Eventos de Estado]

Quando começamos a desenvolver o jogo, pensamos em criar uma classe genérica para todos os personagens - jogador, inimigos, chefes. Para isso resolvemos criar a classe Character que é uma espécie de controlador, que define qual ação o personagem deve executar. Porém se colocássemos todas essas ações dentro da classe em si, ficaria difícil obter um novo comportamento e a classe ficaria gigante, para facilitar deixamos todos os comportamentos (Andar, atacar por exemplo) em classes separadas.
No C# existe um recurso (muito bonito e complicado de aprender no início) chamado event, que é uma espécie de "apontador de métodos".
Métodos de classes externas "assinam" esse evento e toda vez que o evento for chamado, automaticamente é chamado todos os métodos assinados do evento em questão.
Com isso, o controlador (Character) apenas "chama" esses eventos, e não é responsável pela implementação dos comportamentos, as classes que assinarem esses eventos ficam responsáveis pela implementação e execução, deixando o controlador independente das ações e mais fácil adicionar qualquer novo comportamento para o personagem.

Diagrama de Classe do Character e de seus comportamentos.

No jogo, haverá 3 tipos de inimigos (serão descritos em outra postagem) com comportamentos distintos, todos os inimigos serão gerenciados por uma IAManager, que irá validar suas ações, para que todos não ataquem ao mesmo tempo, por exemplo.
Montamos uma sequência de comportamentos genéricos, que servem para a maioria dos inimigos, segue a descrição de cada estado:

• EnemyWaiting: Aqui os inimigos apenas fazem a animação de espera, e o estado será trocado para EnemyApproaching quando o alvo estiver em sua área de alcance.
• EnemyApproaching: O inimigo irá se aproximar do alvo em questão, apenas se permanecer em sua área de alcance, e quando chegar perto suficiente para executar um ataque seu estado é trocado para EnemyAttacking.
• EnemyAttacking: O inimigo executa seu ataque, removendo uma quantidade de Saúde do alvo. Acabando a animação, o inimigo passa para o estado de EnemyAttackWait.
• EnemyAttackWait: Diferentemente do estado EnemyWaiting, este estado é ativado após o ataque do inimigo, e espera um intervalo de tempo para verificar se poderá atacar novamente, se recebeu ataque ou se o alvo saiu de seu alcance, podendo assim passar para 3 diferentes estados.
• EnemyTakeDamage: Estado sentinela que pode ser ativado quando recebe ataque de outro personagem, estando em qualquer outro estado que não possua o atributo de invulnerabilidade.
• EnemyDying: Se a vida do inimigo, for menor ou igual a zero, o estado muda para EnemyDying, executando a respectiva animação, e depois será destruído da cena.

Diagrama de Transição de Estados para o Inimigo Genérico.

Após toda essa descrição teórica de como estamos implementando os personagens no jogo você deve estar pensando:

- MEU DEUS QUE POST MAIS CHATO NÃO TEM NADA DE INTERESSANTE AQUI!!

Calma, para deixar o post mais leve, bonito e agradável vamos atualizar aquela imagem com os itens de cenário da postagem anterior.

[2 - Documentando com RKTR]

Essa semana nós nos dedicamos a pesquisar várias referencias para a criação do conceito do jogo, preenchendo o GDD (Game Design Document) e TDD (Technical Design Document). Esses são necessários para a centralização das informações obtidas nas pesquisas de imersão e são necessários para a matéria de acompanhamento do TCC - Projeto Aplicado em Jogos I.

Basicamente no GDD você descreve qual é o conceito do jogo - história, personagens, level design, gameplay, arte, controles, interface - e o que você achar necessário. Já no TDD você deve descrever a parte técnica do jogo (Oh Rly?), qual Game Engine será usada, qual linguagem de programação, padrões de projeto, diagramas UML, fluxo de testes, esses assuntos que ninguém dá valor mas quando bem detalhado faz diferença no decorrer do projeto.

- "Mas vocês não tem nada pra mostrar?"

Calma, começamos também a fazer alguns modelos, dentre eles o do personagem principal.

Androide de função operacional para fins de construção civil. Possui lataria desgastada pelo árduo trabalho. Possui uma serra na mão direita a qual usa para cortar metais e outros materiais e na mão esquerda uma máquina de solda. Apesar de realizar funções apenas para construção civil, RKTR, seu código de identificação, tem estrutura bem forte, o que em fins poderia se defender muito bem em uma luta.

E modelamos também alguns itens de cenário, para mostrar esses itens vamos ir juntando todos em uma só imagem e depois, quando já tivermos cenários realmente montados colocamos as screens deles aqui. Então esses são os itens que já produzimos.

[1 - O Primeiro de Vários]

Beat'em Bots é um jogo do gênero Beat'em Up, onde você assume o controle de um androide que busca por respostas para garantir sua sobrevivência. O jogo está sendo desenvolvido como Trabalho de Conclusão de Curso, do Curso de Graduação Tecnológica em Jogos Digitais da PUC Minas - São Gabriel.

Criamos o blog com o intuito de mostrar o desenvolvimento do Beat'em Bots, a ideia é fazer publicações semanais mostrando tudo - ou quase tudo - que foi criado durante aquela semana.

Vamos começar mostrando qual é o Background da história desenvolvida para o jogo.

Pesquisa e Background:

Na cidade distópica de DroidTown máquinas inteligentes são usadas para qualquer tipo de trabalho que os humanos consideravam intolerável. Com o avanço da tecnologia, trabalhadores humanos foram substituídos por máquinas, que inclusive tem a capacidade avançada de raciocínio. Todos os androides possuem um algoritmo evolucionário de aprendizado chamado Darwin, criado pela fundação Fundecta que através dos anos permitiu a máquinas uma capacidade muito abrangente de aprendizado para a tomada de suas decisões.

A fundação para desenvolvimento de tecnologias (FUNDECTA) tem crescido desde meados do primeiro século do ano 2000. Possui um campo bem abrangente de atuação como robótica e é responsável pela maioria das máquinas existentes e também por segurança pública.

Todas as máquinas são conectadas via wireless com um Backbone (servidor que interliga os comandos de máquinas periféricas a um comando superior, chamado de comando Ether). Caso esse dispositivo wireless pare de funcionar, a máquina entra imediatamente em estado de hibernação, não executando nenhuma ação, e então deve ser levada imediatamente para a manutenção.

Em um dia repentinamente foi anunciado uma manutenção geral em todos os Backbones. O que significa que nenhum robô funcionaria durante 1 hora, todos entrariam em estado de hibernação.

Por um fato desconhecido (fato este que somente será revelado no clímax do jogo) em uma fábrica em DroidTown, o dispositivo wireless do androide R-K-TR ou simplesmente chamado de R-K (e de outros robôs) para de funcionar, porém ele não entra em estado de hibernação.

Ninguém repara que isso aconteceu, pois R-K continua fazendo suas ações como sempre, ele só percebe que está conseguindo tomar decisões e executar ações mais rápidas e fluidas.

Quando a manutenção dos Backbones é concluída, todos os androides saem do estado de hibernação e percebem que R-K estava trabalhando e não tinha hibernado.

O Backbone responsável recebendo essa informação envia informação para todos os androides avisando que R-K e outros robôs estão com defeito e precisam de manutenção a qualquer custo, pois sem ela os robôs podem ter comportamento de risco para a sociedade.