Hello everyone!  Welcome back to another Blightmare dev blog!  Today is going to be pretty short for reasons that I’ll get into in a little bit.  Anyway, I hope you all are staying as safe as possible and making the best out of this unfortunate situation.

The topic today is upgrades.  Blightmare uses a few external libraries extensively so that Tom and I can focus our time on things unique to the game.  In particular we use Wwise for audio and Spine for animations.  These are both industry standard tools that have official Unity integrations and enjoy widespread use.  I had some experience using Spine from a previous job and our audio wizards knew their way around the Wwise tools so these both seemed like good choices.

There’s always a risk when you use something that you didn’t create in a project.  Largely that risk is that it won’t do the specific thing that you need it to do.  The benefit of using a library is the time saved by not having to build whatever the library provides.  Determining if the risk is worthwhile is a complicated task that is probably never fully knowable in a production environment because doing both is almost certain to hit the budget or schedule too hard to justify.  Other factors that go into the decision to use a third-party library are: how easy is it to understand how it works?  Can you change part of it to specialize for your use case?  Is it optimized well for your data?  Can you update it easily?  And the list goes on.

A couple of weeks ago, I set out to upgrade Spine and Wwise in Blightmare to take advantage of some new features and generally maintain compatibility with our – also updating – version of Unity.  My original estimate for this was a few hours one night and so I found some time, turned on some retrowave and got started.  The upgrade this time was part of a broader audit of the project to remove things that were no longer used an organize everything else.  As part of this, I wanted to put all our external dependencies together in a folder called “External.”  This went very smoothly for Spine.  I downloaded the updated runtime asset, removed the old one, and imported the new one into the project.  After that, I was able to just move the runtime into External/Spine and verified that everything was still working.  45 minutes in and already halfway there.  Time for a beer.

Wwise is up next.  It has a launcher application that you have to install and manage updates with externally.  From here you can launch the very powerful authoring tools that they have which can communicate directly with Unity and allow sound designers to do their work.  We are currently using the latest official Unity release, so I went ahead and updated my Wwise version to the latest release version and pressed the “Update integration” button.  What followed was several hours of frustration as the automatic integration process failed over and over.  I eventually determined that it was just not possible to relocate the integration from the default which is a folder at the top level.  I came to this conclusion by actually reading the source code.  Documentation can be out of date or incomplete, but the code cannot lie.  So now, 4 hours into my task, I gave up on the plan to neatly put external dependencies in their own folder, and allowed Wwise to be special.  After a couple more tries which required cleaning up remnants of past failures, the integration succeeded.  Hurray!

The next day I was going to do some testing to make sure things were still working and then publish the changes in source control.  I decided to change computers for the testing because it was finally a nice day outside.  My laptop is a mac unlike my desktop which is a pc.  This shouldn’t be a big deal right?  Unity, Spine, and Wwise work on many platforms.  We have been using them for years now on pc and mac without any issue.  However, as soon as I grab the changes that I made last night, I can no longer make changes to code with Unity open.  The recompile step that Unity does results in some kind of crash deep within some core libraries that not only crashes the editor, but it invalidates my local assets requiring a re-import on next launch.  Re-importing assets on a small game like Blightmare takes several minutes.  On a large game this could take hours, but fortunately we’re not in that boat.  Now my task was to figure out what the problem is and make very selective changes because it took a long time to see any effect.  Nothing seemed to work.  At the 10 hour mark of working on this task, I decided that it was not worthwhile to spend any more time trying to make it work and I instead set about downgrading Wwise to the version we had working previously.  This did eventually work, and we once again have functional audio in the game.  All in all I spent roughly 12 hours upgrading these two libraries, with by far the most time spent on Wwise and it’s inflexible automated installer.

The point of going through all of this is not just to vent about how annoyed I got at software that didn’t work.  Instead it is to show a very practical reason why we made the unusual decision to build our editor as a standalone application instead of just using the Unity editor.  Being able to control the tools and environment that you use is so critical to efficient development and as a result, the quality of the final product.  As we get further along in the development of Blightmare, our ability to optimize code, assets, tools, and really everything, will become more and more important.  Optimization is only possible by understanding why and how something works.  The simplest way to guarantee that understanding is if you built it yourself.


Well that was quite the ramble!  If you made it this far, then thanks for reading!  As always, if you like the content here, please follow us on Twitter and wishlist the game on Steam to make sure you can get all the latest updates.  Cheers!