Arquitetura

Arquitetura

Utilizaremos o padrão de arquitetura Entity-component-system (ECS).

Entities

Representam um elemento do jogo. São containers de componentes.

Iremos utilizar Entities para representar:

• Character

• Bomb

• Hard/Soft Blocks

• Monster

• Powerup

Note	Entidades não possuem classes próprias, as entidades serão diferenciadas pelos componentes associados. Uma entidade concretamente é apenas um ID.

Components

Os dados de um aspecto de um elemento que interage com o mundo do jogo. São os TAD (tipos abstratos de dados dos Systems) Os components são apenas dados, eles não contém a lógica do jogo. Components são tão pequenos quanto possível, representando apenas um aspecto específico.

Exemplos Components possíveis no Bomberman :

• CellPlacement (para regras do jogo, posição no Grid)

• ScreenPlacement (para renderização, posição e orientação)

• ExplosionBarrier (como interfere no caminho de uma explosão )

• Movable (como a entidade se move no grid)

• Explosion

• Score

• BombDropper

• Health (quantas vidas)

• Powerup

• Timer

Events:

Representar a ocorrência de uma situação no jogo. São uma forma de comunicação entre os systems. Events possuem apenas dados. Events são implementados como classes Java que possuem apenas seja atributos e métodos getters e setters.

Exemplo de Eventos são:

CollisionEvent

Uma entidade tenta ocupar uma celula já ocupada por outra entidade

TriggeredBombEvent

Uma Bomb foi disparada e está pronta para iniciar uma explosão

Existe um único system que cria eventos de um determinado tipo mas vários systems podem tratar eventos criados por outros systems. Events não possuem regras do jogo.

Note	Events são implementados como classes Java. Events devem estender a classe Event. Events possuem apenas dados ou seja atributos e métodos getters e setters.

Systems (ou Controllers):

Os systems implementas as regras do jogo. São nos systems que o código (algorítmos) são implementados. Enquanto Components e Events são os dados que constituem o modelo do jogo. Os systems são a implementação das regras.

Os systems são chamados a cada turno.

Cada component e event reune dados de um aspecto do jogo. Um system reune as regras de um aspecto do jogo.

Os systems cumprem suas responsabilidades criando novos components, atualizando dados nos components já existentes, consumindo events e criando novos events.

Existem systems que são responsáveis pela entrada de dados (Ex: PlayerControl), systems responsáveis pela Simulação do jogo, ou seja, onde são implementadas as lógicas de movimento, colisão e vida dos personagens (Ex: CollisionSystem, MovementSystem, LifeSystem) e systems responsáveis por apresentar os dados ao jogador (SoundSystem, RenderSystem).

Entity Manager

O EntityManager é responsável por manter o modelo do jogo. Ele armazena e permite os Systems acessarem os Components e Events presentes no jogo atual.

Tip	O EntityManager deve ser chamado apenas por Systems (não por Events ou Components)

Diretivas da Arquitetura

• Systems não chamam uns aos outros

• Systems se comunicam criando e consumindo Events e modificando Components.

Diretivas para Escrever Testes

O que testar

• Os testes devem verificar se os Systems cumprem suas responsabilidades.

• Quando estiver pensando em que testes criar, pense em que situações o sistema poderia falhar? Que tipo de cenários poderiam apresentar bugs?

Testes típicos

• testar o tratamento dos eventos que o System deve tratar

• testar a criação dos eventos que o System deve criar

• testar as modificações que o System deve fazer em componentes