Puzzle Game Documentation January 2020
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.
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.
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:
- Levels Beat
- Previous Music Experience
- Ease of Play
- Clarity of Game Play
- Other 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.