id Software's Programming Principles
Every Friday I post a video related to one of the themes of this site. This week it’s John Romero at GDC Europe talking about the the programming principles of early id Software.
n the 1990s, during a hyper-prolific period where they released 28 games in less than five years, id Software’s policy for bugs was to drop everything and fix them as soon as possible. The result was a track record of games that were technically innovative, genre defining, and of undeniably high quality.
In this 2016 talk John Romero discusses the 11 principles that contributed to that remarkable run:
- No prototypes - the code is the game so polish now and maintain quality
- Fallbacks on load failure - keep the game runnable and resilient to errors
- Simplify - remove complexity wherever you can
- Focus on tools - spend time making tools good as they help make a great game
- Don’t rely on testers - as in test your stuff yourself and don’t waste people’s time on buggy code
- Fix bugs immediately - fix bugs so they don’t cause more bugs
- Target less powerful systems - your dev computer should able to make your game fly
- Don’t write code for future projects - You’ll write better code when you need it
- Write modular code - encapsulation aids good design
- Code transparently - talk about how you’re going to solve your problem and ask for feedback
- Embrace differences in programmers - the output matters more than minor differences in coding styles