Sign in to follow this  

Unity 2D Jumping

This topic is 2541 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

Currently I am working on a 2d fighting game and the jumping system I have currently creates a funky looking jump that I don't like. Here's a graph of what the jump looks like in 2d space in relation to the sprites X,Y Position while jumping.

sprite jump



I looked through a few of the topics here and tried to incorporate their methods, namely the one from this topic http://www.gamedev.net/community/forums/topic.asp?topic_id=559493 but it keeps my sprite at the top of the screen without it coming back down for some reason.

Here is the current code I am using


private void Jump()
{

if (canJump)
{
if (isJumping && !moving)
{
//velocity.Y = (float)gameTime.ElapsedGameTime.Milliseconds * acceleration.Y * (float)0.5;

isOnGround = false;
position.Y = position.Y - jumpSpeed;
position.X = position.X + velocity.X;

if (position.Y <= (groundLevel - jumpHeight))
{
moving = true;
}
}

if (moving)
{
position.Y = position.Y + (jumpSpeed/2);//velocity.Y;
position.X = position.X + velocity.X;
//currentState = CharState.JUMP;
}

if (position.Y > groundLevel && !isOnGround)
{

//velocity.Y = 0;
velocity.X = 0;
isJumping = false;
position.Y = groundLevel;
isOnGround = true;
moving = false;

canJump = false;
currentState = CharState.IDLE;
currentFrame.X = 0;
}
}

else
{

if (currentFrame.X > 2)
{
canJump = true;
}
}
}



Any help would be awesome thanks!

Share this post


Link to post
Share on other sites
You should change your approach...

Your players should receive a constant gravity (an acceleration that increases their velocity downwards unless it's touching the ground) each frame, and the action of jumping should apply an upwards velocity to the player.

That way, upon pressing jump, the player's y velocity shoots up, and the gravity makes that upwards movement decay until the player starts freefalling back down to the ground.

Share this post


Link to post
Share on other sites
So I'm still having trouble, the sprite will either not get off the ground or it will go shooting straight up into the air and not come back down.

Here's the two equations I'm using.

float gravity = -0.9;
Vector2 acceleration = new Vector2(0, 5);

velocity.Y += (float)gameTime.ElapsedGameTime.Milliseconds * gravity;


or I use

velocity.Y = (float)gameTime.ElapsedGameTime.Milliseconds * acceleration.Y + gravity;


position.Y = position.Y - velocity.Y;
position.X = position.X + velocity.X;



then in my Sprites class in it's update loop I have it do this

//pseudo
update(GameTime gameTime)
{
if(upButton.GetState() == ButtonState.IsPressed)
{
velocity.Y +=10;
}
}



I dont know exactly what I am doing wrong

Share this post


Link to post
Share on other sites
You have several problems. You're mixing accelerations, velocities and positions.
Quote:
velocity.Y += (float)gameTime.ElapsedGameTime.Milliseconds * gravity;

or I use

velocity.Y = (float)gameTime.ElapsedGameTime.Milliseconds * acceleration.Y + gravity;

position.Y = position.Y - velocity.Y;
position.X = position.X + velocity.X;

What do you use?

If you want to use the second velocity equation, you need to apply the delta-time to gravity also. And the result is a change in velocity so you need to add that to the original velocity. I.e.,

velocity.Y += (float)gameTime.ElapsedGameTime.Milliseconds * (acceleration.Y + gravity); // not the parentheses.

Also, you need to apply the delta-time to the velocity in your position equations:

position.Y = position.Y - velocity.Y * delta-time; // EDIT Question: why do you subtract?
position.X = position.X + velocity.X * delta-time;

[Edited by - Buckeye on December 29, 2010 9:51:55 PM]

Share this post


Link to post
Share on other sites

float gravity = -0.9; // You may have to adjust this value depending on what
// units you are using. Play around with it.
// Vector2 acceleration = new Vector2(0, 5); // get rid of this

// You should determine how much time has elapsed first and save it, to
// keep the code concise. In fact, you should pass this value as a parameter
// to the function where you do physics updates.
float elapsedTime = gameTime.ElapsedGameTime.Milliseconds;

velocity.Y += elapsedTime * gravity; // use this one


// DO NOT use velocity.Y = elapsedTime * acceleration.Y + gravity;
// That means that the guy is wearing a rocket pack, and furthermore that
// gravity has no concept of time elapsed.

// position.Y = position.Y - velocity.Y; // This is the problem: you must also
// account for time elapsed when you update the position with velocity.
// Also, velocity is a signed quantity, so you should always be adding it,
// not subtracting it. Establish a consistent sign convention. E.g. if you want
// the positive Y axis to be up (as in math), then gravity is negative,
// and if you want the positive Y axis to be down (as in screen coordinates),
// then gravity is positive. But either way, you always ADD acceleration to
// velocity, and always ADD velocity to position.
position.Y += elapsedTime * velocity.Y;
// Same thing in the X direction.
position.X = position.X + velocity.X;


//pseudo
update()
// The function that handles key presses should probably not
// care about elapsed time.
{
if(upButton.GetState() == ButtonState.IsPressed
&& onGround() // important! Only set the Y-velocity once.
// You should also check that the button has been released since the
// last time the player landed - you don't want him to bounce up and down
// repeatedly if he holds the button for a long time.
{
velocity.Y = 10; // set, don't add.
}
}

Share this post


Link to post
Share on other sites
Ok I have it working now with a beautiful curve! Thank you everyone who helped me out!

Here's the end code I have


float gravity = -0.09f;
private void Jump(GameTime gameTime)
{
float elapsedTime = (float)gameTime.ElapsedGameTime.Milliseconds * speed;

if (canJump)
{
if (isJumping && !moving)
{
isOnGround = false;

velocity.Y += elapsedTime * gravity;
position.Y -= elapsedTime * velocity.Y; // I found that if I had
//this negative and the gravity negative it worked but didn't work with the recommended way
// for screen coordinates. I don't understand why it didn't work like that but hey it works.
position.X += velocity.X;
}
}
}




Thank you again everyone! feel free to use this code :D

Share this post


Link to post
Share on other sites
This just doesn't make sense:
position.Y -= elapsedTime * velocity.Y;

I assume you do that since PC 0,0 is upper left. You should negate gravity, ie, make gravity a positive number, which means, for PC graphics, it will push down the screen. That's technically the right way to do it IMO.

Share this post


Link to post
Share on other sites
Quote:
Original post by BeerNutts
That's technically the right way to do it IMO.
There's really not any 'right way' to set up a 2-d coordinate system; it really just depends on what API(s) you're using and what your personal preferences are.

I'm not sure what API the OP is using (XNA, perhaps?), but with many APIs you can make +y point either up or down - whichever you prefer. (Personally I find +y up to be more intuitive, but YMMV.)

Share this post


Link to post
Share on other sites
Well I had it like this at first

float gravity = 0.09f;

velocity.Y += elapsedTime * gravity;
position.Y += elapsedTime * velocity.Y;

but for some reason the sprite would just stick to the ground and not do anything.

Share this post


Link to post
Share on other sites
Quote:
Original post by Subliminalman
Well I had it like this at first

float gravity = 0.09f;

velocity.Y += elapsedTime * gravity;
position.Y += elapsedTime * velocity.Y;

but for some reason the sprite would just stick to the ground and not do anything.

Well for the PC, the origin (0,0) is at the upper-left corner of the screen. Also, Y in the positive direction is down, not up. For X, it's right (as opposed to left). So with that in mind, if gravity is .09 * X millisecond, then your character is always moving toward the bottom of the screen. Also if you're again multply by X milliseconds, then your character Y movement is being increased again toward the bottom of the screen. That's why your character never could go up.

I'm not an expert, so if I'm wrong, someone here will definitely correct me.

Share this post


Link to post
Share on other sites
Quote:
Original post by Alpha_ProgDes
Well for the PC, the origin (0,0) is at the upper-left corner of the screen.
This is incorrect (as stated, at least). There are many different graphics APIs that target PCs (by which I assume you mean Windows machines), and among those APIs, a variety of coordinate systems is represented. There's nothing that says that 'on a PC' +y has to be down and the origin has to be in the upper-left corner.

That said, that may indeed be the coordinate system that the OP is working with. (It does appear that the default 2-d coordinate system is as you described for XNA. I was under the impression you could modify that, but I can't find anything online right now that indicates that's the case.)

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
Quote:
Original post by Alpha_ProgDes
Well for the PC, the origin (0,0) is at the upper-left corner of the screen.
This is incorrect (as stated, at least). There are many different graphics APIs that target PCs (by which I assume you mean Windows machines), and among those APIs, a variety of coordinate systems is represented. There's nothing that says that 'on a PC' +y has to be down and the origin has to be in the upper-left corner.

That said, that may indeed be the coordinate system that the OP is working with. (It does appear that the default 2-d coordinate system is as you described for XNA. I was under the impression you could modify that, but I can't find anything online right now that indicates that's the case.)


FFS, let me re-phrase then: Replace "PC," with "On Your programming platform, it seems"

Feel smarter now?

Share this post


Link to post
Share on other sites
Quote:
...but for some reason the sprite would just stick to the ground and not do anything.

Hard to tell. You might have some mixup with those flags (canJump, isJumping, moving). Anyway: Can you show the entire code, please ?

Share this post


Link to post
Share on other sites
Quote:
Original post by BeerNutts
FFS, let me re-phrase then: Replace "PC," with "On Your programming platform, it seems"

Feel smarter now?
Sorry if my post upset you, but lots of beginning game developers read these forums, and unclear statements like the one in question can easily lead to confusion, IMO.

There's a variety of topics in game development (including matrix storage order, vector orientation, coordinate system handedness and orientation, gimbal lock, etc.) that often cause confusion. Take matrix 'majorness' for example. It's *very* common to confuse matrix majorness with vector orientation. Over and over again on the forums you'll see people say, 'The translation is in the bottom row because the matrix is row major'.

I always correct these statements when I come across them. Am I doing it to feel 'smart'? Not so much. When I first started learning about 3-d math, I thought that 'row major' meant 'the basis vectors are in the rows'. Why did I think that? Probably because I read some incorrect (and uncorrected) post online somewhere that stated that.

Eventually I used the term 'row major' incorrectly in a post and I was corrected. I didn't like it - in fact, I felt much the same way about the correction that you seem to feel about my post - but nevertheless, that was the moment when I finally understood the difference between 'row major' and 'row vectors'.

Coordinate systems are another common source of confusion; there's a lot of confusion about left- vs. right-handed, what axis orientation is 'standard', etc.

The statement 'on PC, +y is down and the origin is in the upper-left' is incorrect as stated. You and I may know what he meant, but someone who's just getting started with graphics could read that and take it at face value, then later get confused when someone points out that with many APIs (e.g. Direct3D or OpenGL) you can use just about any coordinate system you want.

Obviously in the grand scheme of things, none of this is particularly important. But, in the context of these boards, it's worth getting these details right, IMO.

Again, I'm sorry if my post upset you, but I stand by it. (And in turn, if I happen to make an unclear or inaccurate statement, I hope that will be corrected as well.)

Share this post


Link to post
Share on other sites

This topic is 2541 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Forum Statistics

    • Total Topics
      628714
    • Total Posts
      2984357
  • Similar Content

    • By AndySv
        Total Music Collection (http://u3d.as/Pxo)   THE COLLECTION CONTAINS:   Mega Game Music Collection   Universal Music Collection   Huge library of high quality music for any project! All at an incredibly low price!   - 2,5GB of high quality audio - 100+ different music tracks - Loop and short versions   Action, fantasy, casual, horror, puzzle, epic, dramatic, romantic, positive, inspiring, motivational and more!
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064

      View full story
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064
    • By Dafu
      Hello all,
      I've been hard at work on a new retro pixel-perfect framework called FES Retro Game Framework. It is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      My own game I started working on using FES, a roguelike, very early: https://simmer.io/@Dafu/merl
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064
       
       
    • By Apollo Cabrera
      Yasss!!! My first Unity3d game is on the App Store and Google Play.
      Download please! About 30 minutes to get through 5 missions.
      Let me know what you guys think.
      Thanks a bunch
       
  • Popular Now