One of the goals for the next version of is to improve the way you give orders to your fleet. It’s a delicate balance – the orders you give should shape the battle, but spending too much time looking at the map and giving orders detracts from the experience of flying your flagship.

The original (and as of the latest release, 0.34a, current) version of the fleet control interface was very RTS-like. At first glance, it seemed like a good idea – why reinvent the wheel, if there’s an already widely-known way to control multiple units? Unfortunately, as the combat gameplay took shape, it became more and more clear that the RTS model is a bad fit for Starfarer.

Why, you ask? There are two main reasons.

One, it set the wrong expectations for the level of control you have over your ships. RTS units are typically instantly obedient drones. Starfarer ships, on the other hand, have to be smarter than that to make interesting opponents in direct combat. The trouble is, it’s hard to make them obey orders to the degree that’s suggested by the RTS control scheme. Either they obey immediately and possibly get killed for their efforts, or they take their time and carry out orders when the tactical situation allows – and appear to be ignoring your commands in the meanwhile.

Two, it allows – and sometimes requires – too much micromanagement. You can keep track of every fighter wing and order it to go to a carrier for repairs any time it takes too much damage (they do so on their own, but sometimes an earlier, explicit order ensures a wing will survive). You can manage the composition of groups in detail – possibly getting a little more efficiency in the process. You have to manage the groups to begin with, when you deploy the fleet. To play optimally, you have to keep going to the map to evaluate the situation and give orders here and there several times a minute.

You can do well just giving a few general orders, but knowing that optimal play requires more micro than enjoyable is hardly ideal.

So what’s the solution? First, let’s rephrase the problem – in the RTS control scheme, you tell your units how to do things. Go here, shoot this, group with these other units. The units have no concept of your larger goals. Instead, why not tell your ships what to do, and let them figure out the details? If you were the commander of a fleet, that’s exactly what you’d be doing – delegating, and reserving your attention for the things that matter.

Now, let’s dive into the gory details.
Read the rest of this entry »

The next major release is going to let you create custom ship loadouts. These include picking from a large variety of weapons – 47 and counting, as of this writing. But if you’re going to pick weapons intelligently, you need to know what they do.

Weapon Lore

Cold, hard numbers are great when you’re comparing the finer points, but for an initial “just what is this” moment, you need a description. Therefore our resident lore master, Ivaylo, has been working night and day (or so he tells me) writing them. I thought I’d share a couple.

Heavy Machine Gun
Primary role: point defense
Mount size: medium
A workhorse of patrol craft across the sector, this weapons system features a reliable, centuries-old blowback firing mechanism. Safety features include a positive cook-off safety for open bolt clearing and double ram prevention. The weapon is typically mounted on a relatively heavy base to help absorb recoil during prolonged bursts of fire.  Calibers vary, but are usually in the 17-20mm range. The heavier projectiles do not shatter upon impact like lighter ammunition and present a credible threat to frigate-class vessels. Extremely accurate, though slower-firing than a vulcan cannon.

Sabot SRM (Short Range Missile)
Primary role: close support
Mount size: small
Sabot-class class missiles are short-range, two-stage KE weapons. A guided missile first stage projects a secondary assembly to within striking distance of a shielded target. A targeting computer then ignites the propellant for the KE penetrator. This “sabot,” as it is commonly called, is typically a narrow, laterally stabilized projectile manufactured from an ultra dense material such as depleted infernium.  Excellent at bringing down enemy shields and causing an overload. Standard ship armor is spaced and thus the damage the sabot causes is largely contained if it gets through the shields.

“Mjolnir” Micro-singularity Cannon
Primary role: assault
Mount size: large
A very advanced design, the Mjolnir is technically a magneto-gravitic shell projector, not a standard cannon. The micro capacitors within each shell are able to deliver enough energy to create a localized singularity with a Schwarzschild radius of 1.8 millimeters. The built-in gravitic lens devastates all nearby matter, especially dense objects.

Weapon Roles

A key bit of information when checking out a new weapon is its primary role. Most weapons are useful in a variety of situations, but the primary role reflects the weapon’s intended design and ideal circumstances for its use.

Assault
The weapon has a high damage output, but limited range. Assault weapons are usually good on well-armored ships that can afford to take a beating to dish one out – or on faster ships that are hard to hit.

Close Support
The weapon has a good range (generally, up to 2x that of assault weapons), but is limited in some way – overall damage output, ammunition, rate of fire, etc. Depending on the specific limitations, close support weapons excel in many situations ranging from harassment to delivering a killing blow against an exposed enemy.

Point Defense
The weapon has a sophisticated targeting system that allows it to automatically target enemy missiles. Other common characteristics (such as a high turret slew rate) make point defense weapons good against fighters as well.

There are several other roles – strike and fire support, to name two – but I’ll let you guess what they are. The first person to guess correctly wins a prize, which is the satisfaction of being the first to guess correctly and winning a prize.

If you’ve been keeping up with the ongoing patch notes, you probably know I’ve spent most of the last week re-working large parts of the ship AI.

A week ago, it was in a decidedly “if it ain’t broke, don’t fix it” state. In fact, it was quite good, except for a few dumb things it sometimes did. Still, Starfarer is a single-player game, so good AI is critically important, and these needed to be fixed. Armed with a list that I’ve been updating based on player feedback and my own experiences, I decided to devote a few days to eliminating them.

As an aside, making the AI not do dumb things is as important to the experience than making it do smart things, maybe more so. Seeing it do something ridiculous – such as repeatedly ramming a friendly ship in an attempt to escape some other danger – is immersion breaking. But if it tries to do something smart, you better make sure its plans actually come off, or it will look silly anyway – since as the player, you usually won’t know what smart thing it was trying to do, but will see it fail. The payoff for doing something smart is lower than the penalty for doing something inane.

It is wholly a matter of perspective, though. If your goal is to have the AI maneuver more strategically, you might state it as “avoid being surrounded” (negative – don’t be stupid!) or “keep enemy ships in one general direction from itself” (positive – do something smart!). Notice that the negative goal is easier to state – and if it’s easier to state, chances are it’s easier to approach when it comes time to implement it.

Incidentally, almost every new gameplay addition breaks the AI – either by making it easily abusable, or worse – so AI work is always going on behind the scenes to keep up with features.

Collision Avoidance
So, after fixing most of the items on my list, I realized that there was a big problem there wasn’t a quick solution to – collision avoidance. The algorithm I had implemented initially had some issues that could not be easily fixed. I know that, because I spent almost a whole day trying! It was time to toss it out and start fresh.

The main trouble with the old algorithm was that it wasn’t context-aware. Collision avoidance isn’t something you want to be doing all the time – generally, a ship is trying to do something else that’s actually useful, like attacking an enemy or getting out of danger – but then you also want it to not run into things while doing these. The old algorithm was an all-in proposition – if you were in danger of hitting something, it took over without regard for what the ship was trying to do at the time. Oftentimes, it would end up on the wrong side of a broadside as a result of successfully avoiding a minor asteroid.

The challenge was to come up with a collision algorithm that could incorporate current ship preferences into its response to potential collisions.

The first part, expressing ship preferences, was easy – the ship AI simply keeps track of which direction it wants to be going, and tells the collision avoidance module. For example, if it’s strafing around an enemy ship, it wants to go away from it if it’s too close, and towards it if it’s too far.

The hard part was coming up with an algorithm that could both be successful at avoiding collisions and could accept this preference as an input. Instead of talking about it in great detail, I recorded and annotated a video showing it in action first, with overlays that tell you what the AI is thinking at any given time. Seeing it will really help make sense the explanation that follows.

In the video, the blue line shows where the ship wants to go. The yellow line shows where the collision avoidance algorithm actually tells it to go. Green arcs show potential collision dangers. The arcs turn red when the danger is imminent and the ship is actively avoiding it.

Here’s a high-level breakdown of what the algorithm does (continued):

Read the rest of this entry »