Update (5/5/23, 3:15pm EST): a hotfix for a crash when viewing the Gilead shrine intel after visiting the shrine; please re-download the game using the links below.

Starsector version 0.96a is now out!

• Take on new missions exploring the story of the Luddic Church and the Sindrian Diktat
• Cut deals Warlord Kanta’s pirates or Luddic Path fanatics to stop their attacks… though peace may come at a high price
• Fly new ships, including 5 new capital-class hulls and numerous smaller vessels
• Acquire new weapons, including a lineup of missiles that shoot lasers (“Directed Energy Munitions”)
• Face faction fleets with distinct identities driven by the new ships and weapons
• Deal with hostile activity at your colonies and master hyperspace navigation using the new “Event” system
• Build hullmods into ships to gain unique bonuses
• Additional illustrations, portraits, descriptions and encounters help bring the Sector to life

In addition to these, there are a slew of smaller changes and addition, including balance adjustments, bugfixes, modability improvements – along with a new exploration music track, and faction music for the Persean League!

The full patch notes, and the comment thread, are here.

You can download the new version here:

(Alternate download links, please try the above first: Windows Mac Linux)

As always, thank you so much for your support!

I’d like to take a moment to talk about the development of narratives in the last update, and maybe in the game in general. I should note: this is a process post, not a lore-dump. So this is about how I went about coming up with these ideas and implementing them, not what Baikal Daud’s favorite flavor of ice cream is. More on anti-lore later. But yeah, I’m dying to talk about all of this but I have to play it fairly close to my chest to avoid spoiling what we’ve got in mind for the long game.

Two things first.

1. As anyone who’s written creative fiction knows, it’s terrifying to work on something for over a year and then show it off to who-knows how many thousands of people all at once. Especially in a field you’re not really ‘proven’ in (though, uh, arguably this feeling was far more pronounced with the introduction of the Galatia missions. There, yes, I was legitimately freaking out a bit. This time, much more confident and comfortable.

… Nonetheless, not everyone is going to like what you do. But I’ve been in games for, what, almost 15 years? And shipped at least one trainwreck. C’est la Vie! Regardless: You’ve all been very kind.

2. And: I know you guys want narrative payoff for the hanging plot threads at the end of Galatia, for the Gates, and now for the fate of the Church and Askonia. And I want to give them to you! But we have to do it when we have the mechanics in place to do it right. I know that sucks to hear, but I think playing the long-game will pay off. (- I think the narrative slow-burn that eg. Andor did was really, really smart because the payoff was fantastic. I have no idea how Disney executives approved that show and let them get away with what they did.)

Oh yeah, this is going to have spoilers for v0.96 story missions. You’ve been warned!

Passage to Volturn

Yes, this is an easter egg. Disney, don’t read this.

Will it tie into anything else? Maybe a little, I dunno. It’s important to leave yourself narrative opportunities that can be picked up later, or not. You can see this in lots of good serialized media, whether games or TV. (Is Andy Serkis coming back to Andor? He could, or could not. They left themselves an opportunity; very smart. At its worst, however, this teasing turns into plots that are all hook and no payoff; they end up feeling like there was no plan at all. Like, oh, Lost? And any number of JJ Abrams productions; ahem.)

Jethro, the Knight Errant

This mission wasn’t in the plan. I had intended to just introduce the character of Jethro at the end of the Shrines mission and leave him be as someone connected to Jaspis.

But then I had An Idea inspired by a movie which I won’t name (because it’d be a spoiler for where I think he could end up)(and.. isn’t even really in the content of the mission at all, except for some vibes. So don’t bother guessing). Right, so: I had to pivot the character introduction into its own whole mission sequence. At first, it was just “go to Chalcedon and pick up Jethro”. But then I had another idea inspired by another movie.

Run the clip: Lawrence of Arabia meets Sherif Ali

(Man, a whole minute of watching a camel walk toward the scene! Build-up! What a great movie.)

This is totally where I got the vibes of Sedge’s introduction. I mean, Omar Sharif’s character is actually nothing like Sedge, but it’s all in that first impression he makes on Lawrence – and the viewer.

Moving along, there’s a pretty obvious set-up with Jaspis to do something like with Baird in the “I need a hammer” dialog. When I was writing that, originally, it was the player character who was to be the “hammer”. But then I was like no, that sucks. We already did this exact same thing with Baird and we have enough old ladies bossing the player around while telling them they’re important for changing the course of history blah blah blah.

I cannot express enough how much I loathe power fantasies played straight. They’re so boring; they suck; you can get that tripe from any stupid game. So: Jaspis doesn’t think you’re The One at all – she thinks it’s Jethro. Except he doesn’t agree!

‘Course it all makes a lot more sense if he gets to do something cool after all of this setup, and we’re not there yet, are we. And maybe it doesn’t happen – it’s a plot thread, where it ends could be different from what I intended a year ago; and I should be open to the player radically affecting that outcome. (Because now that there are a bunch of different missions in the game, they don’t have to play as ‘safe’ as Galatia did – it should be possible to lock yourself out of opportunities by making decisions which change the course of a character – and the fate of the Sector.

You can just straight-up murder Sedge. This was me being like, well, why not? Let’s show the player we’re willing to cut a narrative thread once in a while. (This can get very expensive in terms of development time if you have to plot out a situation like “what if the player shoots Baird – but still wants the Gates mission to happen?” – like, yeah, something plausible could be concocted, but it’s a ton of work that is, besides, retreading old narrative ground. Would it be good for the game? Maybe not.)

… And I mean, we’re still doing the power fantasy. But pretending not to? At least?)

One more comment: it was observed to me that the Luddic Church is medieval. That is, as an institution, it fills in a lot more space in its society than we are used to thinking about for a/the Church in our contemporary societies. This made a lot of it click, for me. (And makes it quite clear that I’m halfway to writing a medieval-fantasy adventure when we’re in the realm of the Church; it’s a fun mood to hit with care and deliberation within the space of, well, a space scifi game.)

Sentinel/PK

Alex left a TODO for me while I was working on Shrines, and I didn’t really process it and just said something to the effect of “Yeah, yeah, leave some notes in the Rules file and I’ll fill in the text when I have time”. Then – lots of time later – I’d wrapped up Shrines and Usurpers and was feeling very good about myself. I thought I’d just knock out the rest of my TODO list real quick and actually looked at what I needed to do and discovered just how deep this content went.

Ohhh noooo, this is an actual whole story? ALEX!!!

Anyway, it’s fine. I’m fine. How are you?

There was a first take with Sentinel that was like three paragraphs and no choices, no unique art or characters. I recall Alex saying “this feels underbaked?”. So I said, “Alright Mosolov, if that’s how you want to play, I’m going to make this WEIRD.

So I did. And even then, I had to hold myself back because you could write a whole novel about Sentinel and not be finished. (And why, I ask myself, should it be so compelling? I think it’s due to all the build-up and investment we’ve done in laying out the setting background. What does the Hegemony mean, what did the XIVth mean, what does AI mean, and the AI Wars, and how do the stories people tell themselves change over time? And what happens when isolated threads of self-told stories from the same source run into each other?

Not that we got too deep into that, but the potential is there; and it makes me excited to poke at those possibilities. (Lots of plot hooks!)

The Usurpers

The whole setting of Askonia is the first thing I wrote when Alex asked me to take on some writing duties for Starsector in, IIRC, 2014. My notes date back to then, at least, and the broad strokes haven’t changed a bit. The three “usurpers” didn’t exist as named characters, but the broad factions/themes they represented in a conflict over the fate of the Diktat did exist. I thought the mix of historical allegories was pretty obvious, though I tried to mix them up a bit. I’m not going to talk about that here.

Andrada: I realized pretty early on that he can’t be a character in this game (and players arguing over how much of a genius he is or isn’t makes this all the more clear to me). His character is more interesting as an idea that lives in everyone elses’ head rather than a character on his own. His whole point is the legend built up around him, and how he, then other people, use it to their own advantage.

With that thought in mind, let me offer a perspective: have you ever been in a toxic work environment with variously insane managers/executives who are under tons of pressure? Just extend those dynamics a bit and that’s all you need to get this story.

Similarly, have you ever witnessed someone who is very good at their job – or considered good at their job – massively mess up doing that job? It sure happens all the time, and happens throughout history, and I think examining the dynamics that surround massive failure and its fallout are absolutely fascinating.

Macario

Now what you’ve really wanted me to talk about is probably Dolos Macario, right?

The core inspiration will probably be really obvious once you know it, but first: I wanted this character to be an absolute scumbag; totally evil, untrustworthy, a villain. He’s running the fascist secret police, he’s a bad dude. At the same time, it isn’t fun to write that. It can get really brutal and grimdark, and while I think that’s artistically legitimate, it’s not where I want to put my headspace while writing for this game.

(And heck, maybe the character shouldn’t be fun. I worry about this.)

At the risk of invoking a piece of media that Did It Better, here’s Hans Landa from Inglorious Basterds.

(And what an amazing scene; describe it on paper and it seems so simple, but it is so tense and every shot so intentional. Brilliant work; Christoph Waltz has irresistible charisma.)

— Anyway, Macario isn’t Landa, but I wanted the sense of a weird, evil guy who is having fun in his weird, evil job.

(And with apologies, I did base his portrait in part on George Orwell for a sense of totalitarian irony.)

Kanta & Cydonia

Speaking of evil, Kanta and Cydonia are fun to write. Not particularly political, just off-the-wall over-the-top space opera inhumanity. What whacky hijinks will they get up to next? It could be basically anything!

(And come to think of it, I think these two characters are pretty much lifted wholesale out of Alastair Reynolds’ novel Absolution Gap. Read the starting bit with Queen Jasmina and Grelier and a touch of Quaiche, and that’s basically them; oops. Major props to Reynolds for how he writes weird doctor characters; I swear, every book he does, there’s going to be a weird doctor. We love his weird doctors.)

Come to think of it even more, the medieval church scifi setting vibes probably owe quite a bit to this novel as well (to say nothing of Hyperion et al). Say what you will about the plot making sense in the grand scheme of things; who cares, the weird vibes are off-the-charts.

To bring this all back around, it feels like giving the Church and Diktat a bit more depth worked out pretty well, and we’ve got a bunch more interesting characters to play with. I’m happy with that. (I know the League needs some love, but we’ll get there when we get there.)

Both Alex and I are eager to bring some… explosive? … conclusions to the various narrative threads we’ve been building up over the years and we’re going to work very hard to make sure they hit like a Hammer when they hit.

Comment thread here.

(PS. Didn’t have a place for it in the post, but I’d totally cast Shohreh Aghdashloo aka Chrisjen Avasarala in The Expanse as Baird.)

Let’s talk about the options the player has for moving around the Sector! For a long time, the set of movement mechanics has been incomplete, with additions made here and there (slipstreams, unlocking the use of the Gates), but still lacking some of the options that in my mind would make up the final picture. Perhaps “final” isn’t the right word – things will certainly be tweaked as necessary – but it’s about having a more complete set to tweak, rather than what has been, until now, a partial implementation.

The overall goal is to … well, of course it’s to make moving around the Sector more fun, though that’s a given and doesn’t actually say much. In practical terms, this means giving the player more options, and making those the kind of options that ask the player to make some decisions.

Let’s start with a quick recap of the current movement mechanics.

Just Flying There. Yep, that’s the basic one; terrain factors in here, as does fuel use. Can be a bit of a slog for longer trips, and this is the baseline we’d like other mechanics to play off of. It’s important to keep some of it, though, if only for contrast with the other mechanics. If the player could instantly teleport anywhere, all sense of scale would be gone.

Slipstreams. Very fuel efficient and fast – if you’re lucky enough to find one going in the right direction, which you’re often not. Also function as an obstacle if they’re going across your path; not their main goal but anything that gives the topology of hyperspace more meaning is a positive. Easy to cross with an Emergency Burn, but that has a cost. As of the previous release, there are new options for detecting slipstreams in a wider area (around your colonies, or near sensor arrays), making it more likely you’d be in position to use one.

Activating the Gate system. Allows instant travel between systems that have gates, which is a fairly small fraction, but they’re well spread out. Fairly fuel efficient, but still does have a hefty fuel cost – it’s just low enough that you’re not tempted to fly there instead. The gates become usable later in a campaign; I think it’s nice to have some of the travel-related options become available over time, so there’s a feeling of progress and the relative freedom of movement by the end feels more satisfying.

With this in mind, let’s dive into the new stuff!

Reverse Polarity
This is a new toggle ability that makes your fleet go in the opposite direction when inside slipstreams, a little slower than usual. It’s unlocked by progress in the Hyperspace Topography “event” – scanning  various interesting stellar phenomena and the like.

The main point here is pretty simple – having this ability doubles the odds that a slipstream is useful, making them very good indeed. With the fuel cost reduction of slipstreams, even one going vaguely in the direction you want is going to be handy.

The design process was not without its difficulties, though. One immediate consequence of the initial design was that slipstreams stopped being an obstacle; this is undesirable both because it makes the topography more same-y (i.e. slipstreams cease to matter as obstacles), and because it steps on the toes of Emergency Burn, making that ability less useful.

For clarity, the process for slipstream-crossing would be to 1) start the crossing and 2) reverse polarity midway through and be carried back to where you started by the time you finish going across.

I tried several things to deal with this. The first was making the ability take some time to activate; this doesn’t work because it can be timed correctly anyway, and it also makes the ability feel less responsive. Another idea was giving it an activation cost – that certain solves the “too easy to cross” problem, but introduces an annoying calculation for travel – is it worth the cost? Ideally we’d just want it to be clearly useful if it’ll let you go in the direction you want, without needing to worry about costs.

The eventual solution was to keep it as a toggle ability, and to give it a cost for both activating and deactivating, but *only when already inside a slipstream*. So if you want to travel along a stream, just activate it before you dive in, and it’s free. If you change your mind midway through, then it has a cost, so it’s not as appealing of an option. This makes a lot of in-fiction sense, too; one can imagine that messing with the drive field’s polarity while already in a high-velocity slipstream is a more difficult proposition. And the ability has a low cooldown and activation time, nice and responsive – all of the design goals are met!

To make sure you can tell whether it’s on or off without looking at the ability bar, when its on, your fleet’s engine flows and trails are shifted towards purple – the color commonly used by the game to indicate that some kind of high-tech shenanigans are going on.

In the context of asking the player to make decisions, whether to use this ability or not isn’t much of one – if you want to use a slipstream going against its current then yes, otherwise no. Rather, the decision is about whether a particular slipstream will be beneficial to you, and this is a factor that makes this decision more interesting – and, importantly, makes the answer be “yes” much more frequently.

Generate Slipsurge
I have to admit, one of the first things I did after implementing slipstreams is try making short and really, really, really powerful ones. No, more powerful than that. It’s just what you do! You add a new mechanic, and then you crank it up to eleven… thousand or so, just to see what happens. In this case, the answer was “it’ll shoot your fleet out like a bullet”. Fun, but clearly something that breaks various game rules so badly would be an irresponsible thing to add to the game. Right? Weeeeell, yes and no. Or rather: yes, but also no, we’re doing it.

Enter the “Generate Slipsurge” ability – you guessed it, it generates a short and really, really (etc) powerful slipstream. Also unlocked by increasing Hyperspace Topography progress, it only works in hyperspace, and requires a nearby gravity well – for example, a star or a gas giant. The slipsurge points away from the well, and its power depends on the object that’s at the bottom of that well. This accomplishes a couple of things:

1. The question of “how do you aim the surge” is solved. The game doesn’t generally support a “use a campaign ability then select a target for it” type of interaction. Not that it couldn’t but it seems like that could get really fiddly, and now we don’t need to worry about it.
2. The layout of stars on the map now matters for movement. For example, you might identify a series of black holes about the right distance apart for you to be able to chain together slipsurges for a faster journey.

So how *is* slipsurge strength determined? An obvious answer would be for more massive objects to generate stronger surges. That makes a ton of sense, and we’ll stick to that – but only kind of. The emphasis has to be on making it clear to the player what to expect, and actual star/black hole masses and so on are quite messy. A star in one class can mass more or less than the star in another, or indeed more than a black hole. It’s a mess! Rude of nature to be so inconsistent, really.

So instead of an approach grounded in science, we’ll go for one grounded in truthiness – what feels right. Unless you’re an astronomer; in which case my apologies. As a nod to science, the game does say that the surge strength depends on the object’s “mass, density, and other poorly understood factors”, so at least it’s not claiming that it’s based on just mass. The ranking is, roughly:

• Black holes, neutron stars
• Supergiant stars
• Giants stars
• “Regular” stars (i.e. not one of the other types)
• Dwarf stars
• Gas giants

This feels like something that’s pretty easy to internalize, hopefully you won’t need to keep checking the tooltip for too long.

A few other points that came up while implementing this:

It felt pretty strange for the fleet to be going this fast (up to burn level 900+, where the normal maximum is 20) if it had its selection circle showing. I think it’s because the circle makes the fleet feel a bit like a UI element, and it just felt like the UI going wild. The solution was to 1) fade the selection circle out during this fast movement, and 2) to add a shimmering/jittering effect to the ships, with a bit of a trail, to really sell the feeling of speed and power. A sound effect to help this along is also in the works.

It’d be nice to be able to control the distance you travel, at least a little – so, using the “go slow” control (default: S) will very rapidly slow the fleet down. It’s not fine-grained by any means, since you can travel up to 15 light years in just a few seconds, but it can make a difference of a few light-years to how on-target you are.

Your fleet can’t be interacted with during this transit – i.e. if you fly through a pirate fleet, you won’t all of a sudden end up in a fight while ostensibly going at 900 burn. Your fleet’s sensor range is also reduced; not a big deal, but that feels right.

Traveling fast in hyperspace grants you points in the “Hyperspace Topography” event (mentioned earlier in the post), and what would happen is you’d get the notification about gaining those points while mid-transit. It really ruined the moment – here’s something cool happening, and then game chimes in with a “you gained some points!!!” notification. No good. So: the notification won’t happen during transit, and is delayed until a few seconds after it’s over.

And, finally, hyperspace storms – hyperspace is pretty big, and for performance reasons, the game only simulates storms in the area around the player. But when the player breaks expectations and travels faster then the game assumed was possible – you’d see the point where the storms end pretty clearly, and you’d see them slowly start to wind up. To fix this, when the ability is activated, the game will – for a few seconds – fast-forward the storm simulation in a larger radius.

As you can see, there’s quite a bit going on under the hood to try to make something like this work cleanly!

Ability slots
With two new abilities, there’s a bit of a problem – the set of abilities the player is generally expected to have no longer fits on one ability bar. On the one hand, that’s why there are multiple ability bars. On the other hand, switching between bars can be a pain, and these new abilities are only useable in hyperspace, so it seems like there’s room to make improvements.

So: the idea is that for each slot, you can configure it to switch to a different ability when the fleet is in hyperspace. “Scavenge” and “Distress Call” are good candidates to do this with, since they are only useful in normal space. To streamline the process, when you unlock the new abilities, “Reverse Polarity” is automatically slotted as the hyperspace alternate for “Scavenge”, and “Generate Slipsurge” is slotted in as the alternate for “Distress Call”. This also makes sure that new players, who might not be super aware of how slotting abilities works in the first place, benefit from the feature.

If we added more abilities down the line, there’d still be a problem, though. I’m considering whether to bring back the default keybindings of Q and W for the first two ability bars – it makes switching between them an absolute breeze. The problem with this was that some players would hit Q or W by accident, end up with an empty ability bar (especially fun during in the tutorial), and be confused. So the question is exactly how to handle this; the concept of switching bars needs to be introduced at some point.

Perhaps a tutorial note for it would be enough. Or perhaps a “hey, you’re on the second bar and it’s empty, here’s what happened” help popup would do the trick. Either way, this seems like a solvable problem, but definitely something to watch out for.

Wormholes
There will be some spoilers from this section onward. I’ll try to keep them light, but: be warned!

The goal here is to let the player connect any two points in the Sector – it’s very powerful bit of customization for the playthrough, but limiting the number of wormholes helps keep the other  travel options relevant.

The way it works is there are two “Wormhole Anchor” items to be found. They can each be deployed at a stable location, to create a “Wormhole Terminus”; the anchor can be retrieved from the terminus at any time, closing it. Visually, the wormhole is like a larger, more intense jump-point.

When first deployed, the wormhole is unstable and unusable for an in-game year – otherwise, the optimal way to go about it would be to deploy one anchor at a colony, and carry the other one around with you, using it as a town portal scroll, and making all of the other travel mechanics fairly obsolete. The point of these is to make a fairly static bridge, not something dynamic.

Using the wormhole requires a “Wormhole Scanner” item. Primarily, this is to explain why these are only used by the player’s fleet. If other fleets can use them, they become potentially very disruptive to the Sector’s status quo in ways it would feel strange not to at least acknowledge. Not that it’s necessarily a bad idea (it might or might not be), but more importantly it’s very much not the point of this addition, and the resulting implications spiral out quickly in terms of the extra work required. Thus: wormhole scanner.

While there are only two wormhole anchors in vanilla, under the hood, the game supports a larger number of these, potentially in separate networks – that was not very complicated to code, and I figured it might be useful for a mod.

Gates
And, finally, the player will have the ability to put a gate into a system of their choosing. To do this, they’ll need to [COMSEC REDACTED, AGENTS DISPATCHED].

Abyssal hyperspace
This is technically not directly related to the new movement mechanics, so why talk about it here? Well, it’s sort of related (for reasons best avoided due to spoilers) and also I think it’s neat and want to talk about it.

So! You might have noticed the “Orion-Perseus Abyss” label in the lower left corner of the Sector map; it’s been there for a *long* time. Now, finally, it’s more than just a label – the area in the lower left corner of the map is “abyssal” hyperspace. Which means what, exactly?

Movement is 4x slower, and sensor/detection ranges are reduced by a like amount – basically, it’s as if the area was 4x larger, without it actually being that. Utilizing the map space more efficiently!

It’s very, very dark. As you get deeper into the abyss, the background fades out, and so do the other things you might normally see such as the deep hyperspace clouds outside it.

Gravity wells and jump-points are only visible at close range, though star gravity wells are visible as normal – you can see them on the map, anyway.

Other fleets mostly try to avoid it.

There are things inside.

Also, there is now abyssal hyperspace all around the Sector, beyond the edges of the map. It isn’t necessarily canon that the Sector is surrounded by abyssal hyperspace – the Abyss is canon, of course, but the rest of it is just a more satisfying way of having a map border. Or perhaps more than that? We’ll see. This is pretty clearly an area that could have a lot more content added to it.

Comment thread here.

For the most part – for almost the entire part – I have been working on new game content since the last update. Talking about it in detail is 100% spoilers, and while I do believe there’s an interesting blog series to write about the overall strategy of narrative design in Starsector during a long development cycle, properly contextualizing it… well, that’d be spoilers.

What else to write about, then? Man, I dunno – but then I had a discussion with Alex about creating an illustration to go with the content I was working on and decided to show him all of my sketches leading up to the final composition. “This could be a blog post, couldn’t it,” I said.

So, hello. This is a digital painting blog post. I’ll show you my process and attempt to explain in hindsight why I made certain decisions. And, to come clean, this is only partially motivated by my desire to insert fan art for Alastair Reynold’s Revenger series into Starsector. (More of it, anyway.)

Earlier this week I created a mission which involves having the player fly out into the fringe of the Persean Sector to dig around in some ruins. There is indeed a Galatia Academy mission which does this very activity, but I assure you that this new mission does it slightly differently! And thinking about these two missions, I was struck by a notion: why not draw some Revenger fan art why not do an illustration of a salvage team finding loot in creepy ruins which could be used for both missions? This situation comes up fairly often in Starsector anyway, and I never really did previously create an appropriate illustration for this sort of thing. Great!

My mind immediately goes to the sequence in Alien where the crew of the Nostromo investigates a derelict ship on LV-426. That era of science fiction movie art production is a huge inspiration to my take on the Starsector aesthetic, as I’ve written about before somewhere on here at some point.

Here’s the shot:

Fantastic! Love the suit silhouettes, the texture, the grim lighting. It’s a bit too organic and boney for what I’m going for, but it feels like a good starting place in terms of setting the mood.

First take:

Yeah, okay. Vertical columns for a temple-like appearance but done in scifi-brutalism. Dark vertical shadows, silhouettes, bright spots of light. Cold environment vs. warm points where the “treasure” can probably be found. It’s not landing for me though; the image both doesn’t feel oppressive enough and doesn’t emphasize the characters enough.

Second take:

No, not feeling it. Feels too much like medieval ruins with those stairs and the lack of verticality. There’s way too much focus on the little salvage vehicle thing – this image should not be about that, not at all. We’re going to have to do a radical revision.

Third take:

I actually quite like this one. Alex commented that you should be able to see someone’s face, and I agree – probably the largest figure primarily, with dramatic underlighting. It’s a very “opening the treasure chest” scene with a warm focus and cool light coming from the environment and a spot from above.

However. This still doesn’t feel right. I might roll this off into its own illustration because I quite like it, but this wasn’t doesn’t feel like it’s hitting what I wanted to go for. It’s too focused on the characters, it doesn’t feel cold and oppressive enough, it doesn’t give you any sense of diving into and exploring huge, dead structures.

Fourth take:

Better.

Same basic setup, but pulled back from the characters. Rows of caskets of some kind are bathed in cool, dim light; “This place is a tomb.” Focus is off-center. We get a dynamic between the lighted hallway in the back – the way in, the way out – and our salvage team reaching into the “treasure chest”.

It’s almost there, but not quite. It doesn’t feel big enough. The space needs to open up – we need those vertical columns so that this tomb can feel more like a dead temple.

Squished the drawing down and added some background and, yes, that’s it! That’s our composition!

I noticed, also, that this happens to fit rather well into the rule of thirds. I wasn’t even thinking about it.

If it works, it works.

(You’ll notice that I did not do a line drawing at any point in this process. This is a painting, after all, and what’s important is to find out where masses of colour and tone go, how their shapes interact and fit into the whole. I figure you need to start the process by thinking about what the end should look like if you squint a bit.)

Anyway, now that I’ve got a composition in mind, let’s draw the rest of the owl.

I start by touching up the shapes of the figures so they’re not cosmic horror blobs, then adding a first pass of intermediate detail throughout. Added some figures in the back for scale [by the end, I do reduce their size a bit] to show that they’re bringing something in or taking something out; this creates a little narrative suggestion for how the foreground figures got there and where they’ll be going next.

(Of course, this could work just as well without the background figures and I’m tempted to cheese up a quick version that doesn’t include them. Check at the end of the post for that.)

The lighting starts getting a little attention so I know what colour various areas are supposed to be, and where to draw dramatic shadows.

Then, more focusing on the figures, their accoutrement, the little crates and cables they might bring along to do general salvage work. Laid out a few more points of light, particularly helmets and suit-mounted light sources.

Most of the detailing focus goes to the left side and foreground.

Stepping back, I realize I needed to add details to the right side and the background to bring it up to speed, so that came next. In particular I needed to figure out what these casket things looked like, how consistent they need to be with one another (not very; watch how those semi-circular pieces on the right side of the foreground casket flip), and how they fit into the scene.

The foreground figures are also getting more rendering from the lighting cast up from the casket.

The background figures get their darks lightening up so their whole zone of the image has a bit lower contrast. Maybe it suggests atmospheric shading; I’m not committing to whether there’s an atmosphere in here or not, but it pushes them into the background a bit more.

Much of the worldbuilding here is necessarily noncommittal – I don’t want the “caskets” to read clearly as anything in particular, I don’t want the place to be a building of identifiable purpose or even for it to be clear if this is a planet’s surface or a ship wreckage. (Microgravity? Don’t worry about it.) This has to work in almost any part of the game where the player is plundering goodies, so I’m leaving it all wide open.

I decided that the central figure looks too much like they’re holding a gun rather than holding a power tool, so that gets slightly redrawn. Perspective on one of the crates to the left gets altered a bit, though its buddy is still a bit off. I don’t think I’ll even fix it. [Edit: I fixed it in the end. It was bothering me.]

It is important to remember that image will be displayed in-game at half the size you’re viewing it at now ( – if you click on it to open it at full, working resolution; just as I paint the character portraits in 4x size, I now do these other illustrations in 2x size). The details can absolutely be murky and loosely defined, and in fact they may work better if they are. The number one rule is to set a mood!

I do a colour/curves correction pass over the whole image to get it feeling a little more unified, then do one more pass over a few key details that were bothering me – mostly to do with the central figure, who I suppose deserves some more attention due to drawing the eye. Some perspective lines have been cleaned up but I’m not being too obsessive about it getting everything strictly correct.

Now I just gotta shrink it down, run the trademark Starsector sharpen effect, add a dash or two of colour burn to calm down some of the lighter spots…

And we’re done!

Or not. Here’s a take without the background figures:

Aw, heck. I almost like it better because it feels more lonely and lets the scale reference in the background play a bit looser.

I’ll decide which one to actually use in-game, um, later. (Consensus is rapidly solidifying toward this version. Per Alex, “with the figures, it’s ‘bustling industry’, without it’s ‘horror-tinged tomb raiding’.” — And that’s me sold.)

Comment thread here.

This post is about the process of implementing scripted dialog content into Starsector. It’ll get technical toward the end and I’ll do a tutorial on how to implement a new piece of character interaction.

So! I’ve been given to understand that rules.csv is notorious among modders of the game – how unfortunate!

In response, allow me to present a spirited defense of this data file and its attendant content pipeline. I’ll talk a bit about what it is, why Alex made it the way it is, how I came to use it, and how it can be used in general.

(It’s probably important to explain what the heck a rules.csv is in the first place, isn’t it.)

The rules.csv file is the primary, but not only, means of creating dialog interactions within the game Starsector. This includes almost all situations where the player engages with an entity – a planet, fleet, or character – where a textbox pops up and allows the player to choose from a set of responses. After choosing a response, stuff happens, more text is displayed, and a new set of possible responses is presented. This interaction loop proceeds until the dialog is closed.

This system is the basis for conversations with NPCs, for most interactions with campaign objects (planets, derelicts, sensor arrays, jump-points), and nearly all of the missions and story events.

In short, rules.csv contains the data used by what amounts to a custom scripting language that hooks into the game code to drive almost all content which doesn’t involve the combat map or the campaign map.

It’s a big deal!

Though some may find it hard to believe, I do enjoy using rules.csv because, above all, it’s lightweight. Every step is fast, simple, and responsive. I’ll walk through how this looks in practice in the tutorial section of this post.

First, though, I’ll get into how Alex came to build this system in the first place and how I came to use it.

How Did This Even Happen

Alex watched this video of Elan Ruskin talking about implementing an interactive content system at Valve. Then he made the system described therein.

(Note: the “AI” in the video title refers to making responsive content for non-player characters in video games, it has nothing to do with the recent hype-wave about using large datasets to generate text and images.)

(Also, props for the Verner Vinge callout at 21:51.)

The video lays out the entire theoretical and practical basis for the implementation the Starsector rules system, and explains why this kind of system can work well – as it does for us – to empower writers (me!) to quickly create and iterate game content. It’s not just a purely technical matter, but one of workflow and project management: who can do what, who can make decisions and where.

In other words, the content creation process is not (only) made for the mindset and convenience of the implementing programmer, but with consideration for the content creator(s) as well. It’s always been my experience in game development that when non-core programmers are given content creation tools which empower them they’ll make shockingly cool things of quality which is often well beyond the expectations of the coder who created the tools!

(Of particular note in the video, I appreciate the point about how he spent a bunch of time making a graphical interface for writing dialog – writers, they’re artsy people right? They must like visuals right? – and the writer he was working with hated it. I share the sentiment; I can’t stand visual programming interfaces! It feels like a layer of mush set between me and what’s actually happening. I remember taking a programming class in art school and being encouraged to use a visual programming tool to learn to code, and I was like “No! I want to use C!”)

The rules systems is only part of it, of course.

The real story is that Alex slowly accreted features into Starsector to expand upon the original combat sim. Alongside the new features – the non-combat campaign layer, planets, characters, missions – Alex also added an increasing ability for me to collaborate more directly on game content. And, well, that story is contained in the last ten years of blog posts… which you can view on the right side of your screen.

But to give an example of how this process developed:

For narrative missions in particular, we started with a process that saw me write dialog in a shared Google doc/sheet. Alex would implement what I’d written from the doc, and this is how we made the “Red Planet” and “Scientist AI Core Bar Event” missions.

We realized that this process was a bit of a chore, especially if I wanted to make edits or add additional content without having to go through Alex. And besides, assembling dialog text in code has a lot of Java markup around it that makes it difficult to know how the text will feel in-game, and it makes it difficult to catch small errors. Just the other day I found an incorrectly uncapitalized letter in one of the hardcoded dialogs!

If I recall correctly, the rules.csv system did exist at this time, but was used mostly to handle generic interactions with markets, and… things. We did not have the backend to (relatively) easily handle actual missions with stages and associated intel UI features – which is why Alex was one-off coding the things. Nor was the set of functions which rules.csv could draw upon for conditions and triggers terribly expansive; certainly all the code hooks existed to do almost anything you could imagine, but the rules parser was not set up to use them. Doing something slightly special such as (say) hiding or unhiding a character in the comms directory would require custom code rather than a simple call in rules. (I use this example because I think this is one of the first customs rules script hooks that I implemented myself! Yes, I was very proud.)

But there was the problem: while Alex could write custom code to do anything at all, but I couldn’t; not without making a giant mess, anyway. I went to art school not computer science school!

Anyway, Alex built general-use structures for missions and steadily improved, well, everything. Meanwhile, I had to learn to use this stuff.

My approach was generally to look at what he’d already implemented, copy a piece of content, then modify certain elements to create a variation that did something a little differently. Sometimes this worked! Sometimes I’d come shamefully crawling back to Alex and have to say “Sorry, I exploded the game again.”

(Alex is extremely patient. I have no idea how he does it.)

I recall now two of the first rules interactions I wrote: one was for flying through derelict Gates and, spookily!, nothing happens. The other was visiting the Beholder Shrine and getting a text dump; Alex then added the bit about donating supplies after we talked about how much fun it was to actually be able to visit a shrine. (Later, this whole line of thought exploded outward into the mission to visit all of the Luddic shrines.)

Stepping back (in time), I particularly got more into scripting/coding bits and pieces for Starsector after Gaslamp Games closed down in 2017 – not only, obviously, did I have a lot more time to work on Starsector, but I was also coming off a period of doing heavy Lua scripting for Clockwork Empires gameplay. This involved creating game objects and quests structured not so unlike the way Starsector’s missions were eventually structured (due to these being commonly solved design pattern in games, nothing more; I wasn’t the code architect for either game.)

Not only that, post-Gaslamp (and, to be honest, immediately pre-post-Gaslamp) I got into learning the Unity engine – yes, hindsight is 20/20 – and with it, the C# programming language. C# is basically Java, so it made learning Starsector code far easier because I had a place outside of Starsector development to screw around and learn by making lots and lots of mistakes.

And as I’ve learned to use both Java and rules.csv, I’ve been able to add increasingly complex narrative structures into Starsector – best of all, it’s super fun! (It doesn’t happen often, but especially rewarding is surprising Alex by using his game to do something he hadn’t thought possible.)

Let’s talk about how the magic happens.

And by magic, I of course mean rules.csv.

Note: this tutorials gets very technical and is probably only of interest to modders or people interested in boring implementation details. If you want fun updates on Starsector content, skip to the design comments section at the very end of the post.

A Rules Tutorial

I’m going to walk you through how to implement some new dialog.

Maybe this will be of interest to regular players, a little peek behind the curtain to see how things work.

Maybe it’ll inspire someone to get into modding? I can only hope. I’m going to write this from my perspective, by the way, not from that of adding a mod to the game – I, um, actually have no idea to do that off the dome.

Happily, someone else does.

A note on tools: I find Google Sheets to be my ideal method of editing lots of interconnected dialog pieces. It allows real-time collaboration between myself and Alex… and it works very nicely across several large monitors so I can pretty much display everything I need to take in a context surrounding a piece of dialog, everywhere, all at once. Though even that is not enough for some of the most complex interactions – if you’ve tried to read through the rules behind “The Usurpers” you’ll know what I mean – but it gets easier with practice and planning.

(I did, by the way, have a quick look at a rules.csv tutorial on the Fandom wiki and was shocked to see a link to Alex’s ancient rules documentation. This thing goes back to the very first doc I remember Alex sharing with me, and I don’t think it’ll upset him too much if I describe it as “scant”.)

Example Dialog Implementation – Supplies, I beg of you!

Let’s start simple: we’ll make a dialog option to allow the player to ask a planet’s quartermaster for free supplies.

To start, I’ll pull up the game and look at where the dialog I have in mind will appear.

(Note that I will be in dev mode; this is a boolean you can set in the settings.json file.)

I zip over to Jangala and find the quartermaster for a chat. Here’s our man, Min Chen:

He doesn’t have a lot to say to us right now. We’ll fix that.

Let’s hit the >> (dev) dump memory option.

This outputs a huge mass of text. This text is everything in memory accessible to the node of dialog we’re in while talking to Min Chen. (If you watched the Valve video, you’re going to start seeing the pieces come together very quickly.)

Each line starts with a name with a dollar sign in front of it, like $name. This is the id or key for a memory entry.

If this name has a dot in it, like $name1.somethingElse, this just means that name1 is a container which holds other memory values, one of which is somethingElse. You can think of them almost like files in folders in a filesystem.

Because we’re talking to Min Chen, we are currently “inside” his memory container, so if we see a memory key without a dot in it, that means the memory is attached to him. (Or it’s been put into the local context automatically for convenience. Don’t worry about it.)

If we want to access a memory within the planet of Jangala while we’re talking to Min Chen, we can call $entity.coolJangalaFacts. Separate memory containers exist for the planet of Jangala (the on-map planet entity), the space station orbiting Jangala (which is a separate object on the map!), the market attached to Jangala ($market, an entity that both the planet and station can access so you can trade and talk to people by moving your fleet to Jangala Station or the planet itself).

There’s also a $faction container, which in this case is the Hegemony because they own Jangala’s market. $personFaction is attached to Min Chen himself, though in this case it is the same as $faction because both Min Chen and Jangala are Hegemony. We’ve also got a $player container to hold information about the player and a $global container to hold information we want to access from anywhere in the game. (For the purposes of player-facing dialog, $player and $global are pretty similar because the person playing the game is always the $player and always has access to $global. …Don’t worry about it.)

Remember all that? Fantastic.

(… there are also memory values which can be called upon which aren’t shown in the memory dump, plus a bunch of special cases. Don’t worry about those right now either. The world is a complex, scary place enough already.)

Back to the memory text dump: after each memory name is an equals sign followed by a value. So (for instance), $entity.name = Jangala means the value with the key “name” is the string “Jangala”. In other words, the entity we’re interacting with is named Jangala. If you read through the memories in the screenshot, you can see that Jangala has a market, a station, doesn’t exist in hyperspace, and other neat #JangalaFacts.

There’s a ton of useful data here we can pull into dialog and use – not just in the $entity container, but also in $player, and of course in the current active character, Min Chen.

Writing A Rule, Finally

Let’s add an option to ask Min Chen for free supplies. This will require a new rule. I’ll open up the rules spreadsheet and add a new rule at the very end of our Rules spreadsheet, line 8182., which looks – to me – a like this:

(Click on the image to view it full size. I’ll make the rest of these a little smaller.)

I’ll explain what each column means.

id

A unique name for the rule. Every id must be unique.

(If you put a “#” character at the start of a line in a cell, that makes the line a comment and will be ignored by the rules parser. Put a # at the start of the id block to quickly comment out the entire rule.)

trigger

The name of the command that must be called to make the rule happen. This is only ever one string.

Some trigger names are set by convention and used throughout the rules file, ie. “PopulateOptions” is a generic call to open the starting options for dialogs initiated by the player. We want this new option to appear when we first start talking to Min Chen, so this is an appropriate place to use this trigger.

conditions

Describes a set of conditional restrictions on the trigger.

If we wrote “$market.id == jangala” as a condition (note the two equal signs), this would mean that the trigger would only fire if the player is at Jangala Station or the planet of Jangala. If we wrote “$entity.id == jangala”, then we would restrict the rule to trigger only if the player was interacting with the planet Jangala.In this case, we only want to fire this rule of the player is talking to the quartermaster, so we use “$postId == supplyOfficer”.

(Every character has a postID, and Min Chen’s is “supplyOfficer”. “supplyOfficer” is a back-end name for a character job which in the Hegemony faction gets displayed as “Quartermaster”.)

$isPerson is technically redundant because $postID == supplyOfficer is only ever attached to characters who also fulfill $isPerson. However, it is a good idea to put conditions which are simpler to query and/or are more restrictive at the top of the condition block for performance reasons. $isPerson is very simple, so it may be appropriate to use it here.

script

Allows a rule to fire off a series of pre-programmed commands with custom arguments. These are references to Java methods that have been set up so that rules.csv can call them.

The scripts section lets us do tons of cool stuff but we don’t need any of that yet so we’ll leave it blank.

text

Simply for text which is sent to be displayed in the in-game dialog box.

The rule we’re making is only to add a new option for the player to ask for supplies, so this can be blank.

options

Places responses at the bottom of the dialog box, allowing the player to choose how they wish to respond to a situation. The format for these is [key]:[text].

(Responses will be placed at the bottom of the dialog box in the order that rules create them, unless you override that ordering. We won’t worry about that now.)

A response line in options automatically hooks into trigger and conditions: when clicked, it will fire a trigger called “DialogOptionSelected” and populate into local memory an entry named $option with a value of the key string.

So if I want this response option to trigger another rule (and not simply cause an error), I need to add a new rule that checks the $option condition after DialogOptionSelected is called:


Note that the condition $option == bqfs_askForSupplies matches the key in the option line bqfs_askForSupplies:”Could you give me some free supplies?”.

All response options populated to dialog must use a unique key. If you want two responses to lead to the same option, you have to make a fake option that triggers the same-named option, like so:
Assigning a new value to $option and firing DialogOptionSelected is essentially identical to the player clicking on an option with that key. It is executed immediately, however, so it looks like the text transition is instant. (Later, the player will read through rules.csv and realize that the game ignored their unique response and then get mad at me for the fake-out.)

… Anyway, I’m getting ahead of myself.

notes

 For comments, not used by the game engine.

We’re only halfway there: the rule triggers, but does nothing (and still causes an error). We need to fill in some text to tell the player what’s happening, add a line to the script section to give supplies, and then figure out how the player gets back to the dialog flow.

Go back to the rule entry for bqfsAskForSupplies.

The script cell will get this:

AddRemoveCommodity supplies 10 true

AddRemoveCommodity is the command. Everything that follows is turned into arguments passed into the Java method written to handle the command by that name. I don’t remember what the “true” does, so I’ll just look at the code real quick… OK, it sets whether text for the commodities getting added (or removed) is automatically inserted into the dialog box. Default behaviour is to add the text, so the true is redundant, we’d only use that argument if we wanted to set it to false; I’ll remove it.

The text cell will get this:

"Well," $heOrShe says slowly, looking troubled. "I suppose we could spare a few supplies for an honest-looking spacer such as yourself."

This quartermaster is clearly a poor judge of character.

We’re still not quite done: if we leave it here, this rule just dead-ends the dialog and creates an error. The game will put a warning and allow the player to back out of the dead-end, but we really do need a way for the player to return to the dialog loop. How to do that?

You already know the answer: we need to call the trigger PopulateOptions!

So, in the next line of the script cell, after the command to AddRemoveCommodity, we’ll add this:

FireAll PopulateOptions

This will query and fire all rules with the trigger set to PopulateOptions. (If we used “FireBest” instead, this would only trigger the rule with the highest number of qualifying conditions. If you watched the Valve video, you’ll know what this means already, but before we get even more ahead of ourselves let’s see how these two rules work in-game.

To review, here’s the rules spreadsheet after the additions I’ve described:

The First Test   

In Google sheets I go to File > Download > Comma Separated Value (.csv) and get the csv file. I open this in Notepad, select all, then paste into the master rules.csv file in the Starsector build folder – filtering the text through Notepad removes certain potential formatting disagreements.

I still have the game open, remember!

Starsector will hot-reload the new rules.csv, which is *great* because I can test my new rule without even leaving Jangala. Let’s “Cut the comm link” with Min Chen then restart the conversation and see what it looks like:

A new option appears! Fantastic. Let’s mash that a few times.

Awesome, free supplies!

But you see the problem: we can’t simply give the player free supplies again and again, forever. Such charity should come with… conditions.

Setting A Memory Flag And Using It

Let’s have Min Chen remember that he gave you supplies.

If you ask for more supplies without waiting (say) three days, he should deny your request.

To do this, we need to set a flag in Min Chen’s memory when he gives you supplies. In the bqfsAskForSupplies rule we’ll add a line to the script cell so it looks like this:

AddRemoveCommodity supplies 10
$gavePlayerFreeSupplies = true
FireAll PopulateOptions

A memory flag called $gavePlayerFreeSupplies will now be set to true when Min Chen gives the player supplies.

This is good, but Min Chen needs to actually give a different response when this memory value is set. (Note that the memory flag is set before calling Populate Options because we want to set this flag before triggering any more dialog rules – they might need to use this flag to evaluate conditions!)

Let’s make a second rule that fires as an alternative to bqfsAskForSupplies when $gavePlayerFreeSupplies is true.

Make a copy of the entire bqfsAskForSupplies rule by copying the whole row in the spreadsheet. This copy will need a new, unique name, so let’s call it bqfsAskForSuppliesDenied.

We’ll add a new line to this rule’s conditions cell:

$gavePlayerFreeSupplies

This is the same as writing “$gavePlayerFreeSupplies == true” (and, indeed, validates if the flag is any non-null, non-false value).

Remember also that this is set in the local context. In other words, this value is attached to Min Chen and only exists in his memory container.

If we set this value on Min Chen then fly over to Eventide and ask the quartermaster there for supplies, they will not know that Min Chen already gave you supplies, so you’ll get another 10 supplies!

Alternatively, we could set (and check) $faction.gavePlayerFreeSupplies if we wanted the entire Hegemony faction to remember it gave the player supplies. Or we could set (and check) $player.gavePlayerFreeSupplies to have the memory follow the player around wherever they go.

Anyway, I wrote a bit of text, put FireAll PopulateOptions to the script block rule, and now the new set of rules looks like this:

Let’s drop this new rules.csv into the game folder and see what happens when we talk to Min Chen.

(My old dialog from before is still in there, remember. The new interpretation of rules is output at the bottom of the dialog box.)

He knows.

Making Min Chen Forgetful

Let’s make this more interesting.

What if there was a time limit, and if you wait long enough, Min Chen will forget about giving you supplies and give you more? Easy: add an expiration to the memory flag by added an integer on the end of the line where you set the memory.

$gavePlayerFreeSupplies = true

becomes

$gavePlayerFreeSupplies = true 3

This number is a count of game-days until the memory expires.

You could also remove memories in a rule’s script block by calling unset, like so:

unset $gavePlayerFreeSupplies

But for now we’ll let the expiration timer do the work.

BTW Pronouns

You may have noticed the use of “$heOrShe” and “$playerName” in the text in the text cell. These are tokens which are automatically replaced with a memory value of the same name if it exists. A full set of these is automatically populated as appropriate for pronouns for character entities. Take note of the difference between $HeOrShe and $heOrShe – we control use of capitalization. Also, $himOrHerself will change to himself or herself, and so on. And of course there is $brotherOrSister for use by Luddics.

The player also has a few tokens which are automatically available in all contexts: $playerSirOrMadam will insert “sir”, “ma’am”, or “captain” (the three genders) as appropriate.

You could even put $gavePlayerFreeSupplies into the text cell and it would be changed to “true” if it exists and is true. (If it doesn’t exist, it’ll stay as $gavePlayerFreeSupplies. If you’ve ever reported a bug where a dollar-sign token shows up in text, it’s because of a missing or misnamed memory key.)

Making It More Complex

We can also add a rule that writes a bit of text which lets the player know that Min Chen remembers giving supplies without having to ask first.

Check out bqfsAskForSuppliesGaveAlready, highlighted above. It is triggered by PopulateOptions, just like bqfsAskForSuppliesOption, so it will be queried at the same time. However its conditions require $gavePlayerFreeSupplies be true, which is only set by bqfsAskForSupplies after a player gets those free supplies.

(You might ask, don’t we need to check that $postId == supplyOfficer again? Technically, no, because this is literally the only place in the game that sets $gavePlayerFreeSupplies… so far. We could write a more restrictive set of conditions if we wanted to make this more safe. I won’t bother now. Adding more conditions to a rule also changes certain things you’ll understand if you watched the Valve video. We’ll get to that soon.)

I’ve added a new set memory to the script block, too:

$saidAlreadyGaveSupplies = true 0

The number of game-days that must pass for this memory to expire is zero! This means that the memory will disappear as soon as the player closes this dialog window, returning to the campaign map. (It will not disappear, however, if the player simply closes the comm link with Min Chen and then re-opens it.)

With that set, note that after this rule is executed and its text printed, it will not repeat until the player leaves the dialog because of this new condition:

!$saidAlreadyGaveSupplies

The exclamation mark is a logical NOT, so this says “if not $saidAlreadyGaveSupplies equals true, then allow this rule to be executed”. Simplified, it’s basically “make sure $saidAlreadyGaveSupplies is either set as false or doesn’t exist”.

We can still ask for supplies, which is a bit silly and possibly rude. Note that he doesn’t repeat the line about recognizing you. (Maybe he should – often it’s good UX for people to repeat things or state the obvious in ways that would be unnatural in ‘real life’ because it hints at important game information.)

Anyway, let’s disable the option to ask for more supplies if it’ll only result in Min Chen saying no, and add a tooltip that tells the player why the option is disabled.

Here are the three lines in the script block:

SetTooltip bqfs_askForSupplies "$personName remembers giving you free supplies. You'll have to wait until 3 days have passed since you last bummed supplies off of $himOrHer for $himOrHer to forget."

This calls SetTooltip on the option with the key bqfs_askForSupplies with the given text.

SetTooltipHighlights bqfs_askForSupplies "3 days"

Same deal, but this gives a highlight effect to the first instance of the specified text found in the tooltip already set on the targeted option. (There’s even another command to set the color of text per highlight effect! We don’t have to get that fancy right now.)

And, finally, the most important command:

SetEnabled bqfs_askForSupplies false

Which disables the targeted option, making it appear grayed-out and unselectable. Sometimes it is good to show options which are not available so that the player knows that they need to fulfill some missing condition to be able to select it.

With the new rule in play, it looks like this in-game:

This does, unfortunately, negate the possibility of encountering the rule we made previously where Min Chen doesn’t give you supplies. We have to choose which way of expressing this setback feels best in this context. (Right now, I don’t care because this is a tutorial!)

Almost Done, I Swear

Let’s return to that tangent about the conditions block using multiple condition checks.

When conditions are evaluated, if any condition fails the whole rule will not be triggered. If we’re using FireAll and all conditions pass successfully, then the rule is fired.

If FireBest rather than FireAll is called on a trigger, the number of conditions that ‘succeed’ becomes important. Each successful condition adds one point to the value of the rule, so a condition that fulfills three rules successfully will be triggered over one that fulfills just one rule.

Let’s use this so that Min Chen has some different things to say if the player has poor relations with his faction.

I cheated the system here by added a score:[number] on the end of one of the condition lines to change the value of the rule if it passes its conditions block. This can be used so an option can override others even if it evaluates fewer conditions.

To test this in-game, I’ll use some other dev-mode options to change my relations with the Hegemony so that I may encounter these responses.

(Truly, setting up the state of the game to test esoteric conditions can be a ton of work – rules.csv scripting also makes this way easier because I can make hidden rules which require $global.isDevMode set to true, and use those to set memory values to match my test case. Later, when we do pre-release testing, it becomes important to encounter these states more naturally. This takes a lot more time, and is why it’s useful to have dedicated QA testers.)

Not bad. The whole thing should probably be overhauled so that all of the reactions work together cleanly and, as mentioned, I need to commit to expressing certain game information in a consistent manner and at consistent times within this dialog. Like, does Min Chen react with suspicion/hostility when the player opens the comm link or only when they ask for supplies? And what happens if the player returns and asks the same question?

I’ll note also that it is tempting to model rules in your head as a series of interconnected dialog nodes, only one of which is “active” at a time. They can be implemented this way, but that metaphor drastically limits the possibilities. Rules are a set of functions which affect the dialog state based on triggered conditions; multiple different rules can be used all at once (as we did with the tooltip modification and option disabling… alongside every other PopulateOptions-triggered rule!) to create a displayed state – and this state can vary wildly based on conditions.

Hmm.

Yes, this is just a tutorial, but it bothers me when things aren’t exactly right…

How About For Real

This whole asking for free supplies business is a bit silly to actually put into the game. But having walked carefully through setting up a basic version of it, I’ve been thinking about how I’d do it for real.

I’m not going to go through step-by-step, but instead just implement everything then show them to you. And now that you know how to read the raw rules spreadsheet, perhaps you can figure out roughly how this will work in-game.

Here’s the rules chunk as a .txt file: bqfs.txt You may need to change it to .csv to view it in a csv editor. (And remove the header line.)

Or, if you like, here’s the largest image on this website:

Some thoughts during/after implementing this:

• I did get a little fancier than strictly necessary to show off more features of the rules system. (And make pretty colours.)

Reviewing this with Alex turned into a bit of a design discussion about how to make this a not-annoying feature.

Basically, if the player can get supplies for free, then it is in their interest to optimize the game by taking free supplies whenever possible – and jumping through stupid hoops to do so. My first-pass implementation scaled based on how many supplies it would take to repair & CR-max your fleet, so: the player could pull a bunch of junkers out of storage to get more supplies. Or this would make it in their interest to start salvaging garbage ships from combat and bringing them back to a commission world to get free supplies. And: if we detect if the player dumped stuff in storage, or if they’re fresh from combat, they’ll just dump ’em in an abandoned station somewhere and it’ll be the same problem but create even more tedious incentives.

So, we came to two decisions: 1. Make this have a huge cooldown (one ‘cycle’) so that the game doesn’t incentivize ‘farming’ supplies. 2. This should also be limited to early/mid game. How? Well, once you have a colony, no more free supplies — you can’t very well dump an entire colony into storage, can you.

• Yes, there is code to check if the player simply dumped their supplies nearby to pretend that they’re all out.
• … In writing this just now I realized that I forgot to check if the player dumped their supplies into local storage to pretend they’re all out. Adding a note to my TODO to implement a check for this case…
• This sequence shows use of unique text for $faction responses. In addition, one can write unique $voice responses (each NPC is given a ‘voice’ memory which corresponds to a vague archetype: soldier, faithful, pather, spacer, aristo, official, business, scientist, villain. These are not used very often, mostly just in the most generic interactions so that those feel less repetitive. Multiplying text variations by 10x (1 generic, 9 voices) for everything is rather unreasonable.

To that point, I don’t make a particular effort to give every faction a unique line everywhere possible. Mostly I’ll write a custom version of text when inspiration strikes or it feels particularly appropriate to the situation. And just as with $voice, certain more generic interactions work better using faction-specific responses to add variation to otherwise repetition lines, or are necessary for flavor i.e. taking a faction commission.

• This chunk of rules does use a few custom script calls written (in Java): “recalcFreeSupplyDaysRemaining”, “isCargoPodsScam” (borrowed and modified from the code used by patrols), and “doesPlayerFleetNeedRepairs” which sets a few different variables based on just how damaged the player’s fleet is so that the Quartermaster can respond appropriately.

All of these scripts return a boolean (true/false) values as well as setting other memory values in the course of their evaluation/execution. This means that they can be used in the conditions block as a condition, and the memory variables they set can be used elsewhere (or immediately!). A common use is to call “updateData” on a mission script – this populates local memory with mission-relevant data, but will also return false if the mission doesn’t exist. So instead of two calls, one to check if the mission is active and one to populate memory, they’re baked into the same call.

• As implied by the above, there’s much to say about Starsector rules design patterns – the “conversation hub” structure is particularly useful – but I think we’ve had just about enough rules talk for today.

Whew. Thanks for sticking by through all of that.

You’ll get your free supplies in the next update – conditionally!

Comment thread here.

What I’d like to talk about today is a re-work, and a major expansion, of the Hostile Activity system introduced in the previous release. It was released in a baseline state where the only two factions involved in it were the Luddic Path and the pirates, but it was always intended as a way to put a lot of different content in front of the player.

So, the changes here are two-fold: 1) taking some lessons from how the existing mechanics worked out, and 2) adding a *lot* of content to the system, so that it can be seen in its intended and more-or-less final form. It’s certainly possible that more content will be added to it here and there, but the amount of content it’ll have in the next release will be enough for the system to “work” – it just needs the variety, more on that a bit later.

First, a quick recap of how it works in the current release: you establish a colony and get “Hostile Activity”. This results in fleets you can fight being found in your star systems, and periodic major events where for example pirates send a raid at one of your colonies. As the hostile activity level goes up, your colonies get some penalties, and you can make the level go down by fighting hostile fleets. You can also resolve the various hostile activity causes in narrative ways – making a treaty with the pirate queen Kanta, or making some kind of deal with the Luddic Path.

Penalties
This works, but some players feel like they have to keep the level down to avoid penalties, which both creates busywork for them, and in turn makes them avoid the more interesting events that occur when the activity level maxes out. It’s interesting to me, because objectively speaking, you can absolutely ignore the current activity level – if your colony is decently set up, it’s just a modest reduction in profits – but psychologically, the amount of incentive to keep it down is enough that plenty of players feel like they “have” to do it.

Taking a step back, why are the penalties there? One reason is to give the player a reason to fight these fleets – but that’s working a little *too* well, and is also working against the player seeing the more interesting events. The other main reason is just feel – it’s hostile activity, right? There should be some kind of consequences for letting it run unchecked.

Reframing as “crises”
Mechanics-wise, though, I think it’d work better without the penalties, the incentives line up better. So: rebranding “Hostile Activity” as “Colony Crises”, which doesn’t sound like something that should have penalties until an actual crisis happens. And along with this, removing all the along-the-way penalties.

So, the way it works is you’ve got a progress bar that fills up gradually, and when it does, a “crisis” happens. Hostile fleets still spawn in your systems before that point, depending on the types of attention you’ve attracted – giving the player a source of varied opponents is a big reason the mechanic exists in the first place. And you still have reasons to fight these fleets – first off, combat can be profitable on its own. Second, you can juice it up by building a Commerce industry and having a permanent independent bounty in the system.

And, finally, if you really don’t like the upcoming crisis, you can fight hostile fleets, reduce event progress, and cause the crisis to be averted, with another crisis being rolled when event progress goes back up again. Some crises can also be averted in other ways – making a deal of some sort, or disrupting the faction’s military capabilities.

Opportunities
An important new thing about crises is they’re no longer just a “massive bad thing happens and you need to stop it from wrecking your colony”. I mean, they’re definitely still that, but they also come with an opportunity; there’s a carrot to go with the stick. For example, fighting off a pirate raid will give your colonies a “Piracy Respite” condition that increases their accessibility, and fighting off a Luddic Path attack will disrupt Pather cells across the entire Sector, for a long time.

Given that a crisis is – if seen in the light of the opportunity it offers – potentially a good thing, the player might feel like they don’t want to fight hostile fleets in their systems to avoid postponing the crises too much. To make sure this isn’t a problem, there’s a “blowback” mechanic – basically, the reductions in event progress are temporary and those points gradually come back. You can fight a bunch of hostiles in your system, get some bounties, and not feel like you’ve delayed the crisis-related opportunities in the long term.

Defensive buildings at your colonies – Military Bases and such – slow down event progress instead of reducing it by a flat amount; otherwise you could end up with negative event progress and miss out on crises (and opportunities) entirely.

After a crisis happens, event progress is reset to a random value within a pretty wide range. The idea with this is to make the pacing of crises more unpredictable. You might get several crises close together, even so much so that one is still going on when another happens – but handing them through the main Colony Crises event makes sure you have a heads up about what’s coming down the road.

New content
In addition to the pirate and Luddic Path crises, there are now also crises for all of the major factions (except the independents, so: 5 of those), and … one for having a [REDACTED] base in your system. No longer will that be just a free source of defenders to thin out incoming raiders!

Punitive expeditions (except for the “you put a colony in the faction’s system” ones) have been replaced with the crises, which are more elaborate and customized versions of these to suit the character of each faction. Some of these went quite a bit farther than I was originally expecting!

The rest of this post is going to have spoilers about the new content, so consider yourself warned. I’ll try to keep it fairly light, but we’ll see. It’s always a balancing act talking about something interesting while at the same time trying to avoid spoiling it. So: if you’d like, feel free to skip to the “what’s next” section at the very end of the post.

Pirates & the Luddic Path
In the initial implementation, raids/problems from Pirates and the Path were unlimited – you would defeat one, but eventually another would come. Given that those were the only two sources of hostile activity at the time, that made sense, to get more mileage out of the system. However, now that the system has *a lot* more content attached to it – and it no longer has ongoing effects like penalties – it’s ok for things to just… end.

If you defeat a pirate raid or a Pather attack (the Pathers, btw, mean business more so than the pirates – they’re coming to saturation-bombard your technological base!), they won’t come after you in this way again. To me this feels refreshing – the system finally has enough content and doesn’t need to keep throwing the same thing at the player over and over. As a bonus, ending the pirate/Pather thread adds to the “opportunity” that these present. Of course, if you don’t defeat the raid, it’ll keep happening, periodically.

But, you might ask, where does this leave the original narrative resolutions to these problems? Namely, making a deal with Kanta to gain her protection, or giving something special to the Pathers that definitely won’t have any long-term consequences. Kanta’s Protection increases the permanent accessibility bonus your colonies get. The Pather deal makes all of their cells on your colonies become “sleeper” cells – defeating a major attack stops major attacks, but not regular cell activity, and the deal is a way to accomplish that.

Persean League
The crisis related to the League ended up being one of the more involved ones. The original idea was just to build on a simple punitive expedition a bit – dress it up with some narrative resolutions, and call it a day. But thinking it through – what would the League, an association of nominally-autonomous worlds, want from the player? How would they go about getting it? What options might the player have for dealing with them? It felt like a case of the story writing itself.

Even in this spoiler-section, I don’t want to spoil it too much, so let’s just say that while combat is very much an option, the League’s approach is not fundamentally hostile, even if it is very heavy handed. And the options for dealing with it include the political ones – of the shady backroom deal sort – and some of the benefits provided to the player operate on the same plane.

I will spoil it a bit – the “hostile activity” fleets that show up in the player system well before the crisis are “League Enforcers” that patrol the space, attack pirates – but also subject your fleets, as well as other trade fleets, to constant harassment.

Luddic Church
In keeping with the idea of minimizing spoilers, let’s just say the crisis is related to habitable worlds that are attractive to the Luddic faithful that want to get out from under the direct secular influence of the Church. Immigration, the Knights; various resolutions.

Sindrian Diktat
If you’re familiar with the Diktat, you can make a pretty good guess as to what the crisis is about!

Tri-Tachyon
Think of it as a high-powered business negotiation. There’s even a separate Event that progresses as you ensure that your position on the issue of healthy competition is understood!

Hegemony
The AI inspections are now a series of escalating crises, instead of being separate from this system. Defeating the inspections is narratively framed as defeating the Hegemony, and there’s a new way to avoid the inspections.

What’s next
The next release is going to be 0.96.1a – the .1 generally meaning that it’s a “bugfix, balancing, and polish release”. With this rework, and the additional travel options, this release has a lot more content than is usual for this type of release, but it just felt like the right time to build on the Hostile Activity foundation, and to finish out the campaign movement mechanics, to have both of these loose ends tied up.

What still remains is a a rather large spreadsheet of minor issues (of which not many strictly speaking *need* to be done, but a lot of which I’d like to at least have a look at), a list of balance tweaks I want to consider, and quite a large – given the new content – amount of playtesting. I’m looking forward to getting this release in your hands, so here’s hoping all that goes smoothly!

Comment thread here.

I’ve been doing a bunch of work adjusting skills in the last couple of days. Since it’s so fresh in my mind, and since there were a lot of changes, it seemed like it might be interesting to talk about the reasoning behind each change – nothing huge, just a sentence or two describing the thought process. This is an extremely unplanned/impromptu post, and it (probably?) won’t be a very long one. [Editor’s note: this turned out to be overly optimistic.] I’ll try to organize things roughly in the order that I made the changes, so you get a little more of a real view into how this type of work goes sometimes.

Overview
First, a bit of a step back. While there are 4 different skill categories, or “aptitudes” (combat, leadership, tech, industry), there are two broad types of skills – ones that boost the ship you’re piloting, and ones that boost… everything else. From other ships in your fleet (usually including your flagship, though not boosting it as much as personal skills), to things like colonies , campaign travel and so on.

Coming at it fresh, it might seem “obvious” that skills that boost your fleet are way better than skills that boost your flagship. Boosting more things is clearly better than boosting fewer things! This is perfectly reasonable, but like many obvious things, it turns out to be wrong – or at least, more complicated than that.

Under the control of a good pilot, personal-ship skills make a huge difference, and your flagship can make an outsized impact on the battle. However, the amount of difference it makes is dependent on the player’s piloting skill. A player that’s better in piloting will get a lot of mileage out their flagship being stronger. A player that’s not so good at it – or one that just elects to command their fleet and doesn’t even try to pilot a ship themselves – won’t.

The point I’m trying to make here is that the balance between these two types of skills is inherently player-skill-dependent (or, preference dependent, in the case of a player that just wants to command their fleet). This means that there’s no specific value where Personal Ship Skill A will be “balanced” when compared to Fleetwide Skill B. Rather, what we’re adjusting here is the amount of piloting skill a player needs to have to make the personal-ship skills worthwhile.

(There have been suggestions to split the skills to use two separate pools of points so they don’t compete with each other. I don’t want to go off on a tangent about this, so I’ll just note that I am aware of this and feel strongly that it’s not the way I want to go with it. I think this sort of balance and the build decisions that come of it – that evolve as the player’s skill and game knowledge evolve – is interesting.)

Elite skill effects
With that, enough setup! Let’s dive in.

First up: I’ve had a long-term TODO item to improve the “elite” effects of the piloted-ship skills. In brief: those skills each have a special bonus you can unlock. Your officers can only get a limited number of those (more on that later), but you-the-player can unlock all of them. It’s meant to make it feel like there’s a particular reason to pilot a ship yourself – you can’t just get the same bonuses from an officer – but as it stands, the bonuses aren’t quite up to the task.

Mostly, this is fairly straightforward. Not trying to do anything fancy, just slinging a few more bonuses around.

Ballistic Mastery improves ballistic weapon damage and range. The elite effect increases projectile speed – a “soft” bonus (i.e. it’s hard to quantify), though quite good in practice. Still: let’s just throw in an extra 5% damage here, why not. It feels good to have something tangible to go with the soft bonus, to feel like you’re always benefitting in a concrete way.

Target Analysis gives increasingly larger damage bonuses to larger ships – 10% to destroyers, 15% to cruisers, etc. Its elite effect is doing more damage to enemy weapons and engines, knocking them out more quickly – good, but also a bit of a “soft” bonus. Just doing more damage to cruisers and capital ships is frankly good enough for the baseline effect, so: moving the bonus damage to destroyers to the elite portion of the effect, and adding a new 5% bonus damage to frigates for good measure.

(Side note: I’d love to throw around numbers that feel more impressive than 5% here and there. And, sure, in some places that works out. But the way combat works, a few 5% bonuses here and there really, really add up.)

Systems Expertise is a weird one, I just had trouble coming up with a nice bonus for it, so it ended up as a grab-bag of underwhelming effects like reducing malfunctions and overload duration. Not very exciting, no-one plans to overload.  So, alright. Nuking the grab-bag of bonuses is a given, but what to replace it with? It *is* a top-tier skill, so it ought to be strong. How about 10% less damage taken? Just, overall. It’s a thematic fit – being an expert in all of the ship systems could conceivably enable you to secure them more effectively. It’s not a super exciting bonus, but frankly, skills can’t afford to do that too much – go too wild with that, and the AI has a hard time with it, and so do players that are surprised by a particular enemy ship having a given skill.

Helmsmanship is just broadly a bit weak – nothing really wrong with it. So, a quick boost to the percent speed bonus the base effect provides, and another boost to the flat speed bonus the elite effect provides (up to 15% and 10 su respectively), and, done. Again, not trying to do ground-breaking things here – rather, making “safe” changes that shouldn’t break things but still nudge everything in the desired direction, when taken all together.

Combat Endurance has a fun elite effect – you regenerate hull (up to a limit) once it drops below 50%! This isn’t something you can do by other means, and it’s a cool ability to have, but it still suffers from requiring you to be “losing” too much before it activates. So: let’s make it regenerate hull whenever it drops below 100%. That happens often enough that it’s not really a “losing” state anymore. And it has the benefit of keeping a ship with a larger hull buffer for as long as possible, so it’s also stronger after this change, even though the total maximum amount of hull regeneration is the same.

Gunnery Implants has a bonus to the fleet’s ECM rating, a higher one for small ships. This… let’s set this one aside for now; how ECM works needs another look first.

Damage Control is another skill with an elite effect that’s fun but requires you to be losing – if you take massive hull damage in a single hit, it gets reduced a lot. So if you play well and don’t make mistakes, you’re going to see no benefit from the skill, yay. Also if an enemy officer has it, you might be scratching your head when you torpedo their ship and it has way less impact than expected. (See: prior point about not really having that much latitude to go wild with these effects.)

So… executive decision time, nuking that effect from orbit, too. I like it, but it’s got to go. What to do instead, though? Don’t want to stack more damage reductions onto this skill, it already kind of *does* that. How about a nice +15% damage to enemy hull? It makes sense that knowing all about damage control would also let you know how to count *enemy* damage control efforts.

Except, hmm. This kind of means that other damage-reducing skills should also maybe provide a small damage bonus against their chosen type of defense, too. At first this felt like a rabbit hole, but there are only two more skills like this.

Field Modulation boosts shields (and phase cloak), and tacking on a 5% extra damage to shields to the elite effect feels just about right.

Impact Mitigation – the armor-boosting skill – has a strong elite effect (boosting ship maneuverability – the thematic connection is being able to angle the ship to distribute the impacts). So it gets a more modest “10% increased hit strength” – that’s something that factors into the armor damage reduction calculation. Given the already-valuable elite effect, this extra boost more of a nod to the theme of these three skills boosting offense slightly than being a substantial boost in its own right. (With that: the rabbit hole turned out to be fairly shallow.)

Ordnance Expertise increases the ship’s flux stats (in brief, flux builds up when you fire weapons, the more of it you can dissipate, and the higher your ship’s capacity, the more weapons fire you can sustain). Its elite effects isn’t flashy, but it’s good enough. The baseline effect, +2 flux dissipation for every ordnance point spent on weapons, though… well, it’s too strong. This skill is almost an auto-pick on an officer, but more problematically, it changes the balance of the game by letting ships fit too many offense-focused weapons and making things like point-defense less valuable. There are other factors involved here, for sure – some overall reduction in weapon flux generation, a few new low-flux weapon options, other means available for improving flux stats – but Ordnance Expertise is part of the picture, too. So the baseline effect gets a modest reduction – 1.5 instead of 2 points. It doesn’t need to be nerfed into the ground, just enough that other skills might be more competitive against it, so I think it makes sense to start with a conservative change.

A few other skills – Point Defense, Energy Weapon Mastery, Polarized Armor – seem like they’re in a fine place to begin with.

Missile Expertise – the other top-tier Combat skill, alongside Systems Expertise – I’d already toned down the elite effect of, some time ago. Unlike the others, it was way too strong, boosting missile DPS by 50% *and* increasing their hitpoints, resulting in even higher effective damage output.

ECM rating
At this point, the elite skill effect pass was done, with the exception of Gunnery Implants, and it was time to tackle the ECM rating/Electronic Warfare mechanics.

In brief: each fleet gets an ECM rating (from ships, skills, etc). These are compared, and the loser’s weapon range is reduced by the amount they lost by, capped to 10% maximum. The problem is that if an enemy fleet has really high ECM, then having a little ECM doesn’t help you even a bit- they have enough to max out your penalty regardless. And the main current endgame enemy – the [REDACTED] – have very high ECM. So it’s extremely binary, either put nothing in it, or absolutely max it out using every trick in the book. Anything in between is pointless. This isn’t good!

There have been some excellent suggestions made on the forum. (Argh, I can’t find the thread now! I even had the link in my TODO list, but deleted it after making the changes.) Anyway, the main point of that specific suggestion was to have one side’s ECM reduce the other side’s weapon range, so that both sides end up with reduced range, and one side having more ECM doesn’t cancel the other out.

That’s good, but there’s still a thorny question as to how you might make higher ECM values worth it. If 10% ECM rating maxes out the enemy range penalty, then having more isn’t worth it. One option is to have diminishing returns on it, so that as your ECM rating goes up, the range penalty approaches the maximum value more and more slowly. This is harder to explain, though, and for the player to evaluate at a glance. If e. g. at some point getting 5% more ECM gives 0.25% increased range penalty, then… that’s still basically useless, just in a complicated way.

But, well – the point here isn’t necessarily a “perfect system”. Rather, a system that works well for the ECM rating numbers you’re likely to encounter in-game. With that in mind, the new ECM rules:

• ECM rating cuts enemy range by half of the rating, maximum 10%, so this maxes out at 20% ECM rating

And, actually, that’s it. That’s the new baseline ECM rule. Unless you’re investing heavily into ECM, you’re not likely to see values higher than this. And if you *are*, chances are you have the Electronic Warfare skill, which is where a few added rules come in.

Electronic Warfare is another skill that needed some help – all it would do is increase the ECM rating by 1% for each ship you have deployed. Just changing up the ECM rating mechanics is enough to give this skill more value/meaning, but it’d be really nice to spruce it up some, make it something that’s actually fun to take. And, since the skill lets you reach higher ECM rating values (i.e. quite doably above 20%), it should provide some benefit when you do.

The fun part:

• The EW skill lets your ships capture combat objectives much more quickly, and from a longer range

Five times more quickly, to be exact, and from 1000 longer range. Another “soft” effect, but being able to capture objectives more quickly and reliably is huge. Imagine sending a frigate to capture a Comm Relay, an enemy frigate gets there at the same time, they have a bit of a fight, neither side able to chase the other off for long enough to complete the capture. Or, instead, as both frigates approach, yours captures the relay almost immediately, before they are even in contact, and you’re able to deploy additional ships right away.

The high-values-provide-a-benefit part:

• With the EW skill, ECM rating values above 20% reduce the maximum range penalty from enemy ECM, by half of the excess ECM rating

So if you have 30% ECM rating, the maximum range penalty you’d suffer is 5%. At 40%, the penalty is countered entirely.

Which does mean that values above 40% are wasted, but they’re not very likely unless you’re really aiming to get them, and if they don’t help, why would you be? It also means that if the enemy fleet has 40% ECM rating and Electronic Warfare, then having an ECM rating between 0 and 20% does not help you any – the range penalty gets cancelled out completely by enemy ECM. Less than ideal, but enemy fleets won’t often have a rating that high, and overall we still have a *much* wider range of ECM values that matter.

Going back to Gunnery Implants and its elite bonus – increasing your fleet’s ECM rating is nice, though now the bonus is only half as valuable because half of the ECM rating becomes the range penalty. At the same time, I don’t want to increase the bonus since that would make higher ECM rating values easier to reach and we’d be back where we started as far as the problem of “useless” ECM numbers – just, with larger numbers. So: Gunnery Implants already increases weapon range by 15%. Let’s give it an extra 5% as the elite effect. This might be too strong, actually; it might be worth considering toning the base effect down to 10% alongside that change. Something I’m still keeping an eye on!

Cybernetic Augmentation
This is another technology skill that didn’t quite work out. What it does is increase the number of elite skills your officers have by 2. This is a good bonus, and it’s more valuable now that the elite skill effects are stronger, but there are still two problems.

One, making officer skills elite costs “story points”. (Without getting into detail, the key thing is that it’s a fairly limited resource – you can always get more, but that can take a while.) The problem is that two more elite skills for every officer you have adds up to *a lot* of points.

And two, it gives officers too many elite skills! If you recall, the point of those is to make the player feel a little more special. But with all of the possible officer-elite-skill boosters, you end up with officers that have 4 out 6 skills elite (or, 3 out of 5).

So, what to do here? First off, the effect is actually nice, but we can tone it down to 1 elite skill. That solves both problems, and honestly, with elite skills being stronger, the skill might be powerful enough as-is.

But it feels a little empty with just that. It’d be fun to give the skill another effect. And, continuing with the theme of making taking personal-ship skills better, maybe something that contributes to that, too. At first I was thinking of just simply tacking on some kind of piloted-ship effect to an otherwise fleetwide skill, but that didn’t feel quite right. Then, I got an idea!

What if the skill gave an additional bonus based on the number of piloted-ship skills you have? Something like:

• Affects all ships with officers, including the flagship
  • +1% damage dealt per piloted-ship skill you have
  • -1% damage taken per piloted-ship skill you have

The actual effect is generic, but I think it needs to be, at least for the concept to make sense. The idea is, you’re better at making combat augmentations based on your actual combat skills. So either it’s something generic like this – or it’d be something where the bonuses are based on the specific skills you have. The latter would involve basically re-engineering the skill system to support that, so: not happening.

There are still a few minor problems here, though. One, “piloted-ship skill” doesn’t read very well. We could say “combat skill” but that might imply “skills under the Combat aptitude” rather than “skills that benefit your personal ship in combat”. Luckily, all piloted-ship skills can be made elite – it’s an intrinsic property of this kind of skill – so we can just say “elite skill” instead. Since that’s a term directly used in the game, in many places, that should make it clear. And requiring the skill to be elite’d is not a significant mechanical change; you’d want to do that anyway.

The other problem is a 1% bonus just sounds weak and boring. This I think we can get around by just rephrasing it:

• +X% damage dealt (1% per elite skill you have)

Or something similar, where X would be the number of elite skills you currently have. A slightly bigger number, and saves you the trouble of counting up the skills – win/win!

For fun, let’s double this bonus for the flagship only. … and, coming back to it sometime later: let’s only double the “damage dealt” part. Too much stacking of “damage taken” reduction has the potential to get out of hand.

But now, new problem: the skill is probably too strong for where it’s at (the third tier of tech). Luckily, one of the top-tier tech skills – Neural Link – doesn’t quite pull its weight as a top-tier skill – so let’s swap them.

Neural Link
Another tech skill that needed a little something. Probably part of a pattern, but one that ends here!

In this case, it’s on-paper a strong skill – switch between ships instantly! Apply your personal skills to two ships at once! But in practice – it works, but it also doesn’t live up to its top-tier billing. The “apply skills to two ships” part is fine and good, but the fancy maneuvers that come to mind when you hear “instant switching between ships” are mostly too hard to pull off.

Moving it down a tier resolves that, I think – it’s still a strong skill, it still works. There’s just less pressure on it to perform at the absolute top level – and on you as a player, to utilize it to that degree.

While I was there, I took the opportunity to clean up the wording on the skill, and the associated hullmods that make it “work”. For example, the skill tooltip now emphasizes applying your skills to two ships at once – a key aspect of the skill that was a little buried before.

However, another aspect of the skill is that it lets you personally control automated ships! Normally, you have to install an AI core in one (well, you don’t have to, they just get way better if you do) and they fight on your side, but you can’t pilot it yourself. Except for with this skill!

To do that, though, you have to get both top-tier tech skills – Automated Ships (which lets you have those in your fleet in the first place) and Neural Link. This means a heavy skill investment in tech, leaving less points for personal-combat skills, so, there’s a tradeoff.

But if you can pick up Neural Link and Automated Ships right off the bat – without an extra investment in tech – this tradeoff is no longer there, and the balance shifts. The question is, is that ok?

The way you’re able to pilot an automated ship is with the “Neural Integrator” hullmod. So if we say that it’s *not* ok, an easy solution is to make this hullmod be unlocked by Cybernetic Augmentation – the newly-minted top-tier tech skill – instead. It fits well enough thematically.

Neural Integrator
To answer that question, though – we’ve got yet another rough spot to polish up. (This is one case where I’m not going in chronological order – I actually made this change pretty early on, maybe even before the elite skill effect changes.)

The Neural Integrator hullmod has a very high ordnance point cost, meaning a ship sacrifices a lot to have it – weapons, firepower, flexibility. This is mostly tuned around the Radiant-class battleship it lets you personally control. It is extremely powerful in player hands, and this serves to rein it in a bit. Unfortunately, with the addition of a Nova-class battlecruiser – that that ship has fewer ordnance points, but is saddled with the same cost, so it’s hit really hard and is not really worth using with Neural Integrator.

So: instead of having an extreme OP cost, let’s change NI to increase the ship’s deployment points instead, say by 20%. Since it’s percentage-based, the cost is affected more in proportion to the ship’s power, making the Nova a little more competitive. And this also reins in the power of the Radiant a bit more.

With that change, I think it’s ok to have the option to manually pilot an automated ship be more readily available, without a full tech skill point investment. At least, that seems worth experimenting with – and the option to move the NI unlock up a tier is always there.

Hull Restoration
And, finally, we come to Hull Restoration – an extremely useful top-tier Industry skills. It repairs your ships over time, getting rid of d-mods (otherwise-near-permanent/very expensive to remove penalties, e.g. “glitchy sensors” etc), and lets you (mostly) recover your ships without getting new d-mods if they’re destroyed.

The complaint about this one is that as you get into the endgame, it doesn’t help you much in combat. The counter argument is that with this skill, you can afford to lose ships (since you can recover them so easily), and this unlocks more aggressive and potentially stronger playstyles! The counter-counter argument is, why do this if you could invest in skills that make you stronger more directly and just not lose ships in the first place?

I think there’s some truth in both the counter and the counter-counter argument. With that in mind, what sort of in-combat bonus would make sense here? The general idea should still be “you can afford to lose ships”; that’s the overall flavor of Industry. So, I don’t want to the skill to boost ships directly. How about this:

• Pristine or near-pristine ships (with at most 1 d-mod) have their deployment point cost reduced by 10% or 5 points, whichever is less

This maintains the feel of the skill – it’s about using (and sometimes losing/recovering) pristine ships, and you get to use more of them at the same time. It also combines nicely with several other top-tier skills. For example, when used with Support Doctrine, you get even cheaper unofficered ships.

(I’ve also removed the “increased combat readiness” part of the skills; with this change, it was just cluttering things up.)

Support Doctrine
And speaking of Support Doctrine, it’s another skill that I thought might need a little help. I’m not actually a hundred percent on this one, so it’s more “see how it goes”, but – it’s a top-tier leadership skill that competes with “Best of the Best”, which is *really* good (that one lets you build more things into your ships, plus has some other bonuses).

Support Doctrine, on the other hand, gives your ships-without-officers the effects of some skills, and makes them cheaper to deploy. Right now it gives the non-elite effects of 3 skills; the change is to give it a 4th – Ordnance Expertise. This *might* make it too close to an officered ship – an unaugmented officer can have 5 skills, one of them elite. On the other hand, the Support Doctrine skills are not hand-picked by the player and it’s not an amazing combination – just a mix of things that are generally useful to almost any ship. And, if you’re picking it up, you’ll likely also pick up the skill that gives you stronger officers, along the way.

So, not sure about this change – it’s one that I’ll keep an eye on during playtesting, for sure.

(And <checks> this 4000+ word essay wraps up my little spontaneous blog post attempt! This is why I don’t usually do those.)

Comment thread here.

(P. S. I forgot one! It’s not a combat skill or a top-tier skill, so it fell through the cracks. “Containment Procedures” is a skill that reduces fuel use and lets you recover more fuel. Basically its job – as an industry skill – is to help you run a larger fleet, which the industry aptitude as a whole encourages. It’s works for that, but the fuel reduction bonus it gave is “50% or 25 units, whichever is less”. The 25 units part is fine. The problem is with the 50% part – it really trivializes fuel costs early on, skewing the feel of exploration in a way it was never meant to. So: the change there is reducing it to 25%, while keeping the endgame usefulness just about the same.)

Starsector version 0.97a is now out!

• Use exciting new abilities for getting around the Sector – Reverse Polarity and Generate Slipsurge
• Engage with new Colony Crisis mechanics with unique in-depth events that flesh out every major faction and have their own rewards (replaces Hostile Activity)
• Explore the Orion-Perseus Abyss and a new mysterious star system found deep in abyssal hyperspace
• Add a new low-tech phase cruiser (the Grendel-class) to your fleet
• Use the new “Escort Package” hullmod to amp up your destroyers and cruisers when used in combination with larger ships
• Take advantage of more powerful elite skill effects and the revamped Cybernetic Augmentation skill
• Discover more unique encounters, from castaways on the far fringe of the Sector to brewing trouble in the spacer bars of the Core

It’s worth noting that the Colony Crisis event, despite being just one bullet point, make up the bulk of the content in this update! It’s worth thinking of each faction-specific event as a new mission, and some of these are very involved, both mechanically and in terms of new writing.

As always, there are also many smaller changes and additions, including balance adjustments, polish, ship AI improvements, bugfixes, and modability improvements! There are also a couple of new music tracks used when interacting with certain entities in the campaign.

Despite being a major version change, this release is actually save-compatible, though I would recommend starting a new game anyway – there would be some oddities with the layout of the new Abyss area.

The full patch notes, and the comment thread, are here.

You can download the new version here:

(Alternate download links, please try the above first: Windows Mac Linux)

As always, thank you so much for your support!

The combat simulator in Starsector is essential to the experience – you need to be able to adjust your ship loadouts effectively, and being able to test out changes quickly is a key part of that. Imagine having to get into a real fight just to see how your new set of weapons performs! That simply wouldn’t do. This means that the simulator was added early on in the development process. This also means that it hasn’t quite kept up with the times, and was very much due for another look.

I wouldn’t say that the simulator is in a bad place – it works, it does the job it’s supposed to do – but there’s also definitely a bunch of smaller issues. For example, the set of ships available to fight against is pretty arbitrary, and for historical reasons, even contains some hand-made “damaged” versions of hulls that you can’t find anywhere else in the game. That could be partially resolved by just cleaning up the list of sim opponents, but with the number of ships in the game, most of them would have to be cut if it were to comfortably fit in the old “one list of ships” UI presentation. For reference, here’s what it looked like, before all the changes in this post:

The simulator also doesn’t give you a lot of flexibility as to the quality and behavior of your opponents. All of the opposing ships are locked to the “steady” personality, baseline-quality ships (without any negative d-mods or positive s-mods), and have no officers. In some ways it’s a positive – it gives you a pretty steady baseline to test against – but it also skews the results. Testing against the baseline sim Onslaught-class battleship is not going to reflect a ship’s performance against a highly aggressive [REDACTED] cruiser piloted by an AI core.

Design goals
Before going further, I think it’s good to step back and establish what we actually want from the simulator – or, in this case, I think it’s helpful to think of it in terms of the opposite, what we don’t want from it. And that is: the simulator should not spoil the rest of the game.

In practical terms, this means that some ships are too “special” to show up as simulator opponents at all, and that others might show up in the simulator, but require being unlocked (i.e. require being encountered in the game in some way) so that their availability in the sim is not a spoiler.

During the design process, I spent a while thinking about the details of how unlocking ships might work, couldn’t come up with answers I felt solid on, and then decided to implement the “full” version of simulator and see how it felt – and once it was that far along, how the unlocking should work became pretty clear. So, in this blog post, we’ll stick with the same flow, and talk about that after laying out how the updated simulator works.

Also – whatever the ship-unlocking mechanics are – the new simulator should not be worse than the old in terms of what’s available, even in its base, nothing-unlocked state. Don’t want to lose the forest for the trees, here; Starsector is not a game about meta-progression, and we’re trying to make the simulator better, not more restrictive.

I also don’t want to make the baseline UI for the simulator more complicated; wouldn’t want a new player to get hit over the head with it and feel overwhelmed when all they’re trying to do is run a quick test of their first ship loadout ever.

A “show advanced options” button in the sim deployment dialog seems to fit the bill here – until that’s toggled on, the new simulator just looks like a cleaned-up version of the old. The game remembers the state of this button (and of the rest of the options that it brings up), across savegames, so that it’s not a hassle for a more experienced player, either. You’d basically need to press this button a total of once, and it opens up a pair of side-panels.

Also, to streamline things a bit and to remove clutter, you can now select multiples of a specific ship to deploy by clicking on it multiple times – it cycles through “deploy x1” to “deploy x9”, and you can right-click to clear the selection. This removes any need to have more than one of the same ship variant in the simulator, and cleans up the list of ships to deploy.

Factions and categories
So, what are the new options? First off, we have ship categories on the left side-panel. The “Default” one has the basic ship set (a cleaned-up version of the current simulation opponents); the rest are categories for factions. For example, if you want to deploy pirate ships to fight against, you can select the “Pirates” category and go to town. The selected category also influences the behavior of the options on the right side-panel, but more on that in a bit.

There’s also a special “Custom” category; you can add whatever variants you like to it, from any of the other categories, if you’d like to have all of the things you personally prefer to use all in one place.

Advanced options
On the right side-panel, we have the options for fine-tuning the quality and behavior of the opposing ships. The options are fairly self-explanatory, so let’s just do a quick rundown.

Aggression
A “default” setting, and the full range of explicit settings from “cautious” to “reckless”. The “default” setting makes the aggression level be governed by the selected faction. For example, if you select “Pirates” and leave the aggression setting on “default”, the opposing ships will have the typical aggressive behavior pirate ships exhibit in the campaign.

Officers
Defaults to “none”. You can also select “some”, which comes into play when deploying multiple ships, and there are options that just put max level (for that faction) officers on all opposing ships. The officer skills will be picked in the appropriate way for the selected faction. If the “Default” category is selected, both officer skills and personality/aggression will be governed by the “independent” faction settings, which are neutral/average, and you have a choice of officer level.

Ship quality
No faction specific settings here, just the full range from “lots of d-mods” (bad) to “lots of s-mods” (good). The default is to have neither; a regular pristine-quality ship.

AI cores
Similar to officers, but only applies to automated ships. The options range from none or some cores to having a fixed type of AI core on every opposing ship. More on this when we talk about how ship unlocking works!

There is also a setting to “integrate” the cores into their ships, increasing their level by 1 and giving them an extra combat skill.

Randomized loadouts
A toggle to make opposing ships have (somewhat) randomized weapons and hullmods.

Group deployment
And, finally, there is an option to quickly select a group of opposing ships to deploy. You choose a target number of deployment points; the composition selected depends on the chosen faction – for example, if it’s the Hegemony, more capital ships will be selected, and so on.

Unlocking mechanics
Now that we’ve covered the full functionality of the new simulator, let’s get back to the unlocking-stuff mechanics. As I mentioned earlier, Starsector is not a meta-progression game, so we’re not looking for anything elaborate here, or that’s a pain for the player, or that the player particularly “works” for. The goal is to generally avoid spoilers and overwhelming a new player while being basically a non-issue for anyone that’s played the game for a while; this unlocking is something you only do once.

With that said, it’s pretty clear that we need to unlock two types of things – the actual ships, of course (or, more precisely: ship variants), but also the factions. There are a lot of “annoying details” here, something that once it’s sorted out just works and you don’t really think about, but is actually kind of a pain to get right, and I’d like to talk about these!

Unlocking factions
First off, for unlocking factions – we don’t want to show empty categories, and don’t want to overwhelm the player with too many of them. And the [REDACTED] faction, we definitely wouldn’t want to just show that to a new player right off the bat; they’re something special you’re meant to discover. (The same logic largely applies to unlocking ships, too.)

So, why not do the obvious thing and just hide the empty categories? Because the same variant might show up in different factions – for example, let’s say the same Hound-class frigate loadout is used by both the Pirates and by some top-secret faction we don’t want to show until it’s been encountered by the player – but if we did the obvious thing, it would show after the player unlocked that ship for the pirates, which would both be a spoiler and a bit confusing.

Alright, so factions have to be unlocked separately from loadouts. Is just encountering a faction fleet in the campaign enough? I’d say not; going back to the [REDACTED], just popping into a high-danger system and having the faction pop up in the simulator would be a bit of a spoiler. Fighting against the faction seems like the cleanest way of doing it – once you’ve done that, having it be available in the list of simulation opponents is by definition less of a spoiler.

Ok, great, now that we’ve settled that, let’s move on to unlocking ships! … except, wait, there are actually a bunch of problems with this approach.

Some fleets in the campaign have one faction be used for selecting the ships that are in the fleet, and are then set to belong to a different faction when they’re actually spawned. Some examples of this:

Bounties! Some of the bounties are “deserters” – e.g., a Hegemony deserter fleet would be using Hegemony ships, but would be assigned to the “pirate” faction.

The Lion’s Guard – an elite subfaction of the Sindrian Diktat – uses a special set of ships, but the fleets are flagged as Sindrian Diktat fleets.

Mercenaries – there is a special “mercenary” faction, used to create elite mercenary fleets, which are then spawned as “independent”, or perhaps belonging to another faction. The “Mercenary” faction would be very nice to unlock in the simulator, but it’s not one that fleets in the campaign *ever* belong to.

Occasionally, other faction-specific fleets will be flagged as independent for in-fiction political reasons, such as Tri-Tachyon “commerce raiders” that use the Tri-Tachyon ships and doctrine but fly the independent flag.

There’s also *another* problem, related to faction unlocking being a meta-mechanic. Let’s say you’re friendly with the Hegemony, but want to unlock their faction/ships in the simulator. You could save the game, fight one of their fleets, get the unlocks, and then reload. The problem isn’t that you can do this to get unlocks – rather, the problem is you can do this, but it kind of feels bad. You can reload the save, but not your recent memory – you’ve still had the experience of attacking a friendly fleet, and it can jar you out of a role-playing mindset. This is fundamentally unsolvable because unlocks are a meta-mechanic that carries across saves, but I think this can be mitigated – and, in fact, the other problems suggest a good approach.

Solution
And that approach is, we need to figure out what the “right” faction is for a fleet; we can’t just look at what faction it currently is for that. It’s possible to try to store which faction was used to create the fleet in a variable somewhere, but that would be a bit of a pain – there are so many ways to create a fleet, and some of those would certainly get missed.

Instead, I wrote some code that matches the ship loadouts in the fleet against the ships used by all of the valid factions that show up in the simulator, weighing the fleet’s nominal faction a bit more – and the highest scoring faction is the one that gets used.

So, those pirate-flagged Hegemony deserters? They unlock the “Hegemony” faction. Lion’s Guard fleets? They unlock the Lion’s Guard faction, despite bearing the Sindrian Diktat flag, and despite the Lion’s Guard being a faction that does not explicitly show up in the game. Likewise for mercenaries and all the other false-flag fleets.

This also helps with the “attack some friendlies then reload” problem. Like I mentioned, I think it’s inherently not 100% solvable – but being able to get the same unlocks by fighting deserters (and in some cases other types of fleets) makes it so you don’t have to do this, if you don’t mind delaying some of the unlocks a bit. And the as unlocks are something you only do once, it’s not a huge problem in the first place – but still, I think having this way around it is nice; you’re not forced to compromise your immersion.

Unlocking ships
This is closely related to how unlocking factions works, and at this it’s pretty clear that you unlock ships (or, rather, specific variants of ships) by destroying them. Design-wise, I thought this through as a whole; it wouldn’t make a lot of sense to think about factions and ships separately. But, I think it’s worth talking about a few approaches that I’d considered and discarded.

One idea was using “learning blueprints” as the trigger for unlocking ships. It makes some in-fiction sense – if you’ve learned how to produce a ship, you might know how to simulate it in combat (though, with how production works – with blueprints being fed into a nanoforge, with the actual process being poorly understood, this isn’t such a given).

But more importantly, it doesn’t make much in-game sense. Right-clicking on a blueprint package to learn how to build a bunch of ships doesn’t mean you the player familiar with those ships, and that’s really the main criteria. There are other problems, too – blueprints are for ships, not for specific ship loadouts (for example, the Luddic Path has a bunch of specialized ship fits, and it wouldn’t feel right to unlock those without encountering them specifically), and also some of the ships we’d like to unlock – e.g. the [REDACTED] – can’t be produced and so don’t have blueprints at all. So, that was a no-go, just an early idea.

Another idea I’d considered briefly is requiring a ship to be destroyed multiple times for the ship to be unlocked in the simulator. This just makes things more complicated, both for the UI (needing to display this progress somewhere) and for the player, and there’s no real upside here – going back to what the goal is, it’s to *not* make this a hassle. This kind of thing might work in game that’s about meta-mechanics, but this isn’t one.

AI cores
And now that we’ve talked all this through, let’s get back to the AI cores simulator setting – the one that lets you assign AI cores to opposing automated ships, and applies to the [REDACTED] faction. Having this faction in the simulator at all is a bit of a spoiler, so I’m making a bit of an exception here – the only AI cores that can be assigned to opposing ships are ones you already have in your possession (in your  cargo, or, if docked at a planet, also in planetside storage). If you have two Alpha Cores? Great, you can face two ships with Alpha Cores at the same time, but no more than that.

This is, of course,, something that does not carry over between saves, but the nice thing is that it creates a dynamic where the more you’ve fought the [REDACTED] (and thus: gained more AI cores), the better you’re able to simulate strong [REDACTED] fleets.

This is both thematically nice and feels like a good balance as far as not having the simulator spoil things. You can’t just simulate a [REDACTED] fleet full of AI cores unless you’ve already faced something similar in-game. Plus, carrying around AI cores is illegal with a number of factions, and might get you in trouble, so that’s an added bonus, as far as I’m concerned!

Settings
With a feature like this – that makes you unlock things that, if you’re an experienced player, you’ve probably experienced – I think it makes sense to add some settings that short-circuit the process. Thus, there are two settings – accessible by editing the config file (so, not an in-game setting): “allStandardShipsAndFactionsUnlockedInSimulator” and “requireAICoresInCargoForSimulator”. Both do what they say; hopefully it’s self-explanatory.

I don’t think these warrant prime real estate on the in-game settings screen – not even close, if we’re being honest – but it’s good to have, just in case.

Modding
Making sure this new system plays nicely with mods was another design goal. First up, the obvious (but perhaps easy to miss, if one is too tunnel-visioned on just making the system work) – it’s possible to unlock modded ships, then re-run the game with the mod disabled. The game should handle this – it shouldn’t crash when it sees a now-invalid hull ID, and it shouldn’t forget that it’s been unlocked, for when it’s run with that mod turned back on. That does (or should, anyway! I tested it) work.

It’s also possible to include/exclude specific factions and ships from being available in the simulator.

The actual code that drives the new simulator options is heavily customizable, too. The specific config settings are provided by plugin code that could be replaced by a mod option. For example, an enterprising modder could add an “install Tachyon Lance in every slot, including small ones” option, or something perhaps more responsible.

Java 17
And, in unrelated news, the next Starsector release will be using Java 17, instead of the currently-used Java 7. What does this mean to you?

• Improved performance – somewhere around 30% higher frame rate, possibly more depending on the machine
• A more stable framerate
• Improved save/load times
• No need to switch to a newer Java version when running the game with lots of mods

A big thank you to Himemiko for all the help with the upgrade!

(Why not Java 23, you ask? Well, it’s not exactly “out” yet. And Java 17 is the latest version which supports 32-bit systems, which isn’t a huge deal at this point, but is nice nonetheless. Also, Java 21 – the latest available prior to 23 – seems to actually have  somewhat worse performance than 17.)

Comment thread here.

Since the previous release, I’ve been working on a bunch of quality-of-life features. This wasn’t exactly planned – at least not specifically for right now – but these were all things that had to get done at some point, and now is as good a time as any. Perhaps a better time than most, even, since I’m feeling oddly motivated to work on these. Part of it is upgrading from Java 7 to Java 17; it’s nice to see the game running more smoothly – and in a similar vein, it’s satisfying to bring some older parts of the game up to par.

Save / Load UI
First up is the way the game handles savegames. To be clear, I’m talking about just the UI parts of it here; the behind-the-scenes “how a game is saved” mechanism remains almost exactly the same.

A quick recap of how it currently works: you get a save slot, and you can use a “save copy” option in the menu to make a copy of that slot. There’s also quicksave/quickload. It’s just about the minimum amount of functionality necessary for things to “work”, and there are no bells and whistles – you can’t add a description to a save, for example. The UI itself is also a bit messy, in large part because it’s old and, frankly, I’ve gotten more experience with UI over the years and can generally do a better job of it now.

Let’s just jump into the changes, without belaboring the “why” too much. So:

To start with, I’ve updated the overall look and feel of the UI to make it cleaner, and since it’s now more compact, you can see more saves at the same time. Also, if you’re ever had trouble with a corrupted save, you’ve probably found out that the game keeps a backup of the previous time you’ve saved, and you can go and rename some files to make the game load it. Now, the game will just automatically try to load the backup if loading the primary savefile fails for any reason.

Save As
“Save Copy” is replaced with “Save As”, which is more intuitive as to the expected behavior. You can save to a new slot, or overwrite an existing slot.

When you do “Save As” (or regular “Save” / “Save & Exit” from the menu), you have the option to type in a brief description for that save. If that’s left blank, it defaults to showing your fleet’s current location, e.g. “Hyperspace” or “Gamma Terror Star System”. The text entry field is pre-selected, and you can immediately type in a description, then press Enter twice – once to finish text entry, and again to save. Or, you can just click “Save” button if you don’t care about a description.

If there’s already a description in the text box, you can press Ctrl-Backspace to delete one word at a time (this is actually a standard UI shortcut that works pretty much anywhere, e.g. in most/all? browsers), or you can press Shift-Backspace to clear the whole field (this one is Starsector-specific).

An initial version of this dialog had the entry field be more prominent – the standard Starsector text field, with a full border and a background. David pointed out that this made the description feel less optional, and suggested what you see now, which I have to agree, looks much cleaner!

When doing “Save As”, you can choose whether the new save becomes the “current” one – for quicksaving, quickloading, and the “Continue” option from the main menu. The expected behavior of a “Save As” action is that the new save becomes the current one, and that’s the initial default (though the game remembers the state of that checkbox). But, if you’re trying to save off a checkpoint – for example, “Near hypershunt, about to fight defenders” – you wouldn’t really want that save to become the current one, you want to put it to the side and continue with your original save, and I wanted to make this easy to do.

(Another way to handle this would be to have quicksave save to special quicksave slots, but with that approach you either end up with a ton of quicksave slots littering both the dialog and your harddrive, or – if they get recycled for different campaigns – with the risk of losing a game. Having a “make current” checkbox seems cleaner all-around.)

Limited autosave
One of the benefits of the upgrade to Java 17 was a pretty significant improvement in save/load times. That said, though, saving the game still takes a couple of seconds – let’s say 2-4 for a vanilla save, more or less. It’s obviously going to depend on your CPU, your harddrive/SSD, and so on; this is extremely approximate.

So, given the save time we’re working with, a pervasive, “you don’t need to save manually” autosave that triggers every time you leave a market, enter a star system, fight a battle, salvage a station, or do anything else of significance – that’s off the table; we’re not even aiming for that. Instead, the goal is to limit the amount of progress that can be lost, by a player that just plain forgot to save for a long time – hence, calling it “limited autosave” here;  I don’t want to oversell it.

The way it works is, autosave will trigger approximately once per the autosave interval, which can be configured in the in-game settings menu, from 5 minutes to an hour. Autosave can also be turned off entirely in the same menu.

The exact timing of when an autosave will happen depends on what’s going on in-game; it’s more likely to trigger after a jump to a new location, but won’t trigger if there’s a strong hostile fleet nearby (mostly to avoid interruptions/distractions), or when your fleet is traveling extremely quickly (such as mid-slipsurge), and a few other checks like this. The timer is also reset any time you save manually, or load a game.

Autosave rotates through 3 save slots (which are labelled in the save/load dialog), and will NEVER overwrite a manually-created save slot. So, even if it saves at the worst possible time somehow, it’ll just be a useless save, it won’t do any damage. It’s also disabled entirely when playing in iron mode, since that doesn’t allow for multiple save slots. Having it run quicksave instead in this case is a possibility, but on the balance, I’d rather stick with it never ever touching a manual save slot, for any reason.

When playtesting this, it felt intrusive to have the save bar pop up in the middle of the screen when it triggers – so, I shrunk the bar moved it the upper right corner of the screen. Surprisingly, this actually made autosave feel faster. I think it’s because it doesn’t interrupt what you’re looking at, so the time that’s taken up by it running isn’t completely wasted, you’re still taking in the surroundings. Possibly the bar itself being smaller contributes to it feeling faster, too; I wouldn’t be surprised if there’s been psychological research on the subject.

(One problem with this was that it highlighted a minor longstanding issue – the screen rapidly switching between the previous two frames while the save is in progress. Not a huge deal if you’re expecting it and just looking at the save bar in any case (which isn’t affected by this), but much more of a problem if all of a sudden the main view you’re looking at starts to vibrate. So, I fixed that up.)

Intel map markers
Occasionally when exploring, you’ll find something that you’d like to come back to, but that the game won’t automatically make an intel item for. Perhaps it’s a planet you’d like to colonize later. Perhaps it’s a derelict capital ship you’re like to recover later, when you can actually afford it. To help keep track of these things, you’ll be able to create “map markers”.

To create a marker, you open the map, left click and hold on the target entity, and select the “Create intel map marker” menu option. You can select an icon, and type in a name and an optional bullet point. The amount of text you can put in is very limited; it’s just meant to be a brief reminder.

The marker is an intel item that shows up under the “Fleet log” tag in the intel screen (and also a new “Markers” tag); there’s a checkbox to open the intel screen immediately on creating the marker. From there, you can edit or delete the marker as you like.

New intel
Doing this made me think about what you’d want to use the feature for, and there are a few things you find that you would pretty much always make a marker for. So, the game will create those for you automatically (some light spoilers here):

• Remnant Nexus (when discovered)
• Domain-era Cryosleeper (when interacted with)
• Coronal Hypershunt (when interacted with)
• Wormhole Termini, with arrows on the intel map showing connections (when deployed or interacted with)

Salvor’s Tally
You’d probably also want to use markers to keep track of salvage you’ve found, but decided to leave for later, say due to running out of cargo capacity, or running low on fuel or supplies and having to return to the core worlds. That would feel like busywork – but I also wouldn’t want to clutter up the intel screen with auto-generated items for every single derelict Kite-class shuttle you’ve found floating out there in the black.

So, a new intel item – a “Salvor’s Tally” – that keeps track of *all* the potential salvage in a star system. Orbital installations, derelict ships, debris fields, planetary ruins, and so on, tracked in one intel item (per system) for easy reference – and for making sure you didn’t miss something that you’d detected but perhaps not actually noticed.

This intel is automatically created for the star system after 1) you’ve found something  salvageable, and 2) it’s been at least an in-game day since you’ve either detected something salvageable, or salvaged something. The goal is to avoid spamming the player with Salvor’s Tally intel whenever they find something and just immediately salvage it. For example, if you find a ship graveyard with a bunch of derelict ships, you would normally just salvage them one after the other, and unless you leave one for later or take an unusually long time in between, a Salvor’s Tally won’t pop up at all.

The tally intel goes away when you exit the star system, if there are no salvageable entities (that you know of) left. The tally shows up under both the “Exploration” intel tag, and a new “Salvage” tag.

And, finally, to make life a little easier – if there’s just one source of salvage remaining, the “show on map” from Salvor’s Tally button takes you right to it, instead of just opening the star system map. (This change brought to you by: “me spending *way* too long trying to find the one remaining derelict in a star system, even though I’d already technically “found” it. It was hiding right next to a jump-point.)

Pinned intel tags
One of the issues with the current intel screen is the tags at the bottom can seem to be in a kind of random order, and it can take a few seconds to find the tag you’re looking for. Let’s say you’re looking for “Bounties” – is it alphabetical? Doesn’t *look* like it, but then at some point it is, and it’s just a bit of a confusing/disorienting moment every time.

The reason it feels this way is that certain intel tags – the more “important” ones (according to yours truly) – show up first in the tag list, followed by the rest of the tags. But looking at it at a glance, they all look the same, so you can’t tell where “pinned, fixed order tags” end and the “rest of the tags, alphabetical” begin.

So, what I did is change the look of the “pinned” tags – making them more prominent – and put them in a separate section. In addition, the “pinned” tags will always be shown, even if they have zero intel items under them allowing you to remember where each of those tags actually is.

Combined, these changes – for me, at least – eliminate that momentary confusion when trying to find a tag. It can still take a second if it’s in the middle, alphabetical section, but it feels much better.

Oh, and also – there’s now a shortcut (“Q”) to select the “Major events” tag. That’s the one for important stuff like Colony Crises, Hyperspace Topography, and TBD in the future.

Other intel changes
Clicking on a star takes to you the star system map, and you can go back to the intel screen by pressing S (which is the key to show something on the map/return to intel when looking at an intel item). The idea is to smooth out the map/intel integration a little bit. It’s tempting to want to just combine the map and the intel screen – it seems like a fairly obvious “it should work that way” – but it’s trickier than it seems. I think it’d end up being fairly close to the current implementation, regardless – shifting the map between two modes vs shifting between two UI tabs. It’s something I’m keeping in mind, but in the meantime: a quick and easy change to make life easier.

“Fleet log” vs “Exploration”
I also had another look at the Fleet Log and Exploration tags; it’s been a while since the original implementation of a lot of the intel items, and it didn’t look like there was a whole lot of rhyme or reason for how things ended up assigned to either (or both) of these.

So, reconsidering what these mean:

Exploration: “things that likely lead you to explore places you haven’t been yet”.

Fleet log: “things you’ve found / learned about”, and also a bit of a catch-all for miscellaneous things that don’t fit elsewhere. (Hey, I didn’t say it would be perfect!)

So, for example, the new intel items – Remnant Nexus, Wormhole Terminus, Cryosleeper, etc – go under “Fleet log”, which is actually pretty sparsely populated now.

On the flipside, stuff like “you found out there’s a research station in some other unexplored star system” goes under “Exploration”.

I’m not 100% sure about where the new Salvor’s Tally is going to go – right now it’s under “Exploration”, too, on the assumption that since you haven’t cleaned that system out, there’s probably still some exploring to do. Classifying things cleanly is basically impossible. This is one of the nice things about a tag-based system, though – you can put something under multiple tags and make it easy to find anyway. In this case, a new “Salvage” tag for Salvor’s Tally.

Survey data intel
I also removed all the “found out about a planet with <interesting condition>” or “got systemwide preliminary survey data” breadcrumbs you’d find during salvage. These seemed like a good idea during the initial implementation, but in practice, they don’t actually matter much at all.

The only planet-related info you’ll find now is full survey data for a planet, and the quality of the planets you find out about this way is much higher – generally only Class IV or Class V, with a few exceptions.

I’ve also spruced up Survey Data intel item, to make it both more useful and more visually appealing. Also, critically, you can spin the planet by right-clicking and dragging it; this is Perfectly Safe.

And, finally, David added lots of new icons for intel items that previously shared the Fleet log one – it makes the screen feel much more lively, if I do say so myself!

Comment thread here.

First off: what the heck is the Codex? It’s basically an in-game encyclopedia where you can look up ships, weapons, and so on. The current implementation is very, very old and and this point really showing its age – frankly, it’s clunky and not very useful, but on the bright side, it’s also not strictly speaking a required feature, so it was fine to leave it be for a while. I’ve been on a roll with QoL work lately, though, and the game is certainly far enough along now for a proper Codex rework, so I decided to jump into it – I’d have to do it at some point!

I started working on the Codex update with a sort of standard question to get my bearings, design-wise – “why is this in the game?” That’s a question with sharp edges, because if there isn’t a good answer, then maybe it should be cut instead, and the time and effort put into other things. Obviously, that didn’t happen, or we’d have a much shorter blog post!
However, I didn’t have a great answer at first. “Some ships and weapons have longer descriptions than what fits in the tooltip, and it would be nicer to read them in a larger font, besides” and “it’d be nice for the player to look up stuff they don’t have access to in-game right then” – which, alright, that’s not *terrible*, but not great either.

Fundamentally, though, the concept of a “Codex” is just fun. It’s a place for the game to showcase a lot its content, though it needs to be done in a way that doesn’t spoil it. And, of course, if it turns out to be an actually-useful reference, that would be ideal. So, it’s definitely worth working on, and I started on the overhaul without having a very specific idea of where it would end up. Sometimes, you just don’t know what’ll spark until you actually see it in the game.

Related entries
In this case, what really got things rolling is the idea of having a section for “related entries” that showed you, well, entries that are related to the one you’re looking at. The initial thought was, when viewing an entry for a ship, to show its built-in hullmods as related entries you can click on to check out. That sounds good – it’s a way to learn about a ship without doing a ton of digging around tracking all these entries down manually – and I hadn’t really thought about it beyond that.

So, I did that – put together a basic Codex UI – all new code, but the same basic layout as before, with a list of categories/entries on the left, and detail on the right, that just makes sense – and added ships and hullmods. What I didn’t expect, and what made the whole thing take off in terms of usefulness, is making the relationships go both ways – the entry for the hullmod would show you all the ships it’s built into.

This is actually really interesting information that’s hard to get at otherwise! You can see, for example, every ship that has Rugged Construction built in. Or the Ballistic Rangefinder, or all the Automated Ships. Doing the same linking with ship systems lets you easily see all the ships the share the same system.

It’s a qualitative  difference – it felt like it let me get a clearer picture of all the stuff that’s in the game, and how it’s connected. That was really exciting! And I think that’s where the primary value of the new Codex is, in letting you explore the relationships between things. It’s not just “let me get a little bit more info about the thing I’m looking at”. It’s “let me see how it fits in with other things, and learn about those, too, if I want to”.

This solves a bunch of minor but nagging problems with the UI – “I’m looking for a ship to buy, what do these built-in hullmods do?”, or “I’m looking at a skill and it unlocks a new hullmod and an ability, what do those do?” Now, there’s a way to find out!

With that, let’s stop with the how-it-came-about and dive right into how the new Codex works. First, I’ll go over the major features, and then spend a bit of time going through each category; some of those have more noteworthy things to talk about than others.

Codex navigation
As I mentioned, it’s the same basic layout as before, with an entry list on the left and a space for details on the right. The basic categories are Ships, Stations, Fighters, Weapons, Hullmods, Ship systems, Special items, Industries, Commodities, Stars & planets, Planetary conditions, Skills, Abilities, and Gallery (more on these later).

The UI keeps track of the history of the entries you’ve looked at; you can go back and forward through it by pressing the on-screen buttons, the arrow keys, and the Q/W keys. For example, if you select one ship and then another to compare their stats, you can press Q and W to go back and forth between them instantly. Or, if you’re looking at the entry for a ship and click on a related hullmod, you can press Q (or any of the other options) to get back to looking at the ship.

If the entry is longer than what fits on the screen – meaning, there is a scrollbar – the history remembers the position of the scrollbar, so you go back to *exactly* where you were. The goal is to make navigation smooth and painless, so there’s as little barrier as possible to exploring the connections in the Codex.

There’s also a button to go up to the parent category, with similar shortcuts. Right now the top level has all the categories, and none of the categories have nested sub-categories – just entries – but nested categories are supported, in case that’s needed in the future. And, there’s a button to open a random Codex entry – if we’re being honest, that one’s just for fun.

Most categories have a set of tags – based on the entries that are in them – that can be used to filter the list. For example, you can choose to see all of the Destroyer-class ships that are also Low Tech, or all of the weapons that deal High Explosive damage and are also Beams, and so on.

As I mentioned earlier, each entry has a “related entries” list – it’s the same UI as the main list, just embedded in the entry’s detail, generally on the right side of it.

And, finally, there’s a search feature that searches through the entry names. The entries whose names start with the search string are shown first; other matches are shown later. This is mostly just there so you can go to a specific entry more quickly – open up the Codex, press Ctrl-F, type in “ons” (the search is not case sensitive) and you can select the Onslaught’s entry in a few seconds. The list of search results is updated immediately as you type.

Codex integration
So we’ve got something that’s useful, but how do you actually get to it? There’s a Codex option in the main menu and the campaign menu, and a button you can press to show you the entry for a ship – from the fleet screen, and from combat. That was good enough when the Codex was more of a “you’re really digging deep for a bit of extra backstory” proposition, but for a feature with more immediate usefulness, that’s just way too much of a pain to access. It needs to be smooth and slick! It needs to be available everywhere, instantly!

Thus: pressing the F2 key pretty much anywhere in the game will instantly bring up the Codex. This works mid combat, while in another dialog, just – anywhere. In addition, in many screens  this action is context-aware and will open the Codex to the right entry immediately. For example, pressing F2 in the refit screen will open the entry for that ship, pressing it in the character screen will open the entry for the currently displayed skill, pressing it in combat while targeting a ship will bring up that ship’s entry, and so on.

In addition, when viewing a tooltip for any of the things that have related Codex entries, pressing F2 will bring up that entry. For example, you might mouse over an Alpha Core in your inventory, and press F2 to open the Codex directly to it from there. Tooltips that support this have a “Press F2 to open Codex” prompt at the bottom.

The goal is, again, to make the interaction flow as smooth as possible. As in an earlier example, if you’re looking at a skill and want to know exactly what the hullmod it unlocks does, you can press F2, click on the hullmod in the related entries section, and then press Escape to get out of the Codex and right back to what you were doing in the character screen. It’s fast, it’s always there, and you don’t need to stop what you were doing to access it.

Unlocking Codex entries
It’s important for the Codex not to be a spoiler, so some entries – for example, [REDACTED] ships, or special items you might find, or even AI cores – need to be unavailable at first. On the other hand, it shouldn’t be a grindy slog to unlock the Codex into a useful state, so most things start out unlocked. If it’s something you could find just by browsing a typical colony market, chances are it starts out unlocked. If you’re curious, the Codex has around 800 entries total right now, a bit under 200 of which start out locked.

For the entries that are locked, the way to unlock them is generally to either 1) have the item in your possession, or 2) look at the tooltip for that item. The latter is enough to say that the player is aware of the thing’s existence now and showing the entry won’t be a spoiler; I don’t want the process to be more onerous than that. For ships in particular, encountering them in battle will also unlock them for the Codex, so you wouldn’t have to mouse over every enemy just to make sure they got unlocked. Once an entry is unlocked, it stays unlocked across all of your saves.

A very few special ships don’t have Codex entries at all, but for example even the Ziggurat does have one.

For veteran players, there’s a setting in the config file that will just unlock the entire Codex. And for players that are bothered by the “Locked” entries just sitting there, mocking them – there’s a config setting to hide those.

Now, let’s take a closer look at all the categories! I won’t talk about every single one, just the ones where there’s something to say beyond “yep, it’s there”.

Ships
By default, the Ships category shows the base hulls – that is, the ship with all of its weapon slots empty (except for built-in weapons), no hullmods (except for the built in ones), no fighters, and so on. You get to see the ship in its basic state with its stats unaltered by hullmods and other loadout choices.

But, if you’re opening the Codex from the fleet screen or from the refit screen, or anywhere similar where you’re looking at a specific ship, then it *will* show you the details for that specific ship and its loadout, including “related entry” links to all of the weapons and fighters it has mounted, and all of the hullmods it has installed.

One of the tricky parts in making this work was the layout of the detail entry – the stats panel that’s in the ship tooltip is too wide to fit in the space available, with the list on the left and the related entries on the right. So, I ended up squishing it down a bit, which required shortening some of the labels in the stats panel. For example, “Fuel cost / light year” became “Fuel cost / ly”, “Recovery cost (supplies)” became “Recovery (supplies)” (that it’s a cost is hopefully clear from the context), and so on. In the screenshots, it might look like there’s plenty of room, but sometimes the values can be much longer than normal. For example, instead of “10.0”, the maintenance cost might be “3.5 (-6.5)” if it was modified by a hullmod, etc; below is a screenshot where the values take up more space.

This all sounds like such a minor thing to worry about! And in some sense it is. But at the same time, little details like that matter when trying to make a UI layout actually work; it’s more important than it perhaps sounds. It’s minor, but it also *has* to work – and at first, I wasn’t even sure if I’d be able to make it work out!

Stations
This category shows orbital stations and similar! I thought about just rolling those in with ships, but ultimately it felt better to keep it separate. Each station is linked to the modules that it uses, and you can click on those to view them individually.

Like with ships, when viewing a specific station, it will show you the actual loadout instead of having it be an empty hull. And, incidentally – the Ships category supports modular ships (which are fairly similar to stations in terms of the implementation), though right now this only comes up for mods.

Fighters
This was one of the more straightforward categories to implement, The data panel fits nicely alongside a display showing the fighter wing, and leaves just enough room for the related entries list on the right. Yes, worrying about the minutiae of the layout is a recurring theme!

The nice thing here is all of the hullmods and weapons the fighter uses, along with its ship system, are related to the fighter entry, so you can very easily dig into the specifics of its loadout.

Weapons
With weapons, the layout got trickier. I’d love to have put the related entries list closer to the top, but couldn’t find a good way to lay out the stats panel and the description text in that case. They don’t all fit next to each other – the text gets way too narrow. Putting the text and the stats in a column doesn’t look good, either – the stats don’t take up enough horizontal space.

I also wanted to make sure the stats were always in the same spot, so it would be easier to compare them when flipping between two entries, so that was another layout constraint. In the end, we’ve got what you see here, which I’m quite happy with, especially since weapons tend to not have too many related entries on average.

Something you might have noticed here, and in some of the previous screenshots, is a list of factions under the description. In the case of weapons (and hullmods), it’s a list of factions that more commonly sell them – not a list of all the factions that use the weapon. For ships and fighters, it’s all the factions that use them, so it’s less of a guarantee that you’d be able to find them for sale at their colonies, but still a useful bit of information. A tooltip when you mouseover the faction explains the distinction.

It’s similar to the related entries section in its role – it helps link the item the entry is about with the rest of the game world. And hopefully it will help answer all the “where do I get this weapon” questions that seem to come up quite a bit.

Hullmods
The detail for the hullmod entries is the hullmod tooltip, spruced up a bit, and augmented with a bit more info – and of course, showing what the hullmod is related to – the ships that have it built in, the skills that unlock it,  some weapons that it might particularly benefit.

I’m rather pleased with how the hullmod tooltips look here with just a larger font and a few minor tweaks for some specific tooltips!

Ship systems
This one’s a bit special in that you don’t unlock ship systems for the Codex – rather, they become unlocked if any of the ships using them are unlocked. Also, ship systems do not have full-color icons – just the grayscale ones used in the combat UI – but giving them a color works just fine for showing them in a list here, and even makes it more immediately clear that something is a ship system.

At first, I just showed the basic system description in the entry, but that wasn’t very helpful (even if most of the value comes from the links), so I ended up adding a “System data” section, showing all the stats such as flux generation, cooldown, etc – and a more detailed “effects” section, giving some number about what the system does.

Special items
This one’s got colony items, AI cores, blueprint packages (linked to everything in them!) and similar. One of the few categories that starts out mostly locked. For colony items, you can see what industries they slot into, and what conditions they interact with.

Skills
A minor but I think interesting detail – most categories are sorted alphabetically, but in the case of skills, they’re sorted in the order you see them in the character screen, to make it easier to navigate. The main usefulness here is being able to check out the related hullmods and abilities – though just being able to read the skill’s effects in a larger font, without having to keep your mouse over the skill button, is nice too.

Gallery
This category has all of the illustrations you encounter in the game! Most of them start out locked, and they are unlocked simply by seeing them somewhere. You can zoom in a bit by mousing over the image. It’s a bit of a hard hat area right now; still needs some proper names for each illustration – the ones you see in the screenshot are placeholders.

Modding support
The Codex is highly moddable – it supports fully custom entries, new categories, a nested category structure, and custom tags for every category. Modders also have control over what’s unlockable and what’s not shown in the Codex at all. The linking between entries is mostly automated, but supports manual links being made for associations the automatic code doesn’t pick up.

All in all, I’m very happy with how the Codex overhaul turned out! It’s gone from being something that was almost outside the game to playing an important role and being an integral part of it. I can’t wait for you to get your hands on it and see for yourself!

Comment thread here.

The next update comes with new music for one of the key early locations in the game, the university space station – Galatia Academy. Most locations and encounters rely on background music shared by the faction the player is dealing with, but Galatia Academy will be the first location to get a unique piece of music not used anywhere else in the game.

As a composer this is very exciting for me because for the first time I get to move from a broad, zoomed out perspective of planets, star systems and large factional groups to the up-close intimacy of airlocks, hallways, private rooms, and most importantly: individual people!

Why is this distinction important in the context of a soundtrack? It boils down to the difference between describing what a group or faction is like and what an individual person is like with music.

Put simply, faction music, if it wants to be effective, is limited to conveying the one or two large common denominators that members of that faction share. The hegemony is bureaucratic and militaristic, and the music is all about that combination of traits. Deviating from these central characteristics by adding complexity or nuanced details into the musical texture usually ends up diluting the main point instead of providing interesting depth. This is because, in the wide variety of gameplay situations the music might be used in, complex or ambiguous information has a harder time finding a logical connection to something the player is at that moment experiencing. An unexpected and oddly dissonant chord change in the faction music doesn’t make sense or connect with anything when all you’re doing is encountering the same Hegemony patrol dude who confiscates your cargo of harvested organs like he always does.

Just like film music, game music is at its best when all or most of its elements consistently relate to or “attach” themselves to aspects of the imagined world at hand.

So what’s different about Galatia? Well, with a unique piece of music connected to a location where the player is mostly in contact with just one or two very familiar (and dare I say iconic?) non-player characters, there’s a broader field of things for a composer to experiment with. Individual characters are more accepting of ambiguous, nuanced or complex musical information because that information only has to believably apply to them, not the entire faction or group.

In contrast to film, the interesting curve ball that game music throws into the mix is that where a filmic scene of meeting Academician Sebestyen followed by private talks with Provost Baird would have music that changes, possibly quite radically, from portraying the former to the latter, the corresponding game situation has background music that has to encompass *both* into the same piece of music. Within the context of games the music is “unaware” of when exactly the player moves from speaking with Sebestyen to speaking with Baird. Thus, ideally, the music would cover both bases regardless of what specific part of the music was playing at any given moment.

If this simultaneous multi-functionality of game music sounds like a tall order … it is! Impossible to perfectly and consistently pull off, in fact. But limitations and difficulties tend to lead to creative problem solving which can lead to very interesting results, and I’m here for it!

Case in point: the harmonic progression of the new Galatia Academy music. It consists of fairly wild oscillations from a bright, optimistic major tonality to foreign scale degrees (in relation to the established key) that are dark, chaotic and unpredictable. A little like the captain’s encounters with Sebestyen and Baird. And not unlike Galatia Academy itself, balancing between the ideals of scientific progress free from politics, and the messy reality of having to involve fallible, flawed human beings in all of its endeavours.

Here’s a piano arrangement that serves as a showcase of the underlying harmony that’s built on alternating “Sebestyen/Baird” chord pairs.

The first two chords are bright and optimistic, with a gentler downward melodic line that reminds me of the mutual (!) waving of hands the captain shares with Sebestyen early in the Galatia quests. The two following “Baird” chords move to remote scale degrees that sound darker, with an ambitious upward line that seems to want to reach ever higher.

The latter half of the piece starting at 0:34 is a further extension of the Baird theme. It moves to obfuscate the tonality of the piece and produces an effect of not being able to exactly tell where the music is moving towards, which can feel unsettling and even scary. This harmonic unpredictability within an otherwise orderly rhythmic pattern is my attempt to convey Baird’s cold, rational approach to her volatile ambitions.

I hope these subtle musical colorations manage to come across to players, subconsciously if not otherwise!

The piano arrangement is where the composition process often starts, but the final version naturally needs to have completely different instrumentation in order to sound like something from the Persean sector.

Here’s the final, in-game version of the Galatia Academy location track:

You can also check these out on my SoundCloud page here:

http://www.soundcloud.com/StianStark

Thanks for listening!

Comment thread here.

I’ve been working on stuff that I can’t talk too much about since that would spoil it, but there are some QoL improvements I’d made a couple of months ago that I wanted to talk about, but hadn’t had a chance to just yet. Talking about it so much after the fact is a bit tricky – I don’t remember all that was going through my mind as I was working on it. I did take a bunch of notes at the time, though, so hopefully that’ll refresh my memory!

The old planet list (that is, the one in the currently-released version of the game) is one of the older pieces of UI in the game, and it’s definitely showing its age. Part of the problem is that I’d designed it around the same time as the initial implementation of colonies – possibly even before colonies – so while I had some ideas about what might important to show or filter on, it was more speculative and not based on “hey, this is what actual players playing the game need out of this screen”. But at this point, there’s a lot more information to base a redesign on!

Planet list
First up was (if I remember right – it’s the first item in my notes, anyway) reworking the planet list itself. The main changes are making it a little more compact, so we can get more planets on the screen at the same time, and tweaking the columns. I removed the “survey cost” column (which wasn’t very useful), and instead added one that shows the number of stable locations in the star system the planet is in – which matters quite a bit for a potential colony.

I also rewrote it to use the new “UI table” widget – the original implementation was from before I’d wrote that general-purpose code, so it looked very similar to it but wasn’t quite consistent with tables in the rest of the game. Now it is, and looks just that little bit cleaner. The screen is now centered when playing at a larger resolution, and the list takes advantage of some of the extra available space by making some of the columns a little wider.

Navigation
I also wanted to improve how this screen ties in with the Sector map. The transitions between the list, the star system detail view, and the map are all instant now, instead of some of them having a fade in/out animation.

Clicking on the planet’s row takes you to the star system detail view, as before, but now – if you want to go directly to the map, you can click on the minimap on the row, and that’ll take you right to the map. The minimap gets “open map” hover text to hopefully make this option clear.

Planet search
The big part, of course, was re-working the planet filter/search interface – that’s the part that needed the most help, to make it more oriented towards helping the player pick good colony sites.

First up, the basics – what type of planets you want to see, whether they’re surveyed or unsurveyed, whether a faction lays claim to them. Similar to the old filter, but much more compact. Then, a filter for the maximum hazard rating, and the minimum number of stable locations in the system – now we’re getting to the “actually useful for picking a planet” stuff!

Resources
What kind of resource deposits a planet has is another important consideration for colonies. For each type of resource, you can say that you either:

• Don’t care if the planet has it or not
• Explicitly want the planet to NOT have it
• Want the planet to have X level of that resource or better

I have to admit, I’m pretty happy with the widget I came up with to show this – it’s simple to use (just click an icon) but I think gets the point across in an intuitive way, by highlighting and drawing a border around all the acceptable resource levels.

Other requirements
And, finally, we get to the stuff that’s most involved for the player to figure out without UI support – which planets allow you to install which special colony items? For example, the “Autonomous Mantle Bore” improves mining (so, you want good ore deposits) but can’t be used on a gas giant (for obvious reasons) or on habitable worlds (Domain-era safety interlocks!).

Originally, I had the idea of letting you filter for certain planetary conditions – ones that factor into item requirements. Similarly to resources, you’d need to be able to say “yes/no/don’t care”, rather than it being a simple two-state toggle for each condition, but that’s doable. So you might say “not habitable” in the conditions widget, and then click off gas giants in the top part of the filter,  and then you’d see all the planets that can use an Autonomous Mantle Bore.

There are problems with that approach, though. There are *a lot* of planetary conditions to show here. If you just have a bunch of icons, it gets complicated trying to pick out the one you’re looking for, and there’s a real risk of running out of UI space to put them all, especially if you factor in mods. And many conditions are mutually exclusive – for example, cold, very cold, hot, etc – so if you’re showing them en masse, you’d want some way to handle that, too.

In addition, the player needs to be sure of what conditions the colony item actually requires. You might check the item’s tooltip, open up the planet search screen, check some boxes, go back to cargo to double-check the requirements, etc. It’s kind of a mess.

Items as search filters
The solution is probably obvious – just let the player select an item and filter the list to only show planets where that item can be used. There’s a lot less items than conditions, and you don’t have to worry about checking or mixing up the requirements – it’s a way better way to go.

So why *wasn’t* this obvious from the get-go, and why did I spent some time on the “conditions” approach? One of the reasons is that there are still a few planetary conditions you want to filter on, so I figured if you’re going to have a section for conditions, you might as well use it for more stuff. Another reason is that showing a list of colony items is a spoiler – seeing a Cryoarithmetic Engine in the planet search screen is just about the worst way to find out about it.

Plus, in the abstract, it “makes sense” to be able to, say, search for all planets that are “hot” or have “toxic atmosphere” or whatever. It’s kind of fun! It just doesn’t *directly* matter – it only matters as far as that condition affects the planet’s hazard rating and factors into what items you can use. So if we were making an abstract “search for planets with these properties” interface, searching for conditions would make a lot of sense. But we’re making a “find planets to colonize” interface, and searching/filtering on conditions doesn’t make sense here.

Showing a list of colony items is still a spoiler, but that’s easy enough to deal with – the items only show up on the list if the player is aware of them, using the same mechanism as unlocking items for the Codex. (Actually: I wrote this code prior to the Codex, and then retrofitted it to reuse the same parameters as Codex-unlocking. Or, perhaps, the Codex unlocking was an expanded version of this code. Either way!) The unlocks are persistent across saves, so you don’t have to do it every time you start a new campaign.

Cryosleeper and Hypershunt
These are both things you find somewhere in the Sector – a massive starship, and a megastructure – that give certain bonuses to colonies within a certain range from them.

For the Cryosleeper, there’s a checkbox to only show planets within range of one, and it only shows up once you’ve found one in your current game. For the Hypershunt, I originally had the same thing, another checkbox – but benefitting from the Hypershunt requires a “Hypershunt Tap” item to be installed at the colony, so it’s actually more compact to just use this item as a filter.

Filtering on conditions
And, finally, there still is a condition that would be nice to filter on – an Orbital Solar Array, which gives a bonus to food production, without being a resource deposit. There aren’t many conditions like this – in fact, just one, though mods could add more – so a separate section doesn’t make too much sense.

Thus: the “Items” section becomes “Other requirements”, and we put the Solar Array there; you can check it to only show planets that have.

Except, there was a bit of a visual problem with this. We’ve got a list of 3D-looking item sprites there, and a flat, square market condition icon looked very much out of place. What I’d ended up doing is adding some shading around the edges of the icon, to make the edges less sharp, and make it fit in with the colony item icons.

The screenshot below shows what it looks like with the harder edges – it’s the last icon in the “Other requirements” section. It’s a bit subtle, but you can compare it to what it looks like with the shading in any of the other screenshots.  Also, something to keep in mind is the edges would be even more prominent in an icon that had brighter colors on those edges.

Filter preset
You can save and load a single filter preset, as well as reset the filter to its default state. I’m not actually sure just how useful this feature will actually be – well, the “reset” button seems handy, but I’m less certain about saving and loading a preset. But it doesn’t really take up any extra UI space, since that row already has the number of matches and the reset button, so, might as well.

(Speaking of saving and loading a preset, I’d also just recently added a somewhat hidden feature to the intel screen – you’ll be able to press Ctrl-S to save the currently selected set of tags, and Q to select those tags (or Shift-Q to add them to your current selection). That you can do this is explained in a loading screen tip, and in the Codex. Ideally I’ll figure out some place to put a UI element for it in the intel screen, but this seems useful enough to want to include regardless. Now then – back to the planet filter stuff!)

Modding
The filter is extensively moddable – mods might add different considerations for what makes a good planet to colonize, or perhaps even do something entirely different with. And, if the amount of stuff in the filter is too much to fit on the screen, it becomes scrollable – less than ideal, perhaps, but better than not fitting on the screen.

All in all – having more tools at my disposal, along with a better understanding of what the screen is actually for – I feel happy with how the new UI turned out!

And, for reference, here’s what the old/current-release UI looks like:

Faction screen
While I was in the area of the code, I also spruced up the faction screen a bit. Nothing too major – just made it center on the screen (like the planet list), added some borders around the text (to be consistent with how similar information is presented in the Codex), and dimmed the faction-button highlighting a bit. Probably the main thing here is that it now remembers the previously-selected faction when opening the screen.

Comment thread here.

Today I’d like to talk about a new ship we’re adding to the game, the Anubis-class Experimental Cruiser. What makes this ship special enough to merit its own blog post? After all, as has been proven by science, at least 10 new ships are being added in the next update. However, this is one of a few ships that will be possible to have in the player’s fleet (as opposed to being [REDACTED]), so, finally, it’s something I can talk about without any real spoilers. Plus – as hopefully you’ll agree – it’s going to be a fun ship!

I try to be careful when adding new ships and want to make sure each one brings something different to the game. This is, for example, why a lot of new ships have built-in hullmods – now that the majority of “normal” ship roles have ships filling them, it takes a little more to make a ship stand out in some way.

This is where built-in hullmods come in, breaking or bending the rules a little for a particular ship. I don’t usually *start out* wanting to add built-ins, though – the process is almost always that I have an idea for how the ship should work, try to make it do that, and then add a built-in hullmod or two if that seems to be the only way to achieve the desired result.

Motivations
For this ship, the motivation is actually a weapon – one that does not see much use despite being very good at what it does. I’m talking, of course, about the Paladin PD System. It’s fitted into a large energy slot, and it’s extremely effective at taking down missiles and fighters, for a reasonable cost in both flux and ordnance points. The problem is the large energy slot – there aren’t many of those to go around, and ships that have them *really* want to use them for their primary armaments, not a point-defense system.

So, what I wanted to do is create a ship where using the Paladin would be a more compelling option than usual, though hopefully not the only one. I’d also like it to be a ship that would be fun for the player to pilot themselves, that is, not just something that’s very firmly relegated to a passive support role.

To have multiple large energy slots, the ship pretty much had to be a cruiser or a capital, but if it was a capital, it’d face a different problem – you’re pretty unlikely to bring an expensive capital ship for point-defense purposes. So, it was pretty clear that this was going to be a cruiser. Three large energy slots felt about right, too – more than that is way too much for a cruiser, and less than that might not leave enough room for the Paladin. (Or for any kind of similar future weapon! Having a ship like this opens up the weapon design space a little bit more.)

Playstyle
The next thing to think about was how the ship should play, what would you do with it if you were controlling it yourself? One of the things that I find fun is using a ship in a kind of fire-fighting role, moving around the battlefield quickly, dealing with incoming fighter wings, missiles, or flanking enemy ships, supporting an allied ship that gets in trouble, that sort of thing. The Paladin is a good match for that type of role, but what should the ship system be?

Temporal Shell – a system that briefly speeds up time for the ship – feels like a good match for this. It’s nice for charge-using weapons like the Paladin (because they can reload more quickly while in fast-time) and it also improves the ship’s mobility. The ship’s name – the Anubis – came from that, since the other ship that uses the Temporal Shell is a frigate named the “Scarab”.

So, we’ve got the broad strokes here – cruiser, 3 large energy slots, Temporal Shell. A bunch of important questions remain. What kind of support slots/options does the ship have? And what’s to stop you from putting 3 high-damage primary weapons in those large weapon slots?

The problem
And this is where I stopped writing this blog post, realizing there was a problem. Sure, *some* assault-type energy weapons can be made a poor choice to put in all of these large slots by just tweaking the ship’s flux stats (briefly: flux is generated by firing weapons/taking shield damage, and limits how much you can do of either); that was the original intent. However – the Tachyon Lance, a powerful “sniper” type weapon, has very similar flux generation to the Paladin. Sure, it generates a bit more flux, but it’s really hard to draw a line between the two, to come up with flux values that favor using one en masse but not the other.

Some quick testing confirmed my fears – yep, a triple-Lance build was effective and in fact way, way too strong. The Anubis is meant to be a cheaper ship to deploy, due to being inherently more support-oriented, and being able to spam 10 of them or so with triple lances… well, it was a sight to see. Though not for very long, because the enemy ships evaporated rather quickly. So, yeah, problem.

I tried a bunch of things. The first was changing the arcs of the large slots so that they couldn’t all focus on the same target. However 1) this feels kind of bad and makes the ship awkward to use, and 2) doesn’t solve the problem because – unless the arcs are truly weird and restricted – you could still turn the ship and focus two lances on the same target, which is already too many. The sweet spot in terms of power is when the ship can maybe use one Tachyon Lance, and not too comfortably.

Then I tried messing more with the flux stats, trying to draw that line between the Tachyon Lance and the Paladin, but there’s just not enough room there – because the lance is a burst weapon with a substantial delay between shots, the two weapons are surprisingly close in terms of flux use!

In retrospect, the solution is obvious – to *make* the room, by reducing the flux cost of the Paladin drastically. This led to a second realization, that while the Paladin is indeed already a strong weapon, it’s strong against threats that either don’t exist or exist so rarely that it’s not as appealing. If every battle had you facing off against massive swarms of missiles and fighters, sure, you’d want to trade some Tachyon Lances for Paladins, even on ships that have few large energy slots – but that’d be a different game.

So in the context of what we’ve actually got, a buff to the Paladin seems justified – and, in fact, required to make the Anubis work. It’s not sufficient by itself, though – it’s just a crack we can wedge the chisel into and make something happen.

The other part of the problem is the player can do a few things to improve a ship’s flux stats – adding vents/capacitors, certain hullmods, certain skills. Normally this is good, but we’re trying to walk a fine line here. If the flux stats the player can *add* to a ship are enough to support a Tachyon Lance or two on their own, then the ship’s base flux stats could be zero and we’d still have problems. This is where built-in hullmods come in!

Putting on our in-fiction hat, what might be holding back an experimental ship like the Anubis? Let’s call the hullmod “Design Compromises”. The first thing it does is reduce the ship’s flux dissipation and capacity by 40%, including the base stats and any bonuses those stats might get from any source; this was the original idea – to rein in the amount of flux stat improvement possible.

By itself this wasn’t enough, even with the Paladin change, so: it also increases the flux generation of energy weapons by 100%, widening the gap between the Paladin (and anything with similarly low flux costs) and the assault weapon lineup (most notably the Tachyon Lance, which has some of the lowest flux costs for a primary weapon). This, finally, is enough; a triple-lance loadout struggles to fire. It’s *possible* to stack every flux bonus and fire off a triple-lance volley, but this makes the ship extremely vulnerable, and even two lances firing can’t be sustained. Maybe it’s possible to make this work and maybe someone will post a video destroying 3 [REDACTED] Ordos with it, but hopefully it’ll be at least a challenge.

(You might be wondering: why double the flux generation of energy weapons instead of cutting down the flux stats some more? Flux is also used for shields, and the ship needs to have at least half-decent shields, so the primary reason is just to keep the “shield flux per damage” number looking reasonably normal.)

Support slots
With that finally figured out, let’s get back to the support slots! That is to say, what other weapon slots is the Anubis going to have, to support the 3 large energies? (Chronologically speaking, I’d thought this through before the lance testing, but the support slots didn’t matter for that – they were left empty, and the extra ordnance points spent on flux stats to power the lances.)

The main thing to keep in mind here is the ship is going to be very flux-limited, so we want the slots to allow for some low-flux-cost options. Given that, I settled on a pair of medium universal hardpoints, and a single fighter bay. The fighter bay doesn’t need much explanation – fighters function independently and you can put in whatever fighters you want without increasing the ship’s flux generation.

The two universal slots open up many options. First off, missiles – always a strong choice, and usually with no flux cost. Second, ballistic weapons; usually unavailable on high-tech ships like the Anubis; generally flux-efficient in their role, and long-ranged. (Briefly, ships tend to either have speed or range; if they have both, then kiting becomes too strong of an option, and high-tech ships tend to have speed, while ballistic weapons tend to have range. As with any rule, there are exceptions.) And, finally, there are some flux-cheap medium beam options.

Usually when a weapon slot allows mounting different classes of weapons – ballistic, energy, and missile – missiles and ballistics win out, due to the former not costing flux and the latter having better range and efficiency. And that’s before the doubling or the flux cost for energy weapons on this ship specifically! To even out the options a little bit, the “Design Compromises” hullmod from earlier has another pair of effects:

• The range of ballistic weapons is reduced by 15%
• The rate of fire of missile weapons is halved

This should make the range of viable choices for these slots more varied, while keeping the ship’s power down, which appropriate for its low-ish deployment point cost. There’s also a nice symmetry with every weapon type being affected by some kind of penalty (with the energy one being a flux cost increase, from earlier).

Loadout feel
So all in all, the ship has  3 large energy turrets, 2 medium universal hardpoints, and 1 fighter bay. This is a small total number of slots for a cruiser, and makes it feel very different! It almost feels like a scaled-up frigate in terms of loadouts, and I like it – the choices are more pronounced, just because there are fewer slots to make them for.

The “Design Compromises” hullmod also drastically reduces the value of vents and capacitors (normally, you’d put a fair amount of points into these before doing much else); this means that hullmods become comparatively more attractive on the Anubis.

Overall, I’m happy with how it turned out; the choices here feel fresh, and the ship feels like something new. I hope you enjoy flying it!

Hi! David here to give some ~*~* artistic perspective *~*~.

The Anubis was brought back from the underworld of one of Alex’s many design documents by a discussion a couple weeks ago about what I needed to do next. See, I’ve been knee-deep in rules scripting for quite some time and I said “tbh I am kinda dying to draw something.” So he said, great! We can do this ship I was thinking about a while ago- and you’ve already read about the mechanics design from there.

Me, I’m interested in the aesthetics. It’s all about the vibes, man.

The Scarab offers an obvious visual starting point due to the common key element of the temporal shell. Alex discussed working on the Anubis briefly in The Socials and I believe the phrase “Fat Scarab” came up in comments and I was like noooooooooooo it can’t be a fat scarab! It can’t! So I also knew what I didn’t want to do.

Ahem. So we did play around with some other names for a bit, taking “scarab” as a starting place – I wondered if there were any other particularly holy beetles to be found, and failing that, considered what Egyptian gods might be fun to pull from. This is a cruiser, after all, a step up from a destroyer. After some discussion “Anubis” felt the best in terms of matching vibes and being easily memorable (and easy to spell, which is an important consideration… says the man who put “Chicomoztoc” into the game.)

Happily “Anubis” also provides a great place for visual inspiration aside from the general high tech ship style and the Scarab itself. Of course the three large turrets are the entire point of the ship so they came first, then everything else. So: Anubis, Egypt. I’ve always wanted to put some stripes on a ship, so why not evoke the pharaonic headdress, the nemes? (It is important, pedantically, to note here that Anubis was not portrayed in Egyptian art wearing a nemes – the nemes is for kings, not gods. Unless the god is also a king. But Anubis was not. So get it right, people! Obviously this doesn’t apply to my use of imagery here, being that this isn’t intended to be an actual representation of Anubis. The walls of my glass house are just fine, thank you.)

– There’s also something compelling in the sleek, elegant shapes in the jackal-head of Anubis that I wanted to evoke, so you get those from the sweeping wing-like pieces to the fore and aft, as well as the skewed/curved shape of the flight deck. The hull can also take on slightly darker shades, more blacks and dark grays, to match the black-headed jackal. This hull is allowed to bend the rules a bit anyway due to being an experimental development and implicitly a more recent design than other high tech hulls.

The engines were quite directly ripped off from another high tech ship. No need to reinvent the AM-catalyzed fusion drive! The docking bay was taken from the Astral, the archetype of high-tech carrier. A few other pieces from other hulls; there’s a design language here, and it’s important to echo what’s been set elsewhere in the game to give a sense of continuity.

So, I was feeling pretty good at about step 8 there.

And then Alex comes back – he’d been doing some testing and balance – and tells me no, it’s too big. (“Fat Scarab” flashes before my eyes! A red fog descends and… )

Some time later I awoke to discover that I’d managed to trim the sprite down. The voluptuous version of the sprite did, in fact, feel even beefier than a full-on Dominator, which was terribly inappropriate. This is supposed to be a sleek opportunistic hunter-escort, not a line-of-battle brawler! It needs to feel a little spooky, a little weird – and so it is. I’m quite pleased with how distinct the Anubis looks while still feeling like a natural extension of the existing style.

Comment thread here.

Starsector version 0.98a is now out! This release has the following major features:

• Several new endgame-level enemies to fight in the Abyss
• New ships, weapons, and hullmods
• Codex UI revamp
• Autosave, revamped save/load UI
• Intel map markers and little notes
• Revamped combat simulator with many options and opponents
• Planet search UI revamp
• New story (not “main” story) missions
• New music
• New portraits and illustrations

In addition, the game has been updated to use Java 17, which should substantially improve performance. As always, there are also many smaller changes and additions, including balance adjustments, polish, ship AI improvements, bugfixes, and modability improvements!

The full patch notes, and the comment thread, are here.

You can download the new version here:

(Alternate download links, please try the above first: Windows Mac Linux)

As always, thank you so much for your support!