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

This article is dedicated to my two project managers on the N.O.V.A. projects, Dragos Gafita and Radu Necula, who were kind enough to indulge my crazy ideas.

When we started N.O.V.A. none of us did any iPhone projects. We just finished Chuck Norris: Bring on the Pain, for Java feature phones. A steep learning curve followed.

1.    How starting from a good design philosophy can lead to a successful game

The biggest and most important part of our philosophy was: fights must be accessible. We reasoned that being too hardcore on a device that "just works" wouldn't do well.

We looked around on what consoles did to adapt shooters, we added our own mechanics, but were still unsatisfied.

We solved most of our problems setting our sights on the origins of the genre. In the first two games N.O.V.A. games, 90% of the enemies shoot traveling time, not instant damage, projectiles. The strafing speed is big enough for the player to evade them. Each enemy has a very clear rhythm, making it clear when it's safe to emerge from cover.

Thank you, John Romero.

2.    How to make a compelling demo using a corridor, two character models, few asteroids and one text

The enemy behavior code was progressing very slowly and it was time to send our first game demo. So I chose to concentrate into making the most atmospheric 3 minutes I could muster, using the elements above. The two models were a huge ass demon and a space marine.

I spent two days until everything was perfectly coordinated: the asteroids would move outside the window exactly when you would naturally look in their direction. The lights would blink unsettlingly. The marine would look like he's been through the most gruesome fight. And just when the player would get to the last corner of the corridor, he would see the enemy turn towards him, then fade to black with the text "fight me next week!".

HQ was thrilled about the suspense, I was thrilled to buy one extra week of work on the enemy behavior, everyone was happy.

Thank you, HQ.

3.    How to survive your programmers while pushing the envelope on the technical side

Our favorite designer saying was "if your lead dev doesn't want to chase you around the studio with a fireman axe, you didn't propose enough technical improvements".

Fortunately, this time we didn't have to survive anything: our lead programmer was one of the most reasonable persons possible. We learned from him as much about technology as about listening.

The takeaway is, you always need a number of big technical achievements in mind when starting a project. Our rule of the thumb was to come up with 10, discuss them with the programmers, agree on 5. Worked great for N.O.V.A..

Thank you, Andi Matei.

4.    How you need to check EVERYTHING in that genre

Some creators have the notion that seeing other's people work would make them less original.

We choose the opposite approach. We reasoned, seeing and understanding everything related to our work would keep us from reinventing the wheel and allow time to put our own spin on it.

It was a good decision: even after acknowledging our influences, the reviewers gave some very kind reviews and so did the users.

Thank you, Alan Moore, for this insight.

5.    How to learn from everyone and wear most designer hats

Talking with everyone in the team about their work was crucial help: understanding each step of their work, the limitations, the advantages. This worked not only for the team: discussing with the programmers from other teams proved useful as well: "How did you improve the FPS in your project?" "We put all the textures in a big atlas." "Really? Sounds great!"

In a team of only 3 designers (a 4th one joined us later for multiplayer), we needed to work on... well... everything: from core and systems design, parameter tuning, A.I., level design, tool design, sound design, font editing, to scripting and story.

Thank you Marius Petculescu, Radu Manole.

6.    How Steve Jobs appreciating your project instantly adds 4 extra months to the deadline

When we started, the project was supposed to finish in 8 months. It was tight, but we decided to go for the best possible FPS that could be done in that time.

We settled for a corridor shooter and invested in a very independent enemy A.I., one that could generate interesting gameplay without any additional scripts needed.

One good day we got told Apple would like to feature a demo of our game in the iPhone 3GS launch conference.

Suddenly there was talk of launching the game for Christmas. Suddenly we could have outside levels and unique situations in every game mission. It was bliss.

Thank you, Steve Jobs.

7.    How to use setbacks to the project's advantage

After the iPhone 3GS presentation our project suddenly became triple-A. The GFX suffered a big overhaul, to fit with the quality level of its newfound status. Changes of this magnitude are usually messy things, but we chose to use the extra time to redo the level design of ALL levels and the game was better for it.

Thank you local review team for being patient with us.

8.    How to play with the player's expectations

In terms of graphics we were bound by what was asked of us, but in terms of design we strived to surprise the player.

See that big fellow with two hammers? He can throw them at you, then grab you by the neck and punch you into oblivion. The ranged guy can throw explosive crates, the small guy runs away to get you into an ambush and so on.

Through enemies and level design we tried to be less generic and more unexpected.

This point is not about 2D artists in any way, but I would be an ass not to thank them, after the great job they did. So, thanks Catalin Raibuh and Alexandru Negoita.

9. How it can never be too late to improve the tools

Wherever behind the schedule a lot of teams look into cutting features. We prefered to look into whichever were the most time consuming tasks. The winning one was making new waves of enemies to appear after the player cleared a room.

Our editor was very modular, so we created a "spawn manager", that made it very easy to choose which enemy would spawn from where and after what time.

In the end, tools and the tool programmers will always save you.

Thank you, Mihai Sebea.