Parasite Paradise

Links to subtopics

Game Controls

Table of contents

Summary Technical Issues Assessment Details Deliverables Project status Project critiques Attachments

Summary

The idea of this game is inspired by the PS2 game ‘Shadow of the Colossus’ where the player has to defeat colossal enemies by climbing onto them and stabbing their weak points with a dagger. The game level is not a mere static landscape anymore, but a moving creature with new challenges to the player.

Shadow of the Colossus

‘Parasite Paradise’, however, steps further into megalomania: The player controls a louse which crawls over the body of a huge moving fantasy creature. Each game level consists of one such victim. The louse starts off at a lower body part, a foot for example, and has to head for the upper parts. The goal is to reach the victim’s weak points where the louse can suck blood from until they have run dry. A victim will eventually fall unconscious from blood loss. Before the louse can move on to the next level, it takes advantage of its victim’s knock-out and lays some eggs. Until the breed has hatched, the louse has to protect them against a vicious hungry bug in an end boss fight. Finally, the player gains score points depending on the number of eggs hatched safely. On its way to the top, the louse has to master some difficulties: It has to fight competing parasites by throwing eggs at them or making use of its claws like swords. When the player louse is attacked and injured itself, it weakens and eventually falls off the victim, which means that the level has to be started again from the beginning. When the louse sucks blood from a weak point, its energy is restored.

Sucking blood from a weak point

Defending your breed

The louse has also the ability to jump, which has to be timed with care, however. Since it is sitting on a moving creature, a miscalculated jump can lead to a fall to the ground and a return to the level start. It is also not a good idea to jump when the louse is in an upside down position. As long as the louse is in contact with the creature surface, there is no danger of falling off. Additionally, the louse has to beware of anti-lice shampoo floodings. The player has to anticipate the flow of the liquid and avoid it as it weakens the louse and could wash it off the creature’s body. To make a different challenge of each game level, they contain special scenarios or tasks. For example, the victim could fly through the sky or dive under water which makes jumping impossible. Or the player louse has to win a race against a horde of enemy parasites and reach a blood-sucking spot faster. Eggs of vicious bugs could be hidden all over the level and have to be spotted and destroyed. The victim creature might also try actively to get rid of the louse by scratching itself, rolling on the ground or shaking itself.

top

Technical Issues

• Rendering of viscous liquid using smoothed particle hydrodynamics (Papers: 1 2 3)
• Rendering hair by representing each strand as a B-spline for close hair and approximating it by sampling particles or sparse hair guides for distant hair (Papers: 1 2 3)
• Under water effects
• Rendering cloth for the level design
• Moving an object on another (the louse on the monster)
• Collision dectection
• Animate models
• Physics (move and jump)

top

Assessment

The main point of “Parasite Paradise” is the fact, that the level is moving. In contrast to a static landscape, the player is challenged by estimating the right time to jump depending on the movement of the ground he is standing on at the moment.

The game contains action, as the player has to defeat enemy parasites by throwing eggs at them. There are also adventure elements since the player has to search the creature for weak points he can suck blood from. Furthermore he has to complete tasks such as collecting hidden eggs or winning a race against other parasites.

Crawling over a huge body which is inhabited by a whole civilisation of parasites should give the player the chills and a unique game experience.

top

Details

Graphical representation

We do not aim for providing a realistic and convincing e.g. human body as level. Rather we want to have fantasy creatures that are represented in much simpler comic styles. Therefore we can more easily adapt the models to make a good game terrain and fit in complexity to our time constraints.

(Camera-) Movement and Animation

Movement and Animation is probably one of the more time consuming part of our game. Only the background is static. All other parts of the game - especially the level and the louse - are in motion.

Level Background

This is simply a texture on a hemisphere, for example with a sky, some clouds and some mountains or of course something more special ... if anybody is more creative than I am

Level Animation

Each level has some predefined movement. The monster is not moving from one point to another. It will be at the origin and stay there from the start until it is dead. But still it is moving, for example it can move an arm, turn the head, lift his leg and so on. All these movements are basically predefined animations created in a 3D studio, like for example Maya. An important thing is that the movements during the game are not just randomly played. Sucking blood on a certain spot could for example trigger a movement of the level.

Louse Animation

The louse Animation is not so critical. In the first step it is important that the player sees that the louse is moving at all. One simple animation of the legs should fulfill that. In a more sophisticated version more details can be introduced, like for example a special animation for jumping.

Camera Movement

Not only the Level and the Louse and the Level are moving. Having a static camera could make the louse disappear 'behind' the monster. That's why it is important that the camera follows the louse in some way, because it is essential for the game-play. Since the monster does not move away from the origin we could imagine the camera moving on or within a single hemisphere, always a certain distance away from the louse. As long as the louse is visible from some point on the hemisphere this would not be so complicated. If this is not possible - because the louse is for example 'behind' the left arm of the monster - the camera has to be placed somewhere in this hemisphere. All this transitions need to be smooth, so that we do not confuse the player by a camera that is 'jumping' around all the time.

We think that it's best to follow a stepwise approach to solve this problem. First, the camera is static. This is not so bad at the beginning, because it still allows us to move the louse on the level. And since moving the louse on the level is one the very first targets a static camera is sufficient in the first step. In the second approach we can move the camera on the hemisphere. This gives us the freedom to follow the louse 360 degrees around the level. In the last step we should be able to follow the louse all over the level. However it could be part of the level not to see the louse on some very places. It's then the challenge for the player to move the louse to the visible part again.

Game stats overlay

We also want to add simple 2D sprite overlays displaying game stats to help the player. In the following we will refer to them as HUD (Head Up Display). Besides standard properties like health we also think about an artificial horizon like those used in aircraft altimeters: This should give the player a simplified indication whether it is a good idea to not jump right at the moment as the character hangs head first.

Our current HUD prototype occupies the upper left and right corner of the game view. The design idea is that the left part indicates general physical facts important for movement while the part to the right displays gameplay relevant details.

The left HUD shows an artificial horizon giving a simplified impression of the fleas roll (in flight navigational sense) and therefore indicates "how headfirst" it is. Around the artificial horizon an anemoscope or weather vane is drawn also restricted to the plane where the roll of the flea happens. Together they give a quick overview of the current situation when it comes to judging whether or not it is a good idea to jump right now.

The right HUD shows both the fleas and the level monsters health status as diminishing curved bars. The health bars surround a simple "radar view" giving a 2D impression of the distance to the nearest opponents which are shown as blobs. The middle of this radar views circle is the fleas position in the displayed plane.

no problem	sudden fall	might work

Jumping

When the player initiates a jump he can choose the direction of the trajectory by pressing the thumbstick in the desired direction. While in air there is the danger that the flea will fall down e.g. since the body part the player aimed to jump at meanwhile has moved away or when the flea hangs headfirst from the body. As the danger of falling down could prove frustrating we are thinking about giving player more help when jumping if playtesting suggests it. For example the player could get a second chance when he performs a certain control in a short time interval after the fall occurs.

Fighting

There are currently two ways we envision the flea to fight its opponents: On the one hand it can throw eggs on them. We are not yet completely sure how the player will control the egg throwing such that it is feasible and effective: The candidates we are planning to test are straight expulsion in the fleas heading direction, auto-aiming with switchable targets and thumbstick controlled direction. The second fighting style is direct melee fighting where the flea has to move close to its opponent to be able to hit. Simultaneously it will also be more endangered of getting hit itself.

XBOX Controls

• Left Stick: To move the louse the left stick is used. The louse can move forward and backward. When it is moving, it can be turned left or right using the stick.
• A: Jump
• B: Shoot
• Left Bumper: Suck blood
• ... to be continued ...

PC Controls

• W/S/A/D: The louse can move forward (W) and backward (S). When it is moving, it can be turned left (A) and rigtht (D)
• Space: Jump
• ALT: Shoot
• Q: Suck blood
• ... to be continued (and may be changed)...

top

Deliverables

Part 1: Project Proposal

Assignment 1 - Project Proposal Draft

Part 2: Design Specification

See above

Part 3: Interim Report

Progress

Up until now, we have completed the tasks to reach our functional minimum and worked through part of the low target. In detail, the finished tasks are the following:

• The basic class architecture has been determined.
• Modelling : A flea model has been done in Maya and completed with a walking animation. To load the animation from the fbx file, the skinning sample from the XNA creators website has been integrated. A basic skybox has been modelled.
• HUD: We have created 2D graphics for the orientation and health display HUD and integrated them into our first prototype.
• Game Controls: We've implemented a mapping from keyboard and Xbox controller input to a set of commands. The flea is steerable on the plane.
• Camera: We've integrated the camera control sample HMEngine from here. The camera can now be moved around freely and follow the flea (but the latter sometimes still fails) .
• Easter eggs to trigger level location based events have been introduced (e.g. blood sucking spots).
• The framework for sucking blood and throwing eggs has been implemented.

Difficulties

While working on the different tasks, we encountered several new problems which we will have to address in the following:

• We spent a lot of time on figuring out how to import an animated model from Maya into XNA. Our first approach was to convert the fbx file into an x file and use a very convenient animation library from the web, but ran into a cul-de-sac with this. Then we decided to use the skinning sample as mentioned above. This means however, that we will have to implement the animation controls and do the shading using an fx file. The skinning sample only plays the whole animation in a loop and doesn't import shaders.
• The camera HMEngine turned out to be incorrect in some parts. The slerping functionality does not work and has to be fixed.
• Unfortunately, one of our group members left us and we had to reschedule the project task breakdown and timeline.

Current work

Our next important step planned is the collision detection which will take up a major part of the following development time. We will first implement a brute force collision detection with a static model. For an optimization, our idea is then to build a hierarchy over the bones of the level model. Finally, we will adapt the implementation to an animated level model. Collision detection also involves throwing eggs at enemy parasites which can be solved simply using bounding spheres. Furthermore, we are working on Maya models for the enemy parasites and the first level. Since we are planning to do cell shading later on, we don't pay attention to the general look of the game for the time being. We also are fixing the problems as listed above with a focus on the animation controls. Finally, we have to extend the flea movement by the ability to jump. This also involves adding a corresponding animation.

Screenshots

The flea model imported with the XNA model processor (left) and its animated brother imported with the skinning sample processor (right).	The orientation display shows the up-vector direction of the flea relative to the ground level.
Unfortunatley the eggs thrown have no nice model yet.

Part 4: Alpha Release

To follow.

Part 5: Playtesting and Final Paper

Final Report

Project Status

Still in prosal phase.

Task Breakdown

1. Functional Minimum
   • The player can move the louse (no jumping, no animation)
   • Static level with different ground properties (slippery, sticky)
   • Skybox
   • Overlays
   • Blood can be sucked from weak points
2. Low Target
   • The camera does not lose track of the flea
   • The flea can jump
   • Throwing eggs
   • Enemies with simple AI
   • Flea / Enemy health indication and management
3. Desirable Target
   • Collision detection
   • The level is moving
   • End-boss fights
   • Cell shading / Overall nice graphics
   • Sounds
   • The camera does not lose track of the levels movement
4. High Target
   • Hair simulation (no interaction)
   • Different game scenarios
5. Extras
   • Anti-lice shampoo
   • Multi-player option
   • Cloth simulation
   • Collision detection with hair

Task List

Task	Phase	Who	Estim. time	Actual time
Miscellaneous
Title screen	1	J	1
Level design	2	D/J	2-3
2D Graphics
Background textures	1	J	1
Blood-sucking spots	1	J	2
Health bar overlay	1	D	1-2
Horizon indicator overlay	1	D	1-2
3D Models
Characters	2	J	30-60
Levels	2	J	50-100
Background	1	J	2
Eggs	2	J	1
Items	3	J	10
Animation
Characters	2/3	J	10
Levels	2/3	J	20
Blood-sucking spots	1	J	2
Camera control / movement / zoom ?	2	D	20-30
Physics
Jumping physics	2	J	5
Movement on slippery ground	1	D	2-3
Movement on sticky ground	1	D	2-3
Hair simulation	3	D/J	15-25
Liquid simulation	4	D/J	50
Characters drifts with liquid	4	D/J	10
Collision detection
Between characters/eggs and ground	1	D	3-4
Between characters/eggs	2	D	1
Between hair strand and ground/characters	5	D/J	25
Between liquid and character	4	D/J	20
Graphic effects
General lighting	1	J	2
Cell shading	3	J	5
Under water effects	5	D/J	25-30
Sound
Background music	3	D	10
Sound effects	3	D	15
Game events
Content loading/unloading	1	D	1
Animation playing/triggering	2/3	D	10
Player interaction (gamepad)	1	D	2
Level start, initialization	1	D	5-10
Level end -> via menu or success	1	D	2
Sound triggering	3	D	2
Throwing eggs	2	D	1-2
Health bar	2	D	1-2
Sucking blood from a weak point	1	D	3
Spawning/removing enemies	2	D	5-6
Spawning/removing hair strands	3	D/J	15-35
Level scenarios
Time race	4	D	2
Collecting hidden eggs	3	D	2
Victim scratches itself, rolls on the floor	5	J	100?
Under water/in the air	5	J	20
AI
Enemies	2	D	10+
End-bosses	3	D	10+

Timeline

1. Move the louse over a flat plane. No animations, no jumping yet.
2. Move the louse over a static level model. Collision detection with the ground.
3. Different ground properties (slippery, sticky) and their effect on the louse movement.
4. Sucking blood from weak spots.
5. Jumping.
6. Moving level model.
7. Background modelling.
8. Enemy parasites with simple AI. Player has to avoid walking into them.
9. Throwing eggs (player louse and enemies).
10. Close hair strands. Only for decoration, no interaction yet.
11. Distant hair strands.
12. End boss fight.
13. Game scenario: Time race.
14. Game scenario: Collecting hidden eggs.
15. Game scenario: Victim scratches itself.
16. Game scenario: Under water/In the air.
17. Anti-lice shampoo. The louse movement is not affected by the liquid yet.
18. Walking into the anti-lice shampoo causes the louse to move with the liquid.
19. Interaction with the hair strands.
20. Multiplayer option.

Next Planning Steps

• feedback from an assistant
• review targets and task list and update project proposal
• estimate task duration time
• distribute the tasks among us

Ideas

• There is an indication, how the player character is oriented, like the horizon display in a flight simulator.
• The story and game instructions are told by the characters using speech bubbles.
• The victim creature is located in the middle of a sky box and moves on the spot.
• Simulate wind by an additional force when jumping.
• Comic effect (?): use 1D indexed texture with sharp color borders. The index depends on the angle between the surface normal and the light direction.
• At the end of each level, the stats are displayed and the player is given a rating.

Status

Still in proposal phase.

Demos and Screenshots

Phase 1

Modelling the main character using Maya

Render image of an early flea model

top

Project Critiques

Questions

1. What is your favourite aspect of the proposed game?
2. What is your least favourite aspect?
3. What one change or addition would you suggest to most improve the game?

Battle Balls

Johanna Wolf:

1. I think this is going to be a great party game! I remeber playing a SNES fun racer where one could similarly push the other drivers down the abyss and this was totally exciting. Also, the inventive power-ups add a lot of variety. Not to forget the possibility for dead players to still influence the game. I also love the graphical design. I'm looking forward to the final product.
2. If I have to come up with something, I'd say, that a single game goal (eliminating the other players) might get monotone after many hours playing it.
3. Add different game scenarios, such as for example 'capture the flag', 'king of the hill', 'who has destroyed most buildings in a certain time' and the like. Why don't you make sphere "characters" selectable with different strengths/weaknesses.

Daniel Wolfertshofer:

1. This sounds like a great multiplayer game. The simple arcade gameplay should be lots of fun when opposing some friends. I also like the idea to still let eliminated players take part instead of becoming bored.
2. As far as i understood there seems to be no real need to risk rolling near to the levels border. Maybe this could lead to unintended boring gameplay in the (rare) case of players who do not play as competitive as expected (e.g. they just do not try to battle each other).
3. I think there is very little that should be enhanced but maybe some negative effect "boni" (e.g. reversing control mapping, very fast movement etc.) could make the level borders much more threatening

Gravity Bound

Johanna Wolf:

1. Bubble Bobble was already fun and I think it is a very interesting feature to have the room rotate, especially in combination with the necessity to collect the scattered blob parts again.
2. It would be a pity if you just used 3D models from the web.
3. I would suggest to put an emphasis on the room rotations when designing the levels. To create a unique look, you should use your own 3D models. What about setting up everything in the retro style of horror movies from the 50ies?

Daniel Wolfertshofer:

1. I liked the old Bubble Bobble in cooperative multiplayer mode very much. I am very interested to see how this will feel in 3D. The idea of the rolling cube seems to be very reasonable to me.
2. I think this game could suffer much from the XNA restrictions to a single console since the rather small split screen could make it much harder to keep track of the level. But surely you can not help that.
3. I think the main challenge is to balance the gameplay so that it gives real arcade fun feeling. So the cube rotations and physics will play the most crucial part. But i still woud recommend to try to give the graphics a cute look. The wobbly main character is a great idea but the opponents should look good as well.

Speed Thugs

Johanna Wolf:

1. The gravity fields are a very interesting idea and I also like the fact that you are going to focus on an extraordinary race track design with many alternative routes. And the cellshading look is going to make a difference.
2. If you don't come up with some innovations, you have to measure yourself against a whole bunch of already existing excellent speed racers.
3. Why don't you add a story mode or mini quest series, as for example eliminating some enemies within a time limit, collect all items in a track, 'capture the flag', make a wheelie and the like.

Daniel Wolfertshofer:

1. I like your idea of having fast paced tracks that offer many strategic decisions on which track to choose with different trade-offs. This could work especially well in multiplayer mode.
2. I think a racing game can not do really wrong. But on the other hand it is quite hard in my opinion to get something really exciting from the concept.
3. Maybe you could add more fancy extras (think of the Mario Kart series)/ penalties (like sticky, bouncing, etc areas) to add some more unique gameplay.

Titor's Equilibrium

Johanna Wolf:

1. The game concept is really exciting and inventive! I especially like the fact that a player can link to an object and acquire its properties. The fact that each level has different goals adds a great variety and surprise effect to the game and keeps the players interested for many hours. Not to forget the retro/Tron style which I think suits the concept excellently.
2. From the first glance, it is impossible for me to come up with any negative points, sorry.
3. It would add another dimension to the game if you'd embed it into a story. This could also work well together with the different level goals.

Daniel Wolfertshofer:

1. The physical effects look very cool and promising. This will definitely make the game stand out.
2. Maybe the gameplay part seemed a bit weak yet (but maybe you just did not emphasize on this in the presentation). The simulation you presented looked really good but i hope you will add an equally cool game mode to it
3. From the presentation the concept made the impression on me to be best played with a mouse. Maybe you should verify that the controls feel right.

S.P.H.E.R.E.S

Johanna Wolf:

1. I think this is also a great concept for a promising party game for its competitive aspect. The pillars which catapult the spheres away are an interesting point to the level design.
2. Having the coin and base regions fixed might encourage camping. Also, I miss power-ups.
3. Since there is only one game modus ("Collect the coin and carry it to the base"), it might get tiresome with the time. To my mind, you could prevent this by elaborate and strongly varied level designs. What about adding more pillars, which could also slow down the spheres or beam them to another place.

Daniel Wolfertshofer:

1. The best thing of the proposal is definitely the multiplayer aspect. If the levels are well balanced this could make a great game
2. Without extras the levels could turn out to be too static.
3. Maybe you should add more dynamic to the levels. For example morphing or moving coin etc. regions could help. Or you could give the players different ball physics with distint control trade offs (e.g. speed vs acceleration).

TBD

Johanna Wolf:

1. I'm a fan of scrolling shooters and think that the cooperative concept will make the game outstanding. You also mentioned that the levels are going to be generated randomly which I'd like to applaud. And I like the fact that missions are incorporated into the levels.
2. The interplay between scrolling and achieving the mission has not been clarified yet. It is only a matter of taste, but I don't like realistic styles. Would you make another Parodius for me, please?
3. You should really emphasize on the cooperation of the players since this makes the game outstanding. In my opinion, the strength of a scrolling shooter lies also in the diversity of enemies so the player should be forced to adapt new tactics.

Daniel Wolfertshofer:

1. To me the cooperative multiplayer mode seems to be the most promising idea of the game. Multiplayer is always fun and cooperative modes are even fun for not equally skilled players. To give both players complementary weaknesses and strength sounds like a very good idea to me.
2. I hope i got the idea right but i fail to see a good reason to use 3D graphics and/or modelling. 3D models would make sence if the movement and colllision detection would be performed in 3D but maybe then control of the game could be too hard to learn.
3. I would also suggest to use comic graphics instead of trying to give realistic impressions and stick to true 2D control. Emphasizing on great levels and well thought-out multiplayer action will let the player quickly forget about graphics anyway (think about this incredible ugly sopwith game for example).

* critique_severin.pdf: critique severin

top

Attachments

• projectproposaldraft.pdf: Assignment 1 - Project Proposal Draft
• Presentation01.pdf: Game Presentation

top