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

61–70 of 83 posts

Re: Id Software Programming Principles

#61

Post by lhnz »

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…

Generalise to the simplest expression of the logic of your application. Don't generalise towards the expression of the logic of all future applications.

The article kind of already says this:

  > Keep your code absolutely simple.
  > Keep looking at your functions and figure out
  > how you simplify further.

Re: Id Software Programming Principles

#62

Post by hyperpallium »

This is first class post-hoc bullshit. They weren't making prototypes or reusing code, they sure as hell weren't composing high-sounding principles.

They just got on with it because they were talented experienced and motivated. For that reason, the rest of the talk is very inspiring - so listen to the hour-long video (half talk, half questions), and not the article which only has the post-hoc bits. https://youtu.be/E2MIpi8pIvY

Re: Id Software Programming Principles

#63

Post by coldtea »

nlyan wrote: post #45
coldtea wrote: post #21

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

People who enjoy actually building and shipping something instead of creating abstractions should go into management?

You do realize that this includes all the hackers with the original sense of the term, which are not about finely tuned abstractions and design patterns, but about creating things and hacking/kludging it out to get there faster?

Re: Id Software Programming Principles

#64

Post by 737013 »

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 thought I was the only one. Thanks for taking off a load of guilt. It's okay to enjoy this stuff. Very sage comment. Never finish because of the fun of building.

Re: Id Software Programming Principles

#65

Post by erikbye »

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"

Carmack has programmed professionally at least since 1990, he was 19 then, 20 when he founded id Software. Genius or not, he obviously has a lot of programming experience, and familiarity with a subject counts for a lot. He has worked really hard, written millions of LoC. Obviously his "genius" lies not in learning a programming language and syntax, anyone can do that. But he evidently has a knack for developing new techniques (e.g. in graphics). He has a good understanding of especially light physics and hence physical based rendering. Considering his ventures with Armadillo Aerospace it's probably safe to say he's got a good understanding of physics in general. How many game developers went from games to aerospace?

http://www.geek.com/geek-cetera/elon-musk-and-john-carmack-t...

https://techcrunch.com/2015/01/16/elon-musk-tries-to-woo-joh...

Elon Musk practically offered Carmack a job at SpaceX, tweeting "Well, if you love rockets, come work on them with me at SpaceX!"

Carmack is a very enthusiastic person, who is hard working, and genuinely passionate about everything he pursues. I have "followed" him for a good while. It's not difficult to tell he's a lot smarter than your average Joe, but he also seems quite a bit sharper than your average smart programmer. I recommend watching all his talks and interviews.

Some amusing and revealing stuff on his childhood: http://www.giantbomb.com/john-carmack/3040-4576/

"In the gaming industry, there are a lot of people that are specifically in it because they love games and they want to create things. My love for programming is a more abstract thing. I'm taking a great deal of enjoyment writing device drivers for Linux. I could also be having a good time writing a database manager or something because there are always interesting problems. There are some things that are inherently more rewarding than others. Graphics and games are probably the most generally rewarding area of programming."

On software engineering: https://www.youtube.com/watch?v=wt-iVFxgFWk

Another smart and nice guy in the business is Tim Sweeney. About the same age as Carmack, and also founded Epic the same year id Software was founded, at 21. Sweeney got his first taste of programming at 11.

"It was astonishing seeing the IBM PC. It was such a crisp machine. I'd seen a Commodore PET computer before, and it was a crappy device that never really did what you wanted, I couldn't figure it out and nobody was there to show me how to use it. I sat down at this IBM and every key you pressed made this bright, quick sound. [It had] this nice clear screen, this very powerful basic programming language. It just took me a couple of days to figure out how to use that. It was totally love at first sight. From that point on, I tried to dedicate all of the time I had free to learning to do more with computers."

He seems to share a similar passion to that of Carmack's.

Re: Id Software Programming Principles

#66

Post by patrickyeon »

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.

There's a bit at the end of Chuck Yeager's autobiography, where he takes to task the idea of test pilots being men who have "the right stuff" (specifically addressing the book by that title).

"And in the end, the one big reason why I was better than average as a pilot was because I flew more than anybody else. If there is such a thing as 'the right stuff' in piloting, then it is experience."

Re: Id Software Programming Principles

#67

Post by pandaman »

douche wrote: post #57
pandaman wrote: post #35

Earlier quoted context omitted.

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.

The existence of so many half-baked and abandoned early-access games on Steam would seem to belie this claim. It's not uncommon to see a few hundred reviews for games where the developers have ghosted without finishing.

How so? You think early access half-baked games sell? Or you think few hundred sales is a good number?

People making these games are not in the games industry because they are not professionals (they don't live off these games). Also, it's curious how people who have not even shipped a prototype game down-vote opinions from the insiders. Good reminder when reading comments on something outside of my expertise here.

Re: Id Software Programming Principles

#68

Post by Nomentatus »

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 that rewrites happened, it's just that they were called "the next game." If you were gonna rewrite, you might as well change the costumes and sets some, and sell to everyone all over again.

Re: Id Software Programming Principles

#69

Post by iabacu »

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…

"...only enjoy generalizing, optimizing, refactoring, designing, and take zero pleasure in delivering an actual usable product"

Too many projects suffer immensely because of people who don't give a shit about delivering. In that mode, anything is an excuse: we need to reactor, we need to build a better framework, we need to revisit the requirements, etc.

Then real progress gets slowed down because of some ill fitting development philosophy that some of those folks pulled out of their asses.

What you need are wise programmers that care about delivering product, wise enough to balance long term maintenability and code health with actual delivery schedule.

The keyword is "wise".

Re: Id Software Programming Principles

#70

Post by a3n »

nlyan wrote: post #48
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.

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

> Write your code for this game only - not for a future game.

The quote refers to a future product, one that is very likely unspecified at best, and more likely just something that an individual contributor dreamed up. Unless we have some sort of multi-phase contract, how do we know we'll ever build another thing like this again?

Markets change, hardware changes, experience changes. Hell, building this thing may show you that you should never build another one like it.

Generalize where sensible inside the project, sure. But as the quote says, build what you're building, not what you're not.

Post reply on HN