The full patch notes are here.

This version is save-compatible.

You can download it using the buttons below. You’ll have to reinstall the game, but shouldn’t need to enter the activation code again.

• Accidents
• Music!
• Greatly improved ship and commander AI
• Significant ship and weapon balance changes
• Lots of UI improvements
• Bugfixes

If that looks like a copy-and-paste from the previous post, that’s because it is – the last week was mostly spent polishing things up and playtesting.

The full patch notes are here.

The new version is, once again, not save-compatible. This is likely to be the case with new releases for the foreseeable future – things are simply changing too much at this point. On the bright side, I don’t think any mods are incompatible with this version, though they’ll probably need some rebalancing.

You can download the new version using the buttons below. You’ll have to reinstall the game, but shouldn’t need to enter the activation code again.

If you’re interested in the details of all the changes that have been made since the last release, this thread has most of them, except for the stuff added in the last week or so. On a high level, the big features and improvements are:

• Accidents
• Music!
• Greatly improved ship and commander AI
• Significant ship and weapon balance changes
• UI improvements
• Bugfixes

Right now, I’m working on the UI (in particular, making improvements to the trade and refit screens). After that’s wrapped up, we’ll take a couple of days to playtest, and depending on how it goes, put the 0.52a release out.

Achievements
The subjects of achievements came up on the forums the other day. Most games these days seem to have them, so will Starfarer?

Achievements are inherently immersion breakers – they remind the player that they’re playing a game. This cheapens the feeling of reward obtained from actual in-game accomplishments by taking away from the player’s emotional investment in the game.

Achievements also provide an external set of motivations to the player. Indeed, that’s the point – increase the longevity of the game by tacking on a set of things to do, on top of the game proper. But the downside is that this can prompt the player to play in a way that’s not fun – and might otherwise be discouraged by the game’s design. A good example is a “kill X number of thing Y” achievement – this promotes grinding (where the game itself might not), and isn’t an actual achievement in any but the gaming-related sense of the word.

Still, achievements do trigger a feeling of reward.

I think that they’re unequivocally a good thing for a game that doesn’t care about immersing the player – Team Fortress 2 or Super Meat Boy come to mind as examples of games not negatively affected by them. Except for those TF2 servers dedicated to unlocks. Or when your teammates act … sub-optimally … because they’re focused on unlocking something rather than playing effectively. So, scratch that whole “not affected negatively” thing, but I’m sure they’re still beneficial overall. The proof is in Valve actually doing it – it’s hard to argue with the results.

On the other hand, if a game cares about keeping the player immersed (as Starfarer ultimately does), then achievements are something to be careful with. Even if they turn out to be a good thing for a game overall, there is a cost involved.

I’d love to hear what you guys think!

The question is, how to keep the player within the set limits?

A straightforward approach would be to treat the limits as hard limits, and disallow the player from being over them at any time. For a straightforward approach, though, it’s not actually very straightforward. Let’s say there’s a cargo limit, and the player loses a ship. What happens now that their cargo is over the limit? Remember, cargo isn’t assigned to a specific ship, but handled as a total fleet-wide capacity. We could automatically dump some cargo at random – but that really hurts (bye-bye <important item>, which there’s no way to safeguard). We could add new mechanics to assign certain items to certain ships – but now we’re adding even more mechanics to make the new mechanics we’re adding “work”, and that’s not a good sign.

We could instead present the player with a choice of what to get rid of any time they’re over capacity. The trouble is, that could be awfully harsh too. Suppose they’ve got a few  ships that are just barely within their fleet points limit. Then they lose an officer that was providing a fleet points bonus – and now must choose which ship to get rid of, too. It’s also awkward to keep presenting the player with dialogs that demand attention and can’t simply be dismissed.

Besides, it would make sense that you could go over limits. An external cargo container attached to the hull with a magnetic grapple. A jury-rigged containment field to convert a cargo hold into a fuel cell. An improvised life support system to increase the personnel capacity of a ship. All these sound like they’d require some supplies to put together and maintain, but well within the capabilities of a well-trained crew. Even so, these probably wouldn’t be very reliable, would they?

Makeshift Capacity & Accidents

There are five limits each fleet needs to stay within:

• Cargo
• Fuel
• Personnel (crew and marines, combined)
• Fleet points (each ship uses some)
• Hangar space (provided by ships, used by fighters)

You can go up to 50% over each limit without any penalty, except for an additional supply cost – to build improvised containers, account for unexpected logistical requirements, perform emergency maintenance on all the jury-rigged systems, and other such.

The revised fleet information display, with a tooltip containing a detailed logistics report

That’s a lot of information on the tooltip, isn’t it?  What really matters is the simplified panel on the right, though – all you need to worry about is keeping the accident risk down, and making sure you’ve got enough supplies to maintain the extra capacity. The tooltip is there if you’re interested in understanding exactly what’s going on, but it’s not something you need to look at often.

Now, on to accidents – if you run out of  supplies, or go more than 50% over any capacity, you run the risk of having a serious problem.

As best I can tell, a cargo crate containing weapons slammed into an improvised habitat. Ouch.

The consequences of an accident depend on its cause, but will always aim to bring your fleet closer to its limits. For example, a personnel-related accident will cause a loss of crew and marines – though it may also cause some collateral damage to cargo or fuel, especially if those are over capacity as well.

The consequences can be very harsh – up to the total loss of a ship – but accidents are also something you shouldn’t be seeing on a regular basis. They’re there for when you’ve made a mistake (didn’t carry enough supplies to support your fleet, say), or for when you’ve made a gamble and lost (can I tow this extra loot to the station to sell?).

Of course, this applies to AI-controlled fleets as well – so later on, you’ll be able to inflict grievous losses on the enemy simply by disrupting their supply chain. Freighters also become much more important – a particularly large fleet needs lots of supplies to stay in the field – and to haul off all the salvaged goods.

Original blog post below.

First off – let’s talk about version numbers. The previous release was technically a “preview” of the 0.5a build “proper”, whatever that means. That was until I started thinking about how to version this “bugfixes & improvements” release, which still wouldn’t have all the features slated for 0.5a. 0.5a2? 0.5a-preview2?

I’ve had to sit through a few meetings with people arguing about version numbers at my various former jobs (seems like everyone doesn’t want to waste time with it, but also can’t stand doing it any way but theirs), and I don’t want to be that guy, especially not to myself. Down with the version number sophistry! This release will be known henceforth as 0.51a, and the next one will be… wait for it… 0.52a. I’ll just have to avoid specifying a version number when talking about planned feature sets, as I did with version 0.5a.

I’m sure everyone is quite sick of talking about version numbers by now (see what I mean? I didn’t want to waste time on this, and look what happened!), so let’s dive into what’s new in this version.

• Improvements to the command system – new escort behavior and tasks chief among those
• Ship balancing (slowed down some frigates, sped up most larger ships)
• Hull mod balancing (added downsides to some of the best ones, buffed some of the weaker ones)
• Added two new orbital stations (pirate & Tri-Tachyon), tweaked content progression
• Larger ships now need less experienced crew
• Re-worked post-battle surrender mechanics
• Improvements to ship and admiral AI
• Added several new medium-sized missile launcher weapons
• Lots of bug fixes

The new version is not save-compatible. My apologies for that – but as the game is still in alpha, maintaining save compatibility just isn’t something we can do yet. Also, at least some (perhaps most) mods will be broken, so you should disable them before playing the new version. On the bright side, the changes in this version mean it will be much, much easier for multiple mods to work together without conflicts.

You can see the full list of changes here.

Please download the new version using the buttons below. You’ll have to reinstall the game, but shouldn’t need to enter the activation code again.

• Campaign mode – fight your way up in the war-torn Corvus system
• Start out with a single frigate, buy (or capture) more ships to grow your fleet
• Customize your ship’s loadout before battle
• Level up your crew
• Ship weapons and engines can be disabled by damage, adding a new layer of tactics
• Tons of balance changes, UI improvements, AI improvements, and several new ships and weapons

For a full list of the additions and changes in this release, take a look at this thread.

You can download the new version using the buttons below. You’ll have to reinstall the game, but shouldn’t need to enter the activation code again. Thank you all for your support!

A couple of things: one, this is really, really awesome. I can’t express how happy and excited I am that Starfarer is reaching a lots of new players. It means a more active community, more player feedback, and of course, more financial resources to support ongoing development. Two, it also means that our web server is struggling mightily with the herculean task of handling all this traffic. I’m looking into ways of improving its performance, so hopefully we can do something about it in the near future.

In fact, it looks like it’s doing a bit better now – but I can’t tell if it’s because traffic has dropped off a bit, or because the configuration changes I made are helping. Ah, the vagaries of trying to optimize a live server.

Edit: The hosting upgrade is finished. Let me know if you notice something not working!

… now that my feeble attempts at humor are over and done with, let’s continue.

Battles are a key way to progress through the game. They’re not the only way – you’ll be able to build up an economic power base, for example – but that’s not what this post is about. Battles offer an opportunity to get stuff for free, even if you don’t fancy yourself a pirate, but something slightly more honorable-sounding. The flip side is you can easily lose some hard-earned assets, too – ships, crews, even cargo if the outcome is bad enough.

What I’d like to do is outline the mechanics as they stand, talk a bit about the motivations for doing it this way, and sprinkle in a couple of screenshots. For the sake of this discussion, let’s assume the player won the battle. If they lost, things happen slightly differently, but it’s more or less a mirror image.

Casualties, Boarding, and Repairs
If you’ve played the combat portion of the game, you already know that instead of simply blowing up when hull integrity reaches 0, ships become floating, disabled hulks. There’s a small chance for each of these to be repaired after battle (most likely, player skills will allow you to raise that chance).

So a friendly ship can emerge from battle in the following ways:

• Completely unscathed or somewhat damaged
• Disabled and subsequently repaired, with a minimal hull integrity and heavily damaged armor (non-fighters only)
• Utterly destroyed (fighters and ships whose hulks are shot repeatedly until they blow up – unlikely for anything bigger than frigates)
• Disabled and beyond repair, and subsequently scrapped for any supplies

The options for enemy ships are slightly different. Retreating ships have a chance to be captured after battle, and the player has a choice between boarding and scrapping these. Disabled ships that can potentially be repaired can also be boarded or scrapped, while ones beyond repair are scrapped automatically.

Also, if a ship takes hull (not armor) damage, then there’s a good chance that some crew will be killed, in rough proportion to how much damage the ship actually took. It’s possible to win a battle and end up losing enough crew that you can’t meet the skeleton crew requirements to deploy most of your ships – so it’s a good idea to carry enough extra crew for these kinds of emergencies. Outside of combat, it’s assumed that automated systems let you get by well enough to navigate the ships, so even extensive crew losses won’t stop you from being able to move around the Sector.

The Odyssey has taken some damage, but the pirate fleet has been eliminated as a combat threat

Boarding captured ships is relatively safe – the commanders of these have surrendered, and the crews aren’t putting up any resistance. Therefore, the risks to your marines are minimal, and the ships can even be captured by your crew. On the other hand, personnel boarding disabled ships face many dangers, from malfunctioning systems to pockets of resistance by surviving enemy crew. Only marines can even attempt this kind of boarding action, and will often take losses.

To recap, the player gets to make a “board or scrap” choice for either captured or repairable enemy ships during this initial post-combat phase.

Looting
The second phase is all about transferring any recovered cargo to your fleet’s holds. The amount of stuff you get depends on the outcome of the initial phase. Boarding ships produces more loot than scrapping them, and of course any ships that managed to retreat get away with their cargo intact.

Supplies, fuel, and weapons looted from what remains of the pirate fleet

The top half shows your current cargo, crew, fuel, and whatever else falls under the loose definition of “cargo”. The bottom half shows what’s been salvaged after the battle. In particular, the weapons come both from the cargo of the enemy fleet and from what was actually mounted on the enemy ships.

Motivations
I had two main goals when approaching the design of both these mechanics and the corresponding UI: 1) make it hassle-free and 2) offer the player some choices. These two are at odds with one another (figures, doesn’t it?), so as usual the process became one of looking for a sweet spot between the two extremes of “no choice” and “way too much of it”.

A simplifying assumption I made is that the player shouldn’t be asked to say whether they want to try to repair a ship or not – it’s just attempted automatically. The key point is that there’s no cost to making the “repair or scrap” choice, so there’s no need to bother the player with it. If the “repair” choice had a cost (say, some supplies to attempt it), then it would need player confirmation.

The “board or scrap” choice doesn’t come up all the time, but it does have a cost – the player is likely to lose marines every time they do it, so it has to be an explicit call on their part.

How often the after-combat screen comes up is actually an important question, and one I don’t have a good answer to at the moment (and it depends on playstyle, to boot). If it’s not too often, then it’s ok to have more choices – and have it be a little more work. If it’s more frequent, then it needs to be as streamlined as possible. I’m going with the streamlined approach for now, but will be keeping an eye on how it plays out – and whether it provides enough flexibility.

First, a minor matter of nomenclature – the next version is going to be called 0.5a (up from 0.35a) to reflect the large chunk of features it contains.

Now, what’s actually done already? I’ll try to keep this on a high level to keep the post from spiraling out of control – there is already a forum thread with the gory details, if you want to dig deeper.

Everything takes place within a single star system for now. You can manage your fleet, cargo, and crew, and engage hostile fleets in battle. You can engage in post-battle boarding actions and salvage what remains of the enemy (and your!) ships. You can refit your ships using available weapons and hull modifications. Ship weapons and engines can get damaged and disabled in combat, adding a whole new layer of tactical considerations. There have been many UI improvements – most notably lots more tooltips, and much-improved existing tooltips. There are also several new ships and weapons. You can create a new character – just a name and portrait for now – and there’s the save/load functionality you’d expect.

When I put it that way, it sounds just about playable, doesn’t it? The trouble is, right now those things are just disjointed features, and what I’ll be doing over the coming weeks is cobbling them together into something that’s actually fun.

The next step is to add factions and faction-specific fleets into the game. There won’t be any higher-level campaign mechanics yet – for now, fleets will spawn somewhere in the star system. There also needs to be a way to hire crew and buy/sell weapons and ship hulls – so we’re probably looking at some basics of interaction with a populated planet. I’d also like to add player skills and character and crew advancement – though that’s separate enough that it could be deferred to a subsequent build if need be.

But none of those are particularly time-consuming as features. The major, major task remaining is intangible – it’s simply going to take a lot of play-testing, balancing, and more play-testing to get all of the above right.

So, what can you expect?

First of all, I’m going to get a just-barely-playable version of the above together and put out a preview release to those interested. It won’t be balanced, it will have bugs, but it will help a whole lot to get some feedback. This should happen in January. After that, I’ll spend some time polishing it up and making it generally more enjoyable, while incorporating any feedback from the preview release.

I’d also like to release a demo. What I’m thinkining is to make the missions playable in the demo, and only make the campaign available after the game is activated – but to release both in the same version. That way there’s still just one download, you can make sure the game runs on your system before buying it, and it’s just all around simple.

All in all, I’m very excited that the initial campaign release is finally drawing close! … I guess I better wrap up this post and get cracking on it. That code isn’t going to write itself, you know.