<story><title>Michael Abrash on Quake: &quot;Finish the product and you’ll be a hero.&quot;</title><url>http://www.bluesnews.com/abrash/chap70.shtml</url></story><parent_chain></parent_chain><comment><author>patio11</author><text>I got the hero speech too, once.  If anyone ever mentions the word &quot;heroic&quot; again and there isn&apos;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 &quot;We&apos;re about to exploit you because the project is understaffed and under budgeted for time and &lt;i&gt;that is exactly as we planned it&lt;/i&gt; so you&apos;d better cowboy up.&quot;&lt;p&gt;Maybe it is different if you&apos;re writing Quake, but I guarantee you the 43rd best selling game that year also had programmers &quot;encouraged onwards&quot; by tales of the glory that awaited after the death march.</text></comment>
<story><title>Michael Abrash on Quake: &quot;Finish the product and you’ll be a hero.&quot;</title><url>http://www.bluesnews.com/abrash/chap70.shtml</url></story><parent_chain></parent_chain><comment><author>imurray</author><text>I liked the discussion of transmitting game state for network play. Quick summary: Doom sent differences of state, which &lt;i&gt;had&lt;/i&gt; to be received and therefore acknowledged. Quake sent the whole game state each time, but compressed, so it wouldn&apos;t matter if a transmission was lost.&lt;p&gt;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&apos;t need feedback. The Quake approach sends the game state redundantly, but across time simply repeats information, and repetition codes aren&apos;t optimal.&lt;p&gt;It could turn out that in this application the Quake approach &lt;i&gt;is&lt;/i&gt; best, because for latency reasons it might not be possible to send long enough blocks for Shannon&apos;s theory to apply. The Quake approach is also nice and simple. However, here&apos;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&apos;ll have to wait for another packet or two before we can infer the deltas, but we don&apos;t need to bother telling the receiver that we lost a packet.&lt;p&gt;[1] &lt;a href=&quot;http://en.wikipedia.org/wiki/Fountain_code&quot; rel=&quot;nofollow&quot;&gt;http://en.wikipedia.org/wiki/Fountain_code&lt;/a&gt; — but a much better resource is chapter 50 of &lt;a href=&quot;http://www.inference.phy.cam.ac.uk/mackay/itila/book.html&quot; rel=&quot;nofollow&quot;&gt;http://www.inference.phy.cam.ac.uk/mackay/itila/book.html&lt;/a&gt;&lt;p&gt;EDIT: In response to replies by VMG and JoachimSchipper: I didn&apos;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&apos;s an interesting puzzle to think about.</text></comment>