This week I continued to adjust the core gameplay, to build a loop that feels satisfying and challenging to play. I drastically changed values, such as making the asteroids spawn much faster and much slower, to find something that works. I always experimented with the fuel system, adjusting variables to give the player lots of fuel and little-to-no fuel. I playtested each of these and found that players enjoyed having more fuel available, as it gave them more leeway during gameplay.
However, when I tested the game with lots of fuel, I found that the player can climb extremely high and outrun all of the asteroids. Using this method only requires the player to stop every now and then to pick up a fuel pick up, after which they can return to going straight up and outrunning the asteroids. This allows the player an easy way to get out of the core gameplay loop, and makes the game very trivial. The video below demonstrates me doing this.
The best way to fix this was to reduce the amount of fuel available to the player, thus they need to be actively engaging with the patterns and seeking out fuel regularly. I implemented this by reducing the max fuel, as well as the fuel that the player starts with, and the fuel that the player gets from a pickup. Eventually, I was able to get these values to a good level to produce a challenging gameplay loop that the player has to engage with. The video below demonstrates how the player can no longer break out of the asteroid patterns like before.
I was able to get my game playtested this week, by a friend who had never tried the game before, and I learnt a lot from watching them. I was sure to not tell them anything, other than to use the space bar to go up, so as to get the best results for improving the game.
Initially, the player spent all of their fuel on the first go and died immediately. On later attempts they realised that they needed to collect the fuel pickups, and they learnt this pretty quickly. However, the player struggled to find some of the fuel pickups; they never noticed the one in the “knockback” pattern, as it was always spawning too far down and appearing offscreen. After a few playtests, I raised the fuel pickup to spawn higher, and the player noticed it every time; they then lasted much longer.
I tested the player on 2 versions of the game: one where they had a lot of fuel, and pickups were worth more, and one where they had less fuel, and the pickups were worth less. The latter is the current build of the game, with the edits discussed above having been implemented. The player struggled a great deal when they had less fuel, and explained that they enjoyed the game more when they could use their fuel more comfortably, as in the first build. It is also worth noting that, when they had a lot of fuel, the player did not exploit the extra fuel and play the game as shown in the first video above.
The player also explained that needing to go up, and expend fuel in doing so, felt frustrating at the start of the game. This is because it always feels like wasting fuel, and the player was always unsure as to how much fuel they should spend to keep their expenditure to a minimum whilst reaching a good height. To fix this, I plan to only have the fuel actually reduce when the rocket is in space, so that the player does not feel that they are wasting fuel before reaching the core gameplay.
The player also fed back that they felt the fuel pickups should be a different colour, as they are currently white and it is difficult to understand exactly what they do at a glance. As a player, it feels natural to want to avoid them, as everything else must be avoided. Instead, the pickup colour could correlate to the fuel gauge by being blue.
This week, I also implemented the UI that shows the player their distance from the planet surface. The gauge is made up of a series of individual triangles that each have a script attached to them that controls their colour. The script for each one is the same, and each tracks the rocket’s y position. When the rocket is within specified boundaries, which are public integers that can be set for each triangle within the Unity editor, then the triangle is changed to red.
The video below shows the gauge in action, on the bottom left of the display. However, in the end I felt that it looked messy, and did not accurately tell the player anything helpful; therefore, I have removed it for the time being.
potential balance for climbing bug.mp4
I was sent a full music track from Georgia, the music student that I am working with, this week. Whilst I have not yet added the music into the Unity project, I was able to play it in the background and speed up the spawn rate of the asteroid patterns, so that they come in sync with the music. Initially, I made the asteroids come in on every beat, however, this became incredibly difficult to play; reading the patterns was impossible and the game became purely reactive, but too unbalanced to be so. As I want the player to be able to plan a little ahead, as well as read and interpret patterns, I slowed the spawn rate down so, instead, asteroids spawn on every other beat. This worked much better, and was pleasantly challenging to play.
I added stars in the background that move slowly, so as to appear as if they are far away. I achieved this effect by making the stars follow the rocket but at 0.01x the rocket’s velocity, so that the stars are unable to keep up with the rocket and slowly move offscreen. The stars, each being individual game objects, are destroyed whenever they are far enough offscreen and more are instantiated, in random positions, to replace them. The newly instantiated stars always spawn offscreen, either above or below the rocket. I programmed the script to randomly decide the maximum amount of stars that should appear on screen, between specified boundaries, and the script will repeatedly decide on a new number whenever enough stars are destroyed. This ensures that the game is constantly providing the player with a new and unique background.
I also, with the help of the technician, was able to fix the version control issues that I was having with GitKraken. We are still unsure as to what the problem was exactly, however, it was likely an issue with the GitKraken GUI itself; its possible that it did not have the correct permissions to do a push via the GUI. In the end, we were able to do a push via the command console and this worked; doing this also enabled the GUI to work correctly.
At the end of the week, I was able to implement the UI overlay. The overlay is the same as the one I designed a few weeks ago, and eventually I used that exact image to place under the other UI components. Initially, however, I attempted to break the overlay into pieces and simply have the pieces take up the corners; I could then utilise grey rectangles in the spaces in between to fill out the rest of the UI overlay, and these rectangles would stretch and squash with the screen size. You can see, in the image below, the start of this process.