Space-mines are too cool a concept not to get into Starsector at some point. We’ve talked about them internally many times in the past, and while the idea is very neat indeed, there are several design pitfalls to watch out for. What I’d like to do in this post is talk about the design process for minefields – what the impetus for adding them was, how I approached their initial design, and how it evolved during the implementation.

Motivation
First off, why add mines now? The answer is for orbital station battles – those present several design challenges, one of which is that they both need to start off strong at the lowest “orbital station” tier, and grow in power as they progress to “battlestation” (tier 2) and “star fortress” (tier 3).

A battlestation is notably bigger and stronger than an orbital station, and that’s nice upgrade. A star fortress, however… one can’t just glom on more modules and make it bigger. Having too many modules makes a station fight less interesting – the station becomes just a mass of stuff to shoot at rather than individual modules with strengths and weaknesses.

What we want is for the star fortress upgrade to make the battlestation more powerful while not compromising what makes the original design interesting. There are several components to this, and one of them is a minefield maintained around the star fortress.

Read the rest of this entry »

Like exploration, orbital stations are a bit awkward to talk about because I’d like to avoid spoiling things, and this rules out talking about all of the content currently using these mechanics. So, the mechanics are what we’ll talk about instead, with a placeholder station for reference.

Before we go on, a disclaimer. Talking about pure mechanics is also tricky, because we’re talking about potential. Potential is very exciting, but often for the wrong reasons – it can mean whatever you want it to mean. Two people can talk about the same ideas, agree that they love them, and mean entirely different realizations of said ideas that the other person would hate.

Finally, the details of the mechanics may point towards specific content that isn’t in the game yet. That doesn’t mean that it will be at some point, though it probably means I’m intending to look at it very closely. Whether that’ll pan out or not, though, is impossible to say until it’s actually done.

All I’m asking for, then, is some brakes for the potential hype train. Really, this applies to any blog post to varying degrees – things can and do change all the time – but it feels more important to mention here, perhaps because the idea of orbital stations in battle really makes my own imagination take off.

With that out of the way, I introduce to you the ISS Placeholder, an orbital station that you will (almost) certainly not see in the game.

The main thing that makes this otherwise smart-looking (if I do say so myself) station a placeholder is its size, barely battleship-level. That’s not to say it could never see action in a different role, but it’s not big enough to be, say, a hypothetical battlestation defending a planet. If such a thing were a thing, which right now it isn’t.

So, how does this all work?
Read the rest of this entry »

As usual, after a major release there’s some time to polish up some things that there just hasn’t been time for up to that point. In fact, a lot of the upcoming 0.7.2a is turning out to be about “paying off” technical and design debt – things that are “good enough for now”, but do have to be addressed at some point.

One such is phase cloaking. There’s a post from a while back on how the current mechanics came to be if you’re interested in the details, but let’s summarize:

Way, way back, the original idea for phase ships was something submarine-like, being able to hide on the battlefield and deliver surprise attacks. That sounds like fun but didn’t turn out to be practical, so phase cloaking changed to become a way to avoid damage instead – shift to another dimension, let enemy fire pass through/over your ship, uncloak, and fire back. That essential concept remains unchanged in this new iteration; the changes are looking to address some specific issues with the implementation.

What, then, are the issues? Read the rest of this entry »

The focus of the last couple of weeks has been on improving campaign gameplay. In practical terms, this means giving the player some choices as they move from point A to point B, and making sure there can be a positive or a negative outcome depending on how well the player does. A simple case, useful for thought experiments, is one fleet trying to chase down another – what options does each of them have, and how do their choices interact?

Before answering that, it’s a good idea to take a step back and consider what kind of feel we’d like the campaign to have. Should it be more visceral, or more detached? The answer is going to drive the design of the gameplay mechanics. For example, if we want visceral-feeling gameplay, then giving the player more direct control of the fleet might be a good idea (e.g. WASD vs click-to-move), and we might also want to give the player less time to react.

Now, I happen to think that this isn’t the right way to go, and something more detached, slower, and tactical would work better. The player is going to be doing all sorts of things in the campaign that don’t involve dodging or chasing enemy fleets, and a visceral-type design could easily bleed over into those activities. We don’t want “interact with market” to be a nail-biting experience, or even something that’s a challenge to do – at least, I definitely don’t. Some of this comes down to personal preference; much of any design does – but now that it’s settled on, let’s take a look at how we’re going to go about it.

Read the rest of this entry »

For a while now, the core campaign gameplay has been pretty … let’s say straightforward. You click somewhere, your fleet goes there, you may chase or be chased along the way, and that’s pretty much all there is to it. It does the job as the “thing you do between the fun stuff” – battles, interacting with markets, and so on – but it doesn’t stand up as anything you’d want to do for its own sake. To be fair, not a lot of time has been dedicated to making it into that – until now.

It’s going to take multiple mechanics working together to bring campaign-level gameplay up to par with combat, and I’d like to talk about the first one of these that we’ve been working on: sensors, that is to say, a set of rules that determine when one fleet is able to see another.

It’s important to note that how sensors work will both influence and depend on other related mechanics (to be added in the near future), and so the current incarnation of sensors – the one I’m going to discuss now – is very likely to change. In general, the more specific a detail, the less likely it is to remain exactly as-is.

That aside, why sensors? Why can’t all fleets always see each other, the way they do now? There’s a realism argument for it, as spotting fleets across light-years doesn’t make a lot of intuitive sense, but I’m not a fan of the “realism” argument in general. It takes days to travel light-years of distance, so who’s to say where sensor tech is relative to that? Internal consistency of the rules and good gameplay are more important; given those, an in-fiction explanation for how things work shouldn’t be too difficult, if it even proves necessary.

What else, then?

First of all, suspense and a sense of discovery. If you see everything, there aren’t going to be any surprises. Say you’re traveling from Corvus to Asharu, and you’ve opened up the map to see the route – and you see that it’s clear of any enemies. From that point on, you know for a certainty that there’s no risk to the trip, and it stops being engaging and becomes a wait until it’s over.

If you don’t have perfect vision, on the other hand, space gets big and mysterious again. You start the trip – and see a sensor blip.

Read the rest of this entry »