(If you want to play the game in question before I rip it apart, it's over on Itch.io.)

Just two weeks ago I was trying to put together a video game in 72 hours. I had a concept that I knew I could build in that time and I ran with it, even if it wasn't the most unique or interesting thing. This turned out to be one of the best decisions I could had made working with such limited time, even though the game I built sucks. Like, really sucks. 

The game isn't fun or interesting, there's no good feedback when a shot is launched, making the base gameplay stale. The wind system doesn't shift in a way that makes it interesting, and is more of an annoyance. There are usability issues everywhere as I did not plan the UI around the background image I drew hastily in 20 minutes. (and was one of the last things I did before the deadline) So with descriptions like this, it's not surprising that I did not hit any sort of quality standard, but I am still proud of the experience.

Quality in creative works in a hard thing to achieve. I liken it to a dragon you are trying to chase, in a dark non-euclidean void. It seems so simple: its right there. Making the assumption that you just need a little push towards it and you'll reach that goal is an easy one to make. However, you find very quickly that making it just a few inches in that direction is much much harder than one could imagine. That difficulty is where you learn as a creator, and far too often I see and hear of those with inspiration simply give up as they find they can't find the right path to success. This is a part of the process that should be celebrated, as you are actually creating, with success and failures just being the result of it all. You know the whole saying of "It's not about the place, it's about the journey"? It's overused and cheesy as could be, but its so very applicable in being creative.

So, back to making things that suck: what does having a project that, in your eyes, fails actually mean? It means you've learned. Back to my weird depressing analogy: you've navigated part of this maze before. You now know that doing one thing will be good for a project of that type, and you know many things that are bad; you can cross off those paths the next time you tackle the same subject. This is important. You aren't going to make just one game, one prototype, one texture, one model. You are going to make many, and how you slowly make your way towards quality. This is just a step for me, part of that journey.

Update October 9th 2016: due to the sensitive nature of part 2, no matter which way I've written and re-written it, it does not come off in the constructive way it should. As such I not be publishing part 2.

Within the core principles of the Backfire design document, the Backfire project was to live off of many of the ideas presented in our biggest influence: Interstate '76. Balance was to be found directly from players customizing their cars, which all had a base stat line and limitations would only be based on a a weight limit stat and the amount of hard points on each vehicle. The hope was to have that system, a location specific damage system more akin to Mechwarrior, and have a simulation and physics driven driving model, to then have a easily recognizable and understandable system for players to pick up and know where they are useful and what tactics will work in their favor or not.
In theory, it was a sound idea: game exploits of the games we were inspired by would be non-issues: we didn't have a Gauss rifle that could shoot further than what could be rendered on screen, and our 'leg damage' equivalent of having a tire shot only affected mobility and didn't take the player out of the game. To add to that, our aiming system was assisted and had no direct precision fire, leading to most tire hits to either be good angling by the player and using level geometry to their advantage. While we never did implement a way to fully customize the vehicles in our final pre-alpha build, we did have a multitude of test loadouts to try these different tactics and see how the driving model handled the weight differences.

Another pillar for the project was to have destructible parts for the vehicles, both to act as a balancing factor for those who wanted to have a large collection of guns on wheels, as well as an easy reference to player state mid-game without the need of health bars or other game staples we wanted to avoid and to allow for more tactics for the player to take advantage of. I distinctly remember one meeting where we had brought up how difficult it would be to play has a car with a speed focus: you would be the most vulnerable on the team, and would have the least fire power. How could you be useful? We then discussed how a fast player could be more focused on taking out previously damaged areas, such as doors or the windshield, generally leading to the killing blow. While this concept remained at the top of the priority list for the whole of the project, we never were able to take the time to implement it and test it.

Ultimately there was some good design forethought on the project in the way of balance and interesting decisions for the player, with some of these concepts coming out in more recent releases such as Mechwarrior Online. (with the change to leg-damage) However, without all of these systems in place, it will be truly hard to know just how well it would have worked beyond what we had on paper, and the number crunching he had done to prototype it outside of the engine.

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.

A quick project of mine: I took some very basic geometry from Blender, baked some lightmaps in pureLIGHT then brought all of that over to the UDK to see how it would all work out. The level concept consisted of a very simple maze-like level that would be able to fit two players just nice, while demonstrating that you don’t just have Lightmass at your disposal if you want pre-calculated lighting.

The maps turned out just nice and showcased what pureLIGHT was capable of, while also demonstrating just how easy it is to implement a sort of middleware like this.

Anyway, on to the level!

All the meshes of the level where very basic exports from Blender, which was one of the harder things to get going as I eventually needed to just ask the pureLIGHT guys for a proper export script as none I found did the trick. Once that was said and done, the momentum with the project grew tenfold. With everything in pureLIGHT, it was as simple as telling it to bake, as the materials from my lights had saved and pureLIGHT imports the x,y and z from all meshes so fiddling with positioning shouldn’t be required.

Once processed, pureLIGHT dumps all of the final mesh and map data into ASE and TGA files that can be easily brought into just about anything, be it a game engine like UDK or 3D software like 3ds Max. The best part is pureLIGHT does all the custom UV work, meaning once it’s imported you just drag and drop the texture/material onto the outputted mesh and you map is applied perfectly onto it.

From here on out, it was as simple as placing and scaling all of the meshes and a few dynamic lights to get the end result. I do have to give thanks to Andrew Czarnietzki, he explained to me how to disable much of the UDK’s Simple collision that was wreaking havoc on my meshes. I found out soon after, however, that there must have been something that Unreal didn’t like about my meshes, as every time a bot or I moved while on per-poly collision, we both rose and fell. In the end I was able to add a BlockingVolume to even things out, but in the future collision meshes may be the way to go, even with this very simple geometry. I’ve noted that the next time through it would likely be better to export per mesh instead of per group of mesh, just to avoid some of this strangeness.

What I did right:

- Went to the resources available to me. The script I got directly from the guys at pureLIGHT Technologies worked exactly as I wanted it too.

- Had a clear plan from the beginning and executed it.

- Doing the project at all. Had I decided to bring this into something else mid project, it likely would have stalled everything.

What I did wrong:

- Very rough meshes, making for some light bleed and extra unnecessary polys. 

- Lightmap resolution not fully optimized.

- No collision meshes.

What I will do in the future:

Outside of adding the collision and making things a bit more optimized, I plan to move on from Blender and work toward adding proper materials and details into similar levels.

From the beginning, I had actually planned for a simple concept level (yet expansive in scope, once I sat down and went through it all) that would push what I knew about the toolset, though keeping those lessons simple. Little did I know that a lot of those simple ideas were far far beyond what I would ever be able to figure out on my own. Yet, I plugged away at it endlessly until I hit points that I just could not figure out: “Why is the lighting shifting when I add this pointlight here, but not here?!”, “How come this wall is transparent from this side, but not the other?!”(Normals where a new thing to me), “Why is it giving me errors when I try to spawn a bot?!”, the list goes on.

It was around this point that I decided to scrap the whole initial plan entirely, I needed to do something I understood right out of the gate, while keeping the learning end of it as simple as possible. What turned out was the 0.1 version of the level you currently see in the YouTube video I’ve posted. To put it simply, just about everything that is in the current version was in the 0.1, with some simple changes such as no proper grass material, no “god rays”, ect.

Now, as I moved on with the level, trying to implement some changes to make things much more believable became quite the problem. I hadn’t learned how to properly plan development, and as such the stability of my level fell through the floor; whenever I tried to add a new terrain material, change some figures in the lighting or an other major change, everything would crash. After a few days of trying and trying again only to have the same issue come up, it became clear I’d have to start over again. As such, I noted the locations and set-up of every mesh and terrain and started over from scratch.

It was around this time that I came across the 3DBuzz tutorials, these things would quickly teach me concepts that I never would have figured out on my own, as well as some strong development fundamentals, such as ordering what elements should be focused on first, which led to my final version.

To wrap it up, the learning experience with this project was very similar to the RedKnight: design within your own knowledge, know when something may be out of reach or beyond your skill level. And if you want to go that extra distance, take advantage of the resources before you dive head-first into the unknown. Should you feel you are unsure of your own skills, do as I just mentioned and take advantage of the resources you can and see how your knowledge compares to what they have to offer. Having this mindset from the get-go will save you a lot of wasted time and frustration.

Summary

What I did right

• Start development with what I knew, to keep the scope in focus.
• Taking advantage of the resources available to me. I can’t stress enough how much those tutorials helped me.
• Restarting from scratch. Though I ended up having to restart one too many times, I was still able to get something out of it in a reasonable amount of time.

What I did wrong

• Not tapping into the previously mentioned resources soon enough. Look up this info as soon as it comes into question, it’ll save tonnes of time.
• Not enough pre-planning. Much of the final level design I came up with as I went and found where my limitations are as a junior developer. This may have worked here, but it sure as hell will not for any future projects.
• Distractions. Since this was my first proper project I was jumping all over the place, deciding suddenly that I wanted this material here, that mesh there, and it made a jumble out of m development cycle, slowing it down considerably.

Flash has always been a strong suite for me. Even when I first started getting into the program 5 years ago, Flash was as pick-up-and-go as it could get for me. As such, it’s no surprise that my first real planned project using Actionscript 3 would turn out a success. 

Fly Smasher is one of the projects that came from my experience over at EDAC's Interaction Design and Game Level Development. The assignment was to develop a simple story driven game that is played through only one player input and that can be developed as quickly as humanly possible. Right out of the gate I had a project document detailing out the  of the game as well as a paper prototype.

Let it be known, if you can create a paper prototype of your game prior to actual development, do it! It’s the most effective way to get your idea across visually to both other people in your team as well as possible targets of your demographic. Had it not been for the paper prototype, many of the final ideas that went into Fly Smasher wouldn’t have come to the light of day. On top of that, a prototype should only take a few minutes to and hour at the most.

Development was interesting to say the least. At the time, Actionscript 3 was still rather new to me, with only a small chunk of Red Knight being the only previous experience with the script. As such I used what I knew to come up with an Alpha version quickly, but it was the polish that took it’s time. As I attempted to move on from that version I quickly hit brick walls; I had never really used aspects like XML and Flash, nor had I used AS3 to code priority in a mouse click over other MovieClip collisions. Suffice to say, I eventually got all of that sorted and quickly jumped onto getting as much testing as possible in.

As the walls fell, and the testers’ grins grew more and more, it became apparent I was on to something. When looking for proper art assets, Albert jumped onto that faster then you can say: “You have two weeks!” He had been rather excited about the project since I first brought it up, and was the first to jump in as a tester whenever he could.

In the end this was the big success of my college career. The scope stayed intact, it remained fun and simple, the story-while basic- is enough to get players interested and the art style Albert came up with was brilliant.

Summary

What I did right

• Paper Prototype, paper prototype, paper prototype
• Get some testing in whenever possible. This was a huge step into keeping the game interesting and consistent.
• Building the fundamentals before assets became a factor. This allowed for both the concept to be proven, as well as the assets to be designed around the game, not the other way around.
• Simple concept was the right scope for an junior developer like myself.

What I did wrong

• Not enough research into XML and Flash. Relying on PHP to transfer data between the two wasn’t a very elegant solution.
• Took too long trying to bash down the “brick walls” instead of changing focus and coming back to those barriers.