Logarithmic Star System Map

[Jeffr0]

What about a hex map of a solar system where the scale changes the further out you get from the sun.

The inner orbit (ie Mercury's in our system) would be the base line... at one hex away from the star. It's simplified orbit would be a circle made from six hexes. Venus might need to be crammed into there, too, for table space reasons.

Earth's orbit would be two hex's away from the sun... and would have an orbit of 12 hexes in a circle.

Mars would be three hex's away. The asteroids 4... Jupiter 5 or maybe 6... and so on.

Then... (as in the game Final Frontier) you would have a table that says when each of the planets are called to move-- each turn would specify what planets move one hex.

Then... you could make a program that calculates the travel times between the various planets and so forth. For any given turn... you could produce a chart explaining how long it takes to get from everywhere to everywhere at each G-rating.

The logarithmic scale would make it possible to have everything visible on a compact map.

 

[captainjack]

Interesting idea - I also note that if you set each planet's scale to 1/365 of its orbital period, you'd have each planet move one hex every day. The overall scale won't necc be log, as the planets are not in a pure log relationship (I think, although there may be a log function that approximates it) but it should work the same way.

 

[mike wightman]

This is a very nice idea - may be a good board upon which to base a TCS/HG tactical game...

 

[Jeffr0]

I just thought of a simpler solution: don't fight in the Sol system. That way, we don't have to fool with the scale so much. You have to assume that people like Hans and Constantine won't play it, but that's the only drawback.

So...

1) Ignore extraneous space junk. Just focus on the belts, gas giants, and habiable worlds.

2) Scuttle this logarithmic hex size distance idea and just take liberties with reality by making smaller star systems that play well.

3) Elongate the orbits into pseudo-ellipses. It just has to look cool.

4) Pick an easy number for the planet movements: every turn, every third turn, etc.

5) For the time scale... one turn is the time it takes for a ship to move one hex at 6G's...?

...

#5 is where I get into trouble, possibly.... Hmmm.... The variable m-drive ratings cause the headaches and there's no easy way around it.

Each fleet/ship will have to track their velocity. Because each map will have its own scale... you need a little chart on it to tell you what velocity gets you one hex....

Ah but that's still hairy...

Hmm.... Given a starting velocity for a turn... AND an M-drive rating... you should be able to calculate the number of hexes you can move on your turn.

Maybe the standard should be that M-3 ships (with velocity 0) can go one hex on a turn.... Better M-drive ships should maybe get to go 2 to 4 hexes depending on the math. Slow ships have to build up velocity before they can move a hex.

Something like that...

...

 

[robject]

You might only need to worry about planetary travel when your campaigns last longer than a couple weeks... and even then, perhaps only the innermost orbit moves a hex.

For High Guard, it seems reasonable that planetary objects will remain stationary for all practical purposes.


I know of one potential way around the acceleration issue: you could state that, unless a ship is using emergency agility, a ship will always use basically half of its acceleration to move, and the other half to "stop". Thus movement is non-vector typically, with the option to go full-out.

 

[samuelvss]

I like, if you have internet access while playing, using Ned Utzig's models when they are available: I think he has most of the 3I done. You just plug in the dates, G's, what orbit to what, and it plots it and gives you the times. A GM can even do this ahead of time.

For example:
http://www.utzig.com/cgi-bin/iai/sy...01 Im M9 V M4 D&UID=&Sectors=Spinward_Marches

 

[dccarles]

I know of one potential way around the acceleration issue: you could state that, unless a ship is using emergency agility, a ship will always use basically half of its acceleration to move, and the other half to "stop". Thus movement is non-vector typically, with the option to go full-out.

Not quite; distance moved is still dependent upon acceleration * the square of time. So distance is based non-linearly on time.

My suggestion: use a simple point-to-point system, along with Trillion Credit Squadron's one week turns. Getting bogged down in vector math is brutal if you have multiple task forces on each side.

--Devin

 

[Jeffr0]

Not quite; distance moved is still dependent upon acceleration * the square of time. So distance is based non-linearly on time.

My suggestion: use a simple point-to-point system, along with Trillion Credit Squadron's one week turns. Getting bogged down in vector math is brutal if you have multiple task forces on each side.

--Devin

Given a map where each hex is at the same scale... you could calculate the number of turns it would take to travel n hexes given a certain m-drive rating. You could also generate a chart detailing which hex you'd be in on each turn as you travel.

 

[Jeffr0]

Let's get specific.

Pull up a subsector hex map.

Put a star in hex 0506.

Put an inner planet in the "green zone" with an orbit going through 0504, 0603, 0605, 0606, 0607, 0508, 0407, 0406, and 0405. (It looks pretty it you draw it on with an actual ellipse.)

Put a gas giant further out with an orbit going through 0502, 0602, 0703-0709, 0609, 0510, 0409, 0309-0303, and 0402.

Make it a short year in this system. The inner planet moves once each month.

Make the gas giant orbit a little slower. He only moves one hex every two months.

So... while you're in system... the planets effectively stay still like robject said.

Now... you just need to know the distance of one hex. I dunno. Call it 100 million miles or so.

Now we just need some sort of movement formula or chart. Given a drive rating m... and a distance of n hexes... how long does it take to travel it assuming constant acceleration and then decerating the second half? Round to the nearest convenient operational turn "unit" of time.