1
\$\begingroup\$

The game is a 2D brawler with depth movement in the vein of Golden Axe, Final Fight, Castle Crashers etc. Characters and environment are all 2d sprites as well. I've had no real issue setting up collision between characters to take the depth into account either.

However, it's just not a proper brawler without higher ground to jump to and pits to throw the enemy into, and that is where I run into a bit of an issue with how best to implement it.

I considered making the collision boxes for the level in the 3D space and having the sprites just translate the z movement of their game object into y movement of the visual component, but I don't particularly like that approach because it feels difficult to work with for doing the level design of matching 3D colliders to a drawn backdrop and placing objects in there.

Any suggestions for a design that is the 2D first, so to speak? Ideally being able to "paint" height levels and pits in the 2D design wise. If it matters, I'm working in unity with a primarily 2d space (though involving the third dimension here will be necessary), but I think the base design problem would be fairly engine/language agnostic.

\$\endgroup\$
5
  • \$\begingroup\$ How are you implementing the depth effect? Are the characters just allowed to walk some distance up on the y axis? \$\endgroup\$
    – lase
    Dec 5, 2014 at 14:20
  • \$\begingroup\$ Ah sorry, should have specified that. I have a box collider at each character's feet, and use edge colliders and other colliders to deal with the level boundaries (since walls and such blocks movement). \$\endgroup\$ Dec 5, 2014 at 14:33
  • \$\begingroup\$ So that's for the left & right side of the screen right? I was more asking about moving forward and backward in perspective, like in the games you mentioned. \$\endgroup\$
    – lase
    Dec 5, 2014 at 14:40
  • \$\begingroup\$ I use it for the y axis too, to accommodate for levels that scroll vertically. The depth is then handled by layer sorting by y coordinates of the bottom of the object, and the collision between objects is also dealt with by using narrow hit boxes. Does that make sense? \$\endgroup\$ Dec 5, 2014 at 14:48
  • \$\begingroup\$ I also did some experiments with actually moving the character in x/z and translating the rendered sprite in the local y coordinate to match the object z, but that became a pain for mapping out level collision and placing objects in the world. \$\endgroup\$ Dec 5, 2014 at 15:07

1 Answer 1

2
\$\begingroup\$

I think you might be able to achieve this in a 2D space by using multiple box colliders - or just just a range of x & y values, really. I spent a few hours in GIMP editing this up: I love Turtles In Time

Depicted is an open manhole that the turtles can fall in. Just a singular box collider would work for pits, but I used the screen wide colliders for illustration.

For elevated platforms, you could do something like this: BIG APPLE, 3AM

If you the player was colliding with the lower platform, it would make the player eligible for standing on the upper platform (in some way of your choosing). In this picture, the upper platform is well above the typical walkable area of the stage, but using this technique, you could easily have platforms you could walk behind, around, and under, by using a combination of colliders - this way elevated platforms could overlap with the ground you could already walk on. I think it'd boil down to something like this:

public class ElevationChecker : MonoBehaviour {
public PlayerClass player;
public Collider upperPlatform;
....
// Where this trigger is the ground collider
public void OnTriggerExit(Collider playerFeet) {
    if (player.isJumping) {
        upperPlatform.enabled = true;
    }
}
....
// You could later disable the upper collider once the player walks off it
// so they could walk around, under, etc
}

There may be things you need to work out here yourself, but I think this general approach would allow you to keep a strictly 2D style and not bother with 3D.

\$\endgroup\$
1
  • \$\begingroup\$ You'd also have to check if the jump started from within the trigger, but that is trivial. \$\endgroup\$
    – lase
    Dec 5, 2014 at 16:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .