As a sub-genre, endless runners have been very successful, however there has been a noticeable stagnation in creativity. I want to analyse what makes endless runner games fun while creating a new spin on the game.
Introduction
Endless Runner is set in a destroyed derelict spaceship that contains a valuable device which can distort time. The backstory is that the player has travelled to this ship in the hopes of stealing this device. But the device has activated, trapping the player in an endless cycle where they are forced to run or die. Players embark on a journey where they must master the loop, avoiding obstacles, collecting resources, upgrading equipment and obtaining gadgets.
I created this game to stretch my programming skills in Unreal Engine. Listed below are three significant areas that I have coded for the game.
Transition Code
The main gameplay mechanic is transitioning between two different arenas. To make this work, I set up a system to block the player’s view, change the look of everything around the player, and then restore their vision with different obstacles spawned.
Blocking the player’s view was a matter of having an invisible black box attached to the player at all times appear and disappear, blocking their view. This is achieved by attaching a static mesh to the player, setting its alpha to 0 by default and then incrementing that timeline node to 1.
Replacing the visuals around the player was done by creating two-row blueprints with different visuals and swapping between them. However, this led to a lot of duplicate code, as both rows had to have the same functionality. I used one blueprint to store all of the static meshes that I need to change, so when a row spawns it can check materials from the game mode blueprint and then apply the material it needs.
The trigger for the transition is decided by the row blueprint. There is also a cooldown timer placed on the transition so players stay in one area for at least 60 seconds, before having the chance to transition back.
Choosing Obstacles
Each obstacle is attached to a blueprint tile which replaces one of the tiles in the row and randomly picks an obstacle. The hard part was making sure these obstacles appear in a way that is balanced, instead of creating impossible situations for the player. This means a system can intelligently place obstacles in the row with knowledge of the previous obstacle, so the next can be placed at an appropriate distance away.
Each spawned row has 10 tiles that could have an obstacle. The code needs to know what obstacle is going to spawn, which is decided by the tile blueprint. The chosen obstacle is defined with a number from 0 to 5 which then runs a specific bit of code based on the obstacle.
Once selected, the code needs to check if that space is occupied which is done by checking a boolean array, despite checking the tiles in order this needs to happen obstacles ocupi spaces in front of them as well as where they spawned so the next run needs to know if an obstacle was spawned last time. Each obstacle at a minimum occupies the space in front to ensure you don’t get two next to each other but some bigger obstacles take up two spaces in front as they are more difficult.
Managing Difficulty
The game has a scaling difficulty that increases every 15 seconds. The difficulty starts at 1 and goes all the way to 10. This affects obstacle spawning. The higher the difficulty, the more likely an obstacle will be spawned. Once the difficulty reaches 10, it goes back to the start, but increases the minimum difficulty by 1, meaning that after reaching 10 for the first time it returns to 2, then 3, then 4, until the difficulty is permanently at 10 for the rest of the run. This up-and-down difficulty system provides high-pressure moments for the player, but also allows them to relax after dealing with tough challenges.
Progression/XP Bar
I wanted the game to have an XP system, providing a sense of satisfaction every time you play. This proved difficult to implement. I wanted to system so the player wins an amount of XP equal to their run distance – the longer they run, the higher the reward.
The way this works is on death, the value of distance is added to the player XP. An array is used to store the XP requirements for each level and both the player XP and the XP required are sent to the game mode blueprint, before setting the text on the XP bar, showing how much XP you have and how much is needed to level up.
The reason why the player XP and XP required values are sent to the game mode is because the original code is in a widget blueprint, which does not allow the timeline node to be used, so I need to move the necessary data somewhere else.
The timeline is required because I wanted the XP bar to move from one position to the next. I required a node to slowly transition between two values. Before starting the timeline, I needed to check if the XP gained is enough to level up, as this will trigger two separate events. If the player is levelling up, the XP calculator needs to be run again.
If there was enough XP earned to level up, the XP bar will be told to get to the end. If not, it calculates the player’s current XP in comparison to the current level they are at and move the bar to the appropriate position.
One final bit of code was needed to reset the XP bar after a level up. This sets the XP and level text to reflect the next level and resets the bar back to the start, before calling the level-up event in the game mode blueprint to start the process again.