Alpha Release Chapter

shot06.png

Particle System

One of our main focuses for the alpha release was to create sophisticated particle system. We first used the DPFS particle framework wich we found in the internet, but it was full of bugs and was very slow, it dropped the frames per second to much. So we decided to implement our own system, with a good architecture, so that afterwards we can create new particle effects in just a few minutes.

Our sophisticated particle system is able to change the size, transparency, color, position, velocity and rotation for every particle individually. Therefore we wrote a special shader, wich handles most of these attributes, so that as many as possible calculations are done on the GPU. Even that every particle is facing the camera is done on the GPU. Since we made an well architected abstract class, new particle effects can be created in a few minutes.

There are more particle effects to come. For the alpha release, we have two different particle effects for the white and the black magic ball. Plus we created another one to visualize a nice rain.

shot02.png

shot03.png

Bloom Shader

We created a bloom shader to give our game a unique look. It is able to bloom the game, wich gives the feeling that bright thnigs do shine and dazzle the player. Plus it is able to blur the image with a gaussian filter. To keep a long story short, our bloom shader has a lot of parameters to play with, so we can create many different ambients.

We advanced our bloom shader to pass over smoothly between the different parameters. Now it changes automatically from time to time it's parameters, wich gives the feeling of a real, living, changing world. For example at one time, the world becomes pretty dark and blurry and it starts to rain, wich gives a very realistic, atmospheric feeling of a bad weather.

shot01.png

shot04.png

Sounds

Next step was to create more sophisticted sounds. Because we have a lot of enemys in the level, wich emmit many sounds, it was extremely important to have 3D sound effects, so that the player can't hear the sounds of an enemy far away.

Therefore we used the "Microsoft Cross-Platform Audio Creation Tool XACT3". The listener of the sounds is always placed at the cameras position and the emitter is placed at the exact position of where the sound rings out, wich gives a real 3D feeling of the audio in the world. We adjusted the fall off curve of the volume to the distance of the emited sound in XACT very precisely to create a realistic feeling.

Since it was very time consuming to find appropriate sounds on the internet and sometimes even impossible, we were even running around with a microphone to record our own sound samples.

Next, we added some music, wich we have carefully choosen to match the ambient of the game. The music was composed by one of our team members.

Level Importer

The level importer has been improve to import a level file containing:
  • the position of the physical map (ground, wall, plateforms, etc..)
  • the initial positions of Llams and Egral
  • the initial positions of the enemies, as well as their "areas" which define their freedom in the world
  • the positions of the crystals, and the gate.

The level is just an *.obj file which is parsed and interpreted, where the (x,y) coordinate represents the real coordinates in the game, and the z-coordinate give some meta-information about the polygon (is it Llams, an enemy, which area is associated with with enemy, etc.)

levelImporter1.jpg

To help design the levels, a base file has been created, containing one instance of each object, with the good z-information, so that we only have to copy-paste this. In addition, based on playing the game, an approximate trajectory for the jump of Llams, Egral, and Llams being onto Egral has been created.

This trajectory is very useful to design the level.

levelImporter2.jpg

Physics

The parameters of the physics have been modified little by little in order to provide a gameplay as cool as possible, and having a specific behaviour for Llams, Egral and the enemies. Information about the forces implied in collisions are handled to decide the current state of a character (is he falling, sliding, waiting, etc...), useful to know if it is possible to jump or not, etc...

In addition, a system handling collision information and object data has been implemented to decide if we have to ignore a collision or not (especially useful for magical balls)

AI

A simple AI has been implemented for the enemies, based on their "allowed area", the distance between the enemy and the characters, and some random behaviour, controling orientation, attack rate, jumps, etc. The aim was to have a general fun behaviour, to get a cool feeling from the game, than to have a very smart and realistic AI. (And stupid actions are fun). The balancing can always be made with a higher attack rate than characters, etc... and so have challenging enemies even if they are stupid.

Logic and balancing

balancing.jpg

In order to have a game challenging but not frustrating, some design decisions on the game interactions has been made. At the time being, there is only two enemies, one magical and the other physical.

First decision: - only Egral can defeat Physical Enemy - only Llams can defeat Magical Enemy

consequences: it's really important to keep both characters alive, unless you will really have difficulties later if impossible to complete the level. This is meant to keep the major idea of the game: always playing with the two characters, and having to switch often.

Second decision: - both enemy can defeat both characters

consequences: if there is an enemy protecting some place, you really need to kill him, and not use the adapted character to go there without fighting. This again forces you to use the two characters: using the one that has the power adapted to kill the enemy, then the one that has the size/jump adapted to continue in this place

Third decision: because of the previous rules, if egral/llams/enemies have the same attack power, the game is unfair/unbalanced (enemies too powerful): - Egral should have an advantage against Physical Enemy - Llams should have an advantage against Magical Enemies

The advantage chosen is to use the white attack: - for egral: you can protect yourself from physical attack with the axe. - for llams: you can use a white magical ball to destroy a black magical ball of an enemy.

Then, with these basic rules coming naturally to fit the idea of the game, the parameters as number of lifes of enemies, speed, attack rate, etc... are modified to balanced the game.

Character animations

Llams and Egral have been designed, modeled, and the UVs created, with a still simple texture applied. Simple enemies have also been created for test purpose. The first animations have been created within Maya, and imported in XNA with the Merge Animation Pipeline. Nevertheless, there is a "bug" in the importer, and all the animation should have the first frame in the binding pose (the importer use this first frame as the binding pose... and so another pose will generate undesired deformations).

egral_twiki.jpg

llams_twiki.jpg

physical_twiki.jpg

flyingEnemy_twiki.jpg

Then, the AnimationPlayer class has been modified in order not to take into account the first frame, and in Maya, after having a cool animation, we just add at the beginning a new frame with the character in the bind pose.

It's still needed to work on an animation for the jump, and to have a consistent walking/running animation depending on the speed of the character, to keep the feet fixed on the ground
I Attachment History Action Size Date Who Comment
JPEGjpg balancing.jpg r1 manage 23.9 K 2011-05-09 - 17:06 BorisDalstein  
JPEGjpg egral_twiki.jpg r1 manage 77.3 K 2011-05-09 - 17:10 BorisDalstein  
JPEGjpg flyingEnemy_twiki.jpg r1 manage 58.8 K 2011-05-09 - 17:11 BorisDalstein  
JPEGjpg levelImporter1.jpg r1 manage 87.3 K 2011-05-09 - 17:07 BorisDalstein  
JPEGjpg levelImporter2.jpg r1 manage 68.7 K 2011-05-09 - 17:07 BorisDalstein  
JPEGjpg llams_twiki.jpg r1 manage 30.7 K 2011-05-09 - 17:10 BorisDalstein  
JPEGjpg physical_twiki.jpg r1 manage 25.8 K 2011-05-09 - 17:11 BorisDalstein  
PNGpng shot01.png r1 manage 383.5 K 2011-05-09 - 16:21 MarcoFelixJenny  
PNGpng shot02.png r1 manage 39.6 K 2011-05-09 - 16:28 MarcoFelixJenny  
PNGpng shot03.png r1 manage 21.3 K 2011-05-09 - 16:31 MarcoFelixJenny  
PNGpng shot04.png r1 manage 647.4 K 2011-05-09 - 16:35 MarcoFelixJenny  
PNGpng shot05.png r1 manage 150.2 K 2011-05-09 - 16:47 MarcoFelixJenny  
PNGpng shot06.png r1 manage 189.1 K 2011-05-09 - 16:54 MarcoFelixJenny  

Page URL: https://twiki.graphics.ethz.ch/bin/view/GameClass/TeamRaMBoAlpha
2024-04-19
© 2024 Eidgenössische Technische Hochschule Zürich