Isometric Platformer with changes in height?

So I'm looking to make a Top down/Isometric game with a focus on platforming. Aka characters can move/jump/fall between multiple different heights. The art style will be using 2D sprites.

A good reference would be the overworld within the Mario and Luigi series:

Or maybe even Radio the Universe:

I'm unsure how best to go about creating the geometry for levels, specifically when it comes to how entities would transition between different heights, and how I would "paint' these colliders with 2D assets. As an added constraint, I need these levels to work with the Unity NavMesh (or A* pathfinding project) so I can have entities path from position to position.

My current thought is to use 3D colliders, rotate the camera to 45 degrees, set the camera to isometric, and just paint over them at that angle with Tilemaps. I'm unsure how viable of a workflow this would be at the moment.

Any tips?

 

For isometric tile the easiest way would be to make the world 3d. Whether you'd construct the world out of sprites is up to you.

Also see video that shows how "saints of rage" level was done on youtube. For example, this one:

Spoiler

 

It does seem like building the world collision in 3D is the way to go. I guess my only issue then is how to align the art with the geometry. Should I make my camera orthographic? Should I have all art be rotated 45 degrees? This is assuming I am trying to replicate the style/viewing angle of my two examples above.

 

If you want level art to be 2d, then you'll have to make camera orthographic, yes.

Whether the art is rotated is up to you. There are games that mix 2d character graphics with isometric 3d level. For example, Disgaea and Breath of Fire.

Basically you can use 3d cubes and place isometric textures on them by projecting UV coordinates specific way. The issue here is that such projected cubes will not have jagged pixelart edges which may require extra work. If you need them, that is.

 

After playing around with 3D orthographic, it seems that moving to the left/right is faster than moving forwards/backwards. This makes sense perspective wise given how the character is moving in 3D space, but not intended behavior. I'm not exactly sure how to fix such a problem either given the navmesh based pathfinding I need to do as well.

 

If you're using normal navmesh, then there's a trick. You can set updatePosition to false.

In this case navmesh will no longer move your object directly, and you basically will keep t elling it where it is, read where it wants to go (either from desiredVelocity or path) and use that to drive your objects yourself. And your objects can use "forward accelerated" movement.

 

So figure out where it's trying to go every frame, and then just multiply the z Velocity by some value based on the camera rotation?

 

Almost correct.

See, NavMeshAgent gives you CORRECT direction pointing where it wants to go. If you scale just one component of that, in many cases you'll get no longer correct direction. So if you scale Z, it'll fail to follow the path.

When you move character around, you often have "movement vector" which describes where character is moving. This vector can be driven by AI, by stick controls, and so on. The thing is, you usually clamp this vector to prevent character from going too fast. Usually this is something like if "moveVector.Length > maxSpeed" check followed by normalization scale if the speed is too much.

With tilted perspective your character max speed check is no longer a circle, but an ellipse. So when calculating movement vector based on sticks, you'll scale forward/backward sticks by factor. But when you want to CLAMP that movement vector, you'll do something different. First, you'll need to "squish" the movement vector by scaling forward component by a factor, clamp it, then unsquish it.

Basically. "moveVector.z /= factor", "if moveVector.Length > maxSpeed", "moveVector.z *= factor".

Do you follow? If not, you could try feeding this into ChatGPT to elaborate.

There's another trick you could try doing.

Mess with camera aspect ratio and stretch image vertically. In this case you won't need to do any extra math.

 

Which solution would you recommend? The camera stretch seems like a catch all solution, but might cause making sure the art is correctly scaled quite a pain.

 

I'd recommend to try both and see which works better. Because I'm comfortable with math, I'd probably pick solution #1 and mess with movement vectors.

The problem with stretched camera is that it might distort particles

Honestly, I prefer jungle strike perspective, which is isometric where you look at corners.

Spoiler

In which case solution #1 and messing with movement vectors is the way to go.

However you want something like beyond oasis or rpgmaker perspective where walls look like they run in parallel to the floor. Here I'd need test things.

Spoiler

Note that when game is done with this angle, it is not unusual to have no ability to jump. Meaning the level can be represented as flat ground. It might be also possible to use shaders here.

And in games like street of rage or x-men which is another example of tilted perspectives, slowed down forward movement fits the gameplay.

Spoiler

 

Alright so just to confirm here. What you'd suggest I do given:
- The need for a top down isometric perspective.
- 2D sprites for characters and environment.
- Multiple (potentially overlapping) heights.
- Many (dozens) of AI entities that need to path-find across the map.

Is...
- Handle the level geometry with 3D colliders.
- Use an orthographic camera rotated to the desired angle.
- Rotate sprites to face this desired angle.
- Paint on top of the geometry using tilemaps or really whatever suits the style.
- Solve the movement speed issue by scaling the movement vector based on the perspective.

Is all this correct?

 

Is path finding really necessary? I don't think most platformers have navmeshes or any fancy navigation. Most platformer enemies just bee line the player or have a canned movement pattern. Then they will only pursue the player within their own little radius. Just an observation.

I often think that navmeshes are a bad fit for platformer games since the walkable area is necessarily discontinuous.

 

Sure, in a sidescroller that may not be necessary, but an isometric view where there's potential elevation changes and obstacles? It's absolutely something that needs to be considered.

 

To be totally fair I was just using the term platformer because characters should be able to jump between elevations, and because the visual examples I was providing (M&L series and Radio the Universe) were also platformers. What I'm really going for is a bit of an RTS, where there's lots of units you control and direct that need to path through the level geometry.

 

Yes.

Except this part below:

There are multiple ways to do it. You could make geometry from sprites. You could make it 3d. You could paint tiles on top of 3d. There's More than one way to do it. It is a visuals part so you might need to experiment with it.

 

Oh? What about it? I understand the whole ellipse/scaling thing. Maybe I didn't make that clear.

 

There's no problem with ellipses, I worded the post ambiguously.

"Except the part below, about tilemaps"

 

Oh I see, my bad. I'll play around with this idea. See what works, what doesn't. Thanks for the help.