[deleted]
Id Software Programming Principles
41–50 of 83 posts
Re: Id Software Programming Principles
#42> 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.
This is basically the Mythical Man Month in a few lines. You once wrote something specific, and it was great. Then you had to write a second thing, and you remember things from the first, so why not make it more general for the inevitable 3rd, 4th, 5th to come? And, then, you fail to deliver the 2nd.
I don't have my copy handy, but I believe that's actually the second system effect
Re: Id Software Programming Principles
#43> "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.
I think there's a distinction between prototypes of parts of the game and the full game. I remember Carmack building a prototype of the texturing system for Rage to see if it would all work, so maybe the prototyping was always just an implicit part of JC's programming.
I think the distinction lies in always building production ready code.
You can build things to try out and experiment different modes of play or modes of rendering but the code you write should always be production ready. No taking shortcuts because "it's just a prototype".
Re: Id Software Programming Principles
#44> "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.
Doesn't sound like a generally useful tip.
Re: Id Software Programming Principles
#45Earlier 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…
> It completely removes the fun though, if you only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product. Then maybe that programmer should go into teaching instead?
You have that backwards. People who don't enjoy these things should go in to management
Re: Id Software Programming Principles
#46He described how literally hundreds of projects were successfully completed in C, targeting multiple platforms, while being first to market with innovative technology, with a small team in a pre-Internet world,
These are achievements beyond belief.
Re: Id Software Programming Principles
#47Earlier 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…
I have seen projects drown to death in a sea of frameworks, supposedly reusable libraries and generalizations developers deemed necessary. But it was fun for some, I am sure.
No doubt that's often the case. And depending on which type of programmer you have too many of, it might be failing for that reason or the opposite (insufficient generalization).
If you ever think "we are on schedule and this codebase has just the right balance between getting things done and doing it right" then you have a well composed team.
Re: Id Software Programming Principles
#48> 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.
Generalizing is part of how you'll be smarter later though. You cannot generalize something unless you understand its essence.
It's easy to confuse abstraction (choosing to deal with one, possibly newly contrived, concept over another) and generalization (reducing the number of concepts required to explain something to a minimum). The former is like building a Haswell CPU from a description of 70s microcontroller architecture, whereas the latter is like trying to figure out what CPUs were like in the 70s by looking at a Haswell core under a microscope.
Re: Id Software Programming Principles
#49Re: Id Software Programming Principles
#50> "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!
What if you prototype a game mechanic and it's shit?