OCR GCE A

COMPUTER SCIENCE PROJECT

H446-03

Name:

Candidate Number:

Institution Name:

Centre Number:

Title of Project: Frog Game Project

P a g e 1 | 70
H446-03 – PROJECT CONTENTS
Table of Contents
Analysis: .............................................................................................................................................................................................. 3

Problem Description: ...................................................................................................................................................................... 3

Stakeholders: .................................................................................................................................................................................. 3

Justification: .................................................................................................................................................................................... 3

Research:......................................................................................................................................................................................... 5

Evaluation of Research: .................................................................................................................................................................. 7

Features: ......................................................................................................................................................................................... 8

Hardware and Software Requirements: ....................................................................................................................................... 10

Success Criteria: ............................................................................................................................................................................ 10

Limitations: ................................................................................................................................................................................... 12

Design: .............................................................................................................................................................................................. 13

Structure Diagram: ........................................................................................................................................................................ 13

Usability: ....................................................................................................................................................................................... 15

Key Variables: ................................................................................................................................................................................ 17

Class Diagrams: ............................................................................................................................................................................. 17

Development Testing Plan: ........................................................................................................................................................... 18

Algorithms: .................................................................................................................................................................................... 19

Development Story: ......................................................................................................................................................................... 21

Week One: .................................................................................................................................................................................... 21

Week Two: .................................................................................................................................................................................... 24

Week Three: .................................................................................................................................................................................. 26

Week Four: .................................................................................................................................................................................... 27

Week Five:..................................................................................................................................................................................... 28

Week Six:....................................................................................................................................................................................... 29

Week Seven: ................................................................................................................................................................................. 31

Week Eight: ................................................................................................................................................................................... 34

Post-Development Testing: .............................................................................................................................................................. 38

Evaluation: ............................................................................................................................................ Error! Bookmark not defined.

P a g e 2 | 70
Analysis:
Problem Description:
The game is going to be a platformer like the Super Mario platformer game, where the player (as a frog) must
navigate the screen by jumping across platforms using the keyboard, avoiding hitting enemies that will make them
lose health, and eat enough flies to meet a certain requirement before the timer runs out in order to complete the
level. Once the player completes the level, the next level has a different layout and the number of flies required to
complete the level will potentially get bigger in order to make it more difficult, or the layout of the level could
become more difficult to navigate, or the timer will be shorter. When the player wins by consuming all of the flies in
the set time, they will be greeted with a screen that says ‘You Win’, however if the player loses and fails to consume
all of the flies in the set time, they will be presented with a screen that says ‘You Lose’.

In the game, I could potentially create multiple game modes once I have completed the initial game; for example, a
common mode in videogames is a mode where you can see how many enemies can be killed (or in my instance –
how many flies can be consumed) in a fixed amount of time.

I think that problems that I will encounter in this process are going to be having to create the different graphics and
corresponding methods for each (e.g., the player and their movement) and having to create a fully functioning menu
system. I also think it will be difficult for me to create the different platforms and have them work correctly (without
the player accidentally entering the actual platform and treating it as a solid object).

Stakeholders:
My game is going to be a level-based platformer, and it’s a game that would potentially appeal to anyone, therefore
my stakeholders are going to be my younger siblings Chloe and Josh (as they are representative of the younger
demographic for videogames) and Charlie, Alfie and Cameron (as they are representative of the teenage demographic
for videogames). Another stakeholder will also be my mum, who is representative of the older demographic for video
games, moreover my mum is a teacher at a primary school and therefore she could also approach the game from the
perspective of a teacher of young children, and give me feedback on how to make the game more appropriate for
much younger audiences.

Charlie, Alfie and Cameron will be able to advise me on what I could potentially do further as computer science
students, which will allow me to develop my program even further and improve certain aspects which they consider
to be not user-friendly or difficult to use. They also play different video games and could potentially enjoy the video
game too. My younger siblings are also interested in platformer video games and may also enjoy it and will be able to
tell me what adjustments can be made.

Justification:
Thinking Abstractly & Visualisation:

P a g e 3 | 70
 • My program is going to be a game and it’s intended purpose is to be fun and entertaining. The details that are
important include: the platforms, the players, the enemies, the flies, gravity and a timer. Details that can be
abstracted during early development include potential textures, music and sound, potential movement
animations and an aesthetic menu.
• The platforms are a very important feature in the game because they dictate where the player can go to and
where the enemies can appear, and create the layout and structure of the level.
• The player is also a very important feature because the player needs to obviously control a component of the
game to play it playable.
• The flies are important too as they are what the player collects in order to complete the level and win.
• Gravity is vital too in a game where a player needs to navigate the x and y axes because when the player
jumps, they must come back down otherwise it’s unrealistic and would remove one of the game’s primary
challenges.
• A timer, that will also be very important because it dictates when the game ends and determines the level’s
length and the difficulty for the player.
• One of the features that isn’t contributary to my game’s functionality is the textures, music and sound, all of
which can potentially be added following the completion of my game’s primary code.
• Another feature that isn’t vital to my game is potential movement animations as they’re merely for the
aesthetics of the game as opposed to having actual functionality.
• The menu where you select levels and potentially adjust settings can also be abstracted and reduced regarding
the quality of the graphics and aesthetics as they don’t contribute much to the actual gameplay and working
of my code.

Thinking Ahead:

• One of the inputs will be navigating the x axis using the ‘A’ and ‘D’ keys or alternatively the left-arrow key and
the right-arrow key, allowing the player to go left and right.
• Another one of the inputs will be navigating the y axis using the ‘W’ and ‘S’ keys or alternatively the up-arrow
key and the down-arrow key, allowing the player to go up and potentially crouch. The mechanic of gravity will
pull the player down the y axis once they’ve jumped.
• Another potential input that will be required is an interact key that will shoot pellets or execute an action that
harms enemies (which I may have set as the ‘E’ key).
• I have chosen these specific key sets because they are the most common ones that are used when playing
videogames, therefore the controls are much easier for the player to use.
• Potentially, I could have a key (most likely the ‘Esc’ key) which will allow the user to access the menu within a
level and click the ‘Exit’ button to close the game window.

Thinking Procedurally & Decomposition:

• The main program can be broken down into many smaller steps and sub-programs that are all independent of
one another and can be called multiple times and reused wherever they need to be.
• Examples include:
o The menu function: It can be called at any point during the game, and therefore can act as a
subprogram outside of the main game.
o The sprite movement: The constants of the movement keys won’t change at all during the program,
however will be used throughout the program, and therefore can be in its own function (potentially
coupled with any sprite movement animations (e.g., moving left and right could have running
animations)).
o Loading a new level: The loading of a new level will be the same, however the layouts of each level
are different from one another, therefore loading can have reusable code, with the variables within it
being the layout of the level.
o Prevent walking into platforms: During the levels, the player will be unable to walk into and enter the
platforms and can only touch them without going into it. As this is going to be used in the different
levels, this can be created in a subprogram and can therefore be reused for each level.

P a g e 4 | 70
 o Loading the flies and enemies: I plan on using OOP for this section of the program which itself can be
embedded within a sub-program and can generate the flies and enemies. The flies all have the same
code, as do the enemies have the same code, therefore it can be reused and called upon multiple
times to create them in the different levels.

Thinking Logically:

• The program will have many key decision points which will proceed to run different sections of the code both
in the menu and in the actual game section of the code.
• Examples include:
o The menu: The user can decide whether to click ‘Play’ (which will load the different levels in a table
for the user to select one and then play it), or whether to click ‘Exit’ (which will close the game
window).
o The level selection: The user can select from the levels that are on the screen, the level that they want
to play and then the game loads that particular level.
o The end of a level: When the user reaches the end of the level, the program has to close to level,
displaying results, and takes the user back to the level selection menu.

Thinking Concurrently:

• Parts of the program that will occur simultaneously include:

o Music and Sounds: The music and sounds (if I add them) with correspond with the different sections
of the game, e.g., the menu, the levels, and potential movements (like a running sound that plays
when the character runs).
o The entities in the game: The character and the other entities (the flies and the enemies) will all be
moving at the same time around the level.
o The timer: The timer will be going up/down constantly throughout the level until it ends/reaches
0/reaches max.

Why use a Computational Approach?

The program that I am creating is a videogame with various graphics, sounds and mechanics that are unachievable in
a format that’s not on a computer. This game wouldn’t be able to be a board game because of the various components
in the game (like the moving sprites and challenge of moving your character). Video games are also very popular forms
of entertainment today, and creating a videogame contributes towards this.

Research:

Considering that one of the key components of my game is that the frog jumps across platforms to collect flies and
avoid targets, a few potential games to research include: Super Mario and Doodle Jump.

Super Mario:

• Platforming:
Super Mario is a platforming game, and my game is also going to be a platformer, a game that revolves primarily
around a character being controlled by a player moving along the x-axis and y-axis across platforms to complete a

P a g e 5 | 70
 task. In Super Mario, the aim of a level is to get from the left side to the right side, collecting coins and killing
enemies without dying, however in my game the aim is to navigate a fixed area, collecting flies and avoiding being
killed by enemies. Super Mario is a platform game known as a ‘scrolling platformer’ where the scene moves as the
character moves from left to right, however the game I plan to create is going to be a ‘single screen platformer’
which is static and doesn’t move.
• Movement:
The character movement in Super Mario has two main movements, being running and jumping. Jumping as a
mechanic requires gravity in order to have characters and certain elements fall. In Mario Bros, there are also more
complex elements, like high jumps, skidding, long jumps, wall jumps, etc, however the game I plan on creating is
only going to have simple jumps (with mechanics that go up and down every time you press the up arrow or the
‘W’ key depending on what keys I choose). Mario Bros also has a mechanic where when you walk (using the ‘A’
and ‘D’ keys or the left and right arrow keys) for around 1.5 seconds, the speed increases and you run instead and
you can jump higher, and in my own game I think that I might also use this mechanic of running.
• Enemies and Entities:
Mario has a variety of different enemies and entities that you can interact with, all with different designs and
abilities (e.g., a Goomba which is the brown mushroom-like enemy that you can kill by jumping on it or hitting it
with a shell, or a Koopa Troopa which is a turtle-like enemy that you can jump on and will retreat into its shell,
which you can then utilise by picking it up and throwing it).
My game is also going to have enemies, however I don’t know yet if I will have different enemies with different
abilities, or just a specific enemy that’s present throughout the game). In Mario, the player character has different
stages which act as a health bar of sorts, where in which if you have a special ability, you lose it when you come in
contact with an enemy (as if you lose a life), and in my game I am simply going to have a health bar of perhaps
three hearts, and when you come in contact with an enemy, you will lose a heart and then have invincibility for 3
seconds to prevent all three hearts going down instantly when you encounter the enemy. In my game, I might make
it so that if the frog jumps on the enemy, it will kill them, but I am yet unsure of how this would work.

P a g e 6 | 70
Doodle Jump:

• Game Window:
Doodle Jump is a mobile game and loads with a game window to display the actual game and allows you to interact
with it through the phones touch screen mechanics. Doodle Jump uses JavaScript, however I am going to be using
python to create my game which has a different syntax and rules for creating a game window.
• Wrap-around:
In the game Doodle Jump, when you jump off the left or right side, the player appears on the other side of the
screen, known as a wrap-around mechanic. In my game, I don’t think I am going to have this feature as it could
potentially cause problems and could allow the player to cheat, depending on the layout and composition of the
level.
• Combat:
In Doodle Jump, when you tap the screen, the player shoots pellets which go in a straight line at the angle you’re
pointing to hit enemies, and when they are hit by a pellet, they take damage, and hitting them three times will kill
them. Potentially, the frog in my game could stick its tongue out in the direction the frog is facing to hit enemies
so that they take damage. Moreover, when you encounter an enemy in Doodle Jump, you die immediately,
however in my game if you contact an enemy, you could potentially lose a heart and take damage.

Evaluation of Research:

I think that the research conducted into Super Mario and Doodle Jump will be very valuable in the designing of my
game, as there are many key features and functions in those games that I plan on incorporating into my own game.
For instance, like the Super Mario platformer game, I am going to be using similar platforms and the platform
navigation, and I am also going to include similar movements like the Mario game, including jumping, and running left
and right. However, unlike the Mario game, I do not plan on having complex movements like crouching and triple
jumping, as they will prove to be overly complicated and unnecessary in my game. For my game, I also plan on
implementing enemies and hostile entities, similar to those that are found in Super Mario with fairly similar
characteristics and attack patterns. However, the Mario game has a lot of different enemies, all with different abilities
and attacks, but my game is going to only have one or two different enemies with different attack patterns. Moreover,
like the Mario game, I plan on the player being able to kill enemies by jumping on their heads to kill them.

From the Doodle Jump game, I plan on also implementing a game window which is a necessity for video games as it
displays the actual graphics for the game, which allow the user to interact with game visually. Doodle Jump, however,
has a wrap-around screen, where the player can go off the left side of the screen and will emerge from the right side
of the screen, and my game is not going to have this feature, it’s going to be a fixed screen and the player will not be
able to go off the left side and emerge from the right, as it could have potential detrimental impacts on the game’s
logic, and may allow the player to ‘cheat’ and reach areas of the level that they need to work to reach. My game – like

P a g e 7 | 70
Doodle Jump – may also have a feature where the player can attack the enemies, however in Doodle Jump the player
shoots pellets at the enemies above them, and in my game, the player is going to able to stick.

Features:

Features: Details: Priority:

Jumping – Gravity – Gravity is an important Jumping is a key mechanic of platformer games and
force in jumping because it brings is a vital component to my game as it allows the
• Gravity entities back down to the ground. player to navigate the levels. Gravity and direction
• Direction are two very important features that impact on the
• Graphics Direction – The direction of the jump code’s functionality; however, the graphics aren’t
will determine whether the player impactful to the code itself, and merely contribute to
can move there (e.g., there could be the game’s aesthetics.
a wall there, in which the player
would fall to the closest platform
beneath it).

Graphics – Potentially, there will be

a graphic to jump where the frog
extends its legs to jump.

Platforms – Ground / Top of Platforms – The Platforms are key features in platformer games and
ground needs to be solid for an are vital for gameplay. The player interacts with the
• Ground entity to walk on without fazing level layout and surroundings, jumping on top of,
• Walls through it. going under and traversing the different platforms to
• Ceiling reach the end of the level or achieve a certain goal.
• Layout Walls / Sides of Platforms – The walls The platform functionalities (e.g., interactions with
• Graphics of platforms need to be solid so that the other entities on the ground, as walls and as a
an entity can hit them by running at ceiling) will be most likely embedded in the code of
them, being unable to faze through each entity, rather than in the code of the platforms,
it. and this is very important for gameplay and the
overall functionality of the program, however the
Ceiling / Underside of Platforms –
graphics can be implemented later in the
The underside of platforms needs to
development process if they need to be (to be
be solid so that an entity is unable to
aesthetic) as opposed to developing textures.
faze through it, simply hitting it and
going back down.

Graphics – There are also going to be

graphics for the platforms so that
they’re displayed clearly, and are
aesthetic and relevant to the
different levels (e.g., grass platforms
in a field, and stone platforms in a
cave).

Entities – Player – The player entity is needed The entities are vital for gameplay, primarily the
so that the person playing the game player entity, as without the player entity, there
• Player can interact with the game. The would be no medium for the actual player user to
• Flies interact with the game. The flies are also essential to
• Enemies the core objective of the game, which is to collect

P a g e 8 | 70
 • Graphics player is going to be dynamic and them in the time given so that the player can
will be able to move on screen. complete the level. The enemies are also going to be
important (although they are not essential as the
Flies – The fly entities are needed so player can still lose by running out of time), as they
that the player can collect them to can make the player lose hearts and in the event that
complete the game’s objective. The they lose three, they lose the game entirely. The
flies are going to be static and will graphics are very important for the different entities
not be able to move on the screen. as the user needs to see the entity that they’re
controlling, the entities that they must collect to
Enemies – The enemies add an
complete the game, and the entities that they must
additional obstacle to the game to
avoid.
make it more difficult for the player
to complete a level and will take
away a heart on the player’s health
bar when a player encounters them.

Graphics – There are going to be

graphics for all of the entities so that
the player can clearly see them on
the screen. The player graphic is
going to be a frog, and the fly
graphics are going to be flies, and
the enemies might be bees.

Health Bar – The health bar is going to be present The health bar is going to be an important feature of
during the levels, and it is going to the core program of the game, as it is dictates
• Functionality display to the user how many lives whether the player loses the game by losing all 3 of
• Graphics they have left. The health bar is their hearts by encountering one of the enemy
going to display three hearts, and entities.
every time the player is attacked by
one of the enemies, they lose a heart
and have invincibility for 3 seconds.

Graphics – There is also going to be a

graphic to make it clear to the user
when they lose a heart: the hearts
are initially going to be red, but as
they lose a life, one of the hearts
turns grey.

Timer – The timer is going to count down The timer is also very important to the game because
from a certain amount of time to if it runs out of time, the level is over because the
• Functionality zero in steps of 1 second, in which player lost. This is very important to the game’s
• Graphics the player loses the level from failing functionality and is what ultimately creates difficulty
to collect the flies in the time period as the levels progress and increase in difficulty.
given.

Graphics – There is also going to be a

graphic that displays the timer
counting down to zero, and if the
player runs out of time, there may
be a graphic displaying a screen
saying ‘Game Over, Out of Time’

P a g e 9 | 70
 Main Menu – The menu is important to the game The main menu is very important to the game
because it allows you to select play because it allows the user to select what levels they
• Buttons which allows the user to play the want to play. The buttons are vital to the mechanic
actual game section of the program. of navigating the menu as it allows the user to select
When you click play, a list of the levels and play them.
different levels will load, and the
player initially will have to select the
first level and the other levels will be
locked. Once a player has completed
a level, the next level should become
unlocked and should be playable.

In Game Menu – The in-game menu allows the user to The in-game menu is important, however it’s not a
pause and quit the game from within necessity, as the game will work without it, and the
• Buttons the game. If the user chooses to user can still play the game. Without it, the user
close the in-game menu, then they simply would not be able to open a menu in the
will return to the game and will be middle of the game to pause it, and they would not
allowed to continue playing. be able to quit the game during the game.

Hardware and Software Requirements:

Hardware Requirements: Software Requirements:

Monitor – A monitor is needed to display the game and Python – The game program is going to be written in the
the different graphics so that the user can see – and python script software as my program is going to be
therefore interact with – the game written in the python programming language
Keyboard – A keyboard is very important for gameplay
Pygame Library – The pygame library is a pre-existing
purposes, allowing the user to use the W, A, S and D keys
to navigate the game library used to store different premade functions, giving
me the ability to create a game. Libraries greatly reduce
Mouse – A mouse is needed to so that the user can programming time as I can easily use these premade
navigate the game menus, clicking ‘Play’ or ‘Pause’ or functions instead of creating them myself.
‘Settings’

Operating System – 64-Windows 7 or a later version

Processor – 1.5 GHZ or a faster processor

Memory – 4GB of RAM minimum

Free Hard Disk Drive Space – Minimum of 3GB

Success Criteria:

Number- Criteria and Explanation of Testing

P a g e 10 | 70
1 My game needs to have a functioning menu which will allow the user to click ‘Play’ and play the actual game part
of the program. The ‘Play button’ needs to function correctly.

This can be tested by the user running the program. If it works then the main menu ought to load with the correct
background, title, buttons, and button texts, all positioned in the right places. When you hover over the button it
ought to change colour from either GREEN to BRIGHT_GREEN or RED to BRIGHT_RED.

2 The game also needs to have the timer working correctly, where in which the frog needs to eat all the flies within
the time given, otherwise they will lose. The timer needs to count down incrementally in jumps of one second
from X, and if the criteria of flies has not been met then the player will lose the game.

This can be tested by the user playing a level. If it works then the timer ought to count down from X to 0 in
increments of one second. Moreover, when the player encounters a fly to eat, the required number of flies ought
to decrease by one. If the player eats all the flies before the timer runs out, they win and a winning message
should appear, however if the player doesn’t eat them in time, there should be a losing message on screen.

3 The frog criteria also needs to update each time the frog eats one of the flies, (e.g., if the criteria were initially 5,
then the number of ‘flies consumed’ count needs to increase by one until the criteria is met).

This can be tested by the user playing a level. During the level being played, there is going to be a graphic that
displays the criteria of frogs that ought to be eaten. If it works then once a player encounters a fly, the criteria
should update.

4 Jumping is another important thing in the game, and it needs to work correctly as it’s a core mechanic and vital to
the game’s overall functionality: the user needs to be able to interact with the game (e.g., jumping, moving left
and right, potentially ducking).

This can be tested by the user playing a level. During the level being played, the user should be able to press the
arrow keys or the ‘WASD’ keys, and the sprite on the screen ought to move with the corresponding buttons (e.g.,
the right arrow key would make the sprite move right).

5 Gravity is an important aspect of the game as logically the sprite needs to be dragged back down towards the
bottom of the screen to allow the player to navigate the various platforms.

This can be tested by the user playing a level. During the level being played, the user should be able to go up, and
the gravity function will pull the frog sprite back down to the ground so that the sprite doesn’t continually stay in
the air.

6 The health bar and enemies are another important part of the game because it can also dictate whether the
player loses or not. The health bar is going to be working correctly if in the instance that the player character
encounters an enemy, they lose one of their hearts or the health bar decreases.

This can be tested by the user playing a level. During the level being played, the user should encounter enemies
which will cause them to lose hearts. There will be a health bar which should be depleted each time the player
encounters one of these enemies. When there is no health left, the player should lose and there should be a pop
up on the screen telling them that they lost.

7 Platforms also need to work correctly by not allowing the player to faze through it, and the platforms ought to be
treated like solid objects that cannot be entered.

This can be tested by the user playing a level. During the level being played, the user should be able to stand on
the platforms, and there shouldn’t be any sign of the player fazing into the platforms.

8 There needs to be both a game over screen and a winning screen displayed when the player either loses or wins
the game.

P a g e 11 | 70
 This can be tested by the user playing a level and successfully eating all of the flies within the set timeframe.

Limitations:

Number- Limitation and Explanation

1 My game is going to be 2D and not 3D, it’s unrealistic to attempt to program a 3D game as it’s very complicated
and complex, and I don’t have the knowledge of how to program and render a 3D game.

2 I am going to have a few levels (potentially 3) instead of many – like in Super Mario – because it will be overly
complicated and unnecessary for a simple game like mine.

3 I am going to have a few enemy types (potentially 3 like in doodle jump) as opposed to many enemies – like in
Super Mario – because too many enemies will overcomplicate my game and potentially make it confusing for the
player because they will have to remember the different enemies and their attacks. If I was more ambitious, I
would aim to create a larger game with multiple enemies, however I am restricted by time and my own
programming knowledge.

4 The animations are going to be simplistic and abstracted down to very simple looking movements (e.g., the frog
will not have an animation for the movement, it will just be an image moving around the screen.

5 The levels aren’t going to be very long or complicated because they don’t need to be, my game is quite simplistic
in its design and overcomplicating it could be potentially confusing for the player.

P a g e 12 | 70
Design:
Structure Diagram:

Summary of Processes

Main Branches Structure Diagram Components Explained -

of Diagram - Components -

Main Game Quit Button This button is displayed on the screen, and upon being clicked, the game
window will close.

Level Select Button This button is displayed on the screen, and upon being clicked, will return the
user to the level select screen where the user will be able to click various
buttons corresponding with each level in order to play it.

Platforms Positioning: The positions of the platforms on the screen, along the y and x co-
ordinates. These positions will potentially be stored as 2D arrays corresponding
with each of the different levels.

Texture: Texture is simply the display on the actual screen. I intend on the
platforms just being simple squares of a single block colour which can be
replicated multiple times in various locations on the screen.

Collisions: The collisions of the platforms with the player are very important
because the player sprite isn’t supposed to glitch or faze through the different
platforms, and is meant to stand on top of them in order to traverse the
different levels.

Enemies Behaviour: The enemies’ functionality, moving left and right and attacking the
player if the player encounters an enemy.

P a g e 13 | 70
 Texture: The design is going to be simple and displayed on the screen.

Timer The timer is used to countdown during the levels. The timer is going to count
down from a set amount of time to zero. When the timer reaches zero and the
player hasn’t managed to collide with all of the fly sprites on the screen, a
screen will appear saying ‘Game Over’, however if the player manages to
collide with all of the flies before the timer reaches zero, a screen will appear
saying ‘You Won’.

Player Movement The player can move left and right along the x axis, and can also move up and
down along the y axis. The player will be able to do this using the ‘W’, ‘A’ and
‘D’ keys or the ‘Up arrow’, ‘Left arrow’ and ‘Right arrow’ keys. The sprite will
also be affected by gravity in the level, which will drag the sprite down the y
axis to either the bottom of the level, or the platform beneath the player.

Flies Goal to Eat: The flies are sprites that are on the screen and the player has to
eat all of them in the time given in order to win, otherwise they will lose. The
goal to eat is simply the number of flies on the screen which will be in created
using an OOP class, with each fly being an object of that class, meaning that I
can create as many flies as I would like in each level, and position them
wherever I would like to.

Texture: The design for the flies is going to be very simple on the screen.

Main Menu Play Button The button is displayed on the screen, and upon being clicked, the game will
load the level selection screen.

Quit Button This button is displayed on the screen, and upon being clicked, the game
window will close.

Level Selector Levels One - Six Buttons These buttons are displayed on the screen and will load the levels
corresponding with the number of the level.

P a g e 14 | 70
Usability:

This screen here is the One of the buttons

main menu screen. This displayed on the screen
is the first screen of the is the ‘Play’ button.
game when you run the When button is pressed
code and it is a very using the left mouse
simple design, making it button, it takes the user
very easy to navigate to the level select screen
and simple to as seen below. The
understand. button is very simple and
displays the word ‘Play’
to clearly signal to the
The screen features the player that you press it
game’s title at the top to play the game. The
middle making it clear to button is also green, as
the user that it’s the green is often related to
main menu screen for the word ‘Yes’, which
the game (as is common relates to the game
with most videogames). loading.

This screen here is the level selection screen. This screen is accessed by the user The other button displayed on the screen is the
pressing the ‘Play’ button on the main menu screen. Much like the main menu ‘Quit’ button, which – when pressed – will close
screen, the design is very simple and easy to navigate. This screen can also be pygame and end the game.
accessed when the user clicks the ‘Level Select’ button within the levels
themselves.

This screen features 6

buttons at the top of
Similar to the main
the screen. Each one of
menu screen, the level
these buttons is titled
select screen has two
‘Level [Number]’, and
buttons at the bottom
relates to the six
of the screen. One of
different levels in the
these buttons displays
game. When a button
the text ‘Main Menu’,
is pressed, it will load
and when pressed will
the level screen for the
return the user to the
level corresponding to
main menu screen.
the button pressed.
The other button
displays the word
‘Quit’, which – when
pressed – will quit
pygame and the game
itself, closing the
window.

P a g e 15 | 70
This screen here is an The screen has two
idea of what the levels buttons on it at the
will look like with the bottom. The first of the
platforms. The buttons displays the
trapezium on the text ‘Level Select’ and –
screen is representative when clicked – takes
of the frog sprite that the user back to the
the player will be level selection screen.
controlling and will be The button (much like
able to navigate the the ‘Main Menu’ and
screen. The black ‘Play’ buttons on the
bubble is other screens) is green
representative of the and consistent across
flies that the frog must the screens to
collect. The yellow oval differentiate clearly
is representative of the from the other button.
bees that the frog must The other button on the
avoid, otherwise the screen is a red button
frog will lose a heart. displaying the word
‘Quit’ and is used to
quit pygame and close
the game window.

The Graphics User Interface of my game has been improved by:

- The quit buttons are all red because red is associated with quitting and termination. They are all the same colour to
improve consistency.
- The buttons that progress through the game (e.g., The ‘Play’ button and the ‘Level Selector’ buttons) are green,
because green is associated with starting or progression. They are all the same colour to improve consistency.
- The background screens are all blue because blue is a stark colour difference from green and red, therefore it can
assist potential colorblind users in differentiating the different components of the game.
- All of the buttons in the game have clear titles too, displaying simply what the button would do if the user were to
click it.

P a g e 16 | 70
Key Variables:

Key Variable Name Key Variable Purpose

main_menu_run The ‘main_menu_run’ variable can be either true or false and corresponds with whether the main
menu screen is being run or not. It’s important that it’s set to false when the other screens are being
run, as two screens cannot be run at the same time.
level_select_run The ‘level_select_run’ variable can be either true or false and corresponds with whether the level
selection screen is being run or not. It’s important that it’s set to false when the other screens are
being run, as two screens cannot be run at the same time.
level_one_run - The ‘level_one_run’, ‘level_two_run’, ‘level_three_run’, ‘level_four_run’, ‘level_five_run’ and
level_six_run ‘level_six_run’ variables can be either true or false and corresponds with each of the different levels
being run or not. It’s important that they are set to false when the other screens are being run, as two
screens cannot be run at the same time.
Player’s x and y co- The player’s x and y co-ordinates are important variables because they dictate where the player sprite
ordinates will appear on the screen and are needed to allow the player to move by having these variables’ values
being either incremented or reduced when particular keys are pressed.
Flies’ x and y co- The flies’ x and y co-ordinates are important variables because they will allow me to place particular
ordinates flies in particular locations on the screen for the player to collect before the time runs out.
Platform’s x and y The platforms x and y co-ordinates are important because they will allow me to position the different
co-ordinates platforms in each level at specific co-ordinates, allowing me to construct the level layouts.
Timer The timer variable is imperative for the game to function. The variable will decrease in increments of 1
second and will ultimately determine whether the player wins or not by eating the flies before the
timer reaches zero.
Fly Quantity The fly quantity variable is very important for the game, because the player can only win if the fly
quantity reaches zero before the timer reaches zero.

Class Diagrams:

Player Class Platform Class Fly Class

Attributes: Attributes: Attributes:

• Image • Image • Image
• X and Y co-ordinates • Rect (the rectangle of the • Rect (the rectangle of the
• Pos (Position onscreen) platforms) sprite)
• Hit (Whether it has collided • X and Y co-ordinates
with another sprite) • Pos (Position onscreen)
• Hit (Whether it has collided
with the player sprite)
Methods: Methods: Methods:
• Instantiation() • loadLevel() • No Methods
• Updates()

P a g e 17 | 70
Development Testing Plan:

Test - What are you testing for? Why are you testing for it?

1) Whether upon clicking the ‘Play’ button on the main I am testing it because it’s vital for the game’s
menu, the level selection screen will load. This can be functionality. This needs to be able to work so that the
tested by pressing the button and seeing whether the player can access the level selector to then actually
screen changes or not. The test for the ‘Quit’ button can select a level and play it.
also be tested at this stage by pressing the button.

2) Whether the frog sprite will move around the screen It’s important because the player moving around the
correctly. screen is one of the vital functions of the game. It
facilitates interactivity between the player and the frog
sprite so that they player can play the game.

3) Whether upon clicking the ‘Level (Number)’ buttons, the I am testing it because the player needs to be able to
corresponding levels are loaded on the screen. load a level for them to play.

4) Whether the frog sprite will be dragged down to the It’s important to the game because without gravity being
bottom of the screen (mimicking gravity). included in the game, the frog would just fly anywhere
around the screen.

5) Whether the platforms will load into their respective The platforms are pivotal to the game and are a very
levels upon clicking the level button. This can be tested important component as they allow the player to
by pressing the button and seeing whether the different navigate the screen and access certain parts of the map.
platforms will load onto the screen.

6) Whether the player sprite will correctly collide with the The collisions are important because logically, the
platforms and not faze through them. This can be tested platforms and sprite shouldn’t faze or overlap with one
by the player sprite hitting the platforms from every another as this could potentially break the game. The
direction and seeing if the sprites faze into one another main concern however is that the player needs to be able
(which they should not). to at least stand on the platforms to allow the player to
jump between them and access other parts of the level.

7) The flies should be correctly drawn onto the screen in The flies are an important component to my game and
various preset locations. are the main objective of the game itself, therefore they
need to be displayed on the screen so that the user can
collide with them.

P a g e 18 | 70
Algorithms:

Algorithm for the Menus and Menu Traversal

This is a flowchart which depicts how the main menu, and

the load level screens are loaded and traversed. The
flowchart begins with loading the main menu and then asks
whether ‘Play’ was clicked, if not then asks whether ‘Quit’
was clicked, if yes then the game is quit, and if not then it
loops back round. If play was clicked, the level selector
screen is loaded which then goes through a series of
decisions corresponding to the player clicking on each
respective level button. In the event that one of the level
buttons is clicked, each corresponding level is loaded. If the
level buttons aren’t clicked, it asks whether the ‘Main
Menu’ button was selected, if so then it loops back round to
the main menu, and if not then it asks whether the ‘Quit’
button was selected, if not then it loops back round to the
level selector, and if the button is clicked then the game is
quit.

This flowchart is connected to each of the load level

algorithms.

Algorithm for the Level Buttons

This is a flowchart which depicts the buttons and the button

traversal within the different levels. The chart begins with
the game being loaded and played and then there’s a
constant loop throughout the level which first asks whether
the ‘Level Select’ button was clicked, and if it was then it will
take the user back to the level selector screen, and if not
then it’s asked whether the ‘Quit’ button was selected. If
the button wasn’t clicked then it loops back to the
gameplay, otherwise the game is quit.

This flowchart is connected to the main algorithm as when a

level button is selected on the screen, it will load the level.

P a g e 19 | 70
 Algorithm for the Player Movement

This is a flowchart which depicts the player movement

within each of the different levels. The flow chart Is iterative
and repeats throughout each of the different levels to allow
the user to constantly press keys and allow the player sprite
to move around the screen. It begins asking whether the ‘W’
or ‘Up Arrow’ keys were pressed, if so then the player’s y
axis value is incremented by 5, otherwise it goes to the next
question. It then asks whether the ‘A’ or ‘Left Arrow’ keys
were pressed, if so then the player’s x axis value is reduced
by 5, otherwise it goes to the next question. It then asks
whether the ‘D’ or ‘Right Arrow’ keys were pressed, if so
then the player’s x axis value is incremented by 5, otherwise
it will reduce the player’s y axis value by 5 as the player will
be falling due to gravity unless the player moves against it.

This flowchart is connected to the game flowchart as this

flowchart will loop throughout the game, allowing the
player to move in the different levels.

Algorithm for loading the Main Menu

This is a sequential flowchart which loads the main menu

onto the screen. It begins by setting the ‘main_menu_run’
variable to true, and the ‘level_select_run’ variable to false.
It then fills the background of the screen as the colour
‘Blue1’ and blits the title ‘Frog: The Game’ on the screen.
The four rectangles are then drawn onto the screen around
the border and the frog_pic is blit onto the screen. Then the
buttons are created and loaded onto the screen as ‘PLAY’
and ‘QUIT’.

Rectangles drawn onto

the screen’s borders

Algorithm for loading the Level Selection Menu

P a g e 20 | 70
This is a sequential flowchart which loads the Level selection
Menu onto the screen. It begins by setting the variable
‘main_menu_run’ variable to false and the
Development Story:
Week One:
Today I have created the main menu system on a game window. The system is simple with one screen with the title and then two
buttons; one that is green, displaying the word ‘Play’, and another that is red, displaying the word ‘Quit’, which quits the game
and closes the game window. The ‘Play’ button – once clicked – loads another screen which will display the level selector, with
eight other buttons. One of the buttons is green and displays the words ‘Main Menu’ which – when clicked – returns the user to
the first menu screen, and another that’s red and displays the word ‘Quit’, which quits the game and closes the game window.
The other six buttons are for each different level and are yellow, when they’re hovered over, they will turn a bright yellow colour,
and will eventually load the corresponding levels.

Lines 1-4 import the pygame library, time, and random, and run
pygame.

Lines 7-24 establish the different colours that I am going to be using

in the menus. These are constants that are set using hexadecimal
values for each colour.

BLUE1 is the colour of the background for the first menu screen,
and BLUE2 is the colour of the background for the second menu
screen. The RED and BRIGHT_RED colours are used for the ‘Quit’
buttons, and the GREEN and BRIGHT_GREEN colours are used for
the ‘Play’ and ‘Main Menu’ buttons on the first main menu screen
and second main menu screen respectively. The YELLOW and
BRIGHT_YELLOW colours are used for the level selection on the
second screen.

The images are prototypes of

the main menu (on the left)
and the level selector (on the
right) screens, there may be
further developments,
however I need to focus on
more important aspects of
the game first.

P a g e 21 | 70
 This section of code simply sets the caption to
“Frog Game”, establishes the dimensions of
the game window, and creates the screen area
and the clock for the game.

This section of the code creates a definition for the buttons with the parameters of the button message, the x and y positions,
the button width and height, the colour of the button, the colour of the button when the mouse is hovering over it, and also the
action to be taken when the button is pressed. The buttons have small text where the font is set to ‘comic sans’ and the size of
the text is set to 20. The text is then put in the center by doing the x position and then the button width divided by 2 and then
the y position and the button height divided by 2.

This section of code here is used to

create the text boxes on the screen.

Validation: The validation taking place is in regard to the player clicking on the screen. The player can click anywhere on the
screen, but it won’t make anything happen, unless the player specifically clicks on one of the buttons.

Stakeholder Feedback:

“The menu screens do the job, but they don’t necessarily look that user friendly or thematic to the game itself” – Stakeholder
Feedback (Charlie)

Later down the line of programming, I am going to make sure that I improve the usability and user interface of the game menus
to make them more interesting looking, however at the moment that is not one of my greatest concerns as I still need to work
on various more important components of the game.

P a g e 22 | 70
This creates the main menu screen with a function defined as ‘main_menu’. This loads the main menu, sets the display colour to
BLUE1 and creates large text with the front ‘helvetica’ at a size of 50 of the words ‘Frog: The Game’. It then positions the text in
the center by setting it at half of the display width and 1/3 of the display height. It then creates two buttons being ‘PLAY’ and
‘QUIT’ which load the level selector and quit the game. The ‘PLAY’ button is GREEN, and when the mouse hovers over it, it
changes to BRIGHT_GREEN and loads the level_select. The ‘QUIT’ button is RED, and when the mouse hovers over it, it changes
to BRIGHT_RED and quits the game. The display then updates, and the clock speed is set to 15 ticks.

This section of code is the function for the

level_select screen. This code sets the display colour
to BLUE2, and creates eight total buttons. The first
button is on line 108, and is the Main Menu button.
The button is GREEN, but when hovered over is
BRIGHT_GREEN and when clicked loads the main
menu screen. The second button is on line 109, and
is the Quit button. The button is RED, but when
hovered over is BRIGHT_RED and when clicked quits
the game.

The other buttons from line 111 to 116 are the level
buttons which will load the next levels once they’re
created.

This section of the code is the quit game function which quits pygame and closes the window. This function is called
frequently throughout the code when the ‘QUIT’ buttons are pressed.

The main_menu() and level_select() sections of code actually call the functions and allow the game to run.

P a g e 23 | 70
 Test Number One
Test Attempt: Expected Result: Actual Result: Working: Changes to be made:
1 That upon pressing the The screen did not change to No I need to make sure that
‘Play’ button, the the level selection screen the variables
screen will load the from the main menu screen. corresponding with the
next screen (the level main menu and the
selection screen) level selection screen
are set to the correct
values (true or false)
2 That upon pressing the I pressed the ‘Play’ button Yes I now need to test the
‘Play’ button, the and it worked quit button
screen will load the
next
3 That the quit button I pressed the ‘Quit’ button Yes It works correctly and
will quit pygame and and it worked the buttons execute the
the game correct instructions.

Link to Test One: https://youtu.be/rIqZyjYoL1E

Week Two:
Today I began to try and create the section of code which is a prototype of how the sprite moves around the screen, however
there are many problems arising, one of which being that the sprite appears to fill the space where it has previously been,
therefore blocking and filling the screen where it moves from.

Here you can see the problem where the sprite

has a trail following it. This isn’t what I want to
happen in my game because I want the sprite
to be treated as a whole entity that can move
and interact with the environment, and that
wouldn’t work if this situation wasn’t rectified.
As of now, I don’t know how to resolve this
problem, but I have an idea of how to solve it.
As there is a trail of the sprite behind it, it
means that the sprite keeps loading on the
screen following each movement, and isn’t
removed, therefore I need to figure out how to
clear the screen following the sprite moving.

P a g e 24 | 70
I have since figured out how to resolve this issue:

The problem was solved on line 16. The code here is

in a while loop which allows the player to constantly
move during a level. Before the sprite position is
updated on line 19, on line 16 the screen is cleared,
which removes the trail behind the sprite.

The rest of the code serves to allow the user to move

the sprite on the screen through the keys being
pressed, with the up, down, left and right arrow keys
moving the sprite in those directions along the x and y
co-ordinates.

The up key moves the sprite along the y axis -2, the
down key moves the sprite along the y axis +2, the
left key moves the sprite along the x axis -2, and the
right key moves the sprite along the x axis +2.

Then line 43 updates the screen at each frame rate,

allowing the sprite movements to update on the
screen, and line 45 sets the clock tick to 180 (the clock
tick can change depending on how fast or slow I want
the sprite to move, low numbers = slow, high
numbers = fast.

Test Number Two

Test Expected Result: Actual Result: Working: Changes to be made:
Attempt:
1 That the frog sprite will The frog sprite was moving No The screen needs to
move around the around the screen correctly, ‘refresh’ each time the
screen. however there was a trail left sprite moves otherwise a
behind. trail will be displayed on
the screen as the sprite is
displayed on the screen
and not removed during
each clock tick.
2 That the frog sprite will The frog sprite was moving Yes I included a line of code
move around the around the screen correctly at the top of the loop,
screen (without a trail without a trail left behind. screen.fill((0,0,0)) to
being left behind). clear the screen after
each sprite movement.

Link to Test Two: https://youtu.be/XVLFpZS8HVw

P a g e 25 | 70
Week Three:
I have since moved the sprite into its own separate class in a separate file titled (moving_sprite) which is imported at the
beginning of the program. The reason I have done this is because if the player is in a class, I can call upon it several times (which I
will have to do at the beginning of each level). I have updated the player movement prototype.

Here I have created the class called ‘player’

which is initialised, and then loads the frog
image. It then gets the rect from the image
and set the initial position of the frog to be
(0,0), and then sets the position to be a
pygame.math.Vector2. It then sets the top
left of the frog sprite to be where the variable
position is.

Within that player class, I have created the method ‘update’ which will facilitate the movement of the player, and will be called
once per frame to allow the player to move.

This section of code gets the list of the keys

pressed and checks as to whether the up-arrow
key is pressed. It then checks if the player sprite
is off the screen and puts the image back onto
the screen if it goes off, else the sprite is moved
upwards by 5 pixels.

This section of code checks as to whether the

down-arrow key is pressed. It then checks if the
player sprite is off the screen and puts the image
back onto the screen if it goes off, else the sprite
is moved downwards by 5 pixels.

This section of code checks as to whether the

left-arrow key is pressed. It then checks if the
player sprite is off the screen and puts the image
back onto the screen if it goes off, else the sprite
is moved leftwards by 5 pixels.

This section of code checks as to whether the

right-arrow key is pressed. It then checks if the
player sprite is off the screen and puts the image
back onto the screen if it goes off, else the sprite
is moved rightwards by 5 pixels.

P a g e 26 | 70
 This section of code sets the pos vector to the
correct positions, and then changes the position
of the sprite with the new positions.

This section of code here instantiates a player

from the player class in the moving_sprite file
that’s imported at the beginning. It then creates
a sprite group named ‘playerGroup’ and adds the
player to it so that all the sprites in the
playerGroup can be added later in the levels.

Validation: This section of code is validation as the game only allows the input of certain keys for the player to move around.

One of the next steps I need to do for the sprite movements is include gravity so that when the sprite jumps, they jump to a
certain height and then fall back down to either the ground below or a platform below due to gravity.

Week Four:
This week I have been attempting to create the different levels. Similar to the main menu and the level select screens, the levels
are each going to need a screen to play on, therefore I have created a screen for level one.

Here is the level_select loop which

displays all of the different buttons on the
screen to load the different levels, and
the actions are now set to load the
different levels at the end of the line
inside the brackets).

This section of code sets the

level_select_run to false and then sets the
level_one_run to true to load the level
itself. There is then a while loop that
actually runs the level itself. The there is
an if statement embedded in a for loop
which will quit the game if the user clicks
to quit. The level screen displays Aqua,
and then runs the update command on all
the sprits in the playerGroup group. It
then displays all sprites in the playerGroup
group on the screen. It then creates a
button on the screen which takes the
player to the level selector. It then
updates the display.

P a g e 27 | 70
 Test Number Three
Test Attempt: Expected Result: Actual Result: Working: Changes to be made / have been
made:
1 That the ‘Level Select’ The level select button No There may be a logic problem
button will take the actually took me back to the regarding the Boolean variables of
player back to the level main menu screen. level_one_run and the
selection screen. main_menu_run. I will attempt to
resolve the problem by changing the
variables and insuring that there are
no other changes made to these
variables in the code which may be
interfering with the different screens
being displayed.
2 That the ‘Level Select’ The level select button No I tested to see if there was a problem
button will take the actually took me back to the within the different loops, however
player back to the level main menu screen. the loops and Boolean were working
selection screen. correctly. I am unsure of what to do
now as the logic of the Boolean
variables are all correct.
3 That the ‘Level Select’ The level select button Yes I have realised that when the user
button will take the correctly takes me back to clicks the ‘Level Select’ button during
player back to the level the level select screen the level, the user also accidentally
selection screen. instead of the main menu clicks the ‘Main Menu’ button too
screen. because the two are in the same
position and are registered as two
separate mouse clicks. Therefore, I
have changed the x and y co-
ordinates of the buttons to prevent
this happening. Alternatively I could
have used validation which would
make the button press be registered
when the left mouse button is raised,
meaning that the player would not
accidentally click on both of the
buttons at once.

Link to Test Three: https://youtu.be/8ZdcCJEEiR0

Week Five:
I have worked on the formatting of the game, and the two different menus. I have tried to make them more visually appealing,
experimenting more with the drawing functions in pygame, and reshaping the size of the windows itself to make it larger and
therefore easier to create a level with platforms in the game.

P a g e 28 | 70
Before:

After:

I have now made the screen larger to accommodate for the

levels and the placement of the platforms. On the main
menu screen, I have included an image of the frog sprite to
make it more aesthetic for the player, and I have also
reconfigured the positions of each feature on the screen
because of changing the size of the display. Whilst these
changes don’t necessarily affect gameplay, these changes
should make the game more appealing to the stakeholders.

Week Six:
This week I have worked on including gravity in my game so that the frog can’t simply move around the screen along the x and y
axes freely, and now is pulled down the y axis (except when the up arrow or w keys are being pressed and held).

P a g e 29 | 70
 The section that is within the red brackets is the section of code
that I have included to create gravity within the game. This
section of code is embedded within the update method of the
player class which allows the player to move the frog sprite
along the x and y axes. The code is an if statement where in
which if the frog sprite’s y value exceeds 410, then it sets the
position to be 410 (to prevent the sprite from clipping into the
rectangle at the bottom of the screen which has the ‘Level
Select’ and ‘Quit’ buttons positioned on it. And if the frog sprite
isn’t on the y axis at 410 (is at any value on the screen above it),
then the y co-ordinate increases by 5 (as in python, the top left
of the screen is (0,0) and therefore the value increases although
the sprite is moving downwards). Having done this, I do not
need to include a down arrow or s key function where the
sprite moves along the y axis, making the sprite move
downwards, as gravity will do it. One problem that will likely
arise from this section of code is when I create the platforms,
the sprite will likely clip through the platforms as they are
above 410 (but are a lower y value), therefore I will need to
include more criteria to prevent this from happening.

Test Number Four

Test Attempt: Expected Result: Actual Result: Working: Changes to be made:
1 That the frog sprite will The frog sprite did nothing. No The problem may be that there
be dragged down to the The frog didn’t move down is an issue with the sequence of
bottom of the screen. the screen. instructions regarding the
movement of the sprite, it may
be in the incorrect place,
however I am unsure therefore
I will read back through the
code and try to identify any
potential issues.
2 That the frog sprite will The frog sprite instead moved No Python has inverted y co-
be dragged down to the upwards, and I am currently ordinates, I expected that
bottom of the screen. unsure as to why. I think that incrementing the y axis by 5
the problem may be because I would move the sprite
confused the directions along upwards, however it instead
the y co-ordinates . moves the sprite downwards.
This was a logical problem.
3 That the frog sprite will That the frog sprite was Yes I recognised that the problem
be dragged down to the dragged down to the bottom was that the y co-ordinate
bottom of the screen. of the screen as intended. value had to increase instead of
decrease as in python, (0,0) is
the top left of the screen and
not the bottom left.

Link to Test Four: https://youtu.be/b7otYYsFr-k

P a g e 30 | 70
Week Seven:
This week I have worked on creating and implementing platforms in the different levels using a series of 2D arrays.

The bottom image is the code that

represents the image on the left. On the
code below, each 0 represents a blank
space within the level display, and each
x represents each space where there is a
platform present. The 2D array consists
of 11 rows and 24 columns. This code
here is only for level one, however I
have created the other five levels using
the same format, creating variations of
the array using the x and 0 to create
different platform formations.

This section of code on the left is the ‘Platform’ class. This code is
used to create the platforms on the display themselves. ‘Image’ on
line 80 refers to what the platform actually is and how it is going to
be displayed on the screen, and is given the dimensions of 50 by 50
pixels. The following line fills that specified area with the RGB colour
of (128, 71, 28).

The function ‘loadLevel’ on line 85 is used to load the different

platform maps onto the different level, and is used by creating a
sprite group for the platforms. An if statement is used to condition
whether the character in the 2D array is an ‘x’ and if so, a platform is
put there and added to the platforms sprite group.

This section of the code is level one. The highlighted sections

are new and are used for implementing the platforms into
their respective levels. Line 156 is used to set the platforms
for the level to the level1 array from the map file. Line 167 is
used to actually draw the platforms on the gameDisplay, and
the following lines update the platforms sprite group.

Test Number Five

Test Attempt: Expected Result: Actual Result: Working: Changes to be made:

P a g e 31 | 70
 1 That the platforms will The platforms did not load, No The problem may be with the
load onto the screen. I am unsure as to why. instantiation of the different
platform objects in the
platform sprite group which
needs to be drawn onto the
screen.
2 That the platforms will The platforms still did not No The problem may be in
load onto the screen. load onto the screen. regards to the application of
the platform class of the map
file in the main program file.
3 That the platforms will The platforms loaded onto Yes No changes, it worked. The
load onto the screen. the screen. problem was that the
platforms weren’t drawn on
the screen within the level
loop, and then the sprite
group for the platforms
wasn’t updated.

Test Number Six

Test Attempt: Expected Result: Actual Result: Working: Changes to be made:
1 That the player will The collisions did not work No The problem may be within
collide with the and the player sprite simply the player movement file in
platforms and not faze fazed through the regards to the hits and
or clip through them. platforms. collisions with other sprites
inside of the ‘if statement’.
2 That the player will The collisions worked for No All of the collisions work
collide with the the left, right and bottom except for collisions from
platforms and not faze of the platform, however above (the sprite moves
or clip through them. the player continued to downwards onto the
faze through the top of the platform). I do not know why
platform. this isn’t working and the
problem must be in regards
to the x and y collisions
written in the moving sprite
file.
3 That the player will The collisions worked for No I do not know why this
collide with the the top and bottom of the problem is occurring;
platforms and not faze platform, however the however, I need to move on
or clip through them. player now fazes through from this and work on other
the left and right of the aspects of the game which
platforms and I am unsure are more important. This
as to why this is happening however is okay as the main
still. platform function is to stand
on them

Here are two examples of the problem that is

occurring where the player sprite is clearly ‘clipping’
into the platform. Whilst this is not an ideal
occurrence, it isn’t necessarily incredibly impactful to
the overall gameplay, the main aspect is that the
player can at least stand upon the platforms, which
was their original intent, therefore I am going to
continue programming the game despite this issue.

Stakeholder Feedback: Link to Test Six: https://youtu.be/6BL9Fzys_zM

“Despite the unrefined collisions with the platforms, the platforms still serve their purpose well as you can stand on top of them
and hit them from below” – Stakeholder Feedback (Alfie)

P a g e 32 | 70
Based upon the feedback I received from Alfie, I think that the platforms in the level work generally, however the clipping is a
small problem which can be encountered and can potentially break the game. However, in order to avoid these issues, I am
going to design the levels and the platform maps in a certain way to avoid these glitches breaking the overall game.

P a g e 33 | 70
Week Eight:
This week, I have worked on creating the flies in the different levels at different positions in a separate file, and I have also
created collisions between the sprite groups of the player and the flies to make the flies vanish when the sprites of either group
come into contact with one another.

The image on the left is a photo of level one with all of

the different flies on the screen. Each of the individual
flies can be positioned at any position along the x and
y axes. When the player collides with one of these
flies, the fly disappears from the screen.

The code on the image on the left is representative of

the fly class which is used to create the different flies
in the levels. The class is initially initalised, and an
image is used on line 7 to be the actual sprite for the
fly, and line 9 is used to remove the background of the
sprite.

Lines 11 and 12 establish the x and y co-ordinates of a

fly, and line 13 establishes these co-ordinates as a
vector.

Line 14 is used to set the co-ordinate of the sprite

corresponding with the top left corner of the sprite
image.

Line 15 creates a Boolean attribute called ‘hit’ and

establishes it as False, which will be used later when
the player sprite collides with the fly, making the fly
disappear off the screen.

The code on the image on the left shows how the flies
are implemented into the levels, and the image is of
level one specifically (however the code is the same for
each level with changes to the number of flies and the
flies’ positions on the screen).

Line 161 creates a sprite group under the title

‘flyGroup’ where all of the flies are going to be added.
In lines 163 to 170, the flies are being created under
names ‘fly1’, ‘fly2’, ‘fly3’ and ‘fly4’ from the flies file
and instantiating them from the fly class. The two
parameters that are being passed into the fly class are
for each of the different positions of the flies on the
screen.

The lines that follow add each of these new fly objects
to the sprite group ‘flyGroup’. Lines 190 and 192 are
used to display the flies on the screen, 190 updates the
flyGroup and then line 192 draws the flies from the
flyGroup on the game’s display.

P a g e 34 | 70
 Test Number Seven
Test Attempt: Expected Result: Actual Result: Working: Changes to be made:
1 That the flies will be The flies were not drawn No I think that the problem may be
drawn onto the screen. onto the screen. that the code for drawing the
sprites in the fly group may be
incorrect or in the wrong
sequence.
2 That the flies will be The flies were not drawn No The problem might be within the
drawn onto the screen. onto the screen. code for the fly class itself and
the co-ordinates that the flies
need to be positioned.
3 That the flies will be The flies were drawn onto Yes There was an issue with the
drawn onto the screen. the screen. parameters that correspond
with the co-ordinates of the flies
on the screen, and it has since
been resolved.

Link to Test 7: https://youtu.be/FX2G0zHWmRA

Week Nine:
This week I have worked on creating the functioning timer and also the game over and winning screens for when the player wins
or loses a level.

The section of code above is how the timer is implemented into each of the different levels. The first image displays a function
which will convert the milliseconds into seconds which allows me to create a timer which counts in increments of seconds
instead of milliseconds. The second image displays how this function is used within the levels to actually create the timer,
establishing the time to be counted down from as 30000 (or 30 seconds). In the event that the timer reaches 0, the ‘game_over’
function is run. There is then a second if statement where in which if the flyGroup value reaches 0 (meaning that the player
collided with all of the flies on the screen), the ‘game_win’ function is run. Lines 556 to 558 allow the timer to be displayed on
the screen and position it accordingly.

P a g e 35 | 70
 This section of code on the top image is
the function for the game_over screen.
This function is run when the timer
reaches zero and the player hasn’t eaten
all of the flies on the screen yet. The
screen is very simple, with a layout very
much like the opening menu screen, with
the buttons being able to take the player
back to the level selection screen or allow
the player to quit.

This section of code on the bottom image

is the function for the game_win screen.
This function is run when the player
manages to eat all of the flies on the
screen. The screen is very simple, with a
layout much like the opening menu scree,
with the buttons being able to take the
player back to the level selection screen or
allow the player to quit.

Test Number Eight

Test Attempt: Expected Result: Actual Result: Working: Changes to be made:
1 That the timer will run The timer wasn’t displayed No There is a syntax problem arising
correctly and will count on the screen. and the code isn’t running for
down from 30 in the levels, the problem is in
increments of 1 second. regard to the timer being
calculated on line 550.
2 That the timer will run The timer works properly. Yes The problem has since been
correctly and will count solved and it works.
down from 30 in
increments of 1 second.

Link to Test 8: https://youtu.be/aU0rpq0E3XU

Test Number Nine

Test Attempt: Expected Result: Actual Result: Working: Changes to be made:

P a g e 36 | 70
 1 That the gameover It loaded correctly and the Yes No changes to be made, it works
screen will load in the buttons executed their correctly.
event that the player proper functions.
loses (the timer reaches
zero and the flies
haven’t been eaten).

Link to Test 9: https://youtu.be/TAFHAIJd2xw

Test Number Ten

Test Attempt: Expected Result: Actual Result: Working: Changes to be made:
1 That the winning screen It loaded correctly and the Yes No changes to be made, it works
will load in the event buttons executed their correctly.
that the player loses proper functions.
(the timer reaches zero
and the flies haven’t
been eaten).

Link to Test 10: https://youtu.be/_sTFxi6yC4M

P a g e 37 | 70
Evaluation:
Post-Development Testing:

Test Number One

Test Test Expected Result: Actual Result: Working: Changes to be made:
Number: Attempt:
1 1 That upon pressing the The screen did not No I need to make sure that the
‘Play’ button, the change to the level variables corresponding with the
screen will load the selection screen from main menu and the level selection
next screen (the level the main menu screen. screen are set to the correct values
selection screen) (true or false)

2 That upon pressing the I pressed the ‘Play’ I now need to test the quit button
‘Play’ button, the button and it worked
screen will load the
next
3 That the quit button I pressed the ‘Quit’ Yes It works correctly and the buttons
will quit pygame and button and it worked execute the correct instructions.
the game
VIDEO TEST ONE: https://youtu.be/rIqZyjYoL1E

2 1 That the frog sprite will The frog sprite was No The screen needs to ‘refresh’ each
move around the moving around the time the sprite moves otherwise a
screen. screen correctly, trail will be displayed on the screen
however there was a as the sprite is displayed on the
trail left behind. screen and not removed during each
clock tick.
2 That the frog sprite will
The frog sprite was Yes I included a line of code at the top of
move around the moving around the the loop, screen.fill((0,0,0)) to clear
screen (without a trail screen correctly the screen after each sprite
being left behind). without a trail left movement.
behind.
VIDEO TEST TWO: https://youtu.be/XVLFpZS8HVw

3 1 That the ‘Level Select’ The level select button No There may be a logic problem
button will take the actually took me back regarding the Boolean variables of
player back to the level to the main menu level_one_run and the
selection screen. screen. main_menu_run. I will attempt to
resolve the problem by changing the
variables and insuring that there are
no other changes made to these
variables in the code which may be
interfering with the different screens
being displayed.
2 That the ‘Level Select’ The level select button No I tested to see if there was a
button will take the actually took me back problem within the different loops,
player back to the level to the main menu however the loops and Boolean
selection screen. screen. were working correctly. I am unsure
of what to do now as the logic of the
Boolean variables are all correct.

P a g e 38 | 70
 3 That the ‘Level Select’ The level select button Yes I have realised that when the user
button will take the correctly takes me clicks the ‘Level Select’ button during
player back to the level back to the level select the level, the user also accidentally
selection screen. screen instead of the clicks the ‘Main Menu’ button too
main menu screen. because the two are in the same
position and are registered as two
separate mouse clicks. Therefore, I
have changed the x and y co-
ordinates of the buttons to prevent
this happening. Alternatively, I could
have used validation which would
make the button press be registered
when the left mouse button is
raised, meaning that the player
would not accidentally click on both
of the buttons at once.
VIDEO TEST THREE: https://youtu.be/8ZdcCJEEiR0

4 1 That the frog sprite will The frog sprite did No The problem may be that there is an
be dragged down to nothing. The frog issue with the sequence of
the bottom of the didn’t move down the instructions regarding the
screen. screen. movement of the sprite, it may be in
the incorrect place, however I am
unsure therefore I will read back
through the code and try to identify
any potential issues.
2 That the frog sprite will The frog sprite instead No Python has inverted y co-ordinates, I
be dragged down to moved upwards, and I expected that incrementing the y
the bottom of the am currently unsure as axis by 5 would move the sprite
screen. to why. I think that the upwards, however it instead moves
problem may be the sprite downwards. This was a
because I confused the logical problem.
directions along the y
co-ordinates .
3 That the frog sprite will That the frog sprite Yes I recognised that the problem was
be dragged down to was dragged down to that the y co-ordinate value had to
the bottom of the the bottom of the increase instead of decrease as in
screen. screen as intended. python, (0,0) is the top left of the
screen and not the bottom left.
VIDEO TEST FOUR: https://youtu.be/b7otYYsFr-k

5 1 That the platforms will The platforms did not No The problem may be with the
load onto the screen. load, I am unsure as to instantiation of the different
why. platform objects in the platform
sprite group which needs to be
drawn onto the screen.
2 That the platforms will The platforms still did No The problem may be in regards to
load onto the screen. not load onto the the application of the platform class
screen. of the map file in the main program
file.
3 That the platforms will The platforms loaded Yes No changes, it worked. The problem
load onto the screen. onto the screen. was that the platforms weren’t
drawn on the screen within the level
loop, and then the sprite group for
the platforms wasn’t updated.

P a g e 39 | 70
6 1 That the player will The collisions did not No The problem may be within the
collide with the work and the player player movement file in regards to
platforms and not faze sprite simply fazed the hits and collisions with other
or clip through them. through the platforms. sprites inside of the ‘if statement’.
2 That the player will The collisions worked No All of the collisions work except for
collide with the for the left, right and collisions from above (the sprite
platforms and not faze bottom of the moves downwards onto the
or clip through them. platform, however the platform). I do not know why this
player continued to isn’t working and the problem must
faze through the top of be in regards to the x and y collisions
the platform. written in the moving sprite file.
3 That the player will The collisions worked No I do not know why this problem is
collide with the for the top and bottom occurring; however, I need to move
platforms and not faze of the platform, on from this and work on other
or clip through them. however the player aspects of the game which are more
now fazes through the important. This however is okay as
left and right of the the main platform function is to
platforms and I am stand on them
unsure as to why this is
happening still.
VIDEO TEST SIX: https://youtu.be/6BL9Fzys_zM

7 1 That the flies will be The flies were not No I think that the problem may be that
drawn onto the screen. drawn onto the screen. the code for drawing the sprites in
the fly group may be incorrect or in
the wrong sequence.
2 That the flies will be The flies were not No The problem might be within the
drawn onto the screen. drawn onto the screen. code for the fly class itself and the
co-ordinates that the flies need to
be positioned.
3 That the flies will be The flies were drawn Yes There was an issue with the
drawn onto the screen. onto the screen. parameters that correspond with
the co-ordinates of the flies on the
screen, and it has since been
resolved.
VIDEO TEST SEVEN: https://youtu.be/FX2G0zHWmRA

8 1 That the timer will run The timer wasn’t No There is a syntax problem arising
correctly and will count displayed on the and the code isn’t running for the
down from 30 in screen. levels, the problem is in regard to
increments of 1 the timer being calculated on line
second. 550.
2 That the timer will run The timer works Yes The problem has since been solved
correctly and will count properly. and it works.
down from 30 in
increments of 1
second.
VIDEO TEST EIGHT: https://youtu.be/aU0rpq0E3XU

9 1 That the gameover It loaded correctly and Yes No changes to be made, it works
screen will load in the the buttons executed correctly.
event that the player their proper functions.
loses (the timer
reaches zero and the

P a g e 40 | 70
 flies haven’t been
eaten).

VIDEO TEST NINE: https://youtu.be/TAFHAIJd2xw

10 1 That the winning It loaded correctly and Yes No changes to be made, it works
screen will load in the the buttons executed correctly.
event that the player their proper functions.
loses (the timer
reaches zero and the
flies haven’t been
eaten).
VIDEO TEST TEN: https://youtu.be/_sTFxi6yC4M

11 1 Validation of the W It worked correctly and Yes No changes to be made, it works.

key. When the player the sprite moved
presses the W key on upwards by 5.
the keyboard, the
player’s y co-ordinate
should decrease by 5,
and the sprite should
move upwards. This is
valid data entry.
12 1 Validation of the Up- It worked correctly and Yes No changes to be made, it works.
Arrow key. When the the sprite moved
player presses the Up- upwards by 5.
Arrow key on the
keyboard, the player’s
y co-ordinate should
increase by 5, and the
sprite should move
upwards. This is valid
data entry.
13 1 Validation of the A key. It worked correctly and Yes No changes to be made, it works.
When the player the sprite moved
presses the A key on leftwards by 5.
the keyboard, the
player’s x co-ordinate
should decrease by 5,
and the sprite should
move leftwards. This is
valid data entry.
14 1 Validation of the Left- It worked correctly and Yes No changes to be made, it works.
Arrow key. When the the sprite moved
player presses the Left- leftwards by 5.
Arrow key on the
keyboard, the player’s
x co-ordinate should
decrease by 5, and the
sprite should move
leftwards. This is valid
data entry.
15 1 Validation of the D key. It worked correctly and Yes No changes to be made, it works.
When the player the sprite moved
presses the D key on rightwards by 5.
the keyboard, the

P a g e 41 | 70
 player’s x co-ordinate
should increase by 5,
and the sprite should
move rightwards. This
is valid data entry.
16 1 Validation of the Right- It worked correctly and Yes No changes to be made, it works.
Arrow key. When the the sprite moved
player presses the rightwards by 5.
Right-Arrow key on the
keyboard, the player’s
x co-ordinate should
increase by 5, and the
sprite should move
rightwards. This is valid
data entry.
17 1 Validation of any I have pressed all the Yes No changes to be made, it works.
irrelevant or unallowed different keys on the
keys. When these keyboard within the
buttons are pressed, levels of my game and
nothing happens nothing occurs when
within the game they are pressed.
because these keys
aren’t coded to have
any functionality
within my game. This is
invalid data entry.
18 1 Testing of pressing the The buttons directly Yes No changes to be made, it works.
‘A’ and ‘D’ keys oppose one another
simultaneously in the with one increasing the
level because they are x axis value by 5 and
opposing. This is the other decreasing
extreme data entry. the x axis value by 5,
therefore nothing
ought to happen.
19 1 Testing of pressing the The buttons directly Yes No changes to be made, it works.
‘Left-Arrow’ and ‘Right- oppose one another
Arrow’ keys with one increasing the
simultaneously in the x axis value by 5 and
level because they are the other decreasing
opposing. the x axis value by 5,
therefore nothing
ought to happen.
20 1 Testing the player The player shouldn’t Yes No changes to be made, it works.
sprite navigating the be able to leave the
border and the extent confines of the screen
to which they can and exceed the
move. This is extreme boundaries.
data testing.
21 1 Testing what will occur The buttons should still Yes No changes to be made, it works.
when the buttons on work properly and
the screen are clicked execute the
repeatedly and quickly. corresponding actions
This is extreme data without any problems
testing. arising.

P a g e 42 | 70
Usability Features:
The stakeholders have given me feedback on the usability of the game and have given me feedback on whether it has been
successful or unsuccessful.

Stakeholder Feedback Response

“Using the W, A and D keys are very helpful because they are This is a successful feature because the player can easily
common keys to use for video games and allow the player to navigate the screen and the buttons all correspond with the
use their left hand whilst the player can use their right hand direction that the player can move.
for the mouse” - Josh

“Having the ability to use the arrow keys to move around the This is a successful feature because the player can easily
screen is also a good feature because it means that the navigate the screen and the buttons all correspond with the
player can navigate the screen” - Cameron direction that the player can move.

“The layouts of all of the different screens are very clear with This is a successful feature because the player can easily
distinguishable features like buttons and sprites” - Alfie navigate and traverse the different screens without
instruction.

“A potential concern is the colour choosing as some of the This is an unsuccessful feature as some of the colours can
colours may look similar to people that are colourblind” - potentially look similar in the game, making it difficult for a
Charlie colourblind player to distinguish between the different
elements of the game.

P a g e 43 | 70
Success Criteria Met:

Number- Criteria and Explanation of Testing Has it been met? Reasoning

1 My game needs to have a This criterion has been met When you load up the game, the
functioning menu which will allow because I have created two user is presented with a working
the user to click ‘Play’ and play the functioning menu systems being main menu screen with two
actual game part of the program. the main menu and the level buttons, one for playing the game
The ‘Play button’ needs to function selection menu. The user can and another for quitting the game
correctly. correctly navigate between the entirely. The play button then
two different menus and the takes the user to the level
This can be tested by the user buttons all work correctly and selection screen with six buttons
running the program. If it works execute their proper functions. corresponding which each of the
then the main menu ought to load six levels, with two other buttons,
with the correct background, title, This has been tested numerous which can be selected and either
buttons, and button texts, all times by both myself and a take the user back to the main
positioned in the right places. stakeholder, and no problems menu screen or quit the game.
When you hover over the button it were identified.
ought to change colour from either
GREEN to BRIGHT_GREEN or RED
to BRIGHT_RED.

2 The game also needs to have the This criterion has been met When you load a level, the user is
timer working correctly, where in because I have created a fully presented with the level (the
which the frog needs to eat all the functioning timer that can count screen, platforms, player, flies,
flies within the time given, down from a fixed number to zero. buttons and timer) and the user
otherwise they will lose. The timer The timer will stop if the player has has to eat all of the flies before the
needs to count down managed to eat all of the flies on timer runs out. This works
incrementally in jumps of one the screen within the time frame, correctly and is imperative to the
second from X, and if the criteria otherwise the timer will reach zero overall functionality of the game as
of flies has not been met then the and the player loses the level. it is the determining factor as to
player will lose the game. whether the player wins or loses
This has been tested numerous the game.
This can be tested by the user times by both myself and a
playing a level. If it works then the stakeholder, and there were no
timer ought to count down from X issues identified as the timer works
to 0 in increments of one second. correctly.
Moreover, when the player
encounters a fly to eat, the
required number of flies ought to
decrease by one. If the player eats
all the flies before the timer runs
out, they win and a winning
message should appear, however
if the player doesn’t eat them in
time, there should be a losing
message on screen.

3 The frog criteria also need to This criterion has been adapted When you load a level, the user is
update each time the frog eats one since it was initially established as presented with the level and the
of the flies, (e.g., if the criteria there is no need for a counter now various flies positioned around the
were initially 5, then the number as the flies are displayed on the screen. The number of flies on the
of ‘flies consumed’ count needs to screen and the user can see how screen corresponds with the
increase by one until the criteria is many flies are left. Whilst this number of flies that need to be
met). could have been implemented into eaten in order for the player to
the game, it would have been a complete the level and win. Each
feature rendered redundant as the time a fly is collided with, the

P a g e 44 | 70
 This can be tested by the user fly sprites on the screen are number of flies in the fly group
playing a level. During the level representative of the number of diminishes by one until it reaches
being played, there is going to be a flies that need to be eaten. zero. When this happens within
graphic that displays the criteria of Implementation of this feature the time, the player wins the level.
frogs that ought to be eaten. If it however may have made the game
works then once a player more user friendly as it clearly
encounters a fly, the criteria displays the objective to the user.
should update. My stakeholders include both
people that are teenagers, who
will likely understand that they
need to eat all the flies on the
screen, however the younger
demographic of primary school
students may find this potentially
difficult.

4 Jumping is another important This criterion has not been met in Whilst this criterion has not been
thing in the game, and it needs to my game. Instead of the player met, the game still functions
work correctly as it’s a core having the ability to jump, the properly and the player can
mechanic and vital to the game’s player can float around the screen, navigate the screen with ease.
overall functionality: the user however will still be dragged back
needs to be able to interact with down due to gravity.
the game (e.g., jumping, moving
left and right, potentially ducking). My stakeholders have given me
feedback on this and said that they
This can be tested by the user would have liked the ability to
playing a level. During the level jump instead of float in the game,
being played, the user should be however they are still pleased that
able to press the arrow keys or the they have the ability to move
‘WASD’ keys, and the sprite on the around the screen easily.
screen ought to move with the
corresponding buttons (e.g., the
right arrow key would make the
sprite move right).

5 Gravity is an important aspect of This criterion has been met as the When the player selects a level
the game as logically the sprite player sprite will be dragged back and the level loads, when the
needs to be dragged back down down to the floor or platform player uses the up arrow to go up,
towards the bottom of the screen beneath it when the sprite is in the the player will move upwards,
to allow the player to navigate the air. however when the player stops
various platforms. pressing this button, the sprite will
This feature has been tested on fall back down because of this
This can be tested by the user every single level and it works on gravity feature.
playing a level. During the level all of them each time it has been
being played, the user should be tested, both by myself and by the
able to go up, and the gravity stakeholder, and no issues were
function will pull the frog sprite identified with this feature.
back down to the ground so that
the sprite doesn’t continually stay
in the air.

6 The health bar and enemies are This criterion has not been met as I Whilst these elements haven’t
another important part of the have not been able to include the been included, the game still is
game because it can also dictate enemies or the health bar in the fully functional as the loser can still
whether the player loses or not. game. These two components win and lose the game, however
The health bar is going to be work together as the enemies the added difficulty of the enemies
working correctly if in the instance determine changes in the health would have made the game more
that the player character bar, therefore it would be illogical

P a g e 45 | 70
 encounters an enemy, they lose to include health bar without the interesting and adds an additional
one of their hearts or the health enemies. challenge for the player.
bar decreases.

This can be tested by the user

playing a level. During the level
being played, the user should
encounter enemies which will
cause them to lose hearts. There
will be a health bar which should
be depleted each time the player
encounters one of these enemies.
When there is no health left, the
player should lose and there
should be a pop up on the screen
telling them that they lost.

7 Platforms also need to work This criterion has been partially When the player loads the game,
correctly by not allowing the met as the platforms work as an the platforms are also loaded onto
player to faze through it, and the object which the player sprite can the screen. When the player lands
platforms ought to be treated like stand on and hit their head on top of one of these platforms,
solid objects that cannot be against, however when the sprite the player sprite stands on top of it
entered. collides with the sides of the and can move along the x axis as
platforms, the player can faze long as it is on top of that
This can be tested by the user through the platforms. However, platform.
playing a level. During the level as the main function of the
being played, the user should be platforms is for the player to stand
able to stand on the platforms, and on top of them, this isn’t much of
there shouldn’t be any sign of the an issue and the game still
player fazing into the platforms. functions.

This has been tested numerous

times by both myself and a
stakeholder, and it was considered
a flaw in the game as it is not
supposed to happen as the player
could potentially enter these
platforms and navigate the screen
incorrectly.

8 There needs to be both a game This criterion has been met as the When the player eats all of the
over screen and a winning screen player will be presented with a flies on the screen within the
displayed when the player either winning screen in the event that timeframe of the level, they are
loses or wins the game. they eat all of the flies in the time presented with a screen that tells
given for that particular level. them that they’ve won, otherwise
This can be tested by the user Moreover, if the player fails to eat they lose and the timer reaches
playing a level and successfully all of the flies in the time given, zero and they’re presented with a
eating all of the flies within the set they are presented with a game losing screen.
timeframe. over screen when the timer
reaches zero.

This has been tested numerous

times by both myself and a
stakeholder and it works correctly
on each individual level.

P a g e 46 | 70
Future Developments / Maintenance:

1 More complex level The levels that I have created are fairly small and simplistic using only one type of
designs platform. Future developments of the game could include levels with more complex
designs.

2 More platforms and I have created only one type of platform; however future developments could include
platform different types of platforms, such as ice, which would have less friction, giving the illusion
functionality that the player is slipping on the ice.

3 Enemies Future developments could include enemies, as was intended for my game. These
enemies would introduce a new feature to the game – being the health bar for the
player. If the player collides with one of these enemies, they will lose one of their hearts
on the health bar. In the event that the player loses all of their hearts in the health bar,
they will lose the game.

4 Animations Potential animations could also be created for all of the sprites; for instance, the player
frog sprite could be changed to have different variations which could alternate as the
player navigates the screen. The same could apply to the fly sprites on the screen, which
could be given animations that would make them move up and down like they’re flying.

5 More levels I have created a total of 6 different levels, however future developments could
potentially allow more levels to be created, making the game much more fun and
entertaining for the stakeholders.

6 Two Player Gameplay The game could potentially be developed further to include two player elements where
one player uses the W, A and D keys, and the other uses the up, left and right arrow keys.
This could open the game up to multiple game modes requiring two players.

7 Music / Sounds Another potential element which could be added in future developments could be the
inclusion of music and sound which is common in many other games (such as super
mario and doodle jump).

8 Level Unlocking One element which could also be included in future developments could be level
unlocking where the player needs to complete and win the first level in order to allow
the player to access the second level, and so on.

9 Powerups In future development, I could also include powerups which could grant the player
different abilities which could help them complete the game, such as freezing the timer
for a certain amount of time or allowing the player to move faster. Alternatively, the
player could encounter other powerups which would hinder their progression in the
level, which could potentially take time off of their timer, or make their movement
slower.

10 Game Modes Future development could also allow more game modes to be created with different
goals and objectives for the player to reach in order to win, for instance there could be a
game mode where the player can see how many flies they can collide with before the
time runs out.

P a g e 47 | 70
Code:
File Name: main.py

import pygame
import time
import random
import moving_sprite
import map
import flies
import math

pygame.init()

# Sets the colours for the MENU SCREEN

===================================================================================

BLACK = (0, 0, 0)
WHITE = (255, 255, 255)
RED = (252, 61, 50)
BRIGHT_RED = (255, 0, 0)
GREEN = (102, 255, 102)
BRIGHT_GREEN = (0, 255, 0)
YELLOW = (255, 255, 0)
BRIGHT_YELLOW = (255, 255, 51)
AQUA = (0, 128, 128)
GRAY = (190, 190, 190)
SLATE = (47,79,79)
BLUE1 = (0, 208, 255)
BLUE2 = (0, 147, 255)

# Sets the Window Caption

===================================================================================

pygame.display.set_caption("Frog Game") # Sets the caption of the display to "Frog

Game"
frog_pic = pygame.image.load("frog.png") # Loads the "frog.png" file and sets it as
the variable 'frog_pic'

#Sets the dimensions of the GAME WINDOW

display_width = 1200 # Sets the width of the display to 1200
display_height = 650 # Sets the height of the display to 650

player = moving_sprite.player() # Creates the player using the

moving_sprite.player class
playerGroup = pygame.sprite.Group() # Creates a sprite group
playerGroup.add(player) # Adds the player to the sprite group

P a g e 48 | 70
# Creates the SCREEN AREA (Multiple needed for each screen)
gameDisplay = pygame.display.set_mode((display_width, display_height)) # Creates
the game display with the established display width and height
clock = pygame.time.Clock() # Creates
a clock for the game

# Creates the buttons

===================================================================================

def button(message, xpos, ypos, buttonwidth, buttonheight, buttoncolour, buttonhover,

action = None): # This is the function which is used to create buttons within
the game
mouse =
pygame.mouse.get_pos()
# This creates the variable 'mouse' which gets the position of the mouse on
the screen
click =
pygame.mouse.get_pressed()
# This creates the variable 'click' which registers whether the mouse button
has been clicked

#Checks the position, creates the rectangle

if xpos + buttonwidth > mouse[0] > xpos and ypos + buttonheight > mouse [1] >
ypos:
pygame.draw.rect(gameDisplay, buttonhover, (xpos, ypos, buttonwidth,
buttonheight))
if click[0] == 1 and action != None:
action()
else:
pygame.draw.rect(gameDisplay, buttoncolour, (xpos, ypos, buttonwidth,
buttonheight))
smallText = pygame.font.SysFont("roboto", 25)
textSurf, textRect = text_objects(message, smallText)
textRect.center = ((xpos + (buttonwidth / 2)), (ypos + (buttonheight / 2)))
gameDisplay.blit(textSurf, textRect)

# For the Text Boxes on the Screens

===================================================================================

def text_objects(text, font): # This is a function which

will create the text boxes on the screen
textSurface = font.render(text, True, BLACK)
return textSurface, textSurface.get_rect()

# Main Menu Screen

===================================================================================

def main_menu():

P a g e 49 | 70
 main_menu_run = True # Sets the main_menu_run
boolean variable to True
level_select_run = False # Sets the level_select_run
boolean variable to False

while main_menu_run: #
A while loops which allows the main menu code to be run whilst the main_menu_run
variable is set to true
for event in pygame.event.get():
#print (event)
if event.type == pygame.QUIT:
pygame.quit() #
Allows the player to quit pygame if the quit window button is pressed

#Sets the screen's background colour (OR IMAGE)

gameDisplay.fill(BLUE1) #
Sets the background of the screen to the constant 'BLUE1'
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(0, 600, 1200, 50)) #
These lines simply draw rectangles on the screen for aesthetic purposes
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(0, 0, 1200, 50))
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(1150, 0, 50, 650))
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(0, 0, 50, 650))
pygame.draw.rect(gameDisplay, WHITE, pygame.Rect( 375, 90, 450, 75))

#Sets the screen's text size and font

largeText = pygame.font.SysFont("roboto", 75)
TextSurf, TextRect = text_objects("Frog: The Game", largeText)

#Sets the position of the Title Text

TextRect.center = ((display_width / 2), (display_height / 5))
titlerect = (490,250)
gameDisplay.blit(frog_pic, titlerect)
gameDisplay.blit(TextSurf, TextRect)

#Creates the BUTTONS

#message, xpos, ypos, buttonwidth, buttonheight, buttoncolour, buttonhover,
action = None
button("PLAY", 150, 400, 200, 50, GREEN, BRIGHT_GREEN, level_select)
button("QUIT", 850, 400, 200, 50, RED, BRIGHT_RED, quitgame)

pygame.display.update()
clock.tick(60)

# Level Select Screen

===================================================================================

def level_select():

P a g e 50 | 70
 main_menu_run = False # Sets the main_menu_run boolean
variable to False
level_select_run = True # Sets the level_select_run
boolean variable to True

while level_select_run: #
A while loops which allows the level select code to be run whilst the level_select_run
variable is set to true
for event in pygame.event.get():
#print (event)
if event.type == pygame.QUIT:
pygame.quit() #
Allows the player to quit pygame if the quit window button is pressed

gameDisplay.fill(BLUE2)
# X, Y, Length, Height
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(0, 600, 1200, 50)) #
This code is for the different rectangles around the screen for aesthetic purposes
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(0, 0, 1200, 50))
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(1150, 0, 50, 650))
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(0, 0, 50, 650))
button("Main Menu", 150, 500, 250, 50, GREEN, BRIGHT_GREEN, main_menu)
button("Quit", 800, 500, 250, 50, RED, BRIGHT_RED, quitgame)

#message, xpos, ypos, buttonwidth, buttonheight, buttoncolour, buttonhover,

action = None
button("Level One", 150, 100, 250, 100, YELLOW, BRIGHT_YELLOW,
level_one) # These are all the different buttons on the screen
which correspond with different levels
button("Level Two", 475, 100, 250, 100, YELLOW, BRIGHT_YELLOW, level_two)
button("Level Three", 800, 100, 250, 100, YELLOW, BRIGHT_YELLOW, level_three)
button("Level Four", 150, 300, 250, 100, YELLOW, BRIGHT_YELLOW, level_four)
button("Level Five", 475, 300, 250, 100, YELLOW, BRIGHT_YELLOW, level_five)
button("Level Six", 800, 300, 250, 100, YELLOW, BRIGHT_YELLOW, level_six)

pygame.display.update()
clock.tick(60)

# Level One Loop

===================================================================================

# This code is the same for each of the different levels with different platforms,
flies and variable names corresponding with each level

def level_one():
print ("Level One Load")
level_select_run = False # Sets the boolean variable of
level_select_run to False

P a g e 51 | 70
 level_one_run = True # Sets the boolean variable of
level_one_run to True
main_menu_run = False # Sets the boolean variable of
main_menu_run to False
score = 0 # Sets the score to 0

flyGroup = pygame.sprite.Group() # Creates a sprite group named

'flyGroup' for the fly objects to be added to

fly1 = flies.fly(250, 200) # Creates the different flies and

their correponding locations, adding then to the flyGroup
flyGroup.add(fly1)
fly2 = flies.fly(300, 350)
flyGroup.add(fly2)
fly3 = flies.fly(650, 500)
flyGroup.add(fly3)
fly4 = flies.fly(1000, 300)
flyGroup.add(fly4)

platforms = map.loadLevel(map.level1) # Sets the platform variable as the

level1 2D array and uses the loadLevel function

player.x = 0
player.y = 450

startTime = pygame.time.get_ticks()

while level_one_run: # Creates a while loop whilst the

level one boolean variable is true

for event in pygame.event.get(): # Allows the player to quit pygame if

the quit window button is pressed
#print (event)
if event.type == pygame.QUIT:
pygame.quit()
quit()

gameDisplay.fill(AQUA) # Fills the background as the constant

AQUA

platforms.draw(gameDisplay) # Draws the platforms onto the

gameDisplay
playerGroup.update(platforms) # Updates the playerGroup 'platforms'

flyGroup.update() # Updates the flyGroup

playerGroup.draw(gameDisplay) # Draws the playerGroup onto the
gameDisplay

P a g e 52 | 70
 flyGroup.draw(gameDisplay) # Draws the flyGroup onto the
gameDisplay

if pygame.sprite.spritecollide(player, flyGroup,
True): # if the player collides with a fly, then the score is
incremented by one
score += 1

# X, Y, Length, Height
pygame.draw.rect(gameDisplay, SLATE, pygame.Rect(0, 550, 1200, 100))
button("Level Select", 150, 575, 150, 50, GREEN, BRIGHT_GREEN,
level_select) # A button which allows the player to go back to the level selection
screen
button("QUIT", 900, 575, 150, 50, RED, BRIGHT_RED,
quitgame) # A button which allows the player to quit the game

if (convert_millis(30000 - (pygame.time.get_ticks() -
startTime))).split(":")[0] == "59": # An if statement which loads the game_over
function if the timer runs out
game_over()

if len(flyGroup) ==
0: # An if
statement which loads the game_win function if the flyGroup value reaches 0
game_win()

smallText = pygame.font.SysFont("roboto", 75)

textSurf, textRect = text_objects(convert_millis(30000 -
(pygame.time.get_ticks() - startTime)), smallText) # Creates the timer
textRect.center = ((display_width/2), 600)

gameDisplay.blit(textSurf,textRect) # Displays the timer on the screen

pygame.display.update()
clock.tick(60)

#Level Two Loop

===================================================================================

def level_two():
print ("Level Two Load")
level_select_run = False
level_two_run = True
main_menu_run = False
score = 0

flyGroup = pygame.sprite.Group()

P a g e 53 | 70
 fly1 = flies.fly(200, 500)
flyGroup.add(fly1)
fly2 = flies.fly(300, 300)
flyGroup.add(fly2)
fly3 = flies.fly(650, 500)
flyGroup.add(fly3)
fly4 = flies.fly(900, 400)
flyGroup.add(fly4)

platforms = map.loadLevel(map.level2)

player.x = 0
player.y = 450

startTime = pygame.time.get_ticks()

while level_two_run:

for event in pygame.event.get():

#print (event)
if event.type == pygame.QUIT:
pygame.quit()
quit()

gameDisplay.fill(AQUA)

platforms.draw(gameDisplay)
playerGroup.update(platforms)

flyGroup.update()
playerGroup.draw(gameDisplay)
flyGroup.draw(gameDisplay)

if pygame.sprite.spritecollide(player, flyGroup, True):

score += 1

# X, Y, Length, Height
pygame.draw.rect(gameDisplay, SLATE, pygame.Rect(0, 550, 1200, 100))
button("Level Select", 150, 575, 150, 50, GREEN, BRIGHT_GREEN, level_select)
button("QUIT", 900, 575, 150, 50, RED, BRIGHT_RED, quitgame)

if (convert_millis(30000 - (pygame.time.get_ticks() -
startTime))).split(":")[0] == "59":
game_over()

if len(flyGroup) == 0:
game_win()

smallText = pygame.font.SysFont("roboto", 75)

P a g e 54 | 70
 textSurf, textRect = text_objects(convert_millis(30000 -
(pygame.time.get_ticks() - startTime)), smallText)
textRect.center = ((display_width/2), 600)

gameDisplay.blit(textSurf,textRect)

pygame.display.update()
clock.tick(60)

#Level Three Loop

===================================================================================

def level_three():
print ("Level Three Load")
level_select_run = False
level_three_run = True
main_menu_run = False
score = 0

flyGroup = pygame.sprite.Group()

fly1 = flies.fly(200, 500)

flyGroup.add(fly1)
fly2 = flies.fly(300, 300)
flyGroup.add(fly2)
fly3 = flies.fly(650, 500)
flyGroup.add(fly3)
fly4 = flies.fly(900, 400)
flyGroup.add(fly4)

platforms = map.loadLevel(map.level3)

player.x = 0
player.y = 450

startTime = pygame.time.get_ticks()

while level_three_run:

for event in pygame.event.get():

#print (event)
if event.type == pygame.QUIT:
pygame.quit()
quit()

gameDisplay.fill(AQUA)

platforms.draw(gameDisplay)

P a g e 55 | 70
 playerGroup.update(platforms)

flyGroup.update()
playerGroup.draw(gameDisplay)
flyGroup.draw(gameDisplay)

if pygame.sprite.spritecollide(player, flyGroup, True):

score += 1

# X, Y, Length, Height
pygame.draw.rect(gameDisplay, SLATE, pygame.Rect(0, 550, 1200, 100))
button("Level Select", 150, 575, 150, 50, GREEN, BRIGHT_GREEN, level_select)
button("QUIT", 900, 575, 150, 50, RED, BRIGHT_RED, quitgame)

if (convert_millis(30000 - (pygame.time.get_ticks() -
startTime))).split(":")[0] == "59":
game_over()

if len(flyGroup) == 0:
game_win()

smallText = pygame.font.SysFont("roboto", 75)

textSurf, textRect = text_objects(convert_millis(30000 -
(pygame.time.get_ticks() - startTime)), smallText)
textRect.center = ((display_width/2), 600)

gameDisplay.blit(textSurf,textRect)

pygame.display.update()
clock.tick(60)

#Level Four Loop

===================================================================================

def level_four():
print ("Level Four Load")
level_select_run = False
level_four_run = True
main_menu_run = False
score = 0

flyGroup = pygame.sprite.Group()

fly1 = flies.fly(200, 500)

flyGroup.add(fly1)
fly2 = flies.fly(300, 300)
flyGroup.add(fly2)
fly3 = flies.fly(650, 500)
flyGroup.add(fly3)

P a g e 56 | 70
 fly4 = flies.fly(900, 400)
flyGroup.add(fly4)

platforms = map.loadLevel(map.level4)

player.x = 0
player.y = 450

startTime = pygame.time.get_ticks()

while level_four_run:

for event in pygame.event.get():

#print (event)
if event.type == pygame.QUIT:
pygame.quit()
quit()

gameDisplay.fill(AQUA)

platforms.draw(gameDisplay)
playerGroup.update(platforms)

flyGroup.update()
playerGroup.draw(gameDisplay)
flyGroup.draw(gameDisplay)

if pygame.sprite.spritecollide(player, flyGroup, True):

score += 1

# X, Y, Length, Height
pygame.draw.rect(gameDisplay, SLATE, pygame.Rect(0, 550, 1200, 100))
button("Level Select", 150, 575, 150, 50, GREEN, BRIGHT_GREEN, level_select)
button("QUIT", 900, 575, 150, 50, RED, BRIGHT_RED, quitgame)

if (convert_millis(30000 - (pygame.time.get_ticks() -
startTime))).split(":")[0] == "59":
game_over()

if len(flyGroup) == 0:
game_win()

smallText = pygame.font.SysFont("roboto", 75)

textSurf, textRect = text_objects(convert_millis(30000 -
(pygame.time.get_ticks() - startTime)), smallText)
textRect.center = ((display_width/2), 600)

gameDisplay.blit(textSurf,textRect)

P a g e 57 | 70
 pygame.display.update()
clock.tick(60)

#Level Five Loop

===================================================================================

def level_five():
print ("Level Five Load")
level_select_run = False
level_five_run = True
main_menu_run = False
score = 0

flyGroup = pygame.sprite.Group()

fly1 = flies.fly(200, 500)

flyGroup.add(fly1)
fly2 = flies.fly(300, 300)
flyGroup.add(fly2)
fly3 = flies.fly(650, 500)
flyGroup.add(fly3)
fly4 = flies.fly(900, 400)
flyGroup.add(fly4)

platforms = map.loadLevel(map.level5)

player.x = 0
player.y = 450

startTime = pygame.time.get_ticks()

while level_five_run:

for event in pygame.event.get():

#print (event)
if event.type == pygame.QUIT:
pygame.quit()
quit()

gameDisplay.fill(AQUA)

platforms.draw(gameDisplay)
playerGroup.update(platforms)

flyGroup.update()
playerGroup.draw(gameDisplay)
flyGroup.draw(gameDisplay)

if pygame.sprite.spritecollide(player, flyGroup, True):

P a g e 58 | 70
 score += 1

# X, Y, Length, Height
pygame.draw.rect(gameDisplay, SLATE, pygame.Rect(0, 550, 1200, 100))
button("Level Select", 150, 575, 150, 50, GREEN, BRIGHT_GREEN, level_select)
button("QUIT", 900, 575, 150, 50, RED, BRIGHT_RED, quitgame)

if (convert_millis(30000 - (pygame.time.get_ticks() -
startTime))).split(":")[0] == "59":
game_over()

if len(flyGroup) == 0:
game_win()

smallText = pygame.font.SysFont("roboto", 75)

textSurf, textRect = text_objects(convert_millis(30000 -
(pygame.time.get_ticks() - startTime)), smallText)
textRect.center = ((display_width/2), 600)

gameDisplay.blit(textSurf,textRect)

pygame.display.update()
clock.tick(60)

#Level Six Loop

===================================================================================

def level_six():
print ("Level Five Load")
level_select_run = False
level_six_run = True
main_menu_run = False
score = 0

flyGroup = pygame.sprite.Group()

fly1 = flies.fly(200, 500)

flyGroup.add(fly1)
fly2 = flies.fly(300, 300)
flyGroup.add(fly2)
fly3 = flies.fly(650, 500)
flyGroup.add(fly3)
fly4 = flies.fly(900, 400)
flyGroup.add(fly4)

platforms = map.loadLevel(map.level6)

player.x = 0
player.y = 450

P a g e 59 | 70
 startTime = pygame.time.get_ticks()

while level_six_run:

for event in pygame.event.get():

#print (event)
if event.type == pygame.QUIT:
pygame.quit()
quit()

gameDisplay.fill(AQUA)

platforms.draw(gameDisplay)
playerGroup.update(platforms)

flyGroup.update()
playerGroup.draw(gameDisplay)
flyGroup.draw(gameDisplay)

if pygame.sprite.spritecollide(player, flyGroup, True):

score += 1

# X, Y, Length, Height
pygame.draw.rect(gameDisplay, SLATE, pygame.Rect(0, 550, 1200, 100))
button("Level Select", 150, 575, 150, 50, GREEN, BRIGHT_GREEN, level_select)
button("QUIT", 900, 575, 150, 50, RED, BRIGHT_RED, quitgame)

if (convert_millis(30000 - (pygame.time.get_ticks() -
startTime))).split(":")[0] == "59":
game_over()

if len(flyGroup) == 0:
game_win()

smallText = pygame.font.SysFont("roboto", 75)

textSurf, textRect = text_objects(convert_millis(30000 -
(pygame.time.get_ticks() - startTime)), smallText)
textRect.center = ((display_width/2), 600)

gameDisplay.blit(textSurf,textRect)

pygame.display.update()
clock.tick(60)

#Convert Millis to
Seconds===============================================================================
====

P a g e 60 | 70
def convert_millis(time):
millis = str(time)[-3:-1]
secs = (time / 1000) % 60

if len(str(math.floor(secs))) > 1: secs = math.floor(secs)

else: secs = "0"+str(math.floor(secs))

return str(f"{secs}:{millis}")

def game_over(): #
This is the function for the game over screen
level_select_run = False

while True:
for event in pygame.event.get():
#print (event)
if event.type == pygame.QUIT:
pygame.quit()
#Sets the screen's background colour (OR IMAGE)
gameDisplay.fill(BLUE1)
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(0, 600, 1200, 50)) #
Creates rectangles on the display purely for aesthetic purposes
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(0, 0, 1200, 50))
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(1150, 0, 50, 650))
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(0, 0, 50, 650))
pygame.draw.rect(gameDisplay, WHITE, pygame.Rect( 375, 90, 450, 75))
#Sets the screen's text size and font
largeText = pygame.font.SysFont("roboto", 75)
TextSurf, TextRect = text_objects("GAME OVER!", largeText)
#Sets the position of the Title Text
TextRect.center = ((display_width / 2), (display_height / 5))
titlerect = (490,250)
gameDisplay.blit(frog_pic, titlerect)
gameDisplay.blit(TextSurf, TextRect)

#Creates the BUTTONS

#message, xpos, ypos, buttonwidth, buttonheight, buttoncolour, buttonhover,
action = None
button("PLAY", 150, 400, 200, 50, GREEN, BRIGHT_GREEN, level_select)
button("QUIT", 850, 400, 200, 50, RED, BRIGHT_RED, quitgame)

pygame.display.update()
clock.tick(60)

def game_win(): #
This is the function for the game win screen
level_select_run = False

while True:

P a g e 61 | 70
 for event in pygame.event.get():
#print (event)
if event.type == pygame.QUIT:
pygame.quit()
#Sets the screen's background colour (OR IMAGE)
gameDisplay.fill(BLUE1)
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(0, 600, 1200, 50)) #
Creates rectangles on the display purely for aesthetic purposes
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(0, 0, 1200, 50))
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(1150, 0, 50, 650))
pygame.draw.rect(gameDisplay, GRAY, pygame.Rect(0, 0, 50, 650))
pygame.draw.rect(gameDisplay, WHITE, pygame.Rect( 375, 90, 450, 75))
#Sets the screen's text size and font
largeText = pygame.font.SysFont("roboto", 75)
TextSurf, TextRect = text_objects("YOU WIN!", largeText)
#Sets the position of the Title Text
TextRect.center = ((display_width / 2), (display_height / 5))
titlerect = (490,250)
gameDisplay.blit(frog_pic, titlerect)
gameDisplay.blit(TextSurf, TextRect)

#Creates the BUTTONS

#message, xpos, ypos, buttonwidth, buttonheight, buttoncolour, buttonhover,
action = None
button("PLAY", 150, 400, 200, 50, GREEN, BRIGHT_GREEN, level_select)
button("QUIT", 850, 400, 200, 50, RED, BRIGHT_RED, quitgame)

pygame.display.update()
clock.tick(60)

#Quit Game
def quitgame(): # This function allows the player to quit the game
pygame.quit()

main_menu() # This calls the function 'main_menu' and allows the

game to begin
level_select() # This calls the function 'level_select' and allows
the game to run the level selection screen

P a g e 62 | 70
File Name: moving_sprite.py

import pygame

class player(pygame.sprite.Sprite): # Creates a class called player

def __init__(self): # __init__ initialises when the

class is created
super().__init__() # Calls the __init__ function from
the pygame.sprite.Sprite class
self.image = pygame.image.load('frog_sprite.png') # Loads the frog image
self.rect = self.image.get_rect() # Gets the rect from the image of
the frog
self.x = self.y = 0 # Sets the initial position of the
frog to be (0,0)
self.pos = pygame.math.Vector2(self.x, self.y) # Sets pos to be a
pygame.math.Vector2 which is like a coordinate system but better
self.rect.topleft = self.pos # Sets the top left of the frog
sprite to be where the variable pos is
self.hit = False

def update(self, platforms):

self.hit = False # Update function to be called
once per frame for physics and movement

if self.y > 450:

self.y = self.y; self.rect.top = 450
else: self.y += 5

hits = pygame.sprite.spritecollide(self, platforms, False)

if len(hits) != 0:
for i in range(len(hits)):
# if self.rect.bottom > hits[i].rect.top:
# print("TRUE")
# self.rect.bottom = hits[i].rect.top
# self.hit = True

if self.rect.right > hits[i].rect.left and self.rect.left >

hits[i].rect.right:
self.rect.right = hits[i].rect.left
self.hit = True

elif self.rect.left < hits[i].rect.right and self.rect.right <

hits[i].rect.left:
self.rect.left = hits[i].rect.right
self.hit = True

elif self.rect.top < hits[i].rect.bottom and self.rect.bottom >

hits[i].rect.bottom:
self.rect.top = hits[i].rect.bottom

P a g e 63 | 70
 self.hit = True

self.x = self.rect.left
self.y = self.rect.top

self.pos.x = self.x # Sets the pos vector to

the correct positions
self.pos.y = self.y

self.rect.topleft = self.pos

# if not self.hit:

keys = pygame.key.get_pressed() # Gets the list of keys

pressed
if keys[pygame.K_UP] or keys[pygame.K_w]: # Checks to see if the up arrow
has been pressed
if self.y < 0: # Checks if the image is off
screen
self.rect.left = 0 # Puts the image back onto the
screen
else: self.y -= 10 # else moves the image up

# if keys[pygame.K_DOWN] or keys[pygame.K_s]: # Checks to see if the down

arrow has been pressed
# if self.y > 410: # Checks if the image is off
screen #463
# self.rect.top = 410 # Puts the image back onto the
screen
# else: self.y += 5 # else moves the image down

if keys[pygame.K_LEFT] or keys[pygame.K_a]: # Checks to see if the left arrow

has been pressed
if self.x < 0: # Checks if the image is off
screen
self.rect.left = 0 # Puts the image back onto the
screen
else: self.x -= 5 # else moves the image left

if keys[pygame.K_RIGHT] or keys[pygame.K_d]: # Checks to see if the right arrow

has been pressed
if self.x > 1112: # Checks if the image is off
screen
self.rect.left = 1112 # Puts the image back onto the
screen
else: self.x += 5 # else moves the image right

P a g e 64 | 70
 self.pos.x = self.x # Sets the pos vector to the
correct positions
self.pos.y = self.y

self.rect.topleft = self.pos # Changes the position of the

sprite with the new positions

P a g e 65 | 70
File Name: map.py

import pygame

level1 = [['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', 'x', 'x', '0', '0', '0', '0', '0', 'x', 'x', '0', '0', '0', '0', 'x', 'x',
'0', '0', '0', '0', '0', 'x', 'x', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', 'x', 'x', '0', '0', '0', '0', 'x', 'x',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', 'x', 'x', '0', '0', 'x', 'x', '0', '0', '0', '0', '0', '0', 'x',
'x', '0', '0', 'x', 'x', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', 'x', 'x', 'x', 'x', 'x', 'x', 'x', 'x',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],]

level2 = [['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['x', 'x', '0', '0', '0', 'x', 'x', 'x', 'x', 'x', '0', '0', '0', '0', 'x', 'x',
'x', 'x', 'x', '0', '0', '0', 'x', 'x'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['x', 'x', 'x', '0', '0', '0', 'x', 'x', 'x', 'x', 'x', 'x', 'x', 'x', 'x', 'x',
'x', 'x', '0', '0', '0', 'x', 'x', 'x'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['x', 'x', 'x', 'x', '0', '0', '0', 'x', 'x', 'x', 'x', 'x', 'x', 'x', 'x', 'x',
'x', '0', '0', '0', 'x', 'x', 'x', 'x'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],]

P a g e 66 | 70
level3 = [['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],]

level4 = [['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],]

level5 = [['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],

P a g e 67 | 70
 ['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],]

level6 = [['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],
['0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0', '0'],]

class platform(pygame.sprite.Sprite):

def __init__(self, x,y): # This is the initialisation of the

platforms
super().__init__()
self.image = pygame.Surface((50,50)) # This creates the image of the
platform being a 50 by 50 pixel square on the display

P a g e 68 | 70
 self.image.fill((128,71,28)) # This creates the platforms as a
certain colour
self.rect = self.image.get_rect()
self.rect.topleft = 50*x , 50*(y)

def loadLevel(level): # This is a function which allows the

levels to be loaded
platforms = pygame.sprite.Group() # This creates a sprite group called
platforms
for i, row in enumerate(level): # The following code is used to
naviate the 2D array, if there is an 'x' there a platform is registered there and the
platform is added to the sprite group
for j, column in enumerate(row):
if column == "x":
plat = platform(j,i)
platforms.add(plat)

return platforms

P a g e 69 | 70
File Name: flies.py

import pygame

class fly(pygame.sprite.Sprite): # Creates a class called player

def __init__(self, x, y,): # __init__ initialises when

the class is created
super().__init__() # Calls the __init__ function from
the pygame.sprite.Sprite class
self.image = pygame.image.load('flysprite.png')
# self.image = self.image.convert()
self.image.set_colorkey((255,255,255))
self.rect = self.image.get_rect() # Gets the rect from the image of
the fly
self.x = x # Sets the initial position of the fly to be
at pos (x,y)
self.y = y
self.pos = pygame.math.Vector2(self.x, self.y) # Sets pos to be a
pygame.math.Vector2 which is like a coordinate system but better
self.rect.topleft = self.pos # Sets the top left of the fly
sprite to be where the variable pos is
self.hit = False

P a g e 70 | 70