Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Id Software Programming Principles

blog.felipe.rs

Post reply on HN
Print view View original

31–40 of 83 posts

Re: Id Software Programming Principles

#31

Post by zem »

coldtea wrote: post #21
alkonaut wrote: post #7

Earlier 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?

nope, I've delivered considerable value to my team by essentially letting the people who enjoy shipping end user features do that, and extracting frameworks and libraries so that the overall product stays coherent and easy to work with, or occasionally stepping in and saying "why don't you let me build the general pieces for this feature first, and then you can use them to make your life easier". as long as you have a decent feel for yagni, it's a useful role to play.

Re: Id Software Programming Principles

#32

Post by Koshkin »

alkonaut wrote: post #7
a3n wrote: post #2

> 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…

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.

Re: Id Software Programming Principles

#33

Post by a3n »

whazor wrote: post #19
a3n wrote: post #2

> 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.

Yeah, sometimes. And other times, the whole contract gets spent on a framework that only makes sense if there's another contract, and ... well, I guess that never happens anymore.

Didn't someone say premature generalization is the root of all evil?

Re: Id Software Programming Principles

#34

Post by Koshkin »

rckclmbr wrote: post #27
joakleaf wrote: post #23

Earlier quoted context omitted.

He was developing large parts of e.g. Doom: He didn't write the BSP traversal and texture mapper (the graphics engine), but he did write monster AI, level behavior, and level editor. I think, I heard him state in an interview that he also did a lot of development on Quake in addition to the levels. Obviously the graphics engine was Abrash and Carmack's

I think Carmacks programming principle would be "be a genius"

Then mine would be "don't be an idiot." :)

Re: Id Software Programming Principles

#35

Post by pandaman »

NumberCruncher wrote: post #15
Hansi wrote: post #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.

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!

In games industry nobody ships prototypes. If you manage to put one on Steam it's not going to sell much either. And yes, writing prototypes is normal, read on "Cerny method" if you are curious.

Re: Id Software Programming Principles

#36

Post by jackmott »

rckclmbr wrote: post #27
joakleaf wrote: post #23

Earlier quoted context omitted.

He was developing large parts of e.g. Doom: He didn't write the BSP traversal and texture mapper (the graphics engine), but he did write monster AI, level behavior, and level editor. I think, I heard him state in an interview that he also did a lot of development on Quake in addition to the levels. Obviously the graphics engine was Abrash and Carmack's

I think Carmacks programming principle would be "be a genius"

No, if you learn more about him, its really more work ethic. I think he is smarter than an average person, but not smarter than the average programmer by a whole lot. Just robotic like work ethic.

Re: Id Software Programming Principles

#37

Post by buzzybee »

a3n wrote: post #2

> 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 helps to allow yourself to be philosophical about what you're writing. Sometimes a generalization just moves around the problem. Sometimes the generalization you want competes badly against cut and paste.

Increasingly I try to find a strategy that transitions towards the generalization over time by following a path of "lower friction instead of greater friction." It's easy to increase friction by adding a new configuration step, new concepts and idioms that are discordant with the rest of the environment, and then the point of doing it gets lost - you don't want to pay for that overhead most of the time, you can't ship code that way.

Re: Id Software Programming Principles

#38

Post by [deleted] »

jackmott wrote: post #36
rckclmbr wrote: post #27

Earlier quoted context omitted.

I think Carmacks programming principle would be "be a genius"

No, if you learn more about him, its really more work ethic. I think he is smarter than an average person, but not smarter than the average programmer by a whole lot. Just robotic like work ethic.

[deleted]

Re: Id Software Programming Principles

#39

Post by metaobject »

Koshkin wrote: post #32
alkonaut wrote: post #7

Earlier 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.

I've seen projects fail for a variety of reasons. A few fall under scenario you described. But, I've also seen quite a few projects succeed by making use of in-house developed libraries and frameworks. It probably more depends on who is on the team than whether or not the code is written to be generic enough to apply to other problems.

e: fixed typo

Re: Id Software Programming Principles

#40

Post by chii »

coldtea wrote: post #21
alkonaut wrote: post #7

Earlier 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?

> go into teaching instead?

if teaching earned me as much as a commercial programming job, then yes. Unfortunately, most teaching positions are fairly poorly paid (compared with the qualifications required and the opportunity cost). That's a sad fact, but one has to consider it.

Post reply on HN