Dev Update #27: Detailing the Refactoring

Last week, I told you about a major project we’ve taken up for Gears of Eden to work properly: refactoring our code!  Essentially, that means we’re fixing the code, which is a simple enough concept.  The thing is though that I keep needing to ask questions about it.  What’s being done?  For what purpose?  How will that fix it?  Etc, etc etc.  Well, it’s only natural that if someone directly involved with the project has a bunch of questions, you might have some too!  So this week, I’ve decided to dedicate this Dev Update to answering some of those questions.

First off … why are we doing this?  It’s a fair question; sure we’ll need to fix bugs at some point, but we’re so thick into the middle of the development process that focusing primarily on this endeavor seems like a weird choice.  At very least, it seems unsatisfying. (Who wouldn’t rather create than correct?) The issue is though, that it affects functionality to such a large degree that there are many situations where we might not know if things are being properly implemented.  Not only that, but it’s an important precedent to set for our development process to minimize issues like this in the future.  In regard to specifically what’s broken though, last week I described it as a bug in how the gravity functions, but really it’s a physics-wide issue, most readily apparent in the “Spider-Rover” bug and a particularly frustrating bug that has the player driver backwards a little every time they start to drive forward.  It’s important to note that it could be affecting any number of other facets of the game, both now and in the future. It’s such a game-breaking bug, that it actually prevents us from accurately testing other features that are in a review stage.

So … what exactly are we doing?  I’ll be honest with you … without looking it up, I really did satisfy myself with “refactoring means fixing the code,” as seen at the top of this Dev Update.  Really what it means though is that we’re reworking how the code itself is structured without actually changing what the code is meant to do.  The intended product of this is to improve how the game runs, both in terms of optimization and functionality.  Now, this can take many forms but in the case of what we’re currently doing, we’re attempting to make functions run more independently of each other so that we’re able to cut down on the number of processes that are needed to accomplish any one particular computing goal.

The issues we’re having with our physics come from running too many functions–from a programming perspective, not in terms of game mechanics–every time the game “updates.” Again, this is from a programming perspective; every new frame that you see while playing a game is rendered during one of these updates.  Individually, they’re practically insignificant, but when accumulated together, they’re the difference between a buggy experience and a clean experience, or (in terms of frame rate) a choppy experience and a smooth one.

It’s complicated and a lot of work, which has required a lot of sleuthing and brining new perspectives into the team, but I have no doubt that we’ll be able to meet this challenge and move back into the fun part of game development.  That’s it for this week’s Dev Update, but if you have any more questions, feel free to reach us on social media (we use Twitter and Facebook), and maybe give us a follow for the latest updates on this process!  Thank you very much for your time and your understanding as we tackle this issue.