Project: Backfire

This is a project that I worked on for a good 3 years with the Gauge Entertainment team. I had joined them back in late 2009, and prior to that they had already put about a year worth of work into the game between original seven members. In that time, they were able to get something playable with some very basic elements implemented. It wasn't pretty, but it worked. I'm not going to take too much time going through team dynamics; this is going to focus all on what went right and wrong with Backfire and how it has shaped my career.

As you may have read in the old post below this one, my early days at Gauge was interesting for me a the time: it was my first foray into working with a proper team, working on an engine I had really just scratched the surface with. It was a time where I had to learn quick to be any use, and learn quick I did. However, how that ended up helping the project is arguable, with several factors at play. This ended up being a lesson in endurance, ego, and when to restrict features. This blog has many times stressed a major reality of game development: understanding what feature creep is, and executing self restraint in your design. This is crucial if you ever want a proper finished project, which this project never was, even after a total of 4 years in part-time development. That doesn't mean there wasn't a lot learned, and a lot to be proud of, however. 

Backfire itself was built to be a response to the lack of car combat games at the time. it was 2008, the whole indie game revolution on Xbox Live had really started to grow just a year ago, and the boom of car combat games like Twisted Metal and Interstate '76 had calmed and dissipated as the 90's had. The project itself was to not only hearken to those days and influences while modernizing them. We wanted a more physics driven and simulation-based driving model, destructible vehicles instead of a life-bar, and a fully customizable load-out system for each vehicle. It was a project much larger than we were, though we didn't see it at the time. We had something playable, after all, and that alone kept us driven to keep working on the project.

In that time I learned the tools of the trade to create a texture for a minigun weapon that had previously been modeled, figuring out good practices for making the diffuse, and then generating the normals and specular maps through tools like Crazy Bump. It took much longer than I had hoped, largely because I was young and foolhardy so I ran headfirst into the tools without really looking for help. This ended up causing the texture to take much too long, and had several very simple rookie mistakes such as not taking into account how rust would realistically set, and incorrectly using the generated textures from Filter Forge. That said, it did give me a good insight as to what it took to make a texture and much respect for modelers and the act of creating a UV map.

From that point forward, I worked more with what I knew best: code and Flash. As such, I turned into the UI designer of sorts, working with Actionscript 2 files and Unreal Script to make developer interfaces. Sadly, it was never anything more than development tools simply because we didn't have someone who could dedicate some time to the art I would need, nor were we in a place to worry much about interface beyond these few tools and some basic player information. As such, I tried to help where I could directly on coding and testing nights.

I very quickly found  that I was more useful to the team in this sort of role. Using what I knew of the code, testing the limits of what had been implemented led to a lot of bugs being squashed, and lots of issues with the level that had already been designed and built before I had joined. This was also the time that a lot of the pace of the project slowed. We already had a pretty rough schedule as-is, with maybe two nights a week in which the coders would work together for maybe four hours at a time, if that. This caused the production schedule to get out of hand rapidly. To add to this, Gauge as a whole was also in the process of building an office space, leading much of the needed hours for the game to go towards drywalling. The project had gotten too large, and the time available had become too little for us to continue on the project, and shortly after we showed a build we had at a local GameCamp meetup, we had to reassess the project and shelf what had become a near half-decade worth of work for many of the team.

What went Right: 

-Hitting on all aspects that could be where my specialization lie. I had no idea where I would excel, but it is so very important starting out.

-Consistent art style that ended up making it look pretty darn good, everything considered

-Consistent design, we kept true to the simulation feeling driving with a more modern feeling when it came to the shooting.

-Getting a playable project up and running right away was a strong suite, considering the tiny bit of time that was available per week and the size of the team.

-Persistence. Projects can take time, and being able to come back to it time and time again is very much a needed factor, and this whole team had that...

What went Wrong:

-...To a fault. There was a lack of self reflection on our own limitations. Taking the scope and available time though the looking glass should have been prioritized. much sooner, and maybe we'd have a success story of a project.

-The team lacked dedication to the project this large in order to complete it.

-We could have just used someone's basement (garages get cold up here in the North) instead of dedicating so many resources to an office that we didn't end up using anyway.