Skip to main content

id Software’s Programming Principles

  • by Helge Klein
  • August 16, 2016

At the recent Game Developers Conference Europe John Romero talked about the early years at id Software where they created groundbreaking games like Doom and Quake with a small team of less than 10 people. After describing how they managed to be so incredibly productive – the team created 28 games in 5.5 years – he laid down id Software’s eleven programming principles.

John Romero’s rules are all about quality and efficiency, two aspects of software development we are very keen on ourselves. Only by following some similar rules internally have we been able to make our end-user computing monitoring and analytics product uberAgent the way it is: highest-quality metrics collected by a reliable and lightweight agent. To top it off, uberAgent is easy to use and quick to install.

The Programming Principles

Without further ado here are John Romero’s programming principles. I have highlighted sections we find especially relevant.

  1. No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code.
  2. It is incredibly important that your 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 simplify further.
  4. Great tools help make great games. Spend as much time on tools as possible.
  5. We are our own best testing team and should never allow anyone else to experience bugs or see the game crash. Don’t waste others’ time. Test thoroughly before checking in your code.
  6. 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.
  7. Use a superior system than your target.
  8. 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.
  9. Encapsulate functionality to ensure design consistency. This minimizes mistakes and saves design time.
  10. Try to code transparently. Tell your lead and peers exactly how you are going to solve your current task and get feedback and advice. Do not treat game programming like each coder is a black box. The project could go off the rails and cause delays.
  11. Programming is a creative art form based in logic. Every programmer is different and will code differently. It’s the output that matters.



Your email address will not be published. Required fields are marked *