Michael Abrash on Games Programming

An anonymous reader sent in an awesome article by Michael Abrash (If you don't know, I'm not telling). Tons of great bits in there, advice, anecdotes etc. Definitely worth a read if you are either a programmer, or a game fan.

Comments

Re:Sweetest spot?

[Joe Rumsey]

I think you're confusing the fulfillment derived from overcoming a set of challenges with the fulfillment derived from knowing that you created something that saves lives or improves the standard of living in some way. Obviously, computer games don't save lives (if anyone cares to disagree with me on that one, I'd love to hear your argument),

One counter argument to the notion that violent games like Quake cause violence is that such games actually give an outlet to violent tendencies, preventing them from manifesting themselves in everyday life. If you believe that argument, you could extend it to believe that games have prevented some people from becoming serial killers, thus saving lives.

I doubt many people who write games believe either side of that. I know I don't. But it's what you asked for, an argument that games save lives.

Great Article

[amnesty]

When I tell people that I'm a Computer Science major, their first reaction is that I'll probably make lots of money. Regardless of the truth of that statement, it saddens me that people think of that first. Even many of my peers are in this program because they think it will be a ticket to a high paying career, even though they hate what they are doing.

So its incredibly refreshing to see an article like this. This reminds me why I chose computer science -- because I love it! Its in my blood! Call me a geek, but binary search is beautiful (log n!!). I can't stop reading about this stuff after school and on weekends.

It almost seems like Abrash really enjoyed his time with game programming, but wanted to 'do the right thing' and go into "a software field with deep structure and long-term challenges-something more significant, difficult, and ultimately rewarding." But in the end, his love for games and graphics programming won out.

Thank you for this inspiration, Mr. Abrash!

Bright Guy, Great Author

[Stiletto]

I consider Mike Abrash my personal hero. His writing inspired me to get into graphics programming. He has a simple way of writing, and he makes it a pleasure to follow him thorough the complex concepts he writes about.

Mike's "Zen of..." books should be on any graphics programmer's bookshelf.

It's kind of sad that he now works for Microsoft, but I guess it's good for MS--if nothing else it proves that they CAN hire talented (and old-school) coders.

His tips on the second page are golden! Particularly:

Get past the abstractions and know what your code does. Profile in many ways: profilers, NULL drivers, bracketing key code with timing calls, breaking into the debugger at random and seeing where you are. If you don't do this, you're guessing.

Knowing what to optimize matters as much as knowing how to optimize. Otherwise, you'll optimize the wrong thing, and end up with really fast slow code.

Re:Bright Guy, Great Author

[Anonymous Coward]

No, it isn't even a little bit sad that he's working for Microsoft. He's enjoying it. Just get over the stupid obesession with Microsoft.

As Carmack says, "Check your assumptions".

Re:Bright Guy, Great Author

[geomcbay]

Your post is not only total bullshit, but its insulting to Michael Abrash as well.

Michael Abrash worked at Microsoft before he worked at id Software. He went back to Microsoft after he left id Software (after Quake 1). He has worked there for YEARS. Do you think he would put up with working there for years if he was just a 'symbol' and not getting useful work done? Suggesting such is like slapping the guy in the face.

Your other suggestions indicate you're not familiar with the voracity in which Microsoft has been getting into gaming over the past few years. DirectX 8, other than being a Windows-only API, is GREAT. There are very few things that can be complained about (other than cross-platform support). This isn't DirectX 3 anymore.

Furthermore, Microsoft knows what it is doing with the X-Box. It WONT change. It might produce an XBox 2 in 5 years, but that's standard console practices these days.

Microsoft, no matter how evil you might portray them as, is smart enough to know that a console isn't a PC, and the X-Box has been handled accordingly. That's partially why every known game developer (and his/her mom) is currently signed up as an XBox developer, the only notable exceptions being Sony (for obvious reasons), Nintendo & its 2nd parties (for obvious reasons), and Squaresoft (who have been rumored for a long time to become an X-Box developer -- if they do that's a major coup and loss of de facto exclusivity for Sony).

Re:Bright Guy, Great Author

[JWhitlock]

Whada ya mean "It's kind of sad that he now works for Microsoft"? Yes, that means he won't be working on Quake X, but Quake is doing fine on it's own. Yes, it means he may have to be a little secretive on what he is doing, but you know he's working, and that the results will be spectacular. When Penny Arcade has a hard time getting one of them to hate the XBox, you know Microsoft is doing well, and the gaming world should send another big thank-you card to Abrash.

Plus, if he can just spend a little time optimizing the DirectX code, then EVERY game benefits. You know that if he finds any new tricks, he'll report on them, and even the free software world will benefit. Check out this link at Dr. Dobb's journal for a taste of what he is doing at Microsoft, and why it is important.

Like he says in the article, the important thing is to do, not to think, and there's a lot of optimization to do at Microsoft.

Sweetest spot?

[Metal Machine Music]

> games cover a huge range of technologies-graphics, physics, modeling, scripting, AI, networking, databases-more than any other kind of software I can think of. What I finally realized was that, for me at least, game programming is the sweetest spot in all of software development.

They might be fulfilling to the programmer, but that does not necessarily mean that games programming is the highest form of programming. Don't get me wrong, I like a Quake deathmatch with the rest of the office as much as the next guy, but to say that games programming somehow transcends other software is wrong.

Surely it's much more fulfilling to say that you created the software that runs a hospital which saves people lives, or that we sent man to the moon on one of your programs. Compared with these games seem just a little trivial.

Re:Sweetest spot?

[Slak]

I don't like using other people's libraries.

*Pu-lease*. It's attitudes like this that I find sad. Are you telling me that you'd rather re-invent string manipulation functions than use the standard ones?

As far as "Games programming is one of the last bastions of 'pure' code", there's plenty of 'pure' code going on in academia - witness the rise of Beowulf clusters. There are places in industry which focus heavily on code optimization - Simulated Anealing at Intel, etc.

I take umbrage with 'pure' code. There is more to a program than code - design and maintenance are important parts to the equation. In the latter, I would argue that game programmers are fairly lazy. Those soul-destroying accountancy programs (generally) are more maintainable than a game. Games (especially closed source ones) are not (or rarely so) designed to last. Such is the nature of the industry.

My perception (admittedly based on little information) is that game programmers tend to be arrogant pricks who tend to subscribe to two theories:

1. If I didn't write it, I won't link to it. This goes directly to your comment about other people's libraries.
2. They do not seem as willing to learn from lessons from other "programming industries".

Re:Sweetest spot?

[scorbett]

Surely it's much more fulfilling to say that you created the software that runs a hospital which saves people lives, or that we sent man to the moon on one of your programs. Compared with these games seem just a little trivial.

I think you're confusing the fulfillment derived from overcoming a set of challenges with the fulfillment derived from knowing that you created something that saves lives or improves the standard of living in some way. Obviously, computer games don't save lives (if anyone cares to disagree with me on that one, I'd love to hear your argument), but writing one can be extremely fulfilling in its own way. As Abrash states in the article, game software covers a surprisingly large number of usually separate fields of knowledge, and you have to be a bit of an expert in everything in order to pull it off. I used to be into games programming myself (as an amateur, not a professional, and certainly not on the same level of quality as Abrash), and I found it more challenging than most of the work I've done as a professional software engineer since then. Not only more challenging, but a hell of a lot more interesting and fun as well.

As you say, surely some people would take more pride in writing software that runs a hospital, but for some personalities, writing a really cool game can be just as fulfilling, if not moreso, even if the usefulness of the end product in the long run is dubious at best.

--

Re:Sweetest spot?

[rde]

...but to say that games programming somehow transcends other software is wrong.
There are two ways to answer this; one is by paraphrasing the man himself. Games programming is one of the last bastions of 'pure' code; you can write from scratch, and optimisation counts. I stopped being interested in programming when Windows was becoming ubiquitous; I don't like using other people's libraries. So as Obi-wan would say, games programming does transcend; from a certain point of view.
As for the fulfilment: the big software that keeps hospitals running is first and foremost accountancy software. I've written this sort of thing, and it's soul-destroying work. Knowing that it was used in a hospital and was helping keep people alive would have made the pill a little less bitter, but not by much.
Are games trivial? Of course they are. How many people do you know who wouldn't benefit from reading a book or visiting a museum rather than fragging ass? But much as I like reading and museuming, I still like crushing the weak underfoot, and consider that aspect of my character - and social life - to be one of the many traits that make me the wonderful human being that I am today.
Is the absolute aim of each human to live longer, or to live better? If I wrote a game that brought enjoyment to millions, and pushed the envelope slightly so that future generations of games - and/or hostpital software - benefited from my insights into coding, then I'd feel pretty fulfilled.

Game Developer

[LightningTH]

I'm a game developer working on the Open Source Genesis3D game engine for a new version coming out.
It has always been my dream to do some type of programming that was constantly a challenge as I tend to become bored very easily. There is always some challenge to game programming as you do your best at something then have to do even better next time around. You are constantly trying to out perform the best out there and constantly pushing the computer to it's limits with the latest games.
It can be a great field to be in but getting in is the difficult part as along the way you are viewed as a game programming wannabe and most people don't even make it over the "write a simple game" hurdle. Even after getting into the area you have to prove your worth against others at or possibly above your level of knowledge. Reading a ton of tutorials doesn't always help as you have to break away from the tutorials sometime and take your own steps out in doing a game or an area of a game. Alot of people fall down at this point too and never get back up because they decide it is too hard and don't really understand what is going on so they continue on the tutorial path or just quit all together. For those that break away from tutorials and understand what is really going on to make the game run can great some good games. From there it is a matter of finding a game company to take you in. Of course you would want to get into a company that is constantly using the latest things and this isn't always easy either.
The road is long but can be very enjoyable for those that have the patience, always want a challenge, and have fun with their job.

Optimizing Conway's Life

[dmorin]

Remember this challenge? Sort of the defining moment for a code optimization metric. I spent a long, long time following in the footsteps of that series of articles. (In short, the challenge was pretty much "make Conway's Life go as fast as possible"). There's a moment in code optimization where you get to experience the true epiphany of hacking - version 1 takes 15 seconds, version 2 takes 13 seconds, version 3 takes 12 seconds....and then suddenly, as if in a dream it comes to you....and version 4 makes that leap to something like 2 seconds and you revel in it.

I have no idea if I explained that like I wanted to. But I know what I meant.

Re:Optimizing Conway's Life

[dmorin]

Ooo! OOO! There was a game contest on rec.games.programmer once to write a game in 256 bytes. I remember, like, within the first day somebody had written "You losers, that's impossible, it'll take me 220 bytes just to pull the A20 line high and get into virtual memory." (Or something very close to that, it's been a long time). Talk about missing the point.

Engineering vs. hacking

[ShadyG]

It's so refreshing to see a prominent games developer advocating such engineering principles as architecture and design. It may seem odd to some -- natural to others -- but the very brightest game programmers I have been able to find care nothing for engineering. Any hint of process or structure means restricting creativity and stifling innovation.

There's a similar sentiment in the hacker community I have witnessed in open source projects. I've participated in a few, and I inevitably get blank stares when I ask for an SRS or architecture document so my components blend well and extend the current structure elegantly. Nevermind when I ask where in the source tree to drop my UML diagrams. I just ask that for kicks nowadays :)

In the business world, no one gets paid to write code. We get paid to ship software, and I've found that regardless of their attitude coming into the project, everyone is delighted when we ship a solid product on time and within budget. It's so rare a thing in this industry that coders get simply giddy at the thought of telling their friends they actually did it.

From my experience, a realistic estimation and budgeting system and thorough engineering process is the number one most effective perk in terms of retaining happy programmers.

-- ShadyG

Re:I thought it was supposed to be hideously hard

[mizhi]

You have to be comfortable in the basics at least. Actually, to do well in any area of computer science, you have to be generally good at math, not necessarily a master, but you still proficient and if you run across something you don't understand, you need to have the ability to sit down and teach yourself. IE, I know basic linear algebra, when I run across something that requires a new skill, I sit down with a text book and acquire it. When I read Abrash's book "Zen of Graphics Programming", I remember thinking to myself about the difficulty of the math (I was in late middle school, early high school), but after working through it, it's kinda neat to see what you can do with numbers. And Abrash is one hell of a programmer and thinker. He and Donald Knuth are two of my favorite CS guys.

Mozilla an Unnatural act?

[Chris Siegler]

Learn by doing. Thinking is great, but the only way you ever really learn something thoroughly is by doing it-and particularly by finishing it, which is harder than it sounds because shipping software is an unnatural act

This is so true. Just visit Sourceforge and check out projects that die between working and complete. There are so few programmers who can actually finish a project. More so than pure programming ability it separates the great from the merely competent programmers.

Natural Language

[copyconstructor]

I myself am on the verge of spending some serious cycles on NL programming (adding 'smart' bots to a MUD) and am curious what about NLP he didn't find satisfying. Seems to me NLP is one of those 'deep knowledge areas the industry is moving to'.

Well, at least in all the games I've ever played the AIs are stupid as fu**, especially when it comes to language, so obviously somebody needs to look into it.

Level of detail

[yerricde]

In many games, polygonal objects are stored at several levels of detail; objects close up are drawn with more complex models. If you always use the lowest LOD model for collision detection, people will notice how much better it is than a cubic bounding box but will probably not notice a couple cm difference in the detail silhouettes.
Like Tetris? Like drugs? Ever try combining them?

Re:Why games save lives

[scorbett]

Actually, computer games do save lives in that they provide income and health benefits to a large populace in the electronic entertainment industry.

Oh, come on now. Are you telling me that everyone in the electronic entertainment industry would die if suddenly there was no more demand for new computer games? I think that most of the people in that industry would be talented enough to roll into related areas rather than slowly starve to death due to lack of income. For example, a graphics programmer could certainly get a job doing engineering graphing software (something I have done, in fact I got that job because I had experience writing games and doing graphics programming), or a game logic programmer could move into the AI field, etc, etc.

So, games do save lives, but in order to see the fact one must be willing to examine indirect economic effects.

Sorry, but it's a little too indirect to actually make the claim that it "saves lives" that way. Certainly it puts bread on the table for a lot of people, but I'm sure none of them would die if it all went away. Interesting argument, though.

--

Programming and Playability

[Bonker]

While this article was great in terms of general programming knowledge, it seemed to neglect a detail that many game developers sadly overlook. A game is *nothing* without playability.

Mr. Abrash spends quite a bit of time in the article talking about the best ways to go about programming a game. This is obviously something that comes through in his designs, since the certain software company he developed for spent more time on their game engine than they did level design. This tendancy is even stronger in today's game market where the 'definitive' FPS's are Quake 3 Arena and Unreal Tournament. Both of these spent much, *much* more time on engine development and programming than they did on making their games enjoyable.

Don't get me wrong... Q3A and UT are loads of fun, but compare them to the playability of Half-Life, a little older game that is based (IIRC) on the Quake 2 Engine. There's a lot of custom code in HL, but the majority of it is still a big Q2 total conversion. Valve focussed on playability, story, and fun in HL, rather than code and this shows. I'll play Q3A for a little while, especially if I'm waiting on a long download, but I've lost entire weekends to the plot details in Half-Life.

Programming can be and end unto itself, and even *should* be in some circumstances, but its only half of the equation when building a video game.

Heh.

[dR.fuZZo]

This paragraph made me smile.

Aim high, think big. Right now is a particularly good time for ambitious game programming, because so much more is possible now than ever before, thanks to CPU performance and 3D accelerators.

You know -- that's as opposed to five years ago when CPU performance was at its lowest in over ten years.

I mean, you know, I dig the point and all, but won't it always be a good time for ambitious game programming?

Problem-centric analysis

[ShadyG]

This guy hit it right on the head when he spoke of changing your perspective from time to time to work the actual problem rather than just your existing design.

I've been doing this subconsciously for years, but I didn't really take note until this past Christmas. My gf and I were at Walmart buying a tree, and it was pretty friggin' sharp. To carry it to the car, I needed gloves. No gardening gloves were to be found in the garden department, so my gf asked an employee where the tools were, thinking they might be there. I instinctively re-asked the question in a different way: "Where can I find gloves suitable for protecting my hands from the tree spines?" We found then in sporting goods. The tool department was a proposed design, but analysis led me back to the core problem that needed solving.

Of course when I got home, I realized that I didn't need gloves at all. The problem was scratched/punctured hands, not an explicit need for gloves. On that same trip, we had already purchased a tarp to lay over our carpet. I could have wrapped the tree in it and not needed the gloves. So I actually failed to address the original problem to determine the most efficient solution. Still learning after all these years :)

Back to software engineering, this new focus has been of tremendous help in developing product requirements, architecture, and design. I feel much more confident that the product my team develops is actually providing a useful service to the customer, rather than usefulness being accidental to the cool technology we invented.

-- ShadyG

All nice clitches...

[Shotgun]

but my boss tells me that we have 2yrs of work to do by July. Optimize code? Hell, as soon as something looks as if it might possibly work one day it is ripped from my hands, stamped with Version 1.0 and shipped to the customer. I'm told that 'we'll fix it later', but there is another list of features that are slated for the next release (December).

I do code as the author suggest at home on my own projects. I'll rework a program at the drop of a hat if I see or hear of a better way. But, at work, and I'm sure this holds for the vast majority of programmers, code is considered optimized when it works correctly on 95% of a regression test set.