3d Subsector

Tom Kalbfus

Mongoose
3d_subsector_000_by_tomkalbfus-d9p10o6.png

This is the beginnings of my 3d subsector.
What do you think so far?
I'm going to name the systems and generate stats and post them later here, but for now, this is the map I made.
 
Nah. Normal formula for determining distance for 3D locations should suffice. Big difference between a flat hexagonal map and a 3D map if both use parsecs will be much greater distances between systems.
 
I like this idea. I had thought of doing it myself earlier, but lacked the motivation. I really hope you get some joy out of this.

It may work better as a mapping app, than as printed pages. It can be hard to visualuse unless you can 3d print it or build it out of one of those chemistry set modelling tools or foam balls. e.g. http://imgur.com/PNZmok7

Although now I write this, I realise that the kits won't work as the holes won't be in the right place, and foam balls look like a better bet.
 
Back before digital modeling, I saw a map of the local system done with wire and painted balls. Holes drilled on a board at the X/Y then the stiff wires cut to the proper Z distance. Balls painted to the color of the primary with other balls attached as companions. Board was black.
 
A long time back, I put all the XYZ data of the 2300AD local star map into a spreadsheet then had it calculate the distance between every system. I printed the whole thing so it could be placed end to end then determined the Jump distances and color coded the entries so you could easily see the relation of every system. Finished up by hand drawing a 3D map with routes up to J3. The distances between systems are far different than what we see for Sol's local Traveller subsector. More distance between systems.
 
3d_subsector_000_by_tomkalbfus-d9p5way.png

Here is my latest map. It contains a wormhole, to allow integration with a 2-d mapped setting.
3d_subsector_000_stats_by_tomkalbfus-d9p5x0w.png

These are the stats for the labeled entries on my map. I've included some work I've done previously.
Not so legible, try this, you can copy and past onto a paint program after a left rotation of the image.
3d_subsector_000_right_90_stats_by_tomkalbfus-d9p5ybk.png
 
Reynard said:
Nah. Normal formula for determining distance for 3D locations should suffice. Big difference between a flat hexagonal map and a 3D map if both use parsecs will be much greater distances between systems.
Yes, I use an system occurance of 12 in a 2d6 roll for system presence, that means for any given cubic parsec, there is a 1 in 36 chance of a system being in a given cube of space, My subsector is a 10 parsec cube. I had my computer roll the 2d6 1000 times on a spreadsheet, and the result is the map you see.
 
boregar_system_020_by_tomkalbfus-d9qq0pg.png

This is my first system for the 3-d subsector, I decided to redo all the stats, rolling them randomly, except for a few select ones such as Magrethera and Terranor (The Ringworld in my setting) The 3-d subsector has a wormhole which connects it to the 2-d OTU. So various "players" from the OTU, can end up here. Here we have the Boregar system, a system, who's primary inhabitants are human colonists. The random roles, produced an Earthlike, low population world with 10,000 to 99,999 inhabitants, the planet boasts just one town with a class E starport, and a tech level of 10, or Early Interstellar, as I call it. I had my Excel spreadsheet do the random rolls, and then I went over the results, I hand rolled the orbits for the moons. As you can see, it is a binary system with a K4 V and an M6 VI. Under this system, Orbit 3 is always in the habitable zone of the star, so the distances vary according to each star's luminoscity.
 
boregar_and_xerx_by_tomkalbfus-d9qr03s.png

I updated and fixed a few things and added another star system Xerx to my list. Stellar Mass, should be 0.98 for the white dwarf, by the way. I didn't catch it before submitting it.
 
I like the work you have put in this. Do you find the jump distances get a bit far apart with the frequency you have chosen? I also have gone 3d with 10x10x10 sub sectors although I use a flat map mechanism for ease of play without a digital device (I picked the idea up from an old space board game called Godsfire). However choice of display is not as important as the question of density and jump distances. I found that a 1,000 cubic parsecs needs about 200 star systems to work well with jump 1 and jump 2 distances and to be somewhat in keeping with stellar densities in the Orion Arm of our galaxy.
 
I'm sure the majority of Traveller fans have a hard time conceiving the physicality of three dimensional mapping compared to a flat hexagon map. Even a square grid map makes FTL travel with a discrete movement system difficult since only four locations around any point are accessible to a jump one flight. Adding a third dimension to that only makes mapping worst (but possible). Not sure what the actual decision making was for the design of 2300AD but it was obvious the staff on GDW wanted a hard science map of the real space around sol and it was apparent there would be no jump style FTL so there came the analog stutterwarp. This calls to mind using the Traveller alternate warp drive for 3D travel. Another possibility would be mapping systems in increments of light years rather than parsecs when using jump drive better matching distance to the limits of jump without actually crowding a sector or subsector by experimenting with density. Still again, 3D systems definitely call for complex paper or digital book keeping.

This is why Traveller K.I.S.S. is such a blessing.
 
DanDare2050 said:
I like the work you have put in this. Do you find the jump distances get a bit far apart with the frequency you have chosen? I also have gone 3d with 10x10x10 sub sectors although I use a flat map mechanism for ease of play without a digital device (I picked the idea up from an old space board game called Godsfire). However choice of display is not as important as the question of density and jump distances. I found that a 1,000 cubic parsecs needs about 200 star systems to work well with jump 1 and jump 2 distances and to be somewhat in keeping with stellar densities in the Orion Arm of our galaxy.
If I drew my map with 200 star systems, don't you think that would look a bit crowded? With my rolling, the chance of a star system in a cubic parsec is 1 in 36, this produces an average of about 27.777 star systems, and when I'm trying to detail complete star systems, not just main worlds, this seems like quite enough. I plan of detailing only one subsector, that would be quite enough work for me.
 
Reynard said:
I'm sure the majority of Traveller fans have a hard time conceiving the physicality of three dimensional mapping compared to a flat hexagon map. Even a square grid map makes FTL travel with a discrete movement system difficult since only four locations around any point are accessible to a jump one flight. Adding a third dimension to that only makes mapping worst (but possible). Not sure what the actual decision making was for the design of 2300AD but it was obvious the staff on GDW wanted a hard science map of the real space around sol and it was apparent there would be no jump style FTL so there came the analog stutterwarp. This calls to mind using the Traveller alternate warp drive for 3D travel. Another possibility would be mapping systems in increments of light years rather than parsecs when using jump drive better matching distance to the limits of jump without actually crowding a sector or subsector by experimenting with density. Still again, 3D systems definitely call for complex paper or digital book keeping.

This is why Traveller K.I.S.S. is such a blessing.
Is my map really that hard to understand? Seems simple enough if you show only one subsector at a time, if you don't get ambitious and stay local, then a 3d subsector can hold as many star systems as a 2d subsector in Classic Traveller. As for jump drives, you can redefine the jump drives as such.
Jump-1 range: 0 to 1.49 parsecs
Jump-2 range: 1.5 to 2.49 parsecs
Jump-3 range: 2.5 to 3.49 parsecs
Jump-4 range: 3.5 to 4.49 parsecs
Jump-5 range: 4.5 to 5.49 parsecs
Jump-6 range: 5.5 to 6.49 parsecs

Or to state it backwards:
A jump distance which rounds off to 1 parsec requires a Jump-1 drive
A jump distance which rounds off to 2 parsecs requires a Jump-2 drive
A jump distance which rounds off to 3 parsecs requires a Jump-3 drive
A jump distance which rounds off to 4 parsecs requires a Jump-4 drive
A Jump distance which rounds off to 5 parsecs requires a Jump-5 drive
A Jump distance which rounds off to 6 parsecs requires a Jump-6 drive

I'd define the minimum jump distance from a gravitational mass as "the cube root of the mass in Earth masses times 100 Earth diameters."
 
Reynard said:
I'm sure the majority of Traveller fans have a hard time conceiving the physicality of three dimensional mapping compared to a flat hexagon map. Even a square grid map makes FTL travel with a discrete movement system difficult since only four locations around any point are accessible to a jump one flight. Adding a third dimension to that only makes mapping worst (but possible). Not sure what the actual decision making was for the design of 2300AD but it was obvious the staff on GDW wanted a hard science map of the real space around sol and it was apparent there would be no jump style FTL so there came the analog stutterwarp. This calls to mind using the Traveller alternate warp drive for 3D travel. Another possibility would be mapping systems in increments of light years rather than parsecs when using jump drive better matching distance to the limits of jump without actually crowding a sector or subsector by experimenting with density. Still again, 3D systems definitely call for complex paper or digital book keeping.

This is why Traveller K.I.S.S. is such a blessing.

Traveller distances are such a approximation, there's no reason why you can't allow diagonal jumps on a square grid.

If a square is just under a parsec on each side, the diagonal will be just over a parsec, and it'll all average out.

Plus, the distance between star systems in adjacent hexes doesn't have to be 1 parsec. The star can be at any point inside the hex. If both stars are at opposite corners of their hexes, they can be well over 2 parsecs apart, and require jump-2 to travel 1 hex. Traveller approxmates all this away, to such a high level that allowing diagonal jumps on a square grid wont break it.

I quite like the 3d maps. I would draw it differently, but I have no objection to using 3d.

The only real difference between squares, hexes and 3d is that you need to adjust the star system density, but that value isn't fixed anyway, so it's all good.

hexes are just offset squares anyway:
BgigR80.png
 
This is what mine look like:

traveller-classic


You can find the file at https://rpggeek.com/filepage/110255/3d-sub-sector-map

( I can't get the image to display, anyone know what I'm doing wrong with the image code? URL is https://rpggeek.com/image/2821121/traveller-classic )
 
DanDare2050 said:
( I can't get the image to display, anyone know what I'm doing wrong with the image code? URL is https://rpggeek.com/image/2821121/traveller-classic )

You have to go to the address (I used properties).

pic2821121_md.png
 
"Plus, the distance between star systems in adjacent hexes doesn't have to be 1 parsec. The star can be at any point inside the hex. If both stars are at opposite corners of their hexes, they can be well over 2 parsecs apart, and require jump-2 to travel 1 hex. Traveller approxmates all this away, to such a high level that allowing diagonal jumps on a square grid wont break it."

As far as I remember, the hex map has always been hex center to hex center. As to a diagonal in a hex system converted to an offset square grid, the diagonal will still be significant enough. If you have stars anywhere within a hex, you might as well go Cartesian coordinate mapping as 2300 uses. Each system has their three coordinates and it's a simple formula to determine the distance between any two stars. If the number falls within the ship's Jump number, the jump is possible. A program to generate coordinates would be a snap even including system densities within a volume of space. Again, stars can be more accessible if coordinates are in light years rather than parsecs while the drive remains the same.
 
Back
Top