Game: Gabriel’s Journey
Speed Runner
Game Concept
A single player parkour speed runner. Rush through a collapsing world as an agile sorcerer.
Rather than giving the players the complete toolset to start clocking the speed run attempts, you have to collect currency across the levels to upgrade your agile abilities. This makes the player explore a multitude of paths in the level and gain an increasing power and speed as they learn the game. During this growing phase, the player is likely to crush their own records multiple times for a satisfying start.
My Focus
I took ownership over the game loop and the general flow of the game. Spending a lot of time on the high level structure of the game, player progression, overlooking the coherency of features as well as keeping the project scope in mind at all times.
I also designed and implemented the currency and upgrade system along with all the UI in the game.
The designers worked closely together within many areas. Being part of constant playtesting, feedback sessions and adding our own competence to all topics we could find.
Player Guidance
The opening level acts as a tutorial. As you reach new obstacles, trigger boxes will show and hide hints in the UI to assist the player without requiring player input. Holding [Tab-key] will bring up a more extensive player guide with control schemes and explanations.
Currency System
To encourage the player to explore new paths we populated the level with crystal pickups, functioning as currency to upgrade your abilities in between runs.
Since levels are replayed multiple times, we decided to have the currency permanently disappear from the level upon pickup.
Persistent Actors
Everything in the level should reset when starting a level, except the already picked up currency which should permanently be gone from the map. Check out my blueprint implementation below using the three tabs:
• First adding the actor to a struct and mapping it to the level it's in. This struct is stored in the persistent GameInstance.
• When we reset the level the actor can check if it's in the struct, and then perform actions based on that. This makes to possibility to remove the already picked up coins after the level has reset.
UI & Menus
Playtesters sometimes missed the upgrade screen entirely and therefore a core part of the game. I decided to make the flow of the menu screens more linear, forcing the player to at least see the shop for a frame if they chose to skip ahead. Below is the updated flowchart:
Upgrade System
Even though the speed runner clock isn't ticking in between levels, the menus should still meet a speedrunners pacing. Rather than walking up to an in-game shopkeeper, implemented a 2D UI for unparalleled speed. Adding keyboard shortcuts within your fingertips and having button positions be consistent was another part.
I designed and implemented the upgrade system along with all the UI in the game. In order to allow the player to experiment we allowed full refunds for the upgrades and abilities to switch up your setup.
UI Workflow
I derived all buttons and UI elements from base widgets. This created an efficient workflow, where all buttons can share the same code, functionality, animation, sound effect, visual states, and overall styling. When changes needed to be made, I could update the entire game immediately. Increasing the amount of iterations and the possible scope for this short project.
The upgrade “cards” are using the widget blueprint inheritance technique. Setting up instance editable properties allow me to vary the data and functionality of each card.
