3D mapping

A thread of 4 messages, 24 October 1993 to 2 November 1993, in the order they were sent.

#6231 3D mapping

Timothy Little · 24 October 1993

> Mapping traveller maps into 3-d isn't that bad.  I did it back in HS
> (circa 1983).  But what you have to do is drop the damn hex grid.  You
> map all the stars into spherical coordinates.

You can (if you like) retain the hex-grid.  However, just as a hex grid
gives better adjacency than a square grid (6 neighbors to each grid point
as opposed to only 4), you can get better adjacency by shifting adjacent
planes of a stack of hex grids in 3D.  It looks really clumsy in text, so
I'll try to draw some pictures.

Instead of using layers of hex paper like:
 __    __        __    __        __    __
/  \__/  \__    /  \__/  \__    /  \__/  \__
\__/  \__/  \   \__/  \__/  \   \__/  \__/  \
/  \__/  \__/   /  \__/  \__/   /  \__/  \__/
\__/  \__/  \   \__/  \__/  \   \__/  \__/  \
/  \__/  \__/   /  \__/  \__/   /  \__/  \__/
\__/  \__/      \__/  \__/      \__/  \__/
   Layer 1         Layer 2         Layer 3      etc...

Where each hex has 8 neighbors; 6 around it, 1 up, and 1 down:

                       1
                   2       6
         7             *               8
                   3       5
                       4

Use a simple shifted pattern like:
    __    __       __    __       __    __    _        __    __
\__/  \__/  \    _/  \__/  \__      \__/  \__/     \__/  \__/  \
/  \__/  \__/     \__/  \__/      __/  \__/  \_    /  \__/  \__/
\__/  \__/  \    _/  \__/  \__      \__/  \__/     \__/  \__/  \
/  \__/  \__/     \__/  \__/      __/  \__/  \_    /  \__/  \__/
\__/  \__/  \    _/  \__/  \__      \__/  \__/     \__/  \__/  \
/  \__/  \__/     \__/  \__/      __/  \__/  \_    /  \__/  \__/
  Layer 1          Layer 2          Layer 3          Layer 4       etc...

So that each hex now has 12 neighbors:

                       1
      7             2     6            11
         9             *            10
      8             3     5            12
                       4

It looks much clearer if your hex maps are done on transparencies,
which you can get by photocopying a normal hex grid onto plastic sheets.
(If you only have access to white-lines-on-black, some photocopiers can
do inverse print - otherwise, you can buy hex paper or draw your own)

> There are mapping functions between this and Cartesian Coordinates.
> And yes you need a computer to do all this, I've had a good
> programmable calculator since HS.  So it was no problem.  You also
> need a computer/good calculator to do the jump calculations.

I don't see any need to use spherical coordinates, since Cartesian is so
much easier to handle.  For one thing, it doesn't matter where you put the
origin, since you can change it by simple subtraction.  Even the distance
between two points (*horrendous* under spherical coordinates) can be done
on a simple `4-function' calculator (since most also have square-root).

> Yes, representing a 3D start chart on paper is difficult. GDWs Near
> Star Chart for 2300 was pretty nice, but it's deceptive because to
> dots on the chart that are right next to each other can easily be on
> opposite sides of the sphere.
>
> One thing that popped to mind was an actual physical model -- ala
> tinkertoys or maybe those smokey sausages on toothpicks (of course
> that model may not survive the gaming session 8-) 8-). But, if your
> area of space is small enough, a small model may be feasible, with the
> sticks being color coded for length and maybe just showing popular
> jump routes.

One idea that may or may not work:  with transparent hex grids, you could
put a hole in each corner, and put some thin rods through them.  Maybe
you'd need some more through the body of the map to prevent it sagging in
the middle.  Anyway, if that worked, you might get a needle and some
coloured thread to show common jump routes, or something.

> On the other side of the coin there are a couple of stat programs (the
> original was something like "Mac Spin") that allow the entry of 3D
> data, and then you can maipulate the "Cube of Data". You can spin it
> around, flip it, whatever, on the computer screen. I'm pretty sure I
> read somewhere that GDW used such a program to create the 2300 Map.
>
> Of course, the detail is that you'll need the machine at the table.

Yes - that's why I tend to shy away from relying too much on my computer.
Of course, I use it extensively for typing up notes and other non-realtime
stuff.  I'm a programmer, so I can do whatever I want  :-)
The problem is finding the time to fiddle with horrible little buggy bits of
code and wading through poor documentation  :-(

> The only place that 3D would change the "feel" dramatically, is in
> tactical space combat. But even then, all it really changes are the
> approaches of the units as they engage. One-on-One...wouldn't really
> matter. Two on one, well...3 points define a plane... Several on one
> it may get sticky.

3 points define a plane, sure, but 3 moving points define a moving plane,
and the tactics of a moving plane differ from those of a static plane.
For one thing, a straight line path (often costing no `maneuver points' in
space battle games) in 3D space maps onto a complicated curve (costing many
`maneuver points') in the case of a plane defined by the positions of the
other 2 ships.  Furthermore, objects that should be "fixed" (like planets)
will need to be counted as a "ship", since they will not in general lie on
the plane defined by the 3 ships.

To make an analogy, you might equally well say that 2 points define a line,
and that therefore any 2-ship battle can be played on a line...
Think how much easier a point-defence objective would be if the enemy had to
*literally* go straight through you to reach its target!

2-ship battles simulated in 2D are not quite so bad, assuming that only
relative velocities matter, and that orientations and `absolute' velocities
don't.  Unfortunately, no space combat game I've seen has both these
conditions, so 2D is even inadequate in the simple 2-ship case.

- --
Tim Little

#6239 Re: 3D mapping

George W Herbert · 25 October 1993 · reply to #6231

>From: Timothy Little [email removed]
Subject: 3D mapping
Date: Sun, 24 Oct 93 14:09:33 EST

>You can (if you like) retain the hex-grid.  However, just as a hex grid
>gives better adjacency than a square grid (6 neighbors to each grid point
>as opposed to only 4), you can get better adjacency by shifting adjacent
>planes of a stack of hex grids in 3D.  It looks really clumsy in text, so
>I'll try to draw some pictures.

>Instead of using layers of hex paper like:
[very good ASCII graphic deleted]
>Where each hex has 8 neighbors; 6 around it, 1 up, and 1 down:
>Use a simple shifted pattern like:
>So that each hex now has 12 neighbors:
>It looks much clearer if your hex maps are done on transparencies,
>which you can get by photocopying a normal hex grid onto plastic sheets.
>(If you only have access to white-lines-on-black, some photocopiers can
>do inverse print - otherwise, you can buy hex paper or draw your own)

There is much to be said for the offset-stacking method.  There are also
good reasons not to use it.  Primarily, it makes mapping with anything
BUT maps-on-transparencies much harder to "see" what's going on.

I chose to have a straight-stacked map for my 3D subsector map,
with 8 neighbors (6 on same level and one above and one below),
and am cheating a bit and also giving a better distance function
if you want to shave a couple of parsecs off that jump (which makes
the systems at up/down one and over one 1 parsec away for jump
purposes, though they're really 1.414 (sqrt(2)) away...).

It's not as realistic, but it's much easier to visualize.
The whole point of using very large-grain hexes is to simplify;
Traveller 2D could have mapped using cartesian coordinates in
much finer detail, but they simplified to keep it straightforwards.
I think that applying that methodology to 3D developments is
a good idea.

- -george william herbert

#6252 Re: 3D Mapping

[unnamed sender] · 26 October 1993 · reply to #6239

3D mapping was discussed some time ago and somebody then pointed
out that the 2D Traveller maps just weren't showing all systems
but just the interesting ones.

If you take the 2D map in this light then you can treat JUMP
drive as a 2D mechanism.  I tinkered with this idea back then
and came up with some basic assumptions.

The Traveller 2D maps are simply a 3D universe squashed flat and
only showing interesting systems.

A JUMP can only travel it's JUMP rating in 2D but in the 3D
universe the source and destination may also be vast distances
apart in a vertical direction.  This vertical distance does NOT
affect the 2D distance that can be travelled.

If two or more interesting systems do end up in the same 2D map
location then you still would need to JUMP (for a week) to get
to each system from any other system in that hex.

What this tells me about the Traveller universe is that their are
either very few star systems and most are interesting or that
their may be many star systems that are not shown because they are
not interesting.  A uninteresting star system in the Traveller
universe would have to be totally devoid of matter other than
the star(s) themselves and therefore not worth mapping or
visiting(?).

To map this type of Universe in 2D all you need is larger hexes.

If you take a sub-sector map and increase it's size so that each
hex contains 7 hexes (a centre and six around it - call it a super
hex) then you can map each of these vertical matching locations into
one of the hexes in the super hex.

If a super hex of 7 hexes is not enough then the next size up is 19
lesser hexes to a super hex.  Scale your universe to suite the density
of stars you prefer.

What do you think?

Bruce...        [email removed]

"If you swallow a live frog first thing in the morning ...
 Nothing worse will happen to either of you for the rest of the day."

*******************************************************************
* Bruce Pihlamae  --  Database Administration                     *
* Commonwealth Department of Health, Housing & Community Services *
* Canberra, Australia                             (W) 06-289-7056 *
*******************************************************************
* These are my own thoughts and opinions, few that I have.        *
*******************************************************************

#6295 Re: 3D mapping

THOMS, KEITH · 2 November 1993 · reply to #6252

From Bruce Pihlamae ...
>Date: Wed, 27 Oct 1993 08:35:33 +1000
>From: [email removed]
>Subject: Re: 3D Mapping
>
>
>3D mapping was discussed some time ago and somebody then pointed
>out that the 2D Traveller maps just weren't showing all systems
>but just the interesting ones.
>

  This has been my interpretation, too.  Keeps it simple so you
can spend more time adventuring.

  From what little I remember about stellar statistical distributions
the vast majority of stars are red dwarfs that have little or no
adventuring value in Traveller.  That and darker matter are what make
the jump calculations so difficult.

  Can anyone on top of matter distribution suggest a gaming reason
to include these systems in an adventure?


>If you take the 2D map in this light then you can treat JUMP
>drive as a 2D mechanism.  I tinkered with this idea back then
>and came up with some basic assumptions.
>
>The Traveller 2D maps are simply a 3D universe squashed flat and
>only showing interesting systems.
>
>A JUMP can only travel it's JUMP rating in 2D but in the 3D
>universe the source and destination may also be vast distances
>apart in a vertical direction.  This vertical distance does NOT
>affect the 2D distance that can be travelled.

  Good explanation as any!  Does anyone think it'll affect any
game mechanics or history?


Keith Thoms

- ---- Is it a rule that there is an exception to every rule?