One of the design goals for the campaign layer of the game is that it should present the player with opportunities for combat. This doesn’t mean that everything you do in the campaign has to lead to it, but it’s a good thing to always keep in mind, regardless – how does a feature of a mechanic give context (and meaning) to combat, or lead into it directly?
If you’ve been following the game, this is something you’ve probably read before. So, in brief: this post is going to talk about some aspects of how establishing colonies leads the player towards combat. This already happens in the currently-released version of the game, and the changes I’ll talk about here are about three things: cleaning up some of the rough edges of the current approach, creating a system that makes it easy to add a variety of encounters, and building some infrastructure that can be used for other purposes, in particular implementing the endgame.
One basic way in which colonies lead to combat is that they attract piracy. You get some smaller pirate fleets just hanging around the system, that you might encounter them when you’re visiting the colony. Occasionally you get bigger pirate raids, which you generally need to defend your colony from. There are also nearby pirate bases – which add a “pirate activity” penalty to some of your colonies’ key stats – that need to be cleaned out periodically.
This is fine, conceptually, but in practice the smaller fleets don’t actually matter all that much – you don’t have much incentive to clean them up, either positive or negative. The larger raids are unpredictable, and it’s difficult to tune their frequency so that there’s “enough” of them – and enough nearby pirate bases – but that it doesn’t also leave the player feeling like they’re playing whack-a-mole.
This also doesn’t help any if we wanted to add a new type of hostile fleet the player might need to deal with in shepherding their colonies towards success. In fact, that can be a little difficult, because we have to consider the combination of all of these various types of activity, so adding a new one might mean turning down the frequency of some of the existing ones. It’d be nice to have a more unified way of handling various types of hostile activity.
For this, we need a new concept; let’s call it an “Event”. The rough idea is that we have something that progresses through stages, with various factors affecting the rate of progress, and things happen when various stages are reached. (Some of the inspiration for this comes from “event tracks” for various board games, and seeing something similar in Heretic Operative – which is basically a board game in computer form, and which I unreservedly recommend.)
This might not sound like a great fit for keeping track of hostile activity around the player’s colonies. Initially, I wasn’t thinking of doing it this way – the “Event” concept was still there, but intended for other things.
My initial approach was to handle “hostile activity” as just a regular type of intel item, tracked separately for each star system the player has colonies in. Here’s an older, work-in-progress screenshot of what that looked like:
The problem is, this gets to be a lot to ask of the player to keep track of, once they get up to several star systems. (Never mind some extreme case where the player uses AI cores to colonize half the Sector – I’m not too worried about that case, but also, it’d be nice if things didn’t break down completely when that happens, either.)
There’s also a more subtle… not “problem”, exactly, but let’s call it a “concern”. This – hostile activity – is something the player needs to interact with. What happens when they destroy a hostile fleet? What about, say, if they build a military base? With the initial approach, this meant adding a “suppression” mechanic (which you can see in the screenshot), which works – but it’s something that other potential interactions may or may not slot neatly into. In fact, just trying to figure out how to make it work with military bases was a pain – you want enough suppression that it matters, not so much that it trivializes the fight or encourages building all of your stuff in the same system with many bases, etc.
To put it another way, every interaction you want to factor into this becomes its own special case. Which isn’t always a bad thing, but on average is going to mean fewer types of interactions, and a bit more potential awkwardness in cases where they need to be shoehorned in a little too much.
Using an Event, after all
So, this “per star system intel item” hostile activity approach worked, and factored in the things it needed to, but didn’t feel right. Since I was, at the same time, thinking through the “Event” system, it was natural to consider if that’d be a better fit. My initial thought was to use an Event instead of each of these intel items (and, to be clear, Events are also intel items, just handled a little differently, with more UI space and some specifics about how they work).
The reason for doing one-item-per-system is because we want to track the types of hostile activity per system. For example, if one colony is using a bunch of AI cores, it’d make sense for there to be more Luddic Path activity in that system, not in all of your systems. More importantly than it making sense (hah) is that it’s also more interesting – if you go to different systems, you get more of a variety of what types of enemies you encounter.
But, one item per star system is just too much – this is far from the only thing the player needs to keep an eye on, so it just feels impossible to justify. In retrospect, the solution seems obvious: only have one Event, but keep track of the types of hostile activity separately for each star system within that Event. Overall event progress can still be shared in common (with some nods to colony individuality there, too), and we can use the same intel item to show a breakdown of what’s going on in each star system under your control.
This is probably starting to get a little vague, so let’s dive into some specifics!
Factors and causes
Hostile activity has a bunch of different “factors” – these represent different types of activity – pirates, Pathers, etc. Each “factor” can have multiple “causes”, so if there are multiple different reasons for why pirates are interested in a colony (there’s a pirate base nearby, the colony is unstable, the pirate queen Kanta is unhappy with you – perhaps it’s all those times you’ve pretended to be working for her to get out of trouble, hmm), you’ll get more and bigger pirate fleets there. Factors and causes are tracked per star system.
The factors also contribute a total value to “event progress”, regardless of which system they’re in. The event stages track increasing levels of impact on your colonies – from “low impact”, where only a small fraction of your colonies – the worst-hit ones – are affected in a small way, to “extreme impact” where all of your colonies suffer heftier penalties. So, over time, if left unchecked, the Hostile Activity event will progress through these stages.
In addition to stages, there are a couple of randomized outcomes along the way. Pretty early on, there’ll be a small pirate raid on one of your colonies; this will only happen once. (It’s also possible that something else might happen instead of that, when/if more types of hostile activity are added, though currently “pirate raid” is the only possibility.)
There’s also a major randomized outcome when event progress fills up all the way. What that outcome actually is gets determined some months ahead of time, when event progress crosses a specific threshold. Currently, the possible outcomes are either an act of Pather sabotage, or a large pirate raid. This outcome is repeatable – once it happens, event progress drops back a fair amount (representing a lull in hostilities after matters come to a head), and if the event progresses up to that threshold again, a new outcome will be rolled.
The important thing here is that the player gets ample warning about when something bad is going to happen, as opposed to events like this being completely random. Another important aspect is that the player can take various actions to avert these outcomes. Also, since event progress is abstracted into “points”, either gained over time or applied as a result of one-off actions, it’s easy to tie anything we want into the system and have it instantly matter. The goal is to give the player many different options in how to handle these, and to shape the way the game plays to their own preferences.
So, what choices does the player have? The first one is to… just ignore hostile activity. The colony impact is only mildly painful, and even pirate raids aren’t that bad if they succeed – it’ll knock a colony back for a few months, result in some lost income, but there’s some compensation from the “lull” coming afterwards. Or the player can elect to just deal with the raid/other outcomes, but let hostile activity run its course otherwise.
The other option is to fight the symptoms. You can build a military base to slow event progress, and there’s a further event stage – at around the halfway mark – where “increased defenses” further slow event progress. In addition – most importantly – destroying enemy ships in or near your systems will push back event progress. If it’s pushed back far enough, this can cause outcomes like the pirate raid to be averted. The player could choose to do a bit of this to keep things in check, or devote more of their energy to it, keeping event progress – and thus its impact on colony operations – right around zero.
And, finally, the third option is to address the causes. (Almost) every cause has some kind of resolution – usually one with a narrative flavor, so that the player can tell themselves a fun story about how they dealt with that aspect of the problem. In a way, the Hostile Activity event is almost a hub of missions the player can do, with the description of each cause hinting at how it might be resolved. A few examples – while trying not to spoil anything – would be, say, making a deal with the Station King of a nearby pirate base, reducing your dependency on AI cores – or some way to reach an understanding with the Pathers, and so on. This is a particularly significant aspect of this approach – there’s a lot of content here (including some one-off special ship modifications, but, spoilers!), and the potential to add more.
A combination of these three approaches (or two, if we don’t count “just ignore the problem” as an approach, though to me it certainly is one!) should let the player find something that suits their preferences. Basically, a lot of this is about letting the player tell the game what they want. Do they want to fight a bunch of fleets in their systems? Perfect, just don’t address the causes – you’ll get stuff to fight, but you’ll mitigate the effects on your colonies. Do you want to not have to worry about it? Build up a military base, resolve the causes, and you’re good. Want to fight some large pirate expeditions? Ignore the problem for long enough, and you’ll get your wish.
Extensions and interactions
In addition, the system is set up to make it easy to add different types of hostile activity, to add more variety to the encounters. Right now it’s just pirates and Pathers (though, you’ll see larger Pather fleets than you would before, sometimes). Another idea I’ve been considering (not implemented yet, please don’t hold me to it if it doesn’t pan out for whatever reason) would be Tri-Tachyon-sanctioned commerce raiding. One could think up some plausible excuses for getting other faction fleets tied in, too. But more importantly, the system allows for the flexibility of “X happened, and there’s a new type of hostile fleet that you’ll encounter in one (or more) of your systems, until you resolve the cause”. In other words, this can be dynamic – the outcome of other missions or Events – not something that’s more or less fixed.
To encourage the “fight the symptoms” approach, the Commerce industry adds a semi-permanent bounty to all of your systems, once the impact gets high enough – posted by the independent commercial interests that are operating in your systems. This both makes Commerce a more interesting pick (and, working on a few other things in that direction, but mum’s the word) and shows how other mechanics can tie into this system.
And, finally, this is groundwork for implementing the endgame – I think one can easily see how “an event that progresses through stages, with lots of factors affecting the progress” will be useful for representing more momentous happenings.
Comment thread here.