Notes on level design workflow for the 3D platformer Big Hops

overview of the Ocean intro level

I made some levels for the 3D platformer game Big Hops by Luckshot Games, and it's finally released! You can now play it on Steam, Switch, and PS5.

So far the game is generally reviewing between 7/10 or 8/10. Most players like the level design, but some hate it, which is fair -- we went for a chill cozy-ish experience that won't hit for everyone.

Despite the lack of universal adoration, I do think we figured out decent level design practices that worked OK for this scope / type of 3D action game. Some of these dev practices may surprise you; it certainly surprised me when I realized what we were doing. So in this post, I'll talk about some of our level design workflow for Big Hops...

SPOILER ALERT: I spoil some mechanics and levels, but not in detail. I don't spoil any of the story or the ending. Don't worry about it.

overview of the Forest intro level

You play the chapters / biomes in this order: Forest, Desert, Ocean, Mountain. 

However, we actually made them in this order: Ocean, Mountain, Desert, Forest. (3, 4, 2, 1). The conventional wisdom is to make the beginning of your game at the end of your dev cycle, to craft a stronger first impression with the benefit of your accumulated regrets, and I think that proved true here.

Sewer layout planning

The first step is often the hardest. And the first world we made, the Ocean chapter, definitely took the longest. We had to figure out what "one unit of content" looked like, how "emergent" we were going to be, what a "boss fight" or finale looked like, and so on. Even though it was a bit painful, I kinda like how it came out, it has maybe the most free-form levels in the game.

Production on the Desert (you reach it after 2 hours, but it's the 3rd chapter we made) went comparatively smoothly, since by then, we had established a pattern for each world: a start level, a big town area, 3-4 item types, 3-4 levels to introduce each item, and an ending climax. We didn't have to debate the shape of a chapter anymore.

wireframe overview of the Desert intro level

Desert planning

To start work on a biome, the director Chris wrote and presented a design brief. It was just 1-2 pages outlining a general story premise, level ideas, and various mechanics to introduce in each level. 

Then the whole team would get on a big video call and start picking apart his plan, but like in a nice way.

After some consensus-building, we'd all prototype and validate different items and mechanics simultaneously. 

Cactus fruit pitch

For example, when we all started working on the Desert chapter, I started with a stealth prototype, Mickey did fire propagation, Eli made slingshots and rope ballistas, etc. and then we all played each others stuff and gave feedback. This is a big advantage of having a generalist indie team: we all know how to make stuff. Like Jonny was the main artist, but he also made some of the coolest levels too... and then I had enough art sensibility to follow the style guides when decorating other levels, freeing up Jonny for other tasks.

If an initial prototype wasn't an obvious slam dunk, sometimes we'd try to prove it out with a beat-driven method popularized by Portal: we'd make a big "beat zoo" test level playground, and then fill it with little gameplay chunks / situations / puzzle-beats. I use "puzzle" very loosely here, to refer to any designed situation that asks for more than the core traversal moveset.

Blockout test level with various beats: "cart bomb", "protect the cart", "cage match", "minesweeper"

We settled on this directed puzzle-beat approach after a looser open-ended sandbox design approach wasn't playtesting great for us. I'm sure someone has the perfect holy grail subtle systems design to scaffold big toolboxes elegantly for all players, but we went for a traditional level design solve: most of our puzzle-beats have a fairly specific "ask" / critical path solution, and everything you need is usually nearby. Yet we do have one redeeming design twist: we don't care if you bring a weird item to sequence break something, and some players (especially speedrunners) really like doing that.

But still, we mostly designed for a canonical solution / critical path. When prototyping puzzle-beats, I found it helpful to try to name each beat with a pithy 3D text label in the game world to try to sell the "parti" / concept. 

another beat zoo

Like "Bomb Aquarium" was a big zero-gravity area full of mines, and "Scary Train" was a soulslike pastiche with a giant minecart trying to run you over, etc. If you can't name something, then it might be too complicated or confusing. These beat callout labels also make discussion and feedback clearer too ("Bomb Aquarium felt broken, but Scary Train is funny")

Some challenges shipped in the final game are just art-passed versions of the best beat prototypes. But making bad beats is important too, because it's how you know which parts of the possibility space to avoid. I must've made like a dozen minecart beats and many of them aren't in the final game, but the survivors were stronger for it.

Splines Rule Everything Around Me

None of this was possible without some very smart level design tool tech investments near the beginning of the project. At the time I thought it was just some silly math-boy nerd overkill, but it proved to be utterly visionary and essential...

Path Shape animated GIF

Specifically, Chris and Eli built out this cool fancy "Path Shape" construction system: 3D splines that we could curve, deform, subdivide, invert, and even carve each other arbitrarily. Each Path Shape has various tiling UV presets and bevel / contour presets, and you can even voxel paint on them to blend different terrain texture types.

For big wide areas like the open desert or the ocean seafloor, we used a modified version of the Unity Terrain tool. But for the other 99% of the level geometry, we used these Path Shapes for cliffs, ponds, cities, interiors, mountains, caves, tunnels, train tracks, pipes, clouds... if it's not foliage or furniture, it's probably some type of Path Shape / spline mesh. 

It was my first time on a big project with a parametric / procedural workflow, and I had a pretty fun time. I think the key to this workflow was maximizing artist control and modular configs, vs. clever programmers trying to automate everything and make assumptions.

metrics test level by Chris I think

One big surprise about level construction: we were pretty casual about metrics. Usually you'd expect a platformer to rely intensely on metrics, but for us, it just wasn't a big concern. Chris made some metrics test levels, sure, but those were more for testing (his really good) player controller, they weren't a design bible to obey.

I think your attitude toward metrics depends on your mechanics. In our case, we were making a chill platformer with generous climbing and ledge grabs. We had very forgiving "soft metrics", versus a tile-based 2D precision platformer with "hard metrics"?

The project team was also small and flat enough that we could "vibe out" the metrics together. We communicated about metrics subconsciously while playing each others' levels, etc.

Not that I could've measured much, since Unity doesn't have a built-in ruler, and I never asked for a custom one. Usually I just eyeballed distances and heights as I blocked out levels with first pass art, subconsciously using textures and props to guess the scale, and then I'd do short quick playtests to run through it and adjust as necessary. Measuring is actually kind of slow, and maybe even a waste of time if you're already playtesting the metrics frequently anyway.

Lastly, I think metrics depend on your construction methods. If we were using Quake-style brushes or tile-based modular construction, we probably would've had to measure a lot and stay on grids. But instead we had this magic stretchy Path Shape tool that could cover gaps and deform for any space.

everyone likes a custom play mode button!

I do have one general tip for anyone making any sort of 3D action / exploration game in Unity: add a custom "Enter Play Mode at Scene View Position" button to your editor tooling, similar to Unreal's "Play From Here" functionality. Conceptually, your editor code should wait until after you enter play mode, then grab a ref to your player object somehow (find something tagged Player?) and teleport it to the scene camera's position. Because you waited until play mode began, the teleport won't persist, it'll just be a temporary thing for that play session.

In general you should always try to make quick playtesting as easy and painless as possible, so that you do it more. And in my experience, this button makes playtesting specific parts of a level so much easier, vs. manually moving player objects every time you want to test something... and then afterward forgetting to move it back to where it's supposed to be? Argh!

I made our custom play mode button using the Unity Toolbar Extender package on GitHub. If you're using Unity 6.3 or later, you can probably rig up something similar without that package, using the new built-in MainToolbarElement API -- which is very limited, but it can do a button at least.

***

Overall this was a fun project and I learned a lot on it. 

This probably won't be the last of my level design thoughts about Big Hops -- it made me think about a lot of design / theory stuff, especially since it wasn't the typical realistic 3D first person shooter stuff I usually work on. 

But that theory stuff will take a little longer for me to write and ponder, so I'll save that for a future blog post.