Detecting circular movement around a static object

Started by
11 comments, last by Richter 13 years, 9 months ago
Hey everyone,

I'm working on a new title and I'm about to wrap up all my gameplay elements, but I've come across a problem(situation?) where I need to detect that the player has circled a static object. I am storing position, rotation, etc. for each object, and I'm updating them accordingly. I have several ideas, but I was wondering if I could pick the brain of the math experts on this one before I went ahead and finished it up.

Thanks
#1 Belmont, Richter
Advertisement
A good place to start might be with the winding number.
When the player approaches an "encircleable" object, note their position. I assume you'll know what plane the player will encircle the object in, so you don't need to set anything complex up, but do calculate the player's position as an angle relative to the encircleable object (ie 25°, being north of the 0° east). Store this "last angle", set a "signage" to +1 or -1 arbitrarily, and set an "accumulated angle" to zero.

Each frame, or every few frames...
1. Determine the new angle, and subtract the previous "last angle" to get "angle traversed".
2. Set the "last angle" to the new angle.
3. If the sign of "signage" does not match the sign of "angle traversed", then the player has reversed their rotation around the object. Set "signage" to +1 or -1 to match the sign of "angle traversed", and reset "accumulated angle" to zero.
4. If the sign of "signage" did match the sign of "angle traversed", then add the absolute value of "angle traversed" to "accumulated angle".
5. If "accumulated angle" is >= 360°, then the object has been encircled.

That should implement a fairly fault-tolerant state machine. Hope it helps.
RIP GameDev.net: launched 2 unusably-broken forum engines in as many years, and now has ceased operating as a forum at all, happy to remain naught but an advertising platform with an attached social media presense, headed by a staff who by their own admission have no idea what their userbase wants or expects.Here's to the good times; shame they exist in the past.
@Wyrframe: What if a player goes almost all the way around, then goes a little back, then completes the loop? I think the OP would want to count that as a complete circle, but AFAIK your algorithm would reset when the player heads back at all, so it would not pick up this motion.

However, I think your algorithm would work without the "signage" part (ie. subtract from total going the "wrong way", not reset the total). Simply integrating angle until total becomes 2pi (or -2pi) should be sufficient. Again, see the winding number page I linked to. The integral given in the "differenial geometry" section would probably be easier to compute - no need to determine angles, etc. The downside is that it's geometrically unintuitive.
i think the main problem with wyrframe's solution could be that it doesn't matter if you draw a circle at all, as long as you go aroudn the object; his solution would allow you to draw any convex shape that encircles the point, however un-circle like it might be. Depends if that's an issue or not :P
Quote:Original post by luca-deltodesco
i think the main problem with wyrframe's solution could be that it doesn't matter if you draw a circle at all, as long as you go aroudn the object; his solution would allow you to draw any convex shape that encircles the point, however un-circle like it might be. Depends if that's an issue or not :P


Oh, I suppose I've just been assuming that it doesn't really have to be a circle at all - just that point has been "encircled", so to speak. I guess the OP will have to clarify. For the record, using the winding number will accept *any* path that goes around the circle, regardless of concavity, self-crossing, or any other complexity.
Hey guys,

Thanks for the replies. In the game, the player must circle some objects counter clockwise, and some clockwise. I guess I was on the right track. The only thing I'm worried about is circling the wrong way. The player starts from a starting point on the level and then they have to circle the objects to form a pattern. Afterwards, they go back to where they started. There's an order to which objects their supposed to circle. I hope this clarifies things. I'll let you all know when I test it out.

Thanks again,
#1 Belmont, Richter
I should also note that the object doesn't have to be completed encircled. Each object in the level has to be looped around in a circle-like manner. I realize that is a terrible term... basically I need to detect that I have gone around the object in a loop. Here's what I'm trying to do:

My player gets control and can move freely in the world. The player must be able to follow a path around certain objects in the level. He must go around several objects in a predetermined path. They cannot deviate from the path, or else they lose. So I must detect going around an object, but it doesn't have to be a full 360.

My problem is that I need to figure out how to detect I went around an object either counterclockwise or clockwise, and when I've passed the point of where I have to be to satisfy the path I need to follow in the level.

Please let me know if any more clarification is needed.

Thanks,



#1 Belmont, Richter
How about using a spline? Whenever the player moves, compute the closest point on the spline to the player. If the distance from the player to the spline is over some threshold, they can be considered to have deviated from the path. Furthermore, if backtracking is not allowed, you can compute the parametric value associated with the closest point and make sure it is not less than the previously computed parametric value. (Note that you might have trouble with this method if the 'thickened' path is configured such that it 'runs into' itself.)

This is assuming that I understand correctly what you're after. If you haven't yet gotten the answer your looking for, maybe you could post an image showing what you're going for exactly.
Since your "encirclables" are static I have an idea for less geometric approach.

What if you put your focus away from the encirclables but rather setup paths the player has to take. Instead of keeping track of the relative position (and angle) you track when the player walks through some virtual doors (whose planes are perpendicular to the floor and intersecting the center) or rooms (polygones the player is standing on). This way you will need to (probably manually) define planes/rooms and of course accepting paths, which in turn will likely force you to use a graph structure (navigation mesh?). And I think backtracking can't be avoided.

Can't say if this suits your needs or even is an overkill. A sketch/screenshot really could clarify things.

This topic is closed to new replies.

Advertisement