yep - i was wondering about the interpolation side you went with, but clean code would definately be simpler.

I'll write up my pseudo-spaghetti tomorrow at work and post with diagrams.

Don
have a great day

You're welcome. But can you tell us where the different approaches failed? Did you try them all? I know my first code was horrifying (not to mention that it actually was no code at all), but the math looks right to me. So why did it fail?

The same goes for all other approaches mentioned here. (I don't know about the content of your PMs, but if there was a solution given, it would surely help others with similar problems if you gave at least basic details as to its content, because I, for one, am totally lost now.)



Sounds like a clever approach. I guess the problem is that for every "t", a different player will be closest to the ball, but you cannot tell this way for which "t" the player will get it (and there may be unlucky cases in which the "smallest distance t" will give you the "longest really-getting-there t". Plus, are you just calculating it once for "t=500frames from now", or are you actually calculating it five hundred times? If so, then my formula may not be so bad after all

EDIT: Ah, so there was a second page already! I didn't really understand your approach, Gumbydon22 (Thats an awesome name right there), so it will be interesting to see diagrams that may help to get it in my head


.....
Is it even real soccer? or is it futuristic soccer with weapons, or maybe MAGICAL soccer? Oh, yes. Magical games. I used to play those.

Your first attempt Error014 really confused me, I don't think it needs to be complex but you gave me the basic idea of calculating where the ball and player will be.

If I know t I can calculate using formulas how far each character will be to the ball. So yes I calculate 500 times, t = 1, t = 2, find the distance from the player to the ball from the player's and ball's position at t. When I've found the shortest distance I store the time value. I then find the player which has the smallest t value and make that player run towards where the ball will be

Nope there was no solution, even the way I have implemented fails at certain times and it's not really clean to calculate 500 times for each character each frame, I could do it less if I wanted. But one set of code which simply calculates what t is at, as you've all so graciously been doing, would be the best solution.

If I were to do the time segment calc's you're doing now David, I'd start with a calculation of half the field traveled, solve for whether its a good solution, or higher or lower, then go halfway to the higher or lower, until the calculation meets the required accuracy - this way you're cutting from 500 to maybe 20? calcs per guy per frame.

Working on my diagrams now...

Don
have a great day

Ok - I think this'll make my approach clearer, but my communication could do with some improvement still.

PDF Version

In text here:

Initial setup: we need to know the time it takes to reach a point at the same time as the ball. From time direction, position are calculatable fairly easily.


In order to solve with simple math, I propose using a 1D direct line between Ball and (each) Guy. This way we can solve with a straightforward timing calculation, and move back to full 2D with simple trig afterwards.


Math:
(Its been years since I did anything for anyone to look at, and my use of math in programming tends to be pseudocode -> compiler -> look at what errors spring up. The following may contain errors in type (int degrees/radians particularly) and code.

G1(2D) is:
G1Pos = BallPos + unityvector(direction to GuyPos) x (ballSpd*T1)

G1(1D math – dist from Ball to G1) is:
G1 = ballSpd*T1 = ballSpd*T1/(guySpd*T1+ballSpd*T1) * vec_dist(GuyPos,BallPos)

Therefore: T1 = T1/(guySpd*T1+ballSpd*T1)*vec_dist(guyPos,ballPos)
T1 = vec_dist(guyPos, ballPos)/(guySpd+ballSpd)

Timefactor = T1*cos(angle delta) //angle delta is angle between (ball-guy & ball–Goal)




I think that will clear it up, and I’ll leave it to you to test with real code. Anything further I write will screw with type errors etc. 

Don
Have a great day

Hey Don

This is the code I'm using from your math:



I'm not sure what it is but it simply fails to work properly in practice...could be my code, could be your math, I'm not sure. Thank you for the code.

I'm using my.movement_speed as the ball's speed value, that's deliberate.

Assuming the ball's speed is 0, this fails to work until I remove "*cos(result)"



David

Ahh - yeah I forgot to mention, it will need special cases for ballSpd == 0 or direction = 90, as these two simulations will be close to division by 0, which is a small no-no.

I'd suggest if the conditions of delta being non-90d, and speed of both greater than 0, then you solve with specific conditions.

I'm wondering if the code works with a delta angle of around 30degrees?

Don
have a great day

I'm sorry for confusing you, but math-wise, that approach should be pretty okay, I think! Maybe if you could put your confusion into specific questions, I could help you?

Honestly, it's actually not that hard. If you understand the graphics and the general concept, you can pretty much take the rest for granted, as thats just "putting it in math-speak" and then getting the proper conditions for "t". I know that it looks confusing, but isn't it at least worth a try? You just need to convert the last line into script (by which I mean: replace "|v_b|" with "vec_length(v_b)", and "x²" with "x*x"), but then, you should have a working piece of code!

It's not a guarantee, mind you, but I still don't see a rpoblem with the math, and I do think that its worth a try. We can try simplyfing it when we find that it works generally.

David - I wonder if you could strip back some code and give us a project prototype to play with, set up as a 2D intercept sim, and error and I could both try to implement our own (and each others) ideas in code?

Don
have a great day

Hi, i don't know if this has already been suggested as i have'nt read every single line but I do mechanics at school and this seems to be a common projectiles question.

The only thing missing is the distance from the ball to the player, but i guess that could be calculated with a vector function or something like that. Once you have the distance the ball is from the player, the time can be found easily.

u = inital velocity
Z = angle to ground
g = acceleration due to gravity (9.8)
t = time

Here are 4 equations of projectile motion...

Displacement (x) = utcosZ
Displacement (y) = utsinZ - 0.5gt^2

Velocity (x) = ucosZ
Velocity (y) = usinZ - gt

Example: distance to player is 30, angle is 15 and intial velocity is 10, trying to find time takes to reach player.

Horizontal velocity = 10cos15 = 9.66....

time = distance/speed = 30/9.66 = 3.11

I know I haven't explained it the best I could, but hopefully this could point you in the right direction.

Sorry if any of this has been mentioned before or that it is totally useless.

DJB MASTER...