9 ms·

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

177 points by gregschlom 15y ago

dools 15y ago
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 15y ago
  Unless you're in tools ;)
gregschlom 15y ago
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/ http://www.bluesnews.com/abrash/ The story on the first one is truly inspiring as well.
- JabavuAdams 15y ago
  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.
  - deleted 15y ago
    [deleted]
imurray 15y ago
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 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 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 15y ago
  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 15y ago
    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 15y ago
      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?
      - krakensden 15y ago
        > For this particular type of application, the tradeoffs are different from typical internet use? Absolutely. The value of any one packet is fairly low, you can interpolate the player's path, hell, maybe no one else was looking at him at the time. But with TCP, you basically stop the world for a couple roundtrips to make sure you have that packet, so all the packets you received after the original drop and before the retransmission are no longer useful, and you have to drop them too. It's also worth noting that TCP does /not/ have a uniformly high latency, it does the sawtooth thing. In other words, if Level3 decides they're going to shovel a bunch of your ISP's traffic into the bitbucket for a second, your packets have been dropped, the server is going to wait until it has a complete set of packets, and your TCP implementation has decided to throttle the number of packets you can send to catch up.
mariusmg 15y ago
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 15y ago
  Sounds like a Market for making bug fixing compelling and fun.
  - ctdonath 15y ago
    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 15y ago
      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.
  - beza1e1 15y ago
    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.
    - 15y ago
erikpukinskis 15y ago
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 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 15y ago
  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 15y ago
    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.
- aw3c2 15y ago
  http://www.quaddicted.com/software-vs-glquake/software-vs-glquake-texture-filtering/ http://www.quaddicted.com/software-vs-glquake/software-vs-gl... has some pictures of the texture filtering. But being able to run it at a "high" resolution (like 640x480) surely was a big part of the wow factor too.
aw3c2 15y ago
Today marks the 15th anniversary of the release of the Quake shareware.
patio11 15y ago
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.
- gregschlom 15y ago
  I get your point, but I think that's really not what Michael Abrash was meaning here when referring to "heroes". His point is simply to show how hard it can be to finish a product, no matter how well or ill managed the team is.
  - phereford 15y ago
    While yes, Abrash's point was that you are a hero because you finished your project on-time, patio11 has a great point. There have been many a horror story of long long LONG hours posted on here ranging from RockStar (lost the link) and many others because of a looming deadline with no working benefits for those extra hours.
  - patio11 15y ago
    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.
    - breck 15y ago
      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 explore space. Few programmers will die shipping a breakthrough product, but to say it won't require a heroic effort I think is to say it's not a breakthrough product.
Revisor 15y ago
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.
hebejebelus 15y ago
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.
- NoItAll 15y ago
  It could be that programming is not for you. (Prove us wrong.) It could be that you need the code for later projects. (You can create a toolkit and restart a project you intend to finish.) Personally, I've worked on at least 50 software titles. For my own, I've finished about half. That's normal. A driving game in Flash was fun, but too derivative of SpyHunter... but I did get the animation routines completed. For work, all projects must be completed on-time and under budget. This one is easier: if I don't finish, I'm screwed and my reputation as a developer would suffer. Each project has a 'ball'. If you keep your eye on the ball, put on some music and wrap it up.
- eru 15y ago
  Have you tried releasing early? As soon as you get some people who are actually using your stuff, and if only trying an early demo, you probably have more motivation to finish it.
- JabavuAdams 15y ago
  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.
seanm 15y ago
> 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.
mambodog 15y ago
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-lFmnFeEGYJ:www.gamedev.net/page/resources/_/reference/programming/140/283/graphics-programming-black-book-r1698 http://webcache.googleusercontent.com/search?q=cache:d-lFmnF...
mikeab 15y ago
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.
- earl 15y ago
  Um, holy shit! Part of the reason I'm a programmer today is I read Zen of Graphics Programming when I was 16 and I just had to get my own bsp tree algorithm working. Thank you.
- lemming 15y ago
  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!

177 points by gregschlom 15y ago

dools 15y ago

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 15y ago
Unless you're in tools ;)

gregschlom 15y ago

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/ http://www.bluesnews.com/abrash/ The story on the first one is truly inspiring as well.

JabavuAdams 15y ago
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.
- deleted 15y ago
  [deleted]

imurray 15y ago

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 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 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 15y ago
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 15y ago
  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 15y ago
    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?
    - krakensden 15y ago
      > For this particular type of application, the tradeoffs are different from typical internet use? Absolutely. The value of any one packet is fairly low, you can interpolate the player's path, hell, maybe no one else was looking at him at the time. But with TCP, you basically stop the world for a couple roundtrips to make sure you have that packet, so all the packets you received after the original drop and before the retransmission are no longer useful, and you have to drop them too. It's also worth noting that TCP does /not/ have a uniformly high latency, it does the sawtooth thing. In other words, if Level3 decides they're going to shovel a bunch of your ISP's traffic into the bitbucket for a second, your packets have been dropped, the server is going to wait until it has a complete set of packets, and your TCP implementation has decided to throttle the number of packets you can send to catch up.

mariusmg 15y ago

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 15y ago
Sounds like a Market for making bug fixing compelling and fun.
- ctdonath 15y ago
  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 15y ago
    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.
- beza1e1 15y ago
  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.
  - 15y ago

erikpukinskis 15y ago

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 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 15y ago
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 15y ago
  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.
aw3c2 15y ago
http://www.quaddicted.com/software-vs-glquake/software-vs-glquake-texture-filtering/ http://www.quaddicted.com/software-vs-glquake/software-vs-gl... has some pictures of the texture filtering. But being able to run it at a "high" resolution (like 640x480) surely was a big part of the wow factor too.

aw3c2 15y ago

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

patio11 15y ago

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.

gregschlom 15y ago
I get your point, but I think that's really not what Michael Abrash was meaning here when referring to "heroes". His point is simply to show how hard it can be to finish a product, no matter how well or ill managed the team is.
- phereford 15y ago
  While yes, Abrash's point was that you are a hero because you finished your project on-time, patio11 has a great point. There have been many a horror story of long long LONG hours posted on here ranging from RockStar (lost the link) and many others because of a looming deadline with no working benefits for those extra hours.
- patio11 15y ago
  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.
  - breck 15y ago
    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 explore space. Few programmers will die shipping a breakthrough product, but to say it won't require a heroic effort I think is to say it's not a breakthrough product.

Revisor 15y ago

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.

hebejebelus 15y ago

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.

NoItAll 15y ago
It could be that programming is not for you. (Prove us wrong.) It could be that you need the code for later projects. (You can create a toolkit and restart a project you intend to finish.) Personally, I've worked on at least 50 software titles. For my own, I've finished about half. That's normal. A driving game in Flash was fun, but too derivative of SpyHunter... but I did get the animation routines completed. For work, all projects must be completed on-time and under budget. This one is easier: if I don't finish, I'm screwed and my reputation as a developer would suffer. Each project has a 'ball'. If you keep your eye on the ball, put on some music and wrap it up.
eru 15y ago
Have you tried releasing early? As soon as you get some people who are actually using your stuff, and if only trying an early demo, you probably have more motivation to finish it.
JabavuAdams 15y ago
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.

seanm 15y ago

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

mambodog 15y ago

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-lFmnFeEGYJ:www.gamedev.net/page/resources/_/reference/programming/140/283/graphics-programming-black-book-r1698 http://webcache.googleusercontent.com/search?q=cache:d-lFmnF...

mikeab 15y ago

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.

earl 15y ago
Um, holy shit! Part of the reason I'm a programmer today is I read Zen of Graphics Programming when I was 16 and I just had to get my own bsp tree algorithm working. Thank you.
lemming 15y ago
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!