Advertisement

soccer game movement help

Started by November 18, 2006 11:01 AM
21 comments, last by anti_hero 17 years, 11 months ago
I'm in the process of just playing about with a basic soccer game in Java that I'm hoping to build on. basically what I currently have is two players on the field with one attempting to pass to the other. the problem I'm having is, I think path-finding related. having one player pass to another player is ok as long as both players are either diagonally/horizantally in line with each other - my problem is that if the pass isn't a straight line. what I'm currently doing is checking where the player A is that will be receiving the pass, checking where the player B is making the pass and trying to figure out an algorithm that would make the pass move in a straight line. can anyone give me some hints/clues what direction I should be moving in for this problem? any help would be greatly appreciated! [Edited by - anti_hero on November 18, 2006 11:53:36 AM]
You also have to take into consideration the velocity of the players if you want the ball to move in a straight line between moving players. I'm not very good at explaining stuff like this, but basically you take the parametric equations of the players (f=position+velocity*time) and put those into the slope equation (m=(f2-f1)/(t2-t1) and then you should get something like:

Vx = (Player2.x-player1.x+t*player2.xvelocity)/t
Vy = (Player2.y-player1.y+t*player2.yvelocity)/t

note that t in those last 2 equations is actually the change in t which conveniently is equal to the amount of time the pass will take to get from player 1 to player 2. The equations should work with any t, but to get a realistic pass you'll have to determine(or atleast estimate) your t based on the actual path length.

edit:
You're using java eh? While coming up with my answer to this question I wrote a java applet to test it: http://www.alrecenk.cjb.net:7790/java/test/pass/
you can get the code there if you want, but it's not commented or anything so I don't know how much good it would do.

[Edited by - Alrecenk on November 19, 2006 3:28:36 PM]
Advertisement
thanks very much for that! it's great - but at the risk of sounding a little stupid - how do I convert from applet to an application type file?
Rather than trying to convert my applet to an application you should try to use the equations/ideas in the code you already have. You'll learn alot more that way and it'll save you alot of trouble later if you don't have to try to read someone else's code(particularly in this case since I wrote that code in like 10 minutes and I highly doubt I did it with good programming practices). Though, for future reference, if you change "extends JApplet" to "extends JFrame" and put in a main method something like below it will probably work as an application.
public static void main(String[] args)  {    yourclassname window = new yourclassname();    window.init() ;    window.addWindowListener(new WindowAdapter()      { public void windowClosing(WindowEvent e) { System.exit(0); }});    window.setSize(width, height);    window.show();  }
Wow, that looks really nice! It's impossible not to see the two spots as two people throwing a ball back and forth between each other (or, actually, a frisbee). It looks particularly nice when one of the players throws the ball "behind his back," in the opposite direction from where he is going.

Some thoughts/expansions on this idea:

- The current throw speed apparently depends on the distance between the two players. While this looks good - hard throws when the players are far apart - it should be codable such that the ball speed can be anything, and still calculate correctly. It should be possible, for instance, to have hard short throws.

- It would be interesting if the aim were not always perfect -- either due to rough guessing of the other person's speed, or just plain bad throws. The other player ought to be able to adjust his course in order to intersect with the ball anyway.

Well, anyway, it looks good. Maybe I'll code up an ultimate frisbee game!
Quote: The equations should work with any t, but to get a realistic pass you'll have to determine(or atleast estimate) your t based on the actual path length.

Yeah, I said this, but I didn't do it in my example. I just plugged in a constant time.

You could have the ball be the goal of the catching player rather than the catching player being the goal of the ball. Then just shoot the ball at where you want the ball to go(like forward in soccer or ultimate frisbee) and rely on the player/s to intersect it.

Since I did this I've been looking for an excuse to use it in one of my games too, but unfortunately my current game uses quadratic splines and circles. Ok, so it's not that unfortunate.
Advertisement
hey guys! good to read your ideas and what you're up to in similar areas to what I'm doing.

where I am now:

I have 5 players each moving randomly around, passing the ball to each other.

what I now want to achieve is 5 opposition players trying to get the ball from the 5 that currently have the ball and also intelligent pass making - the player on the ball looking for players who are open for a pass/no opposition players near them.

what I also want to achieve is more intelligent movement of the players with regards to their field position (ie. defensive players, attacking players).

also I have been trying to work on how fast the players move but seem to be getting no where - for example I want to create players with attributes ranging between 1 and 50 (1 bad - 50 good) - if a player has 50 for pace/acceleration - how could I simulate that player moving faster than a player who has a rating of 1?

these things are my current work in progress things.

edit:

it just occured to me to mess about with t and t2 to make movement quicker (if only there was something like this available to make my brain move quicker!)

[Edited by - anti_hero on November 22, 2006 2:42:06 PM]
For better field positions what you want is some kind of loose formation logic. allow designers to "script" formations by entering offsets for the "ideal" case. the unit AI will then get it's formation slot from some manager.
the unit AI will then be unable to stray too far from that slot position but should have enough freedom of movement to look smart in it's local area.

For locomotion you just apply the weight as a modifier to the speed:
actual speed = modifier * base speed;
might be easier to just have base speed be max_speed and then have the numbers tuned from 0.0 - 1.0
You can author the basic run animation to operate at the base speed value. That way you can just modify the rate at which you play the run animation by the same modifier tuning value to avoid sliding.

For passing it's just a straight up physics problem. You know your starting point, you know the desired endpoint, you know the speed at which the ball travels. For starters just "push" the ball towards the target player. Later on you can do "leading" - i.e. push the ball ahead of the target's position in the direction he is currently moving. But passing is a 2-sided algorithm: 1 the pass itself which is just straight physics, 2 the target unitAI will want to "seek the ball" i.e. move towards it to "catch" the pass.

In general, just start with the easiest possible solution. Once you get that working, iterate on the idea until it becomes a more complicated solution.

Also sounds like you'll want to learn Linear Algebra and some basic kinematic newtonian physics. at the end of the day, all this stuff is math and physics.

-me
An alternative to a scripted, formation based play would be to perform a simple tactical analysis of the conflict between the two teams, looking for 'open' areas (areas of little conflict) to move into and pass into. You could use an Influence Map approach, or potential fields. For some background on this approach, check out Penny Sweetser's homepage at UoQ.

Cheers,

Timkin
with regards to tactics what I was going to do was give players x,y positions for when their team is both attacking and defending, and then take into account specific player tactical instructions to dictate a little how they move. for example if a player is instructed to make forward runs then take into account its field position and then move forward into a position depending on how far forward the player is instructed to go. or another example if a player is told to track an opposition player when the opposition have the ball, that player would then shadow the opposition's player.

that's what I've been working on just now, I have one attacking player making a run toward a preset position and then a defensive player tracking across to follow.

a problem I'm having with player movement is, well this might be easier to explain with the code, so here it is:

p1[0]+=p1[2] ;
p1[1]+=p1[3];
a1[0]+= a1[2];
a1[1]+= a1[3];
double x = 50;
double y = 350;

if ((int)p1[0] != 50 & (int)p1[1] != 50){
p1[2] = (x-p1[0])/(t2+t) ;
p1[3] = (y-p1[1])/(t2+t) ;
}

if (manmarkinga1 != 0){
if (manmarkinga1 == 1){
a1[2] = (p1[0]-a1[0]+t*p1[2])/t ;
a1[3] = (p1[1]-a1[1]+t*p1[3])/t;
}
}

basically the player slows down when it gets towards its preset destination, in this case x position 50 and y position 350... I can kind of see why it happens when setting pl[2] and [3] - I'm just not entirely sure what to change to stop it happening.

I have just been reading the articles on influence maps, it sounds like an interesting way incorporate tactical analysis, I think I need to read more.

I've also been reading about quadratic splines. I think my head is about to explode! it's been a long time since I've done this kind of maths work. fun fun fun!

This topic is closed to new replies.

Advertisement