6 ms·

Programming principles from the early days of id Software

129 points by Impossible 10y ago

sitkack 10y ago
Maintain flow at all costs.
aphextron 10y ago
To anyone that hasn't checked out the source code for Doom 3, it's some seriously beautiful C++. https://github.com/id-Software/DOOM-3-BFG https://github.com/id-Software/DOOM-3-BFG
- aidos 10y ago
  I was just looking at where the cheats are tracked and I suddenly thought, what did IDDQD and IDKFA stand for? https://github.com/id-Software/DOOM-3-BFG/blob/master/doomclassic/doom/d_player.h https://github.com/id-Software/DOOM-3-BFG/blob/master/doomcl...
  - feklar 10y ago
    ID-Kick-Fucking-Ass, ID-Delta-Quit-Delta was a made up frat of college dropouts
  - mrslave 10y ago
    Keys Firearms Armor, IIRC. Sometimes reported as Keys & Full Ammo, but this neglects all firearms granted to the user.
  - mayoff 10y ago
    Dave Taylor (ddt) and I and another friend had some Q's on our college transcripts (from dropping classes after the tuition refund deadline). We joked that we should have a fraternity for losers like us. We called it delta q delta. Dave named the iddqd cheat after that joke. This is also why my vanity domain name is dqd.com. Dave did end up graduating, but I and the other friend didn't.
danso 10y ago
There's a subhed that refers to tooling: > Great tools help make great games. Spend as much time on tools as possible. But the text under it is more related to testing of code and bug-squashing. Anyone have any links/references to id's process and prioritization of building tools?
- vvanders 10y ago
  Tools drive everything in games. Your normal AAA team structure is something along the lines of 1:10 dev:art/design. Every improvement you make in tools has a 10x factor in the people using it. Additionally everything about game development is about iteration. No one really knows what's fun(it's kinda one of those things where "I know what it is when I see it"). So the core of gamedev is iterating and trying as many crazy ideas as you can until something sticks. The right tools that enable that rapid iteration are critical. The faster you can make changes the more shots you get at capturing that lightning in the bottle(which is why 10% of games make 90% of the revenue).
  - danso 10y ago
    I don't doubt that. I am particularly interested in how that mentality compares to the priorities of devs in other fields. For example, web development. I'm thinking that games development might be substantially more bespoke than webdev, necessitating the need to spend time on developing bespoke tooling?
    - vvanders 10y ago
      There's really just 10-50x more "content" involved in gamedev then say web development. You might have 3-4 designers on a front end where a 60M budget game will have 6-8 animators alone, not even considering environment art, character art, level design, gameplay mechanic designers, etc. Now if you get into indie things are slightly different there but you still see just about everyone using an off-the-shelf engine because no one has the time to invest the man-years needed for proper tooling.
      - 10y ago
deleted 10y ago
[deleted]
travisty 10y ago
John Romero is totally irrelevant, why does anyone pay attention to him. Here we are so many years later and all he's got going for him is talking about "the good ole days" at Id. Seriously, look it up, that's all he does. Id Software was John Carmack. Had it not been for Carmack no one would even know who Romero is. It's actually surprising that Romero worked with Carmack for so many years and doesn't seemed to have even learned anything from it. What's Romero doing now? Making flash games for Windows phones?
headShrinker 10y ago
> 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. This alone is worth the read for me. I wish I could shadow this team.
- favorited 10y ago
  I'd recommend checking out this post[1] by Wil Shipley (a longtime Cocoa dev), which includes a story about how Carmack doesn't re-use code. The whole blog post is a fun read. [1] http://blog.wilshipley.com/2013/12/my-doom-20th-anniversary-stories.html http://blog.wilshipley.com/2013/12/my-doom-20th-anniversary-...
  - asimuvPR 10y ago
    Great link. Thanks for sharing.
- adrianratnapala 10y ago
  Bear in mind the next thing the article says is >(And of course there was no Unity or Unreal Engine to license.) But advice like "don't reuse" and "use an external framework", actually have a common root because the difficult thing in programming is not banging out code, not even when you have your QA in place. The really hard thing is getting knowledge: figuring out the right thing to do and how to do it. Once you have figured it out in one app, you can do it again only better in the next app you write. You are re-using knowledge that is stored in your head. But when someone writes an engine, they are also storing knowledge, but now inside code. Again, knowledge is being re-used.
zackmorris 10y ago
Choose the right platform for your goals. While id was banging out bare-metal code on a relatively unchanging PC platform, my old partner and I spent our time battling API deprecation, a change of processor, endianness issues, performance issues, just on and on and on, a whole litany of insults on the Macintosh platform. We were attempting to "just have a successful shareware game business on the Macintosh" but after 20 years of this self-flagellation I bailed. We each now work at rather successful studio/agency development firms and I've probably contributed to more meaningful projects in the last year and a half than in all the years previously. When you choose the wrong platform, you will not only be running against the wind, but when the wind dies down you will be so tired that you miss the new opportunities. We should have been positioned to capitalize on the iOS store back in the mid-2000s with our substantial codebase, but due to burnout I witnessed others openly rake in $100,000 paydays on projects similar to our own that they only spent a couple of months making. That could have been us, but I can't blame the competition or Apple because in hindsight it was my own sheer inability to stop beating a dead horse that put me in the universe that didn't work out. Really you should always be working in a sustainable way that's not too easy and not too hard so that you can see the forest for the trees, and after a while those small successes often accumulate into something unbelievable.
- lawpoop 10y ago
  How does one choose the right platform ahead of time? It seems that that would be something you could only judge in hindsight. For instance, did you know that, over the course of your endeavour, that the powers that be were going to deal you a bunch of API deprecation? Did Id Software know that their respective platform providers, or the market in general, were going to keep their platform a relatively stable development target? I am thinking about developing a game in my spare time. I don't have any grand plans with it. I thought to develop it on Android (though I hear that's a mess, getting apps to run on various phones and OSes), but I want to try to keep open the possibility that it could be ported to other platforms (iOS, console, etc) relatively painlessly. Being a web developer, how could I glean enough information in areas I'm really unfamiliar with to judge which is the right platform? If I decide on Android, for whatever reason, and I become un-enamored with all of its warts, how do I know that the grass truly is greener on the other side?
CyberDildonics 10y ago
Was hoping for Carmack, ended up with Romero.
adrianratnapala 10y ago
I'd say all of these principles are still correct today, and apply outside of games, though perhaps only after appying an interpretive filter. Take: > No prototypes – always maintain constantly shippable code. Polish as you go. Romero then says that nowadays you will need prototypes. I'll believe him: but I think the right way to prototype is to reduce scope, not quality. So even the prototype is in some internal sense "constantly shippable" -- even if you are just shipping to the non-programmers within the company. The alternative is to have a fragile prototype that gets kept because it seems almost ready and just needs a few bugs fixed and some small features added. Two years and 500kloc later, you are still adding bugs faster than you can fix them.
rpdillon 10y ago
Maybe the most interesting part for me was the very last couple of sentences. > 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.

129 points by Impossible 10y ago

Maintain flow at all costs.

To anyone that hasn't checked out the source code for Doom 3, it's some seriously beautiful C++. https://github.com/id-Software/DOOM-3-BFG https://github.com/id-Software/DOOM-3-BFG

aidos 10y ago
I was just looking at where the cheats are tracked and I suddenly thought, what did IDDQD and IDKFA stand for? https://github.com/id-Software/DOOM-3-BFG/blob/master/doomclassic/doom/d_player.h https://github.com/id-Software/DOOM-3-BFG/blob/master/doomcl...
- feklar 10y ago
  ID-Kick-Fucking-Ass, ID-Delta-Quit-Delta was a made up frat of college dropouts
- mrslave 10y ago
  Keys Firearms Armor, IIRC. Sometimes reported as Keys & Full Ammo, but this neglects all firearms granted to the user.
- mayoff 10y ago
  Dave Taylor (ddt) and I and another friend had some Q's on our college transcripts (from dropping classes after the tuition refund deadline). We joked that we should have a fraternity for losers like us. We called it delta q delta. Dave named the iddqd cheat after that joke. This is also why my vanity domain name is dqd.com. Dave did end up graduating, but I and the other friend didn't.

danso 10y ago

There's a subhed that refers to tooling: > Great tools help make great games. Spend as much time on tools as possible. But the text under it is more related to testing of code and bug-squashing. Anyone have any links/references to id's process and prioritization of building tools?

vvanders 10y ago
Tools drive everything in games. Your normal AAA team structure is something along the lines of 1:10 dev:art/design. Every improvement you make in tools has a 10x factor in the people using it. Additionally everything about game development is about iteration. No one really knows what's fun(it's kinda one of those things where "I know what it is when I see it"). So the core of gamedev is iterating and trying as many crazy ideas as you can until something sticks. The right tools that enable that rapid iteration are critical. The faster you can make changes the more shots you get at capturing that lightning in the bottle(which is why 10% of games make 90% of the revenue).
- danso 10y ago
  I don't doubt that. I am particularly interested in how that mentality compares to the priorities of devs in other fields. For example, web development. I'm thinking that games development might be substantially more bespoke than webdev, necessitating the need to spend time on developing bespoke tooling?
  - vvanders 10y ago
    There's really just 10-50x more "content" involved in gamedev then say web development. You might have 3-4 designers on a front end where a 60M budget game will have 6-8 animators alone, not even considering environment art, character art, level design, gameplay mechanic designers, etc. Now if you get into indie things are slightly different there but you still see just about everyone using an off-the-shelf engine because no one has the time to invest the man-years needed for proper tooling.
    - 10y ago

deleted 10y ago

[deleted]

travisty 10y ago

John Romero is totally irrelevant, why does anyone pay attention to him. Here we are so many years later and all he's got going for him is talking about "the good ole days" at Id. Seriously, look it up, that's all he does. Id Software was John Carmack. Had it not been for Carmack no one would even know who Romero is. It's actually surprising that Romero worked with Carmack for so many years and doesn't seemed to have even learned anything from it. What's Romero doing now? Making flash games for Windows phones?

headShrinker 10y ago

> 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. This alone is worth the read for me. I wish I could shadow this team.

favorited 10y ago
I'd recommend checking out this post[1] by Wil Shipley (a longtime Cocoa dev), which includes a story about how Carmack doesn't re-use code. The whole blog post is a fun read. [1] http://blog.wilshipley.com/2013/12/my-doom-20th-anniversary-stories.html http://blog.wilshipley.com/2013/12/my-doom-20th-anniversary-...
- asimuvPR 10y ago
  Great link. Thanks for sharing.
adrianratnapala 10y ago
Bear in mind the next thing the article says is >(And of course there was no Unity or Unreal Engine to license.) But advice like "don't reuse" and "use an external framework", actually have a common root because the difficult thing in programming is not banging out code, not even when you have your QA in place. The really hard thing is getting knowledge: figuring out the right thing to do and how to do it. Once you have figured it out in one app, you can do it again only better in the next app you write. You are re-using knowledge that is stored in your head. But when someone writes an engine, they are also storing knowledge, but now inside code. Again, knowledge is being re-used.

zackmorris 10y ago

Choose the right platform for your goals. While id was banging out bare-metal code on a relatively unchanging PC platform, my old partner and I spent our time battling API deprecation, a change of processor, endianness issues, performance issues, just on and on and on, a whole litany of insults on the Macintosh platform. We were attempting to "just have a successful shareware game business on the Macintosh" but after 20 years of this self-flagellation I bailed. We each now work at rather successful studio/agency development firms and I've probably contributed to more meaningful projects in the last year and a half than in all the years previously. When you choose the wrong platform, you will not only be running against the wind, but when the wind dies down you will be so tired that you miss the new opportunities. We should have been positioned to capitalize on the iOS store back in the mid-2000s with our substantial codebase, but due to burnout I witnessed others openly rake in $100,000 paydays on projects similar to our own that they only spent a couple of months making. That could have been us, but I can't blame the competition or Apple because in hindsight it was my own sheer inability to stop beating a dead horse that put me in the universe that didn't work out. Really you should always be working in a sustainable way that's not too easy and not too hard so that you can see the forest for the trees, and after a while those small successes often accumulate into something unbelievable.

lawpoop 10y ago
How does one choose the right platform ahead of time? It seems that that would be something you could only judge in hindsight. For instance, did you know that, over the course of your endeavour, that the powers that be were going to deal you a bunch of API deprecation? Did Id Software know that their respective platform providers, or the market in general, were going to keep their platform a relatively stable development target? I am thinking about developing a game in my spare time. I don't have any grand plans with it. I thought to develop it on Android (though I hear that's a mess, getting apps to run on various phones and OSes), but I want to try to keep open the possibility that it could be ported to other platforms (iOS, console, etc) relatively painlessly. Being a web developer, how could I glean enough information in areas I'm really unfamiliar with to judge which is the right platform? If I decide on Android, for whatever reason, and I become un-enamored with all of its warts, how do I know that the grass truly is greener on the other side?

CyberDildonics 10y ago

Was hoping for Carmack, ended up with Romero.

adrianratnapala 10y ago

I'd say all of these principles are still correct today, and apply outside of games, though perhaps only after appying an interpretive filter. Take: > No prototypes – always maintain constantly shippable code. Polish as you go. Romero then says that nowadays you will need prototypes. I'll believe him: but I think the right way to prototype is to reduce scope, not quality. So even the prototype is in some internal sense "constantly shippable" -- even if you are just shipping to the non-programmers within the company. The alternative is to have a fragile prototype that gets kept because it seems almost ready and just needs a few bugs fixed and some small features added. Two years and 500kloc later, you are still adding bugs faster than you can fix them.

rpdillon 10y ago

Maybe the most interesting part for me was the very last couple of sentences. > 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.