I hope this post finds you well, healthy, and safe as we navigate these troubled times. Luckily for us, we’ve managed to avoid any illness (other than allergies are hitting us hard) and everyone has remained employed. I worked from home before this all hit and the only real change from my day to day routine is that I now have to supervise school work for my kids. Of course that means less time to work on gaming projects. My wife is a college professor and for her things, actually improved in some ways as she could still go into her office but doesn’t have as many distractions every day. It has been a strange time and hopefully we all pull through it without too much damage.
Looking Back
Despite everything going one, I managed to get a new post out every week. The last post (Starship Construction in the Frontier) was only an hour late. I had actually finished it the night before but forgot to queue it up and then was busy in the morning. Otherwise, we had the usual Detailed Frontier Timeline post to start the month followed by the miniature post, this time about the Agriculture Ship. The final post of the month, which was part of the RPG Blog Carnival, was an update to my star sector map generator, this time adding in a graphical user interface making it easier to use.
Now, back at the end of last month, I talked about doing a post on the True Yazira secret society. Which you may notice I didn’t get to. That was actually a conscious decision. That post will probably come in June, when I’m hosting the Blog Carnival with a theme of “Organizations”. But more on that next month.
The other major thing that happened this month was that I finished and published the next issue of the Frontier Explorer. Issue 28 represents seven full years of publishing, even including the year we took off. If you haven’t gotten a copy, jump over to the Issue 28 page on DriveThruRPG and grab one. As I’m writing this, there have already been over 600 downloads of the issue. I’m quite happy with how it turned out.
Otherwise, most of my other behind the scenes activities were completely obliterated by the changes and school closings due to COVID-19. I haven’t even looked at my book. I also didn’t do any work on migrating or updating the websites. The other thing that suffered is my modeling efforts. I didn’t get a chance to work on any new models this month. There were also a few days when I fell a little bit behind on some of my timeline posts on Twitter but I got caught back up and back on track. Although I do need to sit down and get a little bit ahead of that project.
Looking Forward
This month will start with the usual Detailed Frontier Timeline post. The second post will probably not be a new model. I hope to have one later in the month but I don’t think I’ll have one ready by then. Instead the second post will probably be a spin off of my starship construction post. I’ve been thinking a lot about that and had some good discussions on Facebook and I’ve got another post in the work looking at the logistics and economics of space travel, again looking at how that affects the number of ships to expect in the setting. I have no idea what the final post of the month might be as the topic for next month’s Blog Carnival is still TBD. I guess we’ll find out together.
The other thing that will be starting this month is that I’m going to start running an on-line Star Frontiers game. I’m going to shoot for a weekly game but it might end up being bi-weekly instead. We’ll see how that turns out and I’ll probably be posting on that as we go along. If nothing else, I’ll be generating maps and adventures and can post those once the players have finished with them. It may also end up as an actual play podcast if the players are willing to let me record and post it.
The work on the Space Kids RPG hasn’t started yet so that may also begin this month. Nick Landry, who is producing the game, is working hard and may get to the point where he needs my input. At this point, I’m just waiting on him.
What have you been working on this last month? Are there things you’d like to see me post about? Let me know in the comments below.
Way back in issue 10 of the Frontier Explorer (has it really been over 5 years?!?) I wrote an article entitled “How Many Ships Are There?” (p.27) where I examined the number of starships that could be supported in the Frontier given the stated number of starship construction centers and the ship construction and maintenance rules. The answer came out to be around 1500 ships, not a lot to spread around the 17 systems and Spacefleet.
Starship construction image by Scott Mulder
In that article I talked about some of the implications of that small number and some of the ways you could increase the number of ships flying around. If you haven’t already read that article, I recommend you do so as I’ll be building on some of the work there. Although it’s not necessary to follow along.
While I’m very much in favor of small ship numbers, I think that even this is too small for the setting and in this post I’m going to examine the numbers and methods of ship production and maintenance and see what impacts that has on ship numbers.
At least part of the desire to look at these numbers stems from some campaign background work I’m doing related to the Second Sathar War and how the Frontier would respond to the new Sathar incursion. So let’s get started.
The Baseline
To start with, we need to have an idea of what the base production and maintenance rate in the Frontier is so we can see how changes we make affect that.
When I wrote the article for the Frontier Explorer, I created a Python program that would simulate the starship construction centers, their waiting queues, and handle all the book keeping. That is how I generated the numbers for that article. So the first step was to dust that off and get familiar with the code again. If you’re interested, it is in this GitHub repository. There is no documentation and it’s really rough but you’re free to play around with it.
There are actually two different programs in there. One is the simulation I used for this post and the Frontier Explorer article and the other is one I’m using to keep track and generate the sathar starship construction efforts for the Detailed Frontier Timeline project. Both are really rough (although I do have some unit tests). Caveat emptor.
Since we’re just going to be looking at variations, I’m not trying to reproduce the exact numbers from the Frontier Explorer article. In fact, I’m going to use a very different distribution that gives me more ships as a baseline than the number from that article.
For this article, the distribution I’m going to use is one that has roughly equal numbers of ships hull size 1 to 10 (~6.6% each) and then falling off beyond 10 so that there is only about a .5% chance of building a HS 20 ship. This weighs the distribution toward smaller ships. As I pointed out in the original article, the smaller the average hull size of the ships flying around the Frontier, the more ships the canonical starship construction centers (SCCs) can support. The average hull size of ship produced is 6.5.
I’m also making a few other assumptions. First, I’m treating these all as civilian ships, so any ship can be built at any SCC as long as it is less than that SCC’s maximum hull size limit. Also, I’m not factoring the hull availability rules into the simulation. I’m assuming any size hull is always available. Finally, I’m ignoring the “only system ships” restriction on the smaller Class III construction centers. I’m only interested in counts, not types.
The other “feature” of the simulation is that it doesn’t really handle the queuing of hulls waiting to be built in the best manner. It simply looks at the available space and finds the next ship in the list that will fit. What this means is that larger ships tend to get passed over as there is never any room for them. This also tends to skew the ships sizes toward the smaller hull sizes over time.
Image by Scott Mulder
With this ship distribution and those assumptions, the SSCs listed on page 9 of the Knight Hawks Campaign book can support about 2300 ships. Which is already a significant improvement over the 1500 ships from the original article. If you’re curious, reversing the distribution (ramping up to HS 11 and flat thereafter, only allows the system to support about 1250 ships).
Supporting More Ships
Now with that baseline, let’s look at increasing the number of ships we can support. There are several factors that go into the final number: total capacity, ship size distribution, construction time, and maintenance time.
I’m not going to play with construction time. That actually would have little effect on the total number as the steady state is purely based on the other factors, which are somewhat related to each other. Let’s look at some options.
Double the Number of SCCs
Image by Scott Mulder
The canonical set of SCCs has a total capacity of 510 point of hull size across the nine lists construction centers that can be under construction or in maintenance. Let’s start by just doubling that number. Let’s add 9 more SCCs across the Frontier that are clones of the existing nine. We’ll keep the other parameters the same and start up a new simulation.
Running the simulation with the increased number of SCCs results in the Frontier being able to support about 4100 ships, and increase of 1800 ships of about 80%. It doesn’t double as the increased capacity allows a few more larger ships to get built right at the beginning and the average hull size of ships produced jumps from 6.5 to 7. Since the average HS is larger, the total number is less than 2x based on the 2x capacity.
Planetary Small Ship SCCs
What if we try increasing capacity in another way. Instead of just cloning the existing SCCs, let’s give each planet a small SCC that can only build ships up to HS 5 and can handle 20 hull size points of ships at a time. This represents each planet being able to build and maintain it’s own fleet of shuttlecraft and small system ships separate from the main SCC.
If you drop those 22 SCCs (I didn’t give one to Volturnus) into the Frontier, that adds in another 440 hull size points of capacity. Since we should skew to smaller hull sizes being built, we would expect to get a good increase in the number of ships, possibly more than double. Unfortunately, that isn’t what happens. since we didn’t change the distribution of ships we’re drawing from, these small SCCs get underutilized. The total only goes up to about 2400.
I think a bit of this is a queueing problem so let’s just run a simulation with only those new SCCs, but using the same input distribution. I this case we get the system sustaining an additional 300 ships with an average hull size of 3. Still not exactly what I was expecting.
But that distribution doesn’t really make sense. And I think there is still some sort of bug in my code that isn’t doing the queuing properly. So let’s give these smaller SCCs their own queue and distribution. We’ll only pick ships from HS 1-5 for them to build and just make it a flat 20% chance of each hull size. Running that simulation give us that the smaller SCCs can support ~7000 additional ships with an average hull size 2.9. Dividing that between the 22 planets gives us an additional ~320 ships per planet.
That definitely points to something strange happening with the queue when using all the SCCs in a single run. It’s supposed to be dropping the larger ships that are getting passed over after a while but that doesn’t seem to be happening. Or at least not fast enough to fill the smaller SCCs. I’m definitely going to have to look into the queue system I’m using and this may impact the baseline numbers as well (increasing them).
But that means that adding in these small SCCs at each planet increases then number of ships that we can have flying around from 2300 to nearly 9300, an increase of 400%. They are mostly small ships but that may be what you need for all the transport to and from the surface of the planet and within a star system.
Reducing Maintenance
The previous 2 variations just looked at increasing SCC capacity. What if we look at simply reducing the amount of maintenance that a ship needs in a SCC. If ships have to spend less time in the SCC for repairs, then that space is available for new ship construction.
The KH rules say a ship needs to come in every year for 1d10+HS days of repair. And every year they don’t adds a 5% chance of failure of a critical system on a jump and when they do finally get in adds 1d10 days of repair per year missed.
Let’s reduce that. For this try, we’re going to say that they only have to come in once every five years, and that it is still only 1d10+HS days of work to get the maintenance done. Maybe routine maintenance by the crew is enough. Maybe there are dedicated “repair yards” that can handle the work the other years. Whatever the reason is, we are not tying up the limited SCC space with ships undergoing maintenance. We’re going to jump straight to five year so we can see if this is a large effect or not.
Going back to our baseline configuration with just the canonical SCCs and the original ship distribution, this new maintenance requirement results in a new ship count of 6500 ships with an average hull size of 7.0. That’s an increase of ~280%. So we’re getting more and slightly bigger ships. I knew going in that the maintenance was the true bottleneck. I didn’t get quite as many more ships as I was expecting but it’s a significant increase.
However, the simulations I’ve been running only simulate 100 standard years. That’s usually more than enough time to reach a steady state and longer than the history of the UPF at the time of the Second Sathar War. Interestingly, in this simulation, it never really reached that steady state, the numbers of ships were still going up at the end of the simulation. So for fun, I rand both the baseline and the low maintenance option again for a 200 year simulation.
In that case, we did reach a steady state of the number of ships in the low maintenance simulation of 8500 ships with an average HS of 7.1. The baseline sim only went up to 2850 ships with an average HS of 6.25. We got more ships but on average they are smaller. So the low maintenance option represents an increase of 300% over that new baseline. But it’s going to take the Frontier some time to get to that level.
Conclusions
As expected, increasing the number of SCCs increases the number of ships that can be supported. The simulations have given some number to those increases. What I wasn’t expecting was the impact the queuing system I was using would have on the outcome. Obviously a queue that generates ships of the appropriate size for a given SCC distribution can have an effect on the final numbers.
What we found was that just doubling the number of SCCs with the same capacity profile basically doubled the number of ships. That’s probably a good rule of thumb. But if we increase the capacity and limit the ships to smaller hull sizes, we get a huge increase in the number of ships. Limiting the ships to HS 5 or less and with only an 86% increase in production capacity, resulted in a 400% increase in the number of ships.
The other unsurprising bit was that reducing the amount of maintenance required resulted in more ships being supported, I was expecting a nearly linear increase but that wasn’t the case. At least partially because we ended up with more of the larger ships which reduces the total capacity. What was surprising was in the low maintenance model, 100 years of simulation wasn’t enough to reach a steady state on the number of ships.
The truth is, you can have as many ships flying around as you want. If you have more, you can add flavor to your game to describe the extra ship construction capacity any way you want. Then just take the rules as written as the resources available to the PCs. There is more capacity out there, they just can’t access it.
What’s Next?
There are still more things to explore on this topic. Probably the most obvious is looking more closely as the algorithm I’m using to queue up the ships. That apparently has a bigger impact that I was realizing. It was supposed to model the process described in the rules for getting a ship into an SCC but maybe it’s not doing that well enough.
The other aspect might just be the ship distribution I’m generating. Another area to explore is looking more closely at the number and types of ships that are out there flying around and building up a “realistic” distribution based on that. I have looked at that issue in the past and maybe will do a post about it. It produces a different distribution than the one I used here but I’m not sure I really captured everything.
Another thing to consider is the distribution of SCCs. I did some fairly arbitrary changes for this article just to look at gross effects. A more nuanced look at increased capacity might be interesting.
What ideas do you have? Are there specific things you’d like me to explore? 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.
I had originally planned to start in on the models from the Privateers boxed set after I finished the freighter from the Federation ships box, but a discussion on the starfrontiers.us site put agriculture ships in my brain and, since we had some silhouettes and a counter for these ships, I thought I might make a model of one of those first. Let’s look at these ships.
First of all, here are the images we have to work with:
The black and white drawing is from page 7 of the Knight Hawks Campaign book and the inset is the counter.
Both of these images show a long, spindly fuselage, a bit of a structure at the bow, behind the domes, and at the tail, and of course, the big agricultural domes themselves.
Now, you can debate as to whether or not these ships actually make sense or not. Especially as depicted here. And that’s part of what the discussion on the starfrontiers.us site was all about, but they are included in the game so I figured I’d take a crack at making a model. While I’ll stick with this basic idea, I’m going to make a few changes.
The Model
Here’s an image of the final Ag ship model. As you can see, it differs a bit from those silhouettes. Let’s talk about what I did.
First, I decided to make this model a hull size 10 ship, which for these types of ships, is a little on the small size. The rules say that Ag starships are typically hull size 8-16 while system ships have hull sizes in the range of 10 to 20.
As pictured in the silhouette images, the ships seem to have a single large chemical engine mounted at the tail. That sort of makes sense for a system system ship but just barely. If they are just floating out there collecting sunlight, then everything is growing in zero-gravity. On the other hand, if you want some sort of gravity in the ship, you need to be constantly accelerating (no artificial gravity in Star Frontiers). In the latter case, chemical drives don’t really make sense. So I decided to give the ship ion engines instead. For the model, I used the same engine design I created for the minelayer miniature. It the same size (a Class B engine), but I used two struts to attach them to the hull in this case.
The other difference with the engines is that I used three of them instead of just one. The ship construction rules call for three engines on a hull size 10 ship so that is what I went with. I guess a single Class C engine would do the trick but let’s stick to more standard designs for now.
Like the images, this model has a long, skinny fuselage. But it’s kind of hard to see as I added a bunch more to the ship. The bit at the end is modeled on the tail of the ship in the black and white image. You can’t see it in the model image above but the section right under the domes is also thicker like in the silhouettes. And I also used the same style bow.
I modeled the domes on the image from the black and white image rather than the counter and just put four of them on the ship. On a larger ship, I would probably keep them the same size and just add more of them as is represented on the counter.
The main difference between my ship and the images is that I added some large storage tanks below the domes, and piping to connect them. I figure this is where the extra nutrient solutions, air, and water are stored as they are cycled through the domes. I also figure this area contains the processing machinery.
Another thing I added was lights on the underside of the bow. If you click on the model image above, you can just see them. There is one pointing at each dome. These are powerful, full-spectrum lamps that can be turned on to provide illumination to the domes when the ship is not pointed directly at the sun. Or maybe they are used all the time. If you’re flying around the system, constantly keeping the ship at 1 g, there are going to be many times that you don’t have the domes pointed at the star. In any case, they are a small feature on the model.
This model was created at 1/3000th scale, or 3 meters on the ship equaling 1 mm on the model. This is the same scale I used for the sathar Destroyer and CDCSS Nightwind and roughly the scale of the UPF Frigate, Destroyer, & Minelayer. When I start making a new set of ships after finishing the privateers, the models will all be made at that scale. The fuselage of the ship is 240 meters (80 mm) as is standard for a HS 10 ship. It’s a lot skinnier than a typical HS 10 ship, 15-20m diameter compared to 40, but I figure the extra hull goes into the domes and the storage tanks. With the engines added, the model is 92.67mm long, giving the ship a total length of 278 meters. Across the widest point of the domes it is 56.66 mm or 170 meters.
Printing
With the model complete, it was time to print it. The image at the right shows the hull size 10 Agriculture ship (black) next to the Nightwind freighter (green) and sathar destroyer (red, painted). Unfortunately, the black resin prints don’t photograph very well.
For the most part, the print came out very well. But it needed a lot of supports under the domes. For this print, I printed it upright, just as pictured (and how I’ve printed all the other ships) and used the default supports that the printing software supplied. Unfortunately, that wasn’t quite enough support under the domes. Mainly, the supports could have been placed better and on the edges of the domes, not just the underside. The result was that the physical shape of the underside of the domes is a little warped, rounded were it should be flat and angled. I think in the future, I will print the model at an angle, tilted 30-45 degrees. It will require much less support material and the surfaces will come out better as the printer has issues with large horizontal surfaces that are not touching the build plate.
Up Next
Next up is working on the Privateer models. I haven’t done any modeling recently due to all the life changes resulting from the COVID-19 pandemic but will be getting back to it in the next week or so as life has finally settled down to somewhat of a routine.
I also plan to revisit this ship in the future and create a HS 20 version with more domes. That will probably have to be printed in parts as I don’t think a full scale HS 20 ship will fit on my printer, It’s a bit larger than my print volume, at least printed vertically.
Like all the other models, I’ll be adding this to my Miniatures Price Table if you want me to print you one, and putting the model up on DriveThruRPG on my 3D Models page if you just want to grab the model file and print it yourself.
What do you think of the Ag Ship. Have you ever used one of these in your game? Share your thoughts in the comment section below.
This was a busy month on the Frontier (and beyond). The HSS History’s Hope finally overcomes their misjump issues only to be ambushed by an unknown assailant. A strange computer virus nearly destroys the Moneyspider, and the ships of the Discovery Squadron, on their way home, engage and destroy a sathar raid in the Zebulon system.
As always, you can follow along daily on the Star Frontiers Twitter feed if you don’t want to wait for the monthly summary.
Date (FY)
Events
61.020
Castuss Wallorr (yazirian), the sape handler on the Moneyspider, is launched out of the ship on a lifeboat. His distress call causes the ship’s roboticist, Daqor Klarr (vrusk) to snap and have to be restrained. (SFAD5)
61.021
– Baralou Ap-Reaverchan (yazirian), Moneyspider’s astrogator, is killed in a sudden explosion in the life support system on Snobol, the asteroid the ship is tethered to. (SFAD5)
– On their return to the Moneyspider from Snobol, the elevator fails and the crew that responded to Baralou’s distress call are severely injured. (SFAD5)
– In the confusion of the elevator crash, Daqor, sedated in the Moneyspider’s medical bay, is killed by an overdose of anesthesia. (SFAD5)
61.022
Calculations mostly done, the HSS
History’s Hope begins accelerating for its jump back to the YS01 system.
61.023
– The Moneyspider’s security robot malfunctions and starts shooting holes in the gas tanks holding the filtered toxins from the planet’s atmosphere. The life support system is also malfunctioning and not filtering the air. Fiator Geauis (dralasite), ship technician is killed due to a sabotaged gas mask. (SFAD5)
– Ellen Coopermann, as the only survivor of the original crew is the prime suspect, but she convinces the rescue party she is innocent. She begins to believe the rescue teams account of the Matrix and works to help them eradicate it. (SFAD5)
61.024
After many weeks of behind the scenes deals and increasing discontent over the practices of the Groth Energy Corporation, the creation of a new entity is announced, the Consolidated Nebula Energy Group (CNE) (ZG), formed by the merger of the three largest independent energy producers on Groth. All smaller energy producers are invited to join.
61.025
– Despite their best efforts, the techniques that worked on Jetsom aren’t working to destroy the Matrix on Moneyspider. (SFAD5)
– Looking through the Captain’s Computer/Robot System’s Manual Ellen learns that Baralou, the astrogator is listed as one of the ship’s robots, which means it was not her body recovered in the explosion on Snobol. Baralou becomes the prime suspect of all the deaths. (SFAD5)
61.026
– The Sathar starship construction center in OFS111 completes a light cruiser.
– Her secret discovered, Baralou attempts to eliminate Ellen and the rescue team. After a running fight through the ship between the surviving crew members and Baralou, who is aided by the ship’s robots and automated defense systems, Baralou is neutralized. (SFAD5)
61.027
– The Discovery Squadron arrives at Faire in the Capella system. They spend three days on the planet before heading on to Zebulon.
– The HSS History’s Hope successfully jumps into the YS01 and begins decelerating. Jump calculations are begun anew for another attempt at the jump to the YS02 system.
– With Baralou gone, the remaining crew on the Moneyspider slowly begin to make progress on destroying the Matrix from the Moneyspider’s systems. (SFAD5)
61.028
An attempt is made to
sabotage the Minotaur (Theseus) shipyards. It is foiled due to increased
security after PGC shipyard attack a few months ago.
61.029
– Deceleration nearly complete, the HSS History’s Hope is set upon by an unidentified, armed vessel that does not respond to any attempts to communicate. While obviously of Frontier origin, the vessel is not one that the crew has seen before. An SOS is broadcast via subspace radio to the Frontier.
– In the ensuing fight, the HSS History’s Hope’s engines are severely damaged but a lucky shot by their gunner sends the assailant spinning out of control, ending the fight. The crew rushes to fix the engines and get underway before the assaulting ship can repair itself and return.
61.030
– Having remained undetected as they drifted through the outer system, the sathar ships in the outer Kazak system begin slowly changing their vector for a jump to Zebulon.
– Just hours before the relief ship arrives at the Moneyspider, the crew eradicates the last vestiges of the Matrix from the ship. The remaining crew board the relief ship to head back to the Prenglar system. (SFAD5)
61.031
With the “fall” season approaching CDC
decides that winters are too harsh to keep the crew on Alcazzar (Rhianna) and
stop operations for the year after mining over 6.3 million credits of
resources, mostly gold. (SF4)
61.032
Repairs of the HSS History Hope’s
engines take much longer than expected. Luckily, their assailant failed to
return. The crew debates whether they should return to the Frontier for
complete repairs or push onward.
61.033
After much deliberation, it is decided that the HSS
History’s Hope will push on but not transmit their completed routes back to
the UPF for registration, but only to Histran to track their progress. Calculations are begun again for a jump to
YS02.
61.034
Repairs at the PGC shipyard (Gran
Quivera, Prenglar) restore capacity to 80%.
61.035
– Repair work on the Triad SSC continues. The construction center is now at 85% of its original capacity.
– The Discovery Squadron makes the jump to the Zebulon system and starts decelerating toward Volturnus.
61.036
– The sathar ships from OSF019 make the jump and arrive in the Zebulon system. They start decelerating toward Volturnus.
– Initial calculations complete, the HSS History’s Hope begins accelerating once again for a jump to the YS02 system.
61.037
– Sathar ships are detected by Discovery Squadron and messages are sent to Spacefleet, Pale (Truane’s Star), and Strike Force Nova announcing the sathar presence in the system.
– As the only armed vessels in the system, Discovery Squadron is ordered to intercept the sathar vessels despite being severely out classed.
61.038
The decision by Obar Enterprises to not
report the Truane’s Star-Cassidine jump route has paid off nicely. In just 100 days, they have made over 1.6
million credits in gross profits, more than double what would have been
possible before the jump route was plotted.
61.039
– Discovery Squadron intercepts the sathar ships. Whether due to a sizable skill differential or simply good luck, the smaller UPF ships manage to destroy all 4 sathar vessels. Unfortunately, the militia frigate and one of the Streel corvettes are lost while the other 2 corvettes are severely damaged.
– Realizing that they have too much force projected into the Rim, and that the sathar seem to have a way into the Frontier around the ships station in Kazak, Strike Force Nova begins a high-speed transit back to Frontier Space. Patrol Group Virgo is split off again and remains in Kazak to bolster the Rim defenses in that system.
61.040
– After making critical repairs, the remains of the Discovery Squadron begin making their way to Volturnus.
– The HSS History’s Hope successfully arrives in YS02, much to the relief of her crew. They begin decelerating and plotting the return jump to YS01.
61.041
The sixth saurian Ark Ship is completed and begins
its shakedown cruise.
61.042
Information is uncovered that the
buyout of Groth Energy may have been orchestrated by the group known as the
Investors. The reporter that uncovered the leak is found dead after falling
off of his 16th story balcony in downtown Port Loren (Gran Quivera,
Prenglar).
61.043
The Discovery Squadron pulls into orbit around
Volturnus where they start working on more repairs and resupplying the
assault scouts which had depleted all their assault rockets in the fight with
the sathar.
61.044
Strike Force Nova jumps into the Osak
system but remains near jump speed as they compute the next leg of their jump
to Capella
61.045
Deceleration complete, the HSS History’s Hope begin
accelerating for the jump back to YS01.
They are aiming to arrive high in the system to attempt to avoid the
assailant that was there last time if that ship is still in the system.
61.046
– Repairs complete, the Streel corvettes begin accelerating for a jump home to Truane’s Star. The assault scouts are ordered to stay in the Volturnus system for the time being to provide early warning and defense of that system as Spacefleet finalizes it’s plans. Discovery Squadron is officially dissolved.
– Strike Force Nova jump into the Capella system, again remaining near jump speed as they compute a jump to the Zebulon system.
61.047
Fortress Kdikit (Madderly’s Star) completed.
61.048
After much debate, and heavily swayed
by discovery of the sathar presence in OFS019 and the recent events in the
Zebulon system, the Council of Worlds authorizes additional spending by
Spacefleet to commission several new vessels.
61.049
With the go-ahead and funding from the Council of
Worlds, Spacefleet decides to exercise their development plan Sierra Foxtrot
Meteor, which builds out another Strike Force similar to SF Nova. Orders are placed for vessels from various
shipyards around the Frontier.
61.050
The HSS History’s Hope successfully
makes the jump back to YS01 arriving high in the system as desired. They
immediately begin decelerating and scanning the system for any other ships as
they start in on engine overhauls and plotting the jump back to YS02.
This has been a crazy month. With the world mostly locked down, it’s been interesting to see how things have changed and evolved. For me, work hasn’t changed much as I already worked from home full time. The main difference is that now I have even less free time since in addition to full time work, I have to manage the schooling for my four youngest children. But because of that, I haven’t gotten as much done as I had hoped.
Looking Back
As usual I started off the month with the Detailed Frontier Timeline post followed by a post on a new miniature and model, this time the freighter from the Federation Ships boxed set. Next came a post on the Blue Plague, inspired by the events unfolding around us right now. Finally, last week I finally put together the map of the Yazira Sector, the region of space beyond the Frontier where the HSS History’s Hope is exploring in an attempt to rediscover the Yazirian homeworld. I had originally thought to do a different, but related post in that slot. More on that later. And this post is the final Tuesday post this month.
You might have noticed that there wasn’t an RPG Blog Carnival post this month. The topic was Alchemy and I just wasn’t having any inspiration on that topic for a sci-fi setting.
A lot of my free time this month was spent on the Frontier Explorer. For the first time since we rebooted the zine, I’m actually ahead of the game. As of right now I’m waiting on one final article and a few pieces of art to finish of the issue. I was able to get all the submitted articles edited and into a preliminary layout. I expect that this issue will be out much earlier in the month than the last few issues, which squeaked in just before the end of the month.
Beyond that, not much has been going on. I didn’t get anything done on the website migrations and upgrades and don’t think I got any writing done on my book. The COVID-19 adjustments have just eaten up all my spare time.
Looking Forward
The timeline post is queued up and ready to go out next week. After that will be a post on the agriculture ship model I created. My plan is to do a post on the True Yazira secret society. I had planned to do that instead of the Yazira sector map post this month but two things resulted in putting that off. One was simply that I didn’t have time to do it justice. The other was that I wanted the HSS History’s Hope expedition detailed out since they are related. More on that later this month. The final post will hopefully be related to the Blog Carnival. April’s topic is “Corners of the Multiverse” so I should be able to come up with something.
The other big thing happening this month will be the Frontier Explorer. As I already mentioned, issue 28 is almost completely done. So watch for an announcement on that. Here’s a teaser of the cover.
With my house settling into a routine, I’m starting to have a bit more free time. Hopefully that means more of my behind the scenes projects will get some love including getting more web site work and book writing done. I also suspect that this month I’ll be starting in on my writing for the Space Kids RPG that successfully funded and which I mentioned last month. I also hope to start painting some of these miniatures that I’ve been creating.
I’ll also be working on new models as the ag ship is the last one I’ve finished. This month I’ll start working on the ships from the Privateers boxed set. Hopefully I’ll find my missing three miniatures but I have three to start with.
What have you been working on this last month? Are there things you’d like to see me post about? Let me know 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 was not the post I had planned for this week but with all the precautions and closures due to the COVID-19 coronavirus the last few weeks, it got me thinking about medical technology and then about the differences between Frontier technology and our modern tech.
A Look at the Frontier
One thing that always stood out to me, even as a preteen/teenager
in the early 80’s was that the relative levels of technology in the Frontier
was very different from our own, and that was ignoring things like spaceflight,
laser guns, and FTL travel.
Take computers for instance, even in the early- to mid- 80’s,
the computer technology here on Earth was beyond that of the Frontier, or at
least on par with it. And looking at the
game with modern eyes, we are way beyond the Frontier tech.
Zeb’s Guide did a little to advance the computer technology
and shrink it down, with the introduction of the bodycomp. This helped to bring the tech somewhat in
line with what was available in the mid-80s.
But a visitor from the Frontier to Earth today would be amazed with our
modern computer technology.
However, if you look at Frontier medical technology, it is
light years ahead of even our modern medicine.
With just a handful of relatively inexpensive drugs, you can cure most
diseases, neutralize toxins, heal injuries, and even postpone death. Not to mention the freeze field and storage class
transport fields that can put you into indefinite suspended animation (as long
as the power doesn’t go out). These wonder
drugs would be a dream come true for medical professionals on Earth today.
I don’t know if it was a question really, more like an unsatisfied
curiosity, but I have always wondered and thought about why the Frontier went
down that technology path rather than the one we did. Why is the medical technology vastly beyond the
physical technology?
Game Play
At a practical level, it is what it is so that the game can
be exciting and playable. You need
advanced medical technology (just like you need healing spells in a fantasy
game) so that the PCs can get right back into the adventure after getting
hurt. And you don’t want the tech to be
so amazing that it overshadows the abilities of the characters.
In fact, it was either Larry Schick or Dave Cook, the
original creators of Star Frontiers, who, in an interview said that they set
the tech level where it was so that it was the PCs that had to do the tasks and
not be able to just call on the technology to solve all their problems. That was why they made the computers big and
clunky, with no real networking, and many of the other design choices that they
made.
That said, it is still a fun exercise to think about what
events we could work into the history of the Frontier to account for such a
balance of tech levels.
A Sweeping Pandemic
Which brings me back to COVID-19 and the events happening in
the world today.
In Zeb’s Guide, it talks about the Blue Plague and five worlds that were lost to this plague. While I either like or don’t mind many of the setting elements introduced in Zeb’s Guide, this is one that has never really sat well with me. So much so that I left those worlds off of my Extended Frontier Map completely. What where the original names of those systems? They wouldn’t have been called Alpha through Epsilon originally. Why weren’t they on the Frontier map from the original rules? They would have been in setting at the time in the history that the original game occupies. I understand the desire to expand the setting, but the way the Zeb’s Guide timeline was built made many of the things it presented inconsistent with the original game setting and modules.
I don’t like the placement that Zeb’s Guide gives to the
Blue Plague, occurring from 17-27 FY – after the original sathar invasion that
prompted the formation of the UPF. It
feels too late and tacked on. And I don’t
like that it wipes out five star systems that should have been part of the
Frontier history but were never mentioned in the original game.
But what if something like the Blue Plague happened, just
much, much earlier in the history of the region? Back when all the technology was young and
prompted a focus on the biological and medical sciences over the physical ones? That could have prompted the technology
development we see in the game.
Now you might argue that you need the physical and computer
tech advances to produce the medical ones, we definitely see technology aiding
medicine today. But we don’t know that it’s absolutely necessary. We only have one sample timeline. It didn’t work out that way for us, but that’s
not to say they path we took is the only one.
It’s time for a little willing suspension of disbelief.
The Blue Plague Revisited
So let’s dial the clock way back, to the early settlement of
the Frontier. In the Knight Hawks rules,
it states that the discovery of the FTL travel was an accident. It was completely unexpected. In my game it was the humans who stumbled upon
Void Jumping and shared it around. In
the process of exploring it, they discovered a signal from the Vrusk and went
to investigate. But because of its
accidental discovery, I have the human tech level originally set somewhere
around that of the late 60’s, early 70’s somewhat consistent with the computer
tech of the game. They just happened to
have developed better propulsion systems to get the necessary speeds.
Instead of hunkering down, they exploded throughout the region. There is a reason there are many more human worlds than those of the other races, and even then, you find humans almost everywhere. They had the ability to travel to the stars and they did, aggressively. The other races expanded outward as well, but not nearly as much. As I detailed my Yazirian Lore posts last month (part 1, part 2), the yazirians were expanding outward out of a sense of preservation. The vrusk and dralasites didn’t expand out nearly as much.
And then, shortly after all of these worlds were being
settled, the Blue Plague struck. In Zeb’s
Guide, it describes the plague as receiving its name due to its early symptoms:
large blue welts that appear about the face and extremities that leave horrible
black scars even if you survive the plague.
No one knows exactly where it came from. The first cases were on Prenglar, the hub of
the Frontier where travelers from all over mingle and visit. As more and more cases were discovered on
Gran Quivera, it began to be studied more, restrictions and quarantines were put
in place, and efforts were made to get it under control.
But by then it was too late.
The disease, having a very long incubation period, had already spread throughout
the Frontier and cases began popping up on every world. Due to the horrific nature of the plague as
well as the relatively high mortality rate, quarantines and restrictions became
very strict. Of course, this impacts
production, research, and distribution, especially of food. Because of the long incubation period,
coupled with the long duration of the illness itself, these quarantines ended
up lasting for a very long time. As many
people probably died of knock-on effects of these restrictions as died from the
Blue Plague itself.
One impact of the long duration of the plague was the development
of robot technology. Since the citizens
were afraid to come in contact with one another, something had to be done to
produce the goods and food needed to sustain the populations of the various
worlds. Thus, robot technology got a
huge boost. The early models were crude,
probably remotely operated, and not very sophisticated, but the plague launched
the nascent robotics industry that would continue to develop over the
intervening years.
More importantly, the Blue Plague resulted in a huge boost
in funding into medical research. This funding
came from everywhere. Governments heavily
supported it at the behest of their citizens.
Companies supported both to try to keep their workers and as a public relations
measure. And private citizens supported
it for a wide variety of reasons ranging from altruism to a desperate desire
for self-preservation.
Regardless of the reason, funding into the biological and
medical science boomed and universities and research institutions flourished. It took several years, but a cure was finally
found. Along the way, other interesting
avenues of research were uncovered but left unexplored in the rush to find the
cure. Eventually, all this research
payed off and the Blue Plague was eradicated.
Aftermath
After the Blue Plague was under control, the citizens of the
Frontier took stock of the situation and the results were horrifying. Millions dead across every world of the Frontier. Millions more permanently disfigured for
life. No one issued a proclamation, no
one passed any laws, but collectively as a Frontier-wide community, the people
resolved to never let this happen again.
The funding in the medical sciences, while never again as high a
proportion of the total wealth of the Frontier as during the Blue Plague itself,
remained very high.
Because of this high state of funding, all those interesting
side avenues that had been discovered during the Blue Plague research were able
to be pursued and developed. Over time,
this led to the development of the wonder drugs known in the modern Frontier as
Biocort, Simdose, Staydose, Omnimycin, Antibody Plus, and AntiTox. Six drugs that together can treat almost
anything the universe might throw at you.
Having seen the benefits of using robots for many of the
menial jobs required during the Blue Plague era, robotics continued to develop
a heightened state, although nowhere near the level of the medical
sciences. Effort was put into developing
robotic systems that could be autonomous and operate independently of direct
supervision but rather controlled by programming or robot management
software. This heightened development has
led to the relatively inexpensive and highly capable robots found in the Frontier
today.
Of course, the cost of this increased medical and robotics development
was a slowing of the development of the other technologies. Computers, vehicles, starships, and even
weapons systems fell behind the curve.
Advances were made, but not nearly at the pace of the robotics and
medical technologies. Thus we get the
technology levels presented in the game rules.
Using This in Your Game
If you chose to use this history in your version of the
Frontier, what impacts might it have in your game?
One aspect is survivors of the Blue Plague. Depending on how long you made the extended
history of the Frontier, and where you place the Blue Plague in that history,
there might still be survivors bearing all the scars of their ordeal. Personally, I don’t like the 400+ years of
the Zeb’s Guide Timeline and prefer to compress it much more than that. Making it
200 years at most. That allows me to
have the technology not as developed.
But that means, given the 175 – 250 year average lifespans for the
various Frontier species, there will be survivors of the Blue Plague still
around. They will be older, but could still
be active members of society. How do
they see the world? Do they have agendas
they push for? What stories do they have
to tell and how has their experiences shaped the way they look at the world?
The modern wonder drugs can solve almost any issue. What does that mean for all the companies
that have invested in the research side of things? Is research slowing down? Is the funding shifting? How does that impact the economy and the
people working in those industries?
Maybe there is funding slowly shifting to other areas? Are computers becoming smaller and more powerful,
starting to move along the path of our Earth technology? Is the money going other places? Or maybe there are occurrences of other
diseases like the Blue Plague that break out but never to the same extent that
require constant retooling of the medicines keeping the biotech industry alive
and well.
Is the Blue Plague really eradicated or do new cases pop up
occasionally around the Frontier? How do
people react when it happens? Are the causes
natural or contrived?
How did the enforced isolation required during the Blue Plague
era affect communities? Would the isolation
become standard? Would it cause an
increased awareness of the need for community?
Would it spark an increased care and understanding of the needs and
interests of one’s neighbors? Maybe it
did all of those on different worlds or in different communities. When you create a community for the PCs to interact
with, you might sprinkle in an unusual custom that dates from the time of the Blue
Plague.
What other ideas does this alternate timeline bring to mind? How else might you apply it in your game? Share your thoughts in the comments below.
The model and miniature this month is a recreation of the small freighter model that was part of the Federation Ships boxed set. This is the last model I needed to recreate to complete that original set. With this one done, they are now all available.
The image to the right is the original miniature from the boxed set. I hadn’t tackled this particular miniature in the past mainly because I was initially focused on the military vessels. But I was also a little worried about recreating the shape of those struts and all the detail at the tail of the ship. But with lots of experience behind me, it was time to reproduce this miniature.
The Model
Let’s start with the final model and then I’ll talk a bit about what it took to create.
I started with the main body/oval shape at the bow of the ship. My version is a little more rounded than the original as I just used a stretched sphere for this part. To get the exact shape would have taken creating a custom curve and then doing a rotate_extrude() to make the 3D shape (and then squashing it to make it flattened). I’m happy with how this turned out although I originally expressed some desire to revisit that bit of the model.
The tail of the ship is just a long column that the cargo pods and bits at the end are attached to. That was added next.
Then came the cargo pods. These are a recreation of the original miniature (although the rings around the top and bottom are probably a bit thinner than the original). Interestingly this was the part of the ship that generated the most commentary on the Facebook group when I posted this picture. Everyone wanted me to get rid of the double container and make one big one. Which is something I’ll probably do in the future but for now I’m keeping to the original model.
Next up was the engines. Since these are different than the engines on most of the other ships, but similar to those on the minelayer, I’m assuming that these are ion engines as well. The engines themselves were easy enough, just some cylinders will a sphere at the top. The hard part was getting the curve of the struts right.
That shape is not one that OpenSCAD can do natively. At first I looked at doing some linear_extrude()’s of a few stretched circles. But that wouldn’t give me the curvature that the strut has. So I went looking for an OpenSCAD module that would allow me to extrude along a curve and vary the scale along the extrusion.
The first one I found was the “Extrude Along Path” module by gringer. However, it didn’t allow me to do the scaling the way I wanted or at least easily. So I went looking for another option. What I found was the “path_extrude with scaling” library by tpchuckles. This module built on gringer’s Extrude Along Path module and added in the scaling in a way that was easy to use.
Now that I hd the tool, I just need the path to extrude along and how much to scale at each point. To figure this out, I took another picture of the mini, this time with a ruler for scale (seen at right). This is actually a different mini that had a primer coat on it. Next, I imported the picture into Inkscape. I then scaled it so that there were 10 pixels to a millimeter. This would allow me 1/10th of a millimeter resolution when I was making measurements. Next I drew a curve onto the image down the middle of each strut and then averaged the two curves. This would be the path that the extrusion was to follow.
The next step was to get the scaling at a number of points along that curve. The question was, how many points would I need. As you can see, the entire strut is only a little more than half an inch (about 17mm) in length. I could go really finely detailed but that would be overkill. But if I didn’t have enough, it wouldn’t look smooth enough. I ended up just looking at it and finding points where either the path made a significant change or the width of the strut had a change in curvature (the derivatives changed for those who remember their calculus). In the end, I picked 12 points along the path.
Once I had the points I then drew a line perpendicular to the path that touched the two edges of the strut. With all that done, I read off the coordinates of each point and length of each perpendicular line segment. That gave me the points for the curve and the scaling in one dimension. The scaling in the other dimension came from just making a few measurements with the calipers at a few points along it’s length since the strut is mostly the same thickness with a big of flaring as it approached the main body of the ship.
With all that done, I plugged all the numbers into a few arrays, called the path_extrude() function from the module and out came the strut. I had to do a few small tweaks but it worked quite well and generated the shape you see in the image above.
The final bit was all that stuff at the back of the fuselage. As you can see from the two images of the original miniatures, it was kind of hard to see. But working carefully between the two miniatures, and looking at both sides of each, I was able to tease out a structure. I have the advantage that I don’t have to get molten metal to flow through a mold in making these models so I can go with slightly finer and more defined features in my models than appear on the original miniatures. I had already noticed this on the bigger UPF ships, especially the cannons on the battleship and light cruiser. I took advantage of it here as well.
Printing
With the model complete, it was time to print. Nothing really exciting here, it was a fairly straightforward print. I printed it nose up like I did all the other ships and, standing 41 mm (1.6″) tall, it took about 4.5 hours to print. Given that there isn’t a lot of detail on this one, it might be possible to get a good print with it lying flat which would reduce the print time to about 1.5 hours but require a bit more support on the “down” side of the ship.
Here’s the final printed miniature next to the original (unprimed) mini.
A few things stood out to me comparing the two, some of which I’ve already mentioned. One is the shape of the bow. The other is the rings around the cargo pods. They probably need to be a bit bigger on the model as they didn’t stand out as much as I was expecting.
The other major difference is the details at the back of the fuselage. I think in the end I made them a little bit smaller than on the original. That said, there is more detail in the printed one than in the original.
I also noticed that the engines have a bit of a wobble to them but that can be cured in future prints with a little more support structure to hold things steady.
Up Next
At some point I’ll revisit this model and tweak the cargo pods. Both to make the ring around the top and bottom more defined, and also to make one or two more different shaped pods and produce miniatures with the different cargo containers. The great thing about working in OpenSCAD is that the cargo containers are just a function. Write a new function for the new shape, call that one instead, and viola, you’re done with a new miniature. But for now, I’m happy with the way this one turned out.
Next month’s model will be an agriculture ship. This will be a new creation as there is no existing mini for this type of ship. There was some discussion about it recently on the various Star Frontiers social media hubs and that inspired me to make that model before tackling the privateer minis.
You’ll be able to order this mini from the Order Miniatures page here on the site if you want a printed miniature, or grab the model from my 3D Models page on DriveThruRPG if you have your own printer.
Let me know your thoughts, comments, or suggestions in the comment section below.
This month see a new year in the Frontier, an escalation of the tension with a small battle between UPF and sathar forces, and the start of construction on a new UPF exploration ship. The HSS History’s Hope also runs in to some trouble with a few bad misjumps, ending up in systems they never intended.
Date (FY)
Event
60.391
Construction of the CMS Swallow begins
60.392
The CRL-E1 maintenance robot on Jetsom stops
functioning and refuse to move or obey any commands. Resetting its mission and functions
restores functionality but only for a few hours. The rescue team realize that
it has become infected by the Matrix. (SFAD5)
60.393
– After reviewing the data from Patrol Group Flint, and in light of the information returned by the Discovery Squadron, the commander of Strike Force Nova decides to send another scouting mission to OFS019 before making more definite plans.
– Patrol Group Flint is again detached from the Strike Force and begins accelerating for a jump back to the OFS019 system. If possible, they are to remain undetected in the system and transmit data back via subspace radio.
60.394
Second K’aken-Kar militia assault scout arrives in
its home system.
60.395
Repair work and astrogation
calculations complete, the HSS History’s Hope begins accelerating toward
their next system, designated YS002.
60.396
Shakedown cruise complete, the fifth Saurian Ark
Ship begins loading of cargo and passengers.
60.397
After over two weeks of dealing with
issues caused by the Matrix, the rescue team finally discover its fatal
weakness and start taking measures to destroy the virus and eradicate it from
the Jetsom platform. (SFAD5)
60.398
Patrol Group Flint arrives in OFS019 once again.
They stay near jump speed with engines off to reduce the chance of detection
and coast across the system at high velocity. They begin cataloging signals
from ships in the system.
60.399
The HSS History’s Hope initiates the
Void Jump to YS02. Unfortunately, due to an error in their calculations, they
end up in an unknown binary star system.
Designating this as YS03, they start deceleration and trying to figure
out where they ended up.
60.400
– Preparations, which have been going on for weeks, are finalized on worlds around the Frontier for a major Founding Day celebration celebrating six full decades of the United Planetary Federation. While some events over the past year have been troubling, everyone is determined to make this a celebration to be long remembered.
– After two days of data collection, Patrol Group Flint catalogs an ever growing sathar presence in the system. They have identified over 25 military vessels including four of the new, unknown ship type, as well as a station and various ancillary ships. The data is relayed back to Strike Force Nova.
61.001
– Major Founding Day celebrations held throughout the Frontier. Although there were some small incidents, the general mood on every world was very upbeat.
– Having crossed the system so that their engine emissions should be less noticeable, Patrol Group Flint begins decelerating. They have solidified the ship count to 8 fighters, 4 of the unknown ships, and 15 capital ships, plus a single space station.
61.002
WarTech
factories on Hargut (Gruna Garu) attacked by unknown forces. Expecting a
lower alert level due to the Founding Day celebrations, the attackers
underestimate the automated defenses and alertness of the security staff and
are repulsed with heavy losses.
61.003
Sathar forces in OFS019 detect the
decelerating ships of PG Flint. A
light cruiser, two destroyers and a frigate are dispatched under radio
blackout to intercept. They boost hard
for several hours and then kill their engines, minimizing emissions as they
approach.
61.004
Streel files a protest with the Council of Worlds
requesting that its ships that were part of Discovery Squadron be released by
Strike Force Nova to return to the Frontier as they are private vessels and
not part of Spacefleet or a planetary militia.
61.005
After six days of work, the History’s
Hope astrogation team finally determines their location. They shot way beyond their mark arriving in
a system that is 6 light years beyond YS02. The good news is that they know where
they were, the bad news is that it is well off the path they had planned to
take, and they now have two uncharted jumps back to YS01.
61.006
– Deceleration complete, Patrol Group Flint continue to monitor the OFS019 system and begins plotting a return jump to Kazak from their current location.
– The Sathar starship construction center in the Liberty system completes a destroyer.
– With only eight days until the orbital window opens for them to return to the Moneyspider, the recovery team on Jetsom has nearly eradicated the Matrix from the mining platform. The only holdouts are areas where damage prevents them from pressurizing the area and increasing the temperature.
61.007
After three days
of deliberations within Spacefleet, the Council of Worlds, and slow
communication with Strike Force Nova’s commander, all of the ships of
Discovery Squadron are dedeputized and allowed to depart Kazak and return
home.The six ships of
Discovery Squadron from Truane’s Star depart immediately upon their
release. The two Humma ships stay with
the Flight forces in the system.
61.008
Patrol Group Flint detect the approaching sathar
ships as they begin decelerating and angling for intercept. With evasion unlikely, the UPF ships send
off a subspace radio and begin a hard acceleration to try to escape, while
expecting to fight a very uneven battle.
61.009
The sathar ships catch Patrol Group
Flint. After a short running battle,
the two UPF destroyers are destroyed by the sathar forces which suffer severe
damage to the frigate and one destroyer, but all ships survive the battle.
61.010
– Loading complete, the fifth saurian Ark ships departs the Sauria system for destinations unknown.
– With the destruction of PG Flint, the sathar launch a raid into the Frontier sector to try to draw off the Frontier forces from wherever they are basing from. Two light cruisers, three destroyers, and a frigate leave for Zebulon via a high-speed transit of the Kazak system.
61.011
The HSS History’s Hope’s attempt to
jump to the YS02 system from YS03 fails and they land once again in an
unknown binary system of two M dwarf stars. As they decelerate, they begin
trying to work out their position. It
seems travel here in the Vast Expanse is more difficult than expected.
61.012
Construction is completed on the CDCSS Mystic at
the Triad (Cassidine) shipyards. While it has the same profile as the CDCSS
Nightwind, this ship is focused on passenger transport rather than
cargo. It begins a shakedown cruise
carrying CDC personnel from Triad to Rupert’s Hole and back.
61.013
The Council of Worlds convenes for the
FY61 session.
61.014
– The CMS Osprey docks with a strange looking freighter for what its commanding officer, Lt. Tabbe, says is a “high security” mission. When the airlock opens sathar swarm into the assault scout. After an intense battle, the Osprey’s boarding party neutralize the sathar and their agent Lt. Tabbe. The freighter gets away, but the Osprey is saved.
– The sathar ships from OFS019 arrive in Kazak well outside the inner system. They remain near jump speed search the system for signals of Flight or Spacefleet presence in the system.
61.015
Detecting Strike Force Nova and the
Flight forces in the system, the sathar ships begin cataloging the ships
detected. They remain near jump speed and coast through the outer system.
61.016
After five days of around-the-clock work, the
astrogators on the HSS History’s Hope have determined their location and also
uncovered an error in their astrographic catalog that may have been the
source of their error. The system is designated YS04.
61.017
– After a day of rest, the HSS History’s Hope’s astrogators begin charting a route to YS01, the closest system with known jump routes. It is a 10 light year jump, the farthest new jump they have charted. OFS219 is closer, at 8 ly, but would require several new jumps to get back to charted space lanes.
– Discovery Squadron arrives in the Osak system where they spend a day resting before heading on to Capella
61.018
The rescue crew from Jetsom returns to the
Moneyspider to the relief of Captain Akizk.
As the rescue crew is en route to the Captain’s office, the Captain
dies, seemingly by suicide. The second in command (Ellen Coopermann, human)
doesn’t believe their report about the Matrix. (SFAD5)
61.019
The Frontier Expeditionary Force begins
organizing a project to explore beyond the Theseus system. A new ship, the UPFS Elanor Moraes is
commissioned for construction at the Minotaur (Theseus) shipyards.
