Um jogo simples, descomprometido e maroto para jogar enquanto se está na sala de espera da(o) dentista.
O projeto deve ser entregue como um Pull Request (veja [1] e [2]) neste repositório. Ou seja, você deve fazer um fork e, no branch cujo nome equivale ao ano e semestre atual, você deve criar os dois microjogos.
Siga os passos:
- Faça um fork deste repositório pela interface do GitHub.com.
- Clone o (seu) repositório forked para seu computador.
- Crie um branch cujo nome é o primeiro nome do(s) integrante(s) do grupo, sem letras maiúsculas e com hífen separando o(s) nome(s).
- Por exemplo,
git branch -b sandy-junior
.
- Trabalhe fazendo commits nesse branch
- Quando estiver pronto, faça um Pull Request do seu branch (e.g.,
leandro-leonardo
para o meu branchmaster
(do professor)
Veja alguns detalhes sobre a implementação do jogo a seguir.
O jogo possui algumas telas, como de splash (inicial), menu principal e
"de jogo", e o código referente a cada uma reside em uma classe que herda de
BaseScreen
.
As classes do projeto estão modularizadas nos seguintes pacotes:
br.cefetmg.games
: classes de inicialização e configuração geral do jogo.br.cefetmg.games.graphics
: classes com utilitários gráficos.br.cefetmg.games.logic.chooser
: classes de utilidade para a lógica de jogo.br.cefetmg.games.minigames
: classes referentes aos microgames.br.cefetmg.games.minigames.factories
: classes referentes às fábricas abstratas que são responsáveis por instanciar os microgames.br.cefetmg.games.minigames.util
: classes utilitárias aos microgames.br.cefetmg.games.screens
: classes referentes às telas do jogo.
Os assets (recursos gráficos e de áudio) do jogo ficam na pasta core/assets
:
Os assets de cada microgame devem estar dentro de uma pasta cujo nome é
o nome dele, sem maiúsculas e acentuação, com hífen separando as palavras, caso
haja mais de uma (e.g., assets/shoot-the-caries
).
Para os microgames, estamos usando um gerenciador de assets para pré-carregá-los de forma que, quando da execução da sequência de microgames, o jogo não pára para carregar os recursos e isso dá uma experiência de jogo melhor.
Para usar o gerenciador, cada microgame deve:
- Declarar de quais assets ele precisa, na classe
SuperMicroJogoFactory
. Por exemplo:
public class SuperMicroJogoFactory implements MiniGameFactory {
// ...
@Override
public Map<String, Class> getAssetsToPreload() {
return new HashMap<String, Class>() {
{
put("super-micro-jogo/personagem.png", Texture.class);
put("super-micro-jogo/tiro.wav", Sound.class);
}
};
}
}
- Solicitar os assets já carregados ao gerenciador, na classe do microgame propriamente dito. Por exemplo:
public class SuperMicroJogo extends MiniGame {
private final Texture texturaPersonagem;
private final Sound somTiro;
public SuperMicroJogo(BaseScreen screen,
GameStateObserver observer, float difficulty) {
super(screen, difficulty, 10000,
TimeoutBehavior.FAILS_WHEN_MINIGAME_ENDS, observer);
this.texturaPersonagem = screen.assets.get(
"super-micro-jogo/personagem.png", Texture.class);
this.somTiro = screen.assets.get(
"super-micro-jogo/tiro.wav", Sound.class);
// ...
}
// ...
}
- Usar os assets normalmente - para serem desenhados, tocados etc.
Nota: para ver como o pré-carregamento está sendo feito, procure na classe
GameSequencer
.
Como muito bem lembramos da queridíssima aula de Computação Gráfica, uma aplicação em OpenGL possui pelo menos 2 sistemas de coordenadas extremamente importantes:
- O sistema de coordenadas do mundo (arbitrário, definido por nós)
- O sistema de coordenadas da janela (definido em pixels)
Em jogos digitais, qual deve ser o comportamento quando um usuário redimensiona a janela? Há pelo menos 3 possibilidades:
- A imagem que estamos renderizando fica espichada ou achatada (não queremos isso)
- Mantemos a razão de aspecto (a imagem não distorce) e fazemos com que toda a imagem renderizada caiba dentro do espaço disponível
- Isso faz com que surjam barras laterais ou superioes-inferiores "em branco" quando a nova dimensão da janela tem uma razão de aspecto diferente daquela para a qual o jogo foi programado (veja a imagem a seguir)
- Mantemos a razão de aspecto e aumentamos o espaço do mundo que é visível ao jogador
É possível e bem simples fazer qualquer uma dessas formas na LibGDX. Optamos pela forma (2) porque ela permite que usemos valores virtuais para largura e altura da tela... como assim?
Podemos ver 3 constantes importantes em Config.java
:
public class Config {
/**
* A largura do mundo de jogo.
*
* Todos os objetos (sprites, etc.) devem estar contidos em coordenadas x
* que vão de 0 a WORLD_WIDTH para que apareçam na tela.
*/
public static final int WORLD_WIDTH = 1280;
/**
* A altura do mundo de jogo.
*
* Todos os objetos (sprites, etc.) devem estar contidos em coordenadas y
* que vão de 0 a WORLD_HEIGHT para que apareçam na tela.
*/
public static final int WORLD_HEIGHT = 720;
public static final float DESIRED_ASPECT_RATIO
= (float) WORLD_WIDTH / (float) WORLD_HEIGHT;
// ...
}
Repare na figura a seguir. Podendo considerar que o sistema de coordenadas do mundo é sempre x E [0,1280] e y E [0,720], fica fácil posicionar os elementos de forma que eles estarão aonde queremos independente da resolução atual da janela do jogo.
- Pergunta: Por que o código está em inglês?
- Resposta:
mania do professoras linguagens de programação e seus compiladores costumam ter problemas para identificar caracteres com acentuação nos códigos-fonte. Poderíamos escrever em Português sem usar a acentuação, porém se escrevermos em inglês, além de descartar essa possibilidade de problemas, tornamos o código-fonte acessível a leitores estrangeiros que saibam ler em Inglês.
- Pergunta: Fiz meu fork, mas o professor foi lá e fez mais commits... agora meu fork está desatualizado. Como faço para ressincronizá-lo do o do professor?
- Resposta: basta atualizar o branch master a partir do fork