William Maber

Testing Methodology
I tried the video game by myself, but I did have a team of people from my level 3 ICT course giving me support; their names
are Peter Norton-Spinks, Jackson Fordineo and Peter James. I also had a group of Beta Testers who also helped me through
the test, who gave me ideas and feedback, without looking at the code.

I incorporate both white box and black box testing!

The white box testing is where the developers test the code. They have access to the code to get a lower level of what
problems are going wrong with the program. This will speed up the process because this is a faster way to debug software
than black box testing, but can lead to corner cases being missed more often, and therefore more bugs getting through the
process to the Beta test (also known as Black box). This is down to the amount of code and tests which can be performed by
the limited user base for the software white box testing. White box testing can be used again, after the black box testing, to
get at the problems which are found at the black box test. This helps to work out the main problem(s) of the software. This
makes it easier to be fixed later on.
In this project, I use Game maker debugger and Game maker IDE to find bugs in my computer game. These have different
ways of guiding you to the bugs. One does it statically and the other one does it dynamically when the code is executing.
The static method finds errors which the dynamic one will also find, but the static one will find it more quickly, as you do not
have to run that bit of code to find the error. However, the static one does not find all the errors unlike the dynamic. Game
maker debugger will let you single step through code, to find where the error is. This allows you to work out how you can fix
it move quickly.
There is no need for knowledge of the code for black box testing. This is usually done by external people who are testing
the game, or by people who have actually brought the video game and have found bugs in the video game. They love
reporting them, but they can't see the Source Code (and probably can't be bothered with Source Code anyway). These
gamers will not have any idea where the actual problem is in the code, meaning that developers might have to do extra
testing to find out what the bug(s) problem(s) is. This could be a bigger problem if the bugs that have been found by the
gamers are not documented well, and this stems from a misunderstanding of the information which has been given.

William Maber
I will be creating a testing plan questionnaire to find out information about the video games, and analyse it, later on, to find
out what future improvements I can make for the video game. This will include asking what does not work and what works in
the video game, in turn, this will also allow me to find out what other people think of the video game and how it can be
improved. Other aspects to test in my video game include Navigation, the non-human playable characters, and The
Aesthetics of the video game along with other things which could be important.

Alpha Testing
Moving the project from College to home, so I could carry on working with it caused a number of issues: I got confused in
which was the latest version of the project that I was working on? This led to multiple different versions of the project being
made, with different Features (and bugs) being in each version, spread across the two locations.
I overcame this problem by sitting down to work out which versions of the project I needed to merge together; and-and which
versions were the most current project versions. This allowed me to create a new Game project ready for the submission
date.
The video game Collision detection showed up an intermittent fault. The primary glitch was that the player could get stuck
on the walls. In attempting to overcome this bug, I then found the player could walk through the walls. I had not resolved
the bug but created a new one too. This was a major problem in my code and was a problem that could make the game
worthless as it would be a game breaking Bug
I overcame the problems with my computer game by using the debugger (using Yoyo Game Maker). I was able to work out
where the problem was in my code and to fix it. This took me multiple times to try and figure out what was causing the
problem, and what will be the best way to fix it.

William Maber
The video game did not allow the players to see to the next level (room). This was down to the fact that I thought that I
implemented code that I had not yet implemented; leading me to confusion, as to why I could not proceed to the next level
when I was trialling the game. I realised that I had misunderstood how the next room functionality works in game maker. I
was then able to overcome this by working around the problem by trying different combinations of subroutines in GameMaker
until I got the right combination to get to the next room.

Sometimes the screen was too dark to effectively follow the game. This was caused by a combination of the scene being
designed to be in near darkness, but the lighting system also crashed, causing the game to crash completely. I didn't know
how to make the lighting system work in game maker, but after looking through the different references in GameMaker docs,
I found a set of draw functions, which I thought would help me. So I tried them in a different order to work out how they work
- I had many different errors, but finally I found the right combination. I learnt about the overlays in Game Maker and decided
the best way was to use the alpha channel to make it transparent, so you can see what's right underneath it in certain areas.
The projectiles were static on the screen, and not travelling in the intended direction. This was not how the Projectiles were
supposed to behave. The Player can be rotated, I am then able to use the direction the player is facing to aim the projectiles
in that direction. This overcame the problem of having static projectiles when the player is moving, unfortunately, it will not
sort the problem out when the player is not moving. This should not be a serious problem to put right.

At the beginning, there was a problem with the video memory running out, because the game was creating tonnes and
tonnes of entities in the game procedurally. I overcome this error by finding that the Wizard character was creating loads and
loads of (spawning) Magic missiles. This created a massive load on Memory which was causing the game to slow down and
crashed the program. Having understood the problem, I was able to write in some If statements, which have cured the
problem.

Beta Test

William Maber
Test

The Dream Result

The Real Result

1st Test

Does the game open

The game loads with no

Error
Pressing Up Key moves
player upwards

The video game

opens correctly
The arrow key
moves up the
character
The arrow key
moves down the
character
CPU usage is 29%,
therefore, less than
40%

No need for
follow up
No need for follow
up

Add fps counter

Fixed Press F8 to
show FPS counter
No need for follow
up

The Up arrow key moves up

The Down arrow Down
moves down

Pressing Down Key moves

player downwards

Look in task manager for

CPU used

Cpu less the 40 % used

FPS

Game run at 60fps or better

Fps is better than

60fps

The Left arrow moves Left

Pressing Left Key moves

player to the left

The Right arrow moves

Right

Pressing Right Key moves

player to the right

The left arrow key

moves the
character left
The left arrow key
moves the
character Right
Right click can kill
an enemy as
intended

Test that you can Kill the

enemies variously with
either right or left mouse
click. Use mouse to aim
any projectiles

Using right mouse click, and

arrow keys if needed, You
should be able to kill
enemies.
Using left mouse click, and
arrow keys if needed, You
should be able to kill
enemies.

Right click can kill

an enemy as
intended

The Real
Result
2nd Test
(Follow-up)

What I Need to
fix it (if
needed)

No need for
follow up
No need for follow
up

No need for
follow up
No need for follow
up
No need for
follow up

William Maber
Can the enemies kill the
player?
Test scoring works when
killing the enemy?

The Player character dies

within about 10 seconds of
undefended enemy attack
The Players score increases
by 4 every time an enemy is
killed

Does the level exit take

you to the next level?
The Final Exit informs the
player the game is finished

Level Exit takes player to a

new level
The Final Exit should reset
the game

Test if the enemies chase

the player

Enemies chase the Player

when within a predefined
radius of the Player
I think the game is fun. No
need for improvement.

Do you think the game is

fun? If not why?
Is the Game balanced?
Does the Player versus
enemies challenge have a
realistic potential for win
or lose?
Test the Heath bar of the
player
Collision Detection: Can the
Player walk into a wall, but
not get stuck at, or pass
through the wall?

Can be killed within

10 seconds

No need for follow

up

The score works

differently on
different systems.
This is down to
different versions of
GameMaker
Works as intended

Define and
implement a
health score
instead

Shows the "you

win" dialogue
window over and
over again
Works as intended

No need follow-up
works
Need to send
player back to
room one
No need for follow
up

I think the video

game is fun

Too opinionated,
follow-up on

The game is balanced.

Works as intended

No need for follow

up

The Health goes down when

the Player is being
successfully attacked or
killed by enemies
The Player can continue to
move in any direction, but
only within the confines of
the walls

Not showing heath

bar.

Define implement
a health score
instead

You can walk into

walls and get stuck
in them still

Requires editing
of Sprite images
to provide a
smoother

William Maber
horizontal crosssection, inc' for
Wizards hat
Does the Menu work?

Test New game from the

Menu
Does the Camera move
with the player?
Test Exit form the menu

Observe, is the Overlay

black over most of the
screen?
Does the game work on the
computer that you're
running it on?

The Menu works, with

New, Load and Exit
functioning as designed
A new game is loaded,
ready for the Player to play
When the player moves, the
Camera moves to follow the
player. The player is always
in frame.
The Game is closed, and
the Player becomes merely a
computer device user
Is the screen mostly back
with a transparent circle
depicting the area where the
Player is located
The Game works well on the
College computers

I cannot find the

menu

Implement a
game menu

I cannot find the

menu
The camera move
with the player as
expected

Implement a
game menu
No need for
follow up

The menu wasn't

there so they're exit
button will not be
evaluated

No need for follow

up

Work as intended

No need for
follow up

Yes!

Good result, but

test on different
platforms

William Maber

Rate the game out of 10/6

Testing Evaluation
My test results show that the descriptions in my Game need improvement because they can be quite misleading at times. A
lot of people did not know what to do in the video game, including how the tests work, and some people did not know how to
open their FPS counter (which, in error, Ive missed out from software testing). The test results show that the menu wasn't
working properly, as it was sometimes not showing up at all. It was not able to be accessed by any of the users who have
tested the program. An additional test that failed was the health bar on the video game, as this was not Showing an onscreen tool leading to the play, and not displaying how much help the player / user has left. This is a bug in the computer
game and is an important feature to the functionality and value of the game.
100 percent of Testers said the video game opened. This shows that the video game is working as intended in the section.
This is also meaningful, as all the other tests are valid as they could be carried out with a positively started game running.
This means that the tests could be carried out efficiently and it's ready to be tested to its full ability.
The game controls (arrow keys for movement and mouse buttons for firing projectiles) work as intended. This means the
player can easily navigate around the game, and turn around to aim weapon projectiles, and move in the opposite direction;
allowing the player to have a wide variety of possibilities in the video game. There is a good range of actions that they could
do.
The CPU usage was 29%, and so was the 40% maximum figure, allowing the program to work correctly on multiple different
systems. This shows that the program, which has a high performance, is compatible with modern computers. This means
the program should run at an acceptable performance on my own computer. This is a good thing as the video game was
written for a target audience with higher performing device types. This will allow the program to work at a decent
performance, and even players with older designed computers, with slower processors, should be able to play this at a
reasonable speed, without impairing their motion in the shooter game world, irrespective of the limitations of their computer
system. The game should be transferable to other platforms.

William Maber
Unfortunately not a lot of feedback was given on the FPS of the video game. This might be down to a lack of clarity in my
instructions. This could be fixed in the future by adding Advice on the refresh rate (60 fps) to be seen in the video game. I
have decided to also add an fps meter to show after hitting Function key 8 (F8). This will allow players to more easily
navigate to it. Incidentally, this has some similarities with the information available on Minecraft.
Both of the left and right mouse clicks work as intended, and the player could effectively aim and fire projectiles. I have
checked through the testing documents that all the tests were able to carry out successfully. This meant that the combat
features were implemented correctly in the video game and that I do not need further work to create new features to make
this work correctly. This is a positive feedback confirming this part of the game was ready for playing / delivery.
The feedback shows that the enemy can kill the player. This allows the players to have something to fight against to get to
the end of the level and makes it a fun and interactive experience. There is potential to extend their enemies by adding
different sorts of enemies, that can do different sorts of attack, based on some inputs that the player can do, or, for
example, a long range attack might be a good idea for an enemy, that could be extending the video game.
Unfortunately, the GameMaker didn't keep track of the score very well as I had used an internal function. This was reflected
in my feedback. This is down to the fact that the x-coordinate fixed the full score in the GameMaker version used at College.
Whereas the GameMaker version I used at home didn't do this for some strange reason. This could be down to the different
versions of GameMaker that I used at home and at College. Differences between the two versions of GameMaker could have
led to numerous other bugs in my video game. Fortunately, to date, there has been no evidence of further bugs caused by
using the two different versions of GameMaker.
The level Exit takes you to the next level when you step on it. This is a good thing, as this means the video game is working
as intended and is ready to be played by the masses. There were no further comments about this feature, and there's
nowhere for me to improve on this feature. Therefore, no additional modifications to this part of the program are needed.

William Maber
The videogame Exit also worked as expected: As the players leave the video game, they are informed they won the game, as
I intended the video game would do. Unfortunately, the video game did not send the players back to the First Level. This is a
small bug in the program and could be easily be fixed, but it did tell the player when (if) they had won the video game, and
that an important thing to do in the video game is.
The enemies chase the player when the enemy is within a predefined distance from the player. This was intended to work
like this. This is designed around the player's ability to fire at, and to fight the enemies. The player has a choice whether or
not to access the enemy at close range. However, the player will discover that their power is cut back when they get to
within a certain distance from the enemy, to make sure the player fails if they get too close to the enemy. Therefore, the
Player may decide to get away from the enemy if the player does not want to use their abilities to fight. In the video game,
this allows a Real Player to strategize how best to be able to complete the level. I have developed the level of this ability
expansion, by adding extra parts to the level after updating the video game.
The collision detection meant that players could get stuck at the Wall under certain circumstances. This is down to me in the
alpha testing. I did not anticipate the degree this would affect the game so much, but it has turned out that the game was
really affected by having the players get stuck in the Wall! This would mean players would not make a good recommendation
to friends who otherwise would like to play the Game. There are a number of possible reasons, but the most probable cause
of how the Wizard gets stuck at the wall is due to having different dimensions, when looking in different directions. This is
because when the Wizard turns right, his hat can get stuck in the wall. This is only a minor problem with the collision
detection, and I can change the Wizards hat design so it is not so prominent in one direction. This should fix the overall
problem.
The camera follows the players character as intended in the video game. This shows that the program was working correctly
in this regard, and I do not need to update it to be improved in a later version, to have this functionality. The Black Overlay
through which the camera is able to pierce through to follow the illuminated player character works as intended In the
Videogame Specification. The resultant effect is that both the camera and a moveable spotlight follow the player.

Bugs and shortcomings

William Maber
I would not have been enabled to identify all these bugs and gameplay problems so quickly without the support and feedback
from Beta Testing (thank you all concerned). For example, the collision (stuck to wall / able to pass through the wall) bug was
found to be a lot worse than I thought it was in the game Alpha testing. The collision fault happens a lot more often than I
would have expected, making it a bigger bug than anticipated. Having the main menu not show up is also a bug in my video
game but does not take away from how the video game plays and finishes.
My test plan tested out most of the aspects of my video game that I had implemented. This means that all the possible
functionality had been tested with the video game, meaning I had a complete test plan. This has led to black box testing
finding bugs that I did not know about, and showing that what I had hoped were minor bugs, are, in fact, major game
breakers - picked up by the play testers.
More bugs were detected from Black Box Testing, as I had anticipated, in this testing phase. There were also some additional
bugs which were unexpected, such as the collision detection (where the Wizard player character could get stuck to the
walls), and will have to be patched by creating slightly different / modified sprites for the video game; or changing the
"pushing" code to take into consideration the dimensions of the sprite. Also, the FPS and the Health points were not showing
properly.

Testing Recommendations
One of the Beta testers mentioned my Sprite, for my Wizards animation was not complete, as in some places the game
characters became a static image.
I believe this is for when the character moves. I will change my Wizards Sprite to add this animation into the system, so it
does not look so robotic when he's moving in that particular Direction. I will do this using Piskel as it is a software which I used
to create animated sprites in the first place, and this will allow me to create more sprites of the same quality to fill out the
animations. This will make it look like you're walking in the game and improve the game drastically, as it will give you a
better immersion into your game world.
The Beta tester Peter James said it would be a good idea if you were able to close the screen which allows them (the player)
to be notified that they have won the game. I could use GameMaker to enable this.

William Maber
The health bar could not be seen, and was not working. I would have to make the HUD (status bar) on the screen to support a
health bar to describe the players game character health. This will be done and placed alongside their current player score.
I could do this by drawing the health bar onto the screen by using GameMaker functions in the Gamemaker markup
language.
I can fix the scoring system mentioned previously by making it a global variable, and not using GameMaker's internal scoring
system. This became an issue of the score increasing based on the players positions in the video game. This is necessary
because of the different scoring systems between different versions of GameMaker. Using a global variable would overcome
the broken functionality caused by using two different versions of GameMaker. This shortcoming was mentioned by many of
the Beta testers - some commenting that this is not working properly, and some just left it as blank. This was noticed and
commented upon by Jackson Fordineo.
Most of the Beta testers said that the main menu wasn't working in the video game. The video game menu was not working
in this implementation. I would have to go into GameMaker code to work out why it wasn't working. I would have to use
Game markup language to implement a game menu that will see a high specification. To create a GameMaker menu, I would
have to create a room that contains the menu options, and describe the ways to describe a menu along with an object which
would implement the menu overlay.
How the Project has evolved
The Game Program is now pretty much as I first envisioned it. I had to slim down some of my original plans, to fit in with the
assignment time constraints. This particularly included less refined player character and enemy graphic quality. I had also
wanted to incorporate more advanced, a lifelike movement to the game characters, together with dynamic sound effects. I
dropped the player characters, Knight and Archer, also due to lack of time. Giving the player a choice of characters with
different attributes, requiring different gameplay strategies would improve a future version of the game. During the project,
Ive realised that adding in a menu would be a good idea, but would have needed more time to implement and test.