(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.

I've been adding a little bit more to this project bit by bit and wanted to show what's happened with it since. I'm going to be focusing on creating more puzzle elements both in a way to keep production simple and try to have the command system have a bit of an auto-aim to make hitting objectives feel more satisfying instead of busywork.

I built a little prototype last night in a couple hours. Here's the results.

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.

Within design as a whole, the act of prototyping is a common practice; in architectural design there is AutoCAD and blueprints, web design has mockups, artists sketch. It’s a universal language that is used for very good reason, so it’s no surprise that we’d see this as a common practice in many aspects of game development, but it’s a simple step that is forgotten about by even some experienced developers.

This idea of paper prototyping may not be exactly what you think it is. Generally you won’t be making origami versions of mario to jump around your platformer in mind. It’s creating the most basic form of your game concept and making it playable as quickly as possible. It does not need to be elegant, your main character may just be a square, it won’t matter. What does matter is getting your idea out in a way that someone, including yourself, can play the thing outside your head.

Now, why is it important to get this out? Well, when you think of a game concept, at one point or another you’ll have to make some important decisions, like how high does this character jump, how many enemies will be here, should the player be able to go both left and right? These are all things you could arbitrarily chose, but if you do, are you really making a decision? Is your game better? The truth is almost always no. Where these decisions are truly made is from seeing the game being played and hearing feedback from players. Be prepared to have an idea chewed out and ripped limb from limb, but remember that the process of making a game is not one voice, you need this if you want to be able to make the right decisions for the game that all of these players and you are trying to make.

While not everyone needs this step, some can develop levels and other aspects perfectly fine through entirely digital means, what paper prototyping can do is speed up a process that is key to making a truly fun game: fail faster. Fail faster is important for reasons that we mentioned in the previous paragraph: every criticism is a move forward that you cannot do on your own. This act of fail faster moves beyond this idea of paper prototyping; you’ll need to constantly hear feedback and have people play your game as often as you can from that point forward. From what you receive and figure will make things more fun, iterate on your prototype, make those decisions, and even above that, ask questions, would it be more fun for items to spawn around the player as time goes on, instead of hard setting them? Does the player stay in the air too long? Some of these questions might not get answered until you build digital versions, but being aware of these options are important to not get tunnel vision.

Anyway, with the amount being done on my other project this week, it’s been on my mind quite a bit. On good news, once I get enough tested I’ll be throwing more details on the project on here as soon as I can.