AI jumping. Testing and help.

So I'm trying to teach this square how to jump properly on it's own. I've got it working well on my computer, but it seems like it doesn't work for anyone else. So if you could try this thing and post the results I'd be very thankful. Press R to restart. (Don't mind the ones that falls into the gaps, if one guy makes it then it works.)

I get the feeling the problems are related to the way the built in platform movement works. Anyone who knows what could cause this irregularity? Also, for me it works like 19/20 times with V-synced, but never gets to the end with fixed or unlimited framerate. I use a calculation to determine the strength of the jump, which shouldn't be able to fail as far as i know, but somehow it still quite big mistakes from time to time. I don't need pixel-perfect, but I'd like to know where the problem lies and how i can narrow it down to something i can work with. I'd really prefer not having to use a custom movement since it's going to be tricky with lots of enemies.

http://dl.dropbox.com/u/930918/jumps.exe

If you'd like to help me and need more info, pm me and I'll send you the .cap.

Help is very appreciated.

Jonatan

Only got 2 winners on about 20 runs. Most of the time they can't get past N�5.

Is it a TimeDelta problem?

Might be a timedelta problem. I don't really understand fully how the platform movement interacts with the rest of construct.. that's pretty much what i need help figuring out.

For most people it seems to fail at n.5.

Out of exactly 20 runs i got 0 winners.

After a bunch of resets without ever passing nr 5 I exited the app. But then I changed my mind, restarted the app but clicked too fast and the app ran in the background. Immediatly I had a winner. I then started to test a few running conditions for the app. Here are my results:

(1) Starting the app

No winner after many tries. It always fails at 5

(2) Starting the app, set the windows focus to another thread, but don't cover the app's window

The rate of winners raises strongly. Fails are either at 3 or at 5

(3) Starting the app, set the windows focus to another thread, and cover the app's window

Same results as (2)

(4) Starting the app, set the windows focus to another thread, and cover the app's window, but randomly force the app to draw again by moving the covering window away

Highest rate of winners. Almost always it works. The rare times it fails, it is at either 3 or 5

I don't know what to think about this. It is strange.

Yeah, that's really strange. I'm working on an alternative solusion now, using beizer curves for the jumps, but if possible I'd much rather use this method.

If any of the programmers see this, please give me your thoughts about what the problem might be.

It does come down to frame rate. I posted this on the bug tracker a couple of months ago. Unfortunately my monitor can't run any other frame rates to test it a bit more. Here is the link to the bug tracker artifact

http://sourceforge.net/tracker/?func=de ... id=1003219

try checking override time-delta in application properties? then the platform behavior will be frame rate Dependant.

Thanks for the tip quazi, I'll try and see how it affects things.

I think i found some problems in the code messing up as well. Try this version and see how it does.

http://dl.dropbox.com/u/930918/Jump2.exe

edit: Here's with override timedelta. Seems like that fixed the randomness. Thanks quazi! Now the question is if I'll be able to build a good game on something that requires that box to be checked.

http://dl.dropbox.com/u/930918/timedeltaOverride.exe

I did some tests to shed some light on the cause.

The max y position reached when jumping can be calculated with the following formula:

StartingY - (jumpStrength^2)/(2 * gravity)[/code:1lcbmjqd]
It seems that the platform behavior goes about 20 pixels higher than what is calculated when running 60fps.
I switched to unlimited framerate and it was only higher by 2 pixels on my computer.

The platform behavior seems to have a more accurate jump height with higher framerates, and a less accurate one with lower framerates.

Here's my test of the platform movements jump height with two other methods of computing motion.
[url]http://dl.dropbox.com/u/5426011/examples3/JumpTest.cap[/url] made in 0.99.96

A workaround could be to set gravity to zero and manually change the vertical velocity every tick with a more accurate method like Verlet.

Hope some of this is helpful.

Interesting topic. I have a 60 Hz display.

I tried the original, and it performed poorly for me most of the time.

In the second version, success rates seemed higher, but still not consistent.

The Timedelta override version was perfect every time for me.

The other thing that I noticed was that the 2nd and 3rd versions were a bit choppy on the side-scrolling.

The side-scrolling issues is nothing to worry about. I haven't cared much about the camera.

So it seems like the problems are caused by the irregularity in the platform movement caused by timedelta then. Thank you very much for your post ROJO, very helpful. I'll try to make a version using Verlet.

Another thing i thought about is if it's possible to use the timedelta expression in the jump-event to ajust the height for the platform movement. Don't really know how since i don't understand exactly how it works, but it would be great if it was possible.

So ROJO, i reworked your .cap to make the verlet thing move through a loop for better collision detection, but for some reason it jumps a bit higher, even though it (as far as i can tell) should be exactly the same.

http://dl.dropbox.com/u/930918/Jumptester.cap

At first i tried to make it like:

Always

-run loop "up" ceil(distance) times.

-set Y: Y+(distance-ceil(distance))

Something like that, but it had some problems with floats that i couldn't figure out how to solve, so i used the workaround that is in the .cap right now. I'm not really happy with it though. I don't like the unexplained extra height, and I get the feeling it could be made in a more efficient way.

Anyways, I'm going to implement it into my AI thingy and see how it works out.

It's actually less height. You need to change the order of actions so that the variable vy is changed after the object is moved instead of before. Then the jump will be the same as the calculated.

Doh.. i gotta learn to avoid getting tunnel vision when i spend too much time on the same task. This situation is way to familiar.

Thanks.