It all started for Avalanche Studios during the later phase of the Just Cause 2 beta. The bug reports were still pouring in from the QA departments. This was no time for cool ideas and awesome features. In fact, the very purpose of "beta" as a development phase is to have a team of enthusiastic and creative wizards mutate into a disciplined regiment of bug-fixing soldiers.
The job is no longer about feeding the dream of what the game could be -- it is about coming to terms with what the game is not. Beta is a necessary battle that every game developer must go through - for without beta, a game will behave strangely, crash, and be generally unplayable.
In the midst of this battle, I was working on a particularly annoying bug -- when suddenly, I was called into a meeting... "Hey guys! How would you feel about getting started on a new project? Sega is interested in seeing a concept pitch for an XBLA/PSN/STEAM game with an original IP, using our engine. What do you say?"
Our answer was somewhere along the lines of "OMG! Rock 'n roll!" or similar. We were thrilled.
The first thing we did before getting to work on a concept for the game was to sit down and have a look at what games were currently out on Xbox Live Arcade and the PlayStation Network.
This was around the time when Chair Entertainment released Shadow Complex. We fell in love with it. The developers had done a fantastic job of delivering a modern take on Nintendo's classic Metroid games for the NES and SNES consoles, redone with Epic's Unreal Engine.
The IP was new, and a lot of the mechanics had been updated and deepened to fit the expectations of today's gamer audience -- but the core philosophies and concepts that made Metroid so awesome back in the '80s were kept perfectly intact. The sense of nostalgia it created in us had us sold.
We wanted to base our game on the same idea -- bringing a concept from the "golden era of gaming" into 2011 with a modern spin on it.
We had many discussions about what games we would take our inspiration from. The project would be very small in scale compared to big AAA-budget games, so we needed to choose a source of inspiration that played to Avalanche Studios' strengths and experience: over-the-top action, big destruction, vehicular mayhem, and a tongue-in-cheek-mega-macho attitude.
After we had this down, it didn't take long to agree upon our main sources of inspiration: Jackal (NES 1988), Desert Strike (Genesis/Mega Drive 1992), and the old Saturday morning GI Joe cartoons fit the bill perfectly. This provided a clear framework to work within and helped unify the team's vision for the game from a very early stage.
The primary goals that had been set prior to the projects start were fairly straightforward, though they would certainly prove to be a challenge to deliver on.
Reading through the reviews for Renegade Ops, it seems we succeeded with the first goal. Tom Chick writes the following in 1UP's review of the game: "...it [Renegade Ops] manages to capture all the over-the-top action-movie glee of Just Cause 2. But it does it within the confines of a top-down twin-stick shooter..."
The second goal was also accomplished. Multiplayer exists in the Avalanche Engine now, and I can't wait to share where that door is leading us in future projects. Unfortunately, if I shared that information with you today, I wouldn't be able to share anything in the future.
In regards to the third goal, Renegade Ops ended up with a Metacritic of 81. I am happy with the score, and feel it is a fair number to land on when I attempt to look at the game objectively. However, since the goal was set at 85, this is clearly something we failed to deliver on.
This is all well and good on the surface, but let's dig a little deeper into the juicy bits and bobs of what it was like developing Renegade Ops. What was awesome? What sucked? What manner of life did we lead in the midst of milestone deliveries and beta submissions? Read on!
Every project is an opportunity for evolution of both the process and the individuals involved. This post mortem is an attempt to capitalize on that opportunity and share it with others. I hope this section will provide something interesting or useful to that end. Let us begin with the major aspects of our approach that we feel proved successful.
1. Build-Centric Development
The primary goal for Renegade Ops was that it had to be a fun game to play. It became our highest priority and we discussed "fun" a lot in the team. We wanted to find an approach that naturally let "fun" be the main factor of all decisions. The most reliable tool a developer has to accomplish this is to play the game lots during development, and to openly discuss any issues or gaps that hamper the "fun".
The term we used internally for our approach was "Build-centric development with focus on core mechanics". First of all, this means that we must always have a working build of the game available. As soon as there were any crashes or similar issues that made it impossible to play the game, the team dropped everything and fixed it.
We also let the latest version of the game be the deciding factor on what we were going to work on next. Instead of relying primarily on documentation for that purpose, as is the classic practice. We played the game and basically said things like: "Okay! The driving and shooting feels great now! I'm sick of shooting jeeps, though. We need to get a bigger more interesting enemy in there and see if we can make the combat more exciting and varied!"
Then we looked at our high-level design document, which had a list of potential enemy types and said: "A tank! Big and scary! Perfect! Let's get started on it next week!"
Now, don't get me wrong -- we did have an overarching plan for the project with defined milestones and commitments toward the publisher, but we made sure they were formulated in a way that gave us as much room as Sega was comfortable with, to allow us to follow our instincts (thanks go to Sega!) The milestone definition could, for example, read "Implement two enemy types", but it didn't specify which enemies out of the ones listed in our high-level design doc we would end up delivering.