An open world 3D platformer with a tight and flexible character controller. The movement revolves around a vault mechanic which offers players a lot of horizontal and vertical freedom.
Game genre
3D Platformer
No. Developers
20 Developers
Dvelopment Time
4 Months
Engine
Unreal Engine version 5.2
Release
Available on Steam
Responsibilities quick access
Heatmap Tool
Feature Description
The heatmap is a QA tool created with the purpose of visualizing playtest data and highlighting common player strategies.
The heatmap allows for developers to put into context player position data saved during playthroughs, collected with the help of a telemetry system. Developers can see the player pathing and the positions at which specific movement abilities, horn based movements and specific movement combos were used.
Developers have access to the testing data of all the version they previously tested as well as all respective sessions separately.
Feature Breakdown
Player Pathing
The purpose of this feature is to accurately show the path the player takes throughout the level. The pathway has a color gradient in order to show the timeline of the player movement.
The reason for creating this feature is so that level designers can see whether or not there are preferred paths or areas that are more or less accessed than others
Ability Location
The purpose of this feature is to show the location and frequency at which players use specific movement abilities like diving, rolling or vaulting.
The reason for creating this feature is to be able to check which abilities are used the most / the least to verify both the usefulness of movement abilities as well as the tutorial quality
Since our game is a platformer which strives to create challenges with multiple solutions and shortcuts, keeping tabs on player behavior is very important for balancing the player experience. This system keeps track of those behaviors and visually shows the developers where, as well as how many times, they happen.
Why
Combo Location
The purpose of this feature is to show the location and frequency at which players use specific movement combos.
The reason for creating this feature is to be able to determine the ease of use and strength of combos as well as test the solution variety for level challenges.
How
The heatmap system works by sifting through data, offered by a telemetry system, using player movement states as a guideline. The data chosen is used to draw white dots to a render target at the equivalent relevant positions. The result is then used for creating a material that assigns one of 3 colors based on each point’s brightness. The material is then applied over a still image of the current game map.
The pathway systems has a few differences. Data sifting is not based on movement states but rather goes in reverse order through all position data and only saves each position once so that overlap doesn’t interfere with the visualization. The color gradient is applied immediately rather than after the first render.
Level Elements
Geysers - Asymmetrical platform rising system
Description
The asymmetrical platform rising system - or geyser system for short - is a feature that allows level designers to create sections of rising platforms which rise and fall in very specific, planned patters.
The system is beats based which means the platforms rise and fall on specific time beats. The amount of beats is customizable along with the duration between each beat.
The amount of platforms is easily modifiable, a platform can be added at the click of a button.
Platforms have a starting and a max height.
The rise and fall duration along with uptime and overlap between beats duration are all customizable and up to the level designers to decide for each challenge / section.
Moving Platform
Description
The moving platform is a level element meant to take the player from one point to another. The platform moves between and stops briefly at specific target points chosen by the level designer. These points are clearly visualized to the player.
The platform gets activated when it detects the player atop it. When the platform reaches a target point but doesn’t detect the player anymore, it will quickly cycle through the target points either forwards or backwards until it reaches its origin.
Adding Target Points
Why
The geysers were designed and implemented with the purpose of creating more verticality within the level as well as offering the players time to breathe between challenges.
The asymmetrical rising system was designed and implemented with the purpose of making it easy for level designers to create challenges using the geysers, providing a means of creating puzzles that string the geysers together without having to consider using math for planning out the raising, falling and uptime of each particular geyser. This not only speeds up the design process but also aleviates the risk of inconsistency of geyser behaviour throughout the level.
Moving Platform Behaviour and Cycles
Final Product
Features
Easy to add rising platforms that can be called during as many time beats as desired
Easily accessible and modifiable variables - duration between beats, overlap time, uptime, rise and fall time, starting and max height.
Each section has its own rules, allowing different sections using the same system to have different levels of difficulty.
Features
Easy to add and place target points
Easily modifiable variables: moving speed, retracting speed, wait time at target points, wait time before activation and deactivation buffer.
Retracting feature - goes through target points either forwards or backwards until reaching origin. The speed at which they do is at a much faster rate so that players don’t have to wait long to retry challenges.
Easy switch between retracting forwards or backwards.
Final Product
Why
This feature was created with high pressure challenges in mind. With the use of a moving platform the obstacles come to the player rather than having the player go to the obstacles at their own pace. This makes room for higher difficulty challenges.
The moving platform has multiple target points in order to allow for a varied pathway for the moving platform as well as give players the opportunity to stop at specific parts of the journey to hop off towards other level sections or offer the players a clear look of the challenge coming to them.
The platform retracting mechanic is there as a alleviator of frustration. If the player fails a challenge and they find themselves right at the beginning, they wouldn’t want to waste time waiting for the platform to come back before they try again. That in itself would make any challenge a daunting task.
Other Prototypes
Alternate Player Controller
A character controller highly inspired by that of Overwatch character Doomfist.
The main mechanic of this character prototype is the slam. This mechanic can be a means to swiftly move around the map or trigger “strength based challenges” (more on that later).
The character controller was designed in such a way that, by chaining movement and trying out different combos, players can get a variety of mobility options. This was directly inspired by Mario games, specifically Mario Odyssey. The way variety has been achieved in this prototype is by triggering different behaviour when using the slam in different move states. An example would be the difference in trying to slam while running in contrast to while standing still:
Triggering the slam when standing still will lead to the player being slightly lifted off the ground.
Triggering the slam while running will propel the player forward, similarly to a dash.
Description
While the prototype helped with creating a playful and highly versatile experience, it came with a lot of risks. Inherently, the slam mechanic implies the character mostly goes down rather than up when in reality, in our platformer, the player is meant to climb, hike. There are not that many verticality options with this system and for our platformer that posed a big problem. Other than that, while fun, the slam isn’t anything particularly new or eye catching.
The horn vault prototype, which was this prototype’s competitor, had a clear, interesting USP and offered the player a lot of verticality. For these reasons we decided to focus on the vault mechanic and abandon the slam movement controller.
Description
The Seismic system is a simple ‘trigger’ and receptor system.
The ‘trigger’, when activated, sends out shockwaves. These shockwaves have the power to activate receptors and hurt the player.
When activated, the receptor completes a task and, if it doubles as a trigger, sends out a shockwave of its own.
This system has the potential to be at the core of many prototypes that require long distance or delayed activation.
I created a few such prototypes to showcase the versatility of the system
Reason it was removed from the project
‘Seismic’ System
Prototypes created using the system
The system was initially planned in with the slam character controller. It did not work as well with the vault character controller
The system has a lot of potential specifically for creating puzzles and timed challenges. As at the start of the production phase we decided that our target experience was a relaxing hiking atmosphere, puzzles and stressful time based challenges no longer align with our vision.
For those two reasons, the seismic system was removed from the project.
Reason it was removed from the project
Sound Design
Atmosphere
In sound design, atmosphere is key. The sounds need to fit the experience you’re creating.
For the sounds that were my responsibility, I took to combining the mythical themes of the game with the mountain hike experience. The sound samples I chose were a combination of magical, fairytale-esque sounds (like ghostly whispers) and realistic rocky ones (like wood harshly hitting or grinding against rock)
Collectibles
Wisps
Geysers
Level Elements
Moving Platform
Variety
Since part of my work was on collectibles, and thus would be heard often, they posed the worry of becoming repetitive and as a result somewhat immersion breaking.
Because of this reason, the two collectibles each had three different chimes that can possibly play upon collection.
Door
Implementation
There were two means of implementation for sounds:
Collectibles SFX were implemented using sound ques. The SFX needed to only be 2D and so did not require complex settings to work well.
Level Elements SFX were implemented using Unreal Engine 5’s MetaSounds system. The SFX for level element were required to play in stereo as they were tied to each specific locations. Most SFX required looping. For these reasons, sound ques were no longer sufficient.
Runes
Lead Game Design Role
Collaboration
As lead designer, some of my most important responsibilities were keeping the project and team aligned on one common vision as well as keeping information flow going between developers.
I have tackled this responsibility by being the main point of feedback for the design team. Most features were reviewed by me as a means to ensure their quality and alignment with the common vision.
I had multiple frequent talks with the design team about their current progress and expectations. Whenever issues would arise or when developers were blocked by other people’s work, or lack there of, I would prioritize solving these issues by communicating with other departments, holding meetings or brainstorming with the blocked developers depending on the problem they were having.
Planning and Organizing (Scrum)
As design lead I worked closely with the team producer and my fellow leads in creating the backlog of the project. I took part in both the preplanning and planning processes for each sprint, keeping realistic expectations of the developers while insuring that our target MVP is reached. My responsibilities included helping set sprint goals, assigning responsibilities and determining acceptance criteria for tasks.
Outside of planning, I upheld and often took charge in Scrum rituals such as the daily standups, sprint review and retrospectives.
Throughout the project I kept track of risks with the help of our risk log document. I often updated this document when risks were recognized, which I then helped prioritize and mitigate.
QA and Pipelines
As both design and QA lead, the functionality of the build was one of my top priorities.
I revised and improved an old conditions of satisfaction document template for testing our levels by updating it to match our at the time plans and expectations. I also created a conditions of satisfactions document template for testing the 3Cs.
I conducted smoke tests every morning after standup. I took charge of build reviews by conducting them at the end of every 2 days starting sprint 3. Build reviews were kept track of using the aforementioned conditions of satisfaction documents.
At first I was the only one responsible for build reviews, but due to the big scale of the project, we started tackling them as a team close to the end which greatly increased the speed of the process.
Sprint Goals and Responsibilities
Level Conditions of Satisfaction Document template
High Level Planning
Risk Log