"Over" & "under" the canonical map plane

[lspitz]

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

That's actually my default treatment. If two stars are in adjacent hexes (and have the same Z-coordinate after rounding off), they can physically be 2 parsecs apart if they're at opposite sides of their respective hexes, but they are logically treated as 1 parsec apart. It extends your range by a parsec in a few rare cases, but this doesn't happen often enough to overcome the basic problem and restore anything that looks like a jump-1 Main. The chances of two stars in adjacent hexes being at the same Z-level are pretty low (somewhere on the order of 10 percent).

The easiest solution, since we've already thrown canon out the window by introducing the third dimension and can't possibly do any more damage to it, is to redefine jump distances. Jump numbers are retained as a sort of relative ranking, and Jump-2 is longer than Jump-1 and shorter than Jump-3-- but the numerical identity between jump number and range in parsecs goes away.

So, you can recapture the essence of the Traveller jump system if you're willing to give up this one-to-one correspondence. The easiest way to do it is to define J-1 as two or three parsecs, and increment the range by one parsec for each jump number. That keeps it simple and workable. I will also note that it's a lot less radical than the extremely-long-distance hop and skip drives introduced in T5.

 

[aramis]

I use JX = x+0.5Pc when doing 3D. My next TU probably will be 3D... but I'll have a links-list for every system, rather than a map for the players, tho' I might plug that into a subway-style map.

Generating that list, however, is a job for Python... the slice notation and container variables make it particularly well suited for the task...

System = [SysName,X,Y,Z,[J1Link1, J1link2,...],[J2link1, j2link2],...]

SystemList = [System1, System2,...]

!#python
dist = 0
SystemList = [...]
systemListWorking = systemList
For System in SystemListWorking:
    j1 = []
    j2 = []
    j3 = []
    j4 = []
    j5 = []
    j6 = []
    For Dest in SystemListWorking:
         dx = system[1]-dest[1]
         dy = system[2]-dest[2]
         dz = system[3]-dest[3]
         dist = Math.SquarRoot((dx * dx) + (dy * dy) + (dz * dz)
         if dist < 1.5:
              j1.add(dest[0])
         if dist < 2.5:
              j2.add(dest[0])
         if dist < 3.5:
              j3.add(dest[0])
         if dist < 4.5:
              j4.add(dest[0])
         if dist < 5.5:
              j5.add(dest[0])
         if dist < 6.5:
              j6.add(dest[0])
     system.add(j1)
     system.add(j2)
     system.add(j3)
     system.add(j4)
     system.add(j5)
     system.add(j6)

 

[lspitz]

I use JX = x+0.5Pc when doing 3D. My next TU probably will be 3D... but I'll have a links-list for every system, rather than a map for the players, tho' I might plug that into a subway-style map.

J-1 = 1.5 pc will only buy you Alpha Centauri. You still have to wait to develop the J-2 drive before you go anyplace else, and I'm pretty sure that you can't get out of the immediate region of Sol without J-3. There are only a dozen or so systems you can visit when J-2 is 2.5 pc. Although, I did use that fact once to develop a background where I wanted Terrans to gain a fair amount of experience building and using jump drives, but didn't want them getting loose into the larger galaxy right away.

Links-lists work. I find them useful but kind of dry and flavorless, because they don't give you a visceral feel for the layout the way a map does. OTOH, not everybody is visually oriented, so it's good to have a backup option.

 

[aramis]

J-1 = 1.5 pc will only buy you Alpha Centauri. You still have to wait to develop the J-2 drive before you go anyplace else, and I'm pretty sure that you can't get out of the immediate region of Sol without J-3. There are only a dozen or so systems you can visit when J-2 is 2.5 pc. Although, I did use that fact once to develop a background where I wanted Terrans to gain a fair amount of experience building and using jump drives, but didn't want them getting loose into the larger galaxy right away.

Links-lists work. I find them useful but kind of dry and flavorless, because they don't give you a visceral feel for the layout the way a map does. OTOH, not everybody is visually oriented, so it's good to have a backup option.

0.5 Pc = 1.63 LY
1.0 Pc = 3.26 LY
1.5 Pc = 4.89 LY
2.0 Pc = 6.52 LY
2.5 Pc = 8.15 LY
3.0 Pc = 9.78 LY
3.5 Pc = 11.41 LY

LY	Pc	Star	Type	Mass	COnstellation	Notes
0.00	0	Sol	G2 V	1.000	...	8+ planets, dust, brown dwarf b?
4.22	1.5	Proxima Centauri	M5.5 Ve	0.123	Centaurus	Flare star; brown dwarf b?
4.40	1.5	Alpha Centauri A	G2 V	1.09-1.10	Centaurus	a(AB)=23.7 AUs
4.40	1.5	Alpha Centauri B	K0-1 V	0.907	Centaurus	Sep(AB)=11.4-36.0 AUs, planet
5.96	2	Barnard's Star	M3.8 Ve	0.17-	Ophiuchus	V2500 Ophiuchi, old star
6.5 +/- 0.5	2-2.5	WISE 1049-5319 a	L 8 +/-1 V	<0.08	Vela	Brown dwarf binary
6.5 +/- 0.5	2-2.5	WISE 1049-5319 b	L/T V	<0.08	Vela	Brown dwarf, sep(ab)=3 AUs
7.78	2.5	Wolf 359	M5.8 Ve	0.092-0.13	Leo	CN Leonis, flare star
8.31	3	Lalande 21185	M2.1 Vne	0.46	Ursa Major	Flare & thick disk star; 3 planets?
8.60	3	Sirius A	A0-1 Vm	2.02-2.14	Canis Major	Dust, a=19.8 AUs, e=0.59
8.60	3	Sirius B	DA2-5	1.00-1.03	Canis Major	White dwarf
8.72	3	Luyten 726-8 A	M5.6 Ve	0.10-0.11	Cetus	BL Ceti, flare Star
8.72	3	UV Ceti	M6.0 Ve	0.10	Cetus	Flare star, a=5.5 AUs, e=0.62
9.68	3	Ross 154	M3.5 Ve	0.17	Sagittarius	V1216 Sagittarii, flare star

[tc=7]Source: www.solstation.com/stars/s10ly.htm [/tc]

Note that Pc are rounded up to the next half parsec for illustrative purposes.

Note also: it's about 6.5 LY from A Cent. to Barnard's... so J1≤1.5Pc & J2≤2.5 gives you

Sol - P Cent. 1.5 Pc
Sol - A/B Cent 1.5Pc
Sol - Barnard's 2 Pc
AC-Barnard's 2 Pc
Barnard's - Ross 154 2Pc

J2 gets you some distance.

 

[Nathan Brazil]

There are a few other "Universes" that use three dimensional mapping or posit 3D space.

Someone already mentioned SPI's Universe.

The 2300AD Universe is a three dimensional universe. The star data is old, but serviceable.

FTL: 2448 and Fringeworthy by Tri-Tac had mapping system with layered above/below hexes.

Space Opera by Fantasy Games Unlimited had cubical space sectors. The maps were 2D representations with stars having a +/- numeric designation representing above or below the Z dimension in light years.

 

[Nathan Brazil]

Much history of the OTU is dependent on the two dimensional nature of space.
If you introduce new systems from the new planes and leave the canonical zero plane so to speak alone, it begs the questions:
*These new did not contribute to the such and such war. Why not?
*Why were they not targets?
* Attack/retreat routes might have to be rewritten.

If you reduce the size of the OTU keeping everone's favorite planets by putting them on the different planes, different questions come because of communication times. Everything is closer together, but some things are dependent on comm time:

Rebellion does not occur the same way. Dulinor takes less time run home, but Lucan has an easier time of influencing and raiding other factions for their fleets to put him down. Other factions won't be isolated long enough to become factions.

Should Rebellion continue to the Black War stage, the "Safe" areas will be much smaller or non-existent as you might be able to get your fleet to the enemy's capital so much more easily because it is not so far away

Virus, should it occur in either scenario would be total. One of the much written things for the Spinward Marches is its isolation and the time it took for Virus to get there. With a smaller travel time, Virus has a better chance of destroying everything because everything is closer together meaning less time to develop defenses.

You could fix that somewhat by making JDrive less effective by some factor (say the number = light years, not parsecs). But you still need to rewrite much of OTU

In an ATU, these would be factors to consider.

The challenge on the "non-canonical" plane for the Third Imperium/OTU universe is the 30+ years of material that would have to be rewritten to fit the new astrography. It is likely that history will not be rewritten, as far as making it a new OTU.

 

[SanDragon]

Begging the aramis' pardon, but I thought a Parsec was 3.26 lightyears...?

 

[lspitz]

I'll agree, introducing the third dimension forces so many logical changes to the OTU that it can't be successfully retconned. Don't try this at home, kids. 3D and 3I just don't mix, and someone could get hurt.

Personally, I've never played a campaign set in the OTU, so that's not a concern for me. I've always used the CT rules as a toolkit to adapt interesting SF settings from literature or just roll my own. Sometimes they resemble the 3I setting in broad outline, sometimes they don't. Big empires are fun, but so are first-steps-to-the-stars campaigns, and romps through the ruins of a fallen empire during a dark age.

2300 AD is the only rules set that I have experience with that officially uses 3D starmapping. I remember how exciting the concept sounded- and how clunky the implementation was to actually use. The Near Stap Map never worked for me because it wasn't constructed in a way that allowed me to sense the Z-axis. I think it was about that time that I started thinking there had to be a way to do a starmap that captured the freedom of the third dimension, but kept the order and playability of a 2D hex map. That line of thinking eventually led me to the 10-parsec-slice solution.

 

[simonh]

While I have run games in the OTU, to my mind Traveller excels as a toolkit game. The world generation and ship design systems provide a great starting point for developing your own setting. In fact I think when I first picked up Traveller I started generating worlds before I even started generating characters.

It seems to me that Traveller was always intended to be played this way just as much as it's intended as a game system for playing in the OTU. After all, if you're playing in the OTU what use is the world generation system? This is why I wrote StarBase, it's because I want a tool I can use to develop my own settings.

Of course the moment you start thinking that way, it becomes clear that the world generation, ship design, even the mapping system and others are ripe for modding and adaptation to your specific needs. I don't think of the world generation system, or any of the other rules as being in any way 'canon' except only perhaps with reference to their use in building the OTU. Take the OTU out of the equation and there is no canon.

Simon Hibbs

 

[simonh]

I use JX = x+0.5Pc when doing 3D. My next TU probably will be 3D... but I'll have a links-list for every system, rather than a map for the players, tho' I might plug that into a subway-style map...

Nice idea, sort of a diagramatical 3D equivalent of the J-6 maps I've seen in some supplements. Traveller Universe does those very nicely too.

Simon Hibbs

 

[aramis]

Begging the aramis' pardon, but I thought a Parsec was 3.26 lightyears...?

You're right. I'll correct.

 

[tbeard1999]

Here's a link to a simple 3D mapping form I posted here awhile back:

http://www.travellerrpg.com/CotI/Discuss/showthread.php?p=273796#post273796

Hope it helps.

EDIT -- Just to be clear, hex A10 is directly over B10, which is directly over C10, etc. The megahex rosette in the upper right hand corner is my version of a sector.

 

[lspitz]

Here's a link to a simple 3D mapping form I posted here awhile back:

http://www.travellerrpg.com/CotI/Discuss/showthread.php?p=273796#post273796

Hope it helps.

EDIT -- Just to be clear, hex A10 is directly over B10, which is directly over C10, etc. The megahex rosette in the upper right hand corner is my version of a sector.

It's not a bad solution to the problem. I experimented with similar layouts for a while- I think my first attempts used squares/cubes (basically just boxing up a Cartesian grid), but I missed the look and feel of a hex map so I tried again with stacked hexes. Ultimately I settled on a straight flat projection rather than pseudo-perspective like this for no reason stronger than "I like the aesthetics better". I think your approach will work better than mine as the density of stars goes up, but for lower densities (up to about half the hexes occupied, and maybe as high as two-thirds), the performances will be comparable.


So you have 19 hexes to a level, and 95 hexes to a subsector. How deep are your sectors along the Z-axis? Same depth as the subsectors, or do you stack them too?

Have you put this mapping system to use in an actual game, and if so, how did your players react to it?

 

[simonh]

Here's a link to a simple 3D mapping form I posted here awhile back:

http://www.travellerrpg.com/CotI/Discuss/showthread.php?p=273796#post273796

Hope it helps.

Systems like that work fine for a single sector, and the potential complexity is probably manageable for very short range ships, but start getting very cumbersome when you're dealing with medium range ships, or any ships that have systems in range on vertically diagonal paths.

For example, to show all possible destinations for a J-3 or higher ship in the very center hex, you'd need to lay out 21 of these sheets of paper in three layers of layers. Even just a J-2 ship will often have hexes in eight different sectors within range, on two different layers of sectors.

Worst case, a j-6 ship in any of the upper or lower layer corner hexes (about 12% of the sector) has hexes in, I think, 40 or more of these sectors in range. I'm probably wrong on the exact number though, it's really hard to keep the relationships in my head. Which is the point.

Simon Hibbs

 

[tbeard1999]

It's not a bad solution to the problem. I experimented with similar layouts for a while- I think my first attempts used squares/cubes (basically just boxing up a Cartesian grid), but I missed the look and feel of a hex map so I tried again with stacked hexes. Ultimately I settled on a straight flat projection rather than pseudo-perspective like this for no reason stronger than "I like the aesthetics better". I think your approach will work better than mine as the density of stars goes up, but for lower densities (up to about half the hexes occupied, and maybe as high as two-thirds), the performances will be comparable.


So you have 19 hexes to a level, and 95 hexes to a subsector. How deep are your sectors along the Z-axis? Same depth as the subsectors, or do you stack them too?

Have you put this mapping system to use in an actual game, and if so, how did your players react to it?

Yes, we did use it and the players were fine with it. One consequence was that ships tended to have many more reachable destinations (which increased dramatically as jump capacity increased). For instance, in a 2D system, a Jump-1 ship has 6 destinations possible; a Jump-2 ship has 18 possible destinations. In a 3D system it's 20 destinations and 72 destinations, respectively. Not sure if that is better, but it is very different.

The subsectors are 5 parsecs deep.

 

[tbeard1999]

Systems like that work fine for a single sector, and the potential complexity is probably manageable for very short range ships, but start getting very cumbersome when you're dealing with medium range ships, or any ships that have systems in range on vertically diagonal paths.

For example, to show all possible destinations for a J-3 or higher ship in the very center hex, you'd need to lay out 21 of these sheets of paper in three layers of layers. Even just a J-2 ship will often have hexes in eight different sectors within range, on two different layers of sectors.

Worst case, a j-6 ship in any of the upper or lower layer corner hexes (about 12% of the sector) has hexes in, I think, 40 or more of these sectors in range. I'm probably wrong on the exact number though, it's really hard to keep the relationships in my head. Which is the point.

Simon Hibbs

<shrug> Seems to me that *any* paper based mapping system will have this problem. My form was designed to allow a reasonable number of systems to be displayed on a single sheet of paper (which was obviously the rationale for the CT subsectors -- 8x10 16mm hexes was what could comfortably fit on a single LBB page). You could easily put an entire sector on an 11x17 page, I guess.

 

[lspitz]

Systems like that work fine for a single sector, and the potential complexity is probably manageable for very short range ships, but start getting very cumbersome when you're dealing with medium range ships, or any ships that have systems in range on vertically diagonal paths.

For example, to show all possible destinations for a J-3 or higher ship in the very center hex, you'd need to lay out 21 of these sheets of paper in three layers of layers. Even just a J-2 ship will often have hexes in eight different sectors within range, on two different layers of sectors.

Worst case, a j-6 ship in any of the upper or lower layer corner hexes (about 12% of the sector) has hexes in, I think, 40 or more of these sectors in range. I'm probably wrong on the exact number though, it's really hard to keep the relationships in my head. Which is the point.

Simon Hibbs

Yes. The number of possible destinations will vary as the square of the jump distance on a 2D map, and as the cube of the jump distance on a 3D one. 3D starmaps have a much higher degree of connectedness.

I can't see the cross-sector jump problem as a unique objection to 3D mapping. It's certainly worse in 3D, but it also exists in canonical 2D maps. Any ship with J-5 or better can reach destinations in 5 distinct subsectors if it starts in the center of the originating subsector (hexes 0405, 0505 or 0506). Not usually a problem in the games I've played in, since players rarely get their hands on a ship that is capable of more than J-3.

I sidestepped the whole issue of having to mess around with a lot of subsector maps spread out on the table by writing my own mapping app. It's easy to display adjacent subsectors, and I can zoom in or out, scroll in whatever direction I want, and change the thickness of the Z-slice or move the projection plane up or down on the fly to see what I need to see at the moment. On a sufficiently large screen, I can display the contents of a chunk of space that's almost 50 parsecs wide, 30 parsecs tall, and 20 parsecs deep, centered on whatever coordinates I want, with enough detail to plot a route. That's pushing the boundaries of readability, for sure, but I've never actually had to go to this extreme in play. Displaying 25x15x10 parsecs is more than enough in every real use-case I've run across.

It works for me. Your mileage may vary. I could adapt to using printed maps if I had to, but it's so much easier to do it on a computer screen.

 

[simonh]

It works for me. Your mileage may vary. I could adapt to using printed maps if I had to, but it's so much easier to do it on a computer screen.

Indeed, hence StarBase. It's intended as a tool for setting development though, not the table top. My intention is that the maps would be printed out for use on the gaming table.

Simon Hibbs

 

[lspitz]

Indeed, hence StarBase. It's intended as a tool for setting development though, not the table top. My intention is that the maps would be printed out for use on the gaming table.

Simon Hibbs

I downloaded the StarBase executable and had a look at it. It has a nice Classic Traveller feel to it. Too bad I'm not a Python programmer or I'd download the source files and tinker. I do C, C++, C#, Pascal and Basic, and I know just barely enough Java to be dangerous.

 

[simonh]

I downloaded the StarBase executable and had a look at it. It has a nice Classic Traveller feel to it. Too bad I'm not a Python programmer or I'd download the source files and tinker. I do C, C++, C#, Pascal and Basic, and I know just barely enough Java to be dangerous.

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