Happy New Year all!

Over the past couple months I've made a lot of incremental fixes, changes and content additions to my local development version. Every small change has a chance of introducing a bug. So on News Year's Day I started a full playthrough, something I haven't done since launch, with two goals: 1) seeing whether anything has broken and 2) seeing if the collective changes are ready for player testing.

A full playthrough takes quite a while, so I'm only about half way through. I've discovered one new bug that has been in the game for over a year, but was only revealed through a recent change.

Currently, there is a bug where if you load a save, any damage to your ship would instantly repair. So I've fixed that exploit. But in this playthrough I noticed that sometimes I'd reload a save and have damage when there shouldn't have been any.

After investigating, I figured out the cause:

What was going on was that a while ago I added an optimization that cached your most recent save after reading it from disk, so when the player did a quick load or died the save manager could quickly pass that to the game without spending 200ms or so reading it.

The problem is that the various game systems assume that when a game is loaded, they can take any values passed to them and assign them to their respective variables.

For example, if the save file says the player has 2000 RP, then the game sets the player's RP to 2000 RP. This is not a problem and will not cause a bug because RP is an integer and integers are value types. The game can change the amount of RP that a player has, but there's nothing that will change the value of the number 2000.

But some of the data is more complex. Things like the structure of ships are represented as a bunch of ModuleData's. A ModuleData is a collection of value types (HP, rotation, module type, etc) represented as an "object". An object is a reference type, which means that when you pass it around, you aren't passing around copies of various values, you're passing around an address in memory where those values are stored.

So when I loaded the cached save, the save system handed the ship a list of modules which it used to reconstruct my current ship. But when I flew into battle and the enemy started blasting at me, my modules were still referencing the objects in the cached save for their data. Which meant that the enemies were actually damaging the modules my save game.

Now I had designed the save system very much knowing about the possibility of accidentally referencing save data, which is why the save system uses "cloning" to create copies of the game data. But it only does this on the "save" side. I suspect when I implemented the cache I had forgotten this and thought it also happened on the "load" side.

Anyway, I'll be continuing the playthrough for the next day or two. Depending on how that goes I may either spend more time tweaking, or make it available as an opt-in test build. So stay tuned!

Until next week,
- Kevin

A short update this week as I spent a few days with the family for Christmas.

This week I spent some more time on the side-quests I previously discussed, created several new related anomalies and tackled some bug fixes.

I've previously talked about how I create most anomaly images using an environmental rendering software product called Vue. Earlier this month I got a reminder from the software that my license was about to expire. When I went to renew, I discovered that the company who made the software had been acquired, and development for the product would cease.

On the plus side, they're now giving it away for free[www.bentley.com]. So good on them for that. It still works for my purposes, so I plan on continuing to use it. It's not as general purpose or feature rich as something like Blender (also free), but it is much easier to quickly create cool environment images.

Some anomaly images created with Vue plus some 3rd party models.

Happy holidays and hope everyone has a wonderful New Year!

- Kevin