"Over" & "under" the canonical map plane

[faherman]

Even as a mapping artifact, it drives me nuts that space is apparently a plane one parsec thick. If one were to layer additional, made-up sectors "over" and "under" the canonical ones, in multiple layers in both directions--turning the Imperium and its neighbors into three-dimensional spaces--would that be silly?

(I realize it still wouldn't be realistic, since presumably what real-world stars are present on the official map don't fit within a convenient plane that this schema would still leave intact.)

 

[Reban]

The problem is that the galaxy is on average 600pc "thick". Thats 300 layers above and 300 layers below. Its just hard to represent.

 

[BytePro]

Even as a mapping artifact, it drives me nuts that space is apparently a plane one parsec thick. If one were to layer additional, made-up sectors "over" and "under" the canonical ones, in multiple layers in both directions--turning the Imperium and its neighbors into three-dimensional spaces--would that be silly?

Not at all - how can it be sillier than a 2D based 'space' setting.

(I realize it still wouldn't be realistic, since presumably what real-world stars are present on the official map don't fit within a convenient plane that this schema would still leave intact.)

No, its not at all realistic (which would need to account for the 4th dimension) - its a game after all. But it looks a whole heck of a lot better and its a lot easier to pass off.

I use the 2D plane projection for jump distances and call it the jump plane (handwaving 'jumpspace as an artifact of a brane') - with a limited region above and below that is within jump reach (jump time goes from 'nearly a week' figures in HG, to 'approaching infinite').

 

[faherman]

Reban -- Sure, but I wouldn't imagine Charted Space to be "taller" than its established width. Still a lot of work to fill in, of course.

 

[faherman]

Not at all - how can it be sillier than a 2D based 'space' setting.


No, its not at all realistic (which would need to account for the 4th dimension) - its a game after all. But it looks a whole heck of a lot better and its a lot easier to pass off.

I use the 2D plane projection for jump distances and call it the jump plane (handwaving 'jumpspace as an artifact of a brane') - with a limited region above and below that is within jump reach (jump time goes from 'nearly a week' figures in HG, to 'approaching infinite').

That sounds cool. I'd thought at one point about having the plane be, literally, a plane bisecting the galactic disk (and central supermassive black hole) outside of which jump was impossible, but again there's the problem of real stars not matching to it.

 

[BytePro]

'Matching' real stars back in the day would have been problematic - the error of measurements past a Sector (> 100 ly) was too great from earth based figures.

Satellite missions changed that significantly. But even now, star systems could be a parsec or more off within a single Sector, and dozens of parsecs across the 'Known Space' map...

If you want, though, take a rectangular chunk of a star catalog - if the chunk is a certain depth (I used 32 parsecs parsecs high - i.e. a Sector width) I wouldn't be surprised if you couldn't find a swath with little to no systems falling within the same parsec foot print projected onto a plane. A little nudging would probably fix all those occurrences. But, that is just way overkill to me, especially if one isn't going to include motion - its a game, I use the 3D for props. Its cool and helps folk visually see what I'm talking about by 'jump plane'.

Note, I use custom computer programs, though early 80's I started with mylar overlays and an 8 shelf plexiglass setup. That looked pretty cool, but didn't work very well in play and I never took any pictures of it.

Back around the turn of the century I imported the HES files (from Heaven and Earth - TravellerMap didn't exist yet, IIRC) for the original 35 sectors and made a 3D version in OpenGL. It actually looked pretty cool flying though (though one sector was missing) and collapsing/expanding to the jump plane. Unfortunately, I ran it a few years ago and Windows couldn't capture the screen and I never programmed an animated gif or movie output. Which would be better, a screen cap just looks like a bunch of random dots.

Anyway, there are several excellent free programs that could provide 3D views of custom starmaps - and even stellar systems. Modelling programs like Sketchup and Blender would even work. Not sure about the Jump plane, but if you could toggle a 'top down' ortho view and it'd be the same effect.

P.S. - Googled for a reference on distance errors, this one looks decently readable http://www.uwgb.edu/dutchs/cosmosnotes/distance.htm

 

[Shonner]

To stay canonical, the galaxy must be 1 parsec thick. All that's canon about Traveller depends on this.

 

[faherman]

Goodness, that all sounds quite impressive. And thanks for the link!

 

[faherman]

To stay canonical, the galaxy must be 1 parsec thick. All that's canon about Traveller depends on this.

Well, Traveller5 outright states on p. 14 that the galaxy is--ah, it's errata'ed to 0.3 kiloparsecs thick at the center (originally printed as -3- kpc). So the third dimension is at least acknowledged in theory.

 

[Shonner]

Well, Traveller5 outright states on p. 14 that the galaxy is--ah, it's errata'ed to 0.3 kiloparsecs thick at the center (originally printed as -3- kpc). So the third dimension is at least acknowledged in theory.

Why would that even be mentioned in the book?

 

[77topaz]

Even as a mapping artifact, it drives me nuts that space is apparently a plane one parsec thick. If one were to layer additional, made-up sectors "over" and "under" the canonical ones, in multiple layers in both directions--turning the Imperium and its neighbors into three-dimensional spaces--would that be silly?

(I realize it still wouldn't be realistic, since presumably what real-world stars are present on the official map don't fit within a convenient plane that this schema would still leave intact.)

I don't see why it would be "silly" - it would just be different from normal Traveller. As far as I know, numerous individuals have already attempted to create 3D Traveller (and related sci-fi) settings multiple times, though I'm not aware of any published materials. There are also numerous programs for creating and working with 3D space maps, such as AstroSynthesis.

 

[BytePro]

To stay canonical, the galaxy must be 1 parsec thick. All that's canon about Traveller depends on this.

Where in canon is it stated the galaxy is 1 parsec thick? o:

A parsec is a very Earth centric measure being based on parallax and the Earth derived AU. Actually, next to nothing canon depends on this...

My fix is one simple definition -

Parsec refers to a distance of 3.26 lightyears as measured on the jump plane.​

There, all done.

 

[Whipsnade]

Even as a mapping artifact, it drives me nuts that space is apparently a plane one parsec thick.

You want to really go nuts? Try and come up with a 3D mapping system that you and your players can use quickly and intuitively.

It's a game. We accept certain things for ease of play.

 

[Shonner]

SPI's Universe uses a 3D map. X,Y,Z stuff. But it's less than 100 light years in size I think to keep things simple.

 

[simonh]

This topic inevitably comes up on discussion forums from time to time. The problem IMHO is that layering reams of paper or transparent plastic maps on top of each other just doesn't work on the gaming table. Also the higher order exponential explosion in world numbers as you map size increases rapidly becomes a huge problem. A single sector goes from being just a few hundred worlds, to containing about as many worlds as half the entire OTU.

There are alternative approaches. One is to say that each hex is actually a much larger volume of space, say 10 parsecs across, but that most systems in it are barren and so resource poor as to be uninteresting. This doesn't solve the general problem, because it's still fundamentally a 2D map, but it makes it feel a bit less obviously unrealistic.

One approach I've toyed with is annotating some systems to be up to +/- 5 parsecs above or below the map plane. Not a lot of worlds, just maybe 4 or 5 per subsector. Actually I just said it takes +/- that many more parsecs to get to them from wherever you're jumping from, no trigonometry required. The explanation is that the galactic disc has a kind of lensing effect on jump space which distorts jump efficiency in that direction. This method adds another dimension at the local level when you're planning individual jumps, without significantly complicating the basic 2D mapping system that works so well in play, especially at the campaign level.

Simon Hibbs

 

[Doyle Hunt]

The Japanese science fiction novel "Crest of the Stars" and its sequels had a simple explanation. In the novels, jump space was called "Plane Space" because it was two-dimensional. In the animated versions, tactical plots were planar, and looked an awful lot like Traveller sectors.

The Traveller galaxy can be three-dimensional, but jump space need not be three-dimensional at all. Two stars that are one "parsec" apart in jump space could be farther apart or closer together in real space, but for the average Travellers, the difference is inconsequential since they'll never travel between the stars in real space to notice the difference.

The only ships affected by the difference between 2D jump space and 3D real space would be sub-light ships that took off from Earth before the invention of the jump drive, that still had to be set on a non-planar course. Or ships that mis-jumped, and are vectored toward the closest star in real space because the jump drive is toast.

 

[lspitz]

You want to really go nuts? Try and come up with a 3D mapping system that you and your players can use quickly and intuitively.

It's a game. We accept certain things for ease of play.

It's not that hard. I use a Z-slice that's 10 parsecs thick. I take the real stellar data from the Gliese and Hipparcos catalogs and rotate the coordinates so that coreward is toward the top and rimward is towards the bottom (spinward to the left). Stars are projected onto the plane and marked with their Z-coordinates rounded to the nearest parsec. Using a 1-parsec hex grid, it's quite readable, and figuring distances between any two stars is simple. You count hexes in the XY plane, note the difference between the two systems on the Z-axis, and refer to a small 10x10 table to get the jump distance. If you draw jump lines, you can even eliminate the need to refer to the table when you look at a subsector map.

The 10-parsec slice works well for the solar neighborhood. It could get messy near the Core, but you can always use a thinner Z-slice for those regions to keep it readable if you range that far from the Local Arm.

Admittedly, the result is incompatible with the OTU when you go 3D. At the same time, the starmap has a very familiar look and feel to it, and it doesn't cause hair-pulling or interfere with the ease of play at all. If you prefer a mapping system that acknowledges the third dimension and don't particularly care about preserving canon (or if you aren't playing a campaign set in the OTU to begin with), then it works just fine. I also have a system for randomly generating subsectors in 3D, which can be used where you don't care about using real-world star data or don't want to do the trigonometry. It can be used to fill out subsectors far from Sol where the stellar data are incomplete, too.

 

[simonh]

It's not that hard. I use a Z-slice that's 10 parsecs thick.

That works out very close to the system I used, with some worlds +/- 5 parsecs from the map plane (so none are more than 6 parsecs from a world in a 'neighbouring' map hex on the plane).

I simplified a bit more than that, limiting the number of worlds off the primary plane and making jump distance calculations easier, but I can see how your system could work perfectly well.

I'll have to think about implementing something like this in StarBase.

Simon Hibbs

 

[lspitz]

That works out very close to the system I used, with some worlds +/- 5 parsecs from the map plane (so none are more than 6 parsecs from a world in a 'neighbouring' map hex on the plane).

I simplified a bit more than that, limiting the number of worlds off the primary plane and making jump distance calculations easier, but I can see how your system could work perfectly well.

I'll have to think about implementing something like this in StarBase.

Simon Hibbs

Yup, my system also boils down to +/-5 parsecs above and below the projection plane.

Limiting the number of worlds off the primary plane wasn't an option for me, because I decided up front that I was going to take what the real universe offered me. I get up to three systems stacked in a single hex when the XY coordinates happen to be close to each other, but it's perfectly readable with a sufficiently large hex to draw them in- a scale of about an inch will do.

I analyzed 400 hexes in the vicinity of Sol to get a feel for the distribution. The results:
54% of the hexes are empty.
34% of the hexes contain one star system.
10% of the hexes contain two star systems at different heights
2% of the hexes contain three star systems at different heights

If you're creating star systems from scratch for a game, you can easily impose a rule that says a particular 10-parsec deep column, as represented by a one hex in projection, is either empty or has only one star system. It's not totally realistic, but it isn't horribly far off from reality either. It's certainly a lot closer than "everything lies in the same two-dimensional plane".

That said, I've played plenty of games using the classic 2D map. It's not realistic, but it offers enough of the flavor of "it's a sprawling galaxy" to capture the essential mood of the game, and it's unquestionably easy to play.

I should note that if you use a 3D map with a realistic distribution of stars, no extended trade routes like the Spinward Main can exist until you reach Jump-3. Real stars average a little more than 2 parsecs apart in our part of the galaxy, and (globular clusters aside) you only occasionally see a small group of 2 to 5 stars that form a jump-1 chain. There are a lot of gaps that are uncrossable by low-jump ships. This is one of the big reasons that a 3D map using a real-world distribution is incompatible with canonical Traveller star maps. The Mains simply vanish. Any starship with jump-2 capability will be confined to a finite territory, and a jump-1 starship isn't going much of anywhere.

 

[simonh]

This is one of the big reasons that a 3D map using a real-world distribution is incompatible with canonical Traveller star maps. The Mains simply vanish. Any starship with jump-2 capability will be confined to a finite territory, and a jump-1 starship isn't going much of anywhere.

It might be possible to finesse that a bit. Systems obviously aren't all located at the exact centre of their hex, they could be anywhere in it, so the distance between adjacent systems averages to 1 parsec, but could be much higher. Yet J-1 ships can always get from a system in one hex to a system in an adjacent hex. So to my mind J-1 ships actually have a range of up to 2 parsecs, J-2 ships have a range of up to 3 parsecs, etc.

Does that help at all, or does the way to allocate systems to hexes already take that into account?

Simon Hibbs