• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.
  • We, the systems administration staff, apologize for this unexpected outage of the boards. We have resolved the root cause of the problem and there should be no further disruptions.

Really Big Hexes

My numbers are for stars, not systems. Given the large number of binary stellar systems, the number of stars should be divided by ~1.5 to yield the number of systems. (So at least 2/3 of systems should be binary+; some estimates are higher -- 75%--if you believe that, multiply the number of systems by .89 and increase the Density by 12%).

Here's the revised chart:

Distance..Systems..Density (Cu Parsecs/System)
15LY........35....11.77
20LY.......111...13.07
30LY.......184...17.67
40LY.......381...20.29
50LY.......665...22.7


I see the difference, and don't know for sure which he was referencing -but I suspect it may have been just stars.

In any case, I'm confused about the numbers above am I doing the math wrong ?

Heres my prob: taking 20Ly as = 6 parsec/hexes. one gets 216 cubic parsecs in a 20 LY cube around Sol.....your table notes 111 systems, which is about 1.9 CParsecs per system. Am I misreading your table ?

Interestingly, in any case, 111 systems , presented as a 2d map, would collapse onto a 2d array of 36 square parsecs - for close to 3 sytems per Cparsec, (or hex in traveller).
 
I see the difference, and don't know for sure which he was referencing -but I suspect it may have been just stars.

In any case, I'm confused about the numbers above am I doing the math wrong ?

Heres my prob: taking 20Ly as = 6 parsec/hexes. one gets 216 cubic parsecs in a 20 LY cube around Sol.....your table notes 111 systems, which is about 1.9 CParsecs per system. Am I misreading your table ?

My table is a *radius* not a cube. So, the 20 Ly entry is a sphere with a radius of 20LY, not a 20LY square cube. So 20 LY = ~6.13 Parsec. Volume is 4/3 x Pi x 6.13^3 = 967 cu parsecs. With 111 systems, the density averages 1 system per 8.7 cubic parsecs.
 
Last edited:
My table is a *radius* not a cube. So, the 20 Ly entry is a sphere with a radius of 20LY, not a 20LY square cube. So 20 LY = ~6.13 Parsec. Volume is 4/3 x Pi x 6.13^3 = 967 cu parsecs. With 111 systems, the density averages 1 system per 8.7 cubic parsecs.

Okay, that explains that. I was using a cube with a side of 20LY. Thanks for the explanation.


so, yeah, that is way less than traveller. I wonder where the 1 star/parsec estimate fits into this. Anyone want to ask EDG over on Mongoose ? I probably shouldn't......
 
The simplest solution is to keep everything as-is but institute a jump multiplier, as noted earlier. Instead of J-1 allowing you to jump 1 hex, it allows you to jump 3; J-2 allows you to jump 6; etc. The practical effect is that explorers and colonizers can skip over all those marginal, airless, waterless, fuel-less systems that Traveller generates. They'll still be there; they just won't have population numbers above 2 or 3 (that's the one change you'd need to make in system generation; a significant negative DM for inhospitable atmospheres and hydrography).

An alternative, instead of multiplying jump distances, is to add a constant. J-1 becomes J-3; J-2 becomes J-4; etc., so the range is 3-8 instead of 1-6. This reduces the speed discrepancy (the leggiest ships are not quite 3x faster than the slowest instead of 6x). It also has an important (and desirable, IMO) effect on refueling. Fuel requirements remain the same as determined by the jump plant -- that is, a J-1 plant (which allows you to jump 3 parsecs under these rules) still consumes fuel as a J-1 plant. If you jump only 1 parsec, you consume only 1/3 of your fuel tankage. If you have a J-3 jump engine (now capable of jumping 5 parsecs) and you jump 3 parsecs, you have enough fuel remaining to jump 2 more. The great advantages of this are that

a) there are more unpopulated or very-low population, backwater systems for wildcatters to prospect and pirates to hide in (because you still generate systems at the same density, you just don't populate the ones where it makes no sense to live),

b) you're not forced to run on unrefined fuel as often, and

c) because you can economically operate at less than your jump limit, a misjump no longer carries such a high threat of being a death sentence. (Raise your hand if you've ever lost an entire contingent of characters because their ship misjumped into an empty hex ...)

Steve
 
The simplest solution is to keep everything as-is but institute a jump multiplier, as noted earlier. Instead of J-1 allowing you to jump 1 hex, it allows you to jump 3; J-2 allows you to jump 6; etc. The practical effect is that explorers and colonizers can skip over all those marginal, airless, waterless, fuel-less systems that Traveller generates. They'll still be there;

This was my original solution, and I abandoned it for several reasons. The main reason was that I'd still have to chart and account for all those marginal systems and the players' map would be gigantic and cluttered.

Really Big Hexes allow you to assume the presence of marginal worlds while only having to represent them if they're critical to an adventure. They also give you the flexibility to create new worlds as needed for dramatic purposes (especially if you assume, like I do, that most such systems are largely unexplored).
 
Back
Top