I had originally planned to do a post on the HSS History’s Hope this week but I’m not quite ready for that. Instead, I’m giving you the outlines of a small town on Pale, Myha’s Beach. While I developed this as part of my Star Frontiers campaign, you could easily drop this town on to any world in any game.
Location
In my game, Myha’s Beach is located about 300-400km east of Point True on the sea coast. Here’s a map of the region around Point True.
I can’t seem to find where I recorded it, but I believe each of those grid boxes are either 300 or 350 km on a side.
History
Myha’s Beach started as a small fishing village founded shortly after the sathar were driven out of the Frontier. The village was built about five kilometers south of the crater left from the sathar’s destruction of a former costal city.
Not long after the basic city infrastructure was in place, the small town became a favorite beach destination for vacationers wanting to get away from Point True. The waters are warm and clear as the spur of land to the north keeps the cooler arctic waters from flowing into the bay. The city has embraced this role and now tourism employs a major portion of the city’s workforce.
About a decade after the city was founded, Streel decided to get into the shipbuilding industry and brokered a deal with the city to open a shipyard some 10 kilometers to the south of the city proper. This caused the city’s population to grow once again as the shipyard workers moved to Myha’ Beach and more services grew up to support the new citizens.
City Layout
Click for full sized version
Myha’s Beach is a long narrow city that sprawls out along the seacoast. The original village lies toward the northern end of the current town. The original marina is still in use. As the tpwn began to grow, it was originally small, 4-10 room hotels that were built both north and south of the original village, with almost everything built with access to the beach. This region of small hotels and private residences comprises the northern 3-4 kilometers of the town, centered on the now historic original village center and marina.
With the construction of the Streel shipyards to the south of the town, the town’s growth began to shift more in that direction with new residential and commercial districts being built southward with the residences on the beach and the commercial districts more inland. While growth continued to the north, it slowed considerably. At this same time, several large resort-style hotels were built on large swaths of the beach south of the existing city.
Front view of Observatory Manor
The city’s growth northward was effectively halted in FY18 with the construction of Brekstoone Manor. The manor is simply referred to as Observatory Manor by the locals, due to the large observatory dome on the manor’s north tower. The Brekstoone family secured a large tract of land that ran from the sea several kilometers inland on which they built the manor. With no more room northward to grow, the town continued to grow southward.
The 3-4 kilometers around the initial resort hotels was zoned for more of the same while the area between these large hotels and the Streel shipyards was reserved for the smaller hotels and residences. As this area filled in the city began to grow inland from the seashore with more commercial and residential areas to support the growing resident and tourist population.
In FY36 a small spaceport was built about 30 kilometers inland from the town to reduce the noise and air traffic impact on the town. This allows offworld visitors to come straight to Myha’s Beach instead of having to go to Point True first.
Current Population
The current resident population of Myha’s Beach is about 20,000. It is about 55% human, 20% yazirian, 15% vrusk, 9% dralasite and the remaining 1% made up of Rim and other races. In addition to the residents, the city supports between 20 to 40 thousand visitors, depending on the time of year.
About 5% of the resident population work at the Streel shipyards. Another 10% work in the town’s still thriving fishing industry supplying fresh seafood to both the local residents and tourists but also to Point True. A quarter of the resident population works directly in the tourist industry running shops, hotels, equipment rentals, and as guides both to the ocean and the inland areas. The remaining population works all of the support industries including city services, maintenance, restaurants, and stores that keep the city running.
Your thoughts?
That’s the city of Myha’s Beach. What other details would you like to see in a city write-up like this? Do you have any suggestions for other things that should be included or discussed? Let me know in the comments below.
So I sat down last week with the intention of working on a new spaceship model but I just wasn’t feeling it. On the other hand, I’ve been doing a fair amount of coding at work and was in the programming mindset. I’ve been thinking about getting back to working on my Second Sathar War (SSW) game but wasn’t quite up to tackling that yet. So I decided to dust off the Star Map Generator that I’d been working on (and used to create the Extended Frontier Map) and add a graphical user interface (GUI) to it in order to make it a little more user friendly for non-programmers.
Since the code is written in Python, and I’m already familiar with the wxWidgets GUI framework from my work on the SSW game, it made sense for me to use the wxPython framework, which is just wxWidgets for Python. Since I’m seriously considering converting the SSW program over to Python, this would give me a bit of practice.
Also, this post is going to be my entry for the RPG Blog Carnival this month. The exact topic is “To Boldly Go” hosted by Codex Anathema and is on the topic of exploring the planes and other worlds. It’s couched in terms of Spelljamers and from a fantasy perspective (common with the blog carnival) but I thought, if you’re going to be exploring new worlds, you need a map. So I’m tossing this tool out there for people to use in making their maps.
Building the Basic GUI
The first step was to just implement a basic interface over top of the existing code. The main goal here was to allow the user to specify the various map parameters that up until now, I’ve had to write into the code whenever I wanted to run the program. I’ve never implemented a way to pass those parameters in when it starts. That ability is actually issues number 3 (Add command line parameters) and number 4 (add configuration file option) on my list of open issues. This interface doesn’t solve those issues, but it does provide a workaround.
Building an interface that just accepts some input and stores the values is pretty straightforward and in just a short time (after getting my development environment all set up), I had the basic interface.
It didn’t do anything yet, but could accept the input of all the parameters you need to set to generate a map. Let’s talk briefly about each of those parameters.
Map width – This is just the horizontal size of the map. If you’ve seen any of the maps I’ve made with the program, it’s just the number of boxes wide the map will be. The units are light years (this will be important shortly).
Map height – The vertical height of the map, again in light years
Map thickness – This is the z dimension of the map or how thick of a slice of space you are looking at, again in light years. This is the total dimension just like the width and height. The program will split that into a maximum positive and negative value for use in system generation.
Stellar density – This is a measure of the number of stars that should be placed on the map. The units are star systems per cubic light year, which is why the number is so small. The default value (0.004) is roughly the stellar density around the Sun. If you want your map to a parsec (3.26 ly) per square instead of light years, and keep the same approximate density, you’d use a value of 0.138 (a factor of almost 35). That will be a very crowded map.
Text scale – As I’m writing this I realized this is mislabeled. While the setting here does affect the text size that is printed on the map, it also affects the size of the stellar symbols printed as well. The default is 1 and that is what I used on the Yazira Sector map. However, I used a scale of 1.5 on the Extended Frontier Map.
Output map filename – This is the name of the output map image file. It will be an SVG file and should have .svg as its extension.
Output data filename – This is the output file that contains all the coordinates, names, and spectral types of the stars generated as well as the list of jump routes generated. It’s just a text file and you can call it anything you want. I typically use the same same as the map file but with a .dat extension so I can keep track of them together.
Input data filename – This field is left blank for a randomly generated map. If you specify a name here, the program will try to load that file and use it to generate the map. The file should be the same format as the output data file. This allows you to randomly generate a map, then tweak the data file and have the program redraw the map with your modifications. This is how I made both the Yazira Sector map and the Extended Frontier Map. If the file specified doesn’t exist, the program will probably crash. Or at least not do anything.
Print Z coordinate – This just tells the program whether is should print the z-coordinate (distance above or below the plane of the map) on the map itself. You can see what that looks like on the Yazira Sector Map. I had it turned off for the Extended Frontier Map.
I initially implemented those boxes as simple text boxes but realized that the first five really needed to read in values so I changed them in the code. I should probably change the Input data filename field to be an Open File dialog so that it guarantees that the file is actually there. I’ll need to add that to the open issues.
Finally I added the code to properly process the buttons. Clicking “Generate Map” will do exactly that and write the files to disk in the same directory where the program is located. Clicking “Reset Values” will change all the input values back to the defaults if you’ve made changes.
Making the Program Distributable
By adding the GUI to the program, you need even more setup to run it. Before, you just needed a Python installation as it was pretty vanilla code, but you still needed to install Python. Now, in addition to Python, you need to have installed the wxPython distribution as well. Since I wanted to make this easily usable by non-programmers, I wanted it to just look like another program you that click on and run. So I started looking for ways to package it up for distribution.
It turns out there is a great little Python program called pyInstaller. It takes your program and bundles it up with all the code and files it needs to run and puts it into either a single program file (.exe file) or a folder with all the bits you need and an .exe file to launch it. You can then just distribute it as a zip file, users can unpack the zip file, and run your program.
I tried it out and sure enough, it just worked. You could click on the .exe file and the program would run. Here’s that version of the program. Just download the zip file, extract it somewhere, and run the StarMapGen.exe file.
It works fine, but everything is done behind the scenes and the files are created on disk in the directory where you launched the program.
Adding in the Map
The next step was to add in a map display. I mean, what good is having a graphical interface if you don’t get to see the map?
This is where I ran into the first snag. It turns out that the current release version of wxPython (4.0.7) doesn’t have the ability to read in an SVG file and display it. It can write one if you’ve created your image from it’s primitives, but in my case, I’m writing the SVG directly and just want a display. Luckily, the current development version of the package (4.1.0a) does have that capability.
Normally I try to stick with the released versions of packages, but after looking around, all the other options for displaying SVG files required more packages to to be added to the dependency list and in the end, used the same backend that I would have to install for wxWidgets. So I bit the bullet and upgraded to the head of the development channel. Since pyInstaller grabs everything you need and packages it up, I wasn’t too concerned.
So I wired everything up so that when you click that “Generate Map” button, in addition to creating the map and writing the files, it would then load up the file in to the panel on the right hand side of the GUI. Unfortunately, it ended up looking like this:
Initial map display in the program
Notice anything missing? It’s supposed to look like this:
Full map render in Inkscape
All of the stars and text were missing. Not very satisfying.
Fixing the Stars
For the stars, the SVG code uses a series of radial gradients to create the limb darkening and glow effects and maybe the default renderer just couldn’t handle those yet. After all, it was the development version of the software.
So I started digging. Since the default renderer wasn’t working, I looked for alternatives. The package gives a couple of other options for renderers, the best one being based on the Cairo package. This is the same package that I saw being recommended for rendering when I was searching around earlier. I didn’t really want to pull in another dependency but after trying everything else and failing, I added that in. Unfortunately, that didn’t work either.
However, after some testing, I was able to run the wxPython demos and found that it could render radial gradients. A lot of the sample images had them and the images were created by Inkscape, which I had based my code off of. So it had to be an issue in the code I was writing for the image.
After much experimenting with simple images and trying to render them, I finally discovered that the old Inkscape code I based the SVG data on just wasn’t up to snuff. I originally wrote that code in 2015 and things had moved on. Luckily, it didn’t take much to fix it, I just had to add two additional parameters to the gradient specification to get it to work (cx="0" cy="0" if you’re wondering).
When I next ran the program, the stars appeared!
Render with fixed gradient code. Notice I’m reading in the old data file so I get the same map. Also this renderer makes the grid lines finer so they don’t show up as easily in the small screen capture. They are there though.
Fixing the Text
Next up was to figure out why the text wasn’t rendering.
In the SVG file I’m writing, the labels are all rendered as <text> elements. You’d think that would just work but it wasn’t. After the experience with the gradients, the first thing I checked was my implementation. I went into the new Inkscape and exported a simple SVG with just a few characters. That wouldn’t render.
Next I tried some other on-line SVG code generators to create some <text> elements. Those wouldn’t render either.
I then went looking at the sample SVG files from the demos. In every case, it seems that the text in those files were not stored as <text> elements but rather had been converted from text to paths. In other words, they were no longer text but rather drawings.
It appears that the renderers don’t handle the <text> element. This is a bit of an issue because I want to be able to edit the text as needed. Mostly I’m just moving it around, but sometimes I want to be able to change it as well. And once it’s a path instead of text, you can’t edit the characters. Plus I eventually want to allow the user to specify the fonts used on the map (That’s even an open issue, number 5). I like the defaults I’m using but users should have options.
I could have the program write the paths for the text, it would just require hard coding in the paths for the various characters. Currently there are just 23 characters used across two fonts but I don’t really want to do that as that makes it harder to use different fonts or add in additional characters.
In the end, I decided to pass on this issue for now and revisit it at a later date. The full file written out by the program has the text in it, you just don’t see it in the preview at the moment. When I revisit this, I have several options from just building a library of character paths, writing code to do the conversion from text to paths, or even writing code for wxWidgets to do the text rendering natively. There is also the option to use the native wxWidgets primitives to generate the map and then using its ability to write SVG files to make the map file. All will probably be explored.
After taking a pass on generating text, I did make a banner image for the program to load that rendered the text as a path so you could see it. This now what you see when you load the program.
Program start up screen
Adjusting the Display
The last thing I wanted to tackle in this version was resizing the display. You may have noticed that all the maps I’ve shown so far have been square. But you don’t necessarily want a square map. Otherwise, why allow specification of both a height and a width?
By default you get the display shown in the pictures above. However, I wanted the user to be able to enlarge or reshape the window and have the map expand (or shrink) to fill as much of the space available as possible. This required playing a bit with the layout engine in wxWidgets.
If you notice, in the very first image, the region on the right has a little border around it with the “Map” label. I had intended to keep that border but the layout element that makes it will only resize in one direction and I couldn’t come up with a way to make it stretch in both. It may be possible but I wasn’t finding it and it wasn’t that important. In the end I went with a different element that did stretch the way I wanted, I just lost the border. Which really isn’t that big of a deal.
Now when you generate a map it will scale the map to fit in the available space and then you can resize the window and it will expand or shrink as needed to keep the whole map visible. Here are some examples.
First just a new square map. It fits just fine since the map area was already square.
Next, let’s make the map 30 light years wide. When we hit the “Generate Map” button, we get a view like this:
It’s all there, but has been shrunk down to fit in the space provided. But now we can grab the side of the window and stretch it out a bit to make everything fit.
Packaging Woes
At that point, I was going to package it up as a distributable program and add it to the blog post so you could grab it and play with it. Unfortunately, the addition of the extra dependencies for some reason caused pyInstaller to fail and not make a proper program that I could share. I think it’s just not finding the Cairo rendering library. It has tools to handle that, but I haven’t had time to sit down and figure it out. I finished this last night and am writing this post just an hour before it gets published. Look for an update later this week with the program once I figure it out.
UPDATE:
I got the packaging working. You can grab the version of the program that does the proper rendering of the stars from this link:
Just download it, extract the contents of the folder, and run the StarMapGen.exe file.
Getting the Code
That said, if you’re comfortable installing Python and the dependencies, you can get the code from my StarMapGen GitHub repository. This version of the program is sitting on the master branch. You’ll need to also install the cairocffi Python package and follow the instructions on this page to get the development version of wxPython. Once you’ve done that, the StarMapGen.py script is the main file for the GUI version of the program. makeMap.py is still the command line main program.
What’s Next?
There are a lot of things still left to do and work on. Already identified is the issue of the text rendering in the preview and some of the existing open issues.
A bug that I noticed with the GUI is that if you specify a data file to load, if it’s not square, it doesn’t get scaled properly in the display when rendered and loaded. That will probably be the first issue I track down.
Other improvements include adding a parameter to allow you to turn on and off generation of the jump routes and if you are making them, another parameter that specifies the maximum distance that the program will use to connect systems (currently set to 15 light years).
I also want to add some features to the GUI to include instructions, the ability to save parameter sets, and specify a random seed for map reproducibility.
Finally, I need to do some refactoring of the code to clean it up and document it better.
I’ll be working on this more in the coming weeks so expect to see updates in the future. If you’d like to help out with the code, feel free to clone the repository, make changes and submit a pull request.
What do you think of the program as it now stands? Are there features you’d like to see? Let me know your thoughts in the comments below.
As part of my Detailed Frontier Timeline, one of the threads I’ve introduced is the voyage of the Histran Starship (HSS) History’s Hope, registered out of Histran in the Scree Fron system. The goal of this voyage is to attempt to reach a star system that recent astronomical observations believe to be Yazira, the original homeworld of the yazirian species.
In my Yazirian History and Legends and Lore – Yazirians posts last month, I pointed out that most modern yazirians don’t know the location of their native world having fled some 150 years earlier to escape an astronomical disaster. Early in the Detailed Frontier Timeline I introduced the astronomical discovery of a system that matches the description of the yazirian homeworld, complete with a nearby brown dwarf. It is this system the HSS History’s Hope is trying to reach.
Of course there are some complications. First, the system is over 100 light years, in a straight line, from Scree Fron. Jumping from star to star, it’s even further. And all of those jumps are uncharted so each one carries the risk of a misjump and the crew getting lost along the way. They’ve had several misjumps in the timeline already and they aren’t even halfway there. In fact, they’ve just barely left the area covered by my Extended Frontier Map. This is additionally complicated by the fact that the ship is heading into the Vast Expanse, a region of space where the stars are further apart and thus the jumps are longer and more difficult to chart.
The second complication for their voyage is that the Family of One doesn’t really want them going out there and finding Yazira. And are willing to take measure to ensure that they won’t return. They have already been set upon by unknown assailants but managed to escape and continue their journey. They can expect more of the same in the days to come.
At some point I’ll probably do a write-up and timeline of the whole endeavor as a single post instead of having it spread out through the full timeline project for those that want to see how the mission played out and more of the background related to it’s organization and funding. If that is something you’d be interested in, let me know.
The Yazira Sector
As part of this project, I needed to place the yazirian homeworld. I chose to put it way off to the left of the Frontier, well beyond the area covered by the Extended Frontier Map (EFM). Since I didn’t have any maps of this area I had to create one.
For this map, instead of doing a large area, I chose to do a small, long strip. Enough to allow for multiple possible paths through the area, but not too big. I the end, I made it 90 light years wide (the same width as the EFM), and 20 light years tall (1/5 the EFM). However, I added in a new wrinkle. Unlike the EFM, which has all the stars in a single plane, I added a third dimension to this map making it 24 light years thick. So instead of all the stars being in the same plane, they have a z-coordinate as well.
This is a feature that was already part of my star map generation program that I had turned off for the EFM. I talked a bit about this in my post on the Rael Core Sector map. The image to the right shows how this is represented on the map with the z-coordinate represented by the small number to the lower right of the stellar symbols. Those three systems look close to one another but are widely separate in actual space. RS069 and RS073 are actually 5.1 light years apart, RS069 and RS064 are 9.1 light years apart, and RS064 and RS073 are the closest to each other, separated by only 4.6 light years even though they appear to be the furthest apart on the map.
Additionally, the Yazira sector is part of the Vast Expanse, an area of low stellar density, i.e. not a lot of stars. So in addition to turning on the z-component of the position, I also dialed down the density parameter in the program by a factor of almost 3. So we now have 1/3 the number of stars spread over about 4 times the volume of space. This means that in this region, there are going to be fewer stars than in a comparable area on the EFM. It doesn’t look that sparse to the eye because of the projection on the the 2D plane of the map, but crunching the numbers (and assuming a thickness of 5 ly for the EFM even though they are all on a single plane) you get a density on the EFM of 1 system per 159 cubic light years and in the Yaziria Sector of 1 system per 645 cubic light years. A factor of almost exactly 4. If I strictly held the EFM to a thickness of one, it would be a factor of 20.
So what does this region look like? Well, here’s the map. You’re going to have to click on it to see the details. In fact, I recommend right clicking, downloading it, and opening it up in another window where you can zoom and pan around.
The EFM is to the right of this map. OFS222 is shown on the far right (the blue star about 1/3 of the way from the top) so you can connect it up with the EFM if you want. (This map is actually 94 light years wide. I added on the extra 4 light years so that OFS222 would be on the map, showing the overlap). OFS215 should be on this map as well, but I forgot to add it in when making this draft version of the map. I’ll be sure it gets on there for the next iteration when the HSS History’s Hope gets a bit farther along on its voyage.
The first thing we notice, even without looking at the map at full resolution, is that there aren’t a lot of bright stars here. We see a few, but mostly we see small red dwarfs (M stars). There are a few blue stars and a few giants. This is why the yazirians had to go all the way to the Frontier sector to find a suitable planet. There just weren’t any around.
Also there aren’t any nebula. That’s intentional, this area of space is actually devoid of them. That is a part of it being more empty that the Frontier sector. I won’t be adding any in on the final version of the map once it is done (other than the one between OFS222 and OFS215).
Zooming in you can see that most of the star systems are unlabeled. The only ones I have labeled so far are those that the HSS History’s Hope have visited and the one they believe to be Yazira. Others will get named as they travel through the sector and the final map will be presented in a future update.
The system that the crew of the HSS History’s Hope believes to be Yazira (spoiler, it is) is located at the far left of the map above the legend. This system is represented as a K4 star with a brown dwarf companion. The brown dwarf that disrupted the planetary system is still very close the star, less than a light year away, so it is represented as a single system on the map.
Looking at the right side of the map, you can see the jump routes plotted by the HSS History’s Hope as of today (March 24, 2020) as posted in the timeline posts on Twitter. A new feature on this map that wasn’t on the EFM is the one-way jump, represented as a dashed line with an arrowhead on it. The arrow points in the direction that the jump can be considered “charted.” The jump from YS01 to YS02 is the most recent jump made; they are still slowing down to make the return jump. They had a misjump that took them to YS03 (so no charted jump there) and while trying to jump back to YS01, misjumped again and ended up in YS04 (again no charted jump between those two systems). They did successfully chart the jump from YS04 back to YS01 but did not try to go the other direction, hence that connection is only one way.
Right now the HSS History’s Hope is in the YS02 system slowing down and preparing to chart the jump back to YS01. They are somewhat hesitant about that as the ship that attacked them is probably still in that system and they may have another fight on their hands. We’ll see how it goes as the timeline unfolds.
Going Forward
The HSS History’s Hope still has a long way to go. From YS02 to Yazira is still another 80 light years in a straight line. It’s taken them over half a year to cover the 29 light years they’ve traveled so far. And their path forward is far from straight with lots of long difficult jumps ahead. Who knows what waits for them along the way.
If you want a fun exercise, you might try finding a path forward to Yazira and see how difficult the journey will be. Remember that the chance to plot a new route is 50% + 10% x astrogator’s skill level – 5% x jump distance in light years. They have a level 6 astrogator, plus deluxe astrogation equipment (which in my house rules gives a +10% bonus to astrogation checks). This means their base chance of success is 120% – 5% x distance. With a roll of 96-00 always being failure.
If the jump fails, they end up somewhere other than where they planned and then have to try to figure out where they are (30%+10% x level chance and takes 2d10 x 10 hours per attempt). Each jump takes 9 days (180 hours) unless it’s over 9 light years long. Then it takes a number of days equal to the number of light years. How long did it take you to get to Yazira?
What do you think about this sector map? Are there things you like to see added? Clarified? Share your thoughts in the comment section below.
This posts provides a table of all the systems on the Extended Frontier Map and provides the spectral types of the stars that were used to generate the images on the map. The named systems are listed first, in alphabetical order, followed by the FS designated systems and finally the OFS designated systems. The two latter sets are ordered by number
For the Frontier Sector systems (UPF & Rim), the spectral types were take from the following sources listed in decreasing order of importance. If a source higher up on the list conflicted with a source lower down, the higher sources was used.
Star Frontiers Expanded Rules book – this didn’t give exact spectral types but they could be inferred from the colors given.
Published modules – for most of the systems that were detailed in the modules, a spectral type was given although some just provided colors like the Expanded Rules book
Zebulon’s Guide to the Frontier: Volume 1 – This source provided spectral types for all the systems although some conflicted with the information from above.
With the exception of the neutron stars, all other spectral types were randomly generated and drawn from a realistic distribution of spectral types. The neutron stars were placed either where they appeared in the Expanded Rules or Zeb’s Guide maps or were specifically placed by me.
In addition to the spectral types, the table gives some notes and references for the various systems indicating features of the system and/or the source where the name/spectral type came from.
I realized after the fact that I never went through the Dragon and other “offical” magazine articles to find any systems listed there. I knew there was an Ebony Eyes system with a pair of binary black holes but I never put it on the map. Looking at that article, the FS38 system is almost in the position listed for Ebony Eyes so I put a note about that in the table below.
A quick perusal of all the other articles didn’t reveal any other star systems not already included so it turns out it wasn’t too much of an oversight. So with that, there’s the full table. At the end of the page is a link to a PDF of the table as well that you can download.
System
Name
Spectral
Types
Notes
Named Systems
Araks
G4
Athor
K2
Belnafar
A0
SFAD5: Bugs in the System
Capella
G6
Cassidine
G8
Cryxia
K5
Dayzer
G4
FE004 – The Saurian Sector
Devco
F9
Dixon’s Star
G0
Dramune
K1
Fochrik
F9
Fromeltar
G5
Gamma Hydrus
K6
FE016 – Phri’sk Anyone? Detailing the S’sessu Homeworlds
Gruna
Garu
G8
Imdali
G7
FE016 – Phri’sk Anyone? Detailing the S’sessu Homeworlds
K’aken-Kar
K8
Kashra’sk
G4
FE016 – Phri’sk Anyone? Detailing the S’sessu Homeworlds
Kazak
G1
Kizk-Kar
G2
Klaeok
G8
K’tsa-Kar
K0
Liberty
G1
FS30,
Sathar Starship Construction Center #2 – SFKH4: The War Machine
Lynchpin
NS
Madderly’s
Star
G3
Mechan
K7
Minan
K1
FE016
– Phri’sk Anyone? Detailing the S’sessu Homeworlds
New Streel
G2
Osak
G4
Padda
BD, M1
SFKH2: Mutiny on the Elanor Moraes
PanGal
G8
Precipice
K4
FE004 – The Saurian Sector
Prenglar
F9
Rhianna
G6
SF4: Mission to Alcazzar
Sauria
G8
Saurian
home system – FE004 – The Saurian Sector
Scree Fron
K7
Sessar
F1
FE004
– The Saurian Sector
Solar Major
F3
Solar
Minor
F8
S’seuden
F9
S’sessu home system – FE016 – Phri’sk Anyone? Detailing the S’sessu
Homeworlds
Sundown
K9
SF3:
Sundown on Starmist
Theseus
G1
Timeon
G5
Tischen
G6
FE004 – The Saurian Sector
Tristkar
K0
SFAD6:
Dark Side of the Moon
Truane’s Star
G7
Waller
Nexus
G0
SFKH2:
Mutiny on the Elanor Moraes
White Light
K1
Zebulon
G2
Frontier Sector Systems
FS08
M6
FS13
BD
FS15
BD
FS16
M2, M4
FS18
A4, M0III
FS19
G8, M1
FS21
M1, M2
FS22
BD
FS26
K4, M9
FS28
M7
FS29
NS
FS35
M2
FS37
M3, K1
FS38
M0, M3
This is in the approximate location given for the Ebony Eyes system (it
should be down one and right two squares) so you could replace the two stars
with black holes.
FS41
M2, M4
FS42
M8
FS43
BD
FS44
K2, M3
FS50
BD, M7
FS53
NS
FS56
M9, M4
FS57
M3
Outer Frontier
Sector Systems
OFS001
M9, BD
OFS002
M3, M3
OFS003
M6, M0
OFS004
M8
OFS006
M9
OFS007
M6
OFS008
M4
OFS009
M4
OFS010
M9, M7
OFS011
BD, M2, M9
OFS012
M5
OFS013
BD, BD
OFS014
A6, G1
OFS015
M4, M7
OFS016
M3
OFS017
BD, BD
OFS018
M7
OFS019
M1
Sathar
Starship Construction Center #5
OFS020
F0, M4
OFS021
M0
OFS022
M1, M4
OFS023
M9, M9
OFS024
M4
OFS025
M7
OFS026
M4, M3
OFS027
M6, K7, M2
OFS028
M1
OFS029
M4
OFS030
M4, K3, BD
OFS031
M6
OFS032
M5, K6
OFS033
K8, M7, M5
OFS034
K2, M5, WD
OFS035
M3
OFS036
M2, M3, M1
OFS037
M7
OFS038
BD
OFS039
WD
OFS040
M3
OFS041
M4, M8
OFS042
M8
OFS043
M0, M9
OFS044
G8
OFS045
M4, K4
OFS046
M4, G2
OFS047
M7, M7
OFS048
M3
OFS049
WD
OFS050
BD, BD
OFS051
F1
OFS052
M6, M2
OFS053
BD
OFS054
M7
OFS055
K9
OFS056
BD
OFS057
M1, BD
OFS058
M8, M2
OFS059
WD
OFS060
M6
OFS061
M7
OFS062
M8
OFS063
M4
OFS064
M2
Sathar Starship Construction Center #9
OFS065
M6, M8
OFS066
M1
OFS067
K3, M7, M2
OFS068
M0, M5, M0, BD, M7
OFS069
K6, M8
OFS070
M3
Tetrarch Complex (similar to one on Laco, Dixon’s Star)
OFS071
M3
OFS072
M1
OFS073
M4, K8
OFS074
WD, M1, M4, M4
OFS075
M8
OFS076
M1, M9
OFS077
M6, M4
OFS078
M4
OFS079
BD, M9
OFS080
WD, M0
OFS081
M9
OFS082
M6, M4
OFS083
K5
OFS084
BD
OFS085
M6, M8
OFS086
M9, M7
OFS087
M7, M6
OFS088
K3, M8
OFS089
M7, M3
OFS090
M0
OFS091
BD
OFS092
K5
OFS093
BD
OFS094
BD
OFS095
M8
OFS096
M8, M3
OFS097
M6
Sathar
Starship Construction Center #8
OFS098
M2
OFS099
M8
OFS100
M8, M5, M7
OFS101
F2
Sathar
Starship Construction Center #7
OFS102
M5, K8
OFS103
BD
OFS104
M9
OFS105
M4, M4
OFS106
M2
OFS107
M0
OFS108
M1
OFS109
K6
OFS110
M4, M8, BD
OFS111
BD
Sathar
Starship Construction Center #4
OFS112
M6, BD
OFS113
M4, M0
OFS114
M3
OFS115
M7, M5
OFS116
WD
OFS117
K4
Sathar
Homeworld, Sathar Starship Construction Center #6
This is a common dock lounge found on most large (HS 5 or 6)
civilian stations around the Frontier.
Located in the station hub, the gravity here is only about 0.1g. Just
enough to keep you in your seat but light enough that you have to be careful
with your movements.
This lounge area provides a place for crews to get off the ship without going into the station proper, mingle with crews in adjacent berths, and even conduct some semi-private business away from the hustle and bustle of the main station.
Each docking hub can accommodate up to four ships so there could be members of different crews here at any given time but no more than four at once. Depending on the size of the station and its central hub, there could be from 4 to 16 of these areas on any given station.
The Map
Click for the full resolution (50px per square/meter) image.
I’ve had this map kicking around in my sketch book for years. It’s actually part of a one-shot adventure I’ve run and will write up some day. This weekend I decided to give it the full, vector-graphic treatment and turn it into a usable map. I’ve used this location in a couple of different adventures over the years and it’s part of my concept of the design of the stations around the Frontier.
The map above is the labeled version at my standard 100 dpi resolution with each square representing 1 meter. If you want an unlabeled version, or either version at 70 pixels per square which is the default for Roll20’s map system, here are a few more versions of the map. The ones labeled 70ppm (pixels per meter) are the larger versions for VTT systems.
If your particular virtual table top uses a different default resolution, let me know and I’ll add in maps at that resolution as well.
Area Descriptions
Area 1 – Station Passageway
This is the main passageway through the hub of the station. I’ve drawn it here as a 2m wide passage with a small side passage going to the crew lounge. That’s how I originally drew it and described it the first time I used it. When I used it in the “A New Can of Worms” game, the hub corridor was much wider, like the terminal area in modern airports, and the crew lounge area was right up against it with glass walls. The PCs in that game tried several times, unsuccessfully, to get in.
Area 2 – Crew Lounge
This is the crew lounge proper. It has a couple of desks, some tables and chairs and a sofa and a couple of recliners. All in all, it’s a bit over 45 feet long and 20 feet wide.
The desks are fixed in the corners but all the other furniture is movable and can be positioned wherever the crews want. There are sensors that monitor the area in front of the doors and if they are blocked, the lights in the room flash and an alarm sounds until the offending item is moved. Since there is only 0.1g in the area, it’s fairly easy to move even the sofa but everything stays on the floor and doesn’t float around.
The door into the room from the hallway is locked with a level 4 security lock that opens only to beings who have been registered with the station as part of the crew of one of the ships assigned to these berths. The registration is typically done as part of the docking procedure so that the doors are working as soon as they arrive. The door itself is a pressure door and takes 3 turns (18 seconds) to cycle and move through: On the first turn the person wishing to pass through stops at the door and starts the process, on the second, the doors cycles and opens, and on the third, they can move through into the room. The door closes and seals automatically if not held open.
The roof of the room is a series of large windows, allowing those in the room to look up and out into the central hub of the station and see their ship and the other ships docked in the area. The ships attached to passages 4b & 4c are directly above the room while the other two are slightly higher up and off to the left and right.
Area 3 – Access Halls
These short passages provide access to the docking tunnels on either side of the crew lounge area. Like the door into area 2, these pressure doors have a level 4 lock on them that only allows the registered crews of the two ships docked off of the passageway through. Thus the crew of the ship docked in passage 4a could not open the door to 3b.
Area 4 -Docking Tunnels
Each of these passages ends at another pressure door (not shown) that opens into the docking collar connecting one of the ship’s airlocks to the station. For small ships this may be the only airlock and so all crew and passengers come out this way. On larger ships with more than one airlock, this is connected to the crew’s airlock with passengers typically going through a different part of the station. Alternately, for large ships, more than one of these docking tunnels may be connected to different airlocks on the same ship.
The tunnels move away from the lounge area, angling upward as they do, and then turn into a vertical shaft going up to the ship with ladders and hand holds along the walls. Gravity decreases from 0.1g to less than 0.05g by the time you reach any of the ships.
Tunnels 4b and 4c typically connect to smaller ships (up to hull sizes 8 and 6 respectively) although a single large ship could be connected to both of them. The other two tunnels extend farther out into the hub and can accommodate ships up to hull size 10 (4a) and 12 (4d). Even larger ships could take up 4a and 4b or 4c and 4d together or even three or all four of the tunnels (for a HS 20 ship).
The pressure doors to these docking tunnels are keyed only to the crew of the ship docked to that tunnel and use a level 6 security lock.
Some Thoughts on Station Sizes
The 0.1g gravity in this area only really works if you don’t allow very large ships into the station hub. That limitation goes a bit against the Star Frontiers setting as described in the rule books. There it says that a HS 6 station is 1200m in diameter. Assuming 1 g at the rim, that mean you hit 0.1g of gravity at just 60m from the center of the station. So the hub can only be 120m in diameter. The size given for a HS 20 ship is 100m in diameter so it could just squeeze in but would take up all the space. So you either have to limit the size of ships that can come in, or you have to make the hub bigger which means the gravity would be a bit higher in the lounge area probably up to 0.2g. It’s even worse on smaller stations. Because they are smaller, you hit that 0.1g even closer to the center of the station. Just something to keep in mind.
This is another map done using my map generation software. As I mentioned in my last State of the Frontier post, I’ve been itching to make a map of the area of space my book, Discovery, is set in. I’m (very) slowly working on a sequel to that book as well and so want a nice map to go with them.
Unlike the Frontier map, this map has a third dimension with the stars having positions both above and below the plane of the map. This area of space is 40 lightyears wide, 40 ly tall, and 20 ly thick.
The Original Map
I have a hand-drawn map of the sector that I made years ago (2010-2011). I randomly generated the positions in this map via rolling a bunch of dice in small 10x10x20 ly sections (d10 for x, d10 for y d20-10 for height). I had sat down and worked out the approximate stellar density for the region around the Sun and it worked out to 8 stars in that 10x10x20 volume, so I just rolled eight positions in each section of the map. There are 16 such sections. And somewhere along the way I rolled an extra star system since there are 129 systems on the map and not 128. Here’s a copy of that hand-drawn map:
Scan of my notebook with the map in it. The x=5 line is duplicated across the binding to make sure I don’t mess up when determining positions. Click for full resolution.
The stellar type tables that I implemented in my program come from this time period as well. I worked them out originally to generate this map. I even rolled up the composition of each of the star systems by hand back then using those tables and have a list of the systems generated. Or at least a composition for 128 systems. They weren’t assigned to specific positions on the map, I had never really gotten around to that part.
And apparently I was still using the original map, not the one copied into my notebook, when I originally plotted out the sequel novel as the notes for that novel are on the very original map as well.
One thing you’ll notice is that the “central” star of the sector, Rael, is not at the middle of the map. I’m not sure exactly why I didn’t just arbitrarily put it there. I do remember that I created the map, and then picked the system closest to the center to be on the central plane vertically. Either that or I got lucky and there was a star near the center.
Since the people in that star system are making the map, it would make more sense if it was at the center but that’s not what I did and I didn’t feel like changing it. The more I think about it though, the more I might go back and do that. I’d just shift all the stars down and to the right by 2 positions and wrap everything that falls off the edge to the other side.
In any case, that’s where the map stood for many years. Until I decided to make the full color version.
The New Map
Let’s start by showing the map. And then we can talk about how it was made.
Click for full sized version (~8MB)
So to make the color version of the map, I simply ran the program a few times, tweaking the density parameter to generate exactly 129 systems. They weren’t in the right places yet, but now I had all the data I needed, I just needed to update the positions. If I had already assigned the system characteristics back when I rolled them by hand, I might have actually just entered all that data. However, since I didn’t, and I was using the same random tables (with some additional refinements), I went with the new data.
The next step was to update all the positions. This is actually what took the bulk of the time as I had to manually edit each entry to match a position on my hand drawn map. And then somewhere (at about x=26) I messed up and suddenly dropped back to 24 and everything was off and I had to work back through the numbers and find where I messed up.
As I was working through the positions, there were four stars that I knew the general characteristics of: Rael, Proxima, and two systems from the sequel novel. I made sure that systems that matched the expected parameters for those systems ended up in the correct positions. In the case of Rael, there was no G2 star in the data set so I changed one of the other stars (I think an F9) to be the needed spectral type.
The Third Dimension
The feature that this map adds that I didn’t have in the Frontier map is that the stars all have a z-component to their position, a distance above or below the plane of the map. Since you can’t easily represent that by position on a flat map, what the program does is write the z-component as a small value to the lower right of the star symbols.
Example of some systems with their z-coordinate included.
This required a small change to the code to implement. The original version of the code did draw the z-coordinate, and in developing the code for the Frontier map, I had added a parameter to turn the printing on and off. Since I had it off for the Frontier Map development, I hadn’t kept that bit of code completely up to date.
However, it didn’t take much. Mainly, I needed to increase the font size as I realized that it was just a bit too small to easily read unless you were really zoomed in on the map. And that change also entailed moving the positioning of the text just a bit as well. The code now includes a scale parameter that adjusts the text and star symbol size that I added while making the Frontier map. I elected to not have the font size of the z-coordinate scale with the other aspects of the image. It’s fine to stay small if you increase the scale.
Two systems in the same (x,y) position. In this case a G star (RS075) and a binary pair of M stars (RS074). These systems are actually 10 light years apart.
Another aspect of adding in the third dimension is that is is possible to get more than one star system in the same (x,y) position, but separated in the z direction. That actually happened at five different positions in this map. When that happens, the code automatically shifts the stars away from the center of the square where it would normally draw a single system. While it possible to have more than two systems in a single (x,y) grid position, and the program can handle up to four, I’ve never had more than two in any map I’ve examined.
A Word on Names
There are only two named systems on this map, Rael, the home system of the stories, and Proxima, the other star system visited in the first book. In truth, most of the stars probably have names, especially the brighter ones as they can be easily seen from the night skies of Jord, the habitable planet in the Rael system. I just haven’t sat down and figured out what they are yet.
All the other systems, for the purposes of this map, just received RS (Rael Sector) designations. Those were assigned by starting in the upper left and running vertically numbering the systems moving to the right after each column.
Jumps and Nebulae
That was about it for the automated processing. The only other bit was the single jump between Rael and Proxima. It’s a short 5 lightyear jump and the only one that exists at the end of the first book, which is where this map is set.
Next I had to decide if I wanted to add in nebula or not. In this small region of space, with the older stars, there probably wouldn’t actually be any large nebula. But they sure make the maps look a lot nicer. So I decided to add two large ones in. I created these just like the ones I did for the Frontier map although I muted their colors significantly.
You might notice that some of the star systems look like they are in the middle of the large nebula. However, if you look closely, all those systems have a high z position. They are near the top of the map sector. Thus the nebula is actually below them on the map. That is true for both of the large nebula, they are at the bottom of the 3D volume.
There were also some solitary white dwarfs in the sector (and several more that were in binary systems). Since white dwarfs form from the death of stars like our Sun, and those deaths usually involve the creation of planetary nebula, I decided to add in small nebula around those two stars as well. You can see them over on the left side of the map, a little above center. For those nebulae, I simply grabbed a couple of planetary nebula images from NASA ,then scaled and rotated them to fit the map. They are roughly to scale as planetary nebula are typically about one lightyear across and that’s the size of one square on the map. It’s left as an exercise to the reader to figure out which nebulae I used, although it shouldn’t be too hard.
Final Tweaks
The last thing to do was clean up all the names. By default, the program just prints them up and to the right of the star symbols for the system. The ones on the far right fell off the map. The ones in the five locations where there were to systems in the same square were writing on top of the star systems. And some of the nearby systems were overlapping as well. Plus I wanted to move Proxima’s name off of the jump route line. These tweaks were all done by hand.
I also added in the map title in the upper right and the attribution in the lower right. And with that, the map was done. All told, it took about four hours to make the map, most of that being spent entering the positions.
Code Todos
As always, when I work on this, I dream up more things I’d like to code to do automatically.
In this case, it is to be more intelligent about where it places the system names. Especially in the case of multiple systems in the same grid. I’d still probably have to end up tweaking things manually in the end, however, so it may not be worth the effort.
Using the Map in Your Game
On the the purpose of this blog is to develop and create resources that you can use in your sci-fi game. And if it weren’t for the names on Rael and Proxima, this would just be a generic sector map that you could drop in anywhere. So, to that end, here’s version of the map with the names filed off:
click for full sized version (~8MB)
The other thing you’ll probably want is the actual data used to make the map. That will give you the spectral types for each of the systems. That can be found in the file below, which is an input file to the program if you want to use it.
There was enough interest in getting printed physical copies of the map that I’ve set up an ordering page for them. You can follow the link to get there or hit the “Order a Map” tab at the top of the page.
You can get the Player version, Referee version, or both. Price is $20 a map (including shipping) in the US and $40 international, with a discount if you order one of each. All the details are on the ordering page.
I’ll be taking pre-orders through the end of August 2019 at which point I’ll actually get the posters printed. Any posters ordered in this first round will be signed and numbered. If you want a copy, jump on over and get your order in.
Okay, I had planned to do a different post this week as part of this month’s RPG blog carnival but that will have to wait. I decided instead to just push through and finish the Expanded Frontier Map instead.
Corrections
If you downloaded the color player’s map from last week’s post, go back and do it again. As I was working on the final map, I found a bunch of mistakes that I completely missed while working on last week’s map. Most of them are minor, like names overlapping jump lines, but a few of them are pretty bad like names overlapping each other or running over jump distances. In any case, I’ve fixed those and uploaded new maps to the links in that article.
Adding the Sathar
The only difference between this map and the previous one is that I’ve added in all the jump routes known by the sathar as well as some labels on the map that give the location of the sathar homeworld, their ten starship construction centers, and the location of their Tetrarch ruins complex similar to the one on Laco (If you are following the timeline posts, this is where the signal went out to and was returned from). I haven’t defined which of these systems are actually inhabited by sathar, I’m leaving that up to the individual referee to decide.
Let’s start by showing the black and white version of the map and then I’ll talk about how I filled it in.
Sathar jump routes are shown in red. Click for full scale version.
Jump Routes
As you can see, most of the sathar systems are up and to the right of the Frontier. This is the their main population center. The tendrils that surround the Frontier tend to be more outposts and travel lanes than population centers.
In addition to the jump routes marked in red, it is assumed that the sathar know all the UPF routes marked in black as well.
The routes don’t extend to the left side of the map as the sathar stopped their expansion in that direction after encountering the Rim. They were also stopped by that big nebula in the upper left. I have plans for some of the star systems up in that area on the far side of the nebula.
I consider the jump routes along the bottom of the map, from Saurian space, past Liberty, into S’esseu space, and then up to Prenglar to be newly explored routes. In fact, in the current version of my background material, the starship construction center just south of PanGal, labeled SCC#1, is still under construction and hasn’t even started producing ships yet in my timeline project.
When I first made this map back in the 80’s, I didn’t have Zeb’s Guide and obviously none of the fan material existed so this region of space looked a little different on my original map (I should probably scan that in and post it for reference). But the idea was that these routes were established to give the sathar the jump route right into Prenglar in the Second Sathar War game in the Knight Hawks Campaign book allowing them to strike at the heart of the Frontier. In creating this map, I modified my original concept to work through these modified regions of space. It also provides an opportunity for interdiction as the UPF could potentially cut off some of the Sathar routes.
Starship Construction Centers
The numbering on the starship construction centers may seem a little odd and requires a little bit of explanation. I originally built this map for two purposes. The first was to give me a more strategic level view to write a Second Sathar War timeline, taking into account sathar ship production as well as the UPF ship production. I wanted to see how the balance of forces would work if you stuck to the rules on ship construction. This is now being realized in my timeline project.
The other was to provide a larger Frontier region for a big exploration campaign inspired by the Beyond the Frontier series of adventures (SFKH 2-4) where the PCs would explore out from Truane’s Star upward on the map. I have had the beginnings of that campaign in a notebook for literally decades. Maybe it’s time to dust it off and use it for material here on the blog.
It’s the former purpose that resulted in the numbering of the starship construction centers. I originally had the ones labeled 1-5 dedicated to the Second Sathar War effort. They were strictly producing military vessels with which the sathar would be attacking the Frontier. And I just started at the one connected to the Prenglar jump route and numbered them counter-clockwise.
SCCs number 6-9 were added in to provide “civilian” ship construction for the sathar population and exploration away from the Frontier. They are not labeled on my original map but were added in as part of this project. The final SCC, #10, was added as part of my timeline project to provide the production capacity for the Sathar offensive against the Saurians. I’ll probably do another post about the production capabilities of all these construction centers at some point in the future.
The Sathar Homeworld
The sathar homeworld is labeld on my original map. I had always envisioned it as a slightly cooler star than the sun with their home planet close relatively close in and warm and muggy. As such, I’ve given it a K4 spectral type on the map. Someday I might actually design and write up the system.
The Final Color Map
Now that we have the background information covered and everything else in place, it was time to make the final color version of the map.
This was done in two steps. First, I made a separate data file that had all the star systems again but instead of the jump routes known to the UPF, it contained the jump routes known only to the sathar. Using this, I generated a new map.
Since the map is generated with the jump routes on different layers, the second step was to just open the new map, and copy everything off the jumps route layer, open the Player’s map, create a new layer for the sathar jumps, and paste them in. I then had to adjust the position of all the features after pasting them in but that was just a matter of looking up the position in the original image and entering that in to the final image.
Of course, it really wasn’t that simple. The last step in adding the jumps was to adjust the color. The program makes all jumps in white. I simply changed the color to red in the final map. But that does give me an idea for an enhancement in the program, namely allowing the user to specify the link color.
The next step was to add the sathar specific labels. To do this I created a second names layer that I could add in the labels for the sathar homeworld, the starship construction centers, and the Tetrarch complex. Since the sathar jumps and labels are on separate layers, I can turn them on and off as need to make a player or referee version of the map as needed.
The final step was simply clean up. I went through the entire map and moved star labels and jump route distance labels in order to have the map as clean and clear as possible and fix and small issues the program has in drawing the labels. This is where I discovered the errors in the original version of the Player’s map and fixed them. And since the sathar names and jumps were on separate levels in the image, it was easy to re-export that map.
And that was it. The map is now done. (Unless I find some more typos as I start using it.) Here it is in all it’s glory.
The sathar jump routes don’t quite show up at the resolution of this preview. Click for the full sized version (~4.5 MB). There is also a very high resolution version (~20 MB) available.
The Code
Again, if you want to play with the code and make your own maps, it is written in Python and you can grab it from my GitHub repository. I’m going to continue to work on this code. This will be to add in the remaining features it’s lacking to make it more user friendly such as command-line options, the jump route colors, and creation of nebula, but those will fall under a different article title going forward. If I get really ambitious, I might even add in a GUI to make it a windowed program instead of a command line one. We’ll see. I’m curious how much interest there would be in that project.
Final Thoughts
This has been a fun project. I’ve really enjoyed doing it. As you can probably tell by the number of posts I’ve made. And I love the look of the final map. If you see any errors, feel free to let me know and I can update the map to correct them.
I think if I was doing this again, I would make the map dimensions a little different. This map was original made by taping together six sheets of graph paper (landscape orientation). while that ended up with a nearly square work area, it wasn’t quite. The map is 90 ly wide by 100 ly tall. If I were to do it again, I’d make it either perfectly square, or conform to a more standard aspect ratio.
I’m also curious if anyone would be interested in a printed, poster sized version of the map. 24×27 inches. This is actually what prompted my thoughts on the dimensions. As a purely digital product, the aspect ratio doesn’t matter. But when you try to print it, you start to run into problems. I’ve been looking at possible printing options, and while most of them want you to use a standard aspect ratio (16×24, 24×36, 12×18, or square), I have found a few that would let me print it to exact size. Final costs would be in the $15-$25 dollar range for the 24×27 inch one. If that is something that would interest you, let me know in the comments. I might do this as a small Kickstarter for those that are interested.
And that wraps up the the Extended Frontier Map project. Let me know your thoughts, ideas, and any remaining questions you have about the project and let me know if you’d like to see more things like this in the future.
Woo-hoo, we’re approaching the end of this particular project. In this update we present the final* “Player” version of the Expanded Frontier Map, both the color and black and white versions. This version just contains the systems and jump routes known by the UPF as presented in the rules, modules, and some fan content.
(* Final assuming I don’t find any typos and such)
Changes
First up, as I was generating the data for the color version of the map, I realized that there were just way too many neutron stars on the map. There’s one on the original AD map, five on the Zeb’s Guide map, and I had added in a couple dozen or so more.
One is too many for this volume of space. You might find one (anything is possible) but beyond that is really stretching it. However, since the five are in the original materials, I left them in. I also left in two of the ones I added in the lower left of the map. This puts all the neutron stars in the Frontier region and towards the Vast Expanse. Maybe there’s an explanation for that.
For all the other neutron stars, I replaced them with multiple star systems. That changed two dozen stars systems from neutron stars to multiple star systems, some with as many as five stars.
In comments on the previous update, it was pointed out that I forgot to label Mechan, the world in Zeb’s Guide where the Mechanons fled to when they left Volturnus in the Zeb’s Guide timeline. I don’t typically include that event in my games which is why I probably forgot to include it. Mechan is just up and to the right of Scree Fron on the map. That just required changing the label.
In fixing the labeling on Mechan, I also noticed that the Zeb’s Guide map adds another star 3 light years above Mechan near Capella. So I added a star in there as well.
As far as I can tell, that fixes everything.
The Black and White Version
So that gives us the new and updated black and white version of the map.
The Color Version
Creating the color version was mostly a matter a generating a large number of random systems and then positioning them on the map. Since I had to manually update all the positions, that took a couple hours of work to get all the data into the file and the coordinates updated.
After that, I could generate the rough map with my mapping software. The next step was to go through by hand and tweak the position all the labels that needed to be moved. There actually weren’t that many, I just had to move a few names and a few of the jump distances so that they were not overlapping any of the jump route lines. That cleaned up in just a few minutes.
The other major portion of the map was creating all the nebula. Since I had the outlines of them on the black and white map. I just copied (and scaled) those outlines to the color map. In a few places where the B&W map has little wisps of nebula next to the big ones, I connected them as the process I use to create the nebula would make those wisp-like areas.
This actually took less time than I was expecting. Since I was working zoomed out on the map, the rendering went fairly quickly. Whenever I zoomed in, however, it would take some time to redraw the screen due to all the detail in the nebula. From the earlier sample map, which was zoomed in, I had experienced a bunch of slow down and was expecting the same here. I thought I was going to have to do the nebula on a series of layers so that I could turn them off and on. That wasn’t actually necessary and this process only took a couple of hours instead of the several hours I was expecting.
The hardest part for me was picking colors. The truth is that there probably wouldn’t be any nebula in this part of space but since they look cool and were included in the original material, they are part of the map. I tried to pick colors for them based on the stars that were around as most of the nebula would be reflection nebula since none of the stars in the area put out that much ionizing radiation to cause the gas to glow on its own. I’m not completely happy with it but I like it. This is something that might get revisited at some future date.
The next step was adding in a legend. This also might get redone in the future to include each of the different stellar colors but it is good enough for now.
Finally, I decided I didn’t like the flat black background but wanted there to be a bunch of faint “distant” stars speckling the background of the image. To get that effect was pretty simple. I just applied the Textures->Cracked Glass filter to the black background layer. I’ll admit that I got lucky here and it applied the exactl level of background noise that I wanted. There are other filter combinations that would work as well but that was good for now.
With that done, I signed it and exported the final image.
This is a scaled down image. Clicking on the image above downloads the medium resolution one which is the same scale as the black and white map (4 MB) There is also a full, super high-res version (18 MB).
Up Next
The next step is to do the Sathar worlds and jump routes. Since all the stars are there, all I need to do is add in the links and update some labels. That will be the topic of the next and final (at least for a while) update.
Share you questions, comments, and impressions in the comment are below.
Okay. I’ll admit that this project has taken over my brain. It’s been fun for me to work on it and dust off some of my programming skills. This will be another small update as I haven’t had a lot of free time this past week but enough to get some work done. If you haven’t read them yet, the early posts are here: original post, update 1, update 2, & update 3
The good news is that I think there will just be two more updates and we’ll have the completed map. There might be a few more after that for upgrades to the software but those will probably be a bit more spaced out. Here’s what’s left to do:
Random generation of spectral types (this post)
Complete “Alpha Dawn” map (this post)
Complete “Player’s Version” of the Extended Frontier map (update 5) – This is the full color version of the B&W map I’ve been posting
Complete “Referee’s Version” of the Extended Frontier map (update 6) – This will be a version of the map with all the Sathar system labels and jump routes included.
I’ve decided that to get to the completed map, I’ll just do the nebulae by hand. I already have the shapes drawn on the B&W version of the map so it’s easy enough to transfer them and do the render. Getting the software to do the nebulae will be a future project.
If there is interest, I could also do a remake of the Zebulon’s Guide to Frontier Space version of the Frontier map in this style. While I’ve modified my map to match most of the named systems on the Zeb’s Guide map, they are not exactly the same (for reasons discussed in earlier posts) and the unexplored stars do no match between the two maps. If there is a large clambering for it, I’ll do that as a future project.
Let’s get on with this week’s update:
Random Stellar Types
After I had the program interpolating the colors between the base spectral types, the next step was to sit down and code up the random generation of those spectral sub-types. I needed this to randomly fill in all the “unexplored” systems with a proper mix of spectral types. The explored systems are way too heavily weighted toward the F & G stars and there are a few too many (i.e more than about 3) for the number of stars in the region but that’s okay.
In any case, I wanted the relative numbers to be approximately correct based on real stellar distributions so I busted out data on the stellar mass functions and after a bit of math came up with a d100 table for the various main sequence spectral types (A, B, G, etc.) to determine the relative ratio of their sub-types (A0, A2, A4, etc). Once I had the numbers it was a simple matter to code up a few subroutines to generate the values. There are some refinements I could make in the future but this is good enough for now.
Complete “Alpha Dawn” Map
Once the program was generating random spectral types in the correct distribution, it was time to finish the smaller map corresponding to the Frontier provided in the original printing of the game and the later “Alpha Dawn” reprint (named to distinguish the core rules from the Knight Hawks supplement).
I did this by running a random map and then taking the spectral types generated and applied them to the remaining systems in the original map. Next I took the resulting file and edited it to tweak the positioning of some of the labels so that they weren’t overlapping any of the jump lines or other text. Finally, I took the nebulae I had created for the earlier version and imported them into this map. This gave me my final version of the smaller map.
The full version of this image is 2250×1750 px (1.8 MB). You can grab an even higher resolution version (6750×5250, 9MB) if you want.
I might revisit this in the future and do the nebula with different colors but for all intents and purposes, this one is done.
In making this I realized that the stars in system FS18 are really bright. It’s an M0 Giant and A0 main sequence star in a binary system. Combined, they are ~39x brighter than the sun and only 2 ly from Athor. That means they would appear to be at -5.27 magnitude star in the night sky. For reference, the brightest star in our sky, Sirius, is only -1.46 (small, more negative numbers are brighter). Venus, at its brightest, is a -4.2 magnitude object. That means that this star appears 2.5 times brighter than Venus at it’s brightest and about 30 times brighter than Sirius.
The Full Map
Now that the AD map is done, it’s time to start working on the full Extended Frontier map. I knew I was going to need a lot of random star systems so I generated a big random map with the program to get a good number of star systems with the correct spectral type distribution. I’ll use this whenever I need a random system value.
That done, the first step was to get the data for all the various labeled systems on the map. I already had the ones from the AD map I just needed to add the others. The data for these systems came from a variety of places. For the systems included on the Zeb’s Guide map, I used the spectral types listed in Zeb’s Guide after verifying that they made sense when mentioned in the modules (which usually just gave a color). I didn’t find any real issues so I just used the Zeb’s Guide values.
For the Saurian systems (east of the Frontier), the spectral types were taken from the article “The Sauria Sector” published in the Frontier Explorer, issue 4.
The data for the S’sessu systems (south of the Frontier), the spectral types were taken from the article “Phri’sk Anyone? Detailing the S’sessu Homeworlds” in issue 16 of the Frontier Explorer (p 23 – I haven’t gotten around to putting the individual articles of that issue on-line yet). However, that article only listed spectral types for two of the systems. For the other three, I selected random spectral types in the G & K spectral types from the list of random systems.
With all the star systems in place, I added in all the jump routes connecting those systems. I discovered I had a limit in my code that would not print a jump if it was over 14 light years in length. This was preventing the jump between Gruna Garu and Lynchpin from being drawn so I had to fix that bug. I still don’t let the random process create jumps that long but if you’re entering the data for a map and want a longer connection, the software won’t stop you anymore.
This also required me to change a couple of things. If you’re familiar with Zeb’s Guide, you may notice that the connection between Zebulon and Capella is now a straight line at 9 ly instead of a broken line at 10 ly. The broken line never made any sense given the Knight Hawks rules so I’ve done away with it. The other change was the connection between the S’sessu worlds of Kashra’sk and Minan. The map in the Frontier Explorer lists the distance as 12 ly but it is actually only 11. That is fixed on this map.
The next step is to now add in all the other systems on the map. To do this, I simply pull a system entry from the big random list for each star system on the map and remove the system from the big list so I don’t reuse it. I started in on that process, filling in the systems to the southwest of the Frontier but haven’t finished entering everything else yet. That will be the subject of the next update. However, here’s the big map as it currently stands.
Click for the full resolution version. This map is 4550×5050 px and ~1MB in size
This is just the raw, software generated map, with no tweaking or extra annotations on it. Over the next week or two, I’ll start adding in the rest of the stars and the nebulae. This map covers an area 90 ly wide and 100 ly high which should give your players plenty of area to explore if they need to get out of the Frontier and into the wilds.
That’s it for now
That’s where the project currently stands. If you have any thoughts, questions, or suggestions, let me know in the comments below.
