The title of this post is deliberately misleading. It’s mostly about crew management and me, you see. Specifically, about how the current system came about – and what it is. But now that I’ve tricked you into reading, I hope you’ll stay with it – you won’t get those couple of seconds back anyway, so might as well keep going!

There are three main reasons to have crew in the game: to increase immersion, to add another avenue for advancement, and to introduce interesting resource management mechanics. In other words, having a tangible crew is neat, watching them go from raw recruits to seasoned veterans is rewarding, and having a say in how the crew is used to get the most out of them is engaging. The crew is far from being the main mode of advancement, though – the player also has their own skills, officers, ships, and weapons to upgrade – so it’d be a mistake to look at it solely from the player advancement angle.

However, figuring out just how to model the crew of your ships has been a difficult process. There are two components to the mechanics: advancement and assignment. Advancement is how the crew progresses through experience ranks. Is it linear, or can crewmen specialize in gunnery, piloting, and such? Assignment is just how the player matches up the crew to the ships they run – what amount of control they have over it, and exactly how it works.

The Problem
Those components depend on each other a great deal. Suppose the player just has one ship – we don’t need to worry about assignment at all, then. Free from this concern, we could come up with an involved scheme for crew advancement – with individual crewmen progressing through the ranks all the way from raw recruit to master gunner or somesuch.

On the other hand, suppose the player has a large fleet. Do we really want them to worry about making sure the ISS Unlikely to Survive has the right number of gunners? If they’re losing a ship or two every battle – and with large fleets and battles, that’s quite likely – having to re-crew new ships afterward would quickly become a chore. What we need is to strike a balance – enough detail for immersion and sense of advancement, but not so much that the mechanics become a bother for large fleets. The mechanics should let the player make meaningful choices with a minimum of fuss – not make them perform rote actions over and over.

The crux of the problem for me was the need to assign crew to specific ships. I kept turning that over in my mind, and just couldn’t get around the awkwardness of having to manually do it. You’d have to handle it for new ships, for re-crewing ships after losses, and for switching crews around for key battles – to name just a few situations. It’d be a royal pain.
Read the rest of this entry »

Picture this – you’ve built up just about the toughest merc outfit this side of the sector. Your officers are all hardened veterans. Your ships are outfitted with the best weapons and hull mods. Your skill is legendary, your reputation for prevailing against incredible odds unrivaled. Then, you encounter a small enemy convoy – they pose no threat, but the resources they carry would be a welcome addition to your cargo holds. With hardly a second thought, you order an attack – but really, does such a minor fleet action demand your personal attention? “I’ll let my second-in-command handle it,” you decide as you press the button to auto-resolve the “battle” not worthy of the name – it’s target practice, really. But a nasty surprise awaits – you’ve lost a top-line ship, and two elite officers are dead!

… and that’s the scenario we all want to avoid. Auto-resolve has great potential to frustrate the player, because it can obliterate their progress (in the form of resources, ships, and officers) – but worse, it can do this unfairly. The unfairness comes from breaking the player’s expectations of how the game world works. In our example, the player knows their fleet can mop up that convoy – but auto-resolve plays by a different set of rules, one the player hasn’t been exposed to before, one that isn’t clear. Even worse, the rules are hard to learn because they’re hidden. In the situation above, the player might assume that luck plays a big role – but it may well be that the officer skills weren’t valued as much as they should be, or the weapons you’ve equipped the ships with, or any combination of those and other factors. The player might give up on auto-resolve entirely – there’s no clear way to get better at it, and it’s not apparent whether improvement is even possible – and the player is punished for experimenting.

It’s still necessary though, because the alternative is having to fight every piddling battle yourself. Besides, battles that don’t involve the player need to get worked out somehow. So how can we address these underlying problems? Because I like lists, let’s make a list of things that aren’t fair to do to the player:

• ignoring any improvements they’ve made to their fleet – be it weapons, hull mods, officers, character skills, anything at all that has a bearing on combat
• ignoring the overall rules of combat the player knows – carriers increasing the effectiveness of fighters, bombers being effective vs large ships, point-defense weapons countering fighters, etc
• destroying any ships which would absolutely never, ever get a dent put in them if the actual battle was played out. A wing of Talon-class interceptors should have no chance to take out a wing of Wasps, for example.

To sum it up, the auto-resolve system has to roughly simulate the way combat plays out, take all relevant ship & fleet stats into account, and be very careful that “adding a degree of randomness” doesn’t become “anything can happen”.

One thing we can’t take into account is the actual player’s skill at piloting (not their character’s skill, which can be). That’s ok – a battle where the outcome hinges on the player’s personal skill shouldn’t get auto-resolved to victory, anyway. More importantly, I think the player wouldn’t expect auto-resolve to do as well as they do with themselves at the helm.

In the remainder of this post, I’ll talk about the approach I decided on and give some examples of it in action. Read the rest of this entry »