Trimester 2 - Documentation

Haunted Development
Decapitathlon
Project Documentation
Amos Room
(B00254109)
Table of Contents
1. Planning
1.1. Project Overview
1.2. Original Design & Final Implementation
1.3. Gantt Chart
1.4. Risk Analysis
Page 3
Page 3
Page 4
Page 4
2. Team Working
2.1. Project Management
2.2. Communication strategy
Page 6
Page 6
3. Project Implementation
3.1. Software Development Methodology Research
3.2. Production
3.3. Coding Practices & Standards
3.4. Level Creation
3.5. Bug Fixing
3.6. Art Production
3.7. Audio Production
Page 7
Page 7
Page 7
Page 9
Page 10
Page 10
Page 10
4. Testing
4.1. Alpha & Beta Testing
4.2. Regression Testing
4.3. White & Black box testing
Page 11
Page 11
Page 11
5. User Experience
5.1. User Acceptance Testing
5.2. User Experience Analysis
5.3. Feedback Implementation
5.4. User Testing Log: Stages
5.5. User Testing Log: Full Game
Page 12
Page 12
Page 12
Page 13
Page 22
6. Project Meeting Minutes

6.1. Internal Minutes
6.2. External Minutes
Page 36
Page 38
7. Development Blog
Page 47
1. Planning
1.1. Project Overview
For our game project we aim to create an arcade-style puzzle game called Decapitathlon to be
hosted on our group website, http://haunted-development.weebly.com/ and played on PC web
browsers. Our group name is Haunted Development and consists of one single member performing
the following tasks:
Amos Room (B00254109)
Project Management
Task Management
Content Creation
Art Creation
Concept creation
Game Design
Character and World Design
Sound Design
Game Research
Graphic Design
Development Research
Programming
Project Implementation
Testing
1.2. Original Design & Final Implementation
The original plan for this project was to create an 'arcade puzzler' game, in similar vein to the
WarioWare and Dumb Ways to Die series of games, to be developed using the Phaser game engine.
The game is to be hosted on our website and played through web browsers. The gameplay itself is
composed of short and simple 'microgames' which are to be completed within a time limit of five
seconds. The game is controlled using two different control schemes, one using the keyboard and
the other using the mouse.
The game is set in a fictional fantasy setting with a range of different locations and populated with
various cult horror icons such as the Headless Horseman, the Mummy and Frankenstein's Monster.
The player explores the world through a world map where they are free to choose from a variety of
different stages, each composed of a different location and featuring a different monster with a
different theme being given to the gameplay.
The game was to originally consist of a series of eleven different stages, ten of which having their
own distinct theme and their own series of microgames with the eleventh being an unlockable
bonus stage which played through every microgame available in the game for the player to gain a
high-score. Due to misunderstandings within the team, the original two person group of The Bone
Room was split, rendering the original plan impossible to accomplish within the given timeframe.
As such, the final project now consists of five different stages, including the unlockable bonus
stage.
1.3. Gantt Chart
1.4. Risk Analysis

There are many factors that may leave a negative impact on the project. These may include illness
and holidays, technical issues, human error and failure to work together as a team. These risks have
been identified and are covered in greater detail below.
Illness and Holidays
Illness would cover any absences made by any member of personnel during any stage of the
project, as a result of being ill. We plan to deal with this issue by maintaining a steady line of
communication via emails, text messaging and WhatsApp Messenger to inform personnel
about the absence and by allocating different members of personnel and more time spent to
different sections of the project if someone is unable to work on them.
Technical Issues
This covers issues that can be made due to system hardware or software failing to work as it
should. This would include personal computers failing to load, project software failing to
load work that has been done or work being. We plan to counteract this by having work
stored on multiple systems, as well as in an online Dropbox folder so that work done can be
accessed through multiple systems if one does not work. We also plan to save earlier
versions of work done during the project, such as documents and project builds so that if
the current version fails to work we can then load the earlier builds and then better find the
route of the problem.
Human Error
This covers all the risks that could potentially be made as a result of human error. This
would include unexplained absences not covered by illness or holidays, work being lost and
work not being backed up. We plan to deal with this by using communication methods to
find out the reason for the absence, and by having roles re-assigned to catch up on the work
that wasn't done. If work is lost and not backed up, we plan to have copies of our work saved
on an online Dropbox folder and on personal computers as soon as the work is done and this
will be enforced by having personnel contact eachother as soon as work is done.
Bias in Testing
There is the potential risk that both personnel who have worked on developing the project
may have a certain bias towards the project and may be more prone to missing glitches and
errors during the testing progress, which could then be found in the final build of the game.
To counter this, during the testing stage we will have an internal Alpha test to be done by
both personnel which will then be followed by a closed Beta test that will be done by other
students at the University. This will allow for a fresh, consumer perspective on the project
without any of the potential bias that could come from those who have worked on it.
Project Clash
As development of the game progresses there will be the risk that the time allocated to this
project may negatively affect some of the other work that we have to do for other projects.
In this event, in order to allow us time to work on other projects, we will consider removing
some aspects of the game to make it more manageable and more viable to complete under
these conditions. When doing so, we will ensure to not remove any fundamental parts of the
gameplay and will instead remove more superficial elements such as the number of
microgames available and the world map.
2. Team Working
2.1. Project Management
Before Haunted Development separated from The Bone Room, project tasks and responsibilities
were split evenly between both members of the project. This was to help keep the workload
manageable between group members and ensured that both members were contributing equally to
the project. This left each member responsible for completing five stages of the proposed eleven,
with the eleventh being developed once the first ten have been completed and tested.
When team members separated on Week 6 of Trimester 2, this helped allow for individual work to
recommence quickly as group tasks were already split evenly which meant it was easy to focus on
what was feasible to complete.
2.2. Communication
Communication between both members of The Bone Room was maintained primarily using social
media and phone networks such as Facebook and WhatsApp. It was up to team members to contact
each other if any major changes were being made to the project or if they were unable to make it for
a team meeting.
3. Game Implementation
3.1. 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.
3.2. 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.
3.3. 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. 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 which referred to the instruction that would appear in the game when that state
is loaded. This helped 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 if required, 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 and
reset as each microgame was loaded, this had no negative effects on how the game played. White
spacing is also used to help keep relevant areas of code separated from eachother and prevent the
code from being difficult to navigate.
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 }
3.4. Level Creation

To help maintain consistency all states in the game utilize the same game window and the
microgames all feature the same basic user interface.
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 different game 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.
3.5. 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.
3.6. 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.
3.7. 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/
4. Testing
4.1. Alpha & Beta Testing.
Alpha Testing
Alpha Testing was done after individual stages for the game were completed and game flow
was applied. During Alpha testing, stages consisted of individual project files that played
through their respective microgames endlessly until the player lost all their lives. Each stage
was played through individually and tested to make sure it worked as intended. Stages were
played through multiple times to ensure that all microgames had been played through and
that they all worked together.
Beta Testing
Beta Testing was done after the different project files for the stages were compiled together
to form a single project build and the essential changes found during the Alpha Testing
stage, as well as additional game features such as story elements were implemented. The
entire build of the game was played through multiple times to ensure that all the different
microgames were tested and that they worked as intended along with the new features that
were added.
4.2.Regression Testing
Regression Testing was made after the beta testing is complete. It was done to test any changes or
additional features that were added to the code as a result of findings in the Beta. This included the
difficulty balance of some of the microgames as well as the implementation of a new menu
explaining the different control schemes in the game.
4.3. White & Black box testing
White Box
White box testing was used to test that the code was functional and worked as intended. It
was used during the Alpha testing stage to make sure that microgames and stages worked as
intended before they were implemented into the full build of the project. In the event that
errors were found, code was added in / edited as necessary and further tested as development
continued.
Black Box
Black box testing was used to ensure that the bare essentials of the game worked as
intended. This included making sure that keyboard and mouse inputs were delivering the
correct responses in the microgames and testing that the game ran correctly while hosted on
the development website. During the User Acceptance Testing in the Beta, the game was
tested for compatibility on numerous different web browsers (Google Chrome, Internet
Explorer, Firefox and Opera) and operating systems (Windows 7, Windows 8.1 and Windows
10).
5. User Experience
5.1. User Acceptance Testing
User Acceptance Testing (UAT) was employed during development to observe the game's reception
amongst the intended user audience for the game, as well as test for any potential bugs that may
have still been present in the code.
UAT was employed during two particular areas of the projects development. The first was during
Alpha testing after each stage was completed, with the second being during the Beta testing stage
once an initial build of the project was uploaded to the development website. This was to help test
for any errors or balancing issues that were present early on in development so that they would be
easier to locate and fix before all work was combined to form one singular game.
Testers consisted of people from both within and outside the University, each of which contacted
personally through social media networks. All testers have different opinions and experiences with
computer games and utilized a variety of different web browsers and operating systems. The
majority of testers were Male and aged 20.
During Alpha testing, testers were sent links to playable versions of individual stages hosted
through Google Drive. During the Beta testing, testers were given a link to the where the game was
hosted on the development website. During UAT, testers were given a User Feedback Questionnaire
to fill in and provide feedback, which was distributed through Dropbox.
5.2. User Experience Analysis
Overall, the project has seen a positive reception from users.
The general experience of the gameplay is that the game provides a challenging and engaging
experience. It does take a little bit of time for users to get used to the format of the game, however
this is to be expected given that the 'arcade-puzzler' genre is somewhat unconventional. No
outstanding bugs or glitches were found by users, even after multiple playthroughs. Users
complimented the music in the game and thought it fitted with the theme of the different stages and
wasn't obnoxious or distracting. The two different control schemes were also praised due to being
simple and easy to use.
During UAT of the Alpha stage, a big complaint was that it was awkward for users to switch
between the keyboard and mouse controls. It was also found that some games were unbalanced or
had misleading instructions, which made them far too difficult to complete in the given time. These
complaints were all acted upon before testing was made on the full game.
During testing of the Beta some technical issues were found, however none of which were directly
related to the project as a whole. One tester reported that having a slow internet connection caused
the game to take an incredibly long time loading assets for the different microgames. Another noted
that using the arrow keys / space bar caused the web page to move up and down.
5.3. Feedback Implementation

Over the course of the User Acceptance Tests, several changes were suggested for making the game
a much more enjoyable experience. These were all taken into account and then listed as either
essential or non-essential in regards to whether the changes suggested would help make the game a
more enjoyable experience, or if they weren't feasible to put into the game.
Stages
Essential
Non-Essential
Change instructions for some games

Some games are unbalanced
Control Scheme awkward
Change collisions
Change instructions for some games

Changed in accordance to user feedback
Some games are unbalanced
Changed in accordance to user feedback
Control Scheme awkward
Changed by adding in support for the use of W,A,S,D for directional movement.
Full Game
Essential
Non-Essential
On-Screen Tutorial
Stop stages repeating

Clearer map layout
More level variations
Single Control Scheme
Improve Graphics
Mute Sound
Text Unreadable with Dyslexia
On-Screen Tutorial
Changed by adding in an additional menu at the game's title screen which explains the
different control schemes
5.4. User Testing Log: Stages
Decapitathlon
User Feedback Questionnaire
Tester Name: Rachael Nicol
Date: 12/4/16
Age: 20
Gender: Female
Stage Number: 1
Were there any notable errors during the game?
No
Was it clear what your goals were during the game?

Mostly. The one where you cast a spell took a while to figure out because I didnt immediately see
the spell at the side that is to be copied, because its quite small, and the colours on it are quite
similar. For the same reasons, plus the fact that you need to know what order the symbols appear in
when you click on them to be able to do it quickly, I have so far been unable to complete this level.
Did the controls feel intuitive?

Mostly. The one where you block the incoming fireballs I keep trying to block with the spacebar, it
took quite a while to figure out that its actually the right and left arrow keys that youre meant to
use, and still I keep going to use the spacebar, then in the split second it takes to remember that
thats not that you use, youve been hit already! I think it would help a lot if the first 2 fireballs that
are always right there at the very start were a little further away to begin with, to give time to get
used to the controls.
Did the gameplay feel consistent?

Yes.
Did each microgame stand out as a unique challenge?

Yes.
Do you feel the game is presented well?

Yes.
Is there anything you would like to see changed?

See comments above. Also, in the one where you build armour from 6 pieces of metal, I cant
physically move them quick enough to get the 6 pieces of armour to the person in 5 seconds
-possibly because Im using a mousepad rather than a mouse? I feel that 5 pieces would be better
because it would still be challenging, but would allow for there to be at least a possibility of being
able to complete the level.
What was your overall experience with the game?

I found that for all the microgames except those mentioned above the goals were clear and the
controls easy to use.
Decapitathlon
Date: 12/4/16
Age: 20
Gender: Female
Stage Number: 2
No.

Mostly. The laser one I only figured out how to do by chance. I think it would be clearer if the
instructions said to fire the laser rather than charge it, because that is the end goal of the
microgame, it just happens that you need to charge it first; you cant pass the level if you just
charge it.

Yes.

Yes.

Yes.

Yes.

The instructions for the laser, as previously mentioned. Also, in the one where you have to dodge
the asteroids, they come at you too quickly to give you time to move to the appropriate controls in
order to move out of the way before getting hit. I have as yet been unable to dodge even the first
asteroid as by the time Ive registered what game it is and switched to the appropriate controls,
theres no time left to move out the way of the asteroids. Perhaps start them further away, or in
different directions or something like that?

Overall I found that the game was well presented, and the controls were intuitive and easy to use.
In general the aims of each microgame were immediately clear.
Decapitathlon
Date: 13/4/16
Age: 20
Gender: Female
Stage Number: 3
No. However, in the follow the arrows gam if there are 2 consecutive arrows going the same
direction you only have to press the key once. Is that supposed to happen?

All were clear except the one where you are instructed to get three. I thought this meant that you
had to click on 3 tiles which matched the one shown and couldnt figure out why it wasnt
working!

Yes.

Yes.

Yes.

Yes.

Maybe change the instructions for the get three game to make it clearer what youre supposed to
do.

Well presented and the controls were intuitive and easy to use. The aims of each microgame were
generally clear.
Decapitathlon
Date: 28/03/16
Age: 20
Gender: Female
Stage Number: 4
No. However there were some things that I originally thought might be errors so had to ask about
them. In particular, the disappearance of e.g. the horse, or the birds if you dont manage to
complete the task presented; also, in the pumpkin game no indication is given as to whether or not
youve selected the correct one, or whether or not your selection has been registered by the game
before the timer runs out.

Overall yes, but some required some explanation. In particular, for the needle-in-a-haystack game,
it was unclear that you had to actually click on the needle once youd uncovered it to avoid losing
a life, it seemed like you just needed to uncover it to win, which was quite confusing when it
continued to remove lives even when the needle was uncovered.

Yes, however I sometimes found that, as each microgame lasts only 5 seconds, the time taken to
switch between keyboard-mouse and vice versa can take up a relatively high percentage of that
time, particularly if it doesnt instantly click in your mind which youre supposed to be using.

Yes.

Yes.

Yes.

See comments above. One final thing I havent mentioned previously: in the game with the cow, I
dont feel that 5 seconds is quite long enough to complete it yes it is possible, but only if you
know exactly when to change direction, which is difficult because the cow cannot move in the
entire space that it appears that it should be able to move in it has to be a distance away from the
fence, which is fine when moving in straight lines, but makes determining when to turn quite
difficult.

Overall I felt the game was well presented, and flowed well switching between the microgames.
Apart from the things mentioned above, I found that the objectives were generally clear, and the
controls quite intuitive to use.
5.5. User Testing Log: Full Game
Decapitathlon
Tester Name:
Date:
Age:
Gender:
Alasdair Stuart
21/04/16
20
Male

None.

Yes, for the most part the mini-challenges spoke for themselves and the objectives were clear.

Although the control scheme was simple enough, one problem I encountered was that for some
mini-games precious seconds were wasted finding out whether it was the mouse or the keyboard
that was required for that particular challenge.

Yes

Yes, no one puzzle felt like it was the same as the others.

Yes, the theme of the challenges and the style of the music for each area of the game is well suited.

One thing I found undesirable was repeating the same challenge multiple times within a single
play-through of a stage. Although some puzzles had multiple variations to alleviate this problem,
other puzzles did not. I think increasing the variations of a puzzle would improve re-playability.

I found it to be a challenging experience, but one that was enjoyable. Although some puzzles were
frustratingly difficult to do in 5 seconds such as casting the spell or changing the frequency, they
are possible with practice none-the-less.
Decapitathlon
Tester Name: Ben Antcliff
Date: 21/4/16
Age: 21
Gender: male
No notable errors.

lost from the start.
needs better tutorial/on screen help.
Good mix of WASD, space and clicking. The controls were simple.
The Difficulty varied per micro game.

Each game was quite unique, and fitted themes of the stage.
Execellent music, poor tutorial.

needs better tutorial/on screen help.
Positive bar lack of expaination and tutorial
Decapitathlon
Tester Name: Calum Littler-Gordon
Date:20/04/16
Age: 20
Gender: M
None seen
yes

yes

yes
yes

Good presentation, good music, good sprites

Clearer map layout,
Took a while to figure out where to click to start stages

Positive
Quite difficult
Long loading times
Decapitathlon
Tester Name: John Callaghan
Date: 20/04/2016
Age: 29
Gender: Male
Not sure if it is an error but some games do repeat moments after they have just been played.
While the game is clearly randomly selecting microgames to play it would look and play better if
the already played games where blocked from appearing again in the same playthough.

No as while the game does give small descriptions on what each microgame entails, Not much is
given in the way of how to achieve this. It takes a second to work out what controls you're meant
to be using, which can and does effect the enjoyability of the game. I understand this is a similar
game to such games as WarioWare and Dumb Ways to Die however these games do have more or
less one control method for input making them more consistent overall... consistent game-play
would make this a more appealing title.

The W,A,S,D, Arrow keys and Space bar feel perfectly suited to this type of gameplay. That being
said the mouse controls and constantly changing controls between microgames makes it feels less
intuitive and more of a confusing chore.

Again the keyboard operated gameplay made it very consistent, however constantly changing
control methods made it less so.

Some seemed quite similar however due to this being a game of microgames it is to be expected
for the genre, a unique challenge can be found in each of the games even those with similar styles.

While it was presented for the most part well, I feel that the graphics could be nicer, and the
control swapping polished up a bit, The story text colour on the grey background also made it
impossible for me to follow the goings on due to my dyslexia.

Maybe find a way to control the games that have been played from being played right away again
(or stop them completely,) fix the controls to just be keyboard based as this really made the
gameplay fun, make the text for the story stand out more for those that can't read it, (perhaps a
textbox effect or changing background or text colours to make it more legible.) Graphics could
look better and be of a better standard.

I had the chance to test this games prototype and liked it a lot. This time playing the final project I
found that overall the gameplay seemed fun but I did feel a little frustrated while playing with the
controls changing back and forth and the text being impossible to read making it so I couldn't
understand the story. I really liked the soundtrack and felt it suited the gameplay very well.
Decapitathlon
Date: 20/4/16
Age: 20
Gender: Female
When using the game online (rather than from google drive), the use of the spacebar and up/down
arrows causes the page to scroll up/down as well as controlling the game. The effects of the
spacebar can be reduced by making the page fullscreen, but this does not help with the scrolling
due to the up/down arrows. This issue does not arise when playing the game from google drive.

Yes. Noticed in particular that those which I had found unclear previously in the individual stages
had been changed and are now much clearer.

Yes.

Yes.

Yes.

Yes.

Not that I can think of.

The aims of the game were clear throughout, both in the individual microgames and overall. It was
well presented and the games were linked together nicely, again both between microgames, and
between stages.
Decapitathlon
Tester Name: Ross Sharp
Age:17
Gender:male
Date:21/04/20116

No noticeable errors/distinct errors/glitches

Mostly, some of the minigames were hard to figure out at first, I was able to get the hang of it quite
fast though and it became very enjoyable (though still quite challenging at some stages)

The controls were fine, a bit more description through the levels would have been helpful though,
for example in the alien level with the blaster it was click and hold, I think a better control would
have been the space-bar as that is the common activate button, but thats more personal preference.
Otherwise the controls, were easy to understand, simple and solid.

Some of the cahllanges varied a lot in difficulty, but overall the levels seemed to have a similar feel
and look, the actual gameplay was also very consistent with control mapping not changing
between levels and challenges that are similar and remaining logical throughout.

They all stood out as challenging, I would go as far to say fully unique as they all had very similar
styles, but they were different enough for it to not be repetitive or overly boring. As for challenging
the microgames were fast paced leaving little time to think, this made for a fun experience overall.

The game has a nice simple presentation that suits the theme well, the music is catchy and not
overly obnoxious, the simple layout of the challenges that stays consistent is also quite nice as it
stops the guesswork of ever-changing guis.

Not very much, apart from the slight control issue, but as stated this is more personal preference,
also a volume slider or mute button would be a nice touch for those watching videos or listening to
music in another tab/browser.

Very fun and challenging, definitely something I would play a lot if it was larger, felt very fast at
the beginning and even at the end I was still struggling to keep up, this is a well-balanced game
thats fun and interesting to play.
Decapitathlon
Tester Name:
Age:
Gender:
scott sharp
20
male
Date: 21/04/16

Within the half hour I played the game I didnt come across any errors or problems.

Some of the goals of the game were not clear at first but after few goes the objects became clear.

The controls were self-explanatory and natural.

Yes

Each game had a different fell to it.

I felt the way the game was lady out was

I would like to see different difficulty added witch could increase or decrease the time for each
game or reduce the number of lives you have.

I relay enjoyed the game as it was both changeling and fun at the same time.
6. Project Meeting Minutes

6.1. Internal Meetings
COMP09015 Games Project: Creating Game
Internal Meeting The Bone Room
09/02/16
Those Attending: Nathan Bone & Amos Room
Apologies for absence: N/A
Work that has been done since last meeting
Defined roles for this trimester
Work to be done before next meeting
Finish redesign of microgames, complete work on assets, complete work on sound library, update
Gantt chart and risk analysis for trimester two.
Make sure blog entries are done each week
Any Other Business
The drop from 150 microgames to 120 microgames was approved.

Have a look at software design methodologies
Gantt chart brief:
o Weeks 1 2 Updating design and completing assets
o Weeks 3 8 Development of games for stages
o Weeks 9 10 Development of menus and modes
o Weeks 9 12 Testing
o Week 12 - Presentation

Internal Meeting The Bone Room
16/02/16
Those Attending: Nathan Bone & Amos Room
Work that has been done since last meeting
Graphical assets have been completed
Trimester 2 Gantt chart has been completed
Risk Analysis has been updated to reflect work in Trimester 2
Work to be done before next meeting
Start implementation of Stage 1 and Stage 2 of the project
Start planning QA Testing
- Research on software testing methodologies
Start designing User Feedback questionnaire
- Research on software development methodologies
Any Other Business
-
Development of the game to be done over the next 5 weeks.

If problems are encountered when developing games during the weeks, we can meet up
during the week outside of the class to sort them out.
6.2. External Meetings

External Meeting The Bone Room
16/02/2016, 9:30am, GT 01
Those attending
Nathan Bone
Amos Room
Jim Scullion
Apologies for absence
N/A
Project Status
Green
Work completed since previous meeting
Graphical assets have been completed.
Trimester 2 Gantt chart has been completed.
Risk Analysis has been updated to reflect work in Trimester 2
Work planned before next meeting
Start implementation of Stage 1 and Stage 2 of the project
Start planning QA testing
Start designing User Feedback questionnaire
- Should not be a survey. Play testing should be watching someone play the game and noting
their body language and using a structured Q&A session after play.
- Dont defend, just listen. The player should be doing most of the talking
- Afterwards, take the list of features gained from play testing and split into three categories to
show what is essential and what would be nice to have (even if it doesnt end up being
implemented into the game by the end.
Any Other Business
Should be researching software methodologies. Need to use weekly checklist as a guide of

where we need to be.
COMP09012 Games Project: Design and Plan

23/02/16
Those Attending:
Amos Room
Jim Scullion
Apologies for absence: Nathan Bone

Project Status
Orange / Red
QA Plan started
Stage 1 of project complete
Continue project development
Stages 3 and 4 complete by next week
QA plan complete
Any Other Business
No major issues on the project... yet.
Concerned over Nathan's absence and lack of evidence to completed work
Any issues caused on individuals part will affect individual grade, not grade of group
members

1/03/2016, 9:30am, GT 01
Those attending
Nathan Bone
Amos Room
Jim Scullion
N/A
Project Status
Amber
Software Development Methodologies researched
Software Testing Methodologies researched
- More detail required in the testing methodologies (especially regarding playtesting) over the
development methodologies
Music Library acquired
Project Stage 2 complete
Compile QA plan
- We have the individual components but theyre just not stitched together
Continue development of sound library
Continue project development
Any Other Business
N/A

External Meeting Haunted Development
08/03/2016, 9:30am, GT 01
Those attending
Amos Room
Jim Scullion
N/A
Project Status
Green
QA Plan Complete
80% of Stage 3 complete
Complete Stage 3
Complete Stage 4
Begin writing Testing Report
Begin User Testing on Stage 1
Any Other Business
The Bone Room is split
Create new website domain (email Jim)
Transfer everything from The Bone Room website to new domain (leave documents as is)
Change work plan to reflect solo development

15/03/2016, 9:30am, GT 01
Those attending
Amos Room
Jim Scullion
N/A
Project Status
Green
Stage 4 Complete
Haunted Development website created
Work transferred from The Bone Room
Amend project plan
Create a new document
Project proposal, Risk Analysis + Gantt Chart.
Complete Stage 5 (final stage)
Start work on game-flow
Any Other Business
Leave inconsistencies between Games Design and Technical Design documents to Project
Evaluation, giving context to situation.
If possible make time to amend yourself, however not necessary.
Website is fine, no necessary changes required.

22/03/2016, 9:30am, GT 01
Those attending
Amos Room
Jim Scullion
N/A
Project Status
Amber
Stage 5 mostly completed
- 80% of microgames completed
Project Plan updated to reflect new team development
Game Flow planned
Finish Stage 5 & 6
Complete Game Flow
- Timer
- HUD
- Stage Compilation
- World Map
Any Other Business
Laptop broken (screen-cracked)
- Being repaired
- May take a few days before I gain access to all my software again.
- Work on sound libraries and documentation while its being repaired.
Possibility of borrowing one from UWS library
- Only lasts 3 hours, can only be used on UWS grounds.
Project going fine (Exception of laptop)
- Testing left until end of development
- Still good decision to have split groups
Website is fine, no necessary changes required.

29/03/16, 9:30am, GT 01
Those Attending:
Amos Room
Jim Scullion
Project Status
Green
Game Flow completed
- Microgame Compilation
- Timer
- HUD
User Testing started
Continue game development in accordance to user feedback.
Continue Testing
Create world map
Complete Stage 6
Any Other Business
N/A

`12/04/2016, 9:30am, GT 01
Those attending
Amos Room
Jim Scullion
N/A
Project Status
Amber
World Map completed
Game Flow to stages 1-4 completed
Testing continued
Complete Stages 5-6
Continue Testing and changing game according to User Feedback
Begin Testing write-up
Any Other Business
Prioritize user-feedback
Essential & Non-Essential
Document process of elimination
Create testing cut-off date
22/04/16

19/04/16
Those Attending:
Amos Room
Jim Scullion
Project Status
Green
Stage 5 removed
Would have taken too long to fix / add game flow
Stage didn't stand out that much from the rest
Theme lead to games feeling samey
Initial Project build completed
Uploaded to website
Stages 1, 2, 3, 4, 5
Story Elements included
Musical Score
Few features missing, however nothing critical to the game.
Will be added by next week
Continue Testing and changing game according to User Feedback
Final Week of Testing
Create / Rehearse Presentation
Write-Up Testing document
Any Other Business
Presentation (15 mins):
- Edited Highlights of project
- Personal Experience of whole project
o What you've learned / How it'd be applied
Overall Documentation:
All Trimester 2 documentation in one single document
Everything on CD-R hard copy
7. Development Blog
The Bone Room - 02/02/16
We are back! The Christmas break is over, drink has been had (a lot) and we're back to work on our
game. This trimester is all about actually creating a fully finished game from our prototype and
design work from last trimester. It's going to be a hard task but I think it is one we can do if we put
our hearts into it.
Sadly, the first week back isn't proving too good. Due to the weather, train lines were shut down
between Irvine and Ayr and Amos couldn't make it down to the campus so it was a pretty uneventful
week in the class. Much like in trimester 1, this week was the one and only lecture for this module
which talked about what the requirements for the module are. What needs to be done by the end of
the module is to have a full game ready and completely tested to maximize the player's enjoyment
and to make sure the game is bug free. It's going to be a hard task but if we look at our design, make
sure we have it nailed down and we know where we are going and that it can be done, I believe we
could have a really good game by the end of it.
For next week, really we have to have a chat through whatever means and make sure we can get this
down or if there needs to be some changes made to the design of the game to make it work.
Hopefully by next week we'll have a better idea of what we are doing.
Big update on the game this week.
Over the course of the week, we talked over social media and it became clear that, with the
workload for this trimester, that creating the 150 microgames and putting them together in the way
we have envisioned and then testing the game to its limits is just not going to happen. After talking
it out in the team and with our lecturer, we have decided to drop the number of microgames down
from 150 (15 per stage) to 120 (12 per stage). What this does is allow us to create these and test the
game must better while also allowing us time for other modules to complete the work required for
them. We still believe this to be a great variety of games and that it can still challenge the players
the way we want it to.
Otherwise, it's a pretty standard week going ahead. We will be working on completing the small
things we missed from last week (updating Gantt charts etc) and getting ready to go full steam
ahead into the development of the game itself. Now, with a better idea of what we are doing we can
forge ahead and really get stuck in.

We're finally all set to begin development of the project.
All our graphical assets have now been completed, which means we're ready to start developing the
game as of this week. Following the plan on our newly created Gantt Chart, we should have our
game completed over the next 5 weeks, with the remaining time being used for testing and
improving the game depending on player feedback we get during testing. We're still in the need of
some sound assets which will need to be implemented after several of the microgames are complete
however, with what we currently have, this shouldn't do much to hinder our development schedule.
Our main issue at the moment seems to be regarding everything else not related directly to the game
development. We're still missing a few key documents such as our research on Software
Development methodologies and Testing Strategies. I feel we need to broaden our focus a bit using
the Module Mark scheme, just as we had done last week. Otherwise it could mean.
For next week we plan to catch up on what documents and assets we're still lacking as well as begin
work on our QA Plan and have our first two stages for the game completed. It's still a slog to try and
catch up on the time lost in our first week, however I feel it's still early enough into the
development of the project for us to turn around our situation so that we're back on schedule.
Not much to report on this week, as half of our work is still unaccounted for.
I was the only one able to make it in today, as Nathan took ill last night. Unfortunately he still hasn't
uploaded his scheduled workload from last week. He has said that the work has been completed and
will be uploaded later tonight, but for all intents and purposes, until I see evidence that it's been
done, the work can't be confirmed as having actually been completed. This has been concerning for
my lecturer as it seems he was not informed of Nathan's absence and this does mean that we're now
over a week behind on our workload.
As for what I know has been done, I've been successful in completing the first stage of the project
and I've begun work on our Quality Assurance plan for the project. I was surprised at how quick I
was able to get back into programming using Phaser again, even though it's been a couple of
months. It helps that a lot of the basic code for creating/loading levels is already available for me
from the microgames we created during the project prototype. If I'm able to continue working at this
pace, then we should be entirely on schedule for developing the rest of the project in the coming
weeks.
For next week our goal is to finish another stage in the project and to finish our QA plan. I also need
confirmation that Nathan's work load from the past week has been completed. I've sent a message to
Nathan informing him about what needs to be done and our scheduled work load is written on the
Gantt Chart, so he should know what needs to be done for this week. Hopefully my concerns are
addressed soon, otherwise we may need to make drastic changes to the project.

So far so good as work is back on track.
Despite some schedule alterations in regards to the official coursework plan provided on Moodle, it
seems we're on track with getting our work done. Another stage of the project has been completed
and we finally have our documentation from the last week sent in to our Dropbox folder, so we're
now ready to start compiling together our Quality Assurance Plan and continuing our development
of the project. We've also got our music library for the project, with each of the tracks thematically
matching the stages we're creating for the project.
By next week we should have our QA Plan completed and we should have more of the project
implemented. Once that's done, that will bring us one step closer towards the testing stage of the
project, where we will need to start writing up our Testing report for the project, as well as
acquiring user feedback on our project. We will also need to continue our work on the sound effects
library for the project, however that is not a main concern as we're focusing on making sure the
games actually work before we apply any additional aesthetics to them.
Overall a decent week of work, with plenty of work caught up on and a clear cut goal on what we've
got to do next.
Haunted Development - 08/03/16
An interesting day to say the least.
Today marks the launch of the Haunted Development website, a new group group and website
established after team members from The Bone Room have split due to work disputes. Despite
being a rather difficult choice to make, I have absolutely no regrets about it and I know that the
decision made was in the best interests of not just myself, but for the project as well.
Despite having to restart a website from scratch, the game project will continue as it always has
however content will need to be significantly reduced to reflect the change in development. I would
like to stress however, that the project will fundamentally remain the same, regardless of how much
content needs to be removed. I would also like to make note that all resources from The Bone Room
have been transferred over to this website, with all future developments from today onward being
listed under the Haunted Development name.
As for the work that has been done, the QA plan for the project has been completed, which brings
us one step closer toward the testing phase which should hopefully be started within the upcoming
week. Stage 3 of the game has not been completed however, with only 80% of the total games
actually being finished. This is due to an assessment for one of my other modules coming up, and
my decision to take time off to revise for it. Despite this, I aim to make up for lost time this week.
Over the next week I intend to start writing up the Testing document for the project as well as start
user testing on the game stages that have already been completed using the User Feedback
Questionnaire. As for the project implementation, I aim to have the second to last stage completed
as well as catch up on what's left of Stage 3.
With this new development in the team group, I'm aware of the risks that this brings. I'll need to
quickly change my workload to something more manageable for myself and if something goes
wrong, then there's nobody to blame but myself. However, as the group is now just composed of
myself and I'm aware of my own capabilities, I feel that will help push me forward further and
inspire me to work even harder than before and produce better quality work.

Work continues to go well, however my priorities have been misdirected to some extent.
Another stage of the project is completed, which brings the total to 4 out of 5 stages complete (not
including the planned 6th compilation stage). If I continue working at my current pace then I should
be completed with the main implementation stage of the project by the end of this week. Once that's
done I can work on developing the game-flow and compiling all the games together. After that,
there'll only be testing and editing the game depending on what users feel should be changed to help
make the game better.
Last week, it would seem I was misdirected in what I feel should be done. I had initially planned on
starting external testing last week, however that later seemed to be infeasible and would have
caused some clash with my development schedule for creating the stages. This could've made
development rather unfocused as I would be trying to deal with two different workloads at once, on
top of work that I'm doing on other projects. Instead, testing shall be done later once I feel the
project is 'complete' and I the games flow well from one microgame to the next.
As for what's to do this week, I intend to complete the final stage of the project which will allow me
to start combining everything together next week. It would also seem that last week I had forgotten
to amend my project plan in accordance to the group / website changes last week so I shall also aim
to have that completed as soon as possible.
Overall, all seems to be going well with the new changes to development and I still have no regrets
over my decision last week. It may still take a little time to adjust and make the necessary changes
to already completed work, however this shouldn't have any negative effects on the project as a
whole.
Not much to report on as work continues at a steady pace.
The final stage of the project is nearly complete with 9 of the microgames completed out of 12.
More would've been done, however over the past few days there has been technical issues as my
laptop screen broke and is currently being repaired. Unfortunately this has left me without access to
the software I need to continue work on the project.
My lecturer has suggested using a laptop loaned from the University's library which, while a sound
idea in theory, upon investigation turned out to not be a feasible option as I'd only be able to use it
within University grounds and only for three hours. Given how unlikely it'd be that the laptops
would have the necessary software, requiring me to need to spend some time setting them up, my
only option is to work on other projects and documentation while I wait for my laptop to be
repaired. Fortunately repairs shouldn't take too long, so I should have access to my laptop again
within a couple of days or so.
Throughout the next week, I plan on having the game flow completed for the project which will
include microgame compilation, creating the timer and the HUD. I'll only work on applying it to
one of the 6 stages so that it's easier to test and change. Once that's done, all I'll then need to do is
use the same code for the different stages, which won't take long at all.
Overall, progress on the project is continuing steadily in a positive direction. With the project
nearing it's initial completion, I'll be able to properly start testing the project and being able to finetune it to being a more enjoyable and entertaining experience.

Once again, there's not much to report on as progress goes swimmingly.
Shortly after last week's meeting with my lecturer I received a message from the repair shop saying
my laptop had been fixed, which fortunately meant that I lost little to no progress last week. Since
then I've been able to create the Game Flow for individual stages which includes compiling the
microgames together and implementing the HUD and timer. This turned out to be a lot easier than I
had anticipated so didn't take too long to create. With individual stages now being complete, I'm
now able to start testing and editing the game in accordance to the feedback I receive from users.
The only major concern I have thus far is a perceived decrease in game performance once
everything is put together, as there are a multitude of different images and files that are being loaded
at the same time. This, however, is only a perceived concern and may not actually come to pass, and
even then is only something I can deal with if and when I encounter it.
I've still yet to have a complete sound library, so I will need to work on that over the next week now
that I'm fully confident in the implementation. I'll also need to work on other parts of the game such
as the World Map, the Story Elements as well as applying the Game Flow to other stages in the
game, however I can't perceive any difficulties that may occur.
Overall, progress is continuing at a great pace and coming ever closer to completion. It's really
encouraging to see the game reaching a playable state after several months spent planning and
visualising the project, especially after the rifts in development created over the past few weeks.
With work continuing as it is, I can't see there being any problems with the project and I am fully
confident that I will be able to release a stable, entertaining and challenging game.

Once again, the project continues at a steady pace and comes ever closer to completion.
After a week-long break for Easter, I've been able to get more work done between blog entries than
before. I've been successful in completing and applying Game Flow to 3 more additional stages for
the project as well as designing and creating the main stage-hub area for the game. Unfortunately,
due to a software malfunction on my laptop I was out of work for a couple of days which did mean
I was unable to complete as much as I was intending to. However, I feel I've still more than enough
time to complete what I had intended to do before the due-date in a few weeks time.
Over this week, I intend to have more testing done on what I've completed as well as having a full
build of the project ready and playable as well start my write up of the testing process for the
documentation. After today's meeting with my lecturer, it's been apparent that I don't need to
develop something that's 100% bug-free as there's no time. However, I need to write up the issues
that have been brought up during testing and work out what is essential and non-essential for the
project, with me correcting the essential problems that the game has.
This has left me more at ease with the project, as it does mean I've not got to be 100% perfect in
order to get a good grade. I just need to be aware of the issues that are present in the game on
release and fix any serious errors.
I've noticed that I've been seriously neglecting some of my other modules for my final trimester by
putting almost all my time into creating this project. With this new assurance and with the project
almost complete, I'll be spending more time catching up on what needs to be done for other
modules than for this one, but that's not to say I've no intention of completing what I've set myself
to do.
Overall, I'd say things are looking good for the project and I'm confident that it'll turn out great.
However, I do need to focus on doing some of my other work for other modules or else whatever
grade I get for this project will be for nothing.
A week to go until my submission, and everything's looking on schedule.
I've finally got a completed initial build for the game uploaded on to the website. Much to my
delight, there are no performance issues regarding loading the game assets, which means the whole
game is now playable! I did have to stop development on one of the stages, meaning there are only
five stages available as opposed to my planned six. Given the amount of work it would have taken
to get the fifth stage completed and tested, it would have meant I'd have no time to polish the rest of
the game, so in the end I had to scrap it so that I may put my efforts into more important areas.
This will be my last week of User Testing to identify any last few remaining bug that need to be
ironed out, and then once that's done I'll need to work on my project presentation as well as getting
all my documentation in order. It'll be a tough slog as this and my other assessment will give me a
lot of writing that I've got to do for this week. But I suppose it would make a welcome change from
all the programming I've been doing for the past couple of months.
I'm really proud of my project. It's been a joy to come up with a game concept from scratch and see
it through to it's end. All that's left is to finish off and wrap up all the documentation into one
singular file, work on giving a good performance to demonstrate what makes my project stand out
and to finally see off my project by submitting it all on disc to my lecturer. I hope there's nothing
that gets left out and all my hard work ends up for nothing...

Trimester 2 - Documentation

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Trimester 2 - Documentation

Enviado por

Direitos autorais:

Formatos disponíveis

Haunted Development

6. Project Meeting Minutes

1.3. Gantt Chart

1.4. Risk Analysis

3.4. Level Creation

3.5. Bug Fixing

5.3. Feedback Implementation

Change instructions for some games

Change instructions for some games

Stop stages repeating

5.4. User Testing Log: Stages

Was it clear what your goals were during the game?

Did the controls feel intuitive?

Did the gameplay feel consistent?

Did each microgame stand out as a unique challenge?

Do you feel the game is presented well?

Is there anything you would like to see changed?

What was your overall experience with the game?

Was it clear what your goals were during the game?

Did the controls feel intuitive?

Did the gameplay feel consistent?

Did each microgame stand out as a unique challenge?

Do you feel the game is presented well?

Is there anything you would like to see changed?

What was your overall experience with the game?

Was it clear what your goals were during the game?

Did the controls feel intuitive?

Did the gameplay feel consistent?

Did each microgame stand out as a unique challenge?

Do you feel the game is presented well?

Is there anything you would like to see changed?

What was your overall experience with the game?

Was it clear what your goals were during the game?

Did the controls feel intuitive?

Did the gameplay feel consistent?

Did each microgame stand out as a unique challenge?

Do you feel the game is presented well?

Is there anything you would like to see changed?

What was your overall experience with the game?

5.5. User Testing Log: Full Game

Were there any notable errors during the game?

Was it clear what your goals were during the game?

Did the controls feel intuitive?

Did the gameplay feel consistent?

Did each microgame stand out as a unique challenge?

Do you feel the game is presented well?

Is there anything you would like to see changed?

What was your overall experience with the game?

Was it clear what your goals were during the game?

Did the controls feel intuitive?

Did the gameplay feel consistent?

The Difficulty varied per micro game.

Did each microgame stand out as a unique challenge?

Do you feel the game is presented well?

Execellent music, poor tutorial.

Is there anything you would like to see changed?

What was your overall experience with the game?

Positive bar lack of expaination and tutorial

Was it clear what your goals were during the game?

Did the controls feel intuitive?

Did the gameplay feel consistent?

Did each microgame stand out as a unique challenge?

Do you feel the game is presented well?