Mike Abrash : GDC 2000 speech "It's Great to be Back!

Fast Code, Game Programming, and Other Thoughts from 20 (Minus Two) Years in the Trenches" ______________________________________________________________________________________

- (Outside the game industry) I thought there were truly deep technical challenges... I was chasing illusions. - Game Programming is about the best software job there is. - Game Programming is one of the last few places where code can be written clean, not patched over legacy code or pieced together from canned parts. - Game Programming is one of the last places where performance matters. - Game Programming is more challenging than just apps because you must address functionality and performance. - Games require great code but before that it requires a great design. - First you have to build a mental model and then implement it cleanly and efficiently. - That doesn't mean you'll get it right the first time. In fact, you probably won't ever! - Premature optimization is the root of all evil. - Optimize at a high-level or design-level and work your way down. - Don't jump on the first thing (idea) you think of. Think about the alternatives, build that model carefully, then be ready and willing to change the model constantly as you learn more or even to throw it away. - Think of your design as a jumping off point for a better one. - What matters more? Knowing how to optimize or knowing what to optimize. The answer is what. - If you don't find out where performance bottlenecks are, you're guessing! - When you make changes, measure the real-world effect. - It's often uncomfortable, but in the long-run, it makes more sense to deal with reality. - C++ and Java are great, but they tend to hide details. - This is an illustration of how optimization usually goes : You find a really bad spot, you squash it down, and in the process you come to understand the problem better and you can move on to more global optimizations because you have your head wrapped around the problem. - Rarely will you get more than 2X performance by doing everything in assembly. - Good ideas are key, but they're really a dime a dozen. - I'd say everyone in this room is a smart person. Some are smarter than others, but that's not really the difference. The real difference is hard work. Hard work to try out the ideas in the real world. Hard work to give you the deep knowledge that positions you to have more good ideas. And, most of all, hard work produces something useful, because having the idea or doing some prototype code doesn't really change anything. The key here is to do great software that people actually use! - As one case-in-point, many people thought Doom was a work of technical genius that appeared out of thin air, and it may have been genius, but that was about the 10th 3D engine John had written and he had spent years getting to that point. - In fact, people lust after the fame and Ferraris and all but very few people are willing to invest the years of 70-80 hour weeks that went into John's success. - And John always says "If you're willing to spend a year focusing on this and nothing else and driving yourself as hard as you can, you can get to the leading edge of this industry". - But it really takes the work. There's no substitute. So, the key is to learn by doing and finishing. - Don't overestimate the value of deductive thinking of just sitting there and solving it in your head. Get in there and get your hands dirty. Even the best people in this industry take time to figure out these problems. These are complex issues that really need to be worked through and learned about. So, your job is to keep working through them instead of falling in the trap of just thinking about them. - So, remember, there's an endless supply of good ideas. The limiting factor is the time and the will to try them out. - Another useful principle is to check your assumptions - Better yet, assume nothing. - Question the assumptions and, when you've found you're wrong, just laugh and be glad you learned something when you find you can do something better. - Humility helps. - Always be ready and willing to learn from others, because it's hard to learn everything on your own. - No matter how smart you are in any given area, there's always someone you can learn from. - Other people have been thinking about it (a subject) other ways sometimes for a lot longer. - Reinvention is not the mother of great software. - There are very few brand-new ideas around. - Why not stand on the shoulders of giants?

- There are a lot of people working on these problems and some of them do it for a living. - Learn math. - Do what you love. Good things will come of it. - Stretch until it hurts. Be flexible. Don't get too attached to your design. Be willing to listen to new ideas and admit you were wrong and change your mind. - Be open to change or watch it run you over and leave you behind. - The world constantly changes... - Most of what I knew 10 years ago is obsolete. - This industry has a fast-moving sweet-spot and unless you move with it, you'll be left behind. - As you work longer you'll acquire more preconceptions and knowledge that's not up-to-date and you will need to consciously make an effort to sweep out that trash and learn new things. - The only thing between you and great software are the limits you unconsciously set. - Once you believe something's possible, you will find a way to solve it. - There's only one obstacle and that's your mind. - You already have the capability to do great things. Actually doing them is just a matter of attitude. - The most important thing isn't what you study or how hard you work, although those certainly matter, but rather how you think about your work; whether you're limiting yourself with your assumptions or letting yourself push into unexplored territory. - Innovation is hard because you're wrapped up in doubt. - Your job is to ship great programs, not to get things right with a capital R. Besides, Right is an elusive target. - There ain't no such thing as the fastest code. - Turn your right brain loose. No great idea came from straight-forward linear thinking. - You have to keep in mind much of what you try will fail. It's the only way you'll learn and make progress. Otherwise you'll stay in this little corner of things you know. - Almost all programming can be viewed as an exercise in caching. - Whatever design you have is just a jumping off point for something better. - Resist the temptation to look for "the answer". - Try to change the rules so you can succeed rather than being mediocre under the current constraints. - Don't get comfortable. Aspire to excellence. Fight that comfortable satisfied feeling about your code. - Constantly say "How can I improve this?" instead of saying "Hey, isn't this great?" - Fight code entropy. Be willing to throw away code. - Simplify. Simplification is a wonderful guideline for writing great software. If your code is getting complicated, it's time to take a step back and get a new perspective. - Always try to do better with less in a different way. - Remember to have fun. This is about the coolest job around, but like anything else, game programming can turn into a job if you let it. Don't let it!

Gamasutra - Features - It's Great to be Back! Fast Code, Game Program...

http://www.gamasutra.com/view/feature/3108/its_great_to_be_back_fast...

It's Great to be Back! Fast Code, Game Programming, and Other Thoughts from 20 (Minus 2) Years in the Trenches
By Robert Huebner Editor's note: This paper was originally published in the 2000 Game Developer's Conference proceedings. To the Moon and Back A few years ago, after Quake shipped, I decided it was time to move on from games. Although working on Quake was a great experience, it felt like doing another game would be much the same, but far less interesting the second time around. What I needed, I thought, was a software field with deep structure and long-term challenges-something more significant, difficult, and ultimately rewarding. So I figured it was the right time to switch over to work on natural language, which fit that description perfectly. I figured wrong. By way of explanation, two stories and a conclusion: Story the first: After a couple of years of natural language work, I thought about moving to the Games group at Microsoft, and went to talk with the folks over there. While I was talking to Andy Glaister, my future manager in Games, he asked me, "How old is your daughter now?" When I told him she was 13, he said, "Really? I always think of her as being three or four." This was interesting, considering he had never met her, and had only met me a few days before-but he had read about her in the articles I had written in Dr. Dobb's and elsewhere over the preceding decade or so. It was a useful reminder of how long I had been working on and writing about performance and graphics, and how that had always stayed challenging and interesting even as computers and software changed drastically through the years. Story the second: While I was working on natural language, I read Mihaly Csikszentmihalyi's book Flow, about what sort of work people are happiest doing. It turns out there's a sweet spot, where the work is challenging and stimulating but plausibly doable, and where success happens often enough to form a positive feedback loop. As I read this, I realized that it was basically a description of successful game development. True, games have short development cycles, and progress is made incrementally-but at least progress is made, while the short cycles mean that success in the form of shipping occurs often, and positive feedback in the form of seeing cool stuff on the screen happens pretty much nonstop. And for all the incremental nature of game advancement, in many ways games are pushing the envelope harder than almost any other kind of software-what else does a consumer need a 700 MHz machine with a high-end 3D accelerator for? Plus 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. In Robert A. Heinlein's story "It's Great To Be Back," a couple leaves the Moon, after working there for years and hating it: hating the lack of fresh air, the lack of weather, the lack of cozy old houses, the lack of normal people-basically, hating everything. They make no bones about their feelings, and when they get to Earth, they just keep saying, "It's great to be back!"-although sometimes it seems a little forced. Gradually, the truth seeps in. Weather is often unpleasant. Germs are everywhere. Fresh air results in allergies. The old house they buy is falling apart. Worst of all, the people are rude and stupid, where the Loonies had been hand-picked for skills and compatiblity. Before the year is over, they realize they had been living in paradise and ask for their old jobs back, and before they know it, they're heading back to the Moon, saying "It'll be great to be back!"-and this time, it fits. There's lots of interesting stuff to think about and work on in natural language, or in any of dozens of other types of software, for that matter, and there are lots of other worthwhile pursuits that have nothing to do with software-but in terms of rewarding challenge, stimulation, and flat-out excitement, having made the round trip and returned, all I can say is: It's great to be back! Optimizing the Game of Life Like most of you, I suspect, I just plain like writing software-I did it for fun before I did it for a living-and one of the best

1 of 3

5/17/2010 7:33 PM

Gamasutra - Features - It's Great to be Back! Fast Code, Game Program...

http://www.gamasutra.com/view/feature/3108/its_great_to_be_back_fast...

things about game programming is the opportunity to do challenging programming in a broad range of areas, from graphics to physics to AI to you-name-it. Another is that the game industry changes so fast and is so close to the leading edge of consumer technology that it's a terrific opportunity to ride the wave of the future. The rest of this paper presents a number of principles and approaches to writing software and riding that wave that I've found to be helpful and/or enlightening over the years. At the risk of sounding like "Everybody's Free (To Wear Sunscreen)" (the alleged Kurt Vonnegut graduation speech that became a novelty hit when recited over a musical background), I'm going to present just the core points here, as succinctly as possible. This is basically just an outline, so you'll have some idea in advance of what to expect from the talk, and to jog your memory when you pick up the proceedings later. The talk itself will expand upon and illustrate the points, complete with anecdotes and examples ranging from working on Quake to working on Windows NT to writing "the last great software rasterizer" to speeding up the Game of Life. Herewith, some thoughts on fast code, game programming, software development, and more: The three secrets to success are: 1) Hard work, 2) Hard work, and 3) Hard work. 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 (thanks to David Stafford for the phrase). Accept reality: no software is ever going to be perfect, and perfection is a moving target anyway. Make the necessary tradeoffs and get it out the door. Success is more than just a big paycheck-or, as John Carmack put it, "The Ferraris are only gravy, honest!" You're going to be financially solvent-or better-anyway, so why not do what you love? If you do what you love and work hard and passionately, you're building the foundation of a rewarding life, and in the long term you'll succeed in every way that's important to you. If you like it, game programming is about the best software job there is. It touches on practically every area of programming, and it's one of the few places where code can still be written clean instead of patched over or pieced together from canned parts. It's also one of the few places where optimization still really matters. 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. Great software is more than just great code. First, a great design is needed, before the code can be written. Don't write code until you have a clear model in your head of what you're trying to accomplish. Take the time to get this right, and don't jump on the first workable idea you come up with. Design and optimize from the highest levels of your model on down, focusing on the big architectural issues first. Premature optimization-including premature low-level design--is the root of all evil. Keep looking for new, better approaches, and be ready and willing to change the model constantly as you learn more-or even throw it away entirely. Until you start running out of time, think of whatever design you have as just a jumping-off point for a better one. 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. When it seems you've made your code as good as it can be, and you still need more from it, try to change the way you're seeing the problem. You may be solving your abstraction of the problem rather than the problem itself. Terje Mathisen says, "Almost all programming can be viewed as an exercise in caching." David Stafford views almost all programming as a form of compression. There are infinitely many programming perspectives available to you-use them. Check your assumptions. Assume nothing. Always ask yourself questions and challenge your assumptions, and just laugh and be glad for what you've learned when you find you could have done something better. Stand on the shoulders of giants. There are few brand-new ideas in the world; read what others have done rather than trying to invent everything yourself. Most of programming success lies in engineering and integrating and finishing and being flexible, rather than in raw invention. Sure, it's fun to reinvent things, but there's a huge amount you have to know now, so it's hard to do it all on your own. Besides, there's plenty of cool stuff to figure out after you learn what's already been solved. Learn as much math as you can stand. Then learn some more. The industry is moving from broad, seat-of-the-pants programming to software more dominated by content and deep knowledge of areas like physics. Programming itself is easy; it's expertise in knowledge-intensive areas that will increasingly set programmers apart in the future.

2 of 3

5/17/2010 7:33 PM

Gamasutra - Features - It's Great to be Back! Fast Code, Game Program...

http://www.gamasutra.com/view/feature/3108/its_great_to_be_back_fast...

Be patient. It takes one year to become competent at something new, three years to become an expert. Stretch until it hurts. Be flexible. Don't get attached to your designs or code. Be willing to listen to new viewpoints, admit it when you're wrong, and change your mind as appropriate. Embrace change or watch it run you over and leave you behind. Accept that the goals, techniques, and rules will constantly change. The only thing standing between you and great software ideas is you. Think past the limits you've unconsciously set. TANSTATFC: There ain't no such thing as the fastest code (with apologies to Robert A. Heinlein and thanks to Terje Mathisen, who came up with the phrase). Turn your right brain loose. Try lots of stuff, even wild stuff. Listen to that little voice. Relax. Let yourself be creative. Accept that many ideas will fail. This is the only way to learn and make real progress. If your code is getting more complex, you're probably fine-tuning. Step back and look at the bigger picture for more global solutions. Try to change the rules so you can succeed, rather than straining to be mediocre under the current constraints. Don't get too comfortable. Aspire to excellence. Fight that satisfied feeling about your code, and constantly ask how to improve. Fight code entropy. Simplify. Try to do better with less, in a different way. Programming is not a zero-sum game. Unless you have legal or employer restrictions, share what you've learned, and learn from others. Having to explain something forces you to know it cold. It also makes you known, and leads to interesting opportunities. Remember to have fun! It's about the best job around, but like anything else, game programming can turn into a job if you let it. Don't let it. You're one of the luckiest people in the history of the planet, getting incredibly well rewarded for doing something challenging, fun, and just plain cool. Remember that and count your blessings every day. Then get out there and write some great software! Return to the full version of this article with comments Copyright 2010 UBM Techweb

3 of 3

5/17/2010 7:33 PM