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

21–30 of 83 posts

Re: Id Software Programming Principles

#21

Post by coldtea »

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…

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

Re: Id Software Programming Principles

#23

Post by joakleaf »

eps wrote: post #11

I'd very curious to hear Carmack's take on this. After all Romero was making game levels, not the engines.

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

Re: Id Software Programming Principles

#24

Post by eigenbom »

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.

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.

Re: Id Software Programming Principles

#25

Post by msangi »

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.

That's indeed a very good advice.

All abstractions have a cost and no abstraction is better than the wrong abstraction.

I found this talk on the topic very interesting https://youtu.be/4anAwXYqLG8

Re: Id Software Programming Principles

#26

Post by msangi »

irfansharif wrote: post #6
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.

> "Write code that is easy to delete, not easy to extend."

Absolutely! https://vimeo.com/108441214

Re: Id Software Programming Principles

#27

Post by rckclmbr »

joakleaf wrote: post #23
eps wrote: post #11

I'd very curious to hear Carmack's take on this. After all Romero was making game levels, not the engines.

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"

Re: Id Software Programming Principles

#28

Post by contingencies »

kensai wrote: post #5

> Programming is a creative art form based in logic. Every programmer is different and will code differently. It’s the output that matters. This one is also nice, especially for mid to large software houses. As long as a common denominator is respected, I guess.

It's enabled by encapsulation.

Re: Id Software Programming Principles

#29

Post by mattkrause »

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!

Protoduction!
Post reply on HN