I'd very curious to hear Carmack's take on this. After all Romero was making game levels, not the engines.
Id Software Programming Principles
11–20 of 83 posts
Re: Id Software Programming Principles
#12> "No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code."
I disagree with this so much, prototypes and proof of concepts teach you so much but usually they are crap you will always write it better a second time. Throw away the prototype and re-write it as a much better implementation.
Re: Id Software Programming Principles
#13> "No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code." I disagree with this so much, prototypes and proof of concepts teach you so much but usually they are crap you will always write it better a second time. Throw away the prototype and re-write it as a much better implementation.
He addresses this during QA (@28:00).
Re: Id Software Programming Principles
#14> "No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code." I disagree with this so much, prototypes and proof of concepts teach you so much but usually they are crap you will always write it better a second time. Throw away the prototype and re-write it as a much better implementation.
> If you plan to throw one away, you will end up throwing away two.
Re: Id Software Programming Principles
#15> "No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code." I disagree with this so much, prototypes and proof of concepts teach you so much but usually they are crap you will always write it better a second time. Throw away the prototype and re-write it as a much better implementation.
For every prototype / POC thrown away there are 9 other prototypes ending up in production or getting sold as business software. If you feel the urge to write a prototype to learn something new please do not show it to your manager/sales rep!
Re: Id Software Programming Principles
#16> "No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code." I disagree with this so much, prototypes and proof of concepts teach you so much but usually they are crap you will always write it better a second time. Throw away the prototype and re-write it as a much better implementation.
They were four people shipping multiple games a year. They couldn't afford to prototype or build proofs of concept. They had to ship.
Re: Id Software Programming Principles
#17> 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 really stood out for me. I'm always tempted, while writing something specific, to generalize it. I try to resist that, when I recognize it. Writing a ThingThatImWritingFramework risks ThingThatImWriting never seeing the light of day, or never being used.
It completely removes the fun though, if you only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product. If the product is Doom this shouldn't be a problem - but for most of us the product is form validation or calculations involving plywood. Making frameworks and generalization is the only reason I manage to keep doing what I do. (I'm exaggerating somew…
>> Making frameworks and generalization is the only reason I manage to keep doing what I do.
This could be written on the tombstone of JS.
Re: Id Software Programming Principles
#18Earlier quoted context omitted.
It completely removes the fun though, if you only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product. If the product is Doom this shouldn't be a problem - but for most of us the product is form validation or calculations involving plywood. Making frameworks and generalization is the only reason I manage to keep doing what I do. (I'm exaggerating somew…
>> Making frameworks and generalization is the only reason I manage to keep doing what I do. This could be written on the tombstone of JS.
I hate writing boilerplate and I'd rather have pineapples shoved up my behind than write code of the kind that should be in the freaking standard library.
But yeah
Re: Id Software Programming Principles
#19> 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 really stood out for me. I'm always tempted, while writing something specific, to generalize it. I try to resist that, when I recognize it. Writing a ThingThatImWritingFramework risks ThingThatImWriting never seeing the light of day, or never being used.
Their tools are also a form of generalization. Furthermore, it is definitely possible to create value by generalization.
Re: Id Software Programming Principles
#20> 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 really stood out for me. I'm always tempted, while writing something specific, to generalize it. I try to resist that, when I recognize it. Writing a ThingThatImWritingFramework risks ThingThatImWriting never seeing the light of day, or never being used.
It completely removes the fun though, if you only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product. If the product is Doom this shouldn't be a problem - but for most of us the product is form validation or calculations involving plywood. Making frameworks and generalization is the only reason I manage to keep doing what I do. (I'm exaggerating somew…
[deleted]