Failure Cascades

Last week I released a demo build and received a bunch of useful feedback from early players – both on itch.io itself and on the Discord. So far reception has been encouraging, but a few design and technical issues are preventing people from playing the game the way it was intended.

The biggest problem turned out to be the component failure system – people weren’t able to get anywhere because things on their ship kept blowing out and breaking things. This is a feature, but I was surprised how much it was bothering people.

I spent ages thinking about experience design and how frustrating the player might find it to be interrupted, when that was one of the cornerstones of the game. Then I jumped into a quick test myself and noticed something was extremely wrong.

After some investigation, it turned out that components were failing too frequently because I accidentally changed a 13.5% chance of failure to a 135% chance of failure. At least it was an easy fix in the end.

Voice lines

It’s important that players know when something’s gone wrong in their ship. Since audiovisual cues can be missed when the player is in a different room, I’ve added some placeholder voice lines in so that the ship’s AI can speak to the player.

Hopefully these will be actually voice-acted in future, but for the time being I’ve just done some creative editing of a text-to-speech engine’s output to make it sound like a bargain-bucket version of GLaDOS.

Not-GLaDOS will notify you when it detects a major fault or serious hull damage, plus a couple other events that are worth listening out for.

I did it just by mucking about in Audacity (a free open-source audio editing program) - by duplicating the voice track, delaying the copy, compressing it, adding a slight ring modulation and reverb effect, and lowering the pitch by 10%. Any more than 10% and it started to sound 'edited', but 10% was just enough to give it a more authoritative, robotic tone without making it obvious that it had been pitch-shifted.

Bounty Hunting

I’ve been meaning to implement this for weeks now but it was a bit of a daunting task. I didn’t realise how much of a pain it would be or I probably wouldn’t have started.

The general concept was: stations have a bounty board, naughty NPCs can accumulate a bounty, then the player can destroy them and collect the bounty for cash.

The big challenge with this is that this new system needed to interact with almost every other system in the game – save/load, combat, comms, the station update cycle, the driftingCargo system, policing and piracy. It was also a design problem, since it wasn’t immediately clear whether bounties should be quests or not, and whether they should be handled by the quest system.

In the end I decided no, because I wanted NPCs to also be able to hunt and collect bounties from each other, and quests are a player-focused concept. Here’s how the system ended up working:

1. A ship does something that causes their bounty to rise (e.g. threatening another ship, firing a torpedo, attacking a station)
2. If their bounty rises above a set threshold, all stations in the sector will broadcast an open bounty on that ship.
3. These stations will list open bounties on a bounty board, with details of the crime committed.
4. If the ship is destroyed while a bounty is out on it, it’ll drop a flight recorder.
5. If the player grabs a flight recorder and takes it to a station, they can collect the bounty on it, regardless of how they got hold of it.

It’ll need a bit more work – ideally NPCs would try to snatch up flight recorders and collect those bounties themselves, and they don’t yet. NPCs will sometimes pick up and hunt bounties, but at the moment they make no attempt to claim the reward.

These systems all make heavy use of C# event hubs (I detail this process here) and probably couldn't function without them - because any entity in the game can notify the simulation of any kind of change, my factories and managers can easily keep track of what's going on in the galaxy around them. It's the difference between having to deal with events at the time and place they occur, and being able to handle their effects in a completely different context.

For example, without event hubs I'd probably just have to pop a message up on screen as soon as the player killed their target, saying 'Congratulations! Killed bounty! 100 points!' This might be fine for an action game, but for a simulation I wanted the player to feel like they're living the space trucker lifestyle, with all the legwork and delayed gratification that implies.

This system was difficult to build, but it wasn’t nearly as frustrating as this sort of thing has been on my previous projects. I think having designed these systems from the ground up to be modular and extensible has really helped – adding features hasn’t, so far, required a lot of refactoring or breaking things. I’m actually surprised this whole system came together in one day of work. Whether it’s any fun remains to be seen, though.