It’s week 15 and my furlough has been extended, which means a couple more quick sprints of full-time development before I have to go into slowmode!
Last week I released a demo build on itch.io 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.
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.
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’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:
- A ship does something that causes their bounty to rise (e.g. threatening another ship, firing a torpedo, attacking a station)
- If their bounty rises above a set threshold, all stations in the sector will broadcast an open bounty on that ship.
- These stations will list open bounties on a bounty board, with details of the crime committed.
- If the ship is destroyed while a bounty is out on it, it’ll drop a flight recorder.
- 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.
It was difficult to code, 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.
Anyways, I’m writing this on Thursday and I’d like to get the update out on Friday, but as the project grows the test and build process is getting longer and longer and my rustbucket old PC is feeling the strain, so apologies if the build isn’t quite as quick as I’d like.