next »

[Glaiel-Gamer]

the only question now: which one is faster to calculate?

quadratic most definitely, but who cares? It's gonna end up being 2 multiplications and an addition or whatever, which a computer could do billions of times per second.

Of course if you had 40 billion sprites you'd have a problem and might rather use a lookup table.

[BorisTheBrave]

A variation on Salt's code:

Code:

def hop(startX,startY,endX,endY,gravity, duration, time):
  #Progress from 0 to 1 through animation
  progress = time/duration
  x = startX + (endX-startX)*progress
  y = startY + (endY-startY)*progress
  z = time * (duration - time) / 2 * gravity
  return (x,y+z)

Aside from terseness, this has the advantage of being independant of framerate, and non-incremental, so the frog always ends up at the correct position.

I find it interesting that so many people advise a sin wave. This probably divides those experienced in making games (because sin waves are quite convincing for the part, and easy to use in a wide variety of circumstances), with those who are trained more generally (because quadratic equations are physically correct, but require manual labour). Both are fine, really.

Now, because Paul Eres asked for it, a mini lesson on setting up a quadratic:
What people mean by this is finding the co-efficients of a quadratic equation describing the motion of the object. I.e. finding a,b and c in:
x = a * t *t + b * t + c
Note this equation maps from t, time, to x. We'd need a second equation to describe the y motion (and a third for z, etc). This is called a parametric equation, and they are very powerful for describing paths. They form the basis for splines such as Beziers, of which the lowly quadratic is a simplified form of.
In practise, you don't always use the above form, but the principle is similar so I'll press on. Because the maths is easier, I'll do it in 3d, as salt says, and they transform from 3d co-ordinates to 2d at the end. Another simplification (sometimes) is to transform time to go from 0 to 1.
So, in 3d, we have acceleration only in the z axis. That means that x and y are linear:
x = b*t +c
x starts at startX, ends at endX, so so plugging in t=1 and 0 gives equations solving to c = startX, b=endX-startX. Similarly y.
I'll do z without the transformation of time:
Our know equations:
at t=0 z=0
at t=duration z=0
at any given time d^2/dt^2 z (the second derivative of z) is equal to gravity.
Plugging in to the above equation
c = 0
a*duration^2+b*duration+c=0
2*a = gravity
which solves very simply.

Satis?

[AaronAardvark]

I'm sorry Boris, but I find your description very confusing and I've taken third level calculus.
Is it possible to use proper mathematical markup in here?  Or maybe you could write it down in pencil and scan it in?

I always find a step by step example (with substitutions) written in math to be the easiest to follow.

[ஒழுக்கின்மை (Paul Eres)]

likewise i find that explanation confusing, but will go through it a few more times and see if it makes more sense after that.

[BorisTheBrave]

Ok, sorry, I was trying avoid any actual mathematics, and just show the process. So yes, I'm sure the maths is highly confusing. I'm afraid on this board I cannot see how to do mathematical notation, but I'll try harder to make things clear. I'll try the lesson again, but I cannot honestly say I'm very good at this. This time I'll go heavy on the maths, to the point you find me patronizing. There's a balance somewhere, but damned if I can find it.

There's actually several things to appreciate here. The first is that a common way of describing paths is by parametric equations, i.e. a function that maps from t, time, to position. Or equivalently a function that maps to x position and a second function for y, and a third for z.

The second thing to realize is that a popular choice of function is quadratic equations, or more generally polynomials. Other choices would be cubic equations, or sin waves, or more complicated things, but as we'll see quadratics are physically justified.

Finally, having decided on the family of functions (the quadratic polynomials), we need to pick the exact one we want based on the results we want. I'll go over this last part again.

We can characterize any quadratic with 3 co-efficients, which I will call a,b,c.
In maths, we'd write:

Code:

z(t) = a*t*t + b*t + c

Or we could use code (I hope you like function closures):

Code:

def makeQuadratic(a,b,c):
  def myPoly(t):
    return a*t*t + b*t + c
  return myPoly

which we could use like so.

Code:

quadratic1 = makeQuadratic(0,0,1)
print quadratic1(0) # 1
print quadratic1(5) # 1
quadratic2 = makeQuadratic(1,0,0)
print quadratic2(0) # 0
print quadratic2(5) # 25

quadratic1 represents the function x(t) = 1, i.e. a constant, while quadratic2 would be the function x(t) = t*t. Note I still call quadratic1 a quadratic, even though it involves no powers of t at all. It's just degenerate, but that doesn't stop it being a quadratic.

Ok, that's cool, we can form a function from knowing a,b,c, but what we really want to do is go backwards, based on things we know about the function. So we form equations, and solve them simultaneously.

We know 3 things about our function, which we are going to call f.

• f(0) = startZ
• f(1) = endZ
• The second derivative, written f''(t) is a constant function, of value gravity.

The first two are requirements that we start and end where we want, at the times we want. The third is less obvious, but it derives from physics. The second derivative of position is more commonly called acceleration, and we all know earth gravity causes constant acceleration near the surface, right? In fact, knowing that the second derivative is constant requires f to be a quadratic. We didn't need pre-suppose it. But I'm not going to get into that.

So now we expand out those 3 known things into statements about a,b,c. The first two are simple substitution:
a*0*0 + b*0 + c = startZ
a*1*1 + b+1 + c = endZ
The next one requires calculus. If
f(t) = a*t*t + b*t + c
f'(t) = 2*a*t + b
f''(t) = 2*a

Oh, good, it is a constant function like we said. So we know that 2*a = gravity.

Ok, we've got three equations, for three unknowns. Time to solve. Turns out, it's not very difficult. If we simplify the above, we get
c = startZ
a + b + c = endZ
2*a = gravity

So we can read off what c and a are.
c = startZ
a = gravity/2
Plugging in to middle equation:
(gravity/2) + b + startZ = endZ
i.e.
b = startZ - endZ - gravity/2

Now we are done. We could make our quadratic function with
makeQuadratic(gravity/2, startZ - endZ - gravity/2, startZ)
or simply just write it out:
f(t) = gravity/2*t*t + (startZ - endZ - gravity/2)*t + startZ

But either way, we have successfully found a function that describes the motion we want.

NB: I did not do the above in order to produce my original solution, so don't try to reconcile the two.

NBB: This is a highly mathematical way of dealing with things. You have all encountered quadratic beziers before, but expressed in the form of two anchor points and a control point (ever edited a curve in Flash?). It's a more convenient form for a lot of work, and generalizes very nicely to bezier curves, but I didn't want to use it as it confuses the equations, and it's not quite as clear how gravity fits into the whole thing. Perhaps another day.

[AaronAardvark]

Bravo, Boris.
That's awesomely done.

[ChevyRay]

That explanation actually made a lot more sense to me too, and I can see how the results would work a lot nicer. I actually might try applying this later today cheers!

[salade]

hooray, nice explanation!

 

right now i'm trying to figure out how to change the height of the control point Boris was tallking about, without changing the two anchor points. every time i get it, i fail to make it work in code and then lose it.

oh well...

[ஒழுக்கின்மை (Paul Eres)]

yes, that was nice; perhaps a reposting as a quadratic equations tutorial in the tutorials forum would be warranted?

[BorisTheBrave]

hokay, I've reposted. No sense letting that effort go to waste. Still, it's all overkill, considering how quickly a useful answer was posted in the first place.

[Business Bear]

First of all, sorry if this technique has been given; I didn't feel like wrapping my head around this entire (very technical) thread.

I agree with adding a z-coordinate; this will make a more accurate model of the movement that you are trying to reproduce, even though the game may normally get away without it.

Here's a cheap but still good looking way to do these jumps of variable distance.  I keep the time and the initial delta z (initial velocity on the "up/down" axis) constant, and then calculate the delta x and delta y (movement to the new point) based on the distance they need to cover during that time period.

This way, you get the same jump height and the same duration for each jump, and you skip out on a lot of difficult math that some other methods might take.  The drawback is that the x and y speeds are variable, and would not reflect, say, a player's initial running speed before taking a jump.

[salade]

Um, could you provide an example? I'm trying to imagine how this would work. Wouldn't a z velocity not really matter in orthographic viewing?

[Sam]

You'd represent the Z-position of the object by adding it to the object's Y-position when you draw it.

Of course if we had a real overhead view then Z-axis movement wouldn't be shown at all, but it's assumed we're working with a "overhead but angled a little bit so you can see the sides of stuff" view.

The idea is that movement in the X/Y plane would be a simple straight line, and movement in the Z plane would be a simple jump motion.

Hopefully this can be seen in an example I made earlier in the thread, here.  The "shadow" shows the X/Y position of the ball, whilst the ball itself is drawn with Z and Y position summed.

[BorisTheBrave]

Hmm, your demo reminds me that it is probably more realistic to fix the jump speed and gravity, rather than the duration of the jump. Use duration = 2 * jump_speed / gravity and proceed as before.