As I have been utilising version control a great deal, and adding commit notes to each change made, I will be less specific in upcoming journal entries. Instead of discussing specific implementation changes, and what has been added when, these entries will focus on design choices and why I have added or changed elements within the game. For more specific notes, please refer to the commits in GitHub.
To begin the week, I was able to get touch input working for the game. This was relatively simple as Unity has an inbuilt library that tracks touch inputs and can be used to work out exactly where the player is touching on the screen, as well as other details. The library is simply the Input library, which is also used for any key inputs from a keyboard, so it was very quick to implement. Under Input is a public value called TouchCount, which can be used to access how many times the player has touched the screen since the last frame. If the player has their finger held on the screen, this still increases the touch count; TouchCount resets to 0 each frame, so if the player is not touching the screen at all, then it will remain at 0. As I only need to register whether the player is touching the screen or not, because the buttons already work with touch input, I simply added an if statement that checks whether Input.TouchCount is greater than 0. If it is, then the script activates the thrusters and pushes the rocket up.
After adding touch input, I was able to playtest the game on a mobile phone. I tested the game with 3 2nd year students, who each found the game very confusing. None of the players were able to understand exactly what was going on, and they often expended fuel and repeatedly died without learning anything or even having a chance to interact with the patterns. One player never actually reached the height for the asteroid patterns to spawn, as they kept spending fuel to go up a little bit at a time; this resulted in them being forced to return to the planet surface, and not having enough fuel to go back up, forcing them to restart the game.
To fix the above problems, I will need to ensure that there is a clear distinction between where the asteroids will come in (in space) and where they will not (in the planet’s atmosphere). I will add the atmosphere asset to do this, so that when the player escapes the atmosphere backdrop, then they will slow down and see the asteroids. I also intend to stop fuel reducing whilst the player is in the atmosphere, so that they cannot get stuck on the planet with no fuel.
Another common occurrence was that players initially expected the rocket to move from side-to-side, and tried swiping to make this happen. A possible solution to this would be to include a screen, when the game loads up, that shows a simple image of the rocket with an arrow above, going up, and an arrow below, going down; this quickly informs the player that the rocket only moves in these 2 directions.
Players also linked the colour of the fuel bar to that of the score multiplier, as well as the asteroid indicators. It is more important that players do not make these links than it is to maintain an overall aesthetic, therefore, I will need to change the colour of the fuel bar.
Finally, one player did reach the asteroids but they were quickly overwhelmed. The player never lasted more than a few seconds, as they could not keep up with the patterns. This player was also very confused as to how to gain more fuel, even though they accidentally collected a fuel pickup but were unaware that they did so. After a few turns, the player gave up completely and stated that they felt they were not learning anything. To fix these issues, I plan to have the patterns become available to spawn in increasing difficulty over time; this means that players will always encounter the easy patterns for the first 30 seconds or so, and then more difficult patterns will start to spawn in. Doing this will efficiently teach new players how to play, without overwhelming them, whilst providing experienced players with a short moment to get into a good flow state.
After making the above changes, I found that the initial time before the more difficult patterns spawn in would become boring for experienced players. This is because they have no way of directly influencing their score, as meteorite gems do not spawn until the more difficult patterns, so these players simply need to survive against easy patterns; this can drag on after multiple attempts. To fix this, I added a near miss system.
The near miss system, or perfect dodge, essentially provides the player with an opportunity to only just dodge an asteroid for a bonus score. This bonus score is then added to the player’s final score at the end. To implement this, I added a second game object with a small collider that is instantiated in front of each asteroid. If the player collides with one of these, then the game registers a near miss and adds 5 to their bonus score. I initially intended on having a streak system, where the player could get up to 3 near misses in quick succession for a high bonus score, but I scrapped this as it encouraged behaviour where the player would try to keep their streak rather than collecting fuel pickups. The below video shows the current state of the game. Whenever a “1” appears near the rocket, the player has gotten a near miss.
After playing the game for some time in the above state, I found the “1” to be very distracting whenever it appeared. To change this, I removed it and added text that appears on the top left that flashes whenever the player gets a near miss, as well as a display for the bonus score. The bonus score display also flashes whenever the player gets a near miss, so it is clear what they are being rewarded with.
This week I also worked on the UI scaling, so that it adapts to every screen size. I began by anchoring the UI components to the edges of the screen, rather than the centre, as this ensured that they would appear a specified distance away from a specific edge. Doing this meant that all of the components would always appear within the bounds of the screen, no matter the device.
I then looked into a way to stretch the UI overlay, which is the grey sections that appear under the gauges. After some research, I found that the best way to deal with this was to add an AspectRatioFitter component. This component stretches or squashes the game object that it is attached to, to fit within the bounds of the aspect ratio of the screen. This was a perfect fix, as it is difficult to notice if the actual image has been stretched as it doesn’t look drastically distorted, but it now means that the UI looks pretty much the same on all aspect ratios. This means that the UI is able to adapt to older iPhone sizes, such as those from the iPhone 8 and before, as well as the SE models and, importantly, iPod Touches, which will be used to demonstrate the game at conventions.
For the UI scaling, I also needed to slightly move the gauges and text displays around, so that they fit in the correct spaces. To do this, I added a check on the start of the scene that divides the width by the height, to get the aspect ratio, and checked if it was above a given value. If it was, then the text displays and gauges are moved over slightly.
I decided to get one of my friends, who had not yet tried the game, to play. Unfortunately, they made many of the same mistakes as the above playtesters. They found that they were still expending too much fuel initially, and never understood how to gain more. I asked the player to think aloud whilst playing, so I could tell that they were quickly getting frustrated as to how to get more fuel. They also said that they felt the rocket fell very slowly, and when they ran out of fuel they took a very long time to die; a potential solution, which I will likely implement, to this would be to kill the player a few seconds after they start falling at a specific speed with no fuel, because they will not be able to get a fuel pickup if they are falling too fast.
The first problem is harder to fix and I attempted a few different solutions. The first solution was to add a “ceiling” of asteroids that spawn very high to each pattern spawn, thus killing the player if they go too high and forcing them to interact with the pattern, but this felt very restricting. The second solution was to have the asteroids and pickups follow the player up/down if the rocket is going above a certain speed; in programming this, I found it made the game quickly very buggy and it felt very unpredictable.
As I had designed the fuel system to keep the player engaging with the patterns, I found that players who knew about the pickups were automatically doing this. The issue, then, was more about effectively teaching this to new players in an intuitive way. Therefore, I took a new approach that would always start the player in the correct place, and with the correct information in front of them. To do this, I added a launch button that shoots the rocket up to the perfect point in space; the thrusters then stop and the player will see the patterns spawn before they realise how to control the rocket. This tells the player that there are things going on, which they otherwise would have just zoomed past. The other change I made was ensuring the first pattern to spawn was always the same, one with a fuel pickup spawning immediately, so that players quickly notice that the fuel pickups exist. Further playtests with this system in place showed that new players were able to get the hang of the game after 3-5 attempts.
The video below shows the progress so far, on an iPod Touch display.