A few notes from one Traveller player to many

[DaltonCalford]

Many times I have read that traveller maps space in two dimensions.
I see this as a lack of imagination on the part of the reader.

When I look at a traveller space map, I see a 2.5 D map. Such a map shows relative jump relations to other stars that are close by.

To give an example, I took a series of stellar data (hip, gliese, etc) and came up with all the stars within 5,000 ly. After doing this, I found the nbos website has wonderful lists of out to 10,000ly.

I started with a database but went back to nbos as it has some nice scripting tools.

I loaded the 10,000 ly starchart, and then, I generated all the routes for each of the jump settings. I did not care about actual distance, only if a particular jump would connect the two systems.
I then exported all the data and put it into jED (a free graph tool that anyone can download and use).
I then used yED to come up with a complete starmap that showed all the systems in relation to one another and then I nudged the final result onto a hex grid.

Now this gave me a map that was flat - in effect 2d, but it correctly showed all the relationships - paths between the systems.

Anyone can do this and come up with their own map or use the traveller rules to generate the map.

Sometime this kind of map is called a subway map, while others just refer to it as a 2.5d map. It works and it is very handy.

Although the CT maps never took this into consideration, I used this technique for my own traveller universe.

For anyone wanting to do some pretty hefty stellar mapping, I would strongly recommend the nbos AS2 product.

best regards

Dalton

 

[RandyT0001]

Could you provide us a copy of this map centered on Earth or a link to same?

How did you account for the dropoff in frequency of M stars as distance increases (M stars being so dim we can't see them at 5000ly or 10,000ly as well as we can 20 ly away)? Did you assume their frequency in our neighborhood holds true throughout the 10,000ly or did you just ignore their absence?

 

[EDG]

Many times I have read that traveller maps space in two dimensions.
I see this as a lack of imagination on the part of the reader.

I wouldn't be quite that harsh, given that most people don't have a clue what "2.5D" is. It's a flat map, so it's "two dimensional".

When I look at a traveller space map, I see a 2.5 D map. Such a map shows relative jump relations to other stars that are close by.

I'm not sure what you mean by "2.5D"... as you say later, basically the Traveller maps are best considered as a very crude "subway map" where the distances and directions between each star is severely distorted because it's a 3D map squished down to a 2D map (especially if you want to know the distance and direction between a star that isn't the "origin" of the system and another star). Plus the directions are wrong anyway.

I've looked at this in detail on my Realistic Mapping page.

A star directly "above" Sol in galactic coordinates will break Traveller (e.g. 31 Coma Berenices, which is 307 lightyears away and pretty much at the galactic north pole). How do you show that in Traveller? It'd have to be in the same hex as Sol (assuming that the maps show the view looking down from Galactic North) but really the Distance should be about 94 hexes. And how do you show another star halfway between the two but a bit off to one side? It'd look like a short distance between them on the map, but obviously the distances are large - what looks like a one hex displacement is really about 47 hexes.

To give an example, I took a series of stellar data (hip, gliese, etc) and came up with all the stars within 5,000 ly. After doing this, I found the nbos website has wonderful lists of out to 10,000ly.

10,000 ly is severe overkill, and next to useless beyond about 100 lightyears, because you lose all the dimmer stars. I used the RECONS near star list for my maps, and even there they don't know where all the M V stars and brown dwarfs are. If you're looking out to 10,000 ly you're basically only going to be seeing the brightest O/B V stars and giants. Plus, the parallax errors get a lot bigger the further you go out from Sol.

 

[crazy_cat]

There are some excellent starmaps, most centred on earth, available on this website:

http://www.projectrho.com/smap12.html

 

[Rikki Tikki Traveller]

Sol Station (solstation.com) also has some good maps and is a relatively up-to-date listing of the information about near stars.

Between Sol Station (for detail) and RECONS, you can get a good map of nearby space in 3D.

Converting down to a Traveller Hex Map is much harder though.

 

[EDG]

Between Sol Station (for detail) and RECONS, you can get a good map of nearby space in 3D.

Watch out for Sol Station though, they actually list (but don't describe) stars from the original 2300AD list that are purely fictional! All the stars they actually describe are real though.

Converting down to a Traveller Hex Map is much harder though.

You can't do it while preserving both distance and direction on a 2D map. The way I did it was to have "layers" separated by 1 pc along the vertical axis, so I could put each star roughly in the right spot relative to everything else.

 

[DaltonCalford]

I am at work but I will post the method and output of the process if anyone is interested.

The output is a usable hex based 2.5d map. Very much like a subway map.

The relationship of the stars to one another, on the map is based upon the jump distance and not physical coordinates.

For example, any systems within J1 of a system would be on the first ring of hexes around a world, J2 would be on the second ring etc.

The nice thing about yED is that once you specify the relationships between entities (systems in this case) it will automatically lay them all out for you.

You then need to put a hex grid background into yED and manually manipulate every system so that it lines up properly and so that it keeps coordinated with the rest of the map.

This leads to whole sections that separate themselves out from the others, including some interesting areas that could be considered gaps or rifts.

Viewing the jump points in 3d is a confusing mess as there are so many routes that you soon see only routes and no systems.

With a 2.5D system, the layout of the map is based upon routing not physical position, so two systems, 40 ly apart but sharing one coordinate would not obscure each other, as their physical relationship is not mapped, just their connections.

It is 2D in the fact that it is mapped unto a flat plane but it shows the travel information between multiple points in a 3d universe.

best regards

Dalton

 

[EDG]

I am at work but I will post the method and output of the process if anyone is interested.

I'd be interested to see it.

The output is a usable hex based 2.5d map. Very much like a subway map.

The relationship of the stars to one another, on the map is based upon the jump distance and not physical coordinates.

So the direction from one star to another is pretty much arbitrary then (that seems to be the only way to make it work)? And don't you have problems keeping all the relative distances consistent?

 

[DaltonCalford]

I'd be interested to see it.

So the direction from one star to another is pretty much arbitrary then (that seems to be the only way to make it work)? And don't you have problems keeping all the relative distances consistent?

Sure, I will send the details and post some of it up on my website.

The directions are totally arbitrary, based upon best fit on the map vs any real universe direction.

The method I used took a great deal of time, effort and storage space.

I began with the NBOS 10,000+ly data.
I then generated all the systems, (planets, moons, surface maps etc) for all 87,000+ systems using NBOS's internal system generator.

I then used the software to generate all the possible jump routes and name them J1 to J6 (this took about 3 days, which was fast compared to the 53 days used to generate all the surface maps)

I then exported all the data to a SQL database (firebird) and wrote a series of selectable stored procedures.

Then I selected the data into the xml format I specified in my procedures and loaded it up into yED.

Using yED, I played with various layouts until I found one I liked, then I put the whole thing onto a hex grid background so that I could manually line up every system as per their jump links.

Once that was done (a five month process as I could only do it in my spare time), I removed the links and saved the whole thing as a very large bitmap.

I then opened it up in GIMP and fixed the grid which did not come out properly.

Now that I know how that works out, I am working on a SVG generation routine via sql that will put the whole thing together for me.

I have generated Traveller Stats for each one of the planets, but I have not generated populations. I was going to use EDG's rules for this, but without some sort of SRD or OGL statement, I have to wait to see what Mongoose does.

The whole project is for my "Earth Ascendant" setting.

I am right now trying out various different icons for the economic types so that a trader can tell the economic potential of a system at a glance of the map.

Once it is finished (if it ever does get finished) I will see about posting it all on the web.

As it currently stands, I have about 60 GB of generated data, code and library data.

 

[EDG]

Blimey. That's impressive!

As for legal stuff, I put a legal note on the first post of the EDG Worldgen thread (I ran it past Mongoose Chris and he said it looked fine by him) that should let you use the EDG rules for personal use. Basically, you're fine to use them and post the product of their use (but not reproduce the rules themselves, and not do anything commercial with them), just stick a credit to me somewhere on the site.

 

[DaltonCalford]

Blimey. That's impressive!

As for legal stuff, I put a legal note on the first post of the EDG Worldgen thread (I ran it past Mongoose Chris and he said it looked fine by him) that should let you use the EDG rules for personal use. Basically, you're fine to use them and post the product of their use (but not reproduce the rules themselves, and not do anything commercial with them), just stick a credit to me somewhere on the site.

Thanks, I may still use them, but I will have see how the SRD handles things.

I have over 87,000 systems, 500,000+planets fully detailed and I am planning on creating all the animals etc for them.

One thing is that the NBOS system generates VERY few worlds that you would consider hospitable. I went with the concept of the settlements on most worlds being either highport/space colonies or very rugged situations with TL representing manufacturing base, not what is imported so almost every world within a trading/cultural group has the same tl, but it costs more on some worlds.

I will be making use of terraforming as I have seen various plans for how to terraform worlds, even the moon, that where put forward in the 90's.
One plan even had towers that effectively made the entire surface of the planetoid a single habitation (one big bubble was how one researcher put it)

The terraforming in my setting is NOT permanent and if it is not constantly maintained, it will fail. Although some are in the early stages of bio-microbile terraforming, so they just at the point of precipitating out the iron in the oceans so oxygen has not become common in the atmosphere yet.
There are a few garden worlds, and a whole series of hell worlds where the native life is very hostile to earth life.

The setting is one I have been working on for quite some time, but it currently has more library data/background generated for it that the OTU.

I am awaiting my copy of T5 and MGT to see which one I apply to the setting. I was going to use GURPs for it, but I do not like the system.

best regards

Dalton

 

[Rikki Tikki Traveller]

If you map every star within 1 pc to a 2D map, what do you do if there are more than 6?

While that may not be in issue in a "normal" density, there is no way it could be used to map a cluster area.

I have been working on a 3D to 2D conversion for a while on another project and at some point you HAVE to compromise and leave stars out. Since the number of stars in 3D goes up with the CUBE of the radius, but you only add hexes with the SQUARE of the radius, it falls apart pretty quckly and choices have to be made.

Do you concentrate on direction or distance? How do you handle those stars directly north or south or both?

I think 2D is a simplicification but a reasonable one for most people. If you want to do a full up 3D starmap, then eDG and others have methods out there for doing it and more power to you.

 

[DaltonCalford]

If you map every star within 1 pc to a 2D map, what do you do if there are more than 6?
Do you concentrate on direction or distance? How do you handle those stars directly north or south or both?

Interesting problem since it never occurred with the dataset I was using.

I concentrated only on distance, direction was irrelevant.

You enter in every star, you create a series of linkages based upon distance, you then ask a program to create a view of it where none of the nodes overlap, nor do any of the linkages overlap, and you specify a weight to the graph based upon the type of linkage, where j1 links bring nodes closer while j6 links separate the nodes.

You find you will get some strange designs, such as one point in the middle of the map where it has a series of J3-J6 systems that connect with only one end connected to the rest of the map. Then you look at it in 3D and realize that those systems are on the outer edge of the arm we are in, but they fit onto the 2.5D map into the middle. There are many such little anomalies, where there is what looks to be a rift, but what it is, is that since the program was trying to conserve paper/canvas space, it wrapped one spiral group back down to fit onto the page. Since there are no jump routes that connect the two branches along that gap, I left them 7 hexes apart making the appearance of a rift on the page, but the truth is that the distance between the two branches may be as wide as the galactic arm.

The base assumption with a 2.5D map is that you do not use it to measure anything other than to know where you are and where you can go.

It is very much like the old blackfoot and crow maps. They would mark down on the map how long it would take to travel someplace. So flat even ground was a short line, while rough mountainous terrain was a long line.
The white traders had alot of trouble understanding this non-absolute reference system, but it works and it is very valuable at conveying the information needed.

What it does break is the concept of counting hexes that are not connected via the jump routes.

Very often I have places on the map that are within 6 hexes of each other, and because a link is not shown on the map, they are farther away than six hexes. All systems that can be linked have linkages. Right now I have them in the gaps between the hexes, but I may do something different when I move everything over to svg.

I even found one area of the map which corresponds well to the spinward marshes, but I am going to leave it at that as I have given enough details that most of you could do this now if you wanted to.

 

[AKAramis]

If you map every star within 1 pc to a 2D map, what do you do if there are more than 6?

From Sol, you get 0. 3.26 LY, one Pc, is not as far as the nearest stars, the Centauri systems. They are about 4.26 LY...

 

[Rikki Tikki Traveller]

Dalton:

Interesting. I see what you did, you used distance and ignored direction. OK, that is one way to do it. I would REALLY like to see your data!

AKAramis:
Agreed. No stars within 1 pc of Terra, but in the Pleiades Star Cluster or other places (center of the galaxy), you will have LOTS of stars within 1 parsec, and how that would be mapped was part of my question.

 

[klingsor]

I think the first time I saw a suggestion for a 3-D map for Traveller was in White Dwarf back in the mid 80s. Then Traveller 2300 (unrelated despite the name and also coming from GDW) used real star data for its maps.
For a new game a 3-D map would be really nice, the problem is representing it on paper. For classic Traveller though the maps are fixed.

I rather like jump points and a map using these might just be a series of planets linked by lines, their actual spatial relationship being irrelevant. Not Traveller though and I do not think the Jump Drive is a good match for this.

 

[GamerDude]

For a new game a 3-D map would be really nice, the problem is representing it on paper. For classic Traveller though the maps are fixed.

Well, all it takes is listing the distance above or below the "galactic plain", but yes, calculating jump distances could be tricky for the mathematically disinclined.

 

[Rikki Tikki Traveller]

But, given the X-Y-Z coordinates of every system, a simple program could generate a table of distances, once calculated, it wouldn't need to be regenerated...

 

[Stuie]

Add me to the list of people interested to see your work DaltonCalford. I even stopped lurking just to say so. 8)

 

[SableWyvern]

But, given the X-Y-Z coordinates of every system, a simple program could generate a table of distances, once calculated, it wouldn't need to be regenerated...

Will that actually work, though?

Suppose you have four systems, arrayed at the corners of a square plane in space.

If we change that plane into a pyramid, with a fifth system at the top, eqidistant from each of the first four systems, you can't map that simply to 2D. In order to be equidistant from every corner, it would need to be placed right in the middle of the square -- but that won't be an accurate representation of it's actual distance from these systems.