Combining 2D and 3D Mapping

[Mithras]

Choice is a real bugger. In the good old days you had your hex map. End of story.

Today I have a fully featured 3D beautifully rendered immaculately detailed universe courtesy of the amazing AStrosynthesis 2.0 (and if I can use it, anyone can!).

But I hanker, yearn, for the 2D hex map. I want the old TRaveller experiencefor my players (my sons) with the wow factor of EVE-Online.

I've been able to create a working 2D subsector hex map of my polity, its not accurate (in that Capella, Castor, Aldebaran etc. aren't in their correct positions) but the jump distances between stars is close enough.

I'm just wondering if anyone's combined digital 3D with paper 2D and gotten away with it in play.... can I have my cake and eat it, or should I just make my feckin' mind up.

 

[PereX]

In my opinion: 2D maps seem outdated, but it is the best way to play only with "pencil and paper. " Any way to represent a number of systems (for example, 20-30 stars) in 3D is terribly confusing. There isn't a simple, usable and visually appealing way to do it, sorry.

The best way would be through a computer application, which showed the position of the 3D systems and calculate the distance jumps between them. But of course they would have ALL the stellar maps or Traveller redrawn...

 

[ssgbryan]

What IS this fascination with 3-d maps anyway?

Jump space is neither up or down. It is completely irrelevant whether Mora is 3 parsecs "above" Regina.

 

[sabredog]

What IS this fascination with 3-d maps anyway?

Jump space is neither up or down. It is completely irrelevant whether Mora is 3 parsecs "above" Regina.

I totally agree - jumping from one system to the next seems to be purely a function of a straight line from A to B. All the parabolic and 3-D referential positioning seems more applicable to in-system transit.

Even if jumping had a 3-D element wouldn't it be just part of the computations in the Nav program anyway? So the final map would look 2-D in any case with a marker just giving the total as Jump 1 or 2 or 3?

 

[Mithras]

Its not just the 3D positioning of the systems .... Astrosynthesis creates fully fleshed out systems. And creates maps of every world. You can right click on a system to see a 3D orbital simulation of all bodies in orbit in realtime. Or click on a gas giant or single planet to see it rotating with all its moons in realtime.

It includes so much nice stuff like that. You can import fractal maps from anywhere, any JPG actually with which to skin your planetary globes ... I use a nice piece of free software called PlanetGen.

The Notes section can hold your descriptions.

Its just all so visual and immersive. The 3D stellar cartography is just extra really.

I might use the 2D map in game, on the table. But use the Astrosynthesis software almost as library dara on the laptop, you know ... zooming in to the system, the planet, check out moons, click on details for atmospheric content, G, air pressure etc.

But use 2D for 'where do we jump to'...

 

[D. Foxx]

What IS this fascination with 3-d maps anyway?

Jump space is neither up or down. It is completely irrelevant whether Mora is 3 parsecs "above" Regina.

I personally don't see a need for a 3-d map for CT. However...

Mathmatically speaking, to determine the distance between two points in 3-D, "above" or "below" is relevant. If Mora was 3 Parsecs spinward and 3 parsecs "above" Regina, the number of parsecs between them would be aproximately 4.25 parsecs. A jump 3 ship covers 3 parsecs distance in 1 week, not 4.25. It couldn't make the trip mentioned. I don't think I would say the "above" or "below" factor is irrelevant.

2300AD used a "3d" map for the near star list. It was actually a 2d map that they tryed to add depth to by using small, medium, or large "stars". They provided X,Y,Z coords for each star that could be utilized, with a little math, to determine the distance between them.

 

[sabredog]

I might use the 2D map in game, on the table. But use the Astrosynthesis software almost as library dara on the laptop, you know ... zooming in to the system, the planet, check out moons, click on details for atmospheric content, G, air pressure etc.

But use 2D for 'where do we jump to'...

Then I'd do it that way - chrome is always good.

 

[Frankymole]

White Dwarf did an article on 3D mapping using the hex paper subsector.

The point of having 3D distribution was that you had more systems within reach of a jump, so didn't get "bottlenecks" where the players have to keep backtracking through the same system.

Also, fleet admirals could use several different routes to "outflank" an enemy so you didn't get the strange effect of a single line attack cutting off every direction in "space"!

 

[Icosahedron]

I agree that the mechanics of Jump are boiled down to a one-dimensional straight line between where you are and where you're going, but the difficulty is in representing distances accurately.
From any given start point, it is a simple matter to figure out the distance to any given destination, but it's not so easy to figure out the distance from a number of different systems. For example, picture four starsystems sitting in real, 3D space at the vertices of a tetrahedron. Each one is 2 parsecs from every other. How do you represent that in 2D? You can draw out an equilateral triangle, but where do you situate the fourth star? It has to be 2 parsecs from each of the others in the triangle...

I've never tried Astrosynthesis, but I have seen Celestia in use and I can see how immersive (addictive) it can be - if your computer is fast enough and you have enough hours in your day.

The nearest I got to a 2D/3D synthesis was by drawing out a sector in 6 layers. For a while I had a frame on my desk at home that resembled a Trek 3D chess set, showing the different layers of space.

There's no way you can do it with the OTU. That's purely 2D.

 

[Mithras]

Agreed. I think 'that way lies madness'

There's no way you can do it with the OTU. That's purely 2D.

 

[BytePro]

Not really - its very easy in point of fact.

 

[Mithras]

I heard someone was trying something along those lines with Astro 2.0. Is that madman you?

 

[Mithras]

For example, this is one of the worlds I've been able to create. Mazandaran, created in PlanetGen, editted with MS Paint, then used as a JPG to create a globe.

Its two main features are the purple vegetation, and the 'World River', that extends like the Mariner Valley almost around the globe. Its the blue ribbon, with purple vegetation either side, a little like the Nile Valley is flanked by a green zone.

http://www.youtube.com/watch?v=CosFx_XJ6sE

When you've got one of these for all the worlds in your subsector, it does get 'addictive' I suppose.

A couple of stills from my subsector (I'm not going higher than 25-30 worlds, max to retain the Traveller feel):

I'm going to try and translate it into a decent standard 2D hex subsector format tonight I think.

 

[BytePro]

Sorry, no - that's another madman

Program looks pretty decent, but I write my own. Did my first 3D Traveller map program back about 1983 (monochrome low res graphics back then, with no APIs). For fun, put the OTU in 3D when the classic reprints came out - it looks really sweet, but I never did anything useful with it. (Screen shots don't do it justice, of course... spinning it around and zooming is cool and originally planned on animating it)

My approach is 'cannon' compliant as far as I know - no need to change anything really. For completeness, a simple, but unnecessary, 3 word prepositional phrase (always optional in English) can be used and the rules accommodate 3D absolutely fine. Hence I find most amusing the debates about 2D/3D and flat universes...

 

[Mithras]

Intriguing... sorry I got you confused with someone else. Sounds like an epic work.

 

[BytePro]

Ah - wouldn't call it epic.

My programs for Traveller have always been pretty adhoc and designed to support RP. While I've always had other intents, the 3D versions just look pretty - alas, no picking, route plotting or searching features.

Ha - that planet is very much like those produced by an algorithm I snagged off the net and used many years ago. Re-written in assembler, it was not quite fast enough to allow zooming in infinitely (got around a few frames per second IIRC), but that was back on an XX MHz single CPU computer. However, I did not really like the look - my current approach (quite a WIP) is to 'evolve' continents and then add infinite fractal, procedural and hand made texture details. This has the bonus potential of tying in to automated naming and political boundaries. It also allows conscious design and facilitates merging with custom elements. But, don't be misled, this is also quite an 'epic' undertaking - so right now I am focused on just making better looking continent style designs. Clouds and atmosphere along with better lighting effects are also a necessity to my pedantic mind - something I've done some work on, but have never been quite satisfied with.

 

[Icosahedron]

Not really - its very easy in point of fact.

Ok, I'm curious. Consider six stars arranged in 2D in two lines of three like you see on dice, each one parsec from its neighbour. How do you raise any of them in the Z axis and still have them one parsec from the nearest neighbour and the outlying ones still two parsecs from each other? I can't see it.

 

[BytePro]

Sure you can - you already described it. Measure your 'parsec' only on the 2D plane.

I lack most of the books and have rarely played the OTU, but I suspect there are, at most, a handful of interstellar distances even mentioned. As interstellar distance in Traveller is only really about jump distances, why assume the 'distances' are in 3D?

Note, in real life, we do a similar type of projection simplification all the time (pun intended) - as most distances are actually dependent on 4 dimensions (i.e. time). And I won't even get into how almost everything else, space travel mechanics-wise, is essentially ignored (from relative orbital positions and stellar system motions to relativity).

If one wants to be pedantic about it, call it a 'jump parsec' if you like and leave it otherwise undefined. Or use my implied 'on the jump-plane' approach. Parsec can very easily be defined, for purposes of the game, as generally referring to the special case of a measure of distance on a 2D projected plane.

The approach I use limits the effectiveness of jump above and below a 'central' jump-plane, and thus, it effectively becomes a 'flat' universe for purposes of FTL. BTW: the actual 3D distances from the jump plane can determine canon variation in time for the jump (I have a non-linear formula that makes the time go infinite past a limit and fit in the CT rule time frames otherwise).

Now, rationalizing why a J-6 drive takes the same time as a J-1 to travel 1 'parsec' or how all systems are integral parsec separation distances, even on the flat 2D map, is another issue entirely... o:

 

[Icosahedron]

I see. Glad to note my brain wasn't failing.
I'm not an OTU purist, so I won't comment further on your adaptation - it's only concern to me was whether I'd missed something from my geometry studies.
I devised a formula for Jump travel too, mine doesn't go infinite, though.