a 3D Traveller universe

[steve98052]

This is from the "Future Traveller - Suggestions Appreciated" topic, page 2, but since I'm mostly not writing in favor of this as a future Traveller suggestion I'm replying in a new message.

* I'd like to see the old and broken hex map replaced by 3D star map, perhaps based on a 3D subsector size so it's relatively manageable. I don't think this is beyond modern tablets or even smartphones. Just like a series of dots that spin around a single point to simulate being 3D with links showing the jump number to get to the nearest systems. The 2D paper hex map was the best solution they could come up with in 1976 because of technology limits. It's 2013 now. We're not Vilani. People may not like this, but really they probably wouldn't buy the app anyway.

For people who want to create their own Traveller universes, this would be wonderful. If someone (Mongoose or other) were to publish an alternate "official" universe, this would also be wonderful.

However, we have a very detailed Traveller universe that was built around the 2D map -- and putting that into a 3D map isn't practical. If we could send a 3D mapping application that could run on every kind of computer available in the late 1970s back in time to GDW, we might have a 3D Traveller universe. Unfortunately, we do not, so we're stuck with a choice between 3D maps and a huge volume of reference materials.

If it were possible, it would be nice to thicken the published universe into a 3D space of some sort. However, the Milky Way is some 300 parsecs thick, with a stellar density of about 0.14 stars per cubic parsec in the vicinity of the Sun. At that stellar density, the 11k worlds of the Third Imperium would fit into a cube 43 parsecs on a side, which doesn't allow for nearly the communications lag we find in the published universe (which measures about 220×200 parsecs).

Retaining the published universe history while expanding into a third dimension would vastly increase the number of worlds found in a region that's a year across by Jump-4 xboat. A 200×200×200 parsec space with 0.14 stars per cubic parsec would be 1.12 million stars (though fewer systems, because many stars are part of binary or multiple systems). That's not practical, even with software.

Sure, software could manage a million systems, but just naming all of them would be a huge creative undertaking for players or game designers. Developing planetary profiles for all those systems' main words would be an even larger job, because even if the planetary statistics were filled in by an automatic world generator they'd just be a million statistical descriptions of worlds.

Additionally, maintaining some of the notable aspects of the published universe -- the existence of some important Jump-1 "mains", the gap that formed the natural boundary between the Vilani Imperium and Earth during the Interstellar Wars, etc. -- would take a lot of manual tinkering.

If I were to invent a new universe that was meant to be 3D, the way I'd do it would be to take the Hipparcos, Tycho, or Tycho 2 catalog as the list of stars, and auto-generate worlds for each of the catalog's stars, with a generator that leaves most systems empty of worlds that are worth visiting, and possibly adjust jump rules to put just a few interesting worlds into range of Jump-1, somewhat more in range of Jump-2, etc. It wouldn't have the same feel as 2D Traveller, because the number of systems a ship can reach is proportional to the square of its jump range in 2D, but proportional to the cube of its jump range in 3D.

What about galactic directions? In 2D Traveller, we have a coreward-and-rimward axis and a spinward-and-trailing axis. What would we call the third axis in 3D Traveller? One idea I had was "left" and "right", defined from the point of view of a person facing spinward, with feet pointing coreward. Another possibility would be to use standard galactic north (toward Coma Bernices) and south (toward Sculptor), combined with the coreward-rimward and spinward-trailing system. Yet another would to use a standard galactic coordinate system.

 

[simonh]

If I were to invent a new universe that was meant to be 3D, the way I'd do it would be to take the Hipparcos, Tycho, or Tycho 2 catalog as the list of stars,...

Traveller 2300 already takes this approach and already exists, so it's clearly a viable approach. There are a few caveats though.

The real stellar data for local space actually peters out fairly quickly. Stars are, like anything else, harder to detect the further away they are and so the data gets more and more sparse, less accurate and selects for bigger and brighter stars, the further away you get. It's not so much that you can't find the stars, it's that it becomes very difficult to determine how far away they are. Parallax and all that.

To compensate for this you'd need to seed the data with randomly generated small stars, with a probability function that makes them more frequent with distance. This has actually been done before, I've seen posts by people who did it, but it's not a simple process and of course means you're not using 'real' data anymore.

The other problem, which may or may not be an issue depending on the kind of setting you want, is that the size of the setting in terms of number of worlds grows with the cube of it's lateral dimensions, not the square. On a 3D mapping system you can pack in all the hexes, empty or not, in the traditional Traveller setting map into a cube about 52 parsecs on a side, so each layer would be the size of 2 sectors. The Imperium itself would only be 30 parsecs across.

Al those rifts and voids would functionally disappear. You could get round it by makign space a lot more sparse, but that makes mapping out the 3D space in a comprehensible way even harder. It radically alters the dynamics of a setting. It's not that you can't do it, it's that all the assumptions and tradeoffs that go into the Traveller mapping, economic and technological choices go right out the window. This is one reason why T2300 is a very different game.

Simon Hibbs

 

[Reynard]

Many years ago, I wanted a Traveller campaign based on the real world after seeing how the 2D version of the Sol subsector highly distorted the actual stars. At this time 2300AD was out and the Star List was perfect. (GET 2300AD!!) I transferred the coordinates of all the star systems to a spreadsheet program and had it calculate distances between every system then calculated Jump distances. Then I hand drew a 3D map of the systems out to about 4 parsecs from Sol which I put on the MTG aides yahoo group. Whew! I can tell you Jump is less efficient without all stars in perfect one parsec distances. Explains use of 2300's stutterwarp. Compared to a 2D map, it is a LOT of work.

For random creation, there's is source material for the old TSR Alternity game system - Alternity Cosmos II - that addresses creating a very detailed 3D universe including the possibility of brown dwarves dotting the space between stars. It uses a 12x12x12 parsec cube with each cube 3x3x3 Lys capable of holding more than one star. Remember, you will need the formula for finding distances between to 3D points to determine Jump distances. I like it to place stars then use the Traveller system to create the system within.

 

[darue]

fork EVE and do a total conversion

but seriously, they got the 3d space map working great

 

[ShawnDriscoll]

Get's out his SPI Universe map.

 

[darue]

Get's out his SPI Universe map.

wow, I'd never even heard of that :shock:

this is a useful site:
http://www.projectrho.com/public_html/starmaps/

 

[Traveller-61]

Get's out his SPI Universe map.

wow, I'd never even heard of that :shock:
http://www.projectrho.com/public_html/starmaps/

Now that is going back a bit; I remember the map well (and think I have one somewhere, in the depths of the vaults...), but not so much the game :lol:

DW

 

[ShawnDriscoll]

Remember, you will need the formula for finding distances between to 3D points to determine Jump distances. I like it to place stars then use the Traveller system to create the system within.

DIST = SQRT[ (X1-X2)^2 + (Y1-Y2)^2 + (Z1-Z2)^2 ]

 

[simonh]

fork EVE and do a total conversion

but seriously, they got the 3d space map working great

There's also Astrosynthesis, which I've heard good things about, but the problem with software based solutions is how do you use them conveniently and effectively as a group at the gaming table?

When someone comes out with a 3D mapping solution optimized for large format tablets, then we might be getting somewhere, but even then it's much more complex solution that paper.

It comes down to the time it takes to analyse and comprehend the data, and how parallelisable that is across the group. With a paper map and say a j-3 ship you have 36 hexes as possible destinations. In 3D that’s roughly 170* cubic parsecs or 5 times the number of options, across a much more complex geometry. With paper the whole group can look at the same map at the same time. With 3D you really need software, which means interactively exploring the data set from multiple views. Unless you have multiple copies of the software and devices, the players are going to need to do that individually, or at most in groups of 2 or maybe 3 max.

So let’s say the volume of space is 5x as big (much bigger for higher jump numbers), the complexity of 3D doubles the complexity of analysing the available options (I think that’s being very generous), and a group of 6 players can use the software on one device in pairs. That’s about 30x the work to give everyone a chance to understand the available options. I think that’s a fairly lowball estimate too. Given the exponential nature of going 3D even a small increase in jump distance, complexity of user interface, etc will balloon that number very rapidly.

I know 2300 dealt with this, but their solution was to fiddle the technology assumptions so you didn’t have to actually use 3D navigation hardly at all. In practice the carefully chosen tech assumptions in stutterwarp limiting it’s range, mean that travel can only be conducted along branching routes known as ‘arms’, that can be conveniently represented in 2D on paper.

Remember, you will need the formula for finding distances between to 3D points to determine Jump distances. I like it to place stars then use the Traveller system to create the system within.

DIST = SQRT[ (X1-X2)^2 + (Y1-Y2)^2 + (Z1-Z2)^2 ]

Sure, but would be nice if the player playing the astrogator in my gaming group didn't actually have to be a qualified astrogator in real life in order to be able to play their character.

Simon Hibbs

* Bear in mind, a range of 3 parsecs is actually more like a range of 3.5 parsecs for area and volume calculations. If you don’t believe me, work out the area of circles with radius 3 and radius 3.5 and see which is closer to the actual area coverable by a J-3 ship on a hex grid.

 

[steve98052]

I knew about 2300 AD. I even had a copy of the old version, when it was titled Traveller 2300. Its map was limited by the knowledge of astronomy in its era. Hipparcos and Tycho are much more detailed.

 

[ShawnDriscoll]

Remember, you will need the formula for finding distances between to 3D points to determine Jump distances. I like it to place stars then use the Traveller system to create the system within.

DIST = SQRT[ (X1-X2)^2 + (Y1-Y2)^2 + (Z1-Z2)^2 ]

Sure, but would be nice if the player playing the astrogator in my gaming group didn't actually have to be a qualified astrogator in real life in order to be able to play their character.

I've never actually used it in game, Traveller or Universe. The equation is just shown as a prop for looks on an astrogation console. I've used it before game when figuring out distances to systems the players might go to in the next session. Traveller had its own 2D version of that formula. But it wasn't used for stars. It was used more for ship distances, depending on the orbital map system used. And even then, we didn't use the math. It was just for Hollywood looks on a NAV screen. See Discovery's COM, NAV, and ENG screens in 2001: a Space Odyssey. Luckily, I didn't play with guys that stopped our games to argue about math problems.

 

[AndrewW]

With paper the whole group can look at the same map at the same time. With 3D you really need software, which means interactively exploring the data set from multiple views. Unless you have multiple copies of the software and devices, the players are going to need to do that individually, or at most in groups of 2 or maybe 3 max.

If you can hook up to an external display though, maybe a projector, there are some small ones that would be easy to take along with the displaying device.

 

[Reynard]

And we see why a 3D map becomes unwieldy. Best to have a table for distances in your campaign and give needed information when asked for or, since it would be available in a library, let the players look.

 

[simonh]

With paper the whole group can look at the same map at the same time. With 3D you really need software, which means interactively exploring the data set from multiple views. Unless you have multiple copies of the software and devices, the players are going to need to do that individually, or at most in groups of 2 or maybe 3 max.

If you can hook up to an external display though, maybe a projector, there are some small ones that would be easy to take along with the displaying device.

Sure, that could work. It would be cool and immersive too, I'd play in that game. The thing is you can't publish a commecial SF roleplaying game with required components for play of paper, pencils, dice, a computer, 3D software and a wall projector.

Simon Hibbs

 

[Wil Mireu]

You don't need a projector, you can use a tablet or a laptop.

 

[rust]

When I grew tired of the 2D hex maps I designed the next setting's
background universe as a 3D universe and gave the players the
equivalent of a subway map with distances and travel times, which
in the end was all they needed to plan their ship's voyages.

 

[simonh]

You don't need a projector, you can use a tablet or a laptop.

And we're back to the beginning of the discussion again. A projector was suggested as a solution to the problem that only one or two people in a group can effectively use a single computer at a time.

Simon Hibbs

 

[High Orbit Drifter]

When I grew tired of the 2D hex maps I designed the next setting's
background universe as a 3D universe and gave the players the
equivalent of a subway map with distances and travel times, which
in the end was all they needed to plan their ship's voyages.

Even from day one of my LBBs I thought of the standard Traveller subsector map in this way. To me it was a schematic of star systems, not an actual map. I've been shouted down when I bring this up as remotely related to the Official/Old TU. Specifically the links between areas such as the Islands cluster, that imply, for some reason, a very direct relationship between the map and reality.

In MTU the 2d hex map has a correlation to real distances, but only for local stars. Anything beyond a half dozen parsec or so is only a very general spatial relationship. Stars systems next door to each other are about a parsec apart, sometimes more, sometimes less, but it does take a jump drive to get from one to the other. Otherwise its the subway map.

 

[darue]

yeah. There has to be other stars, not on the map. only stars with some fuel source are listed is my theory. Military forces can maintain huge fuel depots at locations on the map with no apparent star/mainworld. It may even have a sun, but for some reason no hydrogen gas giants (or gas giant far too close to their sun to scoop from) or other sources of water/hydrogen.

 

[Reynard]

In my real space creation, Epsilon eridani is an important world because it was the second contacted alien race. Problem is it is 3 parsecs away and ships at the time period were maximum J-2 so the 1-2 Jump routes take many weeks to get there. Besides contact, it was determined E. eridani was an ideal location to access the denser star population so a deep space fueling depot was built one jump from Sol. and the savings would be tremendous for commerce and exploration.

Depots can be useful for bridging gaps hindering lower Jump ships.