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

31–40 of 104 posts

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

#31

Post by NoItAll »

redfloatplane wrote: post #25

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…

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.

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

#32

Post by aw3c2 »

erikpukinskis wrote: post #5

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

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.

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

#33

Post by imurray »

rubinelli wrote: post #20
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…

You'll probably like another interesting article about a similar problem, the network code of X-Wing vs. TIE-Fighter and how they handled extremely high latency and packet drop rates: http://www.gamasutra.com/view/feature/3374/the_internet_suck...

I did. Thanks!

Their arguments suggest UDP with no acknowledgements. If they had needed to send more data they might have needed slightly more sophisticated error correcting codes than repetition codes. Doing that and keeping the latency low could be a challenge however.

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

#34

Post by ctdonath »

jodrellblank wrote: post #15
mariusmg wrote: post #4

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.

Sounds like a Market for making bug fixing compelling and fun.

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.

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

#35

Post by breck »

patio11 wrote: post #18
gregschlom wrote: post #14

Earlier quoted context omitted.

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.

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

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

#36

Post by ehsanu1 »

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…

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.

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

#37

Post by [deleted] »

patio11 wrote: post #18
gregschlom wrote: post #14

Earlier quoted context omitted.

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.

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.

[deleted]

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

#38

Post by odiroot »

patio11 wrote: post #18
gregschlom wrote: post #14

Earlier quoted context omitted.

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.

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.

Okay, this is a bit sad. How would you respond to your employer if he used this "heroic talk"?

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

#39

Post by jeffool »

matwood wrote: post #27
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.

I don't think that's true. Shipping is really hard - basically the end result of execution. A perfectly run project can still suck to work on at the end. The problem is that for most people the fun part of working on a project is the discovery phase when you're building something new. The last 20% of squashing bugs and going from "the code is working" to the "code is shippable" is generally not a good time.

I speak from a point of ignorance, I've never worked in the field. That said, if a project requires months of unplanned crunch time, it wasn't perfectly run. And I don't think anyone would say that crunch isn't commonplace.

(At least, I think patio11 is referring to the culture of crunch time. Correct me if I'm wrong!) You probably know that, but, if not, (or for those who don't) here's some reading:

http://en.wikipedia.org/wiki/EA_Spouse

http://arstechnica.com/gaming/news/2011/05/the-death-march-t...

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

#40

Post by eru »

ehsanu1 wrote: post #36
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…

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 (comp…

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

Post reply on HN