Count Pollen and the Search for the Golden Nectar
Summary
A collection of 3D mini games based around the Count Pollen story and characters developed by the Toon Brothers I.P. Limited. Developed in C# using the XNA libraries.
This was a group project undertaken as a module for the IET masters course and was done using sprint methodology.
Key Features
The main aspect of our game is the mini game structure which we felt would be appropriate for the target market of young children. The main game consists of six unique mini-games which serve to further the narrative of the story. This variety not only prevents the player’s experience from becoming stagnant and boring but also allows us to show the characters in a variety of way and pays homage to the myriad styles that influenced our design decisions. It is also possible to change the difficulty of the game in the options menu.
A major design decision was to have a question screen after each mini-game as a platform to educate the players on important environmental issues. This is in keeping with the ethos of the cartoon the game is based on as pitched by Toon Brothers.
The mini-game selection screen is also a nice feature. It is based on a map of Dublin city with models representing the locations in which each mini-game takes place. These consist of Dame Street, Trinity College, Merrion Square, the Science Gallery, Dublin Port and St Stephen’s Green. While playing the story mode the locations that the player has yet to encounter will be locked but for demo purposes these have been left unlocked.
The game saves the progress of the player within the game and also the high scores of the players. When starting a story mode, the player is asked to enter a three character pseudonym which will be used to represent them in the high score tables. This is also requested when a story mode is restarted. When the games have been unlocked they can be returned to in order to try and best your previous high score. Only one story can be in progress at a given time.
As previously mentioned the game has a strong narrative which is progressed by story screens before each game. Character bios are also available to help the story.
Tools Used
We used a variety of tools in the production of this game. We used XNA 3.1 for windows as the main development framework. Our programming environment was Microsoft Visual Studio 2008 C# Edition. To create the 3D models we used Blender and 3D Studio Max. For textures and other 2D graphics we used GIMP and Photoshop. We used Tortoise SVN as our subversion tool.
Engine Overview
When we started this project we discussed among ourselves whether to use a 2D or 3D engine. We decided to try using a 3D engine as many of our mini-game ideas would benefit from this. We also decided to use a component based system which allows the same behaviours to be used on any object in the scene. For example if we wrote a flying behaviour for one type of object in one scene it was simple to use this same behaviour in a completely separate object in a different scene.
Each mini-game is described as a separate scene object which describes the objects in that scene as well as the components assigned to them. The scene also describes any custom behaviour for that scene such as win conditions and specific collisions as in flight of the bumblebee and pollen collection. Each of these mini-game scenes is a sub-class of a base scene object, in this way it is simple to set the core scene object to any of the different mini-games at any point during the game. This is how we switch between the games and the map menu which is also described as a scene.
There is also a separate screen class which describes all the screen components in a similar way that the scene class does for the games. There are many different GUI components that can be used in this class such as buttons, images, drop boxes, tick boxes and many more.
There are a few different methods of drawing scene objects. The main method used for this is a model component. This takes in the name of the model and the name of the material to use when rendering. The base object contains information such as position, rotation and scale. The model component uses this information to draw the 3D model to the screen. Other visual components are point sprites and particles which are both 2D but can be located anywhere in the 3D world.
The engine makes use of efficient texture and model management where each texture and model is only loaded as they are needed and the data is stored separately to the objects in the scene. This allows for multiple objects to use the same textures or models simply by requesting the data from the manager systems.
Overall this architecture helped ease the integration of the teams work, reducing conflicts and making the sharing of work easier in general.
Flight of the Bumblebee
The inspiration for Flight of the Bumblebee was the classic Space Harrier game, developed by Sega back in the mid eighties. The name for the game is obviously in reference to the classical piece of music of the same name. The idea of the game is that you can only move the character in two dimensions, combinations of up, down, left and right as the character moves forward through the three dimensional game world. The forward movement is automatic and the in-game camera follows closely behind the character. The object of the game is to dodge obstacles as they fly towards you, whilst trying to collect other objects. In this case the obstacles are leaves and you get deducted points if you are hit by one. The collectables are pieces of pollen which increase your score if you collide with them.
The game engine provided the tools to be able to make this a reality. For starters, a basic scene was set up with some terrain and a game entity object was needed to represent the character. For this game, a bee model represented the character and was set as the model associated with the entity. A camera object was also created which had functionality to allow it to look at the character object at all times and remain offset in terms of position from the entity. This means that as the character would move forward in the world, the camera would move with it.
The component based nature of the engine made it easy to add code to control the bee. A bee control component was set up and could be associated with the bee entity in a similar manner to how the model was associated with it. The main purpose of this bee control was to allow user input to move the bee with the XBOX360 controller and also to move the bee forward automatically, regardless of user input. The bee’s movements had to be restricted as this was key to the game design. Later, functionality was added to allow the bee to rotate slightly if the user moved it left or right. Further functionality allowed the bee to move slightly faster and to spin out of the way of incoming obstacles, if the user had a “boost” available. A boost was awarded every time the player collected a certain amount of pollen.
The positioning of the obstacles and pieces of pollen was quite important in this game. Separate lists were maintained for the obstacles and for the pollen. The pollen had to be placed in such a way that it would not be too close to the obstacles. The obstacles were set up in waves. The pollen was placed in between these waves. The waves of leaves would differ from horizontal to diagonal ones as the game progressed, this was relative to the number of obstacles we wished to have in the scene. So, for example, the final quarter of obstacles would always appear in a diagonal line. These lists were updated so that objects would be deleted from the lists if they collided with the bee. The collision detection was handled by checking the bounding spheres of the objects against each other. The positions of the leaves and pollen had to be updated, as they were moving towards the player and they were also given some random rotation to simulate some wind blowing them.
The rest of the scene had to be set up also, such as the placement of the buildings, road segments and buses. An element of randomness was introduced so that similar buildings wouldn’t appear beside each other all the time. The only collision detection was between the bee and obstacles and the bee and pollen. The bee’s restricted movement made it impossible to collide with the buildings.
Buzzing Rhythm
This is a memory based game in which the player must repeat the pattern shown to them. The game itself features a minimal amount of entities, each of the keys and the bee are entities with model component attached. The bee entity has an idle animation attached to it. These entities only require simple animations (up and down for the keys, with side to side for the bee model) and as such it was not deemed necessary to create components for the simple behaviours. Each of the four keys has a different colour assigned to it, corresponding to the colours of the buttons on the Xbox gamepad
The actually game play logic is relatively simple. The current pattern is stored in a linked list of integers (i.e. the numbers zero to four representing the four keys). The number of keys expected in the pattern is determined by an integer (called chain) which is incremented following each successful repeating of the pattern (the variance in length of this integer is detailed later when talking about game difficulty) If this “chain” value is greater than the linked list count, then another key is added to the list. The key is chosen at random from the set of four and thus the patterns created are random.
Another integer (patternDrawNum) is used to indicate if the full pattern which is contained in the linked list has been drawn. This integer is incremented after drawing each key press until it matches the pattern linked list length and is reset to zero when it is required to show the pattern to the user again.
When drawing the key the linked list is accessed at the index corresponding to the current patternDrawNum value. The key found at this index is then moved down and changed to its corresponding colour. The resetting of the key position and colour and the drawing of the next key in the pattern is delayed based on the game time in order to allow the user to note the pattern.
User input is not accepted while the pattern is being outputting. Once this is completed and the user is prompted to return the pattern, a check is done for the buttons pressed on the Xbox pad. If the key button corresponds to the next colour in the pattern linked list then the expected index is incremented (thus is started at zero for each user input loop). If the full pattern linked list is inputted by the user, the expected chain length is incremented by two and the pattern is again drawn out for the user. If the pattern is inputted wrongly at any point then only the patternDrawNum variable is reset (i.e. the pattern is only drawn again but not lengthened). The drawing here is done simply by moving the key pressed by the player downwards, setting its colour and moving the bee model to this key position using simple integration.
The difficulty level in the game sets the starting and final max length for the chain variable. If the game reaches this max length then the pattern list is cleared and the chain value is reset along with the “repeat” integer being incremented. When this repeat value reaches the max repeat amount ( again set by the difficulty level) an end game state occurs and the screen wipe is called.
Pollen Collection
Pollen Collection is a simple game where the user has a limited amount of time to fly around Merrion Square and collect pollen from flowers of different colours. The user controls Gezundheit the bee and Count Pollen appears in the corner of the screen to tell them which colour pollen they should be collecting next.
The controls for the game are very simple. The left control stick controls the player’s orientation, and hitting the A button causes the player to fly for a short amount of time. Holding the A button down will allow the user to fly for longer periods of time. Whenever Count Pollen announces the next colour pollen for the player to collect, a spotlight appears over that flowerbed containing that colour flower. This adds an extra visual clue as to where the player needs to be going to advance.
One of the most difficult parts of programming this game was the collision detection between the player and the flowers. Due to the shape of the flowers, simple bounding boxes or bounding spheres were not a good enough fit to allow for accurate looking collision detection. To solve this problem, we had to program a series of small spheres to represent the model and do collision tests against all of them. This process was time consuming, since those sphere’s offsets had to be determined manually, but ended up giving a good, natural feeling representation of the flower models.
Behind the scenes, this scene also takes advantage of a set of classes developed by Microsoft employee and XNA MVP Nick Gravelyn (www.nickgravelyn.com). These classes allow for Timers with callback functions that are called after a certain amount of time passes. This is what makes Count Pollen congratulate the player after collecting the correct type of pollen for a small amount of time, then ask for the next type of pollen. These classes are extremely useful, and have a wide variety of applications, but unfortunately the team discovered them too late in our development cycle to make much use of them.
Port Madness
Port Madness is a platform game set in the port of Dublin. The front view, without any movement on the Z axis, makes it a 2D platform game even if it uses 3D models.
The player controls a Death Beetle raiding the port to find pollen. The goal is to collect the biggest amount of pollen spheres in the given time. Pollen spheres are spawned in predefined positions and once collected they are spawned after a few seconds in another position. Four crates are hanging from port cranes and can be used by the player to reach higher spheres. The crates moves up and down and the player can jump on them only when they are low enough.
The Death Beetle model was modelled by the group. A simple animation is applied to it, without using skeletal animation used in other mini-games: we simply modify the orientation swiftly so it looks like is walking or jumping. Collision detection is based on bounding boxes and spheres. The bug can bump its head on the boxes if it jumps below them (collision detected and position of the bug lower than the one of the crate), or jump and stand on them (collision detected and position of the bug higher than the one of the crate). When the bug jumps on a box, it bounces down slightly to simulate a realistic response, and is then pushed up again in a few milliseconds.
The movement of the crates is obtained used a Vibration component attached to the entities; this components moves the entity cyclically along one direction and according to different parameters (maximum distance, speed) as we can see in the game. The pollen spheres are rotated using the AutoRotation component and emits particles using the Emitter entity. We take care of moving the emitter and the sphere at the same time, so they look connected.
Finally, the background models animation (cranes, floating ship on the background) is obtained with a combination of the Vibration, AutoRotation and FollowPath components. These components allow for a very fast creation of background animation, and more models were not added only because of the time needed to model them in 3D modelling software (Blender 3D).
Nectar Alchemist
This game is a test of hand-eye coordination where the player has to press A when the arrow is pointing at a beaker of the specified colour. If the correct beaker is selected the score is incremented by 100, if the incorrect beaker is selected then the score is decremented by 200. The beakers move at an increasing speed and as the game progresses the arrow follows suit. This can lead to the game being quite tricky.
The action takes place in the foreground of the scene where the beakers moving along a conveyer belt and the arrow are situated. These are all entities with model components. The conveyer belt is implied by its two end box model components being located so that the “belt” is just off the screen and the beakers are carried along on it. There is one beaker per colour and the order of these is assigned randomly at the start of the scene. The arrow entity, in addition to the model component, has a “vibro” component which allows it to bounce up and down on an axis. The arrow bounces on the y-axis, to which its longest axis aligns. The background of the scene is composed of further entities for the desk model and the background image.
With regards to the game logic, the positions of the beakers are updated so that they are “carried” by the conveyer belt and so that they loop around when they reach the end box on the right. Their initial speeds and the maximum speeds they can reach are decided by the player’s chosen difficulty level. There are three stages to any game of Nectar Alchemist with the first having a stationary arrow, the second a moving arrow and the third having a quicker moving arrow.
When the user presses A the distance between the arrow’s position and the position of all the beakers is calculated in order to find the closest beaker to the arrow. If this closest beaker is the target beaker then the user is congratulated and the game randomly chooses the next colour, if not then the player is admonished and the same colour is repeated.
Dodge The Don
Dodge the Don is the final game where Count Pollen finally confronts the Don. While creating a fighting game would have been appealing, we decided to stick to a simpler game both because of our younger target group and for the additional technical complexity that would have been required.
The player controls a water lily where the two characters are jumping. Some pollen spheres are scattered around the lily (and respawned after collected) while the Don is jumping close to the centre of the lily, in a circular motion. Count pollen himself is jumping around and his behaviour can be controlled by tilting the lily.
While the Don and the pollen spheres are not affected by the tilting, Count Pollens next jump direction will be affected by the orientation of the lily when he takes off. The normal of the lily model (essentially a circle) is used to decide the new velocity of the Count. It is therefore possible that the player will make the Count to jump out of the lily, in that case the score is decreased and the Count is respawned in the middle of the lily.
We didn’t add a physical simulation to the game; we simply change the velocity with impulses and then decrease the Y-component of the velocity to simulate gravity. This simple choice resulted in a good animation and a more stable simulation.
The Don and Count are approximated by bounding spheres. If they collide, the Count is bounced back in the opposite direction and this can easily result in falling off the lily, increasing the difficulty of the game.
The models themselves have been created by the group with Blender 3D. We would have liked to have a better quality but we lacked the artistic skills needed; we decided then to have a reduced zoom in the scene so the models look fine from the distance. The models have been rigged (or skinned) and the resulting animation is obtained by a skeletal animation scripted in Blender and then exported to XNA.
Personal Contribution
As a team we all shared in the creative aspect of the games, and most major decisions were a group effort decided at scrum meetings. We all worked together to put the game engine together, fixing bugs as they appeared on the scrum board. Personally I worked on much of the story screen architecture for moving between scenes, including setting up the screen wipe for ending games. I worked on the game logic in all the games. most notably implementing the game logic, and scene set up for full nectar alchemist and buzzing rhythm. I integrated the difficulty setting in most games (all except port madness). I set up the music and sound effects components which were used for all scenes, as well as the options of turning these on or off. Art content was all done in house thus I also worked on several models, although all of these were not used in the final game.
