GENRE
Speedrunning platformer
CONTRIBUTION
Product Owner, Gameplay Design
Sound Design, Music
TIME
7 Weeks
(2023)
TEAM SIZE
9
ENGINE
Unreal Engine 5
gabriel’s journey
third person
PC
single player
5 - 20 minutes
Use movement-oriented abilities to beat your own time with upgrades from previous runs.
concept
Our 3rd Game Project in Futuregames had much more openness in the theme “natural phenomena” and we took this to our advantage by choosing black holes as our phenomena. We then merged this with our decision to make a 3rd person, single-player, parkour speedrunner where you use movement-oriented abilities to beat your own time with upgrades from previous runs.
For this project, I took on the responsibility of being Product Owner, which involved making sure we stayed within our vision of “wanting the player to feel agile and clever enough to beat the time challenge" as well as keeping it within scope and maintaining the decisions and ideas universally in check via the use of documentation.
Besides being the P.O, I also worked extensively on the gameplay and sound design
game pillars
Fast-paced Gameplay
Reach the finish line in a specific amount of time. Beat the clock, yourself and others to be the best.
Replayability
Multiple routes throughout the level to choose from. Test and master them.
Invest in upgrades to your abilities. Create unique builds for the determined routes.
my contribution
click the buttons to go to their respective sections
design process
In the first meetings, we knew we were making a speedrunner platformer but it was later in the first week that we decided on an ability system (dash, wall-run, etc) that the player could upgrade via a shop. I then devised a Feature Prioritization Table, where we could visibly decide which ability we would implement depending on its complexity and impact in the game.
During a meeting, I brought up the question if we wanted the game to have more mechanics/abilities rather than levels since having plenty of both would be out of scope. The majority of the team preferred having more levels than mechanics, so we limited the number of abilities.
This made me fear that players would have less agency and options, therefore deviating from the game’s vision and pillars
To solve this, I suggested having upgrades that don’t affect the number of abilities and their synergies, but rather small numbers that might be detrimental to a successful run (e.g dash cooldown time, grappling hook speed). If you want take a look at the document I did were you can see these numbers in detail, you can find it here.
movement
Being a speedrunning platformer, I had to be extra careful with how I designed the player movement. To make things simple for myself, I approached every decision with the question “will this support the theme of making the player feel agile and clever?”. If it didn’t, I would discard the idea or decision.
week 2 of progress
In the video above, you can see the work the programmers did during the 2nd week of the project. Despite already having implemented a tonne by way of the dash and wall-ride, I could see the flaws in how it would collide with our vision for the game.
If you look closely to the beginning of the video, you can see how the character vaults when trying to go over a ledge — thus cancelling the momentum the player gains while running. These kinds of momentum-cancelling interactions were going against what we aimed to do, so I worked carefully to make the movement as smooth as possible, while also being forgiving.
coyote time
Speaking of forgiveness, I brought to the programmers the idea of coyote time — which is the possibility of jumping after a few frames (between 1 and 3) off a ledge. So when a player runs and jumps off a ledge, there’ll be some forgiveness that will let them jump a little bit after there is no longer contact with the ledge.
from directional to strafe movement
After cautiously working with metrics such as movement speed and air time, the team was quite happy with the overall player movement. Playtesting revealed that players would enjoy the feeling of speed they get from running and using the abilities, but several testers said they felt the movement was a bit difficult to control.
This made me go back to the drawing board and try alternatives (and causes) for this. I spent some time researching other games where the movement feels good - and games where it doesn’t. In this process, I started looking at how would the character move if I were to drastically move from one side to the other.
I then realized that our character’s rotation was movement based and not camera based.
Changing this made a massive difference. Most of my teammates were joyful and appreciated how strafing made the movement easier to control while also making the use of the camera as part of the movement - which helped with direction.
abilities and player preference
During the process of making the final decision regarding the abilities, we asked ourselves something we haven’t realized: should the upgrades be linear or non-linear? We originally had the upgrades be linear, but since replayability and player agency was one of our goals, I decided that non-linear would be more suitable - but it comes with a challenge: I had to redo the upgrades and make them independent.
This image is from the original Gameplay document. The upgrades were a couple of specific numbers, but they would become higher/more powerful the better the upgrade. There were also extra abilities as upgrades that I decided to scrap so we could stay within scope. Therefore I had to work with the numbers of the original abilities rather than creating new ones. This was a reiterative process that kept changing until the last build - weekly playtests made us reassess certain numbers and even levels, making it a symbiotic process between disciplines.
Once the abilities were settled and I had the right numbers for most of the upgrades, I became aware while watching other people play that there were some abilities that players engaged with more than others. Players would run and use their dash ability while barely using the slide ability. This to me meant one thing: The slide upgrade is not powerful enough - players don’t see a reason to use it. Therefore, I ramped up the numbers so that the sliding speed would be substantial and thus a key ability to use when trying to beat the clock
This had the desirable result: players ended up sliding more after realizing the upgrade was of significant power.
footage of alpha, beta and final build
playtesting
A big focus of this project was how much time we dedicated to playtesting. Having people from within and outside the team helped to fine-tune details that we were struggling with to see if they would work in a finished build or not.
One of these details was the jump height. Since inception, I wanted the player to have control over how much they could jump depending on how much they would hold the jump button. Therefore I set a difference of 4 meters between the minimum and maximum jump. I managed to be specific on the numbers by creating a gym level where I could visibly test all the changes I made to the character while having the specific metrics written down.
We noticed several of our playtesters who would only tap the jump button and completely miss the option to hold and thus jump higher, so I needed to address that. In the video above you can compare the old and new versions of the jump difference. I shortened the distance to only 1 meter, which despite being less noticeable, it still gives the player a tangible control difference which they can use to their choosing and advantage depending on the situation.
problem solving
Playtesting was also invaluable to determine player experience issues and even problems which could be resolved by the use of smart sound design. Here are some such examples where playtesting led me to some problem solving situations:
problem #1
Players miss the shop menu and thus don’t realize they can buy upgrades.
→
solution
Added a text popup in the first level and force the players to go to the shop instead of having a choice to continue with the next level or go to the shop/main menu.
problem #2
Players were having a hard time finding most of the coins, getting frustrated.
→
solution
Created a 3D sound loop with enough attenuation that would let the players know they were close to a coin.
sound design
My process for this project was to keep things in the realm of the plausible with a mix of fantasy. Things we are familiar with will have a familiar sound, but fantastic things will have a specific character to it. In this case, I worked a lot in adding eeriness, mystery and a feeling of the unknown - all in connection with the manipulation of time and space by the black holes. To achieve this I used several techniques like reversing and pitch shifting
Having worked on the blueprint for the Black Hole hazard, I simultaneously came up with the idea to have its sound be affected by how close the player was to it. So whenever a player would run into or close enough to a Black Hole, they could hear a fluctuation in the sound - in this case, I chose the pitch to be the modified element. Therefore I created an RTPC (real time parameter control) in Wwise and implemented it using the code below.
The code works as follows: I get the world location of the black hole, and the world location of the player and calculate its difference. This number gets fed to the parameter which changes the resulting pitch. Below you can also see a video of it in action.
animation triggers
animation triggers
In order to have the visual and audio feedback be perfectly in sync, I chose to implement all of the player character’s sounds via animation triggers. These were an effective way to make the reiterative process quick and easy, allowing me to move the triggers and playtest with very little time in between. A thing I learned during this process was the fact that some sounds felt off or weird when I triggered them at the same time the animation was triggered. It felt more natural to move some sounds earlier - as it turns out, the human brain takes longer to react to visual stimuli than sound stimuli (180ms - 200 ms for visual. 130ms - 160ms for audio)
In this blueprint, you can see the code I used to implement the animation trigger for the footsteps. I wanted to make sure the footsteps sound would vary depending on the type of surface the player would run on. I used a Line Trace to detect the type of surface the player is running on and subsequently send this information to a Wwise Switch.
layering and scattering
Since there was some realism to the world of the game, most sounds were designed in a pretty straight forward way (a waterfall sounds like waterfall, a whale sounds like a whale, etc) but the biggest scifi element which was also a big part of the gameplay was the black hole. I therefore took some extra time to work on this and properly communicate to the player that is indeed a hazard and not a pretty purple ball they should interact with.
In this video you can see my design process in Reaper and later my implementation in Wwise. I looked for sounds that could be scattered across the frequency spectrum to catch the players attention. To give it a sense of danger, I used reversed strings and screams processed with a shimmer reverb to give that eerie and ethereal sound that black holes can be known for. In Wwise, I made sure each layer had different probability settings so that it could be scattered - avoid repetition and potentially annoying the player.
music
Despite being primarily focused by being Product Owner alongside my Gameplay and Sound duties, I still wanted to have music that was appropriate to the game. Being a speedrunning game, the music had to be of high tempo and make the player want to tap their foot (i.e move). My mind kept going to games from the 90s and their use of Drum and Bass. I thought that by using a sample pack I could quickly come up with something without worrying too much about making bespoke sounds and therefore spend considerable time working on the mix.
problem
With the Wwise implementation, I ran into a problem. Since we weren’t using a Persistent Level in Unreal, I couldn’t make the music play consistently between menus and levels. Therefore, if a player was playing a level and they suddenly had to restart the level by falling into a black hole or water hazard, the music would restart as well. We were late in the project and couldn’t do big changes, so I had to think fast.
→
solution
Originally, whenever you fall in a death zone or a black hole, a blueprint event would run the Open Level node, thus restarting the level and subsequently the timer. I then realized that we didn’t need to restart the level, we only needed to teleport to player to the original spawn position and to reset the timer. Therefore, I changed the code in those two spots, causing the music to play continually and reducing the demand for resources by not constantly opening the level.
product owner
As the product owner, I made it clear to the team early on that any decisions I made would be based on keeping the game within scope and vision. As I approached my gameplay and sound design decisions in this manner, I invited the team to do the same. This helped to build trust because I was making decisions based on a vision that we all agreed on during the pre-production meetings, rather than my own ego and ideas.
I made sure that every team member felt heard along the way, and even asked for someone's opinion if they had been quiet for a while during meetings. I also asked each person how pleased they were with the project and its outcomes.
Having read The Five Dysfunctions of a Team prior to this project, I learned that having the team trust each other, having candid discussions and arguments, and directing each member to what they personally wanted to work on (thus generating motivation and commitment) resulted in everyone being focused on the project's successes rather than their own. I applied such principles and the results were noticeable the more we worked
I also took some time to assist others in tasks that needed a hand, such as UI, programming and even cinematics for the trailer.
Finally, we had a retrospective meeting and received some positive feedback that reassured me that I'm more than capable of working in leadership and team-building roles, having been praised for being "calm and reasonable" and "keeping scope in mind all the time."
what i learned
Throughout this project, I gained valuable insights into the power of clear and constant communication. Every team member was available on Discord from 9 am to 5 pm. Effective collaboration among team members proved crucial in aligning our efforts and driving the project towards success. Not only in terms of the team, but also in how clear player communication has to be. There were several times where we thought we were being clear by i.e, how big an UI element was, only for playtesting to show us that players would miss it. Again, playtesting being key.
Additionally, the practice of packaging/building the game on a weekly basis helped us see how taking things step by step can be a big change, allowing to revisit previous builds to measure the difference. We caught problems early and could adjust things quickly when issues presented themselves changed. We also worked great when it came to “kill our darlings” - I had to decide for the team to scrap several systems or mechanics and they understood right away.