Welcome back to another installment of the Blightmare development blog!  The big editor refactor is finally being used by the designers now, so I think it’s a good time to take a look back at how we got here.  This post will be some thoughts about why we went ahead and did the refactor and then some stats about how long it took and how many changes were made.


The first question of course is why?  We were under no illusions that a refactor like this was going to be easy or quick, but we still decided that it was for the best.  It’s a little hard to describe exactly how I knew that we needed to make some significant changes, because it started just with kind of a feeling that the editor was slower than it should be, there were several annoying quirks (some people might call these bugs), and making changes to the code was very risky.  Sitting down to add a feature to the editor or to try to fix a bug was often a very taxing experience because the code was usually much more complex than it should have been, and there were unnecessary separations between related systems.  The technical terms for this are high coupling and low cohesion and they’re the opposite of what “good” code is.  Tom was in the middle of trying to add a bunch of camera related tools to the editor and I was trying to prototype out some boss features and both of them were just going so slowly because it was just plain hard to program for the Editor.  Meanwhile, Nick was running into bugs and performance issues while trying to make some of the later levels and all of this is without some of the more resource intensive decorations that we will be adding soon.  All of these factors were just simmering away at the back of my mind for quite a while and it became clear that we had to do something sooner or later.  In software – like many things – it’s often better to do something sooner because it’s cheaper and less painful.

Writing that out makes it sound pretty arbitrary which I think is actually pretty accurate.  One of the things I find the most difficult in any moderately complex piece of software is when to decide to live with your choices and when to do an overhaul.  It’s not always better to refactor.  There’s always new bugs, it always takes longer than you think, and there’s really no guarantee that it’s actually better at the end.  However, we decided to do it, so there’s not much sense in debating the decision now.


I’m very pleased to report that the editor seems to be in really good shape now.  It’s much faster than before – confirmed by Nick too! – and it has far fewer problems than the previous version.  This is no accident.  As I mentioned a few weeks ago, the idea was to centralize data and focus on providing a consistent view of that single source of truth.  Things pretty much worked out as planned (so far) in this regard, so the theoretical benefits of such an approach became reality. 

I’ve still got some features to add back in, and there’s a few bugs popping up, but the base just feels really solid.  We also have a significantly improved selection model that allowed us to add support for multi-select and modification of properties for an entire selection group.  The extra code to support this ended up being trivial which is perfect.  Tom’s camera stuff was already using a similar data model so it integrated with almost no changes.  All of these are great signs!


So how much work was it?  The first commit for the refactor was made on October 15 and the build was put out to the team on Dec 6.  There were a few bug fixes to the previous editor during that span to keep things working, but it was about 6 weeks of our time which isn’t small by any stretch.  In terms of actual code changes, the final difference between editor versions includes 665 files changed, 13,474 added lines, and 36,060 deleted lines.  In the end there are 127 feser files in the project and the vast majority of these are Prefabs.  Nearly all the changes were the removal of all the prefabs that we had for various bits of UI and the glue to bind them all together.  All of that was replaced by a rather simple procedural UI which looks similar but is vastly less complex.


Looking back today, I think that it was the right call.  I also hope that it was the last time we need to do something like this.  As we get closer to our milestone of having a game that is playable from start to end, I really want to focus on polishing what we have rather than trying to build new things.  I guess we shall see!



Thanks for stopping by!  Please take a moment to head over to our Steam page and add Blightmare to your wishlist.  Don’t forget to check out our Twitter to stay up to date with all the posts on this blog and any other news about the game.  Cheers!