Big Imperium - Or Traveller 3D

[JustinInOz]

2D to 3D Conversion

G'Day,

If it is of any interest, I have set up a spreaddy that takes a set of 2D coordinates and converts this to a set of 3D coordinates but preserves the relationships between the 2D points.

This allows to keeps the routes and distances between near systems as they were but the whole thing now exists in 3D space.

If you send me a subsector, I would be happy to covert it for you. The conversion goes on the following jump distance assumption:

Jump-1 7.3 ly
Jump-2 10.2 ly
Jump-3 12.8 ly
Jump-4 15.1 ly
Jump-5 17.2 ly
Jump-6 19.2 ly

This keeps the same number of available jump destinations in 2D space per Jump number for 3D space.

It uses a linear program to minimise the differences in distances between the subsector stars 2D and 3D.

Where it becomes more interesting is between subsectors in a sector. Instead of having 8 neighbouring subsectors, you now have 12. This difference is what makes the borders more porous. Also the jump distance conversion works perfectly for the each jump. It breaks down when you string a series of jumps one after another. If there is a gap in the route that you can not jump enough to cross, then that route is still closed to you.

But if you look, 3 Jump-1s cover a greater distance than 1 Jump-6. So in the long haul the lowest jump numbers will not be as bad as they are in the 2D universe. Jump-6 will still have great route selection though. The poor route selection of Jump-1 will erode this greater efficiency.

 

[Kilgs]

There's a very cool 3d subsector map in the file section. All you people and your math... just breathe and embrace the imagination!

 

[ShapeShifter]

Star Probe seems to handle 3D space pretty well, but it's OOP.

 

[Sifu Blackirish]

Another difficulty is that, even more so than with 2D maps and high jump starships, is that there is no easily defended border. Sort of takes the fun out of having border patrol characters, doesn't it?

BTW, has anyone taken RL star locations and mashed them into 2D? I remember doing that with the old StarForce SPI map many, many years ago, but that data fell into the abyss several moves ago... I have no idea how accurate it was, if at all...

Besides, as big as Charted Space is, what referee wants to deal with 10 to 100 times the volume? Ouch!

 

[Ishmael]

I use a 10x10x10 cube as a subsector and draw it out like an isometric 3d graph from grade school math ( maybe I should go through the effort of drawing it out in perspective someday). Placing a world at each location on a 2d6 "12" is good enough for me. But then again, I only fool with 2 subsectors in a thoroughly non-OTU Islands Campaign.

Jump and fuel use are as per normal rules with the exception that I use mass instead of displacement to determine performance and I keep one decimal place. Jump distances are as per the usual distance formula in 3d.

I seriously doubt that this would be workable in a universe as large as the OTU.

 

[Max]

Besides, as big as Charted Space is, what referee wants to deal with 10 to 100 times the volume? Ouch!

!0-100 times? I wish. I ran a 3D campaign for a while until it became unmanageable. Even with a computer generating the systems in a sphere 10 parsecs from where the players wound up there became too many worlds to keep track of in no time.

For way of comparison, if we reduce the probability of suns to 1 per 3 cubic parsecs (which will increase by a factor of about 4 the number or worlds without a jump-1 connection) The "10,000 suns" of the 3I would fit in a sphere with a radius a little over 30 parsecs. A jump 6 ship could travel from any part of the Imperium to any other in 11 jumps or less and no world would be more than 6 jumps away from the center.


Ishmael, 1 in 36 doesn't produce an unworkable number of worlds but doesn't it produce a large number of isolated worlds? Useful with an Islands campaign but not a general one. While toying with the idea of creating another 3D universe I produced this comparison (assuming a 3D taxicab geometry) of number of planet locations to hex based:

• 7 7
• 19 25
• 37 63
• 61 129
• 91 231
• 127 377

Figure the average jump you want to be used and calculate probability of system occurrence to produce similar results to a 50% hex based density and your universe will have a localized flavor similar to that of the 2D system. At jump-1 there are the same number of possible world locations but at jump 4 there are over twice as many possible locations then a 22% chance would produce a similar number of systems within range.

 

[Frankymole]

3D space, mapping, travel...

The famous White Dwarf article solves the trig and mapping "problems"... and some reference to real densities give some elegant results when system presence is determined with three dice (3D!)...

http://img.villagephotos.com/p/2007-1/1238587/3D space.jpg

http://img.villagephotos.com/p/2007-1/1238587/3D system densities.jpg

 

[robject]

The famous White Dwarf article solves the trig and mapping "problems"... and some reference to real densities give some elegant results when system presence is determined with three dice (3D!)...

http://img.villagephotos.com/p/2007-1/1238587/3D space.jpg

http://img.villagephotos.com/p/2007-1/1238587/3D system densities.jpg

Clever solution!

The most important thing to take from that article is that systems have a "layer number" showing what their relative depth is.

Perhaps a simplification can be made that preserves the hex data we currently expect:

• Use the subsector as the map basis, as done in the WD article.
• Only allow one system per hex column, and require a layer number, default 0, from -4 to +4.
• Assume that, even though two systems never show up in the "same" hex, they may nevertheless be closer than they appear on the map.
• This disposes of the need for trigonometry, and in fact warps the map slightly at the extreme distances.
• Distance between layers is the difference between layers plus the "2D" distance.

Total cubic hexes is 10 x 8 x 9 = 720. Assuming nearly every "hex" will be filled, we'll still have a very sparse map. You might have to rule that hexes are approx. 1 light year; so jump drives move three hexes per jump rating. Alternately, if you randomly assign layers using 2D-7 (producing a range from -5 to +5), you'll get a natural distribution off the center plane, and you probably wouldn't have to fiddle with jump distances. A side benefit is that you'll have hard-to-reach systems at the extreme planes.

 

[flykiller]

It's not at all easy to do for any significant scale.

sure it is. start with a standard hex map, put a system in almost every hex, then calculate how far in "hexes" above or below the plane the system is located ...

2d6
2-11, system
12, no system

2d6
2 -5
3 -4
4 -3
5 -2
6 -1
7 0
8 1
9 2
10 3
11 4
12 5

and mark it on the map. and the "trig" is easy - just use the pythagorean theorem. three hexes over, two hexes up, means four hexes away. if you jump enough to be bothered by the calculation you'll soon wind up memorizing all of the possibilities anyway.

started doing this but realized it added nothing to my game so dropped it and stuck with the lbb depiction.

 

[Greylond]

I'm just now coming back to Traveller after many years of not playing SciFi games. Personally, I like 3D maps and I'm going to be looking at it for when I get around to running a game again. Figuring distances and stuff isn't that hard, considering that there's multiple computers at my gaming table every week. We're down a couple but last year we had 7 laptops at a table with 8 people, so I really don't forsee a problem with that.

 

[robject]

sure it is. start with a standard hex map, put a system in almost every hex, then calculate how far in "hexes" above or below the plane the system is located ...
[...]
and mark it on the map. and the "trig" is easy - just use the pythagorean theorem. three hexes over, two hexes up, means four hexes away. if you jump enough to be bothered by the calculation you'll soon wind up memorizing all of the possibilities anyway.

started doing this but realized it added nothing to my game so dropped it and stuck with the lbb depiction.

There is one potential nice thing: if you have 3D modeling software, you'd be able to show a subsector as a 3D model. And if it changes very little of the game, you've got a win-win.

This is almost equivalent to just running the subsector through a hopfield- or kohonen-like network until you get a low entropy in 3D space with the flat 2D map, and just displaying that.

 

[Mark Morgan]

well if you want to play arround Sol and have access to SPI stuff Starforce AC and their universe games had detailed starmaps out about 30 ly wihchi might be usefull at least if I recal correctly

 

[Frankymole]

GDW's "2300AD" (formerly known as "Traveller 2300") also had a 3D star catalogue (the "Near Star List") out to about 50ly/15 parsecs (i.e. a sphere of 15,090 cubic parsecs). There's an excellent project online to list its errata and update it - I'm not sure of its accuracy, since Sol is listed as spectral class G1!

I think it used RA/declination coordinates to create its X/Y/Z axes, but these aren't hard to convert to Galactic coordinates (for Coreward/Spinward etc orientation). There are some words from Marc about its creation here: http://home.earthlink.net/~ad2300/t2300dn2.htm#TNSL&MITT

I like the idea above of making subsectors 8 x 9 x 10 parsecs; this means the standard hex reference number can simply have a decimal 1 to 9 added at the end to indicate a system's "height" or galactic north/south (z axis) location.

Finally check this out - especially the free downloadable maps:
http://www.projectrho.com/smap12.html#rest

 

[Frankymole]

Well I've been converting real star data into Traveller "Spinward/Coreward" etc terms, with the actual 3rd dimension ("inward" and "outward" from the paper, or the galactic plane!), so far I've done the 50 nearest systems to Sol in both hex-map/(sub)sector map and catalogue form.

Some swish graphics and fonts and the 3D Solomani Rim campaign will be ready to roll!

Doing some further bright stars too (like Deneb, Canopus etc - helps with sector placement).

UPDATE: So far I've converted all known real stars out to 17ly distance from Terra/Sol, 76 stars in 53 systems; I've even recalculated the positions of fast-moving stars to where they will be in Imperial year 1105.

The map's in development, preview here:

The codes merely refer to my spreadsheet where the names and other details reside - they progress from the (current) nearest stars outwards (e.g. '1A' is Proxima Centauri, '1B/C' are Alpha and Beta Centauri, '1D' is Barnard's Star where it will be in 5628AD, etc. The bright Sirius is marked in blue ('1G/H'), and the white star just poking on to rimward is Procyon and its white dwarf companion...). There will eventually be hex reference numbers and +/- coordinates to show distance above and below the 'plane' of the map.

For instance, '1W' is Tau Ceti which is actually 3.5 hexes 'below' the plane that Sol is on, and thus requires Jump-4 to reach...

The blue line is the subsector border.