Deep Climb (2024)
Deep Climb is a first-person, precision platformer where the player must learn the strange controls and mechanics to climb upwards towards the surface.
My Role: Design + Programming
Engine: Unreal Engine 5
Team Size: 5
Download: Deep Climb Itch
Deep Climb provides the player with a slow walking character who has to charge their jumps before being launched. The player is unable to walk while charging these jumps and will launch forward or upward, depending on if they are holding forward or not. The trajectory of these jumps are fixed and scaled based on the charge. While mid-jump, the player has access to two abilities.
J.O.L.T. can be charged with left mouse and when released mid-air, launches the player in the facing direction.
V.A.U.L.T. can be activated with right mouse and will multiply ascension and dampen descent until hovering, provided they haven’t run out of fuel.
The player character wakes on the seafloor and must use these abilities to climb to the surface, finding narrative collectibles hidden on the way upward.
Developoment
Summary
Deep Climb was my university capstone project. It was developed over 6 months starting with pre-production, where we brainstormed ideas before digging into one and then creating a game design document and outlining scope/timelines. At this stage, I worked primarily on the ideation of the concept and its mechanics, while prototyping said mechanics in Unreal Engine 5’s blueprints. This took us through to the completion of a vertical slice with its two jump types, two abilities, the post-processing volume, and some art assets.
With approval from the lecturer, we began production of a demo for Deep Climb. This stage involved bug fixing, implementing more robust blueprints, regular playtesting and analysis, development of more art/narrative assets, and level design and tutorial development. I focused primarily on fixing bugs in the mechanics, testing and improving the tutorials, and some narrative writing.
Our goal for Deep Climb was to create a gameplay foundation with simple mechanics that interact in complex ways, from which we could continue to grow the game by adding more elements, such as; abilities, dynamic platforms, alternate endings, multiple levels, etc.
Level Design
For the Deep Climb demo, we created the first level with the goal of teaching the player the foundational skills; the two jumps and two abilities, and how they can be combined. We decided to break the level up into sections where each one would teach the player a different skill, starting simple and growing in complexity with progress in the level. Since multiple people would contribute to the construction of these sections, I outlined these details along with a workflow to follow and some rules to keep in mind. I found this created sections that ‘talked’ to the player in the same way, such as using the collectibles as rewards for completing alternate paths, and using fixed slope angles to reduce confusion between walkable and non-walkable slopes.
The three sections I worked on focused on more complex uses and combinations of the abilities. Knowing this, I started sketching ideas, focusing on creating platforming challenges which would teach the most simple part first, then build onto that until the final challenge required the player to demonstrate the skill being taught.
Taking these platforming challenges to graybox, I focused on starting with low-risk challenges and increasing the risk towards the end, by making the platforming more challenging and/or causing the player to fall further if they make a mistake. While boxing out the challenges, I also looked through our inspiration and concept art to incorporate interesting compositions with a variety of wide and narrow spaces.
Finally, after testing the graybox sections, I used our library of 3D assets to replace graybox elements where detailed collision was needed and visually covered others to avoid unnecessarily detailed colliders. 2D assets and lighting were both used at this stage, primarily as wayfinding to assist the player in navigation, and secondarily to push the atmosphere.
World Design
With each section of the first level underway, I worked on creating the ‘ground floor’ where the player would start and could fall all the way back to. I placed each section into the level, in order of increasing complexity of the skill each was designed to teach. As we encouraged players to explore the level thoroughly for secret collectibles, it was vital that I create an impenetrable wall around the level as any accidental out-of-bounds exploration could be perceived by the player as punishment for exploring. To avoid this, I spent a good deal of time creating walls that funneled the player to the starting area, playtesting, exploring and filling any holes that were found.
I also worked on connecting each platforming section to the next. Being an underwater cave environment, I utilised basalt pillars and enclosed tunnels to create these connections in plausibly natural ways. I also prioritised positioning platforms over and under each other, increasing the odds that a player could save themselves from falling back to the beginning.
Tutorial Design
The tutorial became an unexpected focus of my attention as it evolved from a suggestion to start with the more simple platforming, to a set of tutorial levels with a contrasting visual style and explicit explanatory text. Initially, I had assumed that if the first level tutorialized the mechanics well, this would be more engaging for players, however, due to the dim lighting and less-than-traditional controls, players found the game more frustrating than intended.
As such, we pivoted our design goals for the tutorial. I focused on creating a standalone level, better lit to improve clarity and aid navigation, with simpler geometry to guide the player and in-world text prompts to act as waypoints. We saw an improvement in player understanding with this tutorial, however, some players still had difficulty navigating to the end and the explanation text would confuse as often as it would clarify.
With this feedback, I created 3 distinct levels focusing on the jump, the J.O.L.T. ability and the V.A.U.L.T. ability. The goal here was to create greater separation in the players mind and allow them to focus on a smaller amount of information at a time. I would adjust these levels further based on more playtesting results while others created and implemented the green symbols and formatting on the tutorial text.
Programming
I was one of two programmers for Deep Climb, where my primary focus was on the player character. Much of this was developing, prototyping and iterating on the player’s abilities;
J.O.L.T. – for halting vertical velocity and a horizontal shove in the facing direction
V.A.U.L.T. – for an upward boost and fine lateral positioning.
Jolt was the simpler of the abilities as it borrows many techniques from the jump blueprints I had already made. Notably, was the check for the player falling and the availability of Jolt. This limited the player to using Jolt once per jump, resetting the ability on landing. When the player uses Jolt, it enters a loop which increases the ‘strength’ eventually reaching a maximum. When the player releases the ability, so long as they are ‘airborne’, the vertical velocity is set to a fixed value, which creates a familiar double-jump effect, and the facing direction is combined with the ‘strength’ value to launch the player in the horizontal facing direction.
I experimented with some of UE’s inbuilt functions when developing the jump and Jolt blueprints, however, I found these introduced bugs and unintended behaviours which I was unable to rectify. Instead, I relied on my knowledge of maths and physics to manipulate the player velocity manually, which eliminated those bugs.
Vault was initially a more basic ability, only affecting the vertical velocity of the player. Through many internal playtests, I found this basic ability less useful and more boring compared to Jolt. In an overhaul that would maintain the thrust aspect of the ability, I suggested that Vault should additionally allow for fine control over the lateral position. This resulted in the ability having two states; ascend and hover. When the player uses Vault, it checks if they have enough ‘fuel’, allowing players to use the ability in short burst, before checking if they are falling or rising and executing each state accordingly.
Ascension simply adds a fixed value to the player’s current vertical velocity, causing them to jump higher. Similarly, hover adds a fixed value to the vertical velocity, slowing their descent, however, it also sets the player gravity to 0. This way, when the velocity crosses from negative to positive, the vertical velocity can be set to 0 and the player becomes fixed in vertical space. While player movement is usually disabled while not grounded, a check bypasses this when the player moves while thrust is active and has fuel, resulting in precise control over horizontal positioning while hovering.
When testing this overhaul, we found that we wanted to be able to spend more time hovering. Before the overhaul, this would have been a difficult change as Vault used a ‘fuel’ system which depleted at a fixed rate. However, with the two states, hover and ascend could have independent values which allowed ‘fuel’ to be expended at a variable rate, faster when ascending and slower when hovering.
Want to know more about the development process? Anything unclear or have any feedback? Contact me!
Frazer 'Dolph' Carpenter | Game Designer 