Star Map Generator – GUI Edition

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.

StarMapGen-initialGUI.zip (12.3MB)

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:

Notice anything missing? It’s supposed to look like this:

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.

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:

StarMapGen-v0.2.0.zip (MB)

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.

Legends and Lore – Yazirians

This is the second part of my post on the history, legends, and lore of the yazirians in my Star Frontier universe. Part one, Yazirian History, was posted last week. Both of these posts are part of February’s RPG Blog Carnival, Legends and Lore, being hosted by the Enderra blog.

In last week’s post, we looked at the history of the yazirian species in relation to their arrival in the Frontier region and colonization of the worlds they now occupy. Most of the material presented there is both fact and general knowledge in the Frontier that most characters would either know or be able to discover with just a little bit of research. In this post, we look at things that may be true but unknown, true but hidden, rumor, speculation, or conjecture, the latter three may be true or false. I’ll try to flag each of these items as I discuss them.

Some of this information is part of the ideas I have for an major campaign where the PCs go in search of the yazirian homeworld, the fate of those that remained behind, and the Warhon’s ship. They are definitely spoilers for anyone that may play in that game if I ever run it.

I think the best way to do this will be to organize the ideas by general topic, possibly with a miscellaneous section at the end. In each section, I’m just going to provide a bulleted list with the relevant information. Let’s get started.

The Fate of Yazira

The last exodus ship that arrived in the Frontier departed Yazira some ten years before closest approach of the interloping brown dwarf. (fact, known)
Millions of yazirians remained on Yaziria unwilling to leave their world. (fact, known)
No ship has ever returned to the Yazira system. (fact, known)
In the early days after yazirians arrived in the Frontier, several ships attempted to go back to Yazira to see what happened. None of these ships have ever returned. (fact, obscure)
Most of these ships that failed to return were destroyed by agents of the Family of One. (fact, deeply hidden) Some simply disappeared and their fate is unknown, but none made it to Yazira.
There is no known jump route data back to Yazira. (false rumor). Deep within the archives of Clan Anglann and the Family of One, there is a stored set of routes back to Yazira. They are known only to a few yazirians and heavily guarded and obscured. They are also nearly a century out of date at this point and may not be valid.
Modern yazirians don’t even know which star is their homeworld, just the general direction in the sky. (fact, known) There are some members of the Family of One who know, but this knowledge is a closely guarded secret as well.
Predictions of Yazira’s fate, based on the path of the brown dwarf, indicated that the planet would be hurled out of the system into deep interstellar space. (fact, obscure)
Instead of being spun out into interstellar space, Yaziria was actually captured by the brown dwarf as it passed through the system and now circles that object in a wide orbit as it continues on its journey. (fact, unknown)

Fate of the Warhon and his Guard

Of all the exodus ships, only the Warhon’s ship failed to make the trip to the Frontier (fact, known)
The Warhon’s ship was sabotaged by agents of Clan Anglann so that it wouldn’t arrive and they could seize power. (discredited rumor, but true). There is no evidence to support this anywhere in the Frontier but Clan Anglann did sabotage the Warhon’s ship. All records possibly relating to this were lost in a computer “crash” early after the exodus. Only two living yazirians, seniors elders in the Family of One, know the truth and they aren’t saying anything.
Most of the Warhon’s personal guard that were part of the early exodus died soon after arriving in the Frontier. (fact, obscure) Most of these deaths were “accidents” caused by Clan Anglann (obscure rumor, fact). Most modern yazirians have moved on and just don’t care.
Some of the Warhon’s Guard survived the purge and quickly emigrated to the Prenglar, Triad, and Truane’s Star systems where they went into hiding from the Family of One. (fact, obscure)
The survivors of the Warhon’s Guard formed a secret society named “True Yaziria” that word to oppose or diminish the influence of the Family of One (fact, obscure)
Despite the sabotage of the Warhon’s ship, it was not destroyed and managed to survive long enough to make planetfall on an unknown world. (fact, unknown) Rumors exist that it is still out there, spread by True Yazira, but it is all speculation. No facts exist to support it.
The genetic Ark on the Warhon’s ship survived and is completely intact in the remains of the ship. (fact, unknown)
All of the conspiracy against the Warhon was a very small slice of Clan Anglann. (fact, unknown/hidden) Most clan members were not involved and would be horrified to know the truth.

The General Population

Very few living yazirians actually remember their homeworld as most were born in the Frontier. There is a small and dwindling population (maybe 10%) of older yazirians that actually lived on Yazira. (fact, known)
There is a fairly large generation gap between this older population and the next wave of yazirians. In the final years leading up to the exodus, the birthrate dropped off significantly. (fact, known)
The yazirians of the Frontier, while aware of Yazira, don’t give it much thought except as it is used in holovids and expressions about how things used to be. (fact, known)
The problems with terraforming operations on the worlds in the Scree Fron, Athor, and Gruna Garu systems are intentional problems caused by the Family of One and the General Overall Development Corporation (GODCo) to keep those systems in line. (false, rumor). The problems truly are technical and result from GODCo being overextended trying to work on five different worlds instead of just the one they original planned for. Despite having nearly a century to grow, they still don’t have the resources and manpower they need. These issues provide openings for rumors to be spread by the True Yazira society in their effort to undermine the Family of One.
Interaction with the other species of the Frontier dealt a serious blow to the yazirian cultural identity as a warrior species. (fact, obscure) They discovered that despite their history, they were neither the strongest nor the nimblest species in the area. Although it is slowly fading away, ripples of this are still seen throughout yazirian culture, especially among older yazirians.

Lost Scoutships

There were many scout ships sent out from Yazira shortly after FTL travel was discovered, most of these never returned. (fact, obscure)
Several of these lost starships made it to systems in or near the Frontier, including Volturnus in the Zebulon system. There may be survivors, possibly descendants of the crews, in primitive societies to be discovered. The crew that made it to Zebulon did not survive. (fact, unknown)
Some of the scoutships penetrated into sathar space and were captured or destroyed. (fact, unknown)

Family of One and GODCo

All of the upper management of GODCo are members of the Family of One (fact, discoverable).
All of the upper management of GODCo are members of Clan Anglann (false, rumor). While a significant portion are, not all of them are from the same clan.
The Family of One is using the work done by GODCo to attempt to control all of the yazirian populated worlds. (false, rumor). While the upper leadership of GODCo are members of the Family of One, they are not ideological power-mongers. At least not any more than leaders of other mega-corps. While some fervently believe in the idea of a unified yazirian species according to the Family of One precepts, many are only interested in helping their fellow yazirians and are members of the Family of One out of necessity – they couldn’t hold their position if they weren’t.
Many members of the Family of One are members in name only and only minimally hold to many of the tenants of the religion. (fact) They are members because you need to be to hold any significant position on Hentz (Araks).
Family of One members on worlds other than Hentz tend to me more fervent as membership is optional on those worlds. (fact)
The Family of One is watching all aspects of yazirian culture, everywhere. (partially true, rumor). While the Family of One tries to keep abreast of everything going on, they don’t have nearly as many spies, inquisitors, and informants as the rumors (spread by the True Yazira society) would have you believe.
The Family of One is preventing GODCo from deploying all of its technology and releasing all the flora and fauna from Yazira on the worlds other than Hentz. (fact). Debates about this practice arise regularly in yazirian society. GODCo claims that it is because the environment are not ready or suitable, but most of the restrictions come from the Family of One and their effort to ensure that Hentz is the only “New Yazira”.

HSS History’s Hope

In my Detailed Frontier Timeline, one of the story threads is covering the travels of the HSS History’s Hope, a small exploration ship registered on Hakosaur (Scree Fron) that is currently trying to chart a route to a star system believed to be Yazira. If you want to use this little storyline in your campaign, there are some rumors about it, even though the project has just started.

The Family of One tried to cover up and suppress the discovery of the star system with the nearby brown dwarf because they knew it was Yazira. (fact, rumor) This rumor popped up almost immediately and is based in fact. The star system is Yazira and the Family of One doesn’t want people poking around because no one knows what they will find.
The HSS History’s Hope is being financed by True Yazira. (partially true) While many of the original supporters of the expedition, and and many that provided initial funding, are members of True Yazira, not all of them are and it isn’t a project being directed by the secret society. It just aligned with the society’s goals and many members independently jumped on the opportunity.
Most of the entire crew of the HSS History’s Hope are members of True Yaziria (fact, obscure rumor). Since the society’s membership is very obscured, it is hard to tell for sure who is and who isn’t a member. The rumor circulates among upper members of the Family of One. Most others don’t know about the secret society or don’t care. The fact is that about 80% of the crew are members of the society simply because they have an interest in finding Yazira. It wasn’t intentionally planned.
The Family of One has sent ships to eliminate the HSS History’s Hope. (fact, hidden). This one is a spoiler for the timeline. As I’m writing this, the History’s Hope has had a bad string of calculations and made some misjumps. When they finally get back to the known space lanes, they are going to have to deal with this.

Outstanding Questions

The points above provide some ideas and background but they also raise a number of questions. These are either things I’m going to flesh out in the future as I develop the storylines more or things that someone using this information could expand upon as well. Some of these are:

What exactly happened to the Warhon’s ship?
- How did it fail? What was the damage?
- Did the crew survive? All enter freeze fields?
- What happened to the Warhon’s family?
If they made it to a planet surface, what is their current state?
- Another yazirian colony?
- What tech level are they at?
- What happened to the genetic ark?
What is the “True Yaziria” society doing?
- How to you become a member?
- How well known is it?
- What resources does it have access to?
- I invented this organization just recently as I was working out the detail of these two posts so this is an area I plan on expanding on. This may very well show up as an entry in June when I’m hosting the Blog Carnival.
What events and consequences will the HSS History’s Hope expedition trigger? What will they find?

Final Thoughts

That’s what I have for now. There is still a lot of legend and lore for the yazirians that could be explored. I intentionally didn’t cover much in regards to the daily life of a typical member of the species and current events in the Frontier, just items that are part of their cultural heritage. Some of these other ideas will undoubtedly show up in future posts. Other bits may show up in the pages of the Frontier Explorer.

What legends and lore do you have for the yazirian species? Share your ideas in the comment section below.

Yazirian History

The RPG Blog Carnival this month is being hosted by the Enderra Worldbuild & Role-playing Games blog and the topic is Legends and Lore. You can follow that link to find all the other posts people have made on the topic.

When I read this topic, my mind immediately went to the Yazirians in the Star Frontiers setting. They were a natural choice to pursue in greater depth, especially based on much of the fan material that has been developed for that species. And while I’ve been thinking about these ideas for all of the Star Frontiers species, the yazirians are particularly relevant to me right now since part of my Detailed Frontier Timeline (most recent post as of this writing) is currently dealing with a plot line exploring this history directly, namely a ship, the HSS History’s Hope, that is headed toward a system that they think might be Yazira, the yazirian homeworld.

A lot of the foundation for this background is set in two articles that we published in the Star Frontiersman nearly a decade ago in issue 16, back in December 2010. The first is an article written by my friend Tom Verreault entitled “Origin of the Species & the UPF” on page 34 of that issue. In this he gives his version of how the various species in the Frontier got there. The second article, which I wrote to support the ideas he presented for the yazirians in that article, is entitled “Interstellar Interloper (Brown Dwarf)” (p. 46), and discusses what could happen to a planetary system if a brown dwarf sized object passed close through the center of a star system. I recommend you grab issue 16 and read both articles.

This is going to be a two part series. In this first post will look at the background and history of the Yazirian race as I conceive them when running games. The next one will look at the Legends and Lore as it exists at the current point in the campaign. Some of the material is fact, some is common knowledge, some is belief, and some is propaganda. I’ll be looking at it from all those angles.

The Loss of Yazira

The yazirian homeworld, Yazira, orbited a K4 star that is located some 100 light years “west” of the Frontier in an area known as the Vast Expanse, so named because of its low stellar density and large distances between neighboring star systems. Interestingly, very, very few yazirians living today actually know the location of this star system. More on that in the next post. To start let’s go back to about 200 years ago.

It was a time of relative peace and growing industrialization and prosperity for the world. The world had been united under a single government for several centuries and was beginning to develop spaceflight and really start looking into the universe beyond the Yazira system.

A Threat Discovered

It was at this point, as they began to survey the cosmos, that the yazirian astronomers noticed something in the sky that would completely change the course of their specie’s history. When it was first discovered, it was a curiosity. An object extremely bright in the infrared but extremely faint in the visible, even with the yazirian’s definition of visible light that extended somewhat into the infrared. It wasn’t long before a theoretical model was developed for the object, something we today call a brown dwarf.

The astronomers were excited. Based on the observed characteristics, they realized it had to be very close to Yazira. It would allow them to study this type of object up close. As the object was studied more, the distance, a mere 1500 AU, was established.

However, what was also established was that it was coming closer. Over the next few years, the orbit of the object was refined and it was realized that the brown dwarf was falling nearly directly toward their star and would pass very close to their world in the process. Simulations showed that depending on the mass of the object and its exact path, their world and species was in for a major catastrophe ranging from severe and drastic orbital and therefore climate change to complete ejection from their solar system. If something wasn’t done, they were probably doomed as a species.

The bad news was that they were in trouble. The good news was that they had nearly 140 years to prepare. To the Warhon’s credit (the leader of the yazirians), he took the news in stride and neither dismissed it since it wouldn’t happen in his lifetime, nor panicked. Rather he understood the issue for what it was and began charting a course for his people.

The general populace wasn’t so stoic. Many denounced the scientists as alarmists. Others claimed the discovery to be a hoax. Still others used it to as an excuse to hoard survival gear, food, and other essentials and drop out of society. Many just ignored it due to the long time scale. The most troubling, however, were those that took the news to mean that society was over and reverted to lawlessness and anarchy. It was these latter groups that would plague yazirian society for the next century.

A Plan Takes Shape

Over the next decade, as the Warhon’s troops dealt with the anarchists and the astronomers worked to refine the object’s trajectory even more, the government began investing heavily in space technology. While yazirians had already visited their two moons and had many low altitude orbital flights, the extra push from the government allowed them to set foot on other worlds in the system for the first time before the decade was over.

With the development in space technology well under way, the government also started a few other projects. One was increased medical research, especially related to long duration spaceflight and how the yazirian body would adapt and change under different conditions (gravity, stellar flux, etc).

The other was called the Ark Project. This had two areas of focus. The first was to catalog the genomes of every species on the planet, plant and animal, and collect this into a large database as well as collecting samples of as many species as possible. The second was a push into cloning technology that would allow the recreation of those species from the database.

The ultimate goal was to move the yazirian population off of their homeworld to somewhere else. Where was yet to be determined. The initial plan called for the creation of huge generations ships that would travel to likely star systems looking for a world to inhabit. Astronomers had already begun looking for worlds around other suitable stars.

A Change of Plans

Some thirty years after the original identification of the brown dwarf, a discovery occurred that would change the very foundation of what had come to be called the Exodus project.

Using a variety of propulsion technologies, a major break through had been achieved that would allow them to accelerate small probes fast enough to reach some of the nearer star systems before the generations ships would have to leave the Yazira system. The first probes were launched, and as they achieved speeds of about 1% the speed of light, only a fraction of their final velocity, they vanished.

At first it was believed that the probes had broke up or otherwise become inoperable. However, deep radar scans of the region of space they should have been in returned no data. And having five probes, all going different directions, vanish in exactly the same way was more than mere coincidence.

Another set of probes were launched as a test which ended with the exact same result. Yazirian scientists realized that this was some fundamental aspect of physics that they had not suspected or known about. Hundreds of researchers started working on the problem.

It was nearly a decade before a breakthrough was made and a theory of hyperdimensional travel was discovered. In the mean time, work had been going on to improve technology to the point that a crewed vessel could achieve the speeds necessary to invoke the effect.

It would be another decade before a ship was ready to make the first attempt at testing this theory. With a total delta-V of 5% of the speed of light, the ship should be able to achieve the hyperdimenional travel speed, slow down and do it again. Thus is should be able to make a trip and return. In theory.

A Historic Flight

With an all volunteer crew, the YSS Grand Voyager set out on its maiden voyage in an attempt to make history. It took a month of acceleration to get up to near the 1% speed of light threshold and then another agonizing month of small bursts of thrust to precisely measure and cross the threshold. Then just like the the probes, the Grand Voyager vanished.

It would be months of anxious waiting before the fate of the Grand Voyager would be learned. Most people had given up hope when a faint radio signal was received from the ship coming from high out of the orbital plane of the system. They had survived the trip and hyperdimensional travel, which would come to be called Void travel when they met the other species in the Frontier, was possible. There was still much to learn about this new form of travel, but the travel time for the exodus had been greatly reduced.

Looking for a Place to Call Home

Over the next two decades, propulsion technology was innovated and improved and more and more ships were launched to scout out the nearby star systems looking for a world that they could move the population of Yazira to. Most of these ships would eventually be lost as they explored further and further from Yazira. It was not known if there were troubles with the Void travel, mechanical failures with the ships, or they had suffered misfortune in the systems they visited.

As ships did return, they learned much about the nearby stellar systems but no suitable world was found. Finally, after nearly two more decades of searching, a ship returned from a two year journey reporting that a suitable world had been found, nearly 100 light years away. The star was significantly brighter and yellower than Yazira but the world itself was nearly Yazira’s twin in climate and gravity.

During this time, the designs of the exodus ships were rebuilt from the ground up to use this new mode of faster than light travel. With a destination finally established, exploration ceased and construction began on the first ship, the YSS Yazira’s Ark, that would take a select crew, along with a copy of the genetic archive, to this new world to start preparing it for the arrival of the rest of the population.

The Exodus Begins

It took five years for the YSS Yazira’s Ark to be completed. Crewed primarily by members of Clan Anglann, it departed for the new system which had been dubbed Araks to colonize and begin yaziriforming the planet Hentz.

By this time, the brown dwarf was visible to the unaided eye on Yazira and was year by year growing brighter. The world began to focus almost completely on the construction of the exodus ships. While there were some that decried the damage being done to the environment due to the industrialization of the planet, most understood that the world was doomed and so accepted the changes.

Five years after the YSS Yazira’s Ark left, five more ship were completed with nearly twenty-five more in some stated of completion. These later ships were gigantic, nearly ten times the size of the Yazira’s Ark. It would take nearly two hundred more to move the entire population. With the first five ships complete, the exodus of the yazirian population to Hentz began in earnest.

It had been decided early on that when the time came, ships would be populated by clans. While the crews were often from Clan Anglann, the passengers were drawn from a single clan or possibly two. Depending on the size of the clan, it could take two or three ships to hold the entire clan population.

Over the next two decades, a steady stream of ships departed the Yazira system. Finally, the last ships were completed, three of the giant colony ships and a final, smaller ship modeled on the original Yazira’s Ark. This last ship contained the Royal Court, the Warhon and his family, who was the son of the Warhon who had started the project, 120 years earlier. It also contained a final copy of the genetic database including all the additional data that had been collected since the Yazira’s Ark had left. It was the last ship to leave their doomed world. The interloping brown dwarf was clearly visible in the night sky and only 18 years away. It was the last ship to leave.

Trouble at the Destination

As the second wave of colony ships were arriving at Hentz, the yazirians detected signals from other spacefaring species not too far from their new world. Concerned that they might be hostile, Clan Anglann, which had been organizing the exodus, diverted ships from waves three and four to several new worlds in systems nearby. These ships went to the Athor, Gruna Garu and Scree Fron systems. The worlds there were not as desirable as Hentz, but the yazirians wouldn’t have all their eggs in a single basket if these new species proved to be hostile.

Loss of the Warhon

The trip from Yazira to Araks was a long one requiring nearly twenty Void jumps along the way. As the final fleet of ships made the journey, disaster struck. On the 5th jump, the Warhon’s ship didn’t arrive in the destination system. The other three ships waited for nearly two months but the Warhon never reappeared. Finally, they completed their journey and delivered the news to the yazirians on Hentz and it was related to the others in the Athor, Gruna Garu, and Scree Fron systems.

A week of mourning was held for the Warhon’s family. And then political chaos erupted. With the entire royal family gone, a power vacuum was created. In the end, Clan Anglann and the Family of One, who had been organizing the exodus on behalf of the Warhon, took control of the yazirian government.

Fallout

Many suspected foul play. Of the nearly 250 ships built, only the newest ship with the most up to date technology was unable to make the trip. Coincidentally, it also happened to contain the Warhon and his family. The most vocal opponents of the Family of One’s rule was the Warhon’s personal guard that had arrived in advance. Their voices were quickly surpressed. Many just vanished. Others emigrated to the Prenglar, Cassidine, and Truane’s Star systems, integrating with the other races in the Frontier who the yazirians had established contact with some years before.

It wasn’t too many years later that the sathar first appeared in the Frontier. This effectively put an end to the inter-clan conflict as the species in the Frontier united to fend off his new foe. With the formation of the UPF, the yazirian race started looking forward instead of back. Some still remember the old days but most have accepted the new order and are working toward the future.

Next Time

That represents the history of the Yazirian people as most people know it. There are a few things in that narrative that are not widely known (such as the suppression of dissension by the Family of One, but that information should be familiar to most yazirian characters and many non-yazirians as well.

Next week we’ll look at lots of details behind the scenes and outside the Frontier that impact the store and contribute to the lore of the yazirian species.

Worlds of Origin for Star Frontiers Races – part 1

This week we’re going to begin looking at determining the origins of any given character or NPC in the Frontier. I’ve labeled this as part 1 in a series as it is a preliminary draft that I plan to tweak and expand on in the future. This is really a preliminary, first pass but still quite usable in its current form.

This is the post I had planned for last week but didn’t quite have it ready in time so you got the UPF Minelayer a week early.

This project is something that’s been kicking around in the back of my mind for years now and I was inspired to look at it again as part of the RPG Blog Carnival this month which has the topic “Random Encounter Tables“. While this isn’t necessarily a random encounter table per se, it can be used to randomly determine information about someone you encounter in the game. It’s a bit of a stretch, but still relevant. I encourage everyone to visit the main topic page for this months carnival and read all the posts linked to in the comments. I’ll be hosting the blog carnival in June so I’m going to make an effort to write a post each month for the carnival this year and become more active. It tends to be more focused on fantasy gaming so sometimes I’ll really need to stretch the topic but we’ll see how it goes.

We’re going to start right with the table and then I’ll talk about how it was generated. If you’re interested in a slightly different take on this same topic, we published an article, “Star Frontiers Birth Locations” by ExileInParadise, in issue 19 of the Frontier Explorer back in Jan 2017 as part of our Star Frontiers 35th anniversary issue. This article will be a first pass at my take on that same topic.

Where Are You From?

To randomly determine the world of origin of one of the “Core Four” Star Frontiers species, roll d100 on the following table. Find the value rolled in the column for the species in question and the line tells you the origin world and system for that character. This version of the table is ordered by system and not the name of the world.

Planet (system)	Dralasite	Human	Vrusk	Yazirian
Hentz (Araks)	1	1	1	1-12
Yast (Athor)	2-3	2-3	2-3	13-19
Rupert’s Hole (Cassidine)	4-6	4-10	4-5	20-22
Triad (Cassidine)	7-18	11-20	6-17	23-33
Laco (Dixon’s Star)	19	21-22	18	34
Inner Reach (Dramune)	20-27	23-24	19-21	35-37
Outer Reach (Dramune)	28-35	25-31	22-28	38-44
Groth (Fromeltar)	36-40	32	29	45
Terledrom (Fromeltar)	41-52	33-35	30-41	46-49
Hargut (Gruna Goru)	53-56	36-38	42-45	50-61
Ken’zah Kit (K’aken-Kar)	57-59	39-40	46-52	62-63
Zit-Kit (Kizk’-Kar)	60-62	41-42	53-59	64-66
Kawdl-Kit (K’tsa-Kar)	63	43	60-64	67
Kdikit (Madderly’s Star)	64-65	44-50	65	68-69
Gran Quivera (Prenglar)	66-78	51-61	66-76	70-81
Morgaine’s World (Prenglar)	79	62-63	77	82
Histran (Scree Fron)	80	64	78-79	83
Hakosoar (Scree Fron)	81	65	80-82	84
Minotaur (Theseus)	82-85	66-75	83-86	85-87
Lossend (Timeon)	86-87	76-79	87-88	88
Pale (Truane’s Star)	88-95	80-86	89-95	89-95
New Pale (Truane’s Star)	96	87-90	96	96
Clarion (White Light)	97-100	91-100	97-100	97-100

If you just want to use the table, you’re done. Enjoy. If you want to learn a bit more about how I created it, read on.

Building the Table

First off, this table just covers the original systems presented in the original (Alpha Dawn) ruleset, and doesn’t include Volturnus (Zebulon) as there is no indigenous core four population there in that rule set. Also, that rule set left Kawdl-Kit (K’tsa-Kar) out of the data table so I’ve used the values from Zeb’s Guide for that system.

Design Decisions

One of the decisions I made in creating the table is that it is possible for any of the core four races to be from any planet, although the chance may be very small.

Another decision I made was that I didn’t want either a d1000 table (although that’s easy enough to do in Star Frontiers that only uses d10s) and I didn’t want a series of sub-tables. One roll and you would be done.

The result of those decisions is that the smallest probability of having a race/homeworld combination is 1% and for certain situations this is probably a bit (or even a lot) higher than it would really be given the demographics and politics of the Frontier. An example is a non-Yazirian race from Hentz, a world controlled by the Family of One where non-yazirians are second class citizen. There just aren’t that many there. Similarly, vrusk from Kdikit (Madderly’s Star) after most vrusk were driven off world by the Freeworld Rebellion. Although you could also argue that those situations drive up the chance that those beings would be off-world and increase the chance. So in the end, it’s all good.

Getting the Base Numbers

The rules give a dominant population and a population density for each world in the Frontier. The dominant population could be one of the core four races, a mix of two (Terledrom, Fromeltar with a D/V designation for dralasites and vrusk) or an asterisk (“*”) meaning relatively equal mix of all species. The population codes were either outpost, low, medium, or high.

To determine the relative number of each species on each planet I used the following formula. First, an outpost was given a value of 1, low population given a value of 3, medium population a value of 5, and high population a a value of 8. Next, if a species was not listed as a dominant population on a world, it just received the value above. If it was the dominant population, I multiplied that value by three. For the systems marked with an asterisk, I gave all the species the x3 multiplier. Since these planets are the core planets of the Frontier, typically with high populations, this just helps to concentrate the population density there.

For example, Inner Reach, Dramune, is listed as a medium population and the dominant species as Dralasites. So for this world, humans, yazirians, and vrusk all receive 5 points while dralasites receive 15.

This was done for each planet in the Frontier which gave me a large table that listed points for each race on each planet.

Calculating the Table Percentages

Next I tallied up the points for each race. Depending on the species, those totals ranged from 190 to 226. Using those values I scaled the points for each species so that the total came to 100. This effectively gave me the percentage of each species that came from each planet. Some of these, especially on the outpost worlds, end up with percentages less than 1 but given my assumptions, those all get rounded up to 1%.

After that, it was just a matter of tallying up the percentages to make the table. I built a cumulative table first by just adding up the percentages. Due to the small fractional percentages of the low probability planets, this resulted in some planets having the same value.

To fix this, I fixed some of the percentages to 1. This in turn, pushed the totals above 100 for some of the species. To fix that, I then adjusted the percentages down on a few of the worlds based on physical characteristics and game lore.

I started by reducing the percentage of non-yazirian races on Hentz to one. This reflects (as mentioned above) the fact that that world is very rigidly controlled by the yazirian Family of One and non-yazirians are practically, if not in fact, second-class citizens. Next I reduced the percentages of yazirians on high gravity worlds. This is based on the idea that those worlds are less desirable to yazirians because their gliding ability is greatly diminished on these worlds and so the populations would be smaller. For the vrusk, I set the percentage on Kdikit (Madderly’s Star) to one to reflect the expulsion of the vrusk after the Freeworld Rebellion. Finally, I reduced the percentage of non-yaziran races on the worlds in the Scree Fron system because it is far from the core of the Frontier and deep in yazirian space.

After making these changes, and a few other small tweaks, I ended up with the results presented in the table above.

Thoughts and Discussion

This is definitely a first draft. It will probably get tweaked a bit as I flesh out the lore of the worlds a bit more. I may change the relative populations of the the various species as well as the overall population numbers for any given world (i.e not making all medium populations a value of 5 or every high population world a value of 8) That said, this is definitely usable to get a rough idea of where any given member of each species is from. Future versions will also include the Zeb’s Guide systems as well as generate tables for the Rim races, at the very least.

One thing that this doesn’t do is show the relative percentages of each species on any given planet. Since I renormalized the values for each race, that changed the relative percentages of the races on any given planet. As I refine those relative values a bit more, they will get reflected into the raw data used. I may start presenting that information in separate posts on each world.

What are your thoughts on the table? What other information would you like to see? What is missing? What would you do differently? Let me know in the comments below. And be sure to head over to the Random Encounter Tables post to check out the other posts in this month’s RPG Blog Carnival.