(Unrealistic) 3-D subsector mapping?

[faherman]

I'm sure this sort of thing has been discussed and probably shredded before, but has anyone ever come up with a usable three-dimensional sector mapping system?

For a willfully unrealistic continuing-on-from-the-LBBs approach (and one not really adaptable to the OTU), could the following system work? I've been poking around the idea of it.


3D Subsector Mapping:

Method One: Subsector is three-dimensional, 10pc x 8pc x 8pc. Roll up as normal, assign each world a Z-axis by rolling 1d8.

Method Two: Subsector really is (relatively) planar, but has other planar subsectors layered “above” and “below” it. Eight stacked subsectors form a Zone.

Inter-subsector trade routes must be determined between z-axis adjacent subsectors.

Likewise, Sectors are also 3D. If using Method Two, eight stacked sectors form a Supersector.

 

[Malenfant]

When I did my map of real stars around Sol I went for Method 2 - stacked planar layers.

http://www.evildrganymede.net/rpg/traveller/mapping.htm

The only distortions here are due to fitting stars into hexes - if you removed that then the stars would be placed in exactly the right positions.

That said, you can only do this realistically for the space close to Sol, because beyond about 10pc you lose more and more of the M V systems because it gets harder to detect them beyond that distance.

 

[aramis]

If you offset the hexes on the odd layers, you get 12 directions instead of 6, a convenient (if mildly confusing at first) paradigm.

You move the odd layer such that the centers are over the vertices of of the even layer. This puts three hexes above, and three below, with six around.

Of course, there is Method 3: No Hexes

Using a simple coordinate grid... 3 axis... one can replicate the same process.

I've been thinking about this last one for a while, and thinking that a 5x5x5 subsector with a 15x15x15 sector would work fairly well...

 

[TheEngineer]

Hi !

Method 4:
Use and treat the Traveller maps just a jump maps (with an appearently nearly flat j-space) but map stars to the real star positions.
That makes your TU perfectly 3D, and leaves jumpspace, which is a hypothetical construct anyway, but the backbone on the OTU and its history as it is.

Regards,

Mert

 

[BetterThanLife]

Actual true 3D mapping is possible but causes problems with the OTU which is tied to the flat map.

So if you want a 3D Universe, then my recommendation is to either go true 3d and leave the OTU behind, or leave it alone in 2D. Otherwise TheEngineer's suggestion of it being strictly a jump map is really the only workable solution.

(I spent about 3 months trying to come up with a solid 3D solution and they don't really work, except at a very local level.)

 

[RandyT0001]

Originally posted by Aramis:
If you offset the hexes on the odd layers, you get 12 directions instead of 6, a convenient (if mildly confusing at first) paradigm.

You move the odd layer such that the centers are over the vertices of of the even layer. This puts three hexes above, and three below, with six around.

A year or so ago I was thinking about a similar idea using regular dodecahedrons. A plane perpendicular to a (C3) axis of a dodecahedron cuts the solid in a regular hexagonal cross section. That give you the hexes used in Traveller with three above and three below as you described.

What would be nice if if this type of mapping coordinate system of dodecahedrons could be intergrated into a stellar display program like CHView (at SolStation.com) or maybe Celestia (really don't know if that could be used since last time I looked at it was over a couple of years ago). You could use a red outlined dodecahedron for the origin point, orange for Jump 1, yellow for jump 2, green for jump 3, and blue for jump 4. Jump 5 could be light grey and jump 6 could be white (or slightly tan, off white). You point and click on the star and a seperate window pops up giving the players the star's type and the name and UWP of the mainworld associated with it. Clicking on a second button on that window will give you a page with more complete details about the entire system, all planets, larger moons, gas giants, etc. Make it usable on the web for chat/PBEM games and for the PC's desktop and notebook (and palm pads, if possible) for FtF games. I can't do it because I don't have the programming skills necessary.

Ah, guess I'll have to keep dreaming.......

 

[BetterThanLife]

Actually AstroSynthesis has that facility. Now if we can get the script done to give Traveller information instead of the built in data set. And that is done in true 3D. The question becomes how much of the LBB tables do you keep (with their built in problems, such as too many high pop worlds on rockballs right next to low population, zero tech, garden worlds or Class A starports with a population that isn't big enough to run a small Municipal Airport). If you have to throw out much of the OTU to go 3D anyway, wouldn't it make sense to fix that as well?

 

[BetterThanLife]

But lets look at the different possibilities, such as 3 layers up and down? How do you deal with the Z axis distance and Jump Drive?

That appears to be the major problem with taking the OTU 3D. You get too many stars, you seriously cut communication time, or you have to take multiple jumps to get from point A to point B. Jump-1 drives become virtually useless and Jump-2 isn't much better. But any adjustment to make the low Jump numbers work makes the higher Jump Numbers go screaming across the Sectors and Subsectors.

 

[Malenfant]

Or you could just ditch hexes and squares completely and put the stars where they really are (like the 2300AD map). Then you don't have to worry about tessellating or displacing hexes.

 

[Valarian]

How about just measuring the distance between two stars in parsecs and allowing jump engines to run while they have fuel. A ship has to make a definate decision to come out of j-space.

i.e. A jump-1 craft can travel 1 parsec in a week and uses the fuel stated. If it has enough fuel it can stay in j-space and travel another parsec in another week. A jump-2 craft would travel the 2 parsecs in 1 week.

Okay, the result of this is that a jump-6 craft can travel 1 parsec in 1 day 4 hours and use 1 sixth of the jump fuel for a normal 6 parsec jump. This may have a communication impact on the OTU.

 

[jfetters]

Originally posted by BetterThanLife:
But lets look at the different possibilities, such as 3 layers up and down? How do you deal with the Z axis distance and Jump Drive?

That appears to be the major problem with taking the OTU 3D. You get too many stars, you seriously cut communication time, or you have to take multiple jumps to get from point A to point B. Jump-1 drives become virtually useless and Jump-2 isn't much better. But any adjustment to make the low Jump numbers work makes the higher Jump Numbers go screaming across the Sectors and Subsectors.

Maybe the answer, if you are going to keep the traditional jump drives, is to level all the drives at about J3 or J4.

Alternatively, you could keep the higher drives and place key worlds at higher/lower points on the Z axis. It doesn't necessarily eliminate the ablility for the High J drives to zip across sectors, but there would be a lot more space to cross in order to get to a particular location within a sector.

 

[RandyT0001]

BTL, Astrosynthesis doesn't have dodecahedrons in it's mapping system, at least not in the trial version I DL'd a few hours ago. You can add jump lines to it and other things (and of course cannot save your work in the trial version). I'm not interested in this to "rework" the OTU by the way, that's impossible to convert to 3D. My interest is for an ATU or MTU.

I have no problem with the distances taking three Jump 1's to get from one system to the next. I am going to adjust the distance jump one travels to 3.333333 parsecs and since it's a TL9/10 campaign or TU I'll adjust other things to compensate (like the cost of ships and freight rates as examples).

As far as the star/systems generated by a non-Traveller method I'm looking for a bit more realism anyway. Astrosynthesis seems to use a more realistic system generation process based upon our current knowledge of how stars and planets form. I think one of it's faults is that it overgenerates too many systems, more than the averages we see from Earth, for a given amount of space, even when set to it's lowest setting. For example I made the sector one parsec in diameter and told it to generate systems and I got five systems. By what we have measured from Earth I should have gotten at most two, maybe, just maybe three. So I'll do a few more tests and see if it continues to overgenerate by a factor of three or so.

But I have an idea on how to use Astrosynthesis though. Hmmmmmm......

 

[rhoneycutt]

I just use a 10x10x10 cube and figure distances with pythagorus. The distances between worlds are not as per OTU, but its not like I'm using the OTU as my j-drives are slightly different. with 2d6, using 'rift' system presence rolls gives about 40 world per subsector...about the same as 'standard' density for the OTU. If I want sparser subsectors...I just use 3 dice and numbers to give the sparseness I desire.

System location is given by the position number, where the one's digit is the worlds position withint the subsector and the ten's digit is the subsector's position within the secotr < itself a 10x10x10 group of subsectors >

lots of worlds in a sector...but lots are relatively worthless rockballs unsuitable for settling.

 

[aramis]

There was a good discussion of how to do it somewhere on the board. A declining limit, IIRC, was basically agreed to be the best way...

So J6 is about 3.5 Pc, and J1 is about 2 Pc...