
Id Software Programming Principles - philix001
http://blog.felipe.rs/2017/02/25/id-software-programming-principles/
======
a3n
> 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.

~~~
alkonaut
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 somewhat, but I think this is a clear
distinction between two kinds of programmers those who love the code; and the
craft, and those who like making products. Have too many of one kind and
you'll ship a mess. Too many of the other and you'll never ship)

~~~
coldtea
> _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?

~~~
nlyan
You have that backwards. People who don't enjoy these things should go in to
_management_

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

------
lubujackson
It reads like a "get shit done" manifesto, and good rules of thumb for most
programmers tasked with doing just that. Worth remembering that iD had some of
the most advanced 3D and networking code for years and really pushed the
envelope and the industry forward in many ways (first huge shareware company,
first big company to allow mods, first big company to make code open source,
etc.)

It is easy to slide into an OCD mindset when programming, to make things tidy
and proper. It feels dirty to make stuff just work, to make stuff disposable,
but evolution operates a lot like this - many little, reversible mistakes that
add up to big improvements quicker than any other method.

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

~~~
contingencies
It's enabled by encapsulation.

------
tluyben2
Some of these things, like focusing on the task at hand and trying to be as
simple as possible, not thinking too much about the potential futures is
important to me. If all would do that maybe there would not be 1000s of weird
half baked npms and such.

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

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

~~~
joakleaf
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

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

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

~~~
patrickyeon
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."

------
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](https://youtu.be/E2MIpi8pIvY)

~~~
dualogy
> they were talented experienced and motivated

Agreed and that's the whole secret sauce right there, combined with: no
distractions (social media or indeed even "coding forums" with constant flame-
wars on this and that language/stack/paradigm) and crucially also no
distracting "stack" or APIs to speak of (bare metal coding literally "on top
of the BIOS" in these days, no OS/GUI/multithread/GPU APIs).

The initial core team spent their entire youths 24/7 getting insanely good at
ASM and C and numerous gfx tricks and then "they just played the piano" to the
best of their accumulated abilities. Observe how much longer the Dooms took
compared to Wolfenstein and priors, and how much longer the Quakes took them
compared to the Dooms.. as they were slowly entering the age of Windows native
& Internet multiplayer even they too got slowed down a bit (were shocked how
for Quake "just waiting for 'ze engine' took a year"!) compared to the earlier
works --- of course still managed to ship high-quality products, but still

~~~
hyperpallium
Another eg of distraction-free programming:
[http://www.atariarchives.org/deli/cottage_computer_programmi...](http://www.atariarchives.org/deli/cottage_computer_programming.php)

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

~~~
NumberCruncher
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!

~~~
pasquinelli
What if you prototype a game mechanic and it's shit?

~~~
NumberCruncher
The article talks about similarities between common agile practices and John
Romero's programming principles. There is a world beyond the gaming industry
where you can sign big contracts and ship broken software and no one dares to
complain.

