Galactic Astrography for Traveller

[robject]

Put your pet concept for Galactic Astrography for Traveller here.

Do you think the Ring/Ray system is fine? Say so. I'm not convinced. While it works for a 400-parsec band around the 10,000th ring, it doesn't work everywhere else.

Do you think a simple cartesian system would work? I'm not convinced. It might work better than Ring/Ray, though.

So far, all I've got is a scheme to fix the number of sectors around the core, and vary the width of said sectors. It's not sufficient, though, because I don't like the idea of "partial" subsectors.

Maybe a system which adds four parsecs' width at a time, effectively widening each subsector by 1 parsec as you go out.

 

[inexorabletash]

Even at the same Ray, at 90 degrees offset from Reference, all the hexes will be sideways if you want sectors to be 32x40 oriented Corewards. (And the food will fall off the table, don't want that!)

I wouldn't try to apply the notion of sectors/subsectors far from Charted Space. Ring/Ray works if you have hexagonal rings (like a giant j-6 map). Then six "sectors" (geometric term) of the galaxy have a traditional flat-topped hex grid with Coreward up as Yaskodray intended.

There are some GDW publications with rotated (pointy top) hex maps for small regions.

 

[BytePro]

Capital-centric d, r coords, where r is the 'distance' around an arc originating d parsecs along a line from Capital towards the galactic core and measured in the direction of the galactic spin. I.e., from the map below:

Capital = 0, 0
Knabbib = 3, 0
Sentark 4 = 3, 3
Sevan = 3, 6
Siduka = 7, 0
Khuuma = 7, 7
Kuggar = 7, 14
Eliograh = 7, 21
Eorvin = 7, 28
Dudaka = 7, 41

All coords are positive, and there are d*6 hexes around a given 'jump ring', so simple math can indicate direction from core directed line. (I.e. polar coordinate style.)

Of course, one could make the center the central parsec of the galactic core, but then the number would get unwieldy...

 

[Dragoner]

How does Travellermap work? That is what I use.

 

[inexorabletash]

Offset Ring/Ray.

From http://travellermap.com/api.htm#systems

"World-space coordinates are more compact than Sector/Hex coordinates, requiring just two numbers. The transformation is simple, and based around Reference (Core 0140). In this scheme, Reference is at 0,0, positive x is Trailing and positive Y is Rimward."

(Actually, multiple coordinate systems are used, but that's the most useful in-game system.)

But I'm not trying to represent locations too far from Charted Space, so this isn't what robject was asking about.

 

[BytePro]

BTW: For programming - originally used the zig-zag y row pattern ala the subsector map grid, but later used x and y with the y axis angled in (in line with the NW edge of a hex) such that x columns are lined up vertically and y rows are slanted NW to SE.
y /
/__
x
It makes for easy and numerically cheap calculations of distance between hexes (not that the other was too hard with MODs, but this way is more elegant) and works well for world map grids.

 

[inexorabletash]

Capital-centric d, r coords, where r is the 'distance' around an arc originating d parsecs along a line from Capital towards the galactic core and measured in the direction of the galactic spin.

...

Of course, one could make the center the central parsec of the galactic core, but then the number would get unwieldy...

I agree that that would be a sensible system for galactic coords, and possibly a concrete adaptation of CT's Ring/Ray (except centered at the galactic core, the "Prime Meridian" goes through Reference, and Trailing is positive).

The wrinkle is that the coordinates basically "bend" along the prime meridian, so coordinate transforms in Charted Space would be nontrivial I hadn't thought that through in my earlier post.

 

[robject]

Ring/Ray isn't bad. The problem there is how to divide up space -- The Traveller's Book suggests thinking in Bands 400 parsecs wide or deep, but doesn't offer advice beyond that.

Practically (i.e. this is a game with a history of doing things a certain way), I would think the unit of astrography is still the subsector: an 8x10 parsec chunk of space. This seems to be true, regardless of where that subsector is.

That makes the interfaces weird --- when the number of parsecs per ring changes, an extra hex gets shoved in somehow. Or, perhaps we wait until there's room for 8 more hexes, and shove in an entire subsector. Galactically speaking, that's still a small space, although I'd hate to explain it graphically.

Example. There are 7854 subsectors in Ring 10,000. However, there are only 7853 subsectors in Ring 9,999, and 7855 subsectors in Ring 10,001.

In the larger scheme, this poses no problems at all. Calculations need not be precise at these distances, and error is minimal. Charted Space certainly doesn't care.

And yet, between these three Rings, two new subsectors pop into existence. Can we map this? Ought we even try? Is it even detectable in local space?

 

[robject]

I think I'm over-thinking things.

 

[BytePro]

Er, if you are trying to make 'cannon' consistent against itself - probably.

I'm not real familiar with this ring/ray concept - but if the 'imperium' fits in one ring/ray region, then mapping isn't really a problem in terms of regions. Regions away from ring 10,000 will end up with special case sizes - and more/fewer regions. If you want consistency with 'core expeditions' make those rays (probably only one or two, I suspect) of fixed sizes and vary ones on the opposite side. <shrug>

Distortion of distance measures (parsecs in this case) is inevitable when transforming an offset (hex) Cartesian style grid to a polar style coordinate system. This is also synonymous with RW 2D mappings of the Earth. In a Traveller: with hex world maps requiring 12 pentagons.

[IMTU hex maps are just the projection of my 3D TU onto a plane with markers at hex centers to represent systems and relative jump requirements - a jump-map.]

 

[Dragoner]

The named plus four digit coordinates work fine, somehow I'm not seeing the extra subsector?

The Zho core route runs into all red zone asteroid belts.

 

[robject]

Picture galactic coordinates measured outward from a designated centerpoint. The 'ring number' is at a given radius, in parsecs, from that center.

Reference/Core is conveniently located on the 10,000th ring.

Simple math (the only kind I do nowadays) suggests that this ring has a circumference of 2 x pi x r parsecs; that is, 62,832 parsecs.

Okay so far.

We can even assume that, for all practical purposes, this width is within a reasonable margin of error for some distance in and out from the 10,000th ring. After all, jump is probably accurate within certain tolerances... the 400-parsec-deep "track" is sufficiently sensitive, even at the subsector level.

So every 400 parsecs, another subsector can be added. On the inner edge, a hex is a wee bit tighter than one parsec, and on the outer edge, a hex is a wee bit looser than one parsec -- but it's small enough to fit within a reasonable error.

At least for awhile.

For game purposes it would be as though Charted Space is in a 1,000-parsec wide band, like a narrow strip of paper taped into a loop.


From Ring 9800-10200 there are 7854 subsectors
From Ring 9400-9800 there are 7540 subsectors
From Ring 9000-9400 there are 7226 subsectors
From Ring 8600-9000 there are 6912 subsectors
From Ring 8200-8600 there are 6597 subsectors
From Ring 7800-8200 there are 6283 subsectors
From Ring 7400-7800 there are 5969 subsectors
From Ring 7000-7400 there are 5655 subsectors

...and so on. A change of 300 subsectors is dramatic in the lower Rings, but relatively ignorable around Charted Space.

My preference would be to standardize into an easy approximation: 300 subsectors wide per Track, where a Track is 400 parsecs deep, with an offset of 200 parsecs for the core. So for Track #24, the circumference is 300 x 24 = 7,200 subsectors. Track #25 starts at Ring 400 x 24 + 200 = 9800, and ends at Ring 400 x 24 + 200 + 400 = 10200.

 

[Dragoner]

While I understand what the ring is, it really doesn't fit sectors and subsectors that the game uses; sectors that take years really to make.

 

[inexorabletash]

I think attempting to extend a single sector/subsector grid around the galaxy is not useful. They are useful administrative chunks of space (and conveniently fit on a piece of paper), but trying to make them the lat/long divisions across the whole galaxy seems like overthinking thing.

 

[Dragoner]

I have been working on my four little sectors for three years, I added two more, but even then they seem partially done (the orignal four for which I have fairly extensive notes). I'm leery of seeing things stat'd out without actually delving into them, and then thinking the galaxy... wow, thinking of how big a project that would be.

 

[BytePro]

I would agree in the sense that a UWP really doesn't 'define' a system for play as much as a well crafted backstory, detailed locations, social and government details, local corporations, facilities, spaceships, and, most especially, key characters that inhabit said system. And a sector should relate and tie together some of such aspects between systems.

However, its not too hard to automate a certain level of 'intelligent design' into random sector creation such that adding the above on the fly is very doable. Filtering out excessive 'oddball' UWP combinations, ensuring specific TLs and starport presences, weighing system density, types and zoning as well as accommodating routes for trade and commerce (automate laying them first and then fill in the rest).

My pet peeve, though, is random naming.

Don't care if the system is supposed to be alien - use English dang it. Sure, it cute to have some gibberish, unpronounceable, in-game alien name. Even if its not an alien dominated system, they will have their own name in their own tongue for the system and using it can add nice chrome to RP - but, that is not the name English (or whatever you want to call English in-game) speakers will use when referencing the system. For f2f and pbp gaming its just a heck of a lot easier to refer to a system when one can pronounce or spell the name.

As for mapping any significant portion of a galaxy - yeah that seems pretty useless except as something fun for programmers to do.

 

[robject]

Joshua, you're probably right. It may suffice to identify a local reference point in terms of parsecs out from the core, and parsecs 'around' to Reference. From there, local regions will map out their subsectors and sectors.

My preference is to be able to use something like Ring/Ray for local calculations.

In short, I do not want the Reference Ray to 'bend' when I'm dealing with it locally.

 

[Fritz_Brown]

Don't care if the system is supposed to be alien - use English dang it. Sure, it cute to have some gibberish, unpronounceable, in-game alien name. Even if its not an alien dominated system, they will have their own name in their own tongue for the system and using it can add nice chrome to RP - but, that is not the name English (or whatever you want to call English in-game) speakers will use when referencing the system. For f2f and pbp gaming its just a heck of a lot easier to refer to a system when one can pronounce or spell the name.

You have to do the color though, as there is always someone who insists (as news readers tend to) on pronouncing it Bye-shing or Pock-ee-stahn or even Allegmane. Whether it's a PC or some obnoxious third-tier bureaucrat NPC, it is gonna happen.

 

[Dragoner]

tm already uses an x,y coord for it's sectors.

 

[BytePro]

You have to do the color though, as there is always someone who insists (as news readers tend to) on pronouncing it Bye-shing or Pock-ee-stahn or even Allegmane. Whether it's a PC or some obnoxious third-tier bureaucrat NPC, it is gonna happen.

Color is great for ingame dialog and props - I've made up my own languages and the fonts that go with them (something I expect ). I even mix other RW languages into my material just as they are adopted in the RW (ex: French names appear in a lot of U.S. names, for example).

But for reference material and standard usage, random pseudo crap is just blatantly metagame and fundamentally a PITA. Its also less believable, in that naming on RW maps and such are almost universally made in a given language - not the language of the locals.