id Software co-founder John Romero tells the early story of the game company in this GDC 2016 talk and lists the programming principles that guided them towards the rapid development of many games including Doom and Quake with a very small team.
Some of these principles resembles today’s common Agile practices while others do not. I like them and id definitely had good results, so the principles should at least be considered and adapted to different contexts.
No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code.
Continuous delivery and integration?
It’s incredibly important that your game can always be run by your team. Bulletproof your engine by providing defaults upon load failure.…
id Software co-founder John Romero tells the early story of the game company in this GDC 2016 talk and lists the programming principles that guided them towards the rapid development of many games including Doom and Quake with a very small team.
Some of these principles resembles today’s common Agile practices while others do not. I like them and id definitely had good results, so the principles should at least be considered and adapted to different contexts.
No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code.
Continuous delivery and integration?
It’s incredibly important that your game can always be run by your team. Bulletproof your engine by providing defaults upon load failure.
Don’t break the build.
Keep your code absolutely simple. Keep looking at your functions and figure out how you simplify further.
Spend time simplifying code.
Great tools help make great games. Spend as much time on tools as possible.
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.
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.
This was very true in the 90s when consumer computers could be so much slower than high-end ones.
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.
Don’t write so many libraries.
Encapsulate functionality to ensure design consistency. This minimizes mistakes and saves design time.
Less moving parts.
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 cause delays.
Communicate.
Programming is a creative art form based in logic. Every programmer is different and will code differently. It’s the output that matters.
Respect differences and focus on the results.
