If you’ve been keeping track, about 3 months ago, I decided to push back the next release in order to get the initial version of the campaign implemented first. I thought I’d talk a bit about the progress that’s been made, and what to expect in the near future.

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.

David sent this to me a little while back, and I thought it was very cool to see all of the ships together like that. Most of these are in the game, but some aren’t just yet and a few may or may not make it.

A lot of the ones not currently in the game hint at features under consideration. Let the rampant speculation begin!

Click on the image to view at full size

I just added two new ships to the game, and thought I’d talk about the process that’s involved in determining ship stats, the types of weapon slots that they have, and the role they fill in the game. First of all, there are already lots of ships – around thirty if you don’t count fighters, and about a dozen more if you do. If you’re like me, that might set off some alarms in your head – why are there so many? Is it just variety for the sake of variety, or is it in fact meaningful? That’s what I always wonder about when I see a game tout “500 this” and “200 something-or-other” in their feature list.

Not every ship needs to bring something unique or interesting to the table – if nothing is “average”, then it’s hard for anything to be special. On the other hand, if two ships fill the same role in the same way, that’s a bad sign – it’s a wasted art asset, and complexity added to the game that doesn’t pull its weight by giving meaningful choices to the player. Still, having more ships is good if they pull their weight – it gives the player more choices and avenues for advancement, never mind more varied opponents. Having enough ships to give factions a stronger identity is important, too.

So, what are the factors that differentiate ship designs?

First of all, there are 5 size classes – fighter, frigate, destroyer, cruiser, and capital ship. We’ve also established three tech levels for ship designs – low tech, midline, and high tech. Low tech ships have high armor and a mix of ballistic and missile weapons. Midline ships have a mix of all types of weaponry, and average armor and shields. High tech ships rely on energy weapons and missiles, and typically have lower armor and excellent shields, in addition to improved mobility. Ships can also have launch bays for fighters – with some ships being dedicated carriers.

Just those factors combine to create a lot of combinations – a low tech cruiser? A high tech carrier? You can also easily make a ship distinct by giving it something special – such as, say, a weapon slot that’s too large to be normally found on ships of that size, or exceptional movement speed. Where the weapon slots are located and what arcs they cover is key to how a ship plays out – for example, having an important weapon battery point slightly to starboard will affect the best way to pilot a ship and will be a constant tactical consideration.

To top it off, not all ships are dedicated combat vessels – they have stats such as cargo, fuel, and crew capacity. Down the line, I’d also like to add active ship systems (such as afterburners, a combat teleport, or an ECM device). Between all these, keeping ship designs varied is easy.

Up til now, we haven’t had any particularly large high-tech ships in the game that could also put out a lot of firepower. But that’s about to change – allow me to introduce the Paragon-class battleship and the Odyssey-class battlecruiser. These two are anything but average.
Read the rest of this entry »

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 »