Programming principles from the early days of id Software

When it comes to game developers, id co-founder John Romero is among the most influential. At GDC Europe in Cologne, Germany today, Romero ran down some of the key programming principles that the Doom studio adhered to in the 1990s.

But be warned: Romero said some of these principles sound insane by today’s standards. These guidelines are products of their time, but in the 90s, they worked for id. The studio was able to crank out 28 games in five-and-a-half years with less than 10 developers, producing such seminal titles as Commander Keen, Doom, Quake, and others.

No prototypes – always maintain constantly shippable code. Polish as you go.

Today, the common advice is to prototype, prototype, prototype. Get something playable, and find the fun. But for id, Romero said the company had no time to prototype. The games the studio made were small in scope and easy to visualize in the team’s minds, so they went from idea straight to product. “Nowadays with any big project, you’re going to need prototyping,” he said.

A game called Quake: The Fight for Justice was the only game that the team threw out, Romero said. They worked on it for two weeks (it was an RPG) before deciding to toss it out and move on. They wouldn’t return to the Quake universe until four years later.

It’s incredibly important that your game can always be run by your team. Bulletproof your engine by providing defaults upon load failure.

Romero repeatedly stressed the importance of finding ways to increase efficiency, including making sure the game can be run by your team.

Keep your code absolutely simple. Keep looking at your functions and figure out how you can simplify further.

Again, simplification is important. Not just in code but in game design and production processes.

Great tools help make great games. Spend as much time on tools as possible.

“We are our own best testing team, and we should never allow anyone else to experience bugs or see the game crash,” Romero said. “Don’t waste others’ time. Test thoroughly before checking in your code.”

He added, “As soon as you see a bug, you fix it. Do not continue on. If you don’t fix your bugs your new code will be built on a buggy codebase and ensure an unstable foundation.”

Use a superior development system than your target to develop your game.

Though Doom’s target was MS-DOS, Romero said Doom was developed under the more advanced NextStep operating system, which was the predecessor to OS X.

Write your code for this game only, not for a future game. You’re going to be writing new code later because you’ll be smarter.

Reusing code from game to game didn’t make sense for a team that was all about optimization for the situation at hand. (And of course there was no Unity or Unreal Engine to license.)

Encapsulate functionality to ensure design consistency. This minimizes mistakes and saves design time.

When you do this, you’ll have more efficient code and more flexibility with design choices and changes.

Try to code transparently. Tell your lead and peers exactly how you are going to solve your current task.

In id’s early days it was just four guys – Romero, John Carmack, Tom Hall, and Adrian Carmack – in one room coding and listening to heavy metal. Everyone knew what the other was doing, and that benefited id back then.

Programming is a creative art form based in logic. Every programmer is different.

Self-explanatory! (And still applicable for today.) During a Q&A session, a budding game developer asked if Romero ever got burned out due to the furious pace of game development. Romero explained the kind of programmer he is -- he just loves programming so much that he never got burnt out. And another thing to keep in mind: There was a lot of work that came before id's most famous game, Doom. Wolfenstein was his 87th game; Doom was around his 90th, he said.