3d Traveller subsector map

[Tom Kalbfus]

Here is a map showing distances between Traveller worlds, in this map each component of multi-star systems have their own main world, something that is not possible to show on a standard 2d Traveller map, the UWP Code is also at the bottom of the Hex, the 3d coordinates is also the label of the parsec cube. The big numbers on the table show the distance between star systems in parsecs.

 

[tolcreator]

3D maps are a windmill I have tilted at from time to time over the years... and so I'm very harsh on them

The problems I have with your map:
1) Not sure if intentional or not, you don't show the actual map, despite the evovative 3D grid in the corner.

2) Very hard (and to be honest, this would be true, tho to a lesser extent, even if you had included the map) to tell the structure of the subsector, i.e., which worlds form chains, where there are big gaps/rifts, what worlds are chokepoints.

3) just giving a list like this is probably the best method of doing a 3D map. However:
Your subsector is very sparse. Out of 512 cubic parsecs, you have only 12 systems. And this is reflected in how scattered your worlds are: There are only 3 groups of worlds 1 parsec from each other, that I can see. A more realistic density would be 1/10, which would give you 51 or so systems... and then your list grows very cumbersome.

In short: Providing a list of jump distances is probably the best way of doing a 3D map. It allows the players who are at system A, work out what's within range. However, it very quickly falls down when they begin to think about "Ok, we're here... what's the quickest way to get to here?" This is pretty trivial on a 2D hex map, harder when you might have to trial and error a few routes.

If you do actually draw the map, it might be an idea to draw in jump-1 and jump-2 links (computer help here a must).

 

[Tom Kalbfus]

The problem with actual 3-d maps is certain objects are in front of others, the purpose of Traveller maps is to provide information about each system within each hex and also show the relation of each system relative to other systems. I could not draw a 3-d map and show much more than a dot, a slightly larger dot for the systems that are closer to the viewer's perspective, and a small dot for those systems that are further away, I could not display UWPs on such a map, nor could I display the World size or whether they had water either, such information would clutter the 3-d map and obscure the 3-d positional relationships A list of distances is the best way I can think of, the reason there is only 12 is because if I had too many systems, the table would become too large to read, or the hexes would have to become too small to legibly read in one glance. You can assume there are a lot of systems that aren't included in this table, a 8 parsec cube is 26 light years across, The space within a 21 light year radius of Earth contains 100 systems. The chance of system presence in each cube I used was 1 in 36, so if you rolled a 2d6 and got 12 that would indicate the presence of a system in that cube. Normally on a flat traveller map the standard presence is 1 out of two hexes, about 50% of hexes in a subsector would have systems in it, but that is in a 2-d plane, it 3-d, there are more possibilities, you need a lower system presence chance in order to still have rifts, if you kept it to 1 in 2, a starship could basically travel in any direction it liked.

 

[tolcreator]

The problem with actual 3-d maps is certain objects are in front of others, the purpose of Traveller maps is to provide information about each system within each hex and also show the relation of each system relative to other systems. I could not draw a 3-d map and show much more than a dot, a slightly larger dot for the systems that are closer to the viewer's perspective, and a small dot for those systems that are further away, I could not display UWPs on such a map, nor could I display the World size or whether they had water either, such information would clutter the 3-d map and obscure the 3-d positional relationships A list of distances is the best way I can think of, the reason there is only 12 is because if I had too many systems, the table would become too large to read, or the hexes would have to become too small to legibly read in one glance.

You are quite right, from the maps I have drawn with 50 or 100 systems in them (or thousands!) they're just a great big mess. I've tried 2 main techniques:
1) Just 3D space with "free" coordinates, usually with a precision of 0.1 parsecs, and use 3D distance algorithm to get distances.
2) Use 3D hexes (which was an enlightening rabbit hole to go down itself), so you can "count hexes" like in 2D to get distances. The problem here is that you'd end up with some hexes occluded i.e. underneath others. You could try "forbidding" stacked systems but then why bother with 3D... I tried offsetting things slightly but to be honest trying to look at the map and figuring out how things connected, or where rifts were, was giving me nosebleeds.

You can assume there are a lot of systems that aren't included in this table, a 8 parsec cube is 26 light years across, The space within a 21 light year radius of Earth contains 100 systems. The chance of system presence in each cube I used was 1 in 36, so if you rolled a 2d6 and got 12 that would indicate the presence of a system in that cube. Normally on a flat traveller map the standard presence is 1 out of two hexes, about 50% of hexes in a subsector would have systems in it, but that is in a 2-d plane, it 3-d, there are more possibilities, you need a lower system presence chance in order to still have rifts, if you kept it to 1 in 2, a starship could basically travel in any direction it liked.

You have to reduce density yes, but your density is very sparse, when compared to actual space near the sun. Density there is about 1/10 systems per cubic parsec. As for not representing every system on the map... that's not something I would compromise on (and thus made a lot of pretty pictures but useless maps).

In 3D one "problem" is that you have more options when you jump. In 2D space, the number of jump destinations increases with the square of the jump number. in 2D space, it increases with the cube. One "solution" is to reduce jump numbers (the other being to call it a feature and not a bug). In most iterrations of my 3D maps, I said J1 and J2 is all there is (sometimes had J3). Mains and clusters are much rarer in 3D, even with quite high densities (1/8, 1/6), so carrying enough fuel for 2 jumps and jumping into an empty hex is a thing that will happen much more often.

 

[tolcreator]

This was my effort, using "3D hexes":

This thread explains the 3D hexes, early images are gone now:
http://forum.rpg.net/showthread.php?253382-Necro-3D-hex-maps

 

[Tom Kalbfus]

The problem with actual 3-d maps is certain objects are in front of others, the purpose of Traveller maps is to provide information about each system within each hex and also show the relation of each system relative to other systems. I could not draw a 3-d map and show much more than a dot, a slightly larger dot for the systems that are closer to the viewer's perspective, and a small dot for those systems that are further away, I could not display UWPs on such a map, nor could I display the World size or whether they had water either, such information would clutter the 3-d map and obscure the 3-d positional relationships A list of distances is the best way I can think of, the reason there is only 12 is because if I had too many systems, the table would become too large to read, or the hexes would have to become too small to legibly read in one glance.

You are quite right, from the maps I have drawn with 50 or 100 systems in them (or thousands!) they're just a great big mess. I've tried 2 main techniques:
1) Just 3D space with "free" coordinates, usually with a precision of 0.1 parsecs, and use 3D distance algorithm to get distances.
2) Use 3D hexes (which was an enlightening rabbit hole to go down itself), so you can "count hexes" like in 2D to get distances. The problem here is that you'd end up with some hexes occluded i.e. underneath others. You could try "forbidding" stacked systems but then why bother with 3D... I tried offsetting things slightly but to be honest trying to look at the map and figuring out how things connected, or where rifts were, was giving me nosebleeds.

You can assume there are a lot of systems that aren't included in this table, a 8 parsec cube is 26 light years across, The space within a 21 light year radius of Earth contains 100 systems. The chance of system presence in each cube I used was 1 in 36, so if you rolled a 2d6 and got 12 that would indicate the presence of a system in that cube. Normally on a flat traveller map the standard presence is 1 out of two hexes, about 50% of hexes in a subsector would have systems in it, but that is in a 2-d plane, it 3-d, there are more possibilities, you need a lower system presence chance in order to still have rifts, if you kept it to 1 in 2, a starship could basically travel in any direction it liked.

You have to reduce density yes, but your density is very sparse, when compared to actual space near the sun. Density there is about 1/10 systems per cubic parsec. As for not representing every system on the map... that's not something I would compromise on (and thus made a lot of pretty pictures but useless maps).

In 3D one "problem" is that you have more options when you jump. In 2D space, the number of jump destinations increases with the square of the jump number. in 2D space, it increases with the cube. One "solution" is to reduce jump numbers (the other being to call it a feature and not a bug). In most iterrations of my 3D maps, I said J1 and J2 is all there is (sometimes had J3). Mains and clusters are much rarer in 3D, even with quite high densities (1/8, 1/6), so carrying enough fuel for 2 jumps and jumping into an empty hex is a thing that will happen much more often.

In any interstellar map, you always have to leave something out. For instance if you included brown dwarfs, you would have a more crowded map. Brown dwarfs glow in the infrared, so they are detectable in interstellar space. Brown dwarfs usually have moons, some of them can be gas giants where you can refuel your starship, there are rogue planets including rogue gas giants. Most gas giants give off more energy than they receive from their primary, because of the internal heat created from the compression of their cores from initial formation. An interstellar gas giant is detectable thermally from the interstellar background with the right equipment, if you can find one, you can refuel there. A simple rogue terrestrial planet in interstellar space is very likely to be covered with a layer of ice that will include hydrogen, one can land a ship on one of those and mine the ice from the crust and extract the hydrogen with the fuel processors and store it in the fuel tanks. Just because a space is blank on the map doesn't mean that there is nothing there. Perhaps we need a rule for finding brown dwarfs, gas giants and rogue planets and comets in interstellar space. I would imagine it would take a certain amount of time and expense to detect those in interstellar space. Probably more traveled space would have a better map of what's between the stars than less traveled space.

 

[Reynard]

And this is why a wise Traveller God created the galaxy one parsec thick. Praise the Traveller God!

 

[Tom Kalbfus]

And this is why a wise Traveller God created the galaxy one parsec thick. Praise the Traveller God!

What we really need is a computer to keep track of all the star positions, we need a program to generate the mainworld stats, and the system names. Traveller is a pen and paper game, but there is no reason why a computer couldn't keep track of all the 3 dimensions, and have a user move around in the 3-d space created by the computer. I'll bet there is a way to do this. Oh yes the computer could also take a subset of this data and make a chart like I just drew showing the distances to some local stars.

 

[simonh]

And this is why a wise Traveller God created the galaxy one parsec thick. Praise the Traveller God!

Take a map of the OTU printed on A3 paper.
Scrunch it up into as complex a multi-folded sttructure as you can.
Gently open it up until all the gaps are more that 6 parsecs wide.

Voila! A 3D Map of the OTU.

Simon Hibbs

 

[Jacqual]

a 3D map on a printed sheet of paper makes my noggin hurt, I think for myself I will keep my maps on a 2D grid like they are now as nature intended lol. But yes a neat idea but to much work in my book.

 

[Tom Kalbfus]

a 3D map on a printed sheet of paper makes my noggin hurt, I think for myself I will keep my maps on a 2D grid like they are now as nature intended lol. But yes a neat idea but to much work in my book.

Put the systems on cards, and then where ever the PCs go, pull out a card where ever the dice say there is a system present, create a corridor of stars about as thick as the maximum jump range around the PCs starship. Say for instance the PCs have a scout ship with Jump 2, so you roll dice for every parsec cube out to 2 parsecs to the left, right, up and down as well as 2 parsecs ahead of the starship, then you do the diagonals, that is a box 5 parsecs by 5 parsecs by 3 parsecs (as you don't check behind as the starship has already been there), that is 75 parsec cubes, if the chance for star system presence is 10%, that is about 7 star systems, you pull out 7 cards from your deck with 7 pregenerated star systems on it and your all set. The PCs then decide which system to visit.

 

[Lord High Munchkin]

If you use 'Astrosynthesis' you can label all the routes by length in light years and dump the whole grid thing. Viewing in 3D is just a mouse movement.

 

[IanBruntlett]

a 3D map on a printed sheet of paper makes my noggin hurt, I think for myself I will keep my maps on a 2D grid like they are now as nature intended lol. But yes a neat idea but to much work in my book.

Idea - why not print the 3D map on a 3D printer?

 

[Tom Kalbfus]

a 3D map on a printed sheet of paper makes my noggin hurt, I think for myself I will keep my maps on a 2D grid like they are now as nature intended lol. But yes a neat idea but to much work in my book.

Idea - why not print the 3D map on a 3D printer?

It would be a solid block of plastic, space would be clear plastic while stars would be solid. Would be a fairly heavy map I think and labeling those dots within a clear chunk of plastic would be a challnge

 

[IanBruntlett]

I can only dream

 

[simonh]

All the true 3D mapping systems I've seen suffer from either severe scalability problems or severe usability problems.

Paper based true 3D isn't scaleable. It can work for small regions of space from 5 to 10 parsecs across, but as soon as you try to go beyond that it breaks down quickly. Computer based 3D mapping solves the scalability problem, but how do you work with the software as a group at the gaming table?

There are semi-3D approaches that could work. One is to make a slight modification to traditional Traveller maps so that hexes with worlds have an optional +/-N value showing that the world is up to 5 parsecs above our below the plane of the map. The map now displays an 11 parsec thick slice of 3D space. This would work best for practical purposes if most world's are on the 'zero' plane of the map, with just occasional world's, or small clusters, shifted up or down. It doesn't allow for hexes containing more than one world at different elevations. It is real, genuine 3D though. You could extend this by having certain world's or chains of worlds, leading up or down off the primary plane, link to subsector maps re-based to a different 'altitude', with perhaps just one or two chains of world's linking them to the main map. Think of the way chains of world's bridge some of the voids in the OTU Mao, such as the chain the Aslan control. A chain like that could be used to bridge up or down to a subsector (or more) displaced well away from the main map. The characteristics of jump travel mean that the possibility of journeys from other points between the maps just aren't an issue.

The idea is you can have manageable real 3D, that works fine at the gaming table, as long as you do so in a constrained, disciplined way. We can actually work with the characteristics of jump travel to tame the exponential combinatorial explosion you get with homogenous all-axis 3D.

Simon Hibbs

 

[Tom Kalbfus]

All the true 3D mapping systems I've seen suffer from either severe scalability problems or severe usability problems.

Paper based true 3D isn't scaleable. It can work for small regions of space from 5 to 10 parsecs across, but as soon as you try to go beyond that it breaks down quickly. Computer based 3D mapping solves the scalability problem, but how do you work with the software as a group at the gaming table?

I understand your working on a tablet based 2-d Traveller map, and most of the compute cycles, you say is taken up by generating the names. A quick and dirty solution is just have a premade list of planet names, and assign them to the planets as you need them, a lot of names get repeated anyway. My example is Corinth:
http://forum.mongoosepublishing.com/viewtopic.php?f=89&t=104820&p=864492#p864492
It is the name of an island off of Greece, but in New York there is a Rome, there is an Ithica, I could easily imagine a settlement named Corinth. Tablets fit nicely at the gaming table, and with a flick of the wrist you can rotate your 3-d map, zoom in and zoom out. NASA has one I believe.
http://stars.chromeexperiments.com/
Try it out, its lots of fun! Now would you like one like that for your gaming table?

There are semi-3D approaches that could work. One is to make a slight modification to traditional Traveller maps so that hexes with worlds have an optional +/-N value showing that the world is up to 5 parsecs above our below the plane of the map. The map now displays an 11 parsec thick slice of 3D space. This would work best for practical purposes if most world's are on the 'zero' plane of the map, with just occasional world's, or small clusters, shifted up or down. It doesn't allow for hexes containing more than one world at different elevations. It is real, genuine 3D though. You could extend this by having certain world's or chains of worlds, leading up or down off the primary plane, link to subsector maps re-based to a different 'altitude', with perhaps just one or two chains of world's linking them to the main map. Think of the way chains of world's bridge some of the voids in the OTU Mao, such as the chain the Aslan control. A chain like that could be used to bridge up or down to a subsector (or more) displaced well away from the main map. The characteristics of jump travel mean that the possibility of journeys from other points between the maps just aren't an issue.

The idea is you can have manageable real 3D, that works fine at the gaming table, as long as you do so in a constrained, disciplined way. We can actually work with the characteristics of jump travel to tame the exponential combinatorial explosion you get with homogenous all-axis 3D.

Simon Hibbs

 

[simonh]

I understand your working on a tablet based 2-d Traveller map, and most of the compute cycles, you say is taken up by generating the names. A quick and dirty solution is just have a premade list of planet names, and assign them to the planets as you need them, a lot of names get repeated anyway. My example is Corinth:
http://forum.mongoosepublishing.com/viewtopic.php?f=89&t=104820&p=864492#p864492
It is the name of an island off of Greece, but in New York there is a Rome, there is an Ithica, I could easily imagine a settlement named Corinth. Tablets fit nicely at the gaming table, and with a flick of the wrist you can rotate your 3-d map, zoom in and zoom out. NASA has one I believe.
http://stars.chromeexperiments.com/
Try it out, its lots of fun! Now would you like one like that for your gaming table?

Generating the names isn't a problem, I can generate hundreds per second, maybe thousands. I do actualy use a fixed name list as a basis, with random modifications, but I'm experimenting with Markov Chain algorithms as well. The problem is the way I'm displaying the names.

The way the map works now, each hex is represented as a drawing object, which contains the code to display the world circle, starport code, UWP and planet name for that hex (if it contains a world) as well as the hex borders. If I display the names as attributes of the hex they belong to, and the name extends outside the edges of the hex, if a neighbouring hex is 'in front of' it, that part of the name is obscured. To get round this, when a hex contains a world and I need to display the name, the code in the hex object adds the name to the map layer that sits above the hexes themselves, so the names are all at the top level of the map display. This process of adding the names to a layer above the hex object, from the context of the hex object itself, is very slow.

One possible optimisation would be to not have the hex objects be responsible for drawing world names. Instead I could implement that as a separate function that draws the names all at once, iterating through the worlds on the map, calculating the hex coordinates and drawing the world name at the right place all on one layer. That would avoid the context switching that's causing me performance problems at the moment.

Simon Hibbs

 

[Tom Kalbfus]

I understand your working on a tablet based 2-d Traveller map, and most of the compute cycles, you say is taken up by generating the names. A quick and dirty solution is just have a premade list of planet names, and assign them to the planets as you need them, a lot of names get repeated anyway. My example is Corinth:
http://forum.mongoosepublishing.com/viewtopic.php?f=89&t=104820&p=864492#p864492
It is the name of an island off of Greece, but in New York there is a Rome, there is an Ithica, I could easily imagine a settlement named Corinth. Tablets fit nicely at the gaming table, and with a flick of the wrist you can rotate your 3-d map, zoom in and zoom out. NASA has one I believe.
http://stars.chromeexperiments.com/
Try it out, its lots of fun! Now would you like one like that for your gaming table?

Generating the names isn't a problem, I can generate hundreds per second, maybe thousands. I do actualy use a fixed name list as a basis, with random modifications, but I'm experimenting with Markov Chain algorithms as well. The problem is the way I'm displaying the names.

The way the map works now, each hex is represented as a drawing object, which contains the code to display the world circle, starport code, UWP and planet name for that hex (if it contains a world) as well as the hex borders. If I display the names as attributes of the hex they belong to, and the name extends outside the edges of the hex, if a neighbouring hex is 'in front of' it, that part of the name is obscured. To get round this, when a hex contains a world and I need to display the name, the code in the hex object adds the name to the map layer that sits above the hexes themselves, so the names are all at the top level of the map display. This process of adding the names to a layer above the hex object, from the context of the hex object itself, is very slow.

One possible optimisation would be to not have the hex objects be responsible for drawing world names. Instead I could implement that as a separate function that draws the names all at once, iterating through the worlds on the map, calculating the hex coordinates and drawing the world name at the right place all on one layer. That would avoid the context switching that's causing me performance problems at the moment.

Simon Hibbs

What do you think of what NASA did with plotting 100,000 stars, there were no hexes there. Maybe a Traveller map like this could be generated with the same technique for spinning it around, zooming in and zooming out, you click on a star, and World information pops up, one aditional feature would be if you clicked on one star and held the mouse button down and released it on another, a line would be drawn between the two stars, and you would get a distance in parsecs. Or maybe just by clicking on a star you would get a list of the nearest stars to it along with the UWP information. If you want a Large 3-d map, you have to implement it on a computer, and well need a means to go through that map, pick out individual stars, perhaps even edit it, add and subtract stars and so forth.

 

[simonh]

What do you think of what NASA did with plotting 100,000 stars, there were no hexes there. Maybe a Traveller map like this could be generated with the same technique for spinning it around, zooming in and zooming out, you click on a star, and World information pops up, one aditional feature would be if you clicked on one star and held the mouse button down and released it on another, a line would be drawn between the two stars, and you would get a distance in parsecs. Or maybe just by clicking on a star you would get a list of the nearest stars to it along with the UWP information. If you want a Large 3-d map, you have to implement it on a computer, and well need a means to go through that map, pick out individual stars, perhaps even edit it, add and subtract stars and so forth.

The thing is, Astrosynthesis already exists. A project like that would require full time attention and I just don't have the time to spare.

Simon Hibbs