Puzzle Game Documentation Sarah Crafton January 2020

 1.  Basic Research and Design
 2.  Development
 3.  Testing And Feedback
 4.  Resources:

1. Basic Research and Design

When designing my puzzle, my first thought was to create a game based around audio cues/sounds. This is because I want to explore the UE4 audio components further and expand my knowledge of this aspect. Furthermore, after the games jam I wanted to create a game where the use of headphones/speakers was essential to the game’s core mechanics after my work in that area got brushed over by players, motivating me to ensure it could not be ignored.

My initial ideas for mechanics were based on my experience with classical music examinations – specifically the exam board ABRSM. These are generally split into 3 sections: playing 3 practised pieces, scales and aural. The main section I drew inspiration from was aural as it is made up of a series of tests that check rhythm, pattern recognition and general musicality. Specifically, there is a test where a melody is played to you by the examiner and you need to repeat it back. I felt that this would adapt well into a game mechanic.

To make it easier than the test, I decided that the players would need all the correct notes for the melody available to them as people with little musical experience would struggle to pick the correct notes out of a full piano’s worth. Also, I decided not to penalise the player for incorrect attempts, as I wanted to give them plenty of room for trial and error; particularly as players with no music training would be disproportionately affected.


From here I solidified my concept. I would give the player a set of note blocks that they need to place on a series of platforms in the correct order. They can check the pattern they need to match at any time, and separately they can submit their pattern if they think it’s correct. If the player submits an incorrect pattern, I play it back to them followed by the correct pattern to help them to hear the difference.


To add some difficulty progression to the game, I can either add chords, cadences and inversions or different instruments that play together. To add chords, I needed to allow the platforms to register more than one cube, which would then allow for cadences to be added as these are chord patterns. To add inversions and different instruments I would need to add different audio samples which would be simple to do. However, the more instruments/sound samples I add the more complicated the sound mapping would get so this would be an interesting limiting factor to consider.

2. Development

As I only had 2 weeks to work on this project, I decided to focus on getting my minimum viable product (MVP) ready first so that I would have a game to submit. I defined this as:

  • A movable 3rd person character
  • A complete, winnable level
  • A way for the player to play the pattern they need to match
  • A method for the player to submit a pattern

By keeping my MVP as simple as possible, it meant that I was able to complete it within my first day of development. Furthermore, as I did a lot of planning beforehand and I solidified my concept before I began programming, it was easier to focus on getting the game working rather than needing to decide on features on the fly. Initially, I even used sounds built into UE4 to substitute for music notes – including the infamous compile failed noise.

Once I had my MVP completed I decided to work on my audio assets. I decided to record MIDI notes using Ableton Live 10 at different pitches as this would be quick and give me the flexibility to add additional pitches where needed in the future. I also wanted to make it easier to tell the different note blocks apart so I created several basic pastel materials. This also meant that if I wanted to use more than one of the same note, I could give their cube the same colour to give a visual cue that they are identical.

As I had started with a blank project I didn’t have any animations on my character, so I decided to attempt to import the animations and character model from the third person base project. This did not go according to plan and resulted in a few errors involving the materials and animations I had attempted to import. At this point, I decided it wasn’t worth my time to tinker with the character model further and deleted the broken mess from my project. I also decided that if I had time at the end of the project I would attempt to animated the character again.


The next part of the project I worked on was a sound manager and mapping system. I decided to centralise all audio playback to a sound manager object to give myself easier control and speedier debugging. Rather than needing to give each cube a sound cue component, I instead used a map to access the sound cues. A map works by creating a relationship between two different pieces of data using key-value pairs. For the map I used an integer as the key and paired each key with a sound cue. Then, I gave each cube an integer value that would map to a sound in this map thereby reducing the amount of memory each cube required. This also meant that I didn’t have duplicate sound cues loaded when I had cubes with the same sound.

When the player submits a pattern, it is checked immediately against the correct pattern for the level – before the sounds are played. If the player is correct, then the pattern is passed to the sound manager and played before the level is completed. If the player is incorrect, their pattern is played, followed by the correct pattern so that they have the opportunity to immediately hear the differences. To play the patterns I use a timer event – this fires every time the game attempts to play a sound pattern. The timer event stops multiple sound patterns playing at once, so that the player doesn’t defean themselves.


I created some basic UI to enable the player to proceed to the next level or quit to the main menu. Initially I had the UI in separate levels, but I decided this felt weird when playing the game so I changed it to overlay on the level when the player completes the puzzle.

The last major feature I added was the ability to submit and create chords. I wanted the player to be able to place more than one block on a platform and have it play both notes at the same time – even if the pairing was incorrect. At first, I created new sound cues for each chord that I wanted to create. This was a bad idea as it limited me to the chords that I had prepared previously as well as it meant that if a player submitted an incorrect chord it wouldn’t map to anything, so no sound would play.

To play chords I added a branch to my play pattern event in my sound manager. This branch would redirect any chord patterns (those with more than one sound) to a for loop that would go through each integer given and play the corresponding sound. This would effectively play each note at the same time, as the human ear wouldn’t be able to tell a frames difference.


3. Testing And Feedback

For gathering feedback on my game I decided to use a Google Form as it allows me to create different categories of questions and neatly organises the responses.
My questions on the form were regarding:

  • Name
  • Levels Beat
  • Previous Music Experience
  • Ease of Play
  • Clarity of Game Play
  • Frustrations
  • Positives
  • Improvements
  • Other Feedback
I got 10 responses to my game, giving me a good range of feedback.


Overall, most people only beat level 1 but if they beat level 2 they would also beat level 3. I also find it interesting that so long as you beat the first level, players were more likely to also beat the final level.


All the responses to the music theory experience question rated themselves as below 5, this either shows that my sample population was biased to not having any music training or people were consistently underreporting their practice. However, by having this biased data set it tells me that people were able to understand and play the game successfully without a great deal of prior music theory knowledge.

Based on the responses to the controls question I now know that I needed to make it clearer within the first level. Currently the only controls explanation was given on the title screen, meaning that if players forgot the controls or didn’t read the instructions, they’d be confused as to how to play. Furthermore, I didn’t make it clear enough what different blocks did within the level. To rectify these issues I will add in either signs that explain what everything does, or add in a small quest style tutorial to make the controls and gameplay mechanics clearer. This will also help when introducing additional mechanics such as chords as when observing the players there was variable success in figuring out that they could put more than one cube on a platform to create a chord.


Interestingly, half of players found the game frustrating due to difficulty determining errors with their box placement as they couldn’t tell when blocks were incorrect. To fix this, I could add a hint system that highlights boxes red that are in the incorrect place. This would make the game easier for those that can’t immediately discern where they’ve made a mistake, while still maintaining the difficulty for those that could hear the disparities.

I got a lot of feedback that people liked the game concept and colour scheme, which was encouraging, as well as two people who thought that the difficulty scaled appropriately. I think that this is a good indication that I have a solid idea that I can develop further to create a simple game.

In my final feedback section, players generally had nothing to say, other than a suggestion to add some additional information to the first level on how to play which I plan on doing in the future.

Overall, I feel that my feedback was generally positive, and had constructive ideas on how to improve the game. It also demonstrated to me the viability of the idea which gives me the confidence to take it further. Since the code test I have made one change which Aaron suggested to me which was to make the individual cubes light up when they are playing a sound in a similar fashion to the platforms.

4. Resources:


Google Form:

How Streets of Rage 2 used the Mega Drive Hardware to Create an Iconic Soundtrack

Streets of Rage 2 – called Bare Knuckle 2 in Japan – is a scrolling beat ‘em up video game that was developed by Ancient and released for the SEGA Mega Drive/Genesis console in 1992. It featured 4 playable characters – Axel and Blaze who were in the first game, as well as 2 new additions Max and Skate. The game offered players a range of combination attacks that they could use with each character, and a new versus mode where players could test their skills against each other. They could use any one of the game’s 8 stages to fight each other in, with a range of weaponry scattered around the stage. Due to its 5 difficulty levels and ability for players to choose how many lives they started the game with, Streets of Rage 2 had a low barrier to entry while still offering a challenging experience to fans of the series. Yuzo Koshiro who composed the soundtrack for the original Streets of Rage game returned for the sequel, writing all of the game’s music and sound effects except for 3 tracks which were written by Motohiro Kawashima.

When discussing Streets of Rage 2, strafefox (2018) said that it was one of the first SEGA games to be put on a 16 megabit cartridge which was 4 times the size of the cartridge for the original game. This allowed for more detail in the game overall, as well as additional space for sound effects and music. According to Ayano Koshiro – the head designer at Ancient – they only had around half a year of development time which makes the technical achievements of the game all the more impressive.

The SEGA Mega Drive was released in 1988 in Japan, 1989 in North America and 1990 for Europe. It was unique for the time as it had two on-board processors – the 6800 and Z80. The Z80 handled audio and had a 4 MHz maximum clock speed while the 6800 was in charge of all other operations and was faster with a clock speed of 7.61 MHz. The 6800 was actually a 32-bit processor that took in a 16-bit bus while the Z80 was an 8-bit processor (Mitchell, R, 2016). This meant that if lots of operations were happening at once, the music and sound effects of the game would be unaffected by any strain on the core processor (Mitchell R, 2016). By isolating the sound operations, developers did not need to worry about sounds and music stuttering which created a smoother experience for players.

A 32-bit processor has significantly more computational power than an 8-bit one. This is because it can read data from larger data buses, allowing for more accurate floating point numbers to be used. By increasing the number of bits available for a processor to use, this improves the speed at which it can complete operations. To complete an operation an 8-bit processor will need more instructions than a 32-bit processor, as the size of the commands it can understand is smaller. This meant that the 6800 was significantly more powerful than the Z80 as it took less time for the processor to complete the same action (Bond, K, 2016, p. 489).

The Mega Drive’s capacitors around the headphone jack and YM2612 chip

The Mega Drive also had two ways to output sound – through the RF port for the TV, or a headphone jack on the front of the console. The RF port could only use mono sound, while the headphone jack was capable of stereo. Additionally, it had a volume slider on the front of the console, an unusual feature that gave players finer control over the console’s volume. A reason why they might have added this slider was the headphone jack, as there would have been no other way to change the sound levels. Consequently, the circuit board is covered in capacitors to allow for the audio to be amplified through the port.

For producing sounds, the console once again had 2 chips – the YM2612 and an SN76489A clone that was integrated into the Z80. This was because the console was designed to be backwards compatible and the SN76489A was the sound chip in the Master System – the Mega Drive’s predecessor. As a result, composers for the system had access to 6 Frequency Modulation (FM) channels and 4 Programmable Sound Generator (PSG) channels which they could use to create music and sound effects. Furthermore, the YM2612 had an integrated digital to analogue converter (DAC) along with stereo sound capabilities (Collins, 2008, p. 40) which allowed for audio panning techniques to be used.

Panning is a technique in sound design which, “creates the illusion of a sound source moving from one part of the soundstage to another.” (Trandafir, 2017). It works by playing audio channels louder in one ear than the other to make it sound as though the audio is coming from a particular side. This can be used to make it feel like sound sources are moving, by changing the levels of channels gradually. Both Koshiro and Kawashima took advantage of the Mega Drive’s ability to produce stereo sound and you can notice this in tracks like Alien Power, Expander and Go Straight where different channels move from left to right throughout the tracks, giving them a more dynamic feel.

FM is a way of representing sound by changing the frequency and shape of the wave, while keeping the amplitude (height) the same. The main waveforms used in FM synthesis are sine, square, saw-tooth and triangle. These each produce a different type of sound with sine waves having a softer sound and more jagged waves like saw-tooth and triangle producing harsher tones. These basic tones could then be edited further to create unique patterns.

The different waveforms that can be produced by FM

According to Koshiro (2014), “With the introduction of FM synthesis, various instruments, like string, wind and percussion instruments, could all be played on one FM chip.” Since composers for the Mega Drive had 6 of these channels to work with, they could layer different waves on top of each other to create more complex sounds than previously possible. In the first level of Streets of Rage 2, Koshiro only uses 5 of these channels, leaving one available for the game’s sound effects. One of the channels on the YM2612 could be used to play sounds that had been recorded prior. Koshiro used this channel to play samples of the kick and snare of a Roland TR-909 (strafefox, 2018) while using FM synthesis to copy the Roland TR-808 drum beats, because they were popular drum machines at the time and he wanted to create an authentic club feel.

“Programmable sound generators (PSGs) are sound chips designed for audio applications that generate sound based on the user’s input.” (Wolf, Mark J. P, 2012). They take in an oscillating wave signal that is tuned to a set MHz value and a series of commands which are then applied to the wave signal, modifying how it sounds.

The SN7648A has 8 registers – 4 for volume control, 3 for generating tones and 1 for creating noise. As it was from a previous generation of consoles, it took its instructions in 8-bits, rather than 16. It can take a clock signal of up to 4MHz and has “a range of 10 octaves” (SMSPower, 2005). This meant that Koshiro was able to add 3 additional sounds to his composition on top of the 5 FM channels he was using from the YM2612, giving him greater depth and complexity in his compositions.

When dealing with real components, they aren’t always perfect, resulting in distortion of waveforms. This was particularly noticeable with the Mega Drive as the SN76489A had problems with the wave decaying towards zero. Furthermore, the YM2612 would truncate its 14-bit output to 9 bits which meant that the sound had to be passed through other circuitry – making the waves distort further (MD, 2015). Due to the distortion of the sound, the Mega Drive had a unique feel, known as the ladder effect as it was the only console that can produce this particular noise (Yuzo Koshiro, 2019).

His knowledge of computer programming and components made Koshiro stand out from other composers at the time since it gave him greater control over what the game sounded like compared to someone who needed a programmer to translate their compositions. When speaking on this subject he said, “I was trying to program on the computer to create sounds. It was really important for me to create music drivers or sound drivers.” (Koshiro, 2017).

To create his music, Koshiro used a variation of Music Macro Language (MML) that he created himself, called Music Love.  MML was a programming language used to notate music using text which had many different variations as it was unique to the interpreter and chips it was being used with. Therefore, it made sense for Koshiro to create his own version suited to the hardware that he was using, especially since it gave him more flexibility in how he could program his sounds as he said in an interview “Since I made my own editor and driver, I could control everything about the chip down to the fine details.” (Koshiro, 2014). The main way he modified it was by changing the language from being based on BASIC to coding “more like Assembly” (Koshiro, 2005).

Before he started to make music for the Mega Drive, Koshiro used the NEC PC-8801 for all his work and he used a variant of MML based on NEC’s particular version of BASIC. Koshiro stated during an interview with Redbull that the PC-8801 and Mega Drive conveniently had, “almost the same FM synthesis chips” (Koshiro, 2017) making music production simpler for him as the sounds he was creating on his PC would be true to how they would sound on the Mega Drive.

When they weren’t working on the game, Koshiro and Kawashima would go to clubs in Tokyo to listen to the newest club music, particularly at places like Yellow (Koshiro, 2017). They would take these new sounds and try to bring them into the game’s music. They were heavily influenced by popular dance music of the time, particularly tracks that came from abroad as both techno and the Mega Drive were more popular in North America and Europe than in Japan. Koshiro even took a trip to LA around 1988, where he “constantly had MTV on at the hotel” and he bought records to take home to Japan with him. He wanted to update the sound of the Streets of Rage franchise, in the same way that club and house music was constantly changing and evolving (Koshiro, 2014).

Streets of Rage 2 is still an influential and popular game to this day, with fans of its music across the globe. Koshiro’s music was so key to the game that he was one of the first video game composers to have a major credit for his work. The way that it uses the hardware is particularly impressive when compared to other games for the console as they had a tendency to sound the same. This was due to composer’s over-reliance on GEMS (Genesis Editor for Music and Sound effects) and the built in library of samples. It was released in 1991, and used in hundreds of games for the console, as it allowed musicians to use the MIDI format that they were comfortable with, rather than needing to learn how to program.

Both Koshiro and Kawashima continued to be successful game composers and they went on their Diggin’ in the Carts world tour in 2017 where they exclusively played music from game soundtracks that they composed together. Streets of Rage 2 was an introduction to techno music to many young people, and the game was a successful sequel although Streets of Rage 3 was less well received. Streets of Rage 4 has recently been announced for a 2019 release, leaving fans excited and questioning whether Koshiro will be returning to the franchise, 25 years later to write one more soundtrack.

(Word Count: 2029)


AugmentedVisionVideo (2014) Mega Drive Deconstruction – Streets of Rage 2: Go Straight. Available at: https://www.youtube.com/watch?v=BA7XcAt15_0 (Accessed: 04/05/2019).

Ancient (1992) Streets of Rage 2/Bare Knuckle II. [Video game]. SEGA.

Avery, M (2017) An Introduction to FM Synthesis. Available at: https://flypaper.soundfly.com/produce/an-introduction-to-fm-synthesis/ (Accessed: 04/05/2019).

Bond, K. R. (2016) AS Computer Science For AQA Units 1 & 2. Bucks: Educational Computing Services Ltd.

Collins, K. (2008) Game Sound: An Introduction to the History, Theory, and Practice of Video Game Music and Sound Design.  Cambridge, MA: MIT Press.

Dwyer, N. (2014) Interview: Streets of Rage Composer Yuzo Koshiro. Available at: https://daily.redbullmusicacademy.com/2014/09/yuzo-koshiro-interview (Accessed: 04/05/2019).

Dwyer N. (2017) Yuzo Koshiro. Available at: https://www.redbullmusicacademy.com/lectures/yuzo-koshiro (Accessed: 04/05/2019).

Kikizo, (2005) Yuzo Koshiro Interview. Available at: http://archive.videogamesdaily.com/features/yuzo_koshiro_iv_oct05_p2.asp (Accessed: 02/05/2019).

MD (2015) YM2612. Available at: http://md.railgun.works/index.php/YM2612 (Accessed: 07/05/19).

Mitchell, R (2016) Retro Teardown: The Sega Genesis. Available at: https://www.allaboutcircuits.com/news/retro-teardown-sega-genesis-sega-mega-drive-eu/ (Accessed: 04/05/19).

SEGA Retro GEMS. Available at: https://segaretro.org/GEMS (Accessed: 07/05/2019).

Shmuplations (2000) Streets of Rage 2 – Developer Interview with Ayano Koshiro (designer/planner) of Ancient. Available at: http://shmuplations.com/streetsofrage2/ (Accessed: 06/05/2019).

Strafefox (2013) Sega Mega Drive/Genesis Music. Available at: https://www.youtube.com/watch?v=jLNKUT2ZbDI (Accessed: 04/05/2019).

Strafefox (2018) The making of Streets of Rage 2. Available at: https://www.youtube.com/watch?v=Yb3TEywgwMU (Accessed: 01/05/2019).

Trandafir, L. (2017) Audio Effects: The Beginner’s Guide to Shaping Your Sound. Available at: https://blog.landr.com/audio-effects-plugins-guide/ (Accessed: 05/05/19).

Wolf, Mark J. P. (2012) Before the Crash: Early Video Game History. Detroit, Michigan: Wayne State University Press.

Woodford, C (2018) Synthesizers. Available at: https://www.explainthatstuff.com/synthesizers.html (Accessed: 04/05/2019).

Yuzo Koshiro (2019) [Twitter] 4 April. Available at: https://twitter.com/yuzokoshiro/status/1113854271890415618 (Accessed: 07/05/2019).

Experimenting with an Arduino and a SN76489. Available at:  http://danceswithferrets.org/geekblog/?p=93 (Accessed: 04/05/2019).

Music Macro Language. Available at: http://www.vgmpf.com/Wiki/index.php/Music_Macro_Language (Accessed: 04/05/19).

SN76489. Available at: http://www.smspower.org/Development/SN76489 (Accessed: 04/05/2019).

Iteration 2 – Testing Evaluation

The final version of the game can be found here

For testing, I wanted to take a more hands-off approach than in Iteration 1. This was because I wanted to see how a user would naturally respond to what was on-screen as this would provide useful feedback as to how intuitive the UI design was.

My testing objectives were:

  • To see if my UI could be figured out by the user without any input on my behalf.
  • To see how players prefer to play the game – more upgrades or more tentacles?
  • To see if viewing the tutorial made any difference on a player’s success at the game.
  • To find out what players thought the primary objective/theme of the game was.

From these objectives, I compiled a list of questions I wanted to ask my testers, as well as any quantitative data that I wished to track. These questions would give me my qualitative data:

  1. How were the controls to use?
  2. What was the aim of the game?
  3. How did you find the UI? Was it clear what everything did?
  4. Any other feedback?

I wanted to see how different player choices stacked up against how much health they had left at the end of the game. Players tended to have more health if they went for a mixture of upgrades and tentacles, whereas players that either forgot to upgrade or summon regularly tended to suffer. However, I do not think that the data shows one dominant strategy which is what I wanted: I didn’t want players to feel forced to always go for one path and I believe that I have given them good flexibility.

I asked players to rate the games fun and difficulty on a scale of 1 – 10. I did this to see if players who thought the game was more difficult also found the game less fun, or if they thought the game was too easy and therefore boring. However, after looking at my graph, I can see no correlation between a player’s fun and difficulty ratings for the game. I was pleased that the average fun rating was high and had little variation as it shows a strong enjoyment across the board. I found the changes in the difficulty interesting, as there was no clear trend, and I do not think the average accurately represents the data. There was high variation in the data, with a range of 1 – 7. I think this is a result of personal player preferences, rather than inconsistencies in how the game plays.

Generally speaking I got positive feedback on the controls, but a suggestion I was given was to explain the drag and drop mechanic during the tutorial, as Brad found that he would forget to drag the tentacles the first time. After that, no players would have issues with remembering how the mechanic worked.

Interestingly, there was some variation in how players responded when asked about the aim of the game. 5 people discussed protecting yourself/keep yourself alive whereas 4 responses were about killing all the enemies that come to attack you. While these are very similar, it was cool to see the different interpretations of the game’s aim.

When I asked the testers if the UI was clear, there was a split in the responses. 4 players said that they either needed the tutorial to understand, or that it made the UI significantly clearer, while the rest said that it was clear what the UI did without the prior explanation.

After asking my testers for any additional feedback, 3 people asked for more monsters that they could summon. This is a feature that I would like to add in the future, but I had decided that it was out of scope for this project. Another suggestion was that the tentacles could change in some way visually whenever you upgrade them, to give the player more feedback that the upgrade had made a difference. I really like this idea, and it would be a feature that I would add in the future. It is a common way of showing progression in other games within this genre and it would give the game more visual variety.

Iteration 2 Easter Reflective Journal

For the first two weeks of the Easter break, I took the time off to relax and refresh myself so that I could look at my game with a new perspective. This allowed me to identify some minor errors that I had left in the code, like incorrect frame numbers and icons being in a slightly odd position.

I admittedly did take a few shortcuts, on some features that I added, but I don’t feel that the overall quality of the game is reduced due to this. For example, instead of an interactive tutorial, I have used a diagram and for my pause button I use a click anywhere to resume the game rather than duplicating my existing button.

Now that I’m at the end of the Easter break, I feel satisfied that I have met all of the goals that I originally gave to myself at the start of the project. I definitely found that using a goals based system rather than assigning tasks to set dates gave me the flexibility that I needed – especially given my difficulties with getting any coding done during Week 2 of the project.

For testing, my target device is a Google Pixel. I chose this phone because it’s the one that I have and I feel that most games or websites are designed with other, more popular phones in mind such as the Samsung S8/9 or iPhone X. As I have added resize and scaling functionality, it would be nice if I could test on two devices but it’s more important that I get thorough data on how the game plays on the Pixel as it is my main target device.

Personally, I like to write my test data on paper, by hand, as it allows me to add any observations that I make or that the user makes but forgets to mention during the post-game feedback. The main parts of the game that I want to get feedback on are the UI due to the major changes to it, if the game works on the server correctly and how interactive the game feels to play. This means that I will mainly be using the UI and Deployment Testing methods.

Iteration 2 Week 2 Reflective Journal

This week, I definitely didn’t get as much done as I would have liked. Throughout the week, I was feeling unwell, and so it made it difficult to concentrate on the problems that I was having with my code. Therefore, I have decided to do additional work during the Easter break to ensure that my project is at a stage that I am happy with for testing. This allowed me to properly rest up, so I will be ready to get more work done in the coming weeks.

To make things easier when I carry on working on the project over Easter, I made sure to get some planning done for features that I want to add. In particular, I thought about properties of the tentacles that I can upgrade and the pros/cons of needing to implement each feature.

On a positive note, I really enjoyed the additional changes that I made to the UI. When I spoke to Aaron last week, he said that it wasn’t clear enough which button summoned tentacles. To fix this, I made the button into a summoning circle that lights up red when the player presses it. I am happy with the way that this makes the button stand out more while still fitting with the theme of blood magic.

I haven’t completed any of my goals this week, but I do feel as though the work that I did do has set me up to finish up during the Easter break without any time pressure.

Iteration 2 Week 1 Reflective Journal

Due to needing to change physics engines, there was a lot of code re-writing that I had to do, meaning that I spent less time adding new features than I would have liked. However, this did mean that I could tidy up my code such as removing defunct animations and change some of my classes to extend Phaser classes such as my MonsterBaseClass now extending sprite. On the bright side, Arcade physics is much better documented and I find it easier to use than Matter which will make adding new features easier going forward.

When creating a group for the tentacles, I initially struggled with it as I hadn’t used groups since we were first introduced to them. Once I got it to work, it was especially satisfying and acted as a good reminder of a very useful feature of Phaser 3. This enabled me to have the confidence to use groups for other parts of the game, such as the attack areas for the tentacles and the enemies.

I am really pleased with the way that I have changed the UI to be simplier and easier to understand. I especially found discussing the changes that I had made with Aaron to be helpful, as he gave useful criticisms of how I could improve upon it further. When I look back on how the UI was in Iteration 1, I can already feel the improvements when testing and having to completely re-work my code made it much easier to change how the game looked than if I had to edit my existing code around.

Out of my original objectives for Iteration 2, this week I have completed:

  • Fix the collision bug,
  • Add in grid snapping for monster placement,
  • Waves of attack to add variety to levels.

I have also started working on:

  • Updating and streamlining the UI
  • Create better icons to communicate what things represent on the screen to the player in a more effective way.

Next week, my main aim is to add in the pause/play button, make the monsters upgradable and to finish up the UI changes.

Iteration 2 – Production Diary

Monday, 25th

At the end of Iteration 1, I encountered an issue where the game would crash if an enemy was killed by two monsters at the same time, due to it being removed from the enemy array. In an attempt to fix this, James and I looked into using groups instead, and extending the Phaser sprite class. However, the game was producing increasingly complex errors, mainly due to how I was having to handle collisions. Therefore, I decided to give the game a clean slate, and switch physics systems to Arcade.

I created a new repository on Github so that I wouldn’t lose my Iteration 1 code. However, looking back on this decision I could have created a separate branch in the same repository instead as this would have allowed me to gain proficiency in maintaining separate branches of code.

In Iteration 1, I gave my altar, tentacles, pause button and enemies sprite properties. To update my code, I changed how their classes worked to extend the sprite class instead. This enabled me to cut some useless code out that created animations for changing the altar’s current frame – now I use the setTexture method instead.

Tuesday, 26th

Today I worked on the tentacle physics group. When I initially created the group, I attempted to make it so that the group’s class was the TentacleClass. However, this didn’t work, as Phaser 3 was looking for properties that it couldn’t find. The fix for this was very simple, if I didn’t define the class or set any properties of the group then I could just add tentacles to the group whenever I need to.

One of my main goals for Iteration 2 is to update the UI for the game. The first way that I am doing this is by changing how the player summons tentacles. Instead of opening a menu that clutters up the screen, the player presses a button that creates a sprite that they can drag and drop wherever they want. Next, the player must press the button again to confirm their decision. To implement this, I created a SpriteButton class that will change the sprite’s frame when the button is pressed so that the player will be prompted to press the button again.

A small issue from Iteration 1 that I fixed was that some of the spritesheets looked slightly off. Turns out that I had set the margin on each of the spritesheets to 1px, when I needed to set the spacing that way. Since none of the spritesheets were more than two columns wide, I hadn’t seen any major visual problems so it took me adding a new spritesheet to notice.

Currently, the amount of health and blood the player has is displayed next to text explaining what each number represents. To make the UI more compact, I sourced a heart icon for health and created a blood droplet for blood. I then moved where the blood and health was displayed from the top left of the screen to the bottom right. I want to keep as much of the game UI in a bar at the base of the screen to keep the game clean.

I re-implemented the tentacle summoning mechanic but updated it to put the tentacles into a group and snap their positions to a grid made from 32 x 32 squares. To do this I created a new function that takes in a value x and rounds it to the nearest multiple of 32.

function snap_to_grid(x) {
     if (x % 32 >= 16) {
         x = (Math.ceil(x / 32)) * 32;
     } else if (x % 32 > 0) {
         x = Math.floor(x / 32) * 32;
     return x;

Wednesday, 27th

Today I went into university for several hours as I had my tutorial with Aaron and I wanted to get some additional help from James. During my tutorial, we discussed the improvements to the UI and how now that I have the core mechanics in place I need to focus on making the game more complete, such as adding Game Over screens, options and ways for the player to be more active in the game during attack waves. Furthermore, we briefly spoke about the essay at the end of the year. On Aaron’s advice, I made it so that as the player drags the tentacle around the screen to choose where to place it, the tentacle will snap to the grid.

A key feature that I added today was the enemy base class, as well as a simple art asset to represent the enemies. Whenever an enemy dies, regardless of if a tentacle killed it or it reached the altar, the player gains a small amount of blood. This is so that the player doesn’t get stuck if they can’t kill any enemies because they need more damage.

To give the tentacles an area in which they can attack, I created a hit radius group that has an overlap with the enemies. When the overlap occurs, the tentacle that is associated with the hit circle attacks the enemy.

My tentacles were instantly killing the enemies when they entered their area, even though they were supposed to have a 3 second cooldown on their attack. I resolved this issue by changing the value I passed to the tentacle class, as I had been stating the attack cooldown to be 3 milliseconds, rather than 3000 ms.

The last feature that I added today was a wave of attack system. To do this, I created a WaveProperties class that takes in all the modifiers that I want for a wave so that the level can use this information.

class WaveProperties {
    constructor(spawn_speed, total_enemies, health_modifier, damage_modifier) {
        this.spawn_speed = spawn_speed;
        this.total_enemies = total_enemies;
        this.health_modifier = health_modifier;
        this.damage_modifier = damage_modifier;

I then created an instance of this class for each wave that I wanted and stored it in a wave_properties array that could be accessed from the base class whenever there was a new wave. These properties were then added throughout the code where needed, such as where the timer for spawning enemies is created, or where the game stores the amount of health an enemy starts with.

        this.wave_properties = [
            new WaveProperties(2500, 2, 1, 1),
            new WaveProperties(2000, 5, 1, 1.2),
            new WaveProperties(1500, 25, 1.1, 1.3)];

Sunday, 31st

Today I worked on making sure my production diary was up to date.

Monday 1st

My main focus for today was to work on the UI and to implement the pause/play mechanic. Also, I wanted to add in the tentacles attacking sound effect so that whenever they attack the player gets an audio cue.

To begin improving the UI I created a circle asset to show the attack radius of the tentacles. This was so that I could turn off debug draw which would clean up the appearance of the rest of the game, especially since I had to leave it on for testing during Iteration 1.

I updated the summoning button by changing it from being a blank blue square to having a symbol of a pentagram as this associated with the summoning of demons. When the player has tapped the summoning button it lights up red to show that there’s a monster ready to be placed and to indicate to the player that they need to tap it again to complete the summon.

I also started on an upgrade button sprite to use when I add in that feature. Plus, I created a blank red and green button that could be used for general purposes in case I needed them.

One of the key features that I added today was the pause play button. I did this by creating a new class called Pause that extends Phaser.Scene. When the player taps the pause button and the wave is attacking the game will load up the pause scene. When the player taps anywhere on the screen the game will resume. I found this simpler to implement than having a new pause play buttons spawn in for the pause scene. I added in a default case for the pause buttons frame so that it would show is playing in most cases this is because it would end up getting stuck on pause when the scene switched from pause to play.

A bug that I’d been having was that the game wouldn’t end when the last wave was reached. I found that this was due to the wave number was not reaching the total number of waves in the level when it was supposed to be. I fix this by changing how I checked for if the level was complete.

if (this.wave_no === this.no_of_waves - 1)

Wednesday 3rd

Today I started work on the upgrade button for the tentacles. I created a new upgrade button class that extends Phaser.Sprite. I spent quite a bit of time planning out how I wanted the tentacles to be improved when the player picks to upgrade them, and less time than I would have liked actually coding the upgrades. However, this does mean that when I finish working on the upgrade mechanic, I know exactly how I want to proceed.

class UpgradeButton extends Phaser.Physics.Arcade.Sprite {
    constructor(x, y, sprite_path, scene) {
        super(scene, x, y, sprite_path, 0);
        this.sprite_path = sprite_path;
        this.on("pointerdown", this.upgrade, this.scene);
    upgrade() {
        //what improves when the tentacles are upgraded?
    update() {

Firstly, I decided that when the player upgrades it will upgrade all of the tentacles rather than just a specific one. That way I can loop through the tentacle group and update each tentacle’s properties.

I initially came up with a list of ideas of how the tentacles could be upgraded to make them stronger. One of the ways that I could have chosen to upgrade them would be to increase attack radius however, this is me in that I’d need a new sprite and I’d need to create a new object for each tentacles attack area. I decided that this was a bit too complicated to implement at this stage.

A simple way to upgrade the tentacles and make them more powerful would be to decrease their attack cooldown. This would also give the player instant feedback that something has changed in exchange for them spending blood to upgrade.

Monday 22nd

The main feature that I worked on today was the upgrade button that allows the player to spend blood to make their tentacles stronger. The first thing that I did was change the upgrade button class to extend Phaser.Physics.Arcade.Image rather than Phaser.Physics.Arcade.Sprite which fixed an issue I was having where the upgrade button was not visible despite being interactive. When the player clicks the upgrade button it first checks if they have enough blood to afford the upgrade. Then it deducts the cost of the upgrade from the players total blood and it increases the tentacle level.

To upgrade all of the tentacles that the player has already summoned I iterate through them and increase their attack damage or decreasing their cooldown. Each time the player upgrades their tentacles the cooldown length decreases by 100ms; this allows me to scale the upgrade easily as I can multiply the current tentacle level by 100 and subtract that from the base cooldown of 3000ms.

To make sure that any new tentacles that are summoned were also upgraded I had to edit the way that values are passed to the tentacle class when a new tentacle is created. I also changed the way that attack power was passed from TentacleClass to MonsterBaseClass to ensure that it was accurate regardless of any upgrades.

Wednesday 24th

When I spoke to Aaron at the end of Iteration 1 he mentioned that the game was currently deterministic and suffered with a lack of interactivity during enemy waves. The first way that I dealt with this was by adding the wave system and upgrade functionalities. Today, I created an enemy modifier. Based on the current wave number there is a fixed chance of an enemy having different properties. The properties that I changed were: speed, health, damage and value when killed. This means that within each wave there is some variation and how the enemies behave causing the player to need to plan for a greater range of scenarios.

It was very simple to upgrade the health, damage or value of an enemy. On the other hand, it was more complicated to upgrade the speed due to the way I had the enemies follow the path. To get this to work I created a fast property that would either be true or false. Then, when the game moves the enemy along the path I have it check if the enemy is fast. If they are, then the game increments the pi value twice rather than once causing the enemy to move twice as fast.

The last feature that I added today was the ability of the game to move on to the next level if there was one. I did this by checking the config object to see if the next scene was a new level or the pause scene. This also allows me to add new levels to the game whenever I like without having to edit individual levels code.

  if (game.config.sceneConfig[level_num + 1].name === "Pause") {
      this.wave_text.setText("You Win!")
  } else {
      this.scene.Launch("Level_" + (level_num + 1));

Saturday 27th

My goal for today was to tidy up the game and make sure that it was fully compatible with my target phone: the Google Pixel. The first thing I did was to create a Game Over scene that would allow the player to restart the game. However, upon looking into how to do this in Phaser, it’s quite complicated to completely reset a scene to its initial state. Consequently, I just gave the player written instructions to refresh the page to start again, as this would take less time, especially as I had already sunk a chunk of time into attempting to solve the problem.

A Google Pixel phone has a screen resolution of 960 x 544 pixels and I wanted to use a 32 x 32 tile size. Unfortunately, this isn’t a perfect fit, so my game’s default size was 960 x 540. Therefore, I decided to use scale manager to add a full-screen mode and make the game compatible with more devices. To allow the player to toggle this mode I added a small, white icon that enables and disables full-screen based on the current state of the game.

My final feature for the game was to add a tutorial to the start menu. First, I created a tutorial button in the same font as the start button. Then, I took an in-game screenshot where an enemy was visible and the player had summoned a tentacle. I put this into paint to add in text descriptions of what each button did, as well as an explanation of how to exit the tutorial.

Instead of using an image object for the tutorial, I used my existing button base class, since I wanted it to close when clicked. When the tutorial is clicked, its setActive and setVisible properties are made false so that it disappears from the screen and the player can’t accidentally interact with it. Due to object layering, I can simply overlay the tutorial over the start menu’s buttons as it makes them unclickable until it is no longer active. This prevents the player from being able to accidentally start the game or open the tutorial twice while attempting to close it.

Industry Folder


During my GCSEs and Sixth Form, I did work experience at a games company in London called PlayerThree. After university, I would be interested in working for them as they have a pleasant and friendly work environment, as well as interesting projects. The company consists of a small team of around 10 people, and they create small mobile and web games for existing IPs belonging to other companies such as Disney, Marvel and Cartoon Network.

They currently have a job available for a HTML5 developer listed here:

Their main technical requirements on the advert are:

• Experience in Native HTML5 games development, ideally using Pixi.js
• Well versed in OOP practices and design patterns
• Knowledge of the latest libraries and frameworks
• Experience with using third party plugins and code, and knowing when to use them

This role particularly interests me as I have an existing relationship with the company, and I know what the company environment is like on a day-to-day basis. Plus, there are opportunities to expand your skills and everyone gets the chance to put forward their ideas for proposals to be given to clients. The only disadvantage is that I would have to move back to London, and I would like to stay in Norwich after university.

Frontier Developments

Another company that I would be interested in working for is Frontier who is based in Cambridge which is only an hour and a half comute. I’ve played a few of their games, and they tend to make simulation/management games with their most recent being Jurassic World: Evolution and Planet Coaster. They have a graduate programmer scheme, with opportunities to move into a specialism.

On their page about programmer application guidance, they mention audio as one of their potential pathways, saying:

” Developing game audio systems, working with audio designers to establish workflows and enable content, making the game sound amazing. Requires a good knowledge of C++, familiarity with audio authoring and processing techniques, and a good appreciation for audio quality. “

This is particularly exciting to me as my other interest outside of games is music. I’ve played classical music since I was 6 and performed regularly for just under 10 years. Despite my goals shifting since then, I still have a strong passion for audio and to me, audio in a game can make the difference between a good and a great experience. Next year, I’d like to focus more on ways that I can include audio techniques in my games so that I can specialise in this area.



When I was looking into pathways into the games industry in Sixth Form, I encountered the Ubisoft graduates program. During the program, I would work at two different studios giving me the chance to see the differences in studio environments even within the same company. Furthermore, the company internally works in English so I wouldn’t have to learn a new language for each studio. I love to travel and want to work abroad at some point, however if I went straight from university into working in a foreign country I might have to leave my partner behind in the UK depending on salary.

They have some information on the graduate program on their website here: https://www.ubisoft.com/en-US/careers/graduate_program.aspx

There is also a listing for the graduate scheme with more information here: https://www.ubisoft.com/en-us/careers/search.aspx#sr-post-id=743999681099083

Iteration 2 Planning

From Iteration 1, there were a few features that I had planned that I didn’t get to implement. These included some asset creation, a system for waves of attack, the ability to upgrade your monsters that you summon and a way to pause the game. The main tasks I’d like to carry over to Iteration 2 are the attack wave system, the pause button and allowing the player to upgrade their monsters. If I have time, I will add in the missing assets, but this is of low priority to me as the game functions without them.

At the end of Iteration 1, there were still some major bugs in the code that need to be fixed moving forward into Iteration 2. The most important fix to make is to stop the game from randomly crashing when multiple objects collide and the object is removed before the collisions can resolve for both objects. I want to make this my first priority during Iteration 2 as it renders the game unplayable without refreshing the tab.

Some smaller problems that I would like to fix are the attack radius for the tentacles being off-centre as well as the tentacles only attacking when an enemy enters or exits their attack area. This is a problem as it means that even if an enemy is moving slowly enough that it can be hit more than twice by the same tentacle, it will only be hit at most twice. Finally, where my menu overlaps with the game screen enemies passing through the area appear on top of the menu so I need to adjust how far forward they are.

Based on my feedback from the testing phaser of Iteration 1, I have a few features that are in my nice to have category. Personally, I want to add a second monster type, as this would add further decision making to the game as the player would need to chose which type of monster to summon to optimise their strategy. During feedback, it was suggested that I should add some way for players to be able to generate blood faster through some form of shrine or building. The last feature is grid snapping so that players cannot summon monsters super close together and they are encouraged to spread out their monsters further.

During Iteration 1, I followed a very strict planning schedule. However, due to events outside of my control such as falling ill, I couldn’t stick to it effectively. In fact, it caused more stress as I felt as though I was constantly behind on work despite making good progress. For Iteration 2, I want to use a more goal based style of development, where I have greater flexibility in the order in which I approach the tasks. This will also better allow for any bugs that pop up that slow down the rest of the development.

My main goals for Iteration 2 are:

  • Fix the random collision crash bug
  • Update/Streamline the UI. During one of our meetings, Aaron suggested moving the summoning of monsters out of a menu and simplifying it to a button press.
  • Implement a pause/play button to make the game more user friendly.
  • Add in grid snapping as troop placement can currently be unwieldy.
  • Upgradable monsters to give the player more to think about during attack waves.
  • Creating better icons that communicate what a button does more effectively to the player.

Overall, I’m pleased with the ideas and themes that came out of Iteration 1 and I want to carry that forward into Iteration 2. The main structure of the game is going to remain the same, just be improved upon. My summarising statement for the game is as follows: Blood Magic is a tower defense game where you use blood to summon and upgrade monsters to protect your altar from waves of oncoming enemies.

Iteration 1 – Testing Evaluation

The final version of Iteration 1 is available here

For my testing process, I wanted to test how the game felt to play, to see if the buttons were of a good size on screen. As someone with smaller hands, I was unsure if the buttons were a suitable size for larger hands, or if they were too small.  It was important to see if the tester had previous experience with tower defense games, as it may affect how they score the game in the quantitative data section. Finally, I wanted to see what a player would be looking for in a tower defense game, and to give them a space for any further comments that they wanted to make.

To collect my qualitative data, I created a series of questions for my tester to answer at the end of their time with the game. These questions were:

A) Were the controls easy to use and well-scaled to the screen size?

B) Was the objective of the game clear?

C) Do you play any tower defense games? If so, are they on mobile?

D) What features would you like to see in the future?

Here are the responses I got from my testers:


A) The controls are easy to use, if occasionally a little fiddly.
B) Yes
C) No
D) Extra blood generators that you can summon, to make summoning more troops faster.


A) Well scaled to the screen, and the controls are easy to use.
B) Yes, the aim of the game is simple to understand.
C) No
D) Sprites for the enemies as they are currently missing them, plus, a proper tileset for your tilemap. More assets in general.


A) The controls were easy to understand and use.
B) The objective of the game was sort of clear, but I might not have got it without a small explanation,
C) No, tower defense games are not my thing.
D) Some form of tutorial or instructions on how to play and make it clearer that blood is your form of currency, I didn’t notice it straight away.


A) Yes, especially for me since I have small hands.
B) The aim was to kill the wave of enemies, it was clear.
C) No, I don’t play any.
D) More monsters for the player to summon to defend themselves with.


A) Yes and the controls were responsive.
B) The goal was to stop the enemies from getting to your altar and to get more blood to summon more monsters with.
C) I’ve played tower defense games before and I’ve played the mobile game Balloons, so I have some experience with this type of game.
D) Being able to upgrade your troops, and have more monster options for the player to summon. Also, make the game a little easier.


A) Yes, the controls are also very well suited to a mobile phone screen.
B) Yes
C) I used to play some tower defense games, but not on mobile.
D) It’d be good if there were more ways to defeat the enemies attacking you, and if it was easier to get blood to summon troops with.

After the player had completed their attempt at the game, I recorded my quantitative data. I wanted to track how much blood (currency) the player had, how much health, if they beat the game, how many tentacles they summoned and I asked them how difficult they would rate the game.

Due to an unfortunate bug in the code, some tester’s games crashed on them, leaving them without the opportunity to win. Plus, I made the game too difficult by giving the enemies too much health. When I was testing myself previously, I had made the game too easy, so I decided to make it harder to see how the testers would respond. Evidently, I had overcompensated for how easy the game was and made it too difficult. In Iteration 2 I will spend more time on getting the balance of enemies and player monsters correct.

Before the game begins, the player only has enough blood to summon 2 tentacles. If a player summoned 3, that means they figured out how to gain blood quicker and spend it on the fly. 5/6 players were successful in summoning an extra tentacle, demonstrating that it was clear that you could continue to summon troops, even after the game has begun.

Before the tester started playing, I briefly explained the basic mechanic of the game, and told them that it was a tower defense game. For Iteration 2, I would like to be more hands off with my testing, to better replicate how it would be if the game was released. This way I can test how intuitive my controls are, and how easy the game is to pick up.