0.3.3.02 patch notes

Posted On 5 Jan, 2016
Featured08

0.3.3.02 was a small patch in terms of notes, but a huge patch in terms of changes, thus I will make these patch notes in the form of an explanation instead of in the form of a list. Also in the form of a list.

Note: This patch does not invalidate save files.

0.3.3.02 changes:

  • massive overhaul to how threads are managed which should result in both performance gains and less random bugs
  • fixed a bug where light shafts generated by backdrops would be invisible after changing screen sizes
  • added music

Thread Scheduler

So the main thing I built for this patch is a scheduling engine for all threads. If you follow our development at all you probably already know that Wayward Terran Frontier makes massive use of threading in order to simulate an absolutely insane amount of stuff all at the same time. To satisfy my need for lists, here is a list of things that are done concurrently in Zero Falls:

  • Generating sector maps
  • Saving sector maps to the disk
  • Populating the universe map with stars
  • Loading textures
  • Loading music files
  • Transferring data to and from the GPU
  • Simulating every single ship interior
  • Breaking of ships into pieces

If you have ever worked with threading an application before, you probably know how much of a pain it can be to debug thread interactions, and for a long time Wayward Terran Frontier has had a number of bugs that fell into the “random” category caused by exactly that. Specifically by the last two bullet points and how they interacted with the player entering and exiting ships, as well as how they got cleaned up when saving the game. A big culprit of save game corruption for instance was the fact that sometimes a ship would save itself from 2 threads at the same time resulting in a ship being saved with missing data.

The solution then was to do as I usually do in these situations: tear the whole thing down and rewrite it from scratch! I built a system that I call a scheduler because that’s essentially what it does. Things which once had their own thread are now jobs that get performed by a pool of threads, and the order that they get performed in is now controlled very carefully by my new code to prevent any sort of weirdness. The result is that hopefully entering, exiting, saving, loading, and exploding ships should now be extremely predictable and not prone to interference from strange timing issues.

Performance gains

The scheduler also has a second benefit, and that is massive performance gains. Before, every ship instantiated a thread and would attempt to update its interior as often as the system would let it. Small ships could move their air and power and crew around hundreds or thousands of times while large ships did it once or twice, and usually all of the system’s CPU resources were used all the time. Of course you wouldn’t notice because the algorithm wasn’t tied to frame rate. While crew in a big ship took 5 steps to move one tile, crew in a little ship took a thousand steps to move one tile, but both would do it in the same amount of real time. This worked only because the operating system has its own scheduler and honestly windows does a pretty good job of making sure every thread gets its turn.

Now I do the scheduling, and the results are fantastic. Instead of updating as many times as it can before the operating system calls time out, each ship gets updated exactly once. When it is done updating a ship, the thread moves on to the next ship, and if there isn’t one it goes to sleep. The result is that instead of using 100% of the CPU all the time we use exactly as much as we need, only when we need it. The gains are on the order of 99% and updating ships is no longer CPU bound on multi-core processors.

Now here’s the disclaimer for FPS concerns: This system makes threading better for stuff the player is not looking at. It will reduce or remove the limit of how many ships can be in combat at the same time, but it won’t change the speed of updating what the player looks at. FPS when in a big ship is not affected at all, because that gets updated on the main game thread.

Music

Simply, we added the first batch of music to the game.

Music is tied to biomes, (our name for different areas of space that look different and have different stuff in them) and so you will have to go exploring to hear it all. The fancy threaded loading, unloading, and cross fade system is something that was built a while ago to deal with….monogame issues….but the music itself is slightly more new having waited only ~2 versions for me to get it implemented.

Chris worked a really long time on this stuff and we’ve been very impressed with the results. The music system as a whole can expect lots of tweaks and tuning in the future, but the audio tracks themselves are very exciting to finally have in. I wanna hear what you think.