Jump lines as roads.

Jump lines as roads.

[Henry J. Cobb]

There are several games such as Warp War or Imperium that have jump lines
or warp lines on the map.

You enter one end of the line and appear at the other end instantly or
very quickly.

So how about a map with stars as impassable single hexes surrounded by a
small amount of normal space in which there are planets that do production
and house troops and fighters.

At the edge of each system is an impassable "scale barrier" cut through
with jump line roads that have a movement cost of zero or very close to
it, but these roads are restricted to jump or warp equipped ship classes.

Can mplayer handle this and can it be generated with the standard map
routines?

-- 
Henry J. Cobb's Completely Unofficial list of GURPS Vehicle Builder fixes
and workarounds.  http://www.io.com/~hcobb/gurps/gvb_faq.txt

Re: Jump lines as roads.

[Lincoln Peters]

On Sun, 2004-08-22 at 19:16, Henry J. Cobb wrote:
> There are several games such as Warp War or Imperium that have jump lines
> or warp lines on the map.
> 
> You enter one end of the line and appear at the other end instantly or
> very quickly.

I don't know of any way to make movement cost less than 1 ACP per cell,
although I suppose you could give a jump- or warp-equipped ship lots of
ACP's.  You would then have to counterbalance them in other situations
by requiring them to spend lots of ACP's on anything other than
movement.

> 
> So how about a map with stars as impassable single hexes surrounded by a
> small amount of normal space in which there are planets that do production
> and house troops and fighters.

Such things exist.  See galaxy.g, galaxy2.g, space.g, and space-civ.g. 
I suspect that space-civ.g (which was never finished) comes closest to
what you're describing.

> 
> At the edge of each system is an impassable "scale barrier" cut through
> with jump line roads that have a movement cost of zero or very close to
> it, but these roads are restricted to jump or warp equipped ship classes.

You could make planetary space and deep space different terrain types
entirely.  This is how space.g works.

> 
> Can mplayer handle this and can it be generated with the standard map
> routines?

Look into how it's done in space.g and space-civ.g.  You might also want
to look at the code that's used to generate roads, and possibly the
make-maze-terrain synthesis method (used in cave.g and cave2.g).

Unfortunately, the AI is usually terrible at such games, probably
because it has no concept of how to load armies onto a transport ship
and then move the transport ship so that the armies can attack an enemy
planet.  Perhaps this wouldn't be an issue in your game, depending on
how you were to handle such things.

---
Lincoln Peters
<sampln@sbcglobal.net>

All your people must learn before you can reach for the stars.
		-- Kirk, "The Gamesters of Triskelion", stardate 3259.2

Re: Jump lines as roads.

[mskala]

On Sun, 22 Aug 2004, Lincoln Peters wrote:
> I don't know of any way to make movement cost less than 1 ACP per cell,
> although I suppose you could give a jump- or warp-equipped ship lots of
> ACP's.  You would then have to counterbalance them in other situations
> by requiring them to spend lots of ACP's on anything other than
> movement.

I did exactly that in a game I was working on.  One problem I found was
that the pathfinding code didn't seem to be smart enough to take full
advantage of the fast routes - resulting in a big advantage for human
players if they were willing to spend the time moving the units a step or
two at a time.  It probably would have worked better if the fast routes
were, or were close to, straight lines.

A similar effect applies to the standard game, too - you're in city A,
there is a road to city B but it winds a little, you tell the unit in city
A to move to B, but it doesn't take the road.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Jump lines as roads.

[Eric McDonald]

On Mon, 23 Aug 2004 mskala@ansuz.sooke.bc.ca wrote:

> I did exactly that in a game I was working on.  One problem I found was
> that the pathfinding code didn't seem to be smart enough to take full
> advantage of the fast routes - resulting in a big advantage for human
> players if they were willing to spend the time moving the units a step or
> two at a time.  It probably would have worked better if the fast routes
> were, or were close to, straight lines.

This is one of the few advantages we lost in May of this year when 
we reverted back from Peter's Astar pathfinder implementation to 
the simpler one that Xconq presently uses (and used before around 
October or November of 2003). With Astar, one has an evaluator 
(cost function) that is applied along various paths, and the best 
path is chosen through use of the evaluator. (Provided you have a 
good evaluator, of course.) The evaluator is free to consider 
whatever it wants, and ours did take into account such things as 
movement price when weighing the cost of a particular path.

Eric

Re: Jump lines as roads.

[Jim Kingdon]

> This is one of the few advantages we lost in May of this year when 
> we reverted back from Peter's Astar pathfinder implementation

There was at least one other advantage which I miss on a regular
basis, which was that the Astar pathfinder also would fly over a city
rather than landing in it and taking off again.

Of course, restoring this one feature would probably be much simpler
than the smart pathfinding, as the sequence of hexes traversed
wouldn't need to change.

Re: Jump lines as roads.

[Eric McDonald]

On Sun, 22 Aug 2004, Henry J. Cobb wrote:

> You enter one end of the line and appear at the other end instantly or
> very quickly.

This concept sounds very similar to the "portals" or teleport 
zones that we have discussed previously. Probably if such idea 
was to be implemented, you could utilize it.

Eric