First off: what the heck is the Codex? It’s basically an in-game encyclopedia where you can look up ships, weapons, and so on. The current implementation is very, very old and and this point really showing its age – frankly, it’s clunky and not very useful, but on the bright side, it’s also not strictly speaking a required feature, so it was fine to leave it be for a while. I’ve been on a roll with QoL work lately, though, and the game is certainly far enough along now for a proper Codex rework, so I decided to jump into it – I’d have to do it at some point!

I started working on the Codex update with a sort of standard question to get my bearings, design-wise – “why is this in the game?” That’s a question with sharp edges, because if there isn’t a good answer, then maybe it should be cut instead, and the time and effort put into other things. Obviously, that didn’t happen, or we’d have a much shorter blog post!
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 0.53a version of Starfarer is now out! This update is focused on fleshing out the combat gameplay, and future releases will focus on campaign features. That’s not to say that combat won’t receive any more attention – but this release does wrap up all of the major planned combat features.

What’s new:

• Ship systems – each ship gets an active ability – flares, burn drive, a combat teleporter – and many more
• Phase cloaking – three new ships that use the cloak as a primary defensive system
• New mission featuring phase ships
• Tons of AI improvements, new modding features, and bugfixes

You can see the full patch notes here.

Download the new version using the buttons below – you’ll need to reinstall the game, but shouldn’t have to enter the activation code again.

If you’re using OS X 10.8 (Mountain Lion) and are having trouble running the game, use this version instead.

The previous post was an introduction to ship systems. In this one, I’d like to talk about the thought process and decision making that went into the design. There are many ways to do things, and I’m not claiming that the way I ended up going about it is the best. Nonetheless, looking at the dev build so far – the results seem promising, and I hope you’ll find the process interesting. Besides, it’ll help me to put this down in writing, and then go through the ship systems again, with hopefully greater clarity of thought – so, you’re stuck with this being the subject of the blog entry. Might as well grab a beverage of choice and settle down for a long read.

A brief reminder: a ship system is an active ability, something a ship can do – teleport, engage afterburners, use flares, etc. A system is specific to a hull, and can’t be customized the way weapons and hull mods can – the goal is to make each ship have more uniqueness and flavor, as well as play differently.

The EMP Emitter is one of the more esoteric ship systems

What makes a good system?
Using a ship system is an action you decide to take, and it’s important for that decision to be interesting. What “interesting” means is subjective, but I think it’s reasonable to say that if it’s obvious (also subjective – what fun!) when to use a system, then the decision-making process is too simple. For example: if you had a system that instantly got rid of all of the ship’s flux, and could be used on a short cooldown – but otherwise freely – you’d want to use it every time your flux is right around maxed out.

It becomes a task the player is doing that you could easily automate, and that’s usually not a good sign (Incidentally: this means the more interesting the decision-making, the harder it is to write the AI for it. Argh!)

So, what could we do with a system like that to make the decision process more interesting?

The system could have a longer cooldown – if you use it now, you might not be able to use it a little later, when you really need it. I don’t like long cooldowns, though. In practice, the player will use the ability much less often, waiting for the perfect moment – or holding it in reserve against a bad situation that, if they play well enough, might not happen at all. And really, if I’m going to spend time developing ship systems, I’d like them to see more use, not less.

The system could have a limited number of uses. Even if it’s not so low as to require hoarding until the perfect moment, that’s still not much better. We start off with it being formulaic (enough uses not to worry about running out – use at “obvious” moment) and progress to hoarding when the number of uses goes down. Going from one type of bad to another – but still, it’s more interesting during the transition.

What about something completely different? Let’s say that using the system disables your shields and makes your ship take extra damage during the next few seconds. Now we’re talking! All of a sudden, you have to look at the tactical situation to see if using the system is a good idea – and, better yet, using it will influence your actions in the near future. You’ll want to keep out of trouble, but at the same time, since you’ve got all this flux to burn on weapons, you want to engage any particularly vulnerable targets.

This system was purely hypothetical, but I think we can draw a reasonable generalization from examining it: Downsides to taking an action are more interesting than limitations on being able to take an action. (You could say that the downside of a cooldown is not being able to use the system for a time – technically, that’s correct, but let’s not go there. Before long, we’d start arguing about the meaning of “is”.) The point here is that a downside opens up a new dimension of gameplay, where a limitation closes down an existing one. Unless the limitation is something that comes from within the gameplay (“you have to be behind someone to backstab”) vs outside it (“backstab is on cooldown, sorry”).

Does that mean that cooldowns, limited uses, and all such shouldn’t be used? They’re still useful balancing tools, and can meaningfully play into the decision-making process – but we shouldn’t rely on them to make mechanics more interesting. It’s ok to have a short cooldown to balance out a perfectly good skill that becomes game-breaking if it could be used every frame, for example. I’d be worried about abilities that rely on lengthy cooldowns to counterbalance their effectiveness, though.

Another aspect of a good ship system is that it’s satisfying to use (once again, subjective). I think this comes down to lots of playtesting, tweaking, and some more playtesting. The impact the skill has in the game, the graphics, the sound effects – all of these play into it. Actually having unique visual and sound effects is critical – the player has taken the trouble to make a decision and press a button, after all, so they should see something happening on the screen. It’s also important to be able to tell what enemy (and allied) ships are doing. I don’t have much more to say about this, though it seemed worth mentioning because it’s such an important aspect – but in the end,  it just takes time and iterations until it feels right.

Read the rest of this entry »

So, what exactly is a ship system? The words themselves are overloaded, so for all you know from the title, I could be talking about the ship’s life support system. Or the system for refilling the bucket for the guy swabbing decks A1 though A4 on the ISS Unlikely to Survive. (Which seems like a waste of time – for obvious reasons – but I digress.)

In Starfarer a “ship system” is an active ability that a ship has. Each ship only has one of these (if at all), and it’s determined by the hull. It’s not something you can customize, but rather something to give each hull more flavor and uniqueness. Sure, the weapon slots available on each hull are important, but at the end of the day, those are just guns. A different active system goes much farther to make a ship play, well, differently – and feel more unique.

That’s not to say that every hull will have a unique system – some will, but lots of systems will be shared between hulls, often of a similar type. For example, you might expect the Enforcer, the Dominator, and the Onslaught – all ships in the same “bull right in and keep shooting until they drop” vein – to have a similar active system. Some examples of these  systems are:

Flare Launcher:  Fires off a number of flares to confuse the guidance systems of missiles.

Maneuvering Jets: Activates additional maneuvering thrusters on the ship and greatly improves its maneuverability for a time.

Burn Drive: Allows the temporary use of the travel drive unit in combat. The power required means the ship is unable to use shields, and the highly volatile state of the engines mean a risk of a flameout if the ship collides with anything sufficiently large to jar it.

Here’s a video of these three in action:

Modding
If you’ve done any modding – or played any mods – you might be wondering just how moddable ship systems are.

A critical part of each new system – and what’s taking most of the time as far as implementing them goes – is the AI. That’s not something mods have direct access to right now, so a radically new system is out of the question.

On the other hand, I’m building the current systems with a range of options and behaviors in mind. So, you could take a standard flare launcher, and change the number and type of flares, the cooldown, the chance for each flare to be effective, the range at which it’s effective, its behavior – to some extent – and so on. It’ll still be a flare launcher, but it can be one that looks, feels, and plays very differently than the stock one. The AI is built to be aware of at least some of these possibilities, so it should allow for a good range of new systems mods can add effectively.