Emotion

Descrição

Trata-se de um jogo protagonizado por um simples girino, representado através de formas geométricas que fazem lembrar uma minhoca, tal como no clássico jogo da Serpente. Este girino desloca-se segundo um fluxo de corrente de um rio. O “girino” viaja ao longo do rio usando a sua cauda para movimentar e transimitir emoções. As suas acções, ao longo da viagem, observadas pelo jogador são exercidas automaticamente pela personagem, consoante o seu nível de energia, que vai diminuindo à medida que encontra acidentes geológicos, ficando preso nestes, ou sendo capturado por um ou mais predadores.

É necessário, através da intensidade ou duração da voz do jogador, reforçar as acções da personagem para poder: 1) apanhar comida; 2) escapar de remoinhos; 3) desviar-se da trajectória do/s predador/es e 4) fugir da captura do predador.
Um factor característico, que torna original e creativo a ideia deste jogo é, não só a transmissão de emoções por parte da personagem, através do movimento da sua cauda, como também a passagem de emoções entre personagem-jogador. Ou seja, o estado de espírito de um jogador reflecte-se no sucesso ou insucesso das acções tomadas pela personagem. Um movimento mais ou menos ritmado, influencia o jogador a percepcionar perigos e a ajudar o girino.
Por último, uma vez que a ideia deste jogo foca a manipulação de som – conceito que não é bem explorada nos jogos de hoje em dia – a banda sonora do jogo foi construída de modo a reflectir as várias emoções presentes. Isto significa que quando existe um perigo por perto, o jogador é alertado através de uma intensidade maior na música do jogo.
Nota: Para correr o jogo é necessário abrir o ficheiro “Emotion.pde”, que se encontra na pasta Emotion.

Prototipagem

Elaborámos em detalhe o documento de Game Design, o qual seguimos ao pormenor.
Utilizámos o paint e papel e caneta para poder desenhar as várias situações de jogo, as suas personagens e acções-reacções possíveis.
Passando este conhecimento para a fase de desenvolvimento, torna-se bastante mais simples. Se for necessário qualquer alteração, basta seguir uma abordagem iterativa, na qual voltámos a revalidar o documento de Game Design. Se estivermos já numa fase de testes, basta alterar a partir do Game Design e passando para a fase de prototipagem e concepção.
O projecto foi dividido em vários módulos, como já enunciamos. Os módulos foram os seguintes: manipulação de som, ambiente gráfico, movimentação de personagem e restantes elementos, banda sonora.
Após elaborado o primeiro módulo, foi-nos possível revalidá-lo seguindo as guidelines do documento de Game Design, testando com as pessoas indicadas, conseguindo atingir com sucesso esta fase.
De notar que não foi necessário efectuar qualquer alteração ao Game Design, uma vez que o pouco desenvolvido coincidiu com o efeito desejado por parte dos testers e developers. Seria no entanto benéfico, efectuar várias fases de revalidação ao documento de Game Design, caso conseguíssemos desenvolver mais módulos, encontrando falhas ou pormenores a limar, consoante os vários testes falhados perante os testers e developers, bem como falhas detectadas previamente no acto de desenvolvimento dos vários módulos do projecto.

Resultados

Foi-nos possível retirar algumas conclusões face ao trabalho por nós elaborado. Apesar do insucesso no desenvolvimento do projecto, é-nos possível afirmar que esta cadeira foi bastante útil para compreender as várias fases e processos de desenvolvimento de projectos lúdicos deste género. Através das várias apresentações, conseguimos dividir as várias fases de desenvolvimento, tanto de jogos, como de software, que consistem nos seguintes tópicos: Concepção, Design, Prototipagem, Desenvolvimento, Testes e Manuais.
A fase que mantivemos maior contacto foi a fase de Concepção e Design. Iniciámos a fase de Prototipagem, contudo a margem de sucesso não foi a suficiente. Apesar disto, tal como já foi dito, ganhámos alguns conceitos e noções do desenvolvimento de um projecto em larga escala. Conseguimos detectar as maiores dificuldades, tendo noção das consequências futuras, não conseguindo, no entanto, antecipá-las de maneira eficaz. A demasiada sobrecarga proposta pelas várias cadeiras diferentes frequentadas pelos 4 elementos, não permitiram muito tempo para reuniões de grupo, ou mesmo desenvolvimento dos vários módulos, tendo sido estes distribuídos equilibradamente. Isto aconteceu, uma vez que a dificuldade do projecto foi de encontro à falta de experiência em iProcessing, juntando-se a falta de tempo para poder ganhar alguma flexibilidade nas várias bibliotecas e linguagem Objective C.
PS: Também resultou numa dor de garganta para os editores deste site.