Part one is here. If you haven’t read it, it provides context for what I’m going to talk about here.

Travel Drive
Conceptually, ships use a different, much faster means of transportation for travel than they do for battle. Presumably, they either have to pop out of it every so often to navigate, or are forced to slow down by targeted nav system interference/debris fired across the projected trajectory/need to divert engine power to defensive systems due to the threat of enemy fire/<insert your favorite technobabble here>. Personally, I’m in favor of it being some kind of nav interference, whether it’s due to hypervelocity debris or jamming. The point is, a fleet can be forced to slow down and engage in battle.

On the flip side, a fleet disengaging from battle means that they’ve been able to re-engage their travel drives and put on speed. Maybe the nav computers finally calculated a safe trajectory. Maybe enough distance has been gained to eliminate the threat of enemy fire. The concept was always there, even if it wasn’t directly explored in the gameplay.

But now, there’s an opportunity to use it to improve the experience. With that in mind, the new mechanics:

• A ship or fighter wing being deployed into combat comes in with travel drive on, and it remains on for about 5-6 seconds – enough time to move around 3 grid squares in the command screen
• A retreating ship or fighter wing engages travel drive when it gets to within a couple grid squares from the border it’s heading for to make its getaway

A Medusa and a Wolf entering battle with Travel Drive (possibly pending cooler name) on.

This does a couple of things, all of them to do with reducing the impact of borders on gameplay. One, maps can be bigger without battles taking too long to heat up, because the extra space around the border is traversed very quickly using travel drive. This extra padding means objectives – which fighting often centers around – can be much farther away from borders. Two, retreating ships separate from pursuit far away from the border, almost entirely eliminating the “chase ship all the way to a border” situation.
Read the rest of this entry »

In a previous post, I talked about combat readiness (“CR”) as a means of tying the campaign and combat layers closer together, but also as a means of cleaning up existing mechanics. The mechanics surrounding battle are a perfect candidate, both because they need cleaning up, and because they wouldn’t work well with CR as they now stand. Changes to these aren’t just a consequence of adding CR; rather, they’re part of that process.

First, a quick recap of how things work now. When the player encounters another fleet, they can choose to attack them or leave. If either side wants to attack, the fleets engage, and each side has three options: “attack”, “defend”, and “escape”. Without going into too much detail, there’s a rock-paper-scissors mechanic there where attack beats escape beats defend beats attack. (“Escape” beating “defend” simply means a clean getaway, with “beating” in general meaning having an advantage in the battle, not automatic victory.)

Playing rock-paper-scissors vs the computer isn’t fun. The computer is either predictable or random, but in either case you don’t get the mind games that make it interesting vs a human opponent. The “escape” mechanic also doesn’t work well. The escapee has to run their ships across the map and retreat them off the enemy side, which is much more difficult than “attacking” and then retreating ships off their side of the map – which they could do without seeing a single enemy. If they do that, their ships take some automatic, random post battle damage to simulate a chase after this retreat, but that’s a problem in itself.  Either it does enough damage so that retreat from a real lost battle is disastrous, or it doesn’t do enough damage to stop “attack to retreat” being viable.

Adding in CR, the current setup is also open to being gamed. For example, a single Hound-class frigate fighting against an Onslaught-class battleship – the Hound could engage, then immediately retreat, causing a CR loss for both ships for being deployed in battle. However, the Hound both costs less CR to deploy and recovers it faster. So, it could reliably beat an Onslaught without firing a single shot but wearing down its CR.
Read the rest of this entry »

That’s right, Starsector has a new trailer – produced by Mr. Stian Stark. Without further ado, here it is:

Comment thread here.

In this post, I’m going to talk about one of the new mechanics we’ve been working on; but first, a little background. Starsector has been designed starting with the combat layer and working up, and this has both up and downsides. We get to work out the combat layer first, and make reasonably polished releases with combat as the centerpiece – that’s a good thing. On the other hand, this means that as the campaign comes into focus, we can either 1) force it to fit in with how combat currently works or 2) adjust the way combat works to make it a better fit for how we want the campaign to work.

Option one is unquestionably faster and easier, but also seems likely to result in a tacked-on campaign because of the compromises that we’d have to accept to make it fit. Option two is more work, but is the one most likely to result in a campaign that’s a game in its own right, on par with combat. Do I even need to say which option I find more appealing? (Hint: it’s the second one.)

Enter combat readiness (“CR” henceforth), a mechanic specifically intended to improve the connection between the campaign and combat layers. There are already mechanics that link the two – for example, the persistent fleet, ship damage & repairs between battles, and character skills. So, we’re not talking about anything radically new; just taking stock of what’s there and cleaning it up, smoothing over the rough edges. While this involves some changes to combat mechanics, the goal is to enable the campaign to exert a greater influence on combat (and vice-versa), rather than to rework combat for its own sake. We’re giving the campaign tools to work with, levels to push, knobs to turn, analogies to abuse.

Conceptually, CR represents weapon and system maintenance and repair,  securing the magazines, making sure there are no cargo crates knocking about in the hold, that sort of thing. In-game, it’s presented as a percentage. A good way to think of it is as a “stamina” mechanic on the campaign level.

So, how does it work?

Read the rest of this entry »

The command UI – the interface you use to give orders to your fleet, while also piloting your flagship – has always been tricky to get right, and has gone through a few incarnations since the first release. The combat gameplay merges a top-down shooter with some RTS elements, and both place high demands on your attention. You have to be able to control your fleet, while still participating directly in the combat  - this is the goal the UI has to achieve.

The very first version of the UI used the standard RTS model – control groups, right-click to order ships around, etc. It didn’t work very well – there’s a strong incentive  to keep checking on how your ships are doing, so that you can adjust if they’re doing something you don’t like. Optimal gameplay was, then, constantly interrupting the flow of combat to open up the map, check on your fleet, and tweak their orders.

The next version – the one that’s in the current release – solved that problem by limiting how many orders can be given to ships (via “command points”) and adding the concept of “assignments”. Instead of ordering ships about, you’d create tasks – capture this, defend that, rally a carrier here. The ships would then work out the details on their own. You could also give a few direct orders if you saw the ships doing something undesirable.

This worked much better – you could create an initial set of assignments at the start of the battle, and then just focus on the combat, only occasionally adjusting them. Because you couldn’t give unlimited orders, you were freed from the burden of having to constantly give orders to feel like you’re playing optimally.

The new approach had some issues, though. When it worked (the AI doing the right thing in “working out the details”), it worked well. When it didn’t, it could be frustrating trying to fix it using the limited direct orders.

The bigger problem was (and, I suppose, still is) accessibility. RTS-like controls are the go-to assumption when one sees a map with units on it – but they didn’t work. If you clicked on a ship, hoping to tell it to do something – you couldn’t!  You’d be presented with a context menu that let you create assignments that target that ship – i.e., you could tell your fleet to escort the ship you just clicked. You couldn’t tell that ship to escort something else, not without creating that assignment first (and then using a direct order from the context menu to assign the selected ship to it – a somewhat clunky process).

Telling the game what you want done – i.e. creating an assignment – is reasonable, in the context of commanding a fleet. An admiral wouldn’t tell every frigate in the fleet exactly what to do – that’s the job of his subordinates. But being reasonable, as it turns out, doesn’t get you far when going against UI convention. Games don’t typically ask “what do you want done”, they ask “how do you want to do… eh, whatever it is, I don’t actually know/care.”

The new version – that’ll be in the next release – aims to combine the best aspects of the two approaches.
Read the rest of this entry »