Void Jumping, Acceleration, and Other FTL Nuggets

This post is going to get a little bit math heavy toward the middle. Just warning you now.

The idea for this post stemmed from a recent discussion on the Star Frontiers: Alive and Well Facebook group talking about the accelerations involved in faster than light (FTL) travel in that game. I’ve written about this many times over the years on forum posts but since I can’t seem to find those posts (I think some of them at least are on the now defunct forums at starfrontiers.org), I’m going to do it one more time here on this blog as a permanent reference. But before I dig into the details of the math and physics, I’m going to share some links to other posts I’ve made that I do still have.

Void Jumping

The concept of the Void Jump was introduced with the Knight Hawks supplement in Star Frontiers. In the original rules (renamed to Alpha Dawn when the Knight Hawks rules came out), there were no spaceship rules and it just said to treat interstellar travel at the rate of 1 light year per day.

So how does it work? According to the rules, you make a jump by leaving your starting point and accelerating until you reach 1% the speed of light. At that point you “jump” into the Void. To get out of the Void, you just have to slow down slightly. While you’re in the Void, you travel amazingly fast, on the order of 1 light year per second (The rules don’t actually so but imply something close to that so that’s the value I use). Once you jump into your destination system, you swing the ship around and start decelerating. Remember, there is no artificial gravity in Star Frontiers so this acceleration and deceleration is what provides gravity in the ships. Most ships make these trips accelerating at 1g.

So how long does this take? For these calculations, we’ll take 1 g to be equal to 10 meters per second squared (m/s/s) of acceleration. On Earth we define 1 g to be 9.82 m/s/s but rounding up to 10 just makes everything easier and its less than a 2% difference.

Okay, here comes the math.

If you start at rest, your velocity at any given time is just:

v(t) = at

where v is velocity (in m/s), a is acceleration (in m/s/s), and t is time (in seconds). Technically v and a are vectors but we’ll just worry about speed, not direction.

Now, the void jump occurs at 1% the speed of light. We’ll take the speed of light to be 300,000,000 m/s. It’s really 299,792,458 m/s but we’ll again round up to make the math easier. The difference is less than 0.07%. Good enough for this discussion. 1% of that is just 3,000,000 m/s. That’s our target velocity.

Since our acceleration is 10 m/s/s, dividing 3,000,000 m/s by 10 m/s/s gives us 300,000 s of acceleration needed to reach jump speed. That works out to 83 hours and 20 minutes of acceleration. Given that a standard day in Star Frontiers is 20 hours long, that is 4.17 days.

That’s the time to get up to jump speed. It takes that much time to slow down on the other side as well. Which means at a minimum, an interstellar jump takes 8 and 1/3 days, assuming everything lines up perfectly (see the Exiting the Void Jump article for things that might lengthen that).

That’s the time required. What about distances covered? The equation for position is just the integral of the velocity equation above. Again, for starting at rest, and assuming that you measure the distance from your starting point, your position at any given time is given by:

x(t) = \frac{1}{2}at^2

where x is your position in meters. We know what t is from the velocity equation above is 300,000 s. a is just 10 m/s/s. Plugging these in gives us a distance traveled of 450 billion meters or 450 million kilometers. (A lot of people forget that factor of a half and end up with the wrong number.) Now the distance from the Earth to the Sun, called an Astronomical Unit (AU), is 150 million kilometers (again I’m rounding, the actual value is 149,597,871 km so the rounding is less than 0.3%).

So in those 4.17 days of acceleration, you traveled 3 AU. If you started at Earth and headed straight out from the sun, you’d be 4 AU from the Sun. That’s most of the way from Earth’s orbit to Jupiter’s orbit (at a distance of 5.2 AU from the Sun). That distance puts you well beyond the main asteroid belt which ends at 3.3 AU.

Now, these numbers all change if you use a different acceleration. Doing those calculations is left as an exercise for the reader.

ADF and the Board Game Rules

The above all works just fine. The problem comes when you start looking at the rules for the spaceship combat board game and try to rationalize those rules with the math above.

From the board game, we have that one hex is 10,000 km and one turn in the game is 10 minutes of time. Added to that is the ship’s statistic, the Acceleration/Deceleration Factor (ADF) which is described as the number of hexes that a ship can speed up or slow down in a given turn. The fastest ships (fighters and assault scouts) have and ADF of 5.

Let’s look at some numbers. First, what is Void jump speed on the game map. Well, jump speed is 3,000,000 m/s or 3,000 km/s. Since a turn is 10 minutes or 600 seconds, that works out to 1,800,000 km/turn. Given that a hex is 10,000 km across, that works out to a speed of 180 hexes per turn. Since the game map is only 54 hexes wide, you’ll never get to that speed in the game.

The problem comes when people start looking at ADF as acceleration in gees, i.e. that 1 ADF = 1g of acceleration. If you make that assumption, then accelerating at 1 ADF per turn, it would take you 180 turns to get to jump speed from rest. 180 turns at 10 minutes per turn means that it would take just 1,800 minutes, or 30 hours, significantly faster than the 83.33 hours calculated above. Obviously 1 ADF cannot equal 1 g.

So let’s work that out. 1 ADF represents a change of velocity of 10,000 km per 10 minutes in 10 minutes (or 100 km/min/min). That’s an acceleration, just not in the normal units of m/s/s. So lets convert them:

\frac{10,000 km}{10 min * 10 min} = \frac{100 km}{min^2} = \frac{100,000 m}{60 s * 60 s} = 27.778 \frac{m}{s^2} = 2.78 g

So we see that 1 ADF is really 2.78 g of acceleration. You’re not going to sustain that for 30 hours and have anyone in any sort of condition to function unless severe precautions are taken. Heck, even sustaining that for 1 turn (10 minutes) is going to be rough. It’s doable, that amount of acceleration and duration is roughly equivalent of a launch to low Earth orbit with modern rockets, but you wouldn’t want to keep it up for a long time.

That also raises another issue. 5 ADF is actually 13.89 g of acceleration. And Star Frontiers doesn’t have any sort of artificial gravity tech. Pulling those kind of maneuvers is a little unrealistic. (There are discussions about using interia screen tech to help with this but that’s a different article.)

There are a couple of solutions to this. One, which is the one I use and which is probably the simplest, is a willing suspension of disbelief. The board game rules are just that, rules for a board game that simulates (sort of) spaceship combat. There are other issues with the board game physics besides this one, so I don’t expect it to represent “reality”. It’s a fun way to approximately simulate spaceship combat.

Another option, which immediately removes the 1 ADF not equaling 1 g issues, is to change the size of the hexes in the board game. Simply saying that they are 3,600 km in size instead of 10,000 km, makes 1 ADF = 1 g. If you keep the range of weapons the same (measured in hexes as they are described in the game rules, the only thing that really changes is that any planet counters you put on the map have to take up 7 hexes instead of just 1. And it might tweak the gravity rules a bit, but not significantly. This doesn’t solve some of the other problems, however. That’s a whole different post as well.

How I Apply This In Game

So how do I use this?

Basic Application

For most ships, I assume that they have two astrogators that can work in alternating shifts around the clock to do jump calculations. Since the rules say it takes 10 hours of calculation per light year traveled. And since it takes over 80 hours of travel time to get to jump speed. This means that any jump of 8 light years or less takes the same amount of time, namely 8.5 days, which I typically round up to 9 for maneuvering around the station and slight variations in arrival location (see my linked posts). And actually, since I round this up to 9 days, it play it that jumps of 9 light years or less all take 9 days, regardless of distance. Each light year beyond 9 adds a half of day of travel time to allow for the calculations. This is how I calculate the travel times for ships in my Detailed Frontier Timeline.

Again that assumes that they have two astrogators. If not, jumps take significantly longer, namely one day per light year traveled, plus 4.5 days to slow down at the destination, with a minimum of 9 days total travel. So in this case, jumps of five light years or less take 9 days, and each additionally light year adds a day on to the jump time.

Now I do allow the jump calculations to be started before the ship leaves it’s berth, assuming the crew knows when they plan to leave (to within a day or so). But because the planets and stars are always in motion, and the jump calculations have to be done for each specific jump, no more than half the calculations can be done in advance. The rest must be done “in flight.” For me this represents the tweaking and refining of the ship’s course in preparing for the jump that I discuss in the other articles I linked. But that means that even for a ship with a single astrogator, they can reduce the flight time if the astrogator gets started before they leave on the longer jumps.

Traversing multiple systems in a single trip

Another aspect of this is what I like to call the “high speed transit.” This occurs when the ship wants to traverse several star systems but doesn’t need to stop in each one. In this case, the first jump starts as usual, but once they traverse the Void the first time things change.

In each system after the first, until they reach the final system that they want to stop in, they don’t decelerate, at least not appreciably. But rather remain near jump speed, either drifting or, if they want gravity, decelerating for a few hours, flipping around and accelerating, and repeating until they are ready to jump. During this time the astrogators work on the jump and the engineers do any needed engine overhauls. The amount of time spent in system is just the longest of those two activities. Once that’s done, they nudge into the next system and repeat until they arrive at the destination system where it then takes 4.5 days to slow down.

Let’s look at an example: The UPFS Stiletto, an assault scout, is on patrol in Truane’s Star and has orders to get to Dramune as quickly as possible. This route has 4 jumps:

Truane’s Star to Dixon’s Star – 5 light years
Dixon’s Star to Prenglar – 5 light years
Prenglar to Cassidine – 7 light years
Cassidine to Dramune – 4 light years

Using normal jumps, these are all less than 9 light years so each jump would take 9 days for a total of 36 days.

Rather than do this, let’s look at what this takes using the high speed transit option. According to the rules, engine overhauls take 60 hours minus 1d10 hours for each engineer level. The rules also say that Spacefleet ships typically have level 4 engineers. That means that on average, it will take 38 hours to overhaul each engine. We’ll assume that there are 2 astrogators and 2 engineers onboard the Stiletto. This is what a high speed transit looks like in this scenario:

Accelerate out from Truane’s Star – 4.5 days – plenty of time to do the 50 hours astrogation calculations
Transit Dixon’s Star – astrogation calculations take 50 hours (2.5 days of round-the-clock work), engine overhauls only take 38 hours of work, but since there is only one engineer per engine, they have to sleep. So these are the slow part, taking 4 days – so after 4 days, they jump to Prenglar
Transit Prenglar – astrogation will take 70 hours (3.5 days of round-the-clock work). This one is closer but the 4 days of engine overhauls is still the limiting factor. After 4 days they jump to Cassidine.
Transit Cassidine – Here the astrogation calculations only take 40 hours (2 days of round-the-clock work) and the astrogators get a bit of a break while the engineers finish up. After 4 days, they make the jump to Dramune
Decelerate in Dramune – it takes 4.5 days to slow down and arrive at Inner Reach.

All told, this trip takes only 21 days instead of the baseline 36, saving 15 days of travel. The crew might be a little tired, but they made it without taking any risks.

If you only had 1 astrogator and two engineers, one level 3 and one level 2 (more likely on a merchant ship or PC ship), the transit looks like this:

Accelerate from Truane’s Star – 4.5 days, same as before. We assume the astrogator got started before they left.
Transit Dixon’s Star – Astrogation takes 5 days, engine overhauls take 43.5 for the level 3 engineer and 49 for the level 2 engineer. The level 3 engineer can help the other engineer once they are done so the total time to do the overhauls is five days – Time in system 5 days.
Transit Prenglar – In this case the limit is the astrogation which takes 7 days. Time in system, 7 days.
Transit Cassidine – This time the astrogators win and the jump is waiting on the engineers – Time in system, 5 days.
Decelerate in Dramune – 4.5 days.

Total time: 26 days. Takes a little longer but still faster than the base 36 hours. If there was only one engineer, it would actually take longer than 9 days per system as one engineer just can’t do engine overhauls on two engines in each system that fast (unless they are level 5 or 6). You might as well stop over in the station each time unless you have a reason not to go into a system.

Final Thoughts

That’s it for this post. There are other aspects of the travel that I could talk about such as vector movement, the process of lining up for a jump, what happens to your calculations and alignment when you have to maneuver for a combat or something else, and a discussion on how long those alignment efforts take anyway. Some of those ideas I touched on in the posts I linked. I might look at these again in a future post or two as well.

What are your thoughts? What questions do you have? Share them in the comment section below.

HSS History’s Hope – part 2

This isn’t the post I had planned to do this week but since my game session last Wednesday fell through, I can’t post the details of that adventure yet. So I’m going to revisit the HSS History’s Hope this week. Hopefully we’ll get that game session in on Wednesday and I can post up all the goodies from that adventure.

A few weeks back I was contacted by long time game fan Matt Crymble about the HSS History’s Hope and the timeline project in general. Matt’s on-line involvement in Star Frontiers predates even my one as he is one of the original list serv members from back in the day that I was never a part of. We featured some of Matt’s creations in early issues of the Frontier Explorer and he created the Khad’dan, or yazirian honor blade that figures into a lot of the fan material.

He asked me if I was interested in any help on creating the ship and while I already had KH stats and partial deck plans for the ship, he did a wonderful write-up on the ship’s history. So let’s look at the ship a bit closer.

The HSS History’s Hope

History of History’s Hope

This is the write-up Matt sent me:

The HSS History’s Hope began life as an Imp Class Yacht which was modified into a racing yacht. The vessel class was initially selected for reliability and comfortable long term crew habitation, both critical for the exhausting pace of multi-system racing. Its speed was boosted at the expense of some maneuverability and as a racer it held a distinguished career even though it was not considered a champion. Unfortunately, the highly competitive nature of interstellar racing meant that the ship was too expensive to maintain without champion results and it was eventually made available for sale.

The vessel’s reliability and comfortable crew accommodations also made it a good choice as an exploration vessel and the extra bracing that was added for the increased acceleration from a standard Imp Class make it a sturdy little ship. The racer was slightly modified again after being clandestinely purchased by True Yazira and was rechristened the HSS (Histran Star Ship) History’s Hope out of the Scree Fron system.

Little modification was needed to turn the vessel into an exploration ship, though extra food and fuel stores as well as crew comforts and spare parts were added. Additionally the ship’s precision racing navigation station, known as the “sailing bridge” aboard ship, remains unchanged physically having only received new software to assist with the difficult astrogation tasks of plotting entirely new jump routes.

Because of its status as an exploration vessel the standard radar system was upgraded to include a planetary radar mapper and a planetary scanning system. The planetary scanning system can also work as a limited energy sensor in a focused area in an emergency while in interstellar space. The History’s Hope retains the ability to land on atmospheric worlds with habitable G ratings. The Assault Rocket launcher has been removed though a small part of the mechanism remains and parts were later added to give the vessel the ability to launch atmoprobes.

Crew compliment for a ship this size is small. This is a holdover from its racing days when extra crew was considered extraneous and the vessel is usually crewed with experienced spacers to ensure all needed skills are present. The extra crew berths are taken up by scientists and other specialists with most of the remainder being used for the extra storage necessary for such a long journey.

I hadn’t thought of the idea of an old racing ship, but I had intended it to be HS 4 and an old yacht. So I love this backstory for the ship. There are just a few things in his write-up that I am going to change. Otherwise, it will stand as is.

Modifications

First, it wasn’t “clandestinely purchased by True Yazira.” At least not explicitly. The ship is owned by the Yazira Heritage Foundation (YHF) which is a public non-profit organization. The True Yazira society is a major funder of the YHF, but not as an organizational endeavor. Rather the YHF has many private donors who also happen to be True Yazira members. It’s a happy coincidence. Although not surprising as the goals of the YHF directly align with some of the goals of the True Yazira society and it’s only natural that members of one would donate to the other.

Second, the ship was modified to have a lot more crew that I think Matt was intending. In the end, the ship has a total crew capacity of 24. Actually, there are 24 crew members, the capacity is actually a bit higher but that would require double bunking.

In addition to the ability to launch atmoprobes, I also added in a landing drone and a remote probe, as well as adding in a full-sized (20 being) lifeboat, a small (10-person) lifeboat, a workpod, and small launch. The truth is, a HS 4 ship starting to be pretty large. Designing the ship with my new starship construction system that takes volume into account, and adding in all the systems I needed, created a ship that was within a couple hundred cubic meters of the standard HS4 volume, a difference of just a few percent which is well within the design variation limits given in the rules.

I like how he indicated that it probably had a Deluxe Astrogation suite. That was definitely in the cards for this ship and it would have been upgraded to such if it didn’t already have it. In my game, having the Deluxe Astrogation suite gives a +10% to all astrogation skills. Something definitely needed when charting unknown routes.

While the planetary radar mapper and a planetary scanning system are not standard equipment listed in the rules, I like the description. I did add energy sensors to the ship, so that have that at full capablitily, not just a limited one as described in Matt’s text.

Full Ship’s Stats

Here are the full stats for the ship as I wrote it up:

HS:	4
ADF:	4
MR:	3
DCR:	32
Engines:	2x Class A Atomic
Crew Berths:	24 single occupancy cabins – Journey Class equivalent
Weapons:	LB
Defenses:	RH
Communications Equipment:	videocom radio, subspace radio, Intercom system
Sensor Systems:	deluxe astrogation suite, radar, energy sensors, skin sensors, external camera system
Life Support:	Primary: 600 days for 35 beings Backup: 200 days for 35 beings
Exploration Equipment:	2x atmoprobe, 1x remote probe, 1x landing drone, 1x laboratory
Computer Level:	4
Computer Programs:	Astrogation 4, Atomic Drives 4, Computer Lockout 4, Damage Control 2, Alarm 2, Laser Battery 1, Skin Sensors 1, Guidance/Analysis 3, Anlysis 3, Maintenance 1, Information Storage 6, Communications 3, Language 4, Robot Management 4
Vehicles:	small launch, large lifeboat, small lifeboat, workpod
Other Equipment:	30 spacesuits, laser power torch, 2x engineer’s toolkit, full redundant backup computer, 300 atomic fuel pellets

Deck plans will come in a future post. I have them mostly sketched out but still have a couple decks to go and need to make digital versions of them to share.

The Journey So Far

That’s the ship. Let’s next turn to looking at the crew and their travels up until now.

Crew

The crew is fairly large for this small of a ship, but the truth is, there is plenty of room inside the hull for them all. The crew size, as given in the stat block above, is twenty-four. It breaks down like this:

2 pilots
3 astrogators, one of which is the captain of the expedition
2 engineers
2 energy weapons specialists
2 technicians
1 roboticist
1 computer specialist (in addition to the astrogators)
1 psycho-social specialist
1 doctor
2 environmentalists
4 security personnel
1 linguist
2 archeologists

The first half of the crew are concerned with getting them to their destination or keeping the ship systems and crew running on the journey. The second half are merely passengers for the initial voyage, their skills will be needed if their destination turns out to actually be Yazira.

The Journey

When I first posted about the trip, the ship had left the Frontier and started into the Yazira sector and had made several misjumps. In the intervening months, they have recovered from those early errors, made more, recovered again, and continue to make progress toward their goal. Here is the sector map with the systems they have visited and the jump routes plotted.

The Full map. Click for full sized version.

The route to YS07 is a bit of a spoiler, but only because I’m a bit behind on posting the timeline updates. I should have already posted the successful jump from YS06 to YS07 by now. In fact, today they are beginning their acceleration back to YS06. Those updates will show up in the next few days. At this point, they are about 1/3 of the way across the Yazira Sector to their destination and not quite half way from Scree Fron.

What Does the Future Hold?

The ship is coming up on its one year anniversary since it’s retrofit. That means that they will have to decide if they want to double back to the Frontier for their annual maintenance, or skip it this first year and push on. Even making a high speed transit, it’s on the order of 50 days back to Scree Fron and another week to the nearest SCC. Then 5-15 days of maintenance. And then that same amount of travel time to get back to where they left off. That’s over a quarter of a year of travel. They’ll have to decide if the chance of a system breakdown is worth it.

Also, they were attacked back in YS01. There may still be ships there. And most probably there will be hostile ships in the Frontier itself. They have enough fuel and life support to make it all the way to their destination assuming no major mishaps. But they may have to return for supplies anyway.

The next jump after YS07 is going to be a long one, either 10 or 12 light years. And then some long ones after that, so there is plenty of chance for mishap. There’s a reason this part of space is called the Vast Expanse, the stars are few and far between and the crew is starting to run into that now.

I know what the future holds for the ship in certain areas, but I am actually rolling for all the astrogation skill checks as they come up so I never know if they will succeed in a jump or not. Which means I don’t know how successful they will be or what detours will come up. We’ll have to find out together.

Final Thoughts

That’s it for this post. I’m working on the deck plans and will post them, along with another progress update, once they are done. I’m also planning on a 3D model of the ship once the deck plans are finished. Although that might not be for a couple more months. But those are things you can look forward to.

What thoughts to you have on the travels of the HSS History’s Hope? Are there things about the ship or the expedition you’d like to know more about? Do you have ideas of things they might run into? Let me know in the comments below.

Quality of Spacefleet Enlisted Personnel

This thought has been bouncing around in my head for a long while now so I figured I’d get it out of my head and on (digital) paper so it would quit distracting me. It doesn’t have anything specific to do with any of the projects I’m currently working on but I’m sure it will apply at some point in the future. Regardless, it’s definitely good background/setting material so I’ll label it as such. While the specifics are related to Star Frontiers, the general though process can apply in any setting you are working on.

The “Problem”

In the Knight Hawks Campaign Book (p 48-49), it says:

Although the officers of the Spacefleet represent some of the finest individuals in the Frontier, the same cannot be said for the crews of Spacefleet ships.
The enlisted members of the fleet come from all walks of life. The fleet always is short of crew members. so the requirements for enlistment are not rigorous. No checking is done regarding a crew member’s background or abilities; consequently, a great amount of galactic riffraff has found a home in the crew’s quarters of Spacefleet vessels.
Many of these crews become fine fighting units; the combat record of the Spacefleet is impressive. Occasionally, however, a charismatic bully will win the respect or inspire the fear of his mates to the point of inciting a mutiny. More than one Spacefleet vessel has dumped its officers into space and disappeared to the fringes of the Frontier to embark on a career of piracy and plunder.

I’ve always had a bit of a problem with this idea for a couple of reasons. One, I’m not sure I agree that they are always short of recruits, unless it working for Spacefleet is a really bad job. It doesn’t feel to me that the crew sizes are all that big. The other is the skills required to make off with a ship. Let’s look at those each in turn. Maybe I’ll change my mind by the end of this, or maybe not.

Short Staffed

Let’s start by looking at the staffing issue. There are estimates of crew size for each of Starfleet’s vessels in the opening of the Knight Hawks Campaign Book (KHCB, p. 5) where it describes the different ships. From that we get the following crew estimates:

Fighters: 1
Assault Scout: 4-6
Frigate: 25-30
Destroyer: 40-50
Minelayer: 30-40
Assault Transport: no crew size give but 600-1000 troops, estimate 100 crew
Light Cruiser: 70-100
Heavy Cruiser: no crew size – estimate (based on the battleship) of 300-400
Assault Carrier: 300-400
Battleship: 400

Now I’m going to ignore the Assault Transports in this analysis, at least to start, as they are mentioned nowhere else in the rules and there aren’t even game chits for them. But I’ll probably come back to them later.

If we take the Order of Battle from the Second Sathar War game (KHCB, p. 55) as the baseline size of Spacefleet, we have the following number of ships:

Fighters: 16
Assault Scouts: 14
Frigates: 7
Destroyers: 5
Minelayers: 4
Light Cruisers: 8
Heavy Cruisers: 1
Assault Carriers: 2
Battleships: 3

Now I’d argue that the minelayer in the unattached ships list should be an assault carrier, but it won’t change substantially the argument.

Using that list of ships, what is the total crew size of Spacefleet? We’re going to ignore the fighters, as those are single crew vessels and are going to be manned by officers, not enlisted crew. With their small crew size, the same could probably be said of the Assault Scouts, but we’ll count them anyway. I’ll use the max crew size listed for each ship. This gives us:

Ship Type	# of ships	Crew Size	Total Crew Members
Assault Scout	14	6	84
Frigate	7	30	210
Destroyer	5	50	250
Minelayer	4	40	160
Light Cruiser	8	100	800
Heavy Cruiser	1	400	400
Assault Carrier	2	400	800
Battleship	3	400	1200
Total			3904

If we assume that 10% of the crews are officers, that gives 390 officers and 3514 enlisted. Which to me, doesn’t seem like all that many positions to fill.

The question then becomes, how hard is it to fill those 3514 positions across all these ships? That really depends on what you feel the population of the Frontier is. The game gives population codes (heavy, moderate, light, and outpost) for all the worlds but never really defines what numbers those correspond to.

In a thread on the old starfrontiers.org forums (now defunct) I did a simple analysis of birth and death rates and population growth. Given that some of the worlds of the Frontier have been inhabited for up to 400 years (if you use the Zeb’s Guide timeline), subtle tweaks to those values, would allow you to have basically any population you wanted on a world. (I should resurrect that analysis, I still have the data, and do a new post on it.)

Let’s go with what I consider low population numbers:

Heavy population – 500 million inhabitants
Medium – 200 million
Light – 50 million
Outpost – 200 thousand

According to the AD rules, there are 7 Heavy populations worlds, 8 with medium populations, 4 with light populations, and 3 outposts. Using those numbers, across the Frontier, there are a total of 5.3 billion inhabitants. That’s less than the current population of the Earth. That means that the 3514 enlisted crew members that we need represents 0.000066% of the population. Or one out of every ~15000. I don’t see that as an impossible number.

I mean just for comparison, the ship’s compliment of a US Nimitz class aircraft carrier is 3532. And that doesn’t include the air wing. The US Navy operates 10 of those carriers, with a total crew size of 10x what we’re looking for, with a population of just 330 million, 16x smaller than the estimated Frontier population. And that’s just the aircraft carriers.

Based on those numbers, I just don’t see that it would be that hard to fill the enlisted berths with high quality, low risk recruits.

More Ships?

Now, how might those numbers vary? The first option is that Spacefleet has more ships. The listed order of battle is, after all, from a strategic and tactical board game, picked for playability game balance. The number of ships could be larger. Although the background material in the rules do say there are only 3 battleships. It’s not unreasonable to think that there might be twice as many ships. But that still doesn’t add that many more crew members, putting us up to only 2 aircraft carriers worth.

Another possibility is that there are lots of those assault transport flying around. If you wanted to transport 30,000 troops, you’d need 30 transports, at 100 crew per transport that’s another ~3000 crew members. So depending on the number of troop transports flying around, You could have an order of magnitude more crew members, which gets us closer to the crew complement of just the US aircraft carriers.

Still the crew numbers are small, filling the berths shouldn’t be too hard.

Smaller Population?

Another option is to make the population of the Frontier smaller. But remember that the US Navy supports a much large crew compliment on a population that is almost 20 times smaller. I think you’d have to make the populations of the Frontier worlds, really small indeed for this to start to be an issue.

In fact, I think the population would actually be larger than the numbers I quoted above, by at least a factor of 2 if not more. These worlds have been settled for a couple of hundred years at least. In the last 200 years on Earth the populations has grown from 1 billion to 7.8 billion. Give the high quality medical care, lots of available space for population growth, and general high level of industry and technology, it would not be unreasonable to have a very high birth rate and low death rate. Especially since the average lifespans are much longer.

Undesirable positions?

Another factor would be that these positions are somehow undesirable. This could be possible. Maybe Spacefleet is strapped for funds and doesn’t pay very well. Or maybe people don’t like being on-board ships for extended tours. Or there is some other factor. While these are all possibilities, I don’t seen them being a big factor.

Crews sizes are relatively small, which means it doesn’t take a lot of credits to make payroll. While it may not pay quite as well as civilian sector jobs, I don’t see it being that much different.

I don’t see the on-board living conditions being that much of an issue either. With the exception of the assault scout, these ships are quite large relative to their crew size. A modern Arleigh Burke destroyer is basically the same size as a Knight Hawks destroyer. But the Arleigh Burke has a crew of 300 while the UPF destroyer has a crew of 40-60, 6-7 times smaller. Now there are differences in equipment and living space, but that still leaves a lot of room to make living accommodations more spacious and comfortable. Living on these ships wouldn’t be too bad. Plus they regularly call on stations around the Frontier giving plenty of opportunity for “shore leave” on a regular basis.

I also don’t see it as a reputation issue. Nothing in the game indicates that Spacefleet is looked down on. Quite the opposite actually, it seems that Spacefleet is held in high regard around the Frontier. So sporting the uniform would seem to be a plus not a negative.

There might be other reasons that I’m not thinking of that might make the job less than desirable. Share your thoughts in the comments. The bottom line is that I don’t think Spacefleet would have a problem filling their limited crew slots with high quality crew members, rather than the “galactic riffraff” as described. There might be some that make it in, but I don’t see it being a high percentage.

Crew Mutinies

Let’s leave that aside for now and assume that for some reason, there is a lot of “galactic riffraff” in the Spacefleet enlisted ranks. Even if that is the case, I don’t see them dumping their officers and sailing off to the fringes of the Frontier to engage in piracy.

And the reason is the way the skills are structured. It takes a very skilled set of individuals to fly a spaceship. I don’t see the “galactic riffraff” have the necessary skills and experience to reach the levels necessary to fly these ships. Even an Assault scout takes a level 2 pilot skill which in turn requires level 2 computers and level 6 technician. And a frigate or destroyer requires a level 3 skill. And then you need at least an astrogator, and preferably an engineer and some gunners, although those latter might be able to be recruited later.

In Spacefleet, those skills are found in the officers, not the enlisted crew. If a crew mutinied and dumped its officers, the ship would just sit there as there would be no one to fly it.

That isn’t to say there couldn’t be mutinies. It would just have to involve some of the officers so that there are enough of the spaceship skills to fly the ship. While that goes counter to the quote from the rules, it’s not unreasonable. In fact, in my campaigns, there is a Spacefleet officer that makes off with one of the light cruisers and one point in the timeline.

There is no reason mutinies can’t happen, I just don’t think they would be quite the way described.

Final Thoughts

So that’s my take. Personally, I don’t see the enlisted personnel of Spacefleet being of any lower caliber than its officer corps. The population is high enough, and the number of berths to fill low enough, that they should be able to screen for the better candidates. And while mutinies may happen, they are going to have to involve the officers to some extent or there will be no one to fly the ships.

What do you think about the status of the Spacefleet personnel? Do you play it as written or modify things to be different? If so, what modifications do you make? Share your ideas in the comment section below.

The original draft of this post (everything up through the end of the initial quote) was saved back in May of 2018, right after I started the blog. It had been bouncing around in my mind for a while then, and that was two years ago. I might have more to say in the future but it’s late and I need some sleep.

Economics of Spaceflight – part 1b – Starliners

Last week we looked a bit at the logistics of running a passenger transport system between the various worlds and saw that if you wanted daily flights between all the worlds, you’d need over 600 ships. And that would only give you 250 people moving between each world each day.

Now you can change that a bit by making the ships a bit larger or increase the passenger density. But it gave us a feel of what assumptions or changes you need to make to your setting if you want a certain level of interaction between the worlds. Or if you limit the number of ships and passengers, some ideas of what impacts that has on the culture and setting.

In this article, I am going to look at the financial side of the passenger transport business. We’ll start by actually designing our starliner to get an idea of costs and expenses, look at ticket prices, and decided if it is even worth it. Then we can talk a bit about other changes that we need to make, if any, to make this all make sense. Let’s get started. You might want to settle in. This one is a bit long.

Our Ship

If we’re going to look at economics, we’re going to need details on the ship. In the last article, I based everything on a HS 10 starliner. We’ll detail that ship out and look at its cost.

Hull and Engines

As a HS 10 ship, it will have three engines, which from the discussion last week, are atomic. I realize now that as a passenger liner, maybe we don’t need the power of the atomic engines and can get by with ion engines. Surprisingly, in the discussion that the previous post generated, no one mentioned that. It would also save on the overhaul time as ion engines don’t need that so the ship could be turned around in port more quickly. But for now, we’ll stick with the atomic engines.

Cabins

The next major question is how many of the various passenger berths we have of each class. We have a total of 250 berths. Journey class are the standard. Interestingly, the only safety requirement listed in the rules is that a spacesuit has to be provided. You don’t actually have to have lifeboats for everyone. First class berths are more expensive and require more cabin space, cargo space, and facilities for the passengers. And do need access to a lifeboat. Storage class cabins are cheaper for the passenger and have minimal storage space, but are more expensive to install in the ship, costing as much as a First Class cabin. With the standard starship construction rules, these tradeoffs really don’t affect the design of the ship other than the final cost as the system doesn’t really account for the space and facilities needed. So for this analysis, I’m going to roughly base these ships on our modern airlines, with most of the cabins of the base Journey Class category with a few First Class and some Storage Class. The breakdown will be 40 First class, 180 Journey Class, and 30 Storage Class.

Crew

The other major decision is the size of the crew. We will need to purchase cabins and life support for them as well. The rules give no guidance on this. Looking at cruise ships, it is about a 1-to-5 ratio, crew to passengers. Some of that, such as janitorial and maintenance work, will get automated away to robots on our star liner, but then we’ll need people to look after the robots as well. We’ll design the ship around a crew of 50. We’ll talk about the breakdown later when we have to figure out what they are paid.

Ship Vehicles

While we only need lifeboats for the First Class passengers, we’re going to have lifeboats for all of the passengers (except Storage Class, that’s just one of the hazards of the cheap fare, you are frozen and can’t get to a lifeboat) and the crew. And we will toss in 10 escape pods so not everyone has to make it to a lifeboat. As the final vehicles, we’ll add in 5 large (10 being) launches for shuttling people around between the station and ship, 2 small (4 being) launches for the crew’s use, and 2 workpods for ship maintenance.

Spacesuits

We are required to have spacesuits for all of our non-Storage Class passengers. Plus we’ll have them for the crew as well. Technically, each species has its own style of spacesuits adapted to their physiology. The rules, however, only distinguish between vrusk and non-vrusk as they are only really concerned with cost and the standard spacesuit is 1000 cr. while the vrusk suit is 1,500 as they require more material. If we assume that vrusk make up one quarter of the crew and passengers, and we build in a bit of buffer in the numbers to account for varying numbers of the different species, we’ll get 80 vrusk spacesuits and 220 non-vrusk ones. This is 300 total, which is exactly our crew and passenger count but remember that the 30 Storage Class passengers won’t be using one so we actually have 30 extra.

Robots

There will be a number of robots on board to handle things like cleaning, maintenance, some food production, etc. We’ll design the ship to have 50 robots, basically doubling the crew size. These will be a mix of level 3 and 4 service and maintenance robots, will possibly a small number of security robots. Overall the average cost of each robot will be 4,000 cr.

Other items

There are a number of other items that go into building the starship such as radios, intercoms, computers, portholes, Velcro boots for crew and passengers, toolkits, etc. We’ll add those in as appropriate and list the details in the final stats when presented in the next section:

PGCSS Prenglar Glory

Here are the full KH stats for the ship along with its price tag, fully fueled.

HS: 10
HP: 50
ADF: 3
MR: 3
DCR: 50
Engines: 3 Class B Atomic, 6 fuel pellets each

Communications Equipment: Videocom radio w/ 4 extra panels, Intercom system: 5 master panels, 400 standard panels, Subspace Radio
Sensors: 400 Portholes, radar, camera system, starship astrogation suite
Weapons: None
Defenses: Reflective Hull
Life support capacity: 500 beings, 200 days with full backup
Passenger Accommodations: 40 First Class cabins, 180 Journey Class Cabins, 30 Storage Class cabins
Crew Accommodations: 50 Journey class cabins
Vehicles: 10 escape pods, 14 lifeboats, 2 workpods, 5 large launches, 2 small launches
Computer Level: 4 (175 FP)
Computer Program: Drive 5 (64), Life Support 1 (4), Alarm 3 (4), Computer Lockout 4 (8), Damage Control 3 (8), Astrogation 4 (24), Cameras 1 (1), Robot Management 4 (16), Information Storage 3 (8), Communications 2 (6), Installation Security 3 (12), Computer Security 4 (16), Maintenance 2 (4)
Backup life support computer: Level 1 (4), Programs: Life support 1 (4)
Robots: 50 level 3-4 maintenance, security, and service robots
Other equipment: 220 non-vrusk spacesuits, 80 vrusk spacesuits, 300 velcro boots sets, 5 Engineer’s toolboxes, 10 sets of Magnetic shoes
Cost: 5,658,000 Cr.

The Ship’s Crew

Now that we know the design of the ship, we need to decide on crew makeup. This will determine the wages owed as we operate the ship in the space lanes. This is going to be an approximate mix. The exact details may vary ship to ship but will give us a starting point to figuring out the operating costs when we get to that stage. The crew makeup I settled on, allowing for round-the-clock operations is:

2 Pilots – level 5 – necessary to operate a HS 10 vessel
2 Astrogators – level 3 – It’s an established route so these could be even lower level
2 Engineers – level 4 – as discussed last week for effecting the engine overhauls
4 Technicians – level 4 – assistants to the engineers and helping with on-board maintenance
4 Roboticists – level 4 – maintain the ship’s robots
2 Computer technicians – level 2 – basic computer operations and maintenance
10 Safety and Security staff – level 3 (beam) – assisting passengers and keeping everyone in line
3 Doctors – level 4 – for maintaining the health of crew and passengers
10 Food Services staff – level 3 – cooking, maintaining hydroponics, servers, etc
11 other staff – level 2 – any other duties, entertainment, etc.

Now some of those, such as security, food services, and other could slosh around a bit depending on exactly want you want on the ship and what roles all those robots play, but this mix give us a starting point.

The Economics

Okay, with the ship squared away, let’s look at the income and expenses of running this ship.

For this analysis, we will be looking at a single jump. This means that we’ll be covering the 14 days from departure from one station until the ship is ready to depart the other one. The Knight Hawks rules are based around yearly or 40-day “months”. So we’ll often be scaling the values from the rules to cover just the 14 day period.

Let’s dive in.

Income

There is really only one source of income on a starliner, paying passengers. The KH Campaign Book, page 44, covers the operations of a starliner. We’ll start with the Spaceliner Bookings Table.

This table tells you how many of your berths a ship will fill traveling between different population worlds. Now to be honest, I believe that this table really represents the situation if there were lots and lots of travel available. If there is only a single ship flying between the two worlds each day, it will probably fill every berth every trip. And depending on the route, it might be higher than that given by the table. For example, traveling from Prenglar (high population) to Dixon’s Star (outpost) gives only a low fill percentage but in truth, most of those people are actually going to Truane’s Star (medium population) and so the ship would be fuller. But I’m going to leave those details as an exercise for you to do for your version of the Frontier. I’m going to take the table at face value here.

This ship is flying between Gran Quivera (Prenglar) and Triad (Cassidine), which are both high population worlds. According to the table the ship will fill 80+2d10 percent of its berths on any give trip. We’ll just deal with the average which is 91%. That means on an average trip we will fill 36 of our 40 First Class cabins, 164 of our 180 Journey Class cabins, and 27 of the 30 Storage Class berths. Sometimes it will be more, sometimes it will be less but that’s the number we’re going to use.

The jump from Prenglar to Cassidine is 7 light years. That means that a First Class ticket costs 1400 cr. A Journey Class ticket costs 700 cr. And a Storage Class ticket costs 210 cr. Given the number of berths being filled, that means that our income for any single jump is 170,870 cr.

That’s our gross ticket sales. We need to fit all of our expenses for a trip into that number. So let’s look at our expenses.

Expenses

First up is fuel. We have three atomic engines and each jump uses a fuel pellet in each engine. Since each fuel pellet costs 10,000 cr., each jump costs us 30,000 cr. in fuel.

The next obvious cost is the crew salaries. Daily wages for characters with spacecraft skills are given on page 54 of the KH Campaign book. Daily wages for characters with AD skills are given on page 60 of the AD Expanded Rules book. For the “other crew” line I just uses 10 cr. x level as their pay rate and for the food services crew I use 10 cr. x level+1. I’ve also ignored the fact that characters may have multiple skills and the pay rate is just based on their primary skill level. With the crew as detailed earlier, the daily cost for the entire crew is 3,690 credits. Which means for the 14 days of our trip, the crew wages come to 51,660 cr.

After those two, the next largest cost is maintenance. The ship has to spend 15-16 days in maintenance each 400-day year at the cost of 1,000 cr. per day. In 400 days, a ship can make 400/14= 28 trips 8 days left over. That means that we can make 27 trips a year. So each trip needs to save away 16000/27 = 593 credits to cover that expense at the end of the year. To be safe, and cover other unexpected maintenance costs, we’ll stash away 1500 cr. each trip.

We’ll also need to pay the crew during those 16 days as well so we need to save away a total of 59040 credits to cover wages. That means each trip needs to save 59040/27 = 2187 credits which we’ll round up to 2200.

Each trip consumes life support. According to the rules, refilling the life support system on the ship costs 15000 credits every 200 days or 75 credits a day. Thus our 14 days of operation use up 1050 credits worth of life support.

Another expense is an office at each end of the line where passengers can come to buy tickets. The rules state that this costs 500 credits per 40 days at each station or 12.5 credits a day. With two end points that’s 25 credits a day or 350 credits of expenses for the 14-day period. We need to squirrel way a bit of funds to cover the 16 days in maintenance but it’s not that much and we can assume it’s covered by the extra maintenance money we saved.

Finally, there are docking fees. Here we are going to use the number given on page 32 of the module SFKH1: The Dramune Run, where it says that the standard rate for docking fees is 2000 credits a month. Assuming that is the 40 day “month” we’ve been using, that works out to 50 credits a day or 250 credits for the 5 days in port during each run.

Tallying that all up, we get that the operating expenses for the ship total 86,810 credits for each leg of our run between Gran Quivera and Triad.

That seems pretty good. We’ve got just over 170,000 credits in income and just under 87,000 in expenses. Which is all well and good if there aren’t any taxes, and if the ship is paid for.

Now the rules don’t explicitly give rates for taxes, tariffs, and other fees associated with interstellar travel although they do talk about varying the rates for wages, docking fees, ticket prices, etc. that can affect the income or expenses for our ship. And in the AD rules, when talking about PC and NPC character wages, it says to assume half of all their income goes towards living expenses and talks about raising/lowering taxes to adjust the amount of money the PCs have. And local governments and the UPF need to get income from somewhere. I’m going to leave the taxes issue up to you for your campaign. But a corporate tax of say 5-10 percent of gross sales might not be unreasonable.

Paying for the ship

But now we come to the biggest expense, at least during the early years of operating the spaceliner. How did we pay for that ship in the first place? Maybe this is a mega-corp and they had a huge budget and could just pay for it outright. They still need to recoup the cost of the ship but at least don’t need to take out a loan. If it’s a smaller organization, they may have to get a loan for the cost of the ship, either in part or in full. Let’s look at those two scenarios. And we’re going to ignore taxes. Subtracting our expenses from our income, that leaves us with 84060 credits after each trip.

First, the mega-corp, paid in full option. Assuming every one of those net credits earned goes into paying back the cost of the ship (which from above is 5,658,000 credits), it would take 68 trips to pay off the value of the ship. At 27 trips a year, that’s two and a half years to recoup the cost of the ship. If there are unexpected costs, it will take longer.

Let’s look at a smaller organization that has to take a loan. Pager 42 of the KH Campaign book gives the monthly payment on a 10,000 credit loan amortized over a number of years from 1 to 20. Now, the game was written in late 70’s to early 80’s and the interest rates back then were high, on the order of 10-15% for low risk ventures. So the interest rates for starship loans, which are considered high risk, are set at 4% every 40 days or, over the 400 day year, an APR of 48%! That may seem a bit high, even by late 70’s standards and especially today, but we’ll go with it as that is what is in the rules. If you want to do the math and come up with a different interest rate for your setting, go for it.

We’ll start by looking at a 10-year loan. Using the table on page 42 and the cost of the ship from above, and assuming we finance the whole thing. The cost of the loan is 230,903 credits every 40 days or 80,816 credits every trip. We had 84060 credits left so that’s good, the net difference is still in the black at 3,244 credits. But we have to account for that 16-day maintenance period where we still have to pay the loan but aren’t making any income. The loan cost for that 16 days is 92,362 credits. Spread over the 27 trips in the year that comes to 3421 credits that need to be saved. Which puts us in the red by 177 credits. Considering we had a bit of buffer in our maintenance budget, to the tune of about 850 credits, we can cover that small deficit from that.

So that means, if we have a 10-year loan for the entire value of the ship, we can just break even if the ship operates continuously and don’t have any problems for a decade. It can be done, but it will be tight. But if we run into unexpected problems, we’re going to be in trouble. We could look at a longer loan, but beyond 10 years, it doesn’t really help. Even a 20-year loan only puts us at 1454 credits in the black each year but takes twice as long to pay off and we end up paying twice as much for the ship.

That’s just to break even, there are no profits beyond the wages for the crew so hopefully the owner is part of the crew or they get no money for the first decade. And that is the economics for a run between two high population worlds were we basically fill the entire ship each trip. On a run with fewer berths sold, there would issues on the scenario where the ship was financed. Also, if there are any taxes, we would really be in trouble. It looks like any fraction of the ship that can be paid for up front will make the operation be more financially stable.

Some Variations

This article gives you a baseline for operating your starliner. I will leave most of the variations up to you but look at one. Some of those variations include, but are not limited to, changing ticket prices, changing the mix of berths, shortening the time in port so you make an extra run or three each year, selling more (or less) of the berths, different crew expenses, and using ion engines instead of atomic engines. I’m just going to briefly look at the variation where we fill the ship completely every trip. Which may very well be the case if there is only a single flight each day between worlds.

In this case, the only real change is that have 13 more paying customers across all three berth classes. That means that our income goes up to 188,300 credits an increase of 17,430 credits. Since our expenses don’t actually depend on the number of passengers (the life support costs probably would, but we ignored that), that is all extra profit. In this case, we are now 17,253 credits in the black after each trip, assuming we keep the 10-year loan.

And that means we either have some profit for the owners and can save a bit for other unexpected expenses, or we can shorten the loan term a little bit. We were right at the bleeding edge as far as the loan went and were already in the point of diminishing returns with respect to lengthening the loan. With a full ship every trip, we could shorten the loan period from 10 years to 5 years and still have a 5,400 credit surplus. And reduce that actual amount we pay for the ship (principal and interest) by 57%, a savings of 9,921,303 credits, which is enough to buy almost 2 more ships! The total cost of the 10-year loan was just over 23 million credits, four times the cost of the ship. That interest rate is very expensive.

Conclusions

So, running a passenger liner between two high population worlds is doable. It might be tight for a few years (up to a decade) if you can’t pay for at least part of the ship up front and have to finance it, but it can be done. Runs between smaller worlds might not be possible using the table from the rules to determine the number of berths filled.

This also gives you as a setting designer some ideas of knobs to turn to tune things in your setting or describe what PCs see as passengers on one of these ships.

What did I miss? What other variations might we look at? Have you ever had PCs try to run a passenger liner? What happened? Share your thoughts in the comments below.

Economics of Spaceflight – part 1a – Starliners

My Starship Construction in the Frontier post generated a lot of discussion in the Star Frontiers group on Facebook. In some of the discussion, the commenters seemed to be making the assumption that I wanted to increase the number of ships flying around and that my post was advocating for ways to do that. I actually don’t have a strong feeling one way or another. In fact, I’m much more in the camp of small numbers of ships.

What I’m really looking at, and am interested in figuring out, are the implications those small numbers have and whether or not it makes sense to increase the numbers. Or if you don’t, what that implies for the realities of life in the Frontier and how that impacts the player characters.

I’m interested in questions like, if you only have a small number of ships across the Frontier, what does that mean for interstellar commerce? What impacts does that have on interstellar travel? Who owns the ships? What do they cost? And questions like that.

Since that starship construction article came out, and the ensuing discussion, I’ve been thinking more and more about this and have decided to do a series of articles on the topic. They will all have the Economics of Spaceflight title and a similar tag. In this first article, I’m going to look at interstellar passenger travel.

From the Rules

Let’s start by looking at what the rules say about these ships, which it calls starliners, and interstellar travel. We’ll begin with the description given on page 6 of the Knight Hawks Campaign Book:

Spaceliners. HULL SIZE = 6-15. Spaceliners (passenger transports) are built in a wide variety of sizes. Modern spaceliners are fast, quiet ships, capable of providing the wealthy passenger with any conceivable luxury. Many of the older liners are smaller, somewhat decrepit vessels that promise only the fundamental requirements of life support. The number of passengers carried by a spaceliner is about 25 times the ship’s hull size. For example, a spaceliner with a hull size of 10 can carry 250 passengers. Engine durability varies as much as size on spaceliners. Some will require an overhaul after three jumps, while others will be able to make 8 or 10 interstellar trips without maintenance.
KH Campaign Book, p. 6

This gives us a bit of information right off the bat. First, we have the range of hull sizes for these types of ships and the number of passengers per hull size. I’ll have more to say on that latter concept later. It also seems to imply that there are a bunch of these flying around as it describes various generations of ships. Other bits, such as the comments on engine overhauls, tell us that they typically sport atomic engines (as ion drives don’t need overhauls) and indicate some of the properties of the Class B and C atomic engines which the rules haven’t covered yet if you’re just reading through the book.

In the original Alpha Dawn Expanded Rules book, pages 49 and 50 talk about they modes and costs of interstellar travel. It lists three “classes” of travel accommodations and their costs:

First Class – luxurious accommodations with the best rooms, food, and and best access to survival gear in the case of an emergency. 200 Credits per light year traveled.
Journey Class – This is the standard accommodations. 100 Credits per light year traveled.
Storage Class – In this class, you travel as frozen cargo. 30 Credits per light year traveled.

More details on the accommodation types are given on page 21 of the Knight Hawks Campaign Book.

Travel time is one of the areas where the Alpha Dawn (AD) and Knight Hawks (KH) rule sets conflict with one another. The AD rules say that interstellar travel occurs at the rate of one day per light year, while the KH rules, require 10 hours (one day’s work) per light year to plot out the jump, but actually making the jump takes 8.7 days regardless of the distance. Reconciling and clearing that up is a whole article in and of itself. We’ll save that for a future date. For this article, we’re going to assume that it takes 9 days to make a jump, regardless of the distance.

Of course that probably means the cost of a ticket should be fixed as the same number of resources go into making a jump regardless of the distance but for now we’ll go with the AD rules ticket costs.

If the PCs come into possession of a starliner, either via salvage, original constructions, or some other means, the KH Campaign Book (p. 44) provides guidance on what it costs to operate such a ship, how much of the ship is full on any given trip, and the risks involved. We’ll come back to those numbers later as well.

How Many Passengers – revisited

For this article, we’re going to be looking at a HS 10 passenger liner which falls in the middle of the range specified in the KH rules. According to the rules, this ship can carry 250 passengers. The question is, does this make sense?

A modern cruise ship, roughly the size of a HS 10 starliner.

Let’s look at some sources. A HS 10 ship is roughly the size of a modern, large cruise ship here on Earth. These ships typically hold up to 2800 passengers and 1200 crew, for a total of 4000 people, or 400 per hull size. But that’s the maximum capacity and typically means 4 people to a cabin. If you’ve ever been on a cruise ship, you know those cabins are small, typically 15-22 square meters. Now this is roughly the size of a Journey Class cabin on our starliner (16-24 square meters), the difference being that that size on our starliner is for a single being, not a group of four. That immediately means we need to cut our passenger estimate down by a factor of four putting us at about 700 passengers.

The other thing our starliner has to deal with, that a cruise ship doesn’t, it life support. On a cruise ship, air is free. And while there is probably some recycling of water, it’s not a closed loop with full filtering needed. And cruise ships tend to stop and replenish supplies every couple of days unless it’s a long trans-oceanic cruise. So they don’t carry a lot of food on board. In the Frontier, ships are typically designed to carry half a year of food and the systems to process the air, water, and waste onboard which eats up more space on the ship.

Then you have all the lifeboats, spacesuits, and other ship’s vehicles that our starliner has to have. Cruise ships have lifeboats but the passenger density on them is going to be higher than the ones on our starliner and the some of the lifeboats on cruise ships are inflatable. That’s not going to happen on a starship. Those eat up space as well.

Finally, a cruise ship has a lot of the upper decks exposed to air. That doesn’t count against it’s volume but provides a lot of communal space for the passengers. That space needs to exist on starliners as well but has to be enclosed within the hull.

Between the extra life support machinery, the communal space, and the ship’s vehicles, that could easily reduce the capacity of the ship by 30 to 70 percent depending on how you figure it. 250 passengers is just 36% of the 700 passenger number we had left above. It’s possibly at the low end, but reasonable.

Another point of comparison is the volume based rules I created for starship generation. In that system, which accounts for passageway, cabin space, and storage space, I designed a ship the same size as a HS 10 ship in the KH rules. It had a total of 100 First Class cabins, 1250 Journey class cabins, and 200 Storage class cabins. And that includes the cabins for the crew, the size of which the rules don’t address. For this I’ll assumed 50 of the Journey class cabins are for the (lots of robots on Frontier ships). So the total capacity is 1500 passengers, which is a little large. However, this system doesn’t currently account for communal space which could easily be as much or more than the space taken up by the cabins. So if we cut that number in half we’re back to 750 passengers, similar to our initial estimate from the cruise ship.

The bottom line is that while 250 is probably a bit low, it’s not unreasonable and the actual number might be only a factor of 2 or 3 higher. So we’ll go with 250 passengers for our analysis.

A Typical Journey

The Starliner

Okay, we have our ship, it carries 250 passengers. What does a typical journey look like? For this example, we’re going say this ship makes the run between Gran Quivera in the Prenglar system and Triad in the Cassidine system, a jump of 7 light years. We’ll look at the finances later, right now we are going to just look at logistics.

We’ll start the journey at the point when the ship is all loaded and ready to depart Gran Quivera for Triad. The first step is the jump to the Cassidine system. It takes just under 4.5 days to get to jump speed and the same amount of time to slow down. We’ll assume the total travel time is 9 days. In truth it could be up to 11 days depending on the orbital dynamics of the two systems and how accurate the jump is but we’ll go with 9 days.

After docking at the station around Triad, the ship has to do a number of housekeeping activities. First, the passengers have to disembark, then the interior of the ship needs to be cleaned. And new provisions need to be taken aboard. Then the passengers and the luggage for the next trip need to board.

Since this is a HS 10 ship, it has three Class B atomic engines. These engines require an overhaul after every three jumps. Since there are three engines, it makes sense to stagger the overhauls so that you do one after each jump. You’re always doing an overhaul each time in port, but you are only doing one and that make it reasonable. We’ll also top off the fuel pellets in the engine we’re doing the overhaul on. We’ll assume that the ship has two level 4 engineers on board that work alternating shifts so that maintenance and overhaul work can proceed around the clock to be as efficient as possible.

Let’s look at time scales. If a cruise ship can load or unload it’s 2800 passengers in a single day, I think it’s safe to assume that our 250 passengers can be loaded and unloaded in a single day as well. So that requires two days in port for those two operations. Refueling one engine takes on average 7 hours. The engine overhaul takes on average 38 hours. That’s a total of 45 hours of work. Assuming it is split between the two engineers, either working together on 10 hour shifts or around the clock on alternating shifts, that takes two and a quarter days. We’ll call it three to account for any variations and potential issues that come up. The provisioning and cleaning can occur while the engine work is happening. So our ship spends 5 days in port and then is ready for the return journey to Gran Quivera. So far we’re up to 14 days.

The trip back is exactly the same. It takes 9 days to make the jump, and another 5 days in port before it’s ready to leave. That is a total round trip time of 28 days.

The Shuttle

That’s the main part of the journey. You also need some way to get the passengers from the surface of the planet up to the station to board the starliner. That means you’re going to need a shuttle. For comparison, a Boeing 737 is about the size of a HS 2 ship. And it carries 175 people and their luggage. A Boeing 747 is about the size of a HS 3 ship and it carries 416 people plus luggage.

Now the trip up to the ship isn’t that long. As the Dutch astronaut Wubbo Ockels commented about his 1985 trip on the Space Shuttle Challenger:

Space is so close: It took only eight minutes to get there and twenty to get back.

That was at 3g and we probably want to be a little gentler on our passenger but it shouldn’t take more than a half hour to get into orbit and an hour back. They will need acceleration couches regardless and those take up a bit more room than a typical airline seat but not by much. It’s completely reasonable that a HS 3 shuttle can carry the 250 passengers for our space liner.

That means that we’ll need one shuttle at each system. If we let our spaceliner carry more than the 250 passengers, we’ll need more shuttles as well.

How Many Ships Do We Need?

With one ship, every 28 days we can move 250 beings from Gran Quivera to Triad and another 250 beings in the reverse direction. If this is the only ship running the route, there will only be a single trip once a month between the worlds. If you miss your flight, you’ll have to wait 28 days for the ship to be back. And if you want a round trip then you will spend at least 5 days in the destination system assuming you fly back out immediately when the ship leaves, otherwise it will be 33 days (or longer) after you arrive before you can catch a ship back.

Of course we can increase the frequency by adding more ships on the route. Let’s say we want a flight leaving every day. That’s easy enough. It’s a 28 day round trip for a single ship, you just need 28 ships and means you have a departure and arrival every day. And that allows you to move 250×28 or 7000 beings each way between the two systems in that same 28 day time period.

Regardless of how often you have interstellar departures (as long as it’s not more than once a day), your one shuttle can supply all of those ships. So even though you have 28 starliners, you only need a single shuttle at each system to handle the passenger traffic.

But that’s not the whole story. Each of those ships needs to have annual maintenance performed and that will take on average 15-16 days per ship. Which means once a year, each ships needs to be pulled out of rotation for one cycle to have it’s maintenance done. That means we need a spare ship to fill in while it’s out of commission. If you’re running a ship every day, you’ll actually need two spare ships to cover the gaps as the repair time on 28 ships is longer than a year and there will be some times when two ships are in maintenance. The shuttle needs annual maintenance as well, but that only takes on average 8-9 days as it is a smaller ship. If you only have 1-3 flights in that 28 day period, you can get away with a single shuttle and squeeze in its maintenance between runs, otherwise, you’ll need two of them to cover the maintenance periods.

My rendition of the AD star system map. Click for full size version.

That’s the numbers for a single system. There are 17 inhabited star systems on the AD map (not counting the Zebulon system) for a total of 19 jump routes. If there is a single flight along each route, once a month, you need a starliner for each leg plus a spare. And a shuttle in each system. That’s 55 ships. Of course that ignores the fact that some of the systems have two inhabited worlds (23 in all) and you’ll need more shuttles at those worlds and some ships to move passengers between the two planets in the system.

Now 55 ships (or 67 to account for the two world systems), isn’t too bad, but that is only a single trip every 28 days. If you want a daily trip between systems, you need 30×19 starliners (570 ships) plus 2×17 shuttles for a total of 604 ships. Again, accounting for the two planet systems, that’s another 6-12 shuttles and anywhere from 6 to 168 interplanetary starliners depending on how frequent you make the trips (6 shuttles and 6 ships for once every 28 days and 12 shuttles and 168 ships for daily trips).

With the starship construction centers only capable of supporting about 1500-2300 ships, we’re now looking at about one quarter to one half of the total ship capacity of the Frontier just to connect the worlds for a few hundred people moving between each system each day.

If you want more people moving between the worlds, you have several choices. First, you can make the passenger density higher and make each ship carry more. But that’s only realisticaly a factor of 2 or 3. As another option, you can make the starliners bigger. But remember, if the average ship size increases, the total number of ships the Frontier can support goes down. The final option is to increase the number of ships that the Frontier can support.

Implications

What this all means is that you have to make a decision about interstellar travel. If you have few ships, then trips are few and far between and not a lot of people will be traveling between worlds. Your characters should expect to spend months or years on a single world with all their adventures there, as getting tickets to move between worlds could be relatively rare depending exactly on how you structure it. It also probably means they won’t have their own ship as they are too rare.

Additionally, unless there are daily (or every other day) flights between each world, then it will take a long time to travel across the Frontier with layovers of several days to weeks in each system depending on the frequency and scheduling. If they are traveling between worlds, then there will be even longer spans of time (above the already long base travel times) between adventures and your plots need to account for those long time scales.

This article was focused simply on the logistics of travel and the number of ships it would take to support that. I didn’t even address the costs and economics of each individual flight. That will be part 1b at a future date.

What are your thoughts on the number and size of passenger liners? How do you handle it in your game? What other implications have you thought of that I didn’t cover? Let me know in the comments below.

Starship Construction in the Frontier

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.

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.

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

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.

Image by Scott Mulder (this was used in my Star Clash card game.

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.

Freighter Model and Miniature

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.

Pirate Frigate Model and Miniature

It’s the second post of the month and, as is becoming somewhat of a regular feature, it’s time for a new miniature. This time around we are looking at the Pirate Frigate.

This model is another recreation of an original TSR miniature. The original Pirate Frigate was include in the Sathar Ships box of miniatures along with the Corvette and Pirate Assault Scout and the three sathar ships (frigate and light and heavy cruisers).

The Pirate Frigate completes the set of models from that box. It’s only taken me three and a half years. When I first started this 3D modeling hobby, I began by creating a sathar destroyer miniature to start to fill in the gaps in the miniature line and to make a model for the ship that I had created a full set of deck plans for. I then went on in short order to do every other ship in the Sathar Ships box except for the Pirate Frigate.

The main reason was the guns mounted on the side of the ship. At the time, I knew that the 3D printer I had access to was not able to print that fine of detail. The other reason was the finer detail itself. I was just starting out and didn’t have the skill needed (or maybe it was the patience) to actually build that model. I did try scanning the miniature with a 3D scanner we had just acquired at work, and which I was testing, in an attempt to create a model that way, but that never really worked out. It turns out that the shininess of the metal miniatures make the laser scanning beam give weird results. And so this model languished on my todo list for many years.

But now that I have a high resolution printer that can print the detail on the miniature, the wait is finally over. And after tackling the UPF ships, modeling the details on this one was actually fairly easy. I’ve gotten more confident in my skills and more willing to take a little artistic license instead of trying to make an exact copy, although this one is really close.

The Model

3D render of the pirate frigate model. It has a cylindrical fuselage with a tapered, conical nose cone and two large gun turrets sticking out from the side.

Here’s the finished model. There isn’t a lot to say about this model. Other than the guns, the shape of the model is fairly straightforward with only a few simple details added to the surface.

One bit that you can’t see from the image but is quickly apparent if you are holding the miniature is that the body of the ship is not perfectly round. Rather it is squished somewhat so that it is largest along the axis where the guns are mounted (about 8mm across) and smaller perpendicular to that (about 7mm). I modeled the ship round and then applied a scaling factor to the fuselage to squish it slightly.

The hardest part of the fuselage was actually the nose of the ship. That tapered, pointed shape at the ship’s bow is not a shape my modeling program can create natively. I can stretch out spheres, and I can make pointed cones, but that rounded cone shape is not part of the core system. There might be a library out there that someone has written that will do it, but I haven’t found one (or looked very hard).

Instead, what I did here is similar to what I did for the body of the sathar destroyer. I took an image of the original miniature and, in Inkscape, modeled the curvature of the nose by a series of short, straight lines. Once I had the shape correct, I exported the curve as a .DXF file which I could import into my modeling program (OpenSCAD) and then create the nose of the ship from that imported shape. (Using the rotate_extrude() command). I then had to scale it a bit to get it to be the right size.

The final bit of difficulty was the guns. This is what held me off from creating this model years ago. But now, armed with my calipers, rulers, magnifying glasses, and a lot more experience, I was able to make short work of the gun. It didn’t hurt that I have several of the original miniatures so I could look at all of them and use the ones in the best condition to make the measurements and understand the details. Like the fuselage, the guns are compressed slightly along the same axis but to a different extent. So they are scaled and added separately to the main fuselage.

Overall, this model took about four and a quarter hours. At least an hour of that was getting the nose cone right and remembering that I needed to use small line segments instead of a curve to define the shape.

Printing

3D printed miniature next to the original.

The image to the right shows the printed miniature next to the original metal one. I forgot to include a ruler for scale but he miniature is 53mm (2.1″) tall, tip to tail. The white residue on the printed model is from evaporated isopropyl alcohol that I use to clean the excess resin off the print. I’ve since started flushing the models with soft water before curing them and don’t have that residue any more.

The guns I created are not quite as skinny s the ones on the original metal minis but are pretty close. I could make them skinnier but don’t think it necessary.

Up Next

That completes the Sathar Ships boxed set. You can order any and all of these models on the Order Miniatures page here on the site and I will print and ship them to you. If you want just the 3D model files, they are available on my 3D Models page on DriveThruRPG. Since this model recreates an old mini, the file is just a pay-what-you-want product and can be downloaded for free if you desire.

Now that the Sathar Ships box is done, it’s time to finish the models from the Federation Ships box. The only remaining model from that box is the small freighter model. That will be the subject of my next Model and Miniature post, either late this month or, more likely, the second week in March. After that, I’ll be starting in on the ship models from the Privateer boxed set.

As always, leave your thoughts, comments, or suggestions in the comment section below.

UPF Minelayer Model and Miniature

This is not the post I had planned for this week, but since I’ve been up to my ears getting the next issue of the Frontier Explorer ready to go, I didn’t have time to do the post I had planned. You’ll probably get that one next week.

With the Assault Carriers (UPF & Sathar) completed, it was time to tackle the last of the UPF ships needed for the Second Sathar War game: the UPF Minelayer.

Now, this is a bit of an interesting ship to do the mini for. If we look at the counter from the game (shown at right), those familiar with the miniatures produced by TSR will realize that a miniature already exists with that silhouette.

This is the miniature labeled on the blister pack as the Sathar Cutter. This particular one is missing one of it’s cannons but it’s a really close match for the shape on the counter.

This isn’t the first time that TSR messed up the labeling of ship images as the counters and the “Ship Identification Guide” in the Tactical Operations Manual don’t match up. We can probably assume that they had this miniatures and its silhouette and since the cutter doesn’t have game stats (until fans created them – see Frontier Explorer issue 2 – Friend or Foe), they used the image for the UPF Minelayer but didn’t change the name on the blister pack. In the blister pack, it is sold with the Sathar Frigate so my guess is that it was supposed to be a sathar ship but the silhouette was used for the UPF Minelayer by accident.

In any case, it poses a bit of dilemma. We need to make a ship that at least sort of looks like the counter to continue with the theme of the miniatures I’ve been creating but it also can’t look exactly like the sathar ship. This is also why I saved this miniature for last as you could always use the Sathar Cutter mini as the UPF minelayer in your game as it matches the game counter. So with that background out of the way, let’s look at the ship.

UPF Minelayer Miniature

Since I’m not planning on matching the shape of the silhouette on the counter exactly, I want to look at the broad features of the silhouette for inspiration. In my mind there are four main features to be considered:

The body should be somewhat roundish and elongated
There should be two side lobes off the main body
There should be two guns mounted forward on the main body
The engines should be long and skinny.

Now that last one doesn’t match with any of the engines on any of the other UPF ships. However, I’ve always felt that the minelayer, unlike the mainline ships, used ion engines instead of atomic engines. It’s really more of a system ship that does its work before the battle starts so it doesn’t need the performance of the main warships.

And the game stats bear this idea out. Ion engines are limited to an ADF of 1 and that is what the minelayer has, unlike all the other ships which have an ADF of at least 2. So these long skinny engines can be the UPF ion engines instead of atomic ones.

The two guns really aren’t an issue either as the minelayer sports a pair of laser batteries in addition to the mine and seeker missile dispensers. And the other features are just things to keep in mind while designing the ship. The minelayer is listed as hull size 7, so in the end, the ship should be a bit bigger than the UPF Destroyer when it is all done. With those design constraints, let’s get to work.

The image to the right shows the finished model. Instead of the smooth rounded body of the Sathar Cutter, I chose to go with a more angular squashed cylinder and then add cylindrical lobes to the side somewhat like the UPF Assault Carrier.

The two laser batteries are mounted on the front of the ship and the engines are long, tapered to the back, and, although you can’t easily see it in this image, angled slightly inward at the back as are the engines on the silhouette.

Beyond that I added some surface features reminiscent of the other UPF vessels and then a bunch of small cylindrical indentations on the back of the fuselage to represent the mine dispersal system. In the model, they are all at different angles so that mines are spread out as they are ejected.

Printing the Miniature

With the model made, it was time to print. Since this is a relatively small miniature, the print only took about 5 hours. Here is the UPF Minelayer next to the sathar cutter and UPF frigate, as well as a ruler for scale.

The engines didn’t come out as straight as I’d like. I’ll need to add some more supports to them on future prints to get them to hold the right positions.

As you can see, the ship is a bit bigger than the cutter and the body is bigger than the main part of the frigate as well. It’s also bigger than the destroyer although I don’t have a picture of that one. While it’s not as long, it is about as thick and much wider so I feel that it came in at right about the correct size to be just a bit bigger than the frigate and the destroyer.

This model just about used up all of my grey resin so I’ll probably be printing in the black or white resins until I get some more grey ordered. The grey (and white) take longer to print as they are opaque resins and need more curing time but I definitely like the look of the grey miniatures. At least they photograph better than any of the others.

Up Next

I finished this model a couple of weeks ago so my Patreon supporters already have the model file. I’ll be posting it on DriveThruRPG shortly with all the other models on my 3D Models page. I’ve also added it to the Miniatures Price List here on the site.

That completes all the UPF and Sathar ships. I’m probably going to revisit the fighters soon as I need to make those models more friendly to FDM printers. The models I created work on an SLA printer but the wings are too thin (by about a factor of 5-10) to print on a regular FDM printer. I want to make the models easier to print on FDM printers (or at least versions that are) before I post those models on DriveThruRPG.

But before I do that, I’m going to tackle the last military vessel that I haven’t reproduced from the original miniature sets, the pirate frigate. That’s a ship that came in the Sathar ships box of miniatures along with the pirate assault scout which I have already reproduced. I’ve already started on the model, so once I get issue 27 of the Frontier Explorer out the door, I’ll get back to it.

Once the pirate frigate model is complete, I’ll be in a position to start offering “module packs” of printed miniatures that contain all the ships needed for the Knight Hawks scenarios from the various modules as well as the UPF Task Forces. I may need to make a few more models for some of those (the Gullwind and Elanor Moraes come immediately to mind) but that will give me some direction for future builds.

After the pirate frigate, there are just 7 ships from the original sets left to recreate: the freighter from the Federation Ships box and the six ships from the Privateers box. Those will be my next projects, interspersed with the models needed for the module packs, after reworking the fighters.

What are your thoughts on the minelayer model? Let me know in the comment section below.

Sathar Assault Carrier Model and Miniature

With the UPF Assault Carrier completed, it was time to tackle the Sathar Assault Carrier. This would complete all of the capital ships for both sides.

Now, way back when I started this blog, I posted the outline for a sathar assault carrier project. This is not the model that project was intended to create. When I made that project outline, I never imagined I’d be this heavy into creating miniatures. Although if I ever get around to actually doing that project, the end result might be fairly similar. One major difference, however, would be that all the surface features would be actual scale rather than selected for aesthetics as they are on this model. But that’s for some undetermined future date. Let’s look at the model I have created.

Building the Model

Like the others, for this model I’m working off the silhouette from the game counter, pictured to the right. As you can see, this ship is a bit more bulky and angular than the other sathar vessels which tend to be more bulbous and curvy.

That said, there are definitely some features that fit the typical sathar ship style. We have the long skinny engines with the spherical tip, long, extended nacelles for the engines struts, and a round head separated from the body by a skinny neck. The other features that stand out are the guns on the head of the ship and the rectangular shape of the lobes on the side of the ship. I’m going to assume that the latter are the location of the bays for the fighters.

image showing a small assault carrier being approached by an assault scout and exploration vessel

Now, there is another reference for the sathar assault carrier in the rules. The image to the left comes from the module SFKH3: Face of the Enemy. This ship (bottom) is described as an older, obsolete, and smaller assault carrier no longer in main-line service by the sathar fleet. In the module, it has been converted by the sathar to serve as a mobile base for larger scout craft instead of fighter craft. So while I will probably model this ship at some time in the future, I won’t be using this image as a reference for the assault carrier model.

Like the UPF assault carrier, the sathar assault carrier should be significantly larger than the light cruiser but not quite as big as the heavy cruiser. That gave me a bit of a scale to shoot for when building the model. Once that scale was decided on, I used the counter to get the rough shape of the head and body of the ship.

Here’s the final model (pictured to the right). The size of the body, neck, and head are taken directly from the dimensions on the counter.

Given the positioning of the guns on the counter, I assumed there were three evenly spaced around the head. Since the stats for the Assault Carrier include a laser battery, a rocket battery, and a proton battery, I figured that wasn’t too much of a stretch.

The size and shape of the rectangular lobes around the center of the ship are based on the counter as well. The height of the lobes from the center of the ship match the profile height from the counter and the size of the rectangle that forms the outer face, along with the width where it intersects the hull match as well. What is different is the detail on the face. The counter shows one large rectangular shaped detail that I decided to break into three smaller ones on each lobe. each of these represent a fighter bay giving the assault carrier the capacity (per the rules) to hold up to a dozen fighters.

The other major difference is the engines. Instead of the single, long engine depicted on the counter, I went with pairs of smaller engines, similar to the ones used on the heavy cruiser. Unlike the heavy cruiser, which mounted the two engines in each cluster in-line with the engine strut, for the assault carrier, I chose to mount them perpendicular to the engine strut. Additionally, these engines are slightly shorter, a bit thicker, and have a bit more spacing between them than the ones on the heavy cruiser. Otherwise, they are similar to the heavy cruiser engines and modeled on those engines.

It’s not obvious from the image of the model, which is the intention, but I started using a slightly different technique when modeling this ship. For all the ships in the past, I’ve set a global level of detail for round objects that was fine enough for the larger bits of the ships to look smooth. This resulted in way more detail on small objects (like the spheres around the upper body) than was needed and caused the rendering time of the model to be really long. Starting with this model, I’ve been specifying the detail at the individual part level, allowing me finer control and reducing the rendering time significantly since I don’t have to put as much detail into the smaller pieces.

Printing

With the model done, it was time to print the miniature. As it turns out, this model is fairly massive. In fact, physically, it has more volume than any of the models I’ve created to date, even the UPF assault carrier. Here’s a picture of the sathar assault carrier along with the sathar heavy cruiser and light cruiser (and a quarter for scale).

The light cruiser looks kind of glowy because it was printed in a translucent resin and this particular print was hollow so the translucency really shows.

It sits right in there between the light and heavy cruiser but it is much fatter. It ended up weighing a couple of ounces, compared the ~1 ounce for the heavy cruiser and ~1/2 ounce for the light cruiser. It actually has some heft to it. I may consider printing these slightly hollow to save weight and bring the cost down. Here’s another picture with it next to the UPF assault carrier.

The two assault carriers side by side. One of the features chipped off of the aft fuselage of the sathar ship when I was trimming off the printing supports attached to it. I don’t think those supports are actually necessary and will remove them next time I print one.

As you can see, it ended up being a bit bigger even though they are supposed to be roughly the same sized ships. I probably made the sathar one a bit too big, but I like the way it turned out so I’m going to leave it be. It’s not too out of proportion to the other sathar vessels. Any downsizing I need to do will come with the next round of ships, which I’ll be designing to all be to scale with one another. However, with it being this massive, it makes sense that one of the sathar conditions for retreat in the Second Sathar War game is the loss of too many of these ships.

Up Next

That’s it for the Sathar Assault Carrier. I’ll be adding it and the UPF Assault Carrier to the Miniatures Price Table here on the site as well as uploading the model files to my 3D models page on DriveThruRPG. My Patreon supporters received the model files for both of these ships a while ago.

The next ship I’ll be tackling will be a new model for the UPF Minelayer. That may be ready by the end of the month.

Let me know what you think about the Sathar Assault Carrier in the comments below.

Other Posts

Void Jumping

ADF and the Board Game Rules

How I Apply This In Game

Basic Application

Traversing multiple systems in a single trip

Final Thoughts

The HSS History’s Hope

History of History’s Hope

Modifications

Full Ship’s Stats

The Journey So Far

Crew

The Journey

What Does the Future Hold?

Final Thoughts

The “Problem”

Short Staffed

More Ships?

Smaller Population?

Undesirable positions?

Crew Mutinies

Final Thoughts

Our Ship

Hull and Engines

Cabins

Crew

Ship Vehicles

Spacesuits

Robots

Other items

PGCSS Prenglar Glory

The Ship’s Crew

The Economics

Income

Expenses

Paying for the ship

Some Variations

Conclusions

From the Rules

How Many Passengers – revisited

A Typical Journey

The Starliner

The Shuttle

How Many Ships Do We Need?

Implications

The Baseline

Supporting More Ships

Double the Number of SCCs

Planetary Small Ship SCCs

Reducing Maintenance

Conclusions

What’s Next?

The Model

Printing

Up Next

The Model

Printing

Up Next

UPF Minelayer Miniature

Printing the Miniature

Up Next

Building the Model

Printing

Up Next