3D mapping

> 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