• 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.

3D Star Map opinions?

3D starmaps are great fun to play around with - but at the table in my experience they cause more trouble than they are worth.

I concur. During my tinkering, I wrote a script that generates a graph of every system up to two jumps out for the jump range of the ship. If it had been interactive, I'd have added two features: the ability to tap on a system to re-center the graph on that system, and a "return to current system" button. As it was, the script just spat out Dot code for formatting with Graphviz.
 
The Trav 2D density isn't representative, and wouldn't carry over to a 3D map. Our stellar neighborhood is about 8 cubic pc per star. That means there are about 64 stars in a 5 pc radius. On the other hand, it also means that any star has only about 1 in 3 chance of having a neighbor within 1 pc. If you allow Jn to reach n+0.5 pc the chances of a neighbor in J1 reach go way up.



That more stars are reachable within a given number of parsecs is the whole point. A J2 3D ship could trade like a J3 2D ship, and a J3 3D ship could trade like a J5 2D ship. J4+ becomes the province of military and high-price express travel.
 
Three dee star mapping should probably wait until someone generates a computer simulation that you can easily navigate on a tablet, and which would require a rather extensive retconning of Third Imperium astrography.
[ . . . ]
This is the principal issue with 3D mapping. While you can do a projection that can visualise a small region of space on a paper map, doing anything cleverer puts you into the realms of needing a computer to visualise it effectively.

Even on a smaller scale there are practical issues that make it quite hard to do well, and in practice it doesn't bring a lot of benefit to actual game play. I put it in the 'Not worth the effort' bucket.

Actually building an app to do this and doing it to a quality level where it can be let loose on random DMs is a significant investment, probably out of the reach of all but larger publishers. It also makes your game dependent on the app - which may or may not be strategically desirable. Most of the attempts I've seen at doing this didn't work all that well or were unusably buggy.

Even before you get into the effects on the OTU, you're also into a cubic growth of your universe with dimensions, making the development of sandboxes a rather larger effort. Applying the OTU's assumptions about communication to make a 3D Imperium of the same dimensions would result is a very large region of space with millions of stars. While a published sandbox on that scale would be totally awesome, it wouldn't be practical to build through anything but procedurally generated content. At that point you might as well just go and play No Mans Sky or Elite: Dangerous.

If you were doing a computer game a 3D map isn't a big deal, and you're in a use case where you can assume the player has a computer. For a pen-and-paper game it brings a significant development cost and a dependency on a computer that you or your players might not want.
 
Even before you get into the effects on the OTU, you're also into a cubic growth of your universe with dimensions, making the development of sandboxes a rather larger effort. Applying the OTU's assumptions about communication to make a 3D Imperium of the same dimensions would result is a very large region of space with millions of stars. While a published sandbox on that scale would be totally awesome, it wouldn't be practical to build through anything but procedurally generated content. At that point you might as well just go and play No Mans Sky or Elite: Dangerous.

You can't layer "The Imperium" on to such a structure, not the canonical at least, since the Imperium is the Imperium partly because of the structure of the 2D map. The Imperium has actual borders.

Other than that, going to a lower distribution of planets, along with a longer jump (say J1 is 3 parsecs instead of 1 parsec, or something similar) can counter the cubic complexity issue, making the differences a wash.

But trying to get the higher level Imperial dynamic in to such a sphere, is less practical. It can be inspired to be sure "Look! We have Dukes!" but the history itself is quite different.

What would the Spinward Marches volume be like?
 
You can't layer "The Imperium" on to such a structure, not the canonical at least, since the Imperium is the Imperium partly because of the structure of the 2D map. The Imperium has actual borders.

Other than that, going to a lower distribution of planets, along with a longer jump (say J1 is 3 parsecs instead of 1 parsec, or something similar) can counter the cubic complexity issue, making the differences a wash.

But trying to get the higher level Imperial dynamic in to such a sphere, is less practical. It can be inspired to be sure "Look! We have Dukes!" but the history itself is quite different.

What would the Spinward Marches volume be like?
You would have to substantially re-hash the OTU to fit it to a 3 dimensional space, which was the point of my post. Also, the cubic relationship grows, well, cubically, so it gets bigger a lot quicker than a two dimensional space. It's not just bigger, it grows at a higher rate.

Borders can exist in three dimensions, but you get back to needing CGI to visualise them. A 3 dimensional border based on power projection capability from systems (i.e. some function of jump range) would look like an agglomeration of spheres resembling Yog-Sothoth; intersections between spherical regions of influence belonging to different parties would result in lenticular regions that could be contested. If there was a system in that overlapping region then it could potentially be the subject of conflict.

Alternatively you would have to find a way to sneak a fleet into a neighbouring unihabited system and use it as a jump-off point for an attack. Keeping systems that could be used in this way patrolled to prevent this from happening would be a substantial ongoing job for the Navy.

A 40x32x40 sector would be around 50,000 cubic parsecs and a subsector around 800. For 26 systems per subsector you would have about 30 cubic parsecs per world, or an average of J3-4 between sytems. To fit the same number of worlds (about 400) into the sector, you would have about 6.5 systems per subsector, or about 1 per 120 cubic parsecs, averaging 5-7 parsecs parsecs apart.
 
Last edited:
I'm working on doing that right now. For my map, I'm using randomly generated stars, with a density of about 0.095 solar systems (some of which have multiple stars) per cubic parsec, which is roughly what it is within 5 parsecs of Earth. A subsector is 8 x 8 x 8 parsecs, and a sector is 4 x 4 x 4 subsectors.

I'm generating the systems physical data using modified 2300 rules, but then using MgT for population, government, law & tech level. Much of the work is done using Filemaker Pro, including calculating the distances between nearby systems.

I'm doing this because I want a harder science feel in my next campaign, so I've also decided there is no grav tech, FTL uses stutterwarp instead of jump drive (although with an 8.15 ly limit instead of 7.7), and there are no aliens with comparable technology.
 
I'm working on doing that right now. For my map, I'm using randomly generated stars, with a density of about 0.095 solar systems (some of which have multiple stars) per cubic parsec, which is roughly what it is within 5 parsecs of Earth. A subsector is 8 x 8 x 8 parsecs, and a sector is 4 x 4 x 4 subsectors.

I'm generating the systems physical data using modified 2300 rules, but then using MgT for population, government, law & tech level. Much of the work is done using Filemaker Pro, including calculating the distances between nearby systems.

I'm doing this because I want a harder science feel in my next campaign, so I've also decided there is no grav tech, FTL uses stutterwarp instead of jump drive (although with an 8.15 ly limit instead of 7.7), and there are no aliens with comparable technology.
I got a subsector map for you, it is in my Andromeda Sector and its 8 parsecs thick, 8 parsecs wide and 10 parsecs long.

https://www.deviantart.com/tomkalbfus/art/Subsector-Gaia-871279682

Subsector-Gaia-871279682


The two images are viewed from 2 different angles just in case some stars are in front of others. Each sector consists of 16 subsectors just like in standardTraveller, and each subsector has on average 40 star systems rolling 6d12 will get you in that ball park, then you roll 1d8 for the first two digits of the hex number, 1d10 for the second two digits and 1d8 for the vertical number or layer. I find it's not worth going more 3 dimensional than that.
 
I'm doing this because I want a harder science feel in my next campaign, so I've also decided there is no grav tech, FTL uses stutterwarp instead of jump drive (although with an 8.15 ly limit instead of 7.7), and there are no aliens with comparable technology.

So, no Imperium-threatening aliens?
 
No, and no Imperium either, although there have been many small empires (none covering more than about 100 worlds). There are some human groups that have undergone DNAm treatments resulting, in some cases, in new human species.
Well in the Andromeda Sector, there is no Imperium either, FTL travel is only 26 years old and Interstellar nations haven't had much time to develop yet.
 
No, and no Imperium either, although there have been many small empires (none covering more than about 100 worlds). There are some human groups that have undergone DNAm treatments resulting, in some cases, in new human species.

Really interested to hear about your setting and progress on this.

Contrary to what most people seem to think, 3D mapping using an app is no harder than traditional 2D hexmap, at least in my experience. I have used Astrosynthesis.

It lends itself to a "points of light" setting i.e. only a small percentage (the most desirable) of systems are inhabited, possibly meaning jumps through uninhabited systems for low-jump vessels. Do you jump through the obvious connecting system with the gas giant outside the star's jump mask, that is below 1G so nice and easy to refuel at... given that is where the pirates are going to hang out? Or go a less obvious way round?

It does mean effectively junking the 3I/OTU, or rewriting it so heavily that you might as well start from scratch, but that is no problem as far as I'm concerned.
 
As a description of 3-D empires and space wars, I've often enjoyed "In Clouds of Glory", a novelette by Algis Budrys (1955):

Farla was a cluster of stars shaped like a badly pitted furnace clinker. Adjoining it on the side away from Earth—which he represented by a contemptuous, zero-shaped speck at the foot of the board—was Marak, with its stars grouped like a rat’s head, sniffing at the clinker. To Farla’s right, Genis and her stars were a twisted, mold-eaten orange peel. Working quickly, he sketched in the profile view, which included such scattered breadcrumbs as Ruga, Dilpo, and Stain, all inextricably jumbled in by the fact that stars, unfortunately for diagramatics, occupied three dimensions, were anything but stationary, and were governed by countless dozens of little pocket empires that had seized in any and all possible directions once the Vilk yolk was taken off them.

The pure white stars, he thought—the pure white stars live in a garbage heap.

and so on!
 
Interesting. Are all the inhabited planets newly settled, or were they colonized by STL?

The sector has its own native races, which I borrowed from D20 future, StarDrive, and Star Frontiers, since its a T20 game I can use them all. There are native humans as well, they are very primitive, the Ancients transported some Cromagnons and Neanderthals to an Earthlike planet and they remained at a stone age level of development until contacted by modern human colonists sent over by the Imperium. Since they arrived by one-way intergalactic jumpgate, the Imperium cannot control this place so the colonists are on their own, they brought with them jump technology, something the native races of this sector did not have, they instead ruled individual systems and traveled by slower than light maneuver drives.
 
This subsector generation uses 1 parsec hexoids which stack.
Each layer is offset to nestle on the layer below in a close pack structure, .75 pc vertical separation.
Layers 2 apart are exactly above each other.

A A
B
A

On a layer, it is a nomal hex close pack, with the second column descended

111 131

121

Hex numbering generally starts from the lower spinward coreward location.
2 digits suffice for a sector of 8 subsectors (2x2x2) which is roughly a
cuboid 13.5x12x13.9 parsecs in size, 2245 cubic parsecs.
(ranging from 1 to 18 in Z (layers), 1 to 12 in X (columns), and 1 to 16 in Y (rows))
This gives each 3hex a volume of 0.65 cubic parsecs.

The 9x6x8 subsector is over 5 times larger than the 8x10 subsector, and will have
many more trade routes.

A Traveller subsector is 80 hexes with a maximum distance of 11 parsecs.
This style of subsector is 432 hexoids with a maximum distance of 11 parsecs.

A Traveller sector is 1280 hexes with a maximum distance of 47 Parsecs.
This style of sector (8 subsectors) is 3456 hexoids with a maximum distance of 23 parsecs.

Presenting it to players is simply the layers' maps. Layers would go "down" with higher numbers to conform to 1,1,1 being the upper left top cell.
 
I have had no problems running games with a 3D map:
 

Attachments

  • Old Earth Main small.png
    Old Earth Main small.png
    728.1 KB · Views: 26
This subsector generation uses 1 parsec hexoids which stack.
Each layer is offset to nestle on the layer below in a close pack structure, .75 pc vertical separation.
Layers 2 apart are exactly above each other.

A A
B
A

On a layer, it is a nomal hex close pack, with the second column descended

111 131

121

Hex numbering generally starts from the lower spinward coreward location.
Note that a canon flat J-space world connects to 6 adjacent hexes, while the offset connects to 12 (3 up, 3 down, 6 on same level; the standard rates will result in a lot more density. Twice the trade flow potential.

Note that the odds of an adjacent world are, at standard density (50%). (Using anydice, see the AD line for the used AnyDice coding)
NadjPercent, 2-dim, 1d for 4+Percent, 3-dim, 1d for 4+Percent, 3-dim, 1d for5+Percent, 3-dim, 1d for 6
01.56 0.020.7711.22
19.38 0.294.6226.92
223.44 1.6112.7229.61
331.25 5.3721.2019.74
423.4412.08 23.848.88
59.3819.34 19.082.84
61.5622.5611.130.66
7Not Possible19.344.770.11
8Not Possible12.081.490.01
9Not Possible5.370.33Below Rounding
10Not Possible1.610.05Below Rounding
11Not Possible0.29Below RoundingBelow Rounding
12Not Possible0.02Below RoundingBelow Rounding
AD:output 6d{0,0,0,1,1,1}output 12d{0,0,0,1,1,1}output 12d{0,0,0,0,1,1}output 12d{0,0,0,0,0,1}
Median3 worlds6 worlds4 worlds2 worlds

Going from 8×10×1 = 80 hexes and typically 40 worlds in a subsector, to, oh, say a 6×6×6 for 216 hexes and 108, 72 of them, or 36 of them as a subsector is a huge change -
Option 1 is the hexes about 2.5× the worlds, most of the subsector on mains, and probably a lot more trade.
Option 2 is about 1.7× the worlds, but still really good odds of mains. A bit better than the odds in 2d, simply because of the way the staggered hexgrids connect vertically.
Option 3 is about the same number of worlds (a few less, actually), but much reduced chance of mains...

Using other sizes of dice makes for better nuance, but may violate some people's concepts of Traveller as a ruleset.
 
I have yet to see a good generic algorithm for placing stars in free-form 3D. It's simple to randomize positions starting from a fixed origin, or within a large predefined block of space. I would like to procedurally assign a randomized volume to each star system and have a way to generate a neighbor based on volume and directional limits. Just a thought.
 
The 3D mapping system I've been imagining uses the T5 World Hex map rather than the standard 8x10 subsector hex map. Each layer has 75 hexes. 10 layers define a sector, so 750 spaces per sector. The layers are alternately offset to get hexagonal close packing. I've imagined larger scale maps using the T5 Terrain Hex map to make maps in a similar way to show where the various sectors are. You can continue recursively to get higher scales. This happily corresponds with the higher order drives of T5.

I think to make density come out right, you need to cut the standard value in half, so just roll an extra die for 3- to confirm presence.

To keep the scale manageable, the game I've been thinking about would be heavily on the exploration and expansion side of the spectrum, initially with only Jump-1 available so less of the map is needed initially. I'm thinking I can start with a Core sector plus the 12 adjacent sectors. I can name them after the zodiac, for shades of Battlestar Galactica.

I have in mind to define some broad parameters for each of the sectors. Density of course, but one sector will be a nebula with an OB association (so gets a -1 on the star type roll). There will also be at least one rift sector. I also like the alternate starport tables from Megatraveller and TNE. Core Sector uses the standard table but all the outlying areas are backwater.

If density is on average standard, there are 2400 systems to play with, which should be plenty of elbow room. Communication time is less than for the Imperium since the entire area is only 15pc in radius, but at Jump-1 that's still 30 weeks at typical merchant speeds.
 
Do you have a different map for NAFAL travel between the stars, or do you just disallow it completely?
The fuel rates in CT, MT, or MGT make NAFAL pretty much impossible without bending the minimum power plant rules.

Lets' look at a 1000 Td design, using Bk5 formulae... The minimum plant required is PP 1.
Td​
MCr​
Item​
Rating
1000​
100​
Hull​
20​
500​
Bridge​
10​
15​
Maneuver​
1G
30​
90​
Powerplant TL 9​
1
1​
2​
Model 1​
1
Crew 10​
P N E M C X AAA +1
40​
5​
Staterooms ×10​
890​
0​
Fuel​
89 months. = 6 years and 11 months imperial.
9​
0​
Payload​
9 tons cargo.
712total
Note that one can pull that down - the average distance between stars is (per google) 5 LY... This is about the limit of a 1G hull.
Note also: the crew are getting majorly irradiated, unless one figures the (specified in Beltstrike) force field prevents interstellar medium from becoming abrasive.
Note that the drive will become pretty much dead by the end of year three...
why? Annual maintenance and the drive failure rule.
Weekly failure check: 13+, DM+1 if unrefined fuel, DM+1 per month past AM.
So... assuming refined fuel. Breaking out the HP calculator
Months (13/year in canon)Weekly Roll fail onCum chance of failure by end of month.formula
1 to 13¾no failure possible
14 -- 14¾Nat 12 (1/36)10.66%1-{(35/36)^4}
15 -- 15¾Nat 11+ (3/36)36.92%1-{((35/36)^4)*((33/36)^4)}
16 -- 16¾Nat 10+ (6/36)69.58%1-{((35/36)^4)*((33/36)^4)*((30/36)^4)}
17 -- 17¾Nat 9+ (10/36)91.72%1-{((35/36)^4)*((33/36)^4)*((30/36)^4)*((26/36)^4)}
18 -- 18¾Nat 8+ (15/36)99.04%1-{((35/36)^4)*((33/36)^4)*((30/36)^4)*((26/36)^4)*((21/36)^4)}
19 -- 19¾Nat 7+ (21/36)99.97%1-{((35/36)^4)*((33/36)^4)*((30/36)^4)*((26/36)^4)*((21/36)^4)*((15/36)^4)}
So, by the end of year two, we're into winning the multistate powerball solo with a full match to all balls drawn.
Now... ways to tweak this...
If we assume a non-operating drive doesn't need annual maintenance (which I wouldn't normally concede), we can get 14 months per drive, at a penalty of 40 tons per set of spares. Being a pretty picayune rules monger, I'd also require the computer have a backup, same reason. So, 41 tons per year for semi-mothballed drives.
Oh, and those staterooms only include one month's food storage. Each ton of cargo is 2000 person days. 49 years worth. (Best of JTAS p 30)
 
Back
Top