Pseudo-3d - pits and platforms

Hi,

I've been working on a learning project for a little while now, a pseudo-3d brawler in the style of Final Fight or Golden Axe.
Essentially, all art assets (characters as well as the levels) are 2d, but characters can move in depth.

Level limits as well as Z sorting have been implemented without any big problems, as well as depth-savvy hit detection for attacks (essentially, the hit and collision boxes are near the feet/shadow of the characters rather than the full height of the sprite for most things).

However, this system runs into some trouble when the level isn't a flat plane so far (and really, what kind of Golden Axe type game is it if you can't knock/throw enemies into pits?) - I figure a pit wouldn't be too hard to sort out (a special collider for a pit, and if the character hits it while grounded, they'll just fall until they hit a death zone at the bottom of the screen), but are there smarter ways to implement that?

I'm having bigger trouble implementing elevated areas of the level - any suggestions for a good way to go about implementing a ledge you can jump onto and walk/fall/jump off of? For simplicity, I imagine not being able to move in the depth axis (up/down on the controls/screen) while jumping, only left/right, since I imagine that would simplify things - but there seem to be other pitfalls there too. For example, I'll use a piece of Golden Axe background art for demonstration purposes:

Red Circle jumping to the right would be able to get onto the platform, while red circle walking to the right would just bump into the wall.
However, Green Circle walking to the right would walk in front of the ledge, but Green Circle could also do a high jump, which would move it visually above the ledge (if it wasn't for its shadow) - so I need to make sure that Green Circle in such a situation would still land in front of the ledge rather than on top of it.

I hope that helps visualise some of the design issues I have with this solution - any tips? I imagine it can't be extremely complicated considering home consoles from the early 90s were able to handle it pretty well, so perhaps I'm just making it harder than it needs to be...

 

By far the simplest thing would be to just have the level be 3D.



The art can be 2D, but use 3D colliders for everything.

--Eric

 

I did some experiments with that earlier, but I'm guessing I must be attacking it from the wrong angle as to me, that just causes a lot more problems than it solves.

Basically, since the camera is still orthogonal (to get the 2d visuals), I had to "cheat" the pseudo-3d isometry by shifting the visual sprite off the 3d collider in the Y axis depending on its Z position (making the sprite a child of the object, and giving it a "fake3d" script that sets its local Y position to its parent's Z position) , and then everything just becomes a major nightmare when trying to line things up to match between the 3d "environment" with the 2d art, and even more so with levels that have Z-axis scrolling (and not just pure side scrolling), enemy placement, and the like.

Am I attacking the problem in completely the wrong way by doing this?

 

Trying to "cheat" things is probably making it much harder. You can have everything be in 3D space and work as usual with no cheating, but just replace models with sprites.

--Eric

 

Well, perhaps I'm misunderstanding something here. But if my backgrounds are all 2d, and my characters are all 2d, then won't I have to cheat it somehow to make it work?
Considering I cannot simultaneously view the same things head-on and from an isometric angle...?

Take the picture example in my original post - if I have drawn a flat background much like the one from Golden Axe there, then that's flat. Shifting the camera angle to the point that movement on the Z axis is visible at all will mean that it looks like a flat billboard at an angle. The same for any character/enemy sprites and so on.

(I apologise if these are stupid questions, but while I've found a lot of great resources on 2d and 3d stuff separately, I haven't found any tutorials or info on 2d sprites in a 3d or pseudo-3d space, which is what this effectively boils down to)

 

Update: Think I found a way after all to do it with 3d and still get a good 2d aesthetic to it. Thanks a lot for nudging me in the right direction. =)

 

Just gotta jump in and say it, Golden Axe is my favorite side scrolling platform brawler... I hope you played the arcade version! Btw, I'm also developing a game that will need a similar mechanic, tho I am avoiding 3D at all cost (2D just works far better for my game engine, as it's a Legend of Zelda style 2.5D world, and all the other parts seem to be clicking nicely). If I come up with anything 2D specific as far as platforms and pits go, I'll def show you my progress. As for now, I'm not quite ready to attack that move mechanic yet. Anyway, good luck and happy coding!!!

 

The one that I have the most memories from is the Megadrive (Genesis) version, but I've played the Arcade and C64 versions and even the old PC version with its atrocious option for playing with the mouse. =)

Looking forward to seeing what you come up with - I'm still hoping to avoid 3d but I'm testing it for now in a separate branch as a learning experience.

 

any update on this? I was hoping to do a beatemup with slight platforming to it

 

I haven't found a good way to do it in 2d, unfortunately. It shouldn't be undoable, as it's done not just with brawlers but also with some platformy games like the Mario & Luigi platform RPGs on the GBA.

 

Just do what eric said, use 3D and overlay 2D...

What i did to make pseudo 3D work is using a tilted camera, but stretching the Spriterenderers by certain factors. This helps when editing the levels in the editor, if you would do it as single overlay-plane you could run into perceptional problems while editing. Here is a pic of the game view:


and the editor view


And here is a project file post, Open the "tilted-Camera-Scene" or whatever i called it, there you can see the effect of pseudo-3D while still having pixelperfect rendering (however, the tiles i used are very bad to convey pseudo 3D, but the build was made to show pixelperfection)
http://forum.unity3d.com/threads/pixel-perfect-2d-in-4-3.210497/page-2#post-2197369

 

Thanks for the update and the link, Marrt.

I have to admit, at this point my wanting to figure out how its done "in 2d" is more academic than anything, considering that many older games have done it successfully with far more limited hardware.

 

Yeah, but if you want to cast a fireball in an arc over an obstacle and correctly detect if you would hit a wall or a flying enemy on its way, it is much easier and more realistic to just use 3D-Physics below the surface of your 2D Overlay.

Otherwise you would have to create some kind of self-made height checking routines. The "height", in the 2D environment you proposed in the intro-post, is visually just an y-offset on the screen. and if you jump on the ledge in your picture, all that is happening visually is that the guy is higher in Screen-Coordinates while his pseudo-3D-coordinates are more complicated.

Additionally 2D-implementation is hard if you have AOE attacks. You then need to use your pseudo-3D Coordinates to determine if an object is within the AOE-radius. If you just test in Screen-Coordinates it could happen that the object is right next to the AOE sphere but happens to stand on a platform which -in the 3D sense- is way out of range.

All this complications and bug sources - avoided through the use of 3D-Environment + orthogonal camera.

But i am unsure on how to go about your parallelogram shapes, tilt the camera in two angles? that would impact the pixelperfection except if you tilt all sprites in 2 axes which complicates everything so much that it would destroy the purpose, so it may be even easier to really just use an overlay plane, without stretching Sprites to just get a better 3D-feel for editing.

Anyway, empty talk...

I don't know but i suspect you would really use a pseudo-3D coordinate System with a transformation function for the screenposition, especially if you have things like jump attacks or jump avoidance.
e.g. in your case
-ScreenY = pseudo.y+pseudo.z*0.321
-ScreenX = pseudo.x

Hitboxes for punches would then be just simple XYZ-Box-overlapping tests and things will be easy