
Michael Abrash on Quake: "Finish the product and you’ll be a hero." - gregschlom
http://www.bluesnews.com/abrash/chap70.shtml
======
patio11
I got the hero speech too, once. If anyone ever mentions the word "heroic"
again and there isn't a burning building involved, I will start looking for
new employment immediately. It seems that in our industry it is universally a
code word for "We're about to exploit you because the project is understaffed
and under budgeted for time and _that is exactly as we planned it_ so you'd
better cowboy up."

Maybe it is different if you're writing Quake, but I guarantee you the 43rd
best selling game that year also had programmers "encouraged onwards" by tales
of the glory that awaited after the death march.

~~~
projectileboy
3 guys wrote the world's first game that rendered a truly three-dimensional
world, and they did it in software, and it ran at 20+ frames per second on my
Pentium 75. It's not quite correct to talk about Quake the way you would talk
about almost any other software project.

BTW, if you're curious, Abrash goes into greater depth at the end of his
"Black Book of Graphics Programming", which I think is now freely available
online.

~~~
nitrogen
Abrash's Graphics Programming Black Book was my favorite programming book in
high school. I read it everywhere I went, even when camping. I highly
recommend it to anyone who wants to learn how the lowest-level graphics
primitives were drawn before GPUs. The first half of the book also makes for
an excellent guide to optimizing algorithms by reducing overhead and
converting to assembly language.

My only complaint about the book was that the publisher (Coriolis?) included a
notice at the front saying that no code samples, algorithms, etc. could be
used in any project without their express approval, but most of the algorithms
and code were previously published elsewhere.

~~~
bad_user
I used to do graphic demos in Pascal, in 286 mode, using hand-coded procedures
in assembler for the graphics parts, using Mode X for buffering the
animations, like 320x240 resolution, 256 colors and only one virtual screen
(although more were possible).

Doing 3D was pretty cool too - I couldn't do fancy stuff, but I could display
and rotate 3D objects, drawing only visible polygons, draw textures and even
have simple lighting.

To me it seems weird how kids work these days. I don't know what a pixel
shader is for instance.

~~~
nitrogen
_To me it seems weird how kids work these days. I don't know what a pixel
shader is for instance._

Thanks for bringing up some nostalgia. A pixel shader is roughly analogous to
a hand-optimized texturing routine, except it runs on the GPU.

------
imurray
I liked the discussion of transmitting game state for network play. Quick
summary: Doom sent differences of state, which _had_ to be received and
therefore acknowledged. Quake sent the whole game state each time, but
compressed, so it wouldn't matter if a transmission was lost.

Neither approach seems optimal from an information theory point of view. The
Doom approach needs feedback, but communicating at the optimal rate of noisy
channel doesn't need feedback. The Quake approach sends the game state
redundantly, but across time simply repeats information, and repetition codes
aren't optimal.

It could turn out that in this application the Quake approach _is_ best,
because for latency reasons it might not be possible to send long enough
blocks for Shannon's theory to apply. The Quake approach is also nice and
simple. However, here's the approach I have in mind: send the stream of deltas
protected by a code that can cope with some of them being erased, such as a
Digital Fountain Code [1]. Each message would contain deltas stored slightly
redundantly and XORed with previous deltas. If we have all previous deltas
then we are set, otherwise we'll have to wait for another packet or two before
we can infer the deltas, but we don't need to bother telling the receiver that
we lost a packet.

[1] <http://en.wikipedia.org/wiki/Fountain_code> — but a much better resource
is chapter 50 of <http://www.inference.phy.cam.ac.uk/mackay/itila/book.html>

EDIT: In response to replies by VMG and JoachimSchipper: I didn't mean to
suggest they should have done anything differently. It worked well enough, and
they got it out the door; agreed! I just think it's an interesting puzzle to
think about.

~~~
ehsanu1
Thanks for the pointer to fountain codes. Though, since I'm working on a
networked game that works over websockets, this is basically something I
wouldn't bother with since websockets are TCP, not UDP, and as such they are
guaranteed delivery and correct order of arrival. I realize TCP vs UDP is
something of a debate in game networking, but it's a simple solution here. Let
the protocol do the work and just send (compressed) deltas. I suppose this is
equivalent to the Doom way.

~~~
eru
Yes, it's for the protocol to worry about. imurray basically described a
protocol to build on top of UDP that has slightly weaker guarantees than TCP.

(Or does the construction that immurray described benefit from domain
knowledge about the underlying data?)

~~~
imurray
eru makes a really good point, and I suddenly feel much less confident. My
intention was to sketch the idea for a protocol that was _reliable_ (with very
high probability, just like anything in the real world). So, to repeat the
argument: if there's some information we need reliably, whatever cunning thing
we layer on top of UDP, we're just reimplementing what TCP does. It seems
unlikely we can do better than TCP unless we're doing something very problem
specific.

I guess the argument is that a scheme based on UDP can have very low latency a
lot of the time, only occassionally stalling while waiting for more data.
Whereas TCP, which needs acknowledgements and to keep packets in order, has a
uniformly high latency. For this particular type of application, the tradeoffs
are different from typical internet use?

~~~
stonemetal
TCP is kind of the full feature kid on the block. You might do better making
up a protocol that has what you want and skip on the rest. There are real
latency costs for parts of TCP that a game will never use i.e. Nagle's
algorithm(sure you can turn that one off but every thing has its cost and you
can't turn off everything you don't need in TCP).

I am surprised how infrequently RTP comes up in these conversations. Something
close to RTP seems like it would be ideal for games.

------
mikeab
Fun to read the comments. Thanks to the people who said nice things. My
daughter is 25 now, btw :)

YMMV, but I've never done anything worthwhile without going through a
difficult period near the end. It's just the nature of the beast, and it was
as true on Windows NT as on Quake.

I never said anything about death marches, or at least I don't think I did. I
worked hard and steadily throughout Quake, and John worked incredibly hard and
steadily always, but that didn't change significantly toward the end. It's
just more difficult at the end, because fixing bugs and improving performance
and putting in less interesting features (like menus) isn't as much fun as
experimenting with new renderers, because there's pressure to get it exactly
right, and because you've just seen too much of the same game for too long.
It's not hellish or life-destroying, it's just hard. I know some very talented
people who just aren't willing to push themselves through it, and that's their
right, but they also don't get finished projects out the door, and in the end,
that's what it's all about.

As for companies that routinely put their people through death marches - I
have nothing good to say about that. John and I volunteered to do what it took
to ship Quake. It makes a huge difference when it's internally motivated
rather than demanded by management.

~~~
lemming
Thanks for this and all your writing - the Zen of Code Optimization was a
hugely inspirational book for me when I was younger, and is one of the main
reasons I'm a programmer (even if it has instilled a slight paranoia about
performance in everything I do).

I'd love to see more writing from you!

------
gregschlom
I'm a huge fan of Michael Abrash and his writting style: He always starts with
a totally unrelated story, and somehow manages to relate that to the topic of
his article.

Check out the other chapters on Quake here: <http://www.bluesnews.com/abrash/>

The story on the first one is truly inspiring as well.

~~~
JabavuAdams
How old's his daughter these days? He used to start his Doctor Dobb's Journal
(DDJ) articles with anecdotes about his (toddler) daughter.

I'm guessing she's now older than I was when I was reading those articles.

------
erikpukinskis
Quake was a huge part of my formative nerd years. I remember fondly the first
time I ran the BSP calculation for a level I built, fired it up and crapped my
pants at how smooth the rendering was. The game itself was pretty bizarre, but
so many nerdgasms were had over the insanely beautiful shit they were able to
render in real time.

And then if you got a 3dfx Voodoo Graphics card you would get translucent
water and bilinear filtering on the textures....

Those were the days.

If anyone wants to really travel back in time, the original QuakeTalk
newsletter is still available online:
<http://www.gamers.org/pub/idgames/docs/faqs/qtalk400.txt>. I remember vividly
reading through John Romero's gameplay concepts and being ridiculously
excited. Of course there was no way they could've achieved what my naive 14
year old self imagined from those interviews. But it sure was nice to think
about.

~~~
matwood
_And then if you got a 3dfx Voodoo Graphics card you would get translucent
water and bilinear filtering on the textures...._

It's hard to explain to those who were not around the revolutionary change
that occurred when GLQuake + the Voodoo card came out.

It was one of the few 'holy shit' moments in my technological life. I knew
then and there that everything changed going forward.

~~~
JabavuAdams
Seeing DOOM for the first time in my buddy's residence room had that effect on
me.

The thing is I knew the math for 3D CG, but more from an academic angle. I'd
also been playing some true 3D games like LHX. I "knew" that what I was seeing
was just impossible -- there was no way it could be that fast on that
hardware.

So, simplifying the problem from 6DOF 3D to 2.5D made a world of difference.

I love the idea that I might be able to turn an impossible problem into
something solvable if I just constrain myself to solving a subset.

Something to keep in mind when stakeholders want everything all at once, with
no compromises. Compromise / prioritization is what makes cutting-edge
technology possible.

------
hebejebelus
As a computer games development student, this feels very relevant to me (as,
I'm sure, it does to other software developers). Even a project I'd like to
do, on my own, for a week, is very hard to finish. There never really seems
like there's a point to polish after I've learned what I wanted to learn. I'm
battling this literally as I write this comment - this is only another way to
procrastinate. I find keeping rigid office hours helps, as does keeping in
mind that this project or that will look good in a portfolio, or might bring
in some cash.

Really, though, it's just damned tough to continue something that you view as
finished. The next games project I start will be rather boring to code, but
hopefully fun aesthetically. That way, I'll concentrate more on the second
90%, but getting past the first 90% might be harder than usual.

If you've got any tips for surviving the second 90% of a project, I'd love to
hear them. My short attention span coupled with my low focus really makes it
difficult to finish anything, and it's getting me down.

~~~
JabavuAdams
As a computer games development teacher ... :)

There are ups and downs, and one gets used to dealing with them. It's just
practice.

One of the most motivating things is to get positive feedback -- both from
shipping features, and from human contact.

I always have times where I'm in a rut ... I don't want to work on the project
... but someone sees it and they think it's cool. Or maybe I get away from it
for a few days, then look at it with fresh eyes and get re-motivated to fix
just one more thing...

Also, you can use procrastination to your advantage. Don't play games or surf
to procrastinate. Instead if you're burnt out on project A, switch to project
B, or set up a server, or write a script, or exercise, or play music, or read
a math book (I'm giving away my preferences).

Anything to recharge or to make progress on something else that needs to be
done.

------
mariusmg
The 90% + 90% is soooooo true. Everyone wants to do new shiny stuff, nobody
wants to fix bugs so the product can be pushed out of the door.

~~~
jodrellblank
Sounds like a Market for making bug fixing compelling and fun.

~~~
ctdonath
That's the difference between FOSS and commercial software: the latter gives
developers a reason to do what is otherwise uncompelling and unfun.

Some things are just not fun.

Some things are just not compelling.

Some things are a big obnoxious hassle which nobody will enjoy doing and
nobody will appreciate.

Doing those things differentiate the professional from the amateur, and are
why the professional gets paid.

~~~
billybob
I think this is a great point, and helps explain why much FOSS software is
clunkier than its commercial counterpart.

Although I don't think this is an issue of good, professional developers vs
bad, amateur ones. Sometimes the same developer works on commercial and FOSS
projects. It's just about the nature of work.

Work is hard. That's why you have to be paid to do it. If you're doing a
project for fun, you'll probably stop when it stops being fun.

For many of us developers, the "first 90%" is fun and intrinsically
motivating; the "last 90%" sucks and we do it because it's what we're paid to
do.

------
dools
Shipping is like a project in itself - and I'm not even just talking about the
process of finishing the product, but the act of preparing something for
public consumption _once you're finished_ is like a whole other dimension.
It's enough to leave you cowering in the cupboard. And you'll never be happy.

Ship in fragile terror my friends. It's the only way.

~~~
rplacd
Unless you're in tools ;)

------
Revisor
This comes at a great moment for me. I have just gotten into the second, not
fun 90% part of the project and it's really frustrating. Mr. Abrash has
articulated why.

I'm going to put my head down and work.

And ship it.

------
aw3c2
Today marks the 15th anniversary of the release of the Quake shareware.

------
mambodog
I've been working on a Doom/Build style game engine for the browser so I've
been reading Abrash's Graphics Programming Black Book[1] which has been very
insightful. It covers key aspects of the development of Doom and Quake, and I
highly recommend it.

[1] Full text:
[http://webcache.googleusercontent.com/search?q=cache:d-lFmnF...](http://webcache.googleusercontent.com/search?q=cache:d-lFmnFeEGYJ:www.gamedev.net/page/resources/_/reference/programming/140/283/graphics-
programming-black-book-r1698)

------
seanm
> true 3-D objects. However, this raised a new concern; entities can contain
> hundreds of polygons, and there can be a dozen of them visible at once, so
> drawing them fast was one of our major challenges.

How quaint.

