Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bluesnews.com

Post reply on HN
Print view View original

71–80 of 104 posts

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

#71

Post by kenjackson »

malux85 wrote: post #67
beza1e1 wrote: post #19

Earlier quoted context omitted.

I like fixing bugs. I hate that you have to replicate them beforehand. That's usually digging out certain versions of the environment setup. The actually theory-validation-cycle of bug fixing is fun, because it is just like science.

I like fixing bugs too. The more difficult and obscure the better. I am often called in to fix a bug that nobody else can find, partly because I'm good at it, and partly because I enjoy it. My dream job is freelance bug hunter .. I'll track em down and squish em, when you cant, or dont want to :)

You should talk to John Robbins about that freelance profession. That's what he used to do and maybe still does. If you become really good at jumping into an unknown environment and fixing the hard bugs that no one else can fix, I suspect you can make a really healthy living.

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

#72

Post by JoachimSchipper »

imurray wrote: post #12
JoachimSchipper wrote: post #7

Earlier quoted context omitted.

I'm not an expert, but don't you have the timeline wrong? E.g. Luby's "LT codes" is from 2002, well after Quake's 1996 launch date. Honestly, though, I think the Quake guys were going for - and achieved - "good enough". (Also, coding obviously doesn't work for client -> server communication, since the server has to keep going even if packets are lost.)

I agree Luby's codes came after Quake. Although other codes for the erasure channel did exist, and the important ideas for the class of scheme I'm talking about were known. That wasn't meant to be my point though. I was just thinking about the puzzle, rather than what "should" have been done. I don't follow the final parenthetical comment: the point of the coding is precisely so that the server can recover all inform…

Regarding my parenthetical comment: the server can ignore input that was not received in time, block while waiting for input, or try to "rewind" the world. The first is lossy, the second leads to the same hiccups as reliable transmission protocols (although the effect may be smaller), and the third leads to "paradox" (and lots of complexity). There are no really good solutions here.

I agree that such codes are interesting, though - I really should know more coding theory...

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

#73

Post by rw »

Gravityloss wrote: post #69
swah wrote: post #9

Earlier quoted context omitted.

Haven't the newer games had advances in this area?

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…

This.

QW is the Starcraft of first-person shooters. It's so much fun to duel (or 2on2 or 4on4) that pro players for other games still enjoy coming back to qw, where many of them started. I would say it's a beautiful game.

It also has a ton of fanatical players/mappers/coders hacking on weekends, making their own custom additions to the game.

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

#74

Post by james4k »

Gravityloss wrote: post #69
swah wrote: post #9

Earlier quoted context omitted.

Haven't the newer games had advances in this area?

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…

Valve's Source engine (and GoldSrc, HL1), which itself is heavily based on the Quake 3 engine, uses delta compression and prediction as well. This is part of what made Counter-Strike such a popular game, and still is today. Especially in the competitive gaming world.

http://developer.valvesoftware.com/wiki/Source_Multiplayer_N...

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

#75

Post by rplacd »

dools wrote: post #29

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.

Unless you're in tools ;)

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

#76

Post by kenjackson »

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 we honestly schedule everything out and see it will take 12 months, it will take longer. Because at month 8 it will look like we have three weeks of work left -- to everyone but the project manager and a senior dev or two -- who realize that there is still an honest to goodness four months of work left. On paper it doesn't look like four months of work, but it is (especially because a lot of things are fixing bugs to things that you don't know yet are broken).

So what happens is the pace dev starts to slow down. People start taking vacation, or three day weekends. Before you know it, its month 11 and you're further behind than you were at month 8! WTF!?

You can't just ship the game with this quality. Characters disappearing, levels not loading every other time you play them, etc... A web app you could, and just fix it over the next three months. With a game, while you can service it, its a lot harder, and day 1 reviews are super important -- a 70% metacritic score means no one will even care that you serviced it.

I'm not saying death marches are a good thing. But I've seen that in certain industries they do seem harder to avoid.

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

#77

Post by wmil »

james4k wrote: post #74
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…

Valve's Source engine (and GoldSrc, HL1), which itself is heavily based on the Quake 3 engine, uses delta compression and prediction as well. This is part of what made Counter-Strike such a popular game, and still is today. Especially in the competitive gaming world. http://developer.valvesoftware.com/wiki/Source_Multiplayer_N...

Valve licensed Quake code from id, and GoldSrc/Source are descended from that. There is no Quake2 or Quake3 code, the improvements over Quake are pure Valve.

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

#78

Post by angrycoder »

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…

You don't get to be Carmack or Abrash by working 8-5. They didn't have a slave driver boss standing there making them work, they did it because its what they love doing.

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

#79

Post by shadowmatter »

imurray wrote: post #3

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

Note that fountain codes are very, very patent-protected by Luby et al. Five years ago I came across literature on rateless codes, which are digital fountain codes that allow practically infinite encoding, or a practically infinite stream of data from which the original could be reconstructed. One really promising type of rateless code was online codes, which required O(1) time to generate a single block and O(n) time to decode a message of length n, which was much better than the LT rateless codes that came before it. (The paper can be found at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12....)

I wrote up a Java implementation in my free time, and it worked well and was quite fast. I pinged the authors of the paper, asking if I could open-source it, because I came across a web site with their names on it that seemed like they were going to commercialize the idea. They replied that they had abandoned the idea of online codes because, even though their approach was faster than all other coding schemes, it still violated patents held by Luby and his company Digital Fountain, which has since been acquired by Qualcomm. That was a bummer, because I thought the online codes paper was very elegant, and the implementation was quite simple.

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

#80

Post by sixtofour »

breck wrote: post #35
patio11 wrote: post #18

Earlier quoted context omitted.

Exciting as it was, we hit the same rough patches toward the end as any other software project. I am quite serious when I say that a month before shipping, we were sick to death of working on Quake. Finishing projects should not require this and anyone who tells you different is your enemy. I mean that.

In the past I would agree with you but nowadays I've come to the opposite conclusion. Shipping crappy, trivial, mundane, or even good software shouldn't require this. But shipping something that is timeless is absolutely mentally, physically, and emotionally draining. I think around eleven men died building the Sydney Harbor Bridge. I'm sure many men will die in the next few decades as we start to commercially explor…

"Few programmers will die shipping a breakthrough product,"

Not right away, but abusing your health takes its toll.

Post reply on HN