9 things I learned making N.O.V.A. 02

The holiday after N.O.V.A. was over and it was time again to put back our designer hats.

We started NOVA 2 by reading all our appstore reviews and 300 pages of forum comments about it on TouchArcade. This offered a tremendous perspective.

The biggest surprise was the number of people who went straight to multiplayer, skipping the campaign. From the start, we knew we can’t make a sequel without a deeper competitive mode. We tried to improve on everything, from maximum number of players, to game modes, to adding player evolution.

Thank you, players (even you, guy who gave N.O.V.A. one star because it didn’t feature a knife).

One thing we knew our team lacked was 3D artists, but we benefited from enough experienced designers.

So, one of the important questions for us became “how to increase the gameplay time with minimal graphic assets?” The “fall into the shaft” and “half-pipe hoverbike” levels were the result of this question: 5-10 minute experiences made of repeating 3D segments. The constant acceleration and steam of obstacles distracted from the repetitivity of the graphics. This freed time for the artists to focus on all the other levels and make them shine.

Thank you Nandor Mihaly Penzes and Mihai Ilie.

The biggest challenge of the project was how to improve upon an already well received game. We tried to maintain the mindset of one-upping all the important things we could think off:

We had this enemy in NOVA that threw crates at the player: why not have now a psychic enemy that could throw jeeps? Or turn invisible? We had enemies that could run: why not have some now that could leap or fly? We had a jeep: why not pilot now a huge mech?

Thanks again, producers.

Something significant happened a few months after NOVA launched: Chair Entertainment’s Infinity Blade, the Unreal Engine smartphone game that looked amazing.

We had no other option than to switch to a new engine to match their quality. In a one year development circle, that could push the project very late.

Very quickly the question became “how do we devise all the game level design in the shortest time possible, without turning everything to crap?”

We needed a framework, a lens to focus our creative ideas. So we decided to go for a template: each level should have 2 new elements (usually one weapon and one enemy), 9 enemy encounters (5 common ones, 3 based on the new elements and 1 wow moment) and take 25 minutes.

The secret of using this formula successfully is: don’t become it’s slave. Abuse it to your liking. Want a 10 minutes level with 3 encounters only? Why not? Want one that is just a big labyrinth? Sure! Want a first person tower defense level? Bring it on!

Again, this point is not related to the 2D artists, but since they did a great job: thank you, artists.

When we started on our first features document we tried an experiment: we assigned priorities to each of them and approved them with the HQ.

This way we knew what to focus on and by the end of the project, what to cut.

The method is not without faults, however: we still had a very big push for the final game difficulty balance before release.

Thanks Paul Friciu, for stepping in and helping.

As the team was getting bigger and the project more complex, it became harder to keep everyone updated about the project status. Our studio manager discreetly suggested that we should do something about it.

It wasn’t back then the golden age of free online project management tools, so we had to improvise.

We gathered in an excel file the most important features (which were mainly the enemies, the weapons and the levels). We added for each of them some clear steps: initial design specs, prototyping, graphics, implementation and feedback. Then send weekly status updates showing which feature was at which step.

It offered the team a sense of progression, allowed everyone to pace themselves better and offered a global view, instead of the narrow confinement of everyone’s tasks.

A mistake some designers do is thinking “I’m a designer, so I’ll do designy things and leave the technical part to the programmers.” No, one must always look beyond his area of expertise.

In our project, a (relatively) technical piece of writing that influenced our development was “The AI of Bioshock 2” by Kent Hudson.

It’s an excellent presentation about how the Bioshock 2 team initially flunked the AI of the Big Sister, what they learned from it and how they got back on track. Everyone loved the piece, it’s really worth checking out.

The most helpful takeaway for us was the ability to modify every object’s animation speed in the game editor. It offered a tremendous freedom to design enemies.

Want to change the moving speed of a character? Just move a slider. Want to modify the shotgun reload time? Same. It was just a matter of the artist's providing us some temporary animations to play with, then making the polished animation, once we finished tuning.

Thanks Kent Hudson.

That was by far the most hilarious part of the project: the choreography following every storyboard sent to the animation team. I rolled, kicked and shoot dreadful amounts of time, to the delight of both animators and bystanders.

Thank you, animators.

Back when I was in college, writing for the Game Over gaming magazine I did an interview asking famous game designers what someone needs to become a good game designer. The answer that stuck with me was the one from Doug Lombardi, of the Half-Life fame. He said what you need is “the will to put away the bad work”.

Every time I was too late or too tired I would remember this saying and proceed to elevate back my quality standards.

Thank you, Doug Lombardi