Michael Abrash on Quake: "Finish the product and you’ll be a hero." • Hacker News Board

Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."

#91

Post by eru » Wed, Jun 22, 2011, 10:32 PM UTC

imurray wrote: post #44

eru wrote: post #40

Earlier quoted context omitted.

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

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

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

We can do much better than TCP. We just have to weaken the reliability requirement. And like you say, in the real world, that can go quite a long way, without actually being much weaker than TCP.

Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."

#92

Post by eru » Wed, Jun 22, 2011, 10:34 PM UTC

imurray wrote: post #47

iqster wrote: post #43

Earlier quoted context omitted.

Apart from the timelines, my impression is that implementing fountain codes has some IP issues. Also, there is some code complexity in getting them implemented correctly (as hard to get right as paxos). Anyone know a game that used these? Any body have first hand experience?

If considering using fountain codes, I would definitely want to check out the IP issues; there are certainly some patents in that space. For the application being discussed, fountain codes wouldn't be an exact fit anyway. I pointed to them because the ideas used in fountain codes are fantastic, and it might be possible to do something with that flavor. (I too would love to hear first-hand experience of anyone who's u…

Too bad I only ever proved theorems about codes, but didn't actually use them. But many of code are really beautiful.

Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."

#93

Post by gnosis » Wed, Jun 22, 2011, 10:55 PM UTC

kenjackson wrote: post #89

gnosis wrote: post #86

Earlier quoted context omitted.

"I'm not saying death marches are a good thing. But I've seen that in certain industries they do seem harder to avoid." How hard they are to avoid depends entirely on how good the management is at coming up with excuses for them and at using carrots and sticks, and on how gullible and desperate their developers are.

I'm not sure that's true. But if you look at certain industries, like web startups, death marches are almost the complete culture. Try to be employee #1 of a YC startup while being upfront that you work 40 hours a week, period. Not going to happen in many cases. The death march starts on day one in this industry.

"in many cases" being the operative term there.

How many YC startups would kill to get Steve Jobs to work even 1 hour a week for them as employee #1?

It's all about perceived value and negotiation. If your company values you enough, they will not make you work unreasonable hours. And if a non-workaholic employee values himself enough, he will not agree to work unreasonable hours.

Death marches are definitely a pathology in the computer industry, as they are in the medical field, where residents are forced to work insanely long shifts without sleep. In both cases, people's mental and physical well being is put at risk, the chance of burnout increases, and the quality of the results suffers.

It does not have to be this way. What will it take for management to stop understaffing and overworking their employees? And how long will employees consent to being worked in to an early grave?

Companies pulling this sort of crap is what really makes me wish the computer field had some effective unions that could collectively bargain for reasonable hours for reasonable pay. I know I'd join in a heartbeat.

Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."

#94

Post by stonemetal » Wed, Jun 22, 2011, 11:37 PM UTC

imurray wrote: post #44

eru wrote: post #40

Earlier quoted context omitted.

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

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

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.

Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."

#95

Post by kenjackson » Wed, Jun 22, 2011, 11:39 PM UTC

gnosis wrote: post #93

kenjackson wrote: post #89

Earlier quoted context omitted.

I'm not sure that's true. But if you look at certain industries, like web startups, death marches are almost the complete culture. Try to be employee #1 of a YC startup while being upfront that you work 40 hours a week, period. Not going to happen in many cases. The death march starts on day one in this industry.

"in many cases" being the operative term there. How many YC startups would kill to get Steve Jobs to work even 1 hour a week for them as employee #1? It's all about perceived value and negotiation. If your company values you enough, they will not make you work unreasonable hours. And if a non-workaholic employee values himself enough, he will not agree to work unreasonable hours. Death marches are definitely a pathol…

It does not have to be this way.

It doesn't, but it will be. :-)

I worked on bug, almost full time, about a decade ago, for about a month. A single bug. I hadn't anticipated the bug, and didn't plan for it. I've seen teams spend months trying to hit perf targets. It's the type of thing that isn't uncommon in our industry. I'm not sure how you plan for it.

What will it take for management to stop understaffing and overworking their employees?

Many tmies its not understaffing. Again, I've seen teams struggle to hit perf targets. If you doubled the size of the team it wouldn't make their lives much easier. It may even make it worse.

Our industry is one where you are fundamentally solving new problems (because if someone else solved it, you'd use their code).

Now maybe you're saying we need to toss schedules altogether. Things are done when they're done -- and no crunch time. You do it with 40 hours/week for however long it takes. I'd love to see that dream happen to, but I honestly don't think it ever will.

Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."

#96

Post by Lewisham » Thu, Jun 23, 2011, 12:11 AM UTC

kenjackson wrote: post #76

patio11 wrote: post #13

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

I think games are fundamentally different than web apps in a couple of ways. (1) There tends to be times where having the product ready is much more profitable than other times (holiday season) (2) It's a lot harder to rev games. The end result is you often end up on death march slogs. And unfortnately the state of project management is that they're surprisingly hard to avoid. Part of the reason is human nature. If w…

I know where you're coming from, and what you're saying is currently true, I do however fundamentally believe that the death march is not a given. It is a choice that the games industry has made because it:

a) Doesn't know any better

b) Doesn't care enough to change (there are always hungry young fresh graduates to replace those old guys who keep complaining about not seeing their children grow up)

It's partly a process thing, and it's partly a technology thing. I'm researching game testing [1]. Perhaps if we can get game testing to be better, we might end up with better processes, such as how TDD helps other software domains. Same goes for other technologies leading to other better processes.

Lots of really complicated software gets made every day, but only the games industry really uses terms like "crunch time" and "hero" and "oh thanks for finishing Red Dead Redemption after months of crunch time, here's your pink slip [2]." It has to mature, at some point, I just don't know when that will be.

[1] http://www.zenetproject.com [2] http://www.next-gen.biz/news/rockstar-san-diego-confirms-lay...

Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."

#97

Post by nitrogen » Thu, Jun 23, 2011, 1:10 AM UTC

bad_user wrote: post #88

nitrogen wrote: post #83

Earlier quoted context omitted.

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

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…

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.

Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."

#98

Post by puredemo » Thu, Jun 23, 2011, 1:42 AM UTC

dasil003 wrote: post #84

Gravityloss wrote: post #69

Earlier quoted context omitted.

Quake really wasn't playable over the internet until the QuakeWorld "extension" came along. It used prediction and delta codes, and actually ran the server and client (and still runs) at 72 fps, no other online multiplayer game that I know of has done it ever since. This means if you have ping 14 milliseconds, you really have ping 14 milliseconds. If you've played Quakeworld with solid 72 fps (this only really became…

Quakeworld was such a revolution. The gameplay is brutal. You have to put things in context. At the time Quake was designed rocket jumping was an unknown concept . Using the mouse was a controversial and new idea (you had to enable +mlook!). As such the game doesn't fit the mold of a refined and balanced FPS. Everything is raw and frenetic. You have to master rockets and lightning gun, you have to exercise strong map…

Fully agreed. I was hooked on expert mod ctf (with the offhand grappling hook) for quite a while. I've never found another game that approaches that pace of gameplay.

Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."

#99

Post by mambodog » Thu, Jun 23, 2011, 3:55 AM UTC

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

Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."

#100

Post by daemin » Thu, Jun 23, 2011, 4:40 AM UTC

tincholio wrote: post #60

delinka wrote: post #58

Earlier quoted context omitted.

Don't forget Wolfenstein 3D. While not directly germain to the topic at hand, this makes Quake second and probably more likely its development was handled like any other software project.

I think you misunderstood the parent post. Wolf3D was not really 3D, nor was Doom after it, and many other FPSs that came around at that time. Quake was the first really 3D FPS (e.g. you could walk under a bridge without "tricks"). I don't know what development process they had at ID at the time, but given that it was a Carmack project, I very much doubt it was anything like "any other" software project.

I also remember Mechwarrior 2 came out before Quake and was mostly 3D-ish. Granted most of the levels were flat but you could jump (with jump jets) and climb on top of some terrain.