Apresentação
O jogo que escolhi foi Gradius, pois tenho uma relação de amor e ódio com jogos do estilo shoot'em up e bullet hell. O jogo da empresa Konami foi lançado em 1989, em um período de auge de consoles como o NES da Nintendo e do nascimento de uma nova era de videogames portatéis, movida pelo Gameboy também da Nintendo. No nosso jogo, o jogador deve desviar de tiros de fogo e naves inimigas, atirar lasers e sobreviver a ondas crescentes desses inimigos. A seguir, vamos dissecá-lo em suas submecânicas para apresentá-las.
Submecânicas
Abaixo segue uma série de gifs apresentando visualmente todas as submecâniacas presentes no Gradius:
No GIF acima podemos observar diversas submecânicas:
- O jogador (nave a esquerda) se movimenta para cima e para baixo.
- As naves inimigas surgem a direita, se movendo para a esquerda.
- Pedaços de terra flutuantes (acima e abaixo) surgem nos cantos extremos direitos, se movendo para a esquerda e atirando bolas de fogo aleatoriamente no meio de seu movimento.
- O jogador pode atirar nos inimigos com lasers.
- Quando derrota um inimigo, ganha-se pontos
Acima temos as três formas do jogador perder uma vida em uma partida:
- Ao ser acertado por um Tiro de Fogo.
- Ao colidir com uma Nave Inimiga.
- Quando uma Nave Inimiga passa da tela, o jogador perde Force (que seria como a vida dele) e ao atingir zero, ele perde.
Quanto a telas, o jogo possúi quatro:
Uma tela vazia, o "desligado" do jogo.
A Tela de Espera, onde o jogador é apresentado a quantidade de vidas e o modo de jogo (que não foi trabalhado pois foi recomendado seguir apenas um modo).
A Tela de Jogo, onde o jogador interage com o ambiente.
A Tela de Game Over, após perder todas suas vidas. Pode recomeçar o jogo a partir daqui, voltando para a tela de Espera Inicial.
Além de tudo isso, o jogo possui dificuldade dinâmicas, com o passar do tempo na Tela de Jogo o movimento dos inimigos é acelerado gradualmente, também não possui fim, podendo ser jogado enquanto o jogador for capaz de sobreviver.
Modelo Natural
a. Jogador
- O Jogador pode estar em 5 posições: cima, meio-cima, meio, meio-baixo e baixo, sendo que as posições compostas a nave fica um pouco a frente das outras.
- O Jogador move a Nave apertando dois botões, um para cima e um para baixo.
- O Jogador pode atirar um laser em qualquer posição.
- O Jogador atira apertando um botão de tiro.
b. Naves Inimigas
- Pode aparecer em 5 posições, idênticas ao do jogador: cima, meio-cima, meio, meio-baixo e baixo.
- As Naves no meio-cima e meio-baixo começam um pouco antes no eixo horizontal.
- Elas se movem sempre para a esquerda, três vezes.
- Quando atingidas pelo laser do jogador, ela é destruída e perde uma vida.
- Se atingir o Jogador, ele é destruído.
- Se a nave atravessar a lateral esquerda, o Jogador perde um ponto de força e a nave desaparece.
c. Ilhas Voadoras
- Aparecem em duas posições, sempre no extremo superior direito ou extremo inferior direito.
- Se movem sempre para a esquerda, 4 vezes.
- Após se mover uma vez, a Ilha tem uma chance de atirar um Tiro de Fogo em direção a uma posição fixa, no eixo vertical da nave.
- Ao atingir a sua última posição, a Ilha desaparece no instante seguinte.
d. Tiro de Fogo
- Se move para cima quando atirado de baixo e para baixo quando atirado de cima.
- Se atingir o Jogador, ele perde uma vida.
e. Sistema
- Conforme o tempo de jogo passa, a velocidade de todos os inimigos aumenta.
- Cada inimigo destruído, a pontuação aumenta em 20.
- O jogador começa com três vidas, e ao perder todas ocorre o game over e a pontuação reseta.
Modelo Matemático
 |
| Desenhado na ferramenta gratuita https://vectr.com/, elipses pretas representam o Jogador, círculos dourados representam as Naves Inimigas, quadrados vermelhos representam as Ilhas Flutuantes, quadrados laranja representam os Tiros de Fogo e as linhas pretas representam os Lasers. |
A imagem acima apresenta todas as possíveis posições para cada objeto de jogo, além de indicar a proporção de nossa tela, que nesse caso será de 20x16. Como desejei trabalhar com módulo para tornar possível a livre alteração do tamanho da tela, foi importantíssimo fazer essa estruturação. Uma observação, neste modelo utilizei valores que variam a partir do 0, então quando citar a posição 3 do modelo, será considera como a 4ª posição visualmente. Vamos então a cada objeto:
a. Jogador
- Este poderá se movimentar para cima e para baixo no eixo Y a partir da posição 3, de 2 em 2 módulos, até o limite que será a posição 11.
- Quanto ao eixo X, o Jogador se encontrará na posição 1, com exceção de quando estiver no meio-cima e no meio-baixo, onde estará uma posição a frente, na 2.
- O tamanho da nave será de 2 módulos de largura e 1 módulo de altura.
b. Nave Inimiga
- Este poderá iniciar em 5 posições diferentes no eixo Y, todas relativas as possíveis posições do Jogador, ou seja, 3, 5, 7, 9 e 11. Já no eixo X, a nave inicia na posição 12, com exceção do meio-cima e meio-baixo, onde fica na posição 14.
- A Nave se move apenas horizontalmente, sempre 4 módulos a esquerda.
- Após se mover 2 vezes, a Nave desaparecerá no terceiro movimento, resultando em algumas possibilidades.
- Após realizar seu último movimento, se a posição no eixo Y for igual a do Jogador, ele é destruído e perde uma vida.
- Se atingir nada, reduzirá o nível de Force do Jogador em um ponto.
- Se a Nave se encontrar na mesma posição em que um laser é atirado, ela será destrúida e retirada do jogo.
- Ao ser destruída, o Score do Jogador subirá em 20 pontos.
c. Laser
- É atirado ao apertar o botão de tiro, e sempre aparece na mesma linha onde o Jogador está.
- Ao ser atirado o Jogador não poderá se mover durante um curto espaço de tempo.
- É desenhado de forma quebrada mas seguindo uma lógica, será desenhado uma linha de 1 módulo de largura, 0.5 módulo abaixo da posição no eixo Y do Jogador e na posição 3 no eixo X. Uma segunda linha de 3 módulos de largura será desenhada na mesma posição Y mas na posição 5 em X. Outra linha de mesmo tamanho será desenhada na posição 9 e outra será desenhada na posição 13. Mas novamente temos a exceção do meio-cima e meio-baixo, onde todas as posições no eixo X devem ser movidas 2 módulos para a direita.
- O laser é calculado meticulosamente para não sobrepor nenhum objeto, como no jogo original.
d. Ilhas Flutuantes
- Estas começam sempre em duas posições, 17 no eixo X em cima ou embaixo, e na posição 0 ou 14 no eixo Y.
- Novas Ilhas aparecem sempre em locais alternados, uma embaixo, depois em cima, depois embaixo, e assim por diante.
- Se movem sempre para a esquerda, 4 módulos por vez. Após se moverem 4 vezes, elas desaparecem.
- Após se mover uma vez, na posição 13 do eixo X, há uma chance de um canhão preso nessa ilha atirar um Tiro de Fogo.
e. Tiro de Fogo
- Gerado inicialmente na posição 13 do eixo X, e na posição 2 do eixo Y quando atirado de cima ou na posição 12 quando atirado por baixo.
- Se move sempre para a esquerda, 3 módulos por vez, e se move 2 módulos para baixo se atirado de cima e 2 módulos para cima se atirado de baixo.
- Desapece após se mover 3 vezes.
- Se após o terceiro movimento o jogador se encontrar na posição 5 e uma bola de fogo vier por baixo, ou na posição 9 e uma bola de fogo vier por cima, o Jogador é destruído e perde uma vida.
f. Sistema
- Com o passar do tempo, o jogo vai ficando mais rápido, com todos os inimigos atualizando mais rapidamente.
- Se o Jogador zerar sua barra de Force, ele é destruído e perde uma vida.
- O jogador começa com 3 vidas, e ao perder as três, ele perde o jogo e seu Score é zerado.
- A quantidade de pontos de Force é mostrada em uma barra fragmentada no topo esquerdo da tela.
- O Score é mostrado na parte inferior esquerda da tela durante a tela de Jogo e a tela de Game Over, no mesmo local também é mostrada a quantidade de vidas, mas apenas durante a tela de Espera.
Modelo Computacional
Para produzir meu port, decidi utilizar a ferramenta Processing com os seguintes pontos a se refletir:
- É a ferramenta mais utilizada nas aulas de MAM1 e também será utilizada para realizar a prova.
- Apesar da facilidade de organização e produção de um projeto em ferramentas especializadas em produção de jogos, muitas destas são facilidade pré-programadas que de certa forma podem levar o desenvolvedor a relaxar e a depender da ferramenta, coisa que o Processing não permite.
- Muitas das funções de ferramentas de produção de jogos já vem pré-codificadas e boa parte da codificação acaba ficando por trás dos panos, deixando o desenvolvedor um pouco distante daquilo que ele está fazendo, utilizando o Processing boa parte das funções devem ser feitas a mão e o esforço de produção é maior e mais controlado.
Lendo isso parece estupidez minha escolher a ferramenta mais difícil, mas como o ambiente da universidade é um ambiente de aprendizado e, como programador, tenho noção de que a escolha de uma linguagem ou ferramenta depende daquilo que se deseja produzir. Como não havia a necessidade de produzir um projeto grande, o Processing me pareceu o suficiente para meu projeto.
Todo o código está no link abaixo, e, apesar de estar completamente funcional, tem diversas coisas que adoraria ter tido mais tempo de organizar, além de ter desejado me utilizar mais de POO, porém ainda não tivemos aulas sobre o assunto e não tive tempo de estudar por fora. Contudo, o processo de produção desse trabalho foi muito divertido, apesar da quantidade massiva de tarefas que disputavam com meu tempo de produção do projeto ter me deixado fadigado muitas vezes.
Link para o código: Trabalho MAM1.
