Sidescroller Game Physics

[Quantum]

Hey everybody! I'm new but I've been programming for about a year now (mostly in java), anyway I've been working on this sidescroller for a while now but technically it is still in its base stage. I hit a roadblock when it came to jumping vectors. I hope yo guys can help me out here. My main problem is getting to create a timer at the start of the jump and getting updates to fit the equation for 2d vector motion 
Motion:
 * ∆X=Voy*∆t
 * ∆Y=Voy*∆t-1/2 g(∆t*∆t)
 * Vox=Vo*cos theta
 * Voy=Vo*sin theta
 * Vx=Vox
 * Vy=Voy-y*∆t

[Karmington]

Most side scrollers cheat and just make something that looks like physics.
But if you really want to do it 'realistic', then...

1) don't make a separate timer for the jumper.
the game should have one timer, and everybody can just use that time, marking their start-jump-time
2) give the jumper some variables, position and movement vector.
3) boost the up vector on jumping, apply gravity to bring him down.
4) write some code, if it don't work then come back and let's look at it.

[Quantum]

So if I was to "fake it" how would I do so?

Games published by our own members! Check 'em out!

[Karmington]

one might dispute that faking it can be as difficult as making it 'for real', but here we go.
How to do it depends on your constraints.

a) Level playing field or not ? i.e. are there platforms on different levels, or just one long flat like Moon Patrol?
b) Fixed FrameRate or not ? this decides whether you can force the position without using a Timer.

Examples: (numbers are just off the top of my head )

take Moon Patrol example, long flat ground, fixed frame rate:
one can just say, buggy will be at +3, +8, +10, +8, +3 heights along the jump.
1) decide the time a jump will take in frames, say 24 frames
2) make the array have values for each frame until the jump is complete.
3) modify the height the sprite is drawn at according to how many frames have passed since starting the jump.

take mario example, platforms with no fixed frame rate.
one can say, jump upwards power is + 10 pixels.
mark the starting time, and on every update modify the upvector by a gravity value, say -10 pixels per second.
cap the value to -30 pixels or something so you dont max out the falling speed over your tilesize.
again, with feeling:
1) start the jump
2) update, add the jump power to the sprite, then subtract the (gravity * time) from the jump power.
3) update, repeat. ( and let user continue to move left or right as normal )
4) dont forget to check for landing.
This is not really very far from 'real' jumping...

I might even venture to say for many games faked jumping is better than the 'real gravity' simulation...
Even a lot of modern FPS have jumping that feels like you are popping and floating, quite clumsy.
Maybe watch Osamu Tezuka's animation 'Jumping' for more inspiration

[EDIT] lol totally forgot that main point there...

[DzzD]

My main problem is getting to create a timer at the start of the jump and getting updates to fit the equation for 2d vector motion 

hum.. main problem ?

why not :

1   2   3   4   5   6   7   8   9   10   11   12

boolean jumping: long startTime; if(!jumping) {  if(keyJump )   startTime=System.currentTimeMillis(); } else {    long jumpTime=System.currentTimeMillis()-startTime;   //update player jump }

[DzzD]

I dont think you equation are corrects , it should be something like that :

px0 (player pos at starting jump pos)
py0 (player pos at starting jump pos)
vx0 (player x velocity when starting jump / impulsion strenght)
vy0 (player y velocity when starting jump / impulsion strenght)
gy (earth gravity / y acceleration)
gx (something like air resistance wind / x acceleration)

with t=jumpTime*0.001 (to work with seconds);

playerX=px0+vx0*t+0.5*gx*t²
playerY=py0+vy0*t+0.5*gy*t²

gy=-9.80665 m / s² (for earth gravity)
gx=0;
and for exemple a 45° jump
vx0=14 ( K*cos(theta)) K=20
vy0=14 ( K*sin(theta)) K=20


should give something like (if playerPos X & Y are in pixels it should jump arround 20 pixels up after 1.5s):

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30

boolean jumping: long startTime; double px0; double py0; double gy=-9.8; double gx=0; if(!jumping) {  if(keyJump )  {   jumping=true;   startTime=System.currentTimeMillis();   px0=playerX;   py0=playerY;   vx0=14;   vy0=14;  } } else {    long jumpTime=System.currentTimeMillis()-startTime;    double t=jumpTime*0.001;    double t2=t*t;    playerX=px0+vx0*t+0.5*gx*t2;    playerY=py0+vy0*t+0.5*gy*t2;       //If ground hitted   jumping=false }

[Quantum]

Thanks for all the help guys. Something that will make this all a little harder (something I have'nt mentioned) is tha depending on how much momentum the player has gained through running for a period of time the force put into the jump will differ. Longer periods of time spent running will give the player more momentum.

[Quantum]

Anyway those equations I got out of my dad's physics book.

[DzzD]

Anyway those equations I got out of my dad's physics book.

so your dad's book got at least one problem
∆X=Voy*∆t

[DzzD]

Thanks for all the help guys. Something that will make this all a little harder (something I have'nt mentioned) is tha depending on how much momentum the player has gained through running for a period of time the force put into the jump will differ. Longer periods of time spent running will give the player more momentum.

but V0x & V0y will do the job ? rather than set it to a value (for the jump) add it to the current player velocity

Games published by our own members! Check 'em out!

[lithos]

You're making it a bit harder than it has to be.

when using acceleration/gravity  you just adding how for you should have gone in a set amount of time.   assuming you have a fixed frame rate,  if you have an unfixed time rate you an see some weird variation depending on other factors.

example below using Screen notation for graphing(top left starts at 0,0 then increases towards the right/bottom). is measured in pixels.    And is in the game loop to some extent or another.

Also takes advantage that on average you're calculating changes that are very small.

_______________



if not down collision
  CurrentYVector -= GRAVITY_FACTOR(5 * frame rate)
else if currentYvector < 0
  CurrentYVector = 0
end if

If shouldJump
  CurrentYVector = -50
end if

CurrentXVector += X_ACCELERATION(0 * frame rate)

if allowRight AND currentXVector > 0
   CurrectXLocation += XVector  (maybe times frame time)
else if allowLeft AND currentXVector < 0
   CurrentXLocation += XVector   (maybe times frame time)
else
   CurrentXLocation -= XVector     (maybe times frame time)
   XVector = 0
end if

CurrentYLocation += CurrentYVector

___________

Depending on everything you're going to have to change this since there are bunches of edge cases shoved in there that aren't covered.

Basically the reason why you're multiplying or squaring things in physics is to account for time and the fact that you're not doing everything Fraction of a second by fraction of a second like in programming.

[DzzD]

You're making it a bit harder than it has to be.

I really HATE to do such (and hate people who does it too....) but it use already tones of approximation !

I would say that you are making it a lot too simple :p  it all depend on what you want to do :  in your sample there is no notion of gravity acceleration and the player/entity will just move down at a constant speed and this may look weird depending on the kind of game you build : a simple game that would requiere acceleration + wind would be a tank battle game ( or a game like Worms ).

[lithos]

I agree that I'm making it too simple.  There are even some major flaws in that pseudo code depending on what else you're dealing with.

But my goal was to make the OP realize that a lot of the equations in physics are like that because you're not able to calculate stuff "fraction of a second" by "fraction of a second".   Which means you're going to have to figure out other things to use the equations.

___

Though after quite a bit of tweaking I've gotten those physics to work nicely.   However I want to do a recode because it's a "true mess" since it was the first time I messed with real physics in a little over 2 years.

Not using anything like an array to fake jumping physics or similar.   And it's pretty darn consistent considering some of the "other" mistakes I made in the design(at least on my computer).    I will say though that it's pretty darn hard to get the right numbers down(gravity, jump strength, acceleration) the third time around(this recode) will be the charm since I'm much more aware of the WTF-i-ness.