CONCEPT
Future Riders is a 2-player
competitive Action Rhythm game where you play as a Future Rider who is trying to defeat your opponent in a high-score challenge. You will avoid obstacles by jumping over or dodging them while trying to get more speed in the boosting tunnels.
Our team was tasked with creating a game that fitted the theme "Future Mobility” for a 10-12-year-old audience. We interpreted that by making the main characters use eco-friendly hoverboards.
GAME PILLARS
Competitive
Placing the players next to each other increases the competitiveness between them.
Accessibility
An important point was making the game accessible, also thanks to the use of the Xbox Adaptive Controller. Each player has only one button and must time when to press it, hold it, or fast press it.
Timing
The gameplay is based on the players' ability to time actions at the right moment, similar to rhythm games.
CORE LOOP
REST
Keep your attention up while waiting for the next obstacle track
REACT
Execute the right action at the right time to gain points
GAMEPLAY DESIGN
As the gameplay designer for this game, I began researching the types of games that could be used as a reference and inspiration.
Research takeaways
My main takeaways were that the game should have responsive controls and communicative animations.
The goal of having communicative animations is to:
-
Reduce the amount of unnecessary UI on the screen
-
Make the gameplay more intuitive.
​
Moreover, I identified the most common and used types of actions:
-
Being the first to tap
-
Being the last to tap
-
Holding & releasing on time
-
Filling the bar faster
-
Not tapping
Playtest and improvement
After one week of development, the target audience (10-12 years old) had the possibility to test the first build.
Given the importance of accessibility features, the game was designed with the Xbox Adaptive Controller as the primary input device. Each player was given only one of the two buttons on this controller.
Playtesting the game!
A feedback from a playtester
The main suggestion from the testers was to make the game more visually communicative. We also received some suggestions on how to improve the characters of the game!
The first iteration of the game
The final iteration of the game
The first video depicts the game's state after one week of development.
Following the feedback of the playtesters, we added various types of visual obstacles that would indicate to the player which action they should execute (jump, dodge, etc.), as shown in the second video.
PUZZLE DESIGN
How the obstacle course generation works?
The goal was to create a seemingly endless runner game with a couple of twists:
-
Each race must have an ending
-
It has to be a two-player competition.
To achieve this, a map generator system was created. I used this system to control the length of the game and the types of obstacles that spawned.
The different types of obstacles
I included a total of 4 obstacles in the final version of the game. The player must perform a specific action for each of them:
-
Jump -> Press the button
-
Dodge -> Hold the button
-
Sprint -> Quickly press the button
-
Don't jump -> Don't press any button
​
The action to execute is communicated visually to the player. In fact, each action is associated with a distinct visual representation.
Don't jump obstacle (on the right)
Jump obstacle
Dodge obstacle
Sprint tiles
Course design and balance
The obstacles presented to the two players in the first iteration of the game were the same at the same time. This meant that a player could play the game by themselves by pressing the two buttons simultaneously.
The solution to this problem was to design tracks that avoided using the same obstacle on both sides of the track at the same moment as much as possible.
​
As a result, the courses must be balanced. For example, if the left side of the track has two obstacles of type A and four of type B, the same number of types of obstacles must be placed on the right side, but in a different order.
This is a simplified example of a balanced tile.
There are Don't Jump and Jump obstacles on both sides, even if they are not placed simultaneously for both players.
By the end of the development, I was in charge of 4 different courses out of the 7 that made it into the final build of the game.
In-game UI
Another goal was to keep the in-game UI to a bare minimum in order to keep the player immersed and focused. The only UI elements available to the players are:
-
Score multipliers;
-
Points earned for each action.
​
Displaying the number of points earned is a good way to keep the players engaged.
