Design: Starlanes

tsev · **Posted:** Fri Aug 01, 2003 11:57 am

Thumper wrote:

tsev wrote:

We definitely should limit the maximum length of a starlane, though. I think it would just clutter up the UI if we had starlanes going from one end of the galaxy to the other.

Which brings us to Worm Holes.

Should WHs be long links within a single galaxy -or- should they connect to other galaxies only. As I just thought of this multi galaxy angle I thought it might be interesting to toss it out for comment.

IFF WHs link galaxies then:

1. There should be no more than two per galaxy.
2. They should be considered prime real estate.
3. They should give the controlling race a very large financial boost. (by controlling I mean the race that controlls both ends of the WH.
4. They should be given a very high protect or capture rating by the AI.

Thumper

The entire game takes place in 1 galaxy, so we can't link to other galaxies.

Also, wormholes are actually implemented in the code as starlanes....they just tend to be longer. So the AI will automatically consider them either valuable or useless depending on the current situation. I would think that due to the fact that using a wormhole would be the fastest way to access remote locations of the galaxy, the AI will, in most cases, put a high value on them.

Nightfish · **Joined:** Thu Jun 26, 2003 7:07 am **Posts:** 313

I like the first option best, too. I just wasn't sure how easy this is to program. If it's no problem I think this is the best solution. Starlanes should look rather tidy so as not to confuse the player.

tsev · **Posted:** Fri Aug 01, 2003 1:13 pm

Nightfish wrote:

I like the first option best, too. I just wasn't sure how easy this is to program. If it's no problem I think this is the best solution. Starlanes should look rather tidy so as not to confuse the player.

Programming it wouldn't necessarily be all that difficult, but it would slow down the universe generation process while it validates, replaces, and removes starlanes. But, this isn't a big deal since it happens only once before the game actually starts, so you expect to wait for stuff to load.

<ot>
On a side note....FO is a game, and thus its not really EASY to program anyway. Its the challenge that brought us here. If it were easy, everyone would do it. If we only programmed stuff that was easy, we'd end up with Master of Orion 4 - "Hello World"

</ot>

Nightfish · **Joined:** Thu Jun 26, 2003 7:07 am **Posts:** 313

Well, I hope you'll have some patience with me, as I know nothing of programming. So I don't really know how hard these things are. I'm pretty sure a noncheating, challenging AI is very hard as no game had one of those so far.

Of course I realise that there are several degrees of "hard" and that basically everything that needs to be programmed is hard work to at least some extent. What I was trying to say is "if it makes sense from a gain/cost point of view, let's do it. If the gain is very small and the cost is very high, then let's not do it."

tsev · **Posted:** Fri Aug 01, 2003 3:38 pm

Nightfish wrote:

Well, I hope you'll have some patience with me, as I know nothing of programming. So I don't really know how hard these things are. I'm pretty sure a noncheating, challenging AI is very hard as no game had one of those so far.

Of course I realise that there are several degrees of "hard" and that basically everything that needs to be programmed is hard work to at least some extent. What I was trying to say is "if it makes sense from a gain/cost point of view, let's do it. If the gain is very small and the cost is very high, then let's not do it."

Its certainly an issue we need to resolve, regardless, and I know I don't want to look at a map that looks like a tangled mess of wires.

maybe we could just display all the lanes as they are, and then highlight ones connected to the selected system. Also, we can only display starlanes on the screen that connect to systems that are being displayed, so we don't see any extraneous data.

In the example, only systems B and C are visible, so the starlane connecting A and D doesn't need to be shown.

Code:

 A
  \
   \
 ===\======
|    \     |
| B---\--C |  <----The box is
|      \   |     the viewable
 =======\==      area of the
         \       screen
          D

Nightfish · **Joined:** Thu Jun 26, 2003 7:07 am **Posts:** 313

That would work pretty well when you're trying to figure out where to travel, but how well would this work in gauging strategic positions? I think it's a high priority that you can tell at a glance without highlighting or selecting where choke points are. Also we need to make sure those choke points are in fact created. I'm not sure that's a certainty unless we make starlanes connect to the nearest stars first, though I might imagine it wrong, I've never seen starlanes in action in any game so far.

tsev · **Posted:** Fri Aug 01, 2003 5:00 pm

Well I'm sure we could set something up maybe where starlanes are only visible if you hold the SHIFT key or something....I don't know.

Maybe we should have the graphics people mock up some screens with starlanes in various configuration so we can get a visual feel for what things will look like.

jbarcz1 · **Posted:** Fri Aug 01, 2003 5:26 pm

perhaps the endpoints of a starlane could be visualized. I.E. starlane from A to be looks like this:

A X ------------B----------XC

Or, even better, we can avoid such situations by saying that Starlanes always connect to the first system they intersect, so during universe generation we detect cases like this and either make it:

A X-------XBX---------XC or else just eliminate the lane entirely.

This would guarantee that we dont have lanes crossing systems like that.

Impaler · **Posted:** Fri Aug 01, 2003 5:31 pm

I second that, perhaps also a "high light lanes that connect to your star" that would be like doing the afor mention light up but for ALL systems you have colonis or fleets in.

I think it is possible to have choke points with crossing starlanes but they will not nessarily be faster then off road travel in some unulual highly bent situations, as with uncrossed lanes the starlane choke would for all practical purposes ALWAYS be faster.

tsev · **Posted:** Fri Aug 01, 2003 5:37 pm

jbarcz1 wrote:

perhaps the endpoints of a starlane could be visualized. I.E. starlane from A to be looks like this:

A X ------------B----------XC

Or, even better, we can avoid such situations by saying that Starlanes always connect to the first system they intersect, so during universe generation we detect cases like this and either make it:

A X-------XBX---------XC or else just eliminate the lane entirely.

This would guarantee that we dont have lanes crossing systems like that.

GENIUS! Because essentially, its the same thing! If it takes x turns to go from A to B, and it takes y turns to go from B to C, then it will take x + y turns to go from A to C, whether the starlane stops there or not.

The only difference is that you can get off at B, but in the interests of keeping things simple, we should do it this way.

Thumper · **Joined:** Sun Jul 06, 2003 3:48 am **Posts:** 131

tsev wrote:

In the example, only systems B and C are visible, so the starlane connecting A and D doesn't need to be shown.

Code:

 A
  \
   \
 ===\======
|    \     |
| B---\--C |  <----The box is
|      \   |     the viewable
 =======\==      area of the
         \       screen
          D

It does if B or C connects to either A or D. It is a known route.

Thumper

jbarcz1 · **Posted:** Fri Aug 01, 2003 8:09 pm

tsev wrote:

Nightfish wrote:

Well, I hope you'll have some patience with me, as I know nothing of programming. So I don't really know how hard these things are. I'm pretty sure a noncheating, challenging AI is very hard as no game had one of those so far.

Of course I realise that there are several degrees of "hard" and that basically everything that needs to be programmed is hard work to at least some extent. What I was trying to say is "if it makes sense from a gain/cost point of view, let's do it. If the gain is very small and the cost is very high, then let's not do it."

Its certainly an issue we need to resolve, regardless, and I know I don't want to look at a map that looks like a tangled mess of wires.

maybe we could just display all the lanes as they are, and then highlight ones connected to the selected system. Also, we can only display starlanes on the screen that connect to systems that are being displayed, so we don't see any extraneous data.

In the example, only systems B and C are visible, so the starlane connecting A and D doesn't need to be shown.

Code:

 A
  \
   \
 ===\======
|    \     |
| B---\--C |  <----The box is
|      \   |     the viewable
 =======\==      area of the
         \       screen
          D

I agree with thumper. We're going to want to be able to see everything. What if you thought a system was safe, only to discover that it really connects to some enemy system that wasn't onscreen when you looked?

Nightfish · **Joined:** Thu Jun 26, 2003 7:07 am **Posts:** 313

tsev wrote:

A X ------------B----------XC

A X-------XBX---------XC

Can we make it so that the program knows when it's about to produce something like the first example and have it automatically convert it to something like the second example? I mean what if B was not exactly between A and C but little off center? Could we set some sort of limit? Like "3 stars have to fit between B and the starlane that passes B", meaning if B is too close to the starlane connecting A and C the program sort of bends the starlane to connect A to B and then B to C.

Also, can we have the program avoid crossing starlanes? That would probably look better than having a more chaotic starlane setup and would also help the player in finding his way around the galaxy.

jbarcz1 · **Posted:** Fri Aug 01, 2003 8:37 pm

It should be easy enough to figure out when you've got an intersecting system that's close, but not quite, in line. So off-center planets can be dealt with.

Having the program avoid starlane crossings is a non-trivial task. I did some proprietary research work involving graph layout, and we never did find a solution to the edge crossing problem while I was there. There are solutions in existence, but its probably more trouble to implement than its worth IMO, at least initially. If there are third party graph layout libs out there though, we might look into using them.

If we wanted We could do it by detecting crossings and then putting another, empty system there, but that's sortof cheating

And if you've got a wormhole that stretches the length of the galaxy there will be a crossing someplace, there's just no avoiding it.

Nightfish · **Joined:** Thu Jun 26, 2003 7:07 am **Posts:** 313

With Wormholes it's no problem, I think. Well, that depends on how many wormholes we have. I was thinking that those would be really rare. Starlanes on the other hand... well, they might average at about 2 or 3 per system, so we have about 300 of them in a galaxy with 100 systems and I'm not even sure that's our largest galaxy...

The idea of detecting crossings and placing systems there isn't that bad. I wouldn't dismiss it offhand. Though I don't know about making the systems empty by default. It would give away our "cheating" and besides it might flood the galaxy with empty systems *g*

FreeOrion

Design: Starlanes

Who is online