Game Implementation

Software Methodology
After observing the pros and cons of five different software development methodologies, the
decision was made to use the Waterfall methodology. As problems tend to come up within the first
half of the development weeks, this methodology would allow us to catch these and fix them or
change roles/development design to fix them and get a game produced on time. Also, with a focus
on documentation over implementation, this would allow us to use our skills much better to
accomplish what is needed.
Production
The project was developed with the Phaser (http://phaser.io/) game engine. This game engine was
chosen due to it's high compatibility with web browsers, it's multitude of tutorials and it's modular
approach to game development, which made it simple and efficient to use. To help create the game,
the Netbeans IDE (https://netbeans.org/) was used. This development environment was chosen due
to it's versatility in using different programming languages as well as its efficient and helpful user
interface.
During development, several tutorials were consulted on the Phaser website
(http://phaser.io/examples) to help gain a better understanding of how the Phaser game engine
works and how it could be utilized to help create the microgames we intended to make.
Coding Practices & Standards
To make the code more legible individual microgames and stage elements, such as the breaks
between microgames and character interactions, were separated into individual game states. States
were then separated using blank lines of code to help make them stand out. Using the Netbeans
IDE, these states could be collapsed which helped reduce the amount of code that was visible and
making the code easier to navigate.
Game states followed a set naming scheme (I.E- stage1gm01state, stage1gm02state, etc.) and
placed in sequential order to make them easier to locate. Comments were then added at the end of
each collapsed state giving off the instruction that would appear in the game when that state is
loaded, to further help identify what microgame each state contained. During implementation of the
alternative control scheme, comments on each state were followed by an asterisk (*) symbol to help
identify which states required the new control scheme.
An appropriate naming scheme was applied to all variables within the project, to make it easy to
identify what role they played in the creation of the game. Variables were often kept global, so that
similar names can be used across different microgames. As values for the variables changed as each
microgame was loaded, this had no negative effects on how the game played.

Example
///////////////////////////
//STAGE 1///////////
///////////////////////////
var stage1state = {...77 lines }
var stage1gm01state = {...301 lines } //CAST THE SPELL!
var stage1gm02state = {...211 lines } //GET THE TREASURE!*
var stage1gm03state = {...206 lines } //BLOCK!
var stage1gm04state = {...158 lines } //FLOAT!*
var stage1gm05state = {...162 lines } //ASSEMBLE!
var stage1gm06state = {...213 lines } //COUNTER!
var stage1gm07state = {...208 lines } //FREEZE AND SMASH!*
var stage1gm08state = {...163 lines } //DEFROST!*
var stage1gm09state = {...246 lines } //COLLECT THEM ALL!*
var stage1gm10state = {...233 lines } //HEAL UP!*
var stage1gm11state = {...201 lines } //CREATE ARMOUR!
var stage1gm12state = {...274 lines } //RESURRECT!*
var stage1end = {...69 lines }

Level Creation
To help maintain consistency all states in the game are the exact same size and microgames feature
the same basic elements.

Microgame

Lives

Timer
Control Scheme
Instruction
The Phaser game engine contains four different modules that were routinely used in the
construction of each of the states of the project
Preload( ): function { }
This module was used to load game assets such as levels, sprites and backgrounds into the
game and assign variables to them so that they can be called and used in the current game
state.
Create( ): function { }
This module was used to create the initial state of each microgame. This was done by adding
objects into the game using the assets created in the Preload function and setting initial
values for the microgame This module was used to load the user interface for each
microgame and reset values related to microgame completion, such as the timer and
the
'gameWin' / 'gameLose' values.
Update( ): function { }
This module is one that is repeatedly called as the game is playing. This was used to create
response to player actions like moving characters or firing weapons, as well as create
continuous events such as repeatedly spawning enemies. Actions could be created either by
writing code within the Update function itself, or by calling an additional function.
Render( ): function { }
This module was used to help check for errors in the game code. It was used to display the
values of certain variables on screen to ensure that they are changing correctly and working
as they should. Once everything is working as intended, all code within the function is
commented out for future reference.

Bug Fixing
Upon completion of each area of the project, such as microgames or stages, it was immediately and
repeatedly tested by the development team to ensure that it worked as intended. If a bug was found,
it was located either by inspecting the HTML5 source code using Google Chrome or by using code
written into Phaser's Render ( ) function to observe the changes of values. This helped to
immediately identify what section(s) of code was causing the problem and to quickly fix it.
Art Production
To help allow for more time for project implementation the majority of art assets were created
during the break between Trimester 1 and Trimester 2. Artwork for the game, such as character
sprites / animations, tilesets and backgrounds, was created by using the online graphics creation tool
Piskel (http://www.piskelapp.com). Graphics were saved as a PISKEL project file to allow for ease
of graphical manipulation, such as scaling and redrawing, and were converted to a .PNG format
using Piskel when being implemented into the game.
Audio Production
Unfortunately, due to time constraints on the project, only a musical score was able to be
implemented into the final build of the game.
All audio used in the game was composed by Kevin Macleod and downloaded through his website:
http://incompetech.com/wordpress/. To help make the sounds more compatible with different web
browsers, the initial .MP3 files were converted into an .OGG format using VLC media player
(http://www.videolan.org/vlc/index.html). Sound files were then renamed to make them easier to
implement into the project.
The following tracks are used in the project:
Thief in the Night (renamed to mapMus)
https://incompetech.com/wordpress/2016/04/thief-in-the-night/
Exhilarate (renamed to stage1Mus)
https://incompetech.com/wordpress/2013/05/exhilarate/
Rhinoceros (renamed to stage2Mus)
https://incompetech.com/wordpress/2015/06/rhinoceros/
Curse of the Scarab (renamed to stage3Mus)
https://incompetech.com/wordpress/2016/02/curse-of-the-scarab/
Motherlode (renamed to stage4Mus)
https://incompetech.com/wordpress/2015/04/motherlode/
The Lift (renamed to stage5Mus2)
https://incompetech.com/wordpress/2015/10/the-lift/