Jump to content
  • Advertisement
Sign in to follow this  
ahlex

Jumping control in games like castle crashers and little fighter

This topic is 3545 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, how do i implement the jumping function in games like castle crashers and little fighter? in normal side scroller games like mario, i would have no difficulty as it has only 2 direction, left and right. In castle crashers and little fighter, there are 8 directions, so I am a little lost here. Any advice would be appreciated.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
@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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!