“A fast-paced puzzle-platformer with a preparation phase to mold the level to your advantage!”
Stomp-Fu is a 2D puzzle-platformer that tasks the player with solving short, one-screen puzzles with a time limit. The rooms these puzzles take place in all feature a button. This buttons spawns a handful of collectibles. Gathering these collectibles and reaching the end of the level before time runs out is the main goal of the game. This project took around two months to develop and was made by a team of 6.
I only worked on Stomp-Fu for the duration of its production phase. One of my responsibilities for this project was to create the first level of the game. This level ended up consisting of three sections: two main levels and one transitional area teaching you the main mechanic of the next level.
6 Developers
8 Weeks
Developed in Unreal Engine 4 Released on Itch
As for my personal roles and responsibilities within the team, I was one of six level designers as well as the co-lead for the “Mandatory Collectibles” feature. Due to the nature of the project however, with it only taking 8 weeks to develop, everyone essentially did a little bit of everything, myself included. Stomp-Fu was centered around feature development rather than cohesive level or game design.
My biggest contributions to this project were the levels I’d made, the blueprint that changes the cameras transform (used at the start of the first level), the QA testing I’d done throughout the block, and the Itch page itself. I also wrote the Devlogs found on the Itch page.
This level its main purpose is to introduce Stompable Blocks, as well as force players to think on the spot and come up with the most efficient path through the level within just a couple seconds.
It’s important for a level like this not to be too complicated and to be readable within seconds, as it is the first one.
This image shows “Elevators Pt. 1” broken down into individual gameplay moments. This is also where rational Level Design comes into play. Dividing the level up into a multitude of smaller gameplay moments allowed me to score them in terms of difficulty, as well as curate the intended player experience to a t.
This image shows “Elevators Pt. 1” its golden path.
This level in particular was broken down into 5 smaller gameplay moments. While I don’t intend to go over each and every moment and scene present in the level, I do briefly want to talk about the metrics being measured and how I can calculate difficulty through area separation.
For example, let’s take Section 3. I intended this section to further engage players into what they’ve learned up until this point. It makes use of both a Stompable Block, also found in Section 1, as well as a set of Trampoline Blocks, also found in Section 2.
now, Section 3 features the following LD elements:
– 2 Mandatory Collectibles;
– 1 Optional Collectible;
– 1 Stompable Block;
– 3 Trampoline Blocks.
Furthermore, a total of 4 Stomps are required to beat the section and move on to Section 4.
the team and i then created a difficulty table (and system) to determine the difficulty of each section present in the game, based on what features it makes use of how they are presented to the player. This made it so that we could curate the player experience to be as difficult or easy as we needed it to be at any given time.
As confusing as the table below might eye to the average person, it shows that section 3 was actually the hardest section in sublevel 1. unfortunately, i was unable to iterate upon this section before release.
This image shows the difficulty table created for “Elevators Pt. 1”.
From left to right, it starts by going over a feature or its placement within the level, and asks a question about it. Then, it goes over every scene from 1 to 11, and answers those questions using the following terms: “Beginner” (B), “Intermediate” (I) and “Expert” (E). These three terms each have a set amount of points assigned to them, meaning that once every section within a level has been graded, it ends up with a final score. This final score can then be put in a graph, such as the one to the right, in order to oversee the entire level’s pacing in terms of difficulty.
This image shows the difficulty graph for the entire “Elevators” level, not just pt. 1.
It constantly sways back and forth between easy and hard. This is because the rational level design process was only implemented in the final few weeks of the project, meaning there wasn’t much time to really use it as much as we wanted to. however, despite the rollercoaster-like graph, playtesters didn’t seem to care nor notice. to them, the levels felt just fine difficulty-wise.
This level its purpose is to introduce Moving Platforms, as well as to give players a much needed break after everything that happened in the level prior. It also gives players some time to figure out what the most efficient path through might be.
I made it so that there’s enough time to scan the level ahead of time whilst, for instance, on the Moving Platforms at the start of the level.
It’s important for a level like this not to feel like too much of change of pace from the other levels.
This image shows “Elevators Pt. 2” broken down into individual gameplay moments.
This image shows “Elevators Pt. 2” its golden path.
This level its purpose is to introduce players to a mechanic before being sent into a level that’s revolved all around them.
It requires no effort from the player, but that’s also where its main improvement point lies.
It’s important for a level like this to engage players into wanting or needing to learn about new mechanics.
This image shows “Elevators Pt. 3” broken down into individual gameplay moments. However, because the level only consists of a single gameplay moment, there isn’t much to break down here.
This image shows “Elevators Pt. 3” its golden path.
Despite “Elevators Pt. 3” falling a bit short in terms of actually fulfilling its purpose, namely to explain the new camera mechanic, I did manage to come up with a concept that would most likely resolve the majority of issues found with it so far. One of the biggest flaws with it currently, is that people just zoom past it and don’t even pay attention to the new mechanic. Furthermore, there is no puzzle. You just walk forward and that’s it.
So, to combat those issues, I drew up a sketch of what should’ve been. For starters, with this updated layout, there is actually a puzzle present. The player walks in the room, thinks they can just walk forward, but are then stopped by the camera closing the door when they enter its line-of-sight. This creates a problem in the player’s mind, making them actually have to think about what to do next. The solution isn’t necessarily anything to write home about; just avoid the camera’s line-of-sight. However, this much more effectively teaches the player what this new mechanic actually does.
This image shows an old test version of the scrapped level “Tight”. I placed a bunch of the feedback points I’d gotten over the course of its development as some sort of to-do list.
This image shows an old test version of the scrapped level “Tight”. This version shows iteration based on last version’s feedback points.
This image shows an old test version of the scrapped level “Tight”. This version shows another iteration based on last version’s feedback points. This was the last version of this level before it got scrapped.
This image shows an old version of the level “Elevators Pt. 3”. As you can see, It used to be even shorter than it is now. Players found it to be bare and uninteresting, so I changed it to, one, take up more of the screen, and two, introduce the next level’s mechanic to give it more of a purpose.
This image shows one of many gym levels. This one in particular focuses on metrics. This is where I tested what did and didn’t feel comfortable for the player. It is also where I determined metrics such as the max ceiling height, or max jump height.
This image shows one of many gym levels. This one in particular focuses on chaining multiple LD elements after one another. The reason the level is set-up in this way is because I would later go on to use a similar set-up in one of my levels.
Encourage player engagement in a non-intrusive manner for them to care about potential new mechanics, or LD Elements for that matter. I cannot tell players what to do or which path to take, and that’s something I’ll need to keep in mind whilst designing levels in the future.
It’s nice to have a set of rules to keep to and fall back on, but the rules we settled on as a team were too specific. Not to mention the sheer amount of specific rules each and every one of us had to adhere to. This made creating levels a hassle, as I was constantly worrying about whether or not I was accidentally breaking some kind of rule. Rules and agreements within a team are good, great even, but don’t make them so strict and so specific that they limit the team’s creative vision.
Do not put too many, if any, Optional Collectibles in the Golden Path. It might as well be a Mandatory Collectible at that point. Encourage players to explore the game’s levels outside of what they’d perceive to be most efficient path. Optional objectives, such as collectibles, are perfect for this. They act as a nice reward for completing an optional, often intrinsic objective.