"Over" & "under" the canonical map plane

[lspitz]

Even with the executable version you can tinker with the rules files under the project directory, as they are pure source dynamically loaded at runtime. If you don't mind dirtying your hands with a little Python that is. It's not all that different from what you're familiar with, and you can both modify the world attribute definitions (add new attributes, for example) and tweak the world generation algorithms.

Simon Hibbs

I might tinker with it a bit. Python syntax doesn't seem too outré. I already have quite a bit of time and effort invested in a Visual Basic starmapping program of my own, though (always a work in progress, one that will probably never be completed because there's always just one more feature I'd like to add). I like using 3D and real star data, and I think it would take a substantial revision of the StarBase code to make it do either of those.

It could be faked with much less programming effort, I think, by just adding a Z-dimension tag to each system and creating multiple projects with sectors that stack logically on top of each other. The onscreen navigation wouldn't support the concept, but the subsectors could be printed out and referred to in tabletop play.

 

[Lapthorn]

When dabbling with 3D mapping, I like Astrosynthesis from NBOS. There is a feature allowing search for all systems within X lightyears or parsecs of an origin system - makes selecting destinations a breeze. One of my 3D maps is in my gallery post.

Given the wealth of the OTU setting though, I have sometimes toyed with a rationale for the 2D map as follows: it's to do with jump being measured relative to the galaxy's central supermassive black hole. So your jump-1 could be hundreds of lightyears "up" or "down" but all that counts is whether you end up nearer or further away from the CSBH.

Needs more thought, though.

 

[BytePro]

...Needs more thought, though.

Yeah, gave it some thought long ago. Jump being affected by distance from masses, i.e. gravity gradient like, its a good fit.

The OTU is pretty far from the SMBH and relatively small, so any effect of curvature is minimal and could be ignored (well within the 'parsec' accuracy of hexes). Thus towards and away from the core is nicely explained this way.

Unfortunately, that leaves Trailing/Spinward unexplained.

Hence, I used a 'jump plane' rotating with the galactic disk (handwaving brane artifacts). Distance above/below is useful for the variable jump times. Time non-linearly jumps [pun] to infinite X parsecs above/below, limiting things nicely. I use 16 parsecs above/below - mostly because it looks good in 3D.

 

[pennshome723]

I have a 3D system worked out...but it is all on paper!

I run in the Verge sector only and have a +/- maps too, with one star map above and another below the standard verge sector maps.

Some stars are points that connect via a Jump-3 to either other maps.

It is much easier to do this from scratch from your own created made up space region.

 

[simonh]

...
Some stars are points that connect via a Jump-3 to either other maps.

It is much easier to do this from scratch from your own created made up space region.

I have heard of GMs who've done something similar, such as have a few subsectors that are off the plane of the main map and only accessible via certain systems. That's a nice idea and makes hardly any changes to the normal way Traveller maps work.

Simon Hibbs

 

[Lapthorn]

The OTU is pretty far from the SMBH and relatively small, so any effect of curvature is minimal and could be ignored (well within the 'parsec' accuracy of hexes). Thus towards and away from the core is nicely explained this way.

Unfortunately, that leaves Trailing/Spinward unexplained.

Ah, but the effect of the CSBH (or SMBH!) doesn't work in jumpspace as it does in 3D space. Any change of position relative to the CSBH encounters a kind of resistance. Higher-rated drives access a different combination of additional dimensions where the CSBH resistance is less.

I did say it needed more thought. And there it is!

 

[BytePro]

Handwave^2.5.

Hehe, I used to relentlessly badger a mediocre physics prof by adding 'and what happens when we take that to n dimensions?'

Its cute, but for now I'll stick with my Tattoo style explanation for my Players - "Ze Plane! Ze Plane!"

 

[lspitz]

One could argue that canonical jumpspace doesn't allow you to access star systems that lie outside a plane (or if not a true plane, at least a Z-slice of restricted height, maybe a few parsecs. Space is 3D, but it's not relevant to travel using the jump drive since most of it is inaccessible.

I seem to recall reading somewhere along the line that jumpspace is not natural- it's one of Grandfather's creations, and that this statement is attributable to Marc Miller. But I can't recall the source (too many years gone by, too few neurons still firing), so I could very well be mistaken. Anyway, if this recollection is true, then the 2D nature of jump maps is easily explained. It's a Mad Science experiment with unusual properties. It allows you to access star systems in a restricted volume +/- some small distance from a reference plane, and can be represented as being flat for all practical purposes. The bulk of the galaxy can only be reached via STL travel, and for all practical purposes can be (and is) ignored by starfaring civilizations dependent on the jump drive.

It's another form of handwaving, but it works as well as any.