Presentation of My Final Year Project at Staffordshire University

1. EVOLUTION EXPLOSION

2. Background
 Story
• Scientist caught in lab explosion
• Needs to navigate world looking for lost vials
• To obtain vials puzzles need to be completed
• All vials make scientist human again
• Otherwise stuck as animal
 Chosen because:
• Experience in the adventure-puzzle genre
• Related to degree specifications

3. Introduction
Evolution Explosion is an adventure-puzzle game written in C++ and DirectX for the Personal Computer with a
Windows operating system. This project was designed to demonstrate the following:
 A complete game that can be played from start to finish
 The coding structure of a complete game
 Multiple handling of different user inputs and selecting the appropriate handler at the beginning of the
game
 Customisable user options
 Saving and Loading
 Selecting appropriate libraries from both C++ and DirectX to optimise, refine and refactor code
 In-Game sound
 Global Highscores
 Professional deployment of a game for the Windows operating system
 Multiple playable characters, rewards and punishments
 A complete game storyline outlined by a game design document
 Game pre-loading, pre-compiled assets, initialisation, real-time text rendering, error handling and cleanup
 Image manipulations such as rotation and scaling
 Powered by an in-house game engine
 Error handling
 Follows coding rules fully with Hungarian notation

4. Research and Planning
 Gantt Chart
 Methodology
• Agile Software Development
 Game Design Document
 Technical Design Document
 Similar Games
 Integrated Developer Environments
 Language and Application Development Interfaces
 Modelling
• Jackson Structured Diagram
 HCI
• Screen kept as simple and ‘clutter free’ as possible.
• Error Handling
• Consistency
• Instructions

5. Quality Assurance
 Developer Testing (Rapid Test)
• Black Box Testing
• Obvious bugs fixed immediately
 User Testing (Stress Testing)
• White Box Testing
• Less visible bugs and confusions resolved
 Soak Test

6. Front End
 Five Buttons
 Two Sub-menus
 Quit confirmation
 Continue game button disabled if no save
game is found
 Checks if the front end is brought up in-game
(esc) or from starting a new game

7. Frontend

8. Levels
 Five levels
 Graphics selection methods
 Character selection methods
 Scrolling the backgrounds
• Updating (paging on level 5)
• Parallax
• Relative to characters velocity
 Other animations
• Star rotation
• Door opening

9. Level One: Racecourse

10. Mini-Games Structure
 Four states per mini-game
• Introduction
• Play
• Win
• Lose
 Class structure
• Mini-games factory
• Completely independent (mini-game only knows
what it needs to know)

11. Pseudo Code
enum MinigameStates
{
intro state = 0,
play state = 1,
win state = 2,
lose state = 3
} eMinigameStates;
void Draw()
{
switch(eMinigameStates)
{
case intro state:
draw introduction screen;
break;
case play state:
draw play screen;
break;
case win state:
draw win screen;
break;
case lose state:
draw lose screen;
break;
}
}

12. Memory Game
Aim: To match all of the cards in the required timeframe.
 16 Cards
 2 Pairs – 8 matches
 Difficulty determines how much time the mini-game
runs for
 Win condition
• All cards have been matched
 Lose condition
• Timer hits zero

13. Memory Game

14. Issues Faced
 Initially randomising the cards
• Create a two-dimensional array with a while loop
that checks that a position on the x and y axis was
free. If so, fill it. If not, look again
 Crash when swapping a blank card with an
image card
• Changed the checking system to coordinate based
so if the clicked variables do not match the cards
position then the card stays blank

15. Level Two: Stamping Ground

16. Slider Game
Aim: To rotate all of the slide into their required positions within the
set timeframe.
 Randomly Rotated
 Each click rotates 90 degrees
 Difficulty determines how much time the mini-game runs for
 Animation in the rotations
 Score only incremented for the first time the slides are rotated to 0
degrees
 Win Condition
• All slides are rotated back to 0 degrees
 Lose Condition
• The timer hits zero

17. Slider Game

18. Issues Faced
 Rotating the slides
• Create a function with a local pointer to a Sprite
• Get the clicked sprite and convert rotation into
degrees
• Compare the current rotation position with the
desired position
• Convert position back to radians and update until
desired position is met

19. Level Three: Flying High

20. Sequence Game
Aim: To correctly follow each sequence the computer creates
within the set timeframe.
 Randomly generated
 Each new round is same as previous with one extra
sequence added
 Difficulty determines how many rounds there are
 Win Condition
• All rounds complete
 Lose Conditions
• Incorrect sequence
• Timer hits zero

21. Sequence Game

22. Issues Faced
 Constantly looping through a case invalidating it
• Create a NULL case which is called once the read
marker has been validated
 Last lit tile remaining on in the next round
• Set up a SetHotspot function that returns a boolean
true
• Change that boolean value to ‘false’ once the game
begins the next round
 Setting the timing of the game
• Define a constant show frequency variable and divide
it into the round length

23. Level Four: Swim Gym

24. Lights Game
Aim: To switch on all of the lights within the set
timeframe.
 Lights array toggles all surrounding lights
 Flickering animation and SFX when user does not click
for extended period of time
 Difficulty determines how many lights there are
 Win Condition
• All lights turned on
 Lose Condition
• Timer hits zero

25. Lights Game

26. Issues Faced
 Toggling Lights Crash
• Put in checks so if light is on the edge of the grid,
do not try to toggle the light on the side of the
edge that it is on
 Win state check returns true if only one light is
on
• Move the ‘for’ loop to an external function and
assume that the win condition is false until it has
checked every light and they are all on

27. Level Five: Vine Climb

28. Quiz Game
Aim: To answer all of the questions within the set timeframe.
 Questions are randomly set
 The same question is never asked twice in one game
• Link a boolean variable to the for loops ‘i’ variable
 Difficulty determines how difficult the questions are
• Three structures; easy, medium, hard
 Timer resets itself after every question answered
 Win Condition
• All questions answered correctly
 Lose Condition
• A question is answered incorrectly
• The timer hits zero

29. Quiz Game

30. Issues Faced
 Same questions repeating themselves
• Created a boolean variable that is set to true
when a number of an array has been chosen
 Comparing the answers to the correct answer
• Used ‘strcmp’ to compare the string selected with
the correct string
• Returned 0 = correct
• Otherwise incorrect

31. Game Structure
 Engine in separate library
 Each animal and mini-game completely
separate and managed by factories
 Everything initialised while the introduction
screen is shown so no loading times
 Easily editable
• Levels / characters can be swapped with one line
of code
 Game can be restarted from anywhere

32. Art
 Loaded in by resource
• Bigger executable
• No resource errors by users deleting assets
 Can either be a:
• Bitmap
• Sprite
• Static Background Layer
• Scrolling Background Layer

33. Audio
 Loaded in by resource
• Bigger executable
• No resource errors by users deleting assets
• Played asynchronously (new sound overrides previous sound)
• As opposed to synchronously (current sound needs to finish
before new sound can begin)
 Sound effects played by in-game events
• Card being flipped
• Correct selection
• Random number modularised to zero
 Support for background audio with pause and rewind
• Not implemented as no relevant music found

34. External Data Handling - Loading
 Use the <sys/stat.h> header file
• Call a structure from the header
• Use this structure to see if a file exists
• File is not opened, just checked
• Boolean TRUE or FALSE is returned
 If Save file exists:
• Enable the ‘Continue Game’ button
• If clicked, send boolean file requested to Levels
• Use custom written Load function to iterate through
each byte in the file and apply it to the correct
variable

35. Pseudo Code
structure saveTypes
{
enum Level currentLevel;
int difficulty;
bool checkFullscreen;
int score;
bool miniGameWinStates[4];
} sSaveTypes;
BOOL LoadGame()
{
open existing file EvoEx.dat;
Set saveTypes structure to in-game variables;
loop through each byte in the file and apply that byte to the
correct variable;
close the file;
}

36. External Data Handling - Saving
 Called each time a new level begins
 Check if a save file exists. If not, create one
 Use custom written Save function to write each
variable value to the file as a byte
 If a variable has not been set then fill the
corresponding byte with a placeholder value
 Saved data includes:
• Current level
• If the game should be fullscreen or windowed
• The users score (written in 5 bytes)
• The win states of each mini-game

37. Pseudo Code
structure saveTypes
{
enum Level currentLevel;
int difficulty;
bool checkFullscreen;
int score;
bool miniGameWinStates[4];
} sSaveTypes;
BOOL Save()
{
open existing file EvoEx.dat, if one does not exist,
create it;
set in-game variables to saveTypes structure;
format each variable into bytes (e.g ‘true’ becomes ‘1’);
write the bytes to file;
close the file;
}

38. External Data Handling
– High Scores
 Uses same method as saving and loading the
game
 Two extra functions used:
• Update – Checks if the current score is higher than
a highscore and places it
• Draw – Draws the scores to the screen

39. Debugging
 Breakpoints
• Show each iteration of a segment of code and
what each value contains
 Print to screen
• Use TCHAR to format variables and print them to
screen
 os stream
• Prints the results to the Integrated Development
Environment console

40. Optimisation
 Images
• Different Bit Depths
• Main Images – 24-Bit
• Secondary Images – 16-Bit
• Background Images – 8-Bit
• RLE compression used – halves the image size
• SetColour function used to change colour of image
• Sprite sheet flipping technique used – halves animation size
• Sprite class batch processes all images at once so adding extra images produces virtually no extra load time
• Loaded in by resource so already compiled
 Audio
• Stereo sound for major sounds
• Mono for less significant sounds
• Looping rather than one long effect
• Loaded in by resource so already compiled
 Fonts
• Loaded using the Sprite manager (batch processed)
• Splits the image into small tiles – one for each character
 Variables
• Pointers to memory – less overhead
• Use floating point variables as little as possible
• Use a vector container to manager all of the images (entity manager)

41. Future Improvements
Weather System
• Randomly selected when the game is opened
 Sun
• Use a light source for the sun
 Rain
• Randomly create lines that fall from the top to the bottom of the screen
 Snow
• Randomly create white pixels that randomly ‘sway’ left to right as they fall
• Or create a small image of a snowdrop and replicate many times
 Wind
• Play sound effect with volume relative to the wind strength
• Slow down or speed up the characters speed depending on wind direction

42. Future Improvements
Multiplayer
 Support already implemented for multiple
controllers
 Instead of facing a timer, user faces another
user. Winner gets the score multiplier and the
next character

43. Future Improvements
Computer AI
 Add in extra, computer controlled animals
• Bird character has birds flying in opposite direction and
avoiding it
• Already a distance checker so all that is required is a ‘for’ loop to
check each computer controlled characters distance from user and
if the animal is to close, to move up or down to avoid it
• Elephant has baby elephant following it around
• Scale the original elephant down
• Check the distance from the big elephant and the facing direction
and update accordingly

44. Miscellaneous Improvements
 Audio button in front end options so user can turn off
in-game sounds
 Create a resource cache to manage all game entities
 Add ambient lighting so transitions can be
implemented
 Better debug support
 Check memory and CPU requirements
 Add three-dimensional engine support
• Camera class, lights class and mesh class required
• Entity manager updated to check if the asset is a mesh or a
Bitmap

45. Conclusion
 Fully tested and bug free game that can be played from start to
finish
 Five different games in one game world
 Demonstrates common game aspects
• Saving / Loading
• Highscores
• Multiple Levels
• Multiple input device support
• User customisable options
 Industry standard Game Design Documents, Technical Design
Documents and Asset Lists
 On schedule with Gantt Charts
 Followed methodology as much as ably possible

46. The End