Jumping control in games like castle crashers and little fighter

You see, ahlex, all you need to do is implement a quaternion-tree system. This left-first translation system provides a functional solution that doesn't result in that nasty static quad-tree gimbal lock other systems are known for. Don't forget to use reinterpret_cast on your vectors too, that speeds up movement in multiple directions.

@Funkapotamus: ??! Is this an inside joke or are you just testing how people respond to bullshitting with random technical terms thrown in? ;)

I never heard of castle crashers or little fighter. Are these top-down view games played similar to a jump 'n run?

If it's top-down, you're already halfway into 3D. Your character moves on the X/Z plane (typically) and jumps would affect the Y axis (whereas in 2D, your character only moves on the X line with jumps affecting the Y axis)

Please provide some more informations!

the game which i am currently working on is a 2d side scroller fighting game. For your info, it is something similar to this: http://www.littlefighter.com/lf2_pic/5.gif. The challenge is that I have only done side scroller games similar to mario but not this, so I am having some difficulty with the jumping part.

Even though the view in Castle Crashers is isometric, I'm guessing the underlying data is still in 2D (with some height information for stairs and the like). That makes all the logical calculations rather simple, and you can still render a traditional isometric side-scroller view by adjusting the screen position depending on where objects are in the map. For instance, moving in the Y direction on the map might correspond to moving up and down on the screen, however the larger your Y location in the map, the less you move on the screen to simulate perspective. You might also apply a scaling factor. Moving in the Z direction on the map (off the ground) would have the same effect on the screen position, although perhaps you wouldn't do any scaling.

I don't know how they actually do it and I've never implemented such a side-scrolling view before, so that's just my two cents :)

Whats the problem. Just treat it as 3d data confined to an area.

Castle Crashers is a side-scrolling beat'em'up, like GoldenAxe, River City Ransom, Double Dragon, et al.

ahlex; this means you are essentially working with 3D, not 2D. There is an X coordinate which maps naturally to the X screen coordinate, a Y coordinate which maps to near/far on the combat "stage", and a Z coordinate which maps to vertical distance off the "floor" of the combat "stage". Thus; movement is done in the XY plane as normal, and when you jump your Z coordinate will vary with altitude.

When drawing, of course, you can use pure-2D graphics because Y and Z are parallel once projected into screen space.

Quote:

Original post by Wyrframe Castle Crashers is a side-scrolling beat'em'up, like GoldenAxe, River City Ransom, Double Dragon, et al. ahlex; this means you are essentially working with 3D, not 2D. There is an X coordinate which maps naturally to the X screen coordinate, a Y coordinate which maps to near/far on the combat "stage", and a Z coordinate which maps to vertical distance off the "floor" of the combat "stage". Thus; movement is done in the XY plane as normal, and when you jump your Z coordinate will vary with altitude. When drawing, of course, you can use pure-2D graphics because Y and Z are parallel once projected into screen space.

There is no Z axis in games like Golden Axe and Castle Crashers. The Y axis serves as a measure of depth into the screen, and as height from a given depth.

Collision is considered vs. objects within a certain threshold of your Y translation.

Jumping is a temporary offset on the Y axis and does not effect your character's Y translation in regards to collision.

Thus, the further your depth, the higher your Y translation. Likewise, the higher you jump, the higher your Y translation.

Funkapotamus; what about "a temporary offset on the Y axis that does not affect the Y-position in collision" disqualifies it as being the Z axis? All that means is that you don't want to call that vertical-offset variable a "Z" variable.

Or another way; I say potáto, you say potàto.

To merge Funkapotamus and Wyrframe:

There is no literal Z axis, it's rendered as the Y because no Z really exists. In a view like this the Z axis is just an illusion. You can make a variable, called Z, but it is just an offset that gets added to the Y upon rendering (or you can just directly modify the Y).

Quote:

Original post by TriggerB (or you can just directly modify the Y).

Wouldn't that like totally screw up you jump mechanism?

I don't see why it would, you just have to make sure to store the original Y value temporarily so that at the end of the jump you return to it.

2 Ways:

1. Hold the old value of the Y so that it can be returned to at the end of the jump

or

2. Hold a Z value which is typically 0 and is modified whenever you want to jump (add it to the Y)

Both very similar, I think the second approach is more straightforward.