How to determine if a line is fully contained inside a group of circles

Started by
4 comments, last by Zeraan 11 years, 11 months ago
For my 4X game, I'm considering switching over from a grid-based system to a star-to-star movement (basically a node-based system where every node is connected to another node), similar to Master of Orion 1/2. One aspect of this is that I will introduce "Supply Range" which restricts where your ships can go. Each owned system have its own supply range. So the problem is now broken down to this:

Each node has a circle with radius of s (supply range)
When moving from a node to another, the line between the two nodes must be fully contained by circles. (X1,Y1 is starting position, X2, Y2 is destination)
If the line is not fully contained, the route is invalid.

Here's two examples:
Two star systems on the opposite sides of galaxy are owned by the player, but no stars in middle are owned, so the player can't send his ships directly from one node to another.
One fleet is moving from one star system to an unexplored star system that is within range, so the route is valid.

I tried looking this up, but was unable to find any resources. Maybe I'm looking with wrong search terms.

I think I do have an idea of how to do this:

Find intersection points along the line where it intersects with circles, and call them l1, l2, l3,...
For each lx, lx+1, check to see if both points is within any circle, if so, remove from list.
If list is empty after processing, then the line is fully contained.
If list have at least one segment remaining, then the line is not fully contained.

Is this a good approach to this problem? Any pitfalls I missed?
Advertisement
Performance-wise the solution does depend upon how many stars there are and what distances you are travelling.

From my perspective, a simple approach that doesn't involve necessarily checking every circle goes as follows:
1. You have a list of "closed" stars. These are stars you have already checked against. The rest are "open" stars.
2. If either start or destination star is owned, start by going a distance s along the line to the other star. Add it to the closed list. An easy start.
3. Check if any open stars are within distance s of your current position. Methods such as quadtrees could be used to make this stage faster.
4. Move to the intersection of this circle and the line closest to your destination. Add it to the closed list.
5. Go back to 3.

- If at any stage you reach the destination or go past it, it is reachable.

- If at any stage no stars are left, it's not reachable.
There is a serious flaw in your scheme: not all routes are straight lines, as you might be forced to make deviations to remain inside the supplied region (a longer path is better than no path at all).
Your problem is equivalent to pathfinding through caverns consisting of the union of hollow balls (i.e. node supply ranges) dug into solid rock (i.e. unsupplied space): straight lines might go through rock, but maybe you can detour around corners.

If you don't want to maintain a traditional pathfinding graph, you can presumably build it on the fly: from each ball, you can only go to intersecting balls, which are easy to find with suitable spatial indexing. Then you only need to sort "portals" by angle to see whether you need to make a turn at either corner of the intersection of two balls, or you can go straight.

Omae Wa Mou Shindeiru


There is a serious flaw in your scheme: not all routes are straight lines, as you might be forced to make deviations to remain inside the supplied region (a longer path is better than no path at all).
Your problem is equivalent to pathfinding through caverns consisting of the union of hollow balls (i.e. node supply ranges) dug into solid rock (i.e. unsupplied space): straight lines might go through rock, but maybe you can detour around corners.

If you don't want to maintain a traditional pathfinding graph, you can presumably build it on the fly: from each ball, you can only go to intersecting balls, which are easy to find with suitable spatial indexing. Then you only need to sort "portals" by angle to see whether you need to make a turn at either corner of the intersection of two balls, or you can go straight.


It depends upon the OP's intent. If line means a straight line, then he's on the right track. Reasons to do this could be an emphasis on micromanagement, or an aversion to the control system accepting an order and sending a valuable ship on a mighty odyssey that gets it to the destination via 31 hops near enemy territory.

On the other hand, if you're correct then (as I think you're saying) a simple A* using stars as nodes and intersecting circles as edges, with some path smoothing and/or steering behaviours would work fine.
Alternatively one could build the navigation graph from circle intersection points and stars. That should give the absolute shortest path.
After reading your responses, I realized that if the star was just a bit off the beaten path, but is within supply range, it'd be annoying for the player to have to send the fleet to an adjacent star then issuing another order to finally arrive at the destination. In Master of Orion 1/2, it just checks whether or not the destination is within range, not if the route itself has left the range.


Alternatively one could build the navigation graph from circle intersection points and stars. That should give the absolute shortest path.


This looks promising, since I plan on adding obstacles such as black holes or nebulaes that you need to navigate around. Are there tutorials on creating a navigation graph? I remember trying to find some, but was unable to do so.

This topic is closed to new replies.

Advertisement