[FT] Strategic Thrust

The point of a strategic game is to generate battles for Full Thrust, which
means we ought to have an idea of each force's vector at the intercept point.
I propose we map the solar systems on hex grids with a scale of, say, 1 AU per
hex (or whatever fits neatly into the equation--if I recall
correctly, 1 gravity for 24 hours will move you 1/4 AU, and
1 g for 48 hours is about 1 AU). If you come from Star A to Star B with the
intent of attacking a planet, you will have an inherent vector (which we can
PSB as the velocity difference between one star and the other). If you arrive
on one particular hex, you will have a straight run to your target; arrive on
any other hex, and you have to maneuver, which takes more time, costs fuel (if
you worry about that) and makes you more likely to be detected.

Why bother? Because this way the defender doesn't have to
garrison all of space to protect his planet--but on the
other hand, the attacker doesn't have to force his way through a jump point
assault (I personally prefer a "wide Alderson Point" approach, but that
doesn't seem to fit the Tuffleyverse).

If we assume that the jump limit for a star is proportional to the square root
of the mass, and we set the Jump Limit for Sol at 1 unit, we find the Main
Sequence stars will have jump limits that vary from about.46 (M9 star) to 1.79
(for
an A0 star like Vega--I don't recall that we have any O or B
stars locally).

The question then becomes, how many hexes across do we want our map to be, and
at what scale? That will determine how far out the Jump Limit is. I'm thinking
about 11 AU out
from Sol, which would put it out past Saturn--but would also
mean that an A0 star would have its jump limit at about 20AU
or 80 hexes (on the .25AU/hex scale), requiring several
sheets of paper to map (or a change in scale).

Cut to the chase: How far out should the Jump Limit be for Sol? Please vote
using AU (not, for example, "in the Oort Cloud").

--Chris  DeBoe
Quixtar IBO#706882
http://www.quixtar.com

> The question then becomes, how many hexes across do we want

This depends on your hex size. Make your hexes 1/2 or 1 AU and it's very
possible (at 40 or 20 hexes respectively).

For the "system scale" you don't need excessive detail, just enough to provide
tactical possibilities. You should be more than able to do that with a jump
limit 40 hexes in diameter. That includes ALOT of hexes. I like the 1AU per
hex option.

> Cut to the chase:

11 sounds fine for Sol. 22 hex diameter. KISS.

> >Cut to the chase:
I like the Traveller New Era take on this where each star had 20 "zones" (40
in diameter)

Each zone covers an exponentially larger area but then the further from the
habitable zone you are in a system, the less interesting things are likely to
be happening anyway.

If each star has a constant 20 radius of zones you could figure out, per star,
what its jump limit would be as a zone number. For instance Sols might be
"Zone 7" and Betelgeuse might be "Zone 11". With consistent system maps its
easier to track things in a campaign. With real star data it is easy to
calculate what the characteristics of a zone would be ie "Inside Star",
"Inner", "Habitable", "Outer" by assigning a Bode Constant to the star.

Mapping this back to a hex map would just mean using hex "rings" instead of
circles.

        Dan

Daniel Cleyne said:

> I like the Traveller New Era take on this where each star

I thought about this, but with a varying distance per hex, it's a real pain to
figure your vector into the
system--which is what determines the details of the battle.

> far out the Jump Limit is. I'm thinking about 11 AU out

I'm thinking now about a sliding scale: Inner System (8 or 10 or 12 hex
radius) 1 hex =0.25 AU Mid Distance (another layer as thick as the first)= 1
AU Outer System 1 hex = 4AU These correspond to 1, 2 and 4 days of 1 gee,
which means it would be easy to translate speeds when crossing a boundary.

> I'm thinking now about a sliding scale:

I think that the system would benefit from consistent scale, otherwise it gets
too complex.