• 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.

Square (Sub)Sectors


I need to start mapping out my alt-TU soon. This means applying many of the ideas I've collected over the years to actually produce results. (OMG! :eek: )

Tonight's alternate astrography topic is square subsectors. I've long since given up on 3D space and non-hex mapping. There's just something elemental about Traveller hex maps. But I draw the line at rectangular astrography. I know others have used alternate subsector grids, so feel free to share.

Without running the trig, and just doodling on blank hex paper, I find that 8 columns of 7 hexes produces a fairly square, subsector-sized area.

Anyone have any other suggestions besides 8x7?
Why not hexagonal?

I'm just saying if you're going to stick to hexagons for system delineation why not base all your larger groupings likewise?

1 system is 1 hex

7 system hexes (central and 6 perimeter) make a province

7 provincial hexes make a subsector

7 subsector hexes make a sector

7 sector hexes make a domain

Just an idea I've toyed with now and again.
before you start should decide whether your mapping conventions will equal your political conventions. i.e. does a map segment equal an imperial governmental segment?

another consideration is who will use your maps, and how. the original 8x10 subsectors were employed because they fit in the little black books. do you want others to access your maps? by webpage? by printer? by poster-sized sheet?

yet another consideration is how much detail and information will be placed on these maps. full upp's, graphics, ports, anything else? it will all have to be big enough to read, which may determine your hex size, which will then along with your presentation access limitations determine how big of an area you can depict.

thinking of new ideas is fun. putting them all together in a coherent fashion not only is hard work, but also generates new ideas that must be addressed. least it does for me. good luck.
Originally posted by Silent Cartographer:
Without running the trig, and just doodling on blank hex paper, I find that 8 columns of 7 hexes produces a fairly square, subsector-sized area.
Keep in mind that because of that trig (and the staggering of the hexcolumns) an 8-hex wide subsector is actually 7 parsecs wide (6.93 to be exact).

So technically a 'square' subsector should be 7 columns by 7 rows.
I'd never considered a full-scale hexagonal progression, so I just gave that some thought. An interesting idea for sure, since it eliminates the hex vs. square transition. Self consistent, almost organic. It also strikes me a bit impractical, but I wanted to think about why it struck me that way.

It's similar to another idea I did think about, which was throwing the hex out altogether, and going full cartesian. You get the same consistency effect, by not mixing the styles of geometry. When we draw maps, we like to measure position and distance in the context of a cartesian coordinates.

The question here is, do you still use squares to approximate a location (just swap hexes for squares), or go with real coordinates? A coordinate star map is pretty cool looking, and adds an element of realism to the game, but not without cost. A player glancing at the map cannot determine viable jump routes without closer examination of the map or additional information.

Using square shaped spaces gives you simplified positioning, which makes movement easier to plot. Despite its natural fit in the cartesian grid, however, the square is a lousy movement grid. Great for position and distance.., but crappy for movement simulation. This is where the hex comes in.

The serious minis wargamer never needed any grid, because the tale is in the tape, so to speak. The tape measure tells you everything you need that isn't already obvious by looking at the table. Grids are used to abstract position and movement for games that can get by with simple counters -- much cheaper and easier than armies of painted miniatures! Orthagonal movement is awkward and unrealistic, if very easy. The hexagon therefore becomes a kind of compromise between gamism and realism. We give up easy cartesian positioning for improved movement simulation.

To me, though, going with a full-hilt hierarchical hexagon based system, is kind of magnifying the artifice beyond usefulness. Since movement is plotted only at the parsec level (and not at the subsector, sector, or domain level), its uselfulness on a Traveller star map stops there. IMHO, YMMV, etc.

Regarding cartographic and presentation issues...

IMTU, a hex represents an area location rougly 1 parsec in diameter, just as in the OTU. Subsectors should be large enough to encompass one or more small-to-medium sized clusters or pocket empires. It should also typically contain enough resources and wealth to justify a standard ducal fief (this can vary).

I am not plotting star positions on any strict coordinate system beyond placing them in a particular hex. Any particular jump rating is assumed to have the necessary range to reach destinations based on hex displacement only. No specific assumptions are made regarding the precise range of displacement delta for any jump rating.

Not straying very far into heresy so far. ;)

However, I really do like Rob's idea of collapsing sector sizes for MTU, so my sectors will be 4 subsectors in area, with 4 sectors making a typical domain.

For presentation, I am targeting both software display (possibly web, rich .net client, or both) and letter sized printed pages. The printed page should fit a complete subsector within the upper margins of the page while maintaining roughly canonical hex sizes (or bigger) on the page. The remaining lower portion of the letter page will contain world summary data and notes. I like and intend to cram as much symbolic data as I can into the hexes, so slightly larger hexes than the typical TAS form are oki-doki. Less lists, more geometry! :D

A sector map can easily fit in this same area on a single page as a dot map. Domain maps are not a major concern to me.

Didn't mean to burden y'all with all that, but since it came up...
Originally posted by Malenfant:
Keep in mind that because of that trig (and the staggering of the hexcolumns) an 8-hex wide subsector is actually 7 parsecs wide (6.93 to be exact).

So technically a 'square' subsector should be 7 columns by 7 rows.
Yep! That's pretty much what my thumbnail ruler-fu indicated as well. The resulting subsector is roughly 7 parsecs 'square'. My idea of square being that the area occupied by the hex grid forms a reasonably orthagonal square. The actual count of columns or hexes is not considered for the purpose of filling a square area. Is it even possible to have a symetrical hex grid (total columns = column hexes) form a reasonable square?

If 8x7 parsecs (56 total hexes) seems too small, the next nice square approximation up seems to be 12 columns of 10 hexes (120 total hexes, quite larger than the canon 80 hexes). I'm still a little unsure how "small universe" I want to go. I think it'll come down to how I decide to handle fief size vs. rank.

My 7 square parsec map is probably too small for a Duke, so I would either need to shift the ranks or increase the size. Still thinking out loud, here...
Originally posted by Malenfant:
BTW, you've seen my mapping page, right? Might give you a few more ideas.
Yeppers! :D

I once (years ago) imported the entire Hipparcos library into SQL Server, ran 3D cartesian coordinate scripts, and then ran a series of analysis queries to test the suitability of the data for gaming.

For example, I calculated the count of available J1 thru J6 destinations for every star within 100 parsecs of Sol. I then looked for destination density trends based on distance from Sol, testing the effects of near space 'dwarf pollution'. The results showed a marked drop-off of recorded stellar density as one moved farther from Sol. It was very pronounced.

Back on topic, here is a sample PDF document I whipped up for comparison:
Subsector Resize Sample


After cooking that up, I'm leaning back to the 7 parsec subsector again, heheh...
I would love to go full 3D. Astrosynthesis seems to be the key but I haven't been able to tweek the specs enough yet to get a Playable Traveller Universe. But man the possibilities....
I like the cool look of hexes and all, but if you're going to use real data, you may as well use squares. Diagonal movement can be safely rounded to 1.5 for the short ranges of jump drives. If you're just making up your map, or using published official maps though, then you can keep the coolness factor for hexes.
I gave up on using real astronomy data for MTU years ago. Job #1 is making a fun game. Realism has a role to play in that, but in this case my current opinion leans toward the simpler gamist pleasures of the funtastic hexagon, LOL.

If I had entire months of my life to devote to it, I might develop the necessary software to generate, manage, and display a truly gameworthy, fully 3D cartesain Traveller universe. My advice: don't hold your breath, hehehe...

Hmm, let's see.

Girlfriend, or Traveller 3D? Uhh...
New House, or Traveller 3D? Hrm...
Big Promotion, or Traveller 3D? Err...
61" HD Big Screen TV, or Traveller 3D? D'OH!!!

Dude, I am taking the TV! Anyway, the real question I continuously face is, actually play a real game with my real friends, or just indefinitely work alone on a game that will never happen?

Squaring off subsectors is an easy, modest change that adds a touch of verisimilitude at very little cost.
Has anyone tried creating a isographic or isomorphic drawing of a hexagon?

You can draw the grid a a isographic hexagon grid. Add an extra number to the hex identifier (ie, 010305 for the first column, third hex, height of 5)

You can put system icons hanging above the grid depending upon height, drawn from the back to front so that the systems look 3d (scale the systems in the back so they are a little smaller than those in the front).

I have all the stars within 1000 ly of earth in a firebird database. If someone can create a pseudo-3d hex grid for me, I can have a program generate the whole thing in a easy to game with manner.

I am not an artist in any way, but, I can measure a finished item to get the appropriate scale and slope. I am a programmer, so, for any budding artists who happen to be trained in drafting, if you want something like this generated, let me know and I can knock it off quickly.

best regards

IMTU I abandoned the standard 8x10 rectangles for a hex based subsector.

Don't have it with me right now, but it works out that you get a hex in the center, and each edge has 4 hexes to it. I think it came out at about 100 hexes per subsector.

Far trader, gread idea for grouping. I hadn't figured out how to put them together...Mind if I use your idea as a base to work from?

(after I file off the serial numbers...)
Originally posted by Dominion Loyalty Officer:
Far trader, gread idea for grouping. I hadn't figured out how to put them together...Mind if I use your idea as a base to work from?

(after I file off the serial numbers...)
;) Go for it. Let us know how it works and all. Silent Cartographer has made some good points to keep in mind, more thought than I think I ever gave it

I think it started because I wanted an alien map system different fromt the Imperial ones. It always bugged me that the Zho space was mapped the same as the Imps, the same as the Dogs, etc., etc. Just the names changed to make them "alien" sounding. Sure it might have all been published from the perspective of the Imperium, or just as a metagame simplification, but I was always hoping the Alien Modules at least would have done it differently.

Anyway, have at it and have fun :D
Well, I'm fairly convinced that nobody in a real setting would map things using hexagons - that's definitely an abstraction for our benefit as gamers.
Very true. It would still be neat to hand players a set of maps that they just pulled from an alien ship (or purchased) and have them laid out differently, after all they aren't Imperial maps. Even though the use of 2D and hexagons is an abstraction to support easier game play, it would still get across some of the feel of the situation.
Well it has been written before now that the hex maps are meant to be jump charts rather than astronomically accurate ;)

I once had an alien ship discovered whose jump charts were based on concentric circles rather than the hex grid.
I got the idea from the rake marks around a rock in a Zen garden ;)
It looks a bit like ripples spreading across a flat pond - each ring being one jump number further out - and a marker for each planet on the ripple circumference.
Plain grid squares would seem the easiest form to map on.

Perhaps a 3D system would be more appropriate for the Traveller setting and for actual space mapping.