Ups and Downs of 2.5D

February 22, 2019

My trajectory was explosive for parts 1 and 1B of this series, but this post has been a bit harder to put together because my outline was apparently terrible. Despite that, I'm going to try to stick it out.

Part 2: Why Care About 3D

It seems that a much larger percentage of games are 3D than was the situation in the past, but a 3D game is by no means necessarily better than 2D. I brought up in Part 1 of the series that one of the driving motivators for 3D in Maven was the jump mechanic. Jumping is a pretty good representative of the primary class of 3D features that we care about; so I'm going to try to visit the questions posed at the end of Part 1: "How might an engine fake jumping in a layer-based 2.5D game?" and "Why is jumping important?" (I know, I know. I changed the questions a little bit; so those aren't exact quotes. But if I'm quoting myself...)

Fake Jumping in a Layer-Based 2.5D Game

In the old Maven demo, we tried to produce a jump mechanic that would allow the player to jump over things or jump up to higher areas. This visual should give an idea of what we are talking about with the jumping-over-things part, and we'll touch on the jumping up part later.

Up to this point, our development had consisted in layer-based 2.5D game engine land; so we had to consider how to accomplish this feat while always keeping the player on some layer.

Fake Jump Method #1

We'll start by considering the simplest implementation of jumping which ignores layers altogether.

With this method, we need to mark the areas in the level that the player can jump over slightly differently (heretofore denoted "jumpy") than other walls. When the player walks into a wall or one of these jumpy areas, movement is blocked. But when the player jumps into a jumpy area, movement is allowed. In other words, we set a flag on the player entity to indicate it is in a "jumping" state, and our collision checks account for this flag. Of course, we render the player sprite at an offset so that the player gets an illusion of height.

Based on my limited knowledge of the game (not having played it), I believe that the jump mechanic in The Legend of Zelda: Link's Awakening probably falls into this category of jump implementation.

One of the obvious problems with this method is that ignoring other layers isn't necessarily ok. What if there is something above Sasha, and she smacks her head on it?!?

Fake Jump Method #2

Ok. So we want to account for the layer above.... Alright, in this method, we will just switch the layer that the player is on at some point during his jump to the layer above and then back down to the original layer at the end.

This method is probably more in line with how we expect the physics in our layer-based engine to work. Unlike method #1, the jumpy areas with this method should probably be specified on layer 2 rather than on layer 1 where the barrels actually are. The barrels can be specified as an ordinary wall, and we leave the hard part up to layer 2.

If I recall correctly, the old demo of Maven used this method for its jump mechanic. And this method works pretty well for jumping up to higher areas.

Howerver, method #2's jump is odd because the player is only on one of the layers at a time. One moment, Sasha is being blocked by the barrel on layer 1; the next, she is so blocked by the flying hippopotamus on layer 2 that she doesn't care about the barrel. How do we decide when to make the switch between the player being on layer 1 and then on layer 2? Maybe the player's upper body is on layer 2 while the lower body is still on layer 1?

Fake Jump Method #3

As a slight modification to method #2, why don't we just let the player be on two layers for a brief period of time?

Now Sasha can multitask and hit both the barrel and the hippopotamus at the same time! Also, both the developer and the computer processor have more things to worry about!

In all seriousness, though, this method would work pretty well, except that we've been ignoring the barrels in the room this whole time.

Why Fake Jumping Will Never Be Real

Regardless of which method we pick (and I'm sure there are other ways I haven't covered), we are always going to run into the problem of landing the jumps.

What should happen when the player decides not to finish jumping over the barrels? The naive developer would have a broken situation on his hands, but since we aren't naive:

I believe that the old Maven demo implemented the fail-safe return trip.

So why can't we make it work?

As I hope that the diagrams have begged, the obvious answer is that we want is to specify the player as positioned somewhere between layers, but that's cheating* in the layer-based engine. AND we need to know exactly how tall both Sasha and the barrels are, because those flat squares aren't doing them justice. Sure, we could keep fudging these values at finer and finer levels, but we will only achieve the real deal if we start representing the values in a true simulated 3D environment.

Is it really worth the effort, then, to make a jump?

Jumping Is Worth Effort

I believe that jumping is worth it because it can easily add more fun to a game. Super Mario Bros. is fun because you can jump. No top-down 2D game is fun just because you walk around. Jumping also opens up the game world to be a grander experience for the player, which brings me to the second part of the answer.

It's not about Jumping

Jumping just represents the tip of the iceberg for what the third dimension of height adds to a game. Height can be a incredible tool for bolstering the sense of exploration a player feels—and that's important to us because Maven is an adventure game with an intended core aesthetic of discovery. I remember how my experience playing The Witness was significantly dampened by the artificial boundaries placed on the tantalizing vibrance of the mysterious island because I wanted to explore the world. The game, being a puzzler, wouldn't let me walk off even the smallest of ledges!

(I have heard great things about The Witness and was mostly turned off because of the motion sickness it brought on for me.)

There is something exhilarating about the freedom offered by a game with fewer boundaries. Around the time I played The Witness, I picked up The Legend of Zelda: Wind Waker for the first time. When I started Wind Waker on Aryll's Lookout, I immediately tried to jump off the edge. I was disappointed that all of the edges of the platform were blocked off by short railings I couldn't surmount.

Then I started down the ladder. I could let go and fall off to the dock below! And then I could even jump in the water!!! AND SWIM INDEFINITELY AWAY!!!!! (then I drowned) My excitement was sobered somewhat by the drowning, but I was so excited at the great freedom I felt as a player to explore this game world by the little extra feature of falling.

Later, Breath of the Wild opened that door even further, pushing the limits of open-world game by allowing the player to climb nearly anything (and fall too).

As a specific recent example, CrossCode is a 2.5D game that does an amazing job of utilizing the extra dimension to enhance its gameplay experience. The way they have implemented their 3D physics allows for some awesome moments like this:

Game Soup has an excellent video on YouTube analyzing this specific aspect of CrossCode's design. CrossCode's devs also put together an interesting blog post that is tangentially related to this one.

Onward and Upward

Where to from here? Next stop we'll be working toward making some of these lofty dreams a reality by looking at options we considered to solve our flat-earth problems. And in the longer term, hopefully you'll see a game from us—and perhaps even from others—utilizing these techniques to make better games.


*I'm making the argument that this feat is impossible by definition, not by practice. We'll talk more later about a similar concept, but then we are moving away from a layer-based engine.