10 development commandments that led Doom dev Id Software to change the games industry

10 development commandments that led Doom dev Id Software to change the games industry
Matthew Jarvis

By Matthew Jarvis

August 16th 2016 at 1:05PM

Co-founder John Romero shares the iconic studio’s philosophy with up-and-coming creators at GDC Europe

In a GDC Europe talk recounting id Software’s early days, co-founder John Romero revealed ten core principles that led to the studio’s success creating Doom, Quake, Wolfenstein and more than 25 other games in five years with fewer than ten staff.

“Some of this will sound insane, but we were in our twenties and there were no limits,” Romero began, recalling the start-up developer’s experience making a Super Mario 3 demo for Nintendo, licensing the Commander Keen engine – a move Romero described as the beginning of the modern engine licensing business – and implementing smooth scrolling pixel-by-pixel in Dangerous Dave in Copyright Infringement – a discovery said led to “Id Software being born that moment”.

Revealing stories behind the iconic studio’s formative months and years – including wading through a river filled with snakes to make it to the office in order to code and creating Doom in homage to Dungeons & Dragons, Aliens and Evil Dead – Romero outlined ten key commandments developers should abide by in order to produce the best game they can:

  1. “No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code. We just quantified what needed to be done and went about working on it.”
  2. “It’s incredibly important that you game can always be run by your team. Bulletproof your engine by providing defaults upon load failure.”
  3. “Keep your code absolutely simple. Keep looking at your functions and figure out how you can simply further. We made everything up to Quake in plain C, not C++.”
  4. “Great tools help make great games. Spend as much time on tools as possible. I wrote a tile editor in 1991 called TEd, for ‘Tile Editor’. It was used for 33 retail games.”
  5. “We are our own best testing team and should ever allow anyone else to experience bugs or see the game crash. Don’t waste others’ time. Test thoroughly.”
  6. “As soon as you see a bug, you fix it. Do not continue on if you don’t fix your bugs, as your new code will be built on a buggy codebase and ensure an unstable foundation.”
  7. “Use a superior development platform than your target. Doom was developed on NeXTSTEP workstations, which was superior to DOS.”
  8. “Write your code for this game only – not for some future game. You’ll be writing new code later because you’re smarter, and you won’t be limiting yourself by using old code. Try new things.”
  9. “Encapsulate functionality to ensure design consistently. This minimises mistakes and saves design time.”
  10. “Try to code transparently. Tell your lead and peers exactly how you’re going to solve your current task and get feedback and advice. Do not treat code like a black box.”