CAGD 370 - Blog Post 1
- Els Fouche
- Mar 7, 2025
- 4 min read
A Hop, Skip, and a Jump
Level Design
A Hop, Skip, and a Jump is a 3D platformer that utilizes player-placeable gravity spheres that bend space allowing for slingshot maneuvers to get through levels. The player is also able to dash forward based on their current velocity. This movement is dependent on the player's current movement vector as well such that a player that is jumping while running forward will launch diagonally upwards when activating their dash.
This presents a unique challenge to me as a level designer. Considering the player's extreme movement capabilities, how can we go about controlling their flow through the level in a way that is both intuitive and fun?
Annotated Map
I decided I wanted to start as simple as possible. I created the above map as the most barebones version of the introductory section for the player. I wanted to focus on cleanly conveying the dash (aka slipspace) and gravity sphere mechanic visually in the annotated map to establish precedent for future maps. This map (along with part 2) was given to the developer for feedback and, as expected, was kicked back due to being too short. Of note, I created these sections with the expectation that the player would not have access to placing gravity spheres yet and would instead have to make use of pre-existing spheres.
The feedback for version 1 requested that more time be spent exploring the dash mechanic before moving on to the gravity spheres. As shown above I expanded section 1 to create multiple opportunities for the player to experiment with the dash while also adding a secret area that requires the player to fall into a pit hazard to reset. This was done so that the player will learn that collected secrets are saved automatically.
Section 2 of the map focuses on the use of gravity spheres to cross large gaps. Here I wanted to focus on cleanly conveying the point in space where activating the dash would carry the player across the gap. Additionally, there's an opportunity for the player to experiment with using gravity spheres to reattempt previous sections without needing to reset via the pit hazard.
Lessons for next time:
Adding a secret in section 2 to further incentivize player's exploring the reattempt path would be beneficial.
Adding a top-down overview of the map will be useful in conveying scale as well as de-obfuscating the third axis of rotation.
Reducing the size of the map components is planned in future versions to allow for larger maps to be constructed. This was not done in this version due to the previously mentioned desire to establish a visual language for the maps that clearly conveys different mechanics.
Paper Prototype
For the paper prototype our designer established the game rules while I was tasked with creating the physical components. The rules for the game were somewhat vague but after discussion the designer and I were able to reach an understanding. The player must place gravity spheres on the level which they can only enter at a specific angle (± 27.5° from dead-on). The gravity spheres then shoot the player out in a straight line to the next sphere.
I made a key mistake during this process. To rapidly prototype the game I decided to work in a physical medium (in this case, pencil and engineer's pad). This made constructing walls for the players to get around a breeze but also meant that players felt intuitively that the play space was grid-aligned. This led to some confusion during the playtest.
For level 1 the player must simply show that they understand how to use the gravity spheres by maneuvering around a wall. This was, as expected, quite easy for most players. One point of confusion was the 'max spheres' notation in the upper left. Many players did not notice this. Originally I had written this as 'par' similar to golf; the designer requested I change it to a maximum value instead. This would have increased the challenge for the game but that proved unnecessary due to the aforementioned grid-alignment misunderstanding.
This was the final level for the paper prototype. All test players were able to beat all the levels once the grid-alignment confusion was cleared up. Players reported that they felt proud that they were able to beat the level with less spheres than the 'max orbs' value. Players also reported a high level of engagement with and enjoyment of the game.
Lessons for next time:
Beware using grid paper on non-grid-based games.
Ensure vital player information is presented more prominently.
Consider creating modular pieces for levels to allow for on-the-fly level modifications.
Level Tools Programming
Following our paper prototype I began work on creating a checkpoint system to allow for players to be reset when they fall out of bounds.
The above video shows a simple checkpoint system in Unreal Engine. The checkpoint actors have a capsule radius that detects the player as well as a gizmo associated with a transform. When an actor with an AC_PlayerCheckpoint component triggers one of the checkpoints it changes its appearance and resets the previous checkpoint's appearance.
The actor component AC_PlayerCheckpoint meanwhile grabs the transform of the checkpoint actor's gizmo and stores it. If no checkpoint has been hit the system uses the player start location as its fallback point. The component exposes a function for reseting the player to a specific location when called, allowing for hazards or killboxes to reset the player's progress when touched. The system is meant to be extended to allow for additional effects such as a quick camera fade-in/fade-out and obstacle resets, as well.
Lessons for next time:
Don't get distracted working on a fancy shader; it's an inefficient use of time even if it's fun.
Final Thoughts
Overall this has been a productive and informative sprint. I'm eager to begin blocking out level 1 and working on the annotated map for level 2.
Comments