Starsector 0.6.2a Release

Update: The hotfix for 0.6.2a is now out. The changes are:

  • Fixed ArrayIndexOutOfBoundsException crash when flying around in campaign mode
  • Fixed crash caused by trying to do a drag-select in the command UI while the battle is ending
  • Fixed crash caused by scuttling last ship at station and then switching to the cargo tab
  • Fixed issue where exiting to the main menu directly from combat could result in the encounter dialog popping up after loading a saved game
  • Fixed issue where an enemy fleet with low CR across the board would stand their ground but then not deploy anything in battle
  • Fixed bug where CR reduction from the Combat aptitude would not apply to the piloted ship if command was transferred prior to battle
  • “Crash mothballing” now actually works
  • Hermes description now fits in tooltip
  • Modding: fixed issue with getFleetManager() crash
  • Modding: fixed issue with fireSoundOne being played at the first shot rather than at charge startup
  • Modding: CampaignFleetAIAPI.performCrashMothballingPriorToEscape now takes a FleetEncounterContextPlugin

Please re-download the game using the links below – make sure the file you get ends with RC3.

Starsector version 0.6.2a is now out! You can get it here:

(Alternate download links: Windows Mac Linux)

 

As with other point releases, this is a followup to 0.6a. The main features in this one are:

  • Adjustments to combat readiness (more ship longevity and more choices, details below)
  • Four new ships!
  • Campaign help – dialogs that explain various game mechanics – how to split cargo stacks, how CR works, etc
  • Choice of starting difficulty – Easy and Normal. “Easy” gives you a choice of better starting ships and a Mule combat freighter, does not affect the rest of the campaign
  • Updated to use Java 7 and the latest version of LWJGL (2.9.2). Improved performance, OS X 10.6 (Snow Leopard) is no longer supported
  • Reduced memory usage (mostly affects larger mods)
  • Lots and lots of assorted bugfixes/improvements etc

The full patch notes are here.

A note about OS X: if you’re using 10.6, you should be able to upgrade to OS X Mavericks (for free) and run Starsector from there. Not all machines running 10.6 are able to run Mavericks, but the great majority should be able to. I’d have liked to keep supporting 10.6, but Java 7 doesn’t run there, and the machines that can’t be updated to Mavericks likely have a rough time with Starsector to begin with. All in all, it seemed like a worthwhile trade-off for improved performance and access to additional Java features for development.

As usual with OS X, if you’ve got Gatekeeper enabled, right-click on Starsector and click “Open” when running it for the first time. Otherwise, you won’t get the option to run it anyway when it complains that the app is from an “unidentified developer” (that’d be yours truly).

A bit more about the changes to CR:  the deployment cost has been cut in half, but so has the recovery rate. This means that the time to recover from a single deployment and the supply cost per deployment both remain the same, but ships can be deployed more times before exhausting their CR.

In addition, low combat readiness no longer prevents a ship from being deployed. Instead, ships will suffer progressively more damaging and debilitating malfunctions – allowing for a desperate last stand rather than a helpless retreat, if it comes to that.

Combat Readiness Update

With CR being one of the main features (perhaps the main feature) of the 0.6a release, it makes sense to revisit it after seeing how it’s played out so far.

(If you haven’t been keeping up with the details: CR (“combat readiness”) is a percentage rating each ship has that’s reduced each time it’s deployed into combat and governs how effective it is, and whether it can be deployed at all. Recovering CR costs time and supplies, thus rewarding the player for winning with fewer ships. That’s not the only reason for CR’s existence, but there’s a whole blog post devoted to it, so I won’t talk about it here.)

Overall, I think CR accomplished its intended goals, but that doesn’t mean that it’s perfect and can’t be improved. One of its effects in the current form is that ships go from “pretty much working fine” to “can’t even deploy this rust bucket anymore” awfully quickly, without much of a transition period. For reference, right now a ship below 10% CR can’t be deployed at all, while a ship below 20% CR suffers weapon and engine malfunctions. In theory that should be the aforementioned transition period, but in practice deployment costs are high enough that it can get skipped altogether.

With that in mind, the changes:

Ships have their deployment costs and CR recovery rates halved.
This means the supply cost per deployment and the recovery time remain the same, but more consecutive deployments are possible.

Malfunctions start at 40% CR, critical malfunctions start at 20%
This is all about extending the transition period between “working fine” and “not working at all”. A ship in average shape has roughly the same number of deployments as before until it runs into malfunctions, but now it’s possible to continue deploying the ship well beyond that.

Just what are critical malfunctions, you ask? Conceptually, it’s a chance for things to go very, very badly wrong. For example, a power junction failing catastrophically, ammo exploding inside a magazine, an engine containment field failing, that sort of thing. In game terms, it’s a chance for weapons and engines to go offline for the duration of the battle, and cause major hull damage in the process. Simply deploying a ship at low CR will cause some of these, an continued use in battle has a chance to cause even more.

Say goodbye to the starboard-side Heavy Blaster and some engines; and that’s just the beginning!

Read the rest of this entry »

Fighter Update

Did I mention that combat readiness (“CR” – briefly, a measure of how good a shape the ship is in, 0 to 100%) has lots of tendrils into other areas of the design? I think I did. That’s not a bad thing; in fact that’s rather the point. It does, however, mean that I end up adjusting a number of mechanics in the name of everything fitting in better.

One such set of mechanics is just about everything surrounding fighters. In the current release, they’re a bit rough around the edges, especially in the campaign – a few things don’t quite make sense lore-wise, and a few things combine to make them weaker than I’d like them to be.

So, changes!

In Combat
The first big one is that fighter wings no longer go back to a carrier as a single unit. Instead, individual fighters peel off when they need to repair or rearm, while carriers launch replacements for every wing that needs them. This does a couple of things.

First of all, having more flight decks is actually useful. An Astral’s three decks can crank out replacements at an alarming rate, one that a more modest carrier will be unable to match. This is particularly important because with more decks, fighters can regain their numbers more quickly – instead of being massacred piecemeal as replacements trickle in. (As it stands in the current release, the three decks on the Astral are overkill; hardly any fleet can make use of all of them.)
Read the rest of this entry »

Fleet Encounter Mechanics, Part 1

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 »

Combat Readiness

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 »

Forum Blog Media FAQ Features Digg it! Del.icio.us! Share this on Facebook Reddit Stumbleupon it! Technorati Tweet it! Download Starsector for Linux Download Starsector for Mac Download Starsector for Windows