Slashdot Mirror
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.
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!
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".
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.
I have no idea if I explained that like I wanted to. But I know what I meant.
www.HearMySoulSpeak.com
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
Nerd Rock In Progress
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.
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.
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.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
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.
--
www.scorbett.ca
...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.
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?
-- dR.fuZZo
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
Nerd Rock In Progress