• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.

2-D vs 3-D Mapping Experiences

SpaceBadger

SOC-14 1K
Knight
I've been making notes on a new TU since January, and really need to get some mapping started to proceed further. My dilemma is whether to go ahead now and do it in the traditional Traveller 2-D scheme of hex mapping on paper, or wait until I can buy software to map in 3-D.

My purpose in making this thread is to think-out-loud some of the pros and cons to each choice, and get some input from others here, especially those of you who have actually used a 3-D map system for Traveller.

*****

2-D: Traditional Traveller Maps on Paper

Pros:
- Easy to visualize relative locations and distances. Gamers are familiar w flat maps of all kinds, and Traveller players are familiar w subsector and sector maps.
- Easy for me to make. If I don't find a free universe generator that I like, I can do it myself in Excel and Access. I am familiar w Access and can make a database that will be easily maintained and customized, and can make any queries or reports that may prove useful in universe creation or in game play. I have lots of blank hex maps and can print more as needed.
- 2-D mapping provides the information most often needed in game: Where are we now, and where can we get to from here?
- I can do this right now.

Cons:
- 2-D is unrealistic, as the universe seems to be laid out in 3-D. A flat map does not provide as many alternative paths to or around a given location as would be available in 3-D.



3-D: Software Display (or flat simulation such as 2300AD Near Star Map)

Pros:
- More realistic. Allows more alternate paths to get somewhere, and requires governments to plan and defend in 3-D rather than having neat borders.
- More systems fit into a compact sphere or cube of space compared to a large number of flat-mapped sectors.
- Coolness factor. 3-D computer display of multiple star systems, zooming in or out for detail or perspective (especially if 3-D display of planets in system is included) seems a lot more like what spacers would actually use.
- Integration of map with library data about systems and planets (assumed?).

Cons:
- I don't have software to do this right now, and for various reasons can't buy it for awhile. This is delaying progress on the new TU I have been working on.
- I don't relate well to paper simulations of 3-D, such as the 2300AD Near Star Map or the StarForce map.
- I don't know how well I'll be able to visualize with the software. I've had some discussions here on CotI that make it seem pretty awesome, but have not tried it myself, so am not sure whether it is worth delaying until I can use it.
- Some of what I have read suggests there are limits on display with low-end computers (such as mine), and limits on the number of systems that can be saved and displayed. I would not have either of these problems with an Access database and paper maps.


So, help me out, people. Is it worth waiting until I can buy 3-D software (AstroSynthesis has been highly recommended), or should I just get to work w tools that I already know? (I don't think that converting later from 2-D to 3-D is something I want to do.)
 
You don't need to buy any software...

Excel and Access have VBA that should suffice: ala http://www.doka.ch/Excel3Dscatterplot.htm

There is also a bunch of free software, that with a little effort could certainly meet your needs - such as 3D apps like Blender, Sketchup or POV Ray (non interactive). You can generate your TU as a text file from Excel, Access (or Notepad) for use with these programs. Better yet, you can make it for Celestria (though, link at http://www.shatters.net/celestia/ doesn't work for me at the moment... hmmm?).
 
Perhaps if realism is the main reason for going 3D, to me, the benefit is too little. The costs in time, possible money, and limiting the ability to review map information to only when in front of the program, too great. You already state that
I've been making notes on a new TU since January
It doesn't sound like you have much time to spare. Of course, for some, the joy is in the creation and they never even play the game with others.

I think of Traveller as a role playing game and acknowledge that mechanics and rules in the game may not be 100% realistic but are necessary to help make things playable. It would be different if this was a explore and conquer space simulation game.

Pros:
- More realistic. Allows more alternate paths to get somewhere, and requires governments to plan and defend in 3-D rather than having neat borders.
While true, this is just one small step. For example, how about the fact that all system are an exact number of parsecs away from each other. No systems .8 or 2.2 or other non whole number distance in parsecs.
- More systems fit into a compact sphere or cube of space compared to a large number of flat-mapped sectors.
Does this add to the role playing at all? Not really. Will this require lots of additional work, not just in mapping, but in planning out the whole history of your TU and how the different races colonized, traded, warred, and so on? Definitely.
- Coolness factor. 3-D computer display of multiple star systems, zooming in or out for detail or perspective (especially if 3-D display of planets in system is included) seems a lot more like what spacers would actually use.
So it looks cool, but is it playable? Can you just ask it to show you all the systems that are within jump 2? Show me the quickest route from our current location to some destination? Now show me the safest route and calculate the difference in time?

I have no idea what the capabilities of this software are but it will never come close to a futuristic voice and motion interactive computer with holographic display (depending on time frame and TL of your TU). Perhaps a benefit of using a 2D map is it helps simulate the ease of which people would have in interpreting the information.
- Integration of map with library data about systems and planets (assumed?).
This has nothing to do with a 3D universe and could be done with 2D as well.

Additional Pro: If this is something you will enjoy, why deprive yourself?
 
Last edited:
Think of your game universe as a narrative vehicle. When telling a story characters go from A to B to C ... one dimensional. In a game you want to offer choice ... a two dimensional world gives you that. So what does a three dimensional world give you? Sure it's more "realistic", but from a narrative point of view what does that extra complexity give you?

Answer: it depends on your players. If they highly value 'realism' then the addition of a third dimension will improve their overall enjoyment. But many will be perfectly happy with a more abstract two dimensional world, especially if it frees up the referee to concentrate on building better stories.
 
There's a decent enough 3D map program for 2300 (WARP2010) that I've used.

However, fairly simple python scripts or basic programs can handle fairly small setting maps and filtering for specific world and connections in reach, at least if you don't want a 3d display.

It's all about managing the database...

steps:
1. Input key system
2. input maximum distance
3. search database to find key system's xyz
4. sequentially retrieve each system
4.1. calculate distance
4.2. if distance < maximum, add to system database
5. output result database.

A lot of the issue is how one handles the database - array loaded from file, sequential file alone, data statements in program, directory listings...
 
A compelling story with good characters and keeping things interesting almost make the difference irrelevant. I suppose if you are playing some sort of strategic version where the arrangement of the systems is important it might make a difference but with your typical small group of players I'd think the space in between systems is pretty much irrelevant.
 
A compelling story with good characters and keeping things interesting almost make the difference irrelevant. I suppose if you are playing some sort of strategic version where the arrangement of the systems is important it might make a difference but with your typical small group of players I'd think the space in between systems is pretty much irrelevant.

I tend to disagree... especially when allowing players control over a ship.

My players prefer, as a rule, 2d maps... I prefer 3d..
 
I'd love to map MTU in 3D but sanity prevailed. My problem is with the thickness of any mapping unit.

If a Sector is 32 parsecs wide, common sense says its also 32 parsecs thick or high. If the Galaxy is approx 300 parsecs thick how can I ignore the bits above or below the sector. I have to add more layers of sectors.

That's fine it can all be done (and done with any variation of the numbers above). But, it's hard to represent to players.

2D maps are nice because players can glance at them and see how near something is.

In game there are two common explanations that I have seen used:

  • The map reduces 3D space to a 2D representation
  • The map actually shows the distances via Jump space not real space

Space is big, bigger than a map I can unfold on my kitchen table.
 
Last edited:
Aramis said:
My players prefer, as a rule, 2d maps... I prefer 3d..
Yeah - I've always preferred 3D maps. 2D starmaps just plain don't feel right at all. The hex maps are cool looking - and love the world maps - but, space, well, it just calls for 3D to me...

Honestly, though, don't think my Players really cared one way or the other.

Early days I used Mylar sheets and foam balls on sticks that were fun to make, but quite impractical. Switching to computer programs, though, really makes 3D starmaps an enjoyable and useful prop. It also matches the genre much better than wargaming hex grids. Note I'm not talking about realism - my stars don't move in relation to one another nor are their distributions 'realistic'... its just a playing prop, like ID cards and deckplans.
 
I use 8 deep 3D subsectors, and four 3D subsectors depth for a 3D sector.

So, IMTU, a sector represents vaguely 32 by 40 by 32 parsecs of volume.

I say vaguely, because I kept my system entirely compatible with CT rules. I use a jump plane based on hexes. 'Parsecs' between systems are integral number 'jump parsecs' based on the jump plane, not on actual measured distance - which can otherwise span over 32 'true' parsecs for jump-1.

This is easily represented on a 2D map, because I don't allow stars to 'overlap' - its just an 'elevation' from the jump plane. I use alpha, beta, delta and gamma sector naming to avoid +/- signs and also for Sci-Fi coolness ;). So my 3rd dimension doesn't factor into 'jump distance', however, it does factor into jump duration as I created an equation that spans the time range provided originally by CT LBBs. An ingame artifact of the the 'jump plane' is that jumps are limited to 16(+.5) parsecs above and below the plane. Sure, its a hack to match the metagame restrictions, <shrug>, but I can 'handwave' it as jump physics being an artifact of some localized space time defect (planar cosmic loop <wave, wave>).

So I maintain 100% compatibility with CT LBB rule mechanics, even providing a time mechanic that was missing (ignoring any JTAS articles that I never had). I refer to jump distances using parsecs to mean 'jump parsecs' in context, as opposed to 'actual' distances. This is much the same way starship references use tons colloquially, but actually implies 'displacement tons' not mass units. Means 2D maps are still useful - and easy to read - while supporting a more immersive 3D experience...
 
A sector is 32 parsecs wide (and 40 long). Common sense could also say that it's only 8 parsecs high (width of one subsector).

Thanks for catching that slip.

Common sense varies :D but if subsectors are subdivisions of the standard unit which is the sector it just makes more sense to me that it would be as high as it is wide.

Of course isn't the only reason that Sectors and subectors are the shape they are because the fill up a standard page nicely? That is however a good enough reason to make it a mapping convention.
 
The pros & cons are you to consider, however, if I were to switch to 3D, my inclination would be to change the size of a subsector so it was a cube. Perhaps 8 x 8 x 8 or 9 x 9 x 9. The latter because that would be J6 + 50%, and give you a firm middle point which even number of parsecs would not.

Just IMO
 
I liked the 3D mapping that SPI's Universe used. No software needed. But Traveller has excellent 2D mapping.
 
You don't have to mess with fancy-schmancy 3D mapping software to pull this off: just use TSR's old Star Probe as inspiration. That game had a perfectly simple way of representing 3d space on 2d maps.

*0 = a star on the plane of the map
*3 = a star three hexes over the plane
*2 = a star two hexes under the plane (note the underline).

Nebulae, or other multi-hex-spanning objects can be notated similarly.
Personally, I don't like the extreme density of stellar objects in the official Star Probe map, but one can create one's own map with much more comfortable distributions.

Simple. :)
 
You don't need to buy any software...

Excel and Access have VBA that should suffice: ala http://www.doka.ch/Excel3Dscatterplot.htm

Thanks for the link! I DLd the zip, will need to read the pdf to see if I can figure out how to use this. I have never gotten into the graphics of either Excel or Access, just created business records databases w necessary queries and reports, and scripting as needed for forms.

There is also a bunch of free software, that with a little effort could certainly meet your needs - such as 3D apps like Blender, Sketchup or POV Ray (non interactive). You can generate your TU as a text file from Excel, Access (or Notepad) for use with these programs. Better yet, you can make it for Celestria (though, link at http://www.shatters.net/celestia/ doesn't work for me at the moment... hmmm?).

Sounds like I will need to study more on Sketchup, as I currently have no clue how to take a bunch of x,y,z coordinates in text and map them, but I like this idea.
 
Thanks for the link! I DLd the zip, will need to read the pdf to see if I can figure out how to use this. I have never gotten into the graphics of either Excel or Access, just created business records databases w necessary queries and reports, and scripting as needed for forms.



Sounds like I will need to study more on Sketchup, as I currently have no clue how to take a bunch of x,y,z coordinates in text and map them, but I like this idea.

Start by deleting the woman from the default new drawing. Next, draw a line on green axis equal to the X. Then, a second parallel to the red axis with a length equal to the Y. Then a parallel to the blue equal to the Z axis. Put your star object on top of that line. Delete the three lines.

Add next system.

Attached is a sketchup file that took about an hour...
 

Attachments

  • NSL2300p1.skp
    70.2 KB · Views: 11
Last edited:
I've used Wings 3D to do my 3D work (what I haven't done inside SecondLife). I tried mapping elements of a binary system to get a visual of how the night/day thing would go, but I mucked up the scale at one point so it doesn't make sense. I've created a ship model in it (exterior only, with no detail). And, I've built a notional 3D subsector (only allowing a +-2Z IIRC).

The 3D work is harder than 2D work, certainly. It's an advantage in some things, though.

Will any of these free 3D programs let you do movement? To get the solar system model I was working on, I had to take a pic, then go move everything for a certain time period, then take another pic, then move everything, then take another pic........ I was hoping to *not* have to do claymation work in the '10s.
 
Realtime interactive or just creating motion paths and letting it rip?

Only addressing free programs, not demos or restricted commercial programs..

For a solar system simulation, I'd go with Celestria (or any of a number of others that are made for astronomy).

You can do 'real-time' animation in both Blender (http://blenderartists.org/forum/showthread.php?272988-Addon-Real-Time-Animation) and in Sketchup (using scenes). Blender will more readily give purdy scenes, but Sketchup is more approachable (being more CADD than modeler). Moving around a static 3D scene is easy and built-in, but handling complex orbits might be a challenge for both and require coding (script).

POV-Ray (or one of the many text or RIB based programs) would allow you to directly write up the orbits and there are probably examples on the web. With no interactive GUI or API to deal with, its actually probably easier overall to do than with the other programs. Once done, it would be easy to generate other systems - much more so than the other programs. But its not interactive - you would generate a movie or scene, not a 3D model you could manipulate in real time.

While free and approachable, I don't think any of them will make it 'easy' without some time spent on their learning curves.

[Note that you can do 4D (3D plus time) solar simulations in Javascript, especially with WebGL, with nothing but modern browser and text editor (which is even built in for Firefox). Well, with know-how and time. ;)]
 
Back
Top