Michael Abrash on Quake: "Finish the product and you’ll be a hero."
1–10 of 104 posts
Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."
#2I'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.
Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."
#3I 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.
Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."
#4The 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.
Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."
#5Quake 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.
Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."
#6Today marks the 15th anniversary of the release of the Quake shareware.
Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."
#7I 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…
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.)
Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."
#8I 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…
You probably can get lost in choosing and implementing the optimal algorithm in every aspect of the game. Sometimes you just have to go with the sub-optimal to get it out of the door.
Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."
#9I 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…
Haven't the newer games had advances in this area?
Re: Michael Abrash on Quake: "Finish the product and you’ll be a hero."
#10I 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…
Haven't the newer games had advances in this area?
Quake 3 sent the game state update to clients as a delta relative to the last state they had acknowledged receiving: http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Ne...
On a different end of the spectrum there is Unreal's replication model, still used today by all UE3-based games: http://udn.epicgames.com/Three/NetworkingOverview.html