Christmas Time is here, by golly,
disapproval would be folly,
deck the halls with hunks of holly
fill the cup and don't say when!
Tom Lehrer, "A Christmas Carol"
Christmas time is here again, and like park workers do in Yellowstone, we're celebrating it (enduring it?) in August. I don't know about you, but at Rocket Science, this year's game teams are working madly on shipping and trying not to think too hard about next year. It's the time of year when we reap the results of our folly or wisdom in preparation. Did we think of all the important things? Did we put together the right team? If someone gets hit by a truck can we replace them? Did whoever started these products think enough when they started them so that I can finish them? All across the games business people are struggling with these issues. I know I personally have been too busy the last few days to write down (as I do most days) what I've done - not even one line descriptions of each meeting I've been to, task I've (hopefully) completed, or disaster I've tried to fix. So naturally I'd like to struggle with some different issues for a while, if I might.
Buy War Toys for Christmas,
have a Happy Holiday!
Santa's slain his reindeer
now he drives the Enola Gay.
The Foremen, "Buy War Toys for Christmas"
We make toys (the actual quote from an EA colleague was "we make toys for rich kids"), and children (of all ages) play with those toys, and the toys we make have an effect upon the people who buy them. At least, I like to think they do - if they don't, why would anyone spend money for them?. It's a wonderful feeling to have someone send email about how an early game made them want to become a game programmer, or to hear how a person thought a game was really great. The things I've always wanted to build into games have to do with evoking emotional response - adrenaline is OK, but I'd really like to see a wider range of responses including curiosity, anticipation, sadness, even love ("Can a computer make you cry?" the EA ad asked. Little did they know then that the answer was "of course - with frustration"). And the more emotional response a game provides, the more engaging it becomes, the more potential it has for affecting the person playing it. Who bears ultimate responsibility for that effect? I don't know for sure, but at this time of year I think about it. I think it's a shared responsibility - a collaboration, if you will -between the creative force behind the game and the player. I know that I want to feel good about showing my work to my children (the users of tomorrow). What anybody else wants to produce is their business so long as I'm able to leave it on the shelf if I don't like it.
If I sound uncertain about where this is leading, it's because I am. I'm trying to balance creative and intellectual freedom with a marketplace that values things I don't, and to resolve questions of moral responsibility in a context and society that often seems to barely value or recognize legal responsibility, much less ethical responsibility. It's a tough nut for a mostly practical engineer-type to handle, and I need to chew on it in small pieces. I'd love to engage you in dialog on this or other subjects. Feel free to email me. Anyway, enough philosophizing - on to the books!
Bringing Design To Software
Terry Winograd, ed.
Addison-Wesley, 321 pages, $29
This is one of those books that just came out of the blue. It's a collection of essays by various authors on design in many forms - design of software, design of bridges, graphic design. It includes profiles on various subjects including the Xerox Alto and Star, Kid Pix, Macintosh, and Quicken. Each chapter attempts to address some fundamental issue of design - what is design, how does it apply to software, how can we do it better? I found the essay by Mitch Kapor especially interesting, given my general rule that the games business is years behind the general software business which is years behind academia. Kapor's essay "A Software Design Manifesto" was first delivered as a speech in 1990, and it concerns the need for a special kind of designer for software - someone who will be responsible for the design of the product instead of the program or the user interface. We've had people like that around for well over a decade - we call them game designers. It's one of the first clear indications I've seen in external literature which demonstrates our being ahead of the rest of the world. Of course I think we're behind on the program design part, but that's another story.
The essays on "Design as Practiced" and "Organizational Support for Software Design" were very enjoyable for me as well. The story of the power switch on the Mac made me run around to all my computers and look at the switches and controls on them, and the quote that "I've been in the business for 20 years and I know what the customers want" reminded me forcefully of people I've worked with. I suspect that anyone who reads the collection of essays will find other connections to their own experience which will resonate as strongly.
It's a different viewpoint on the world, that of the designer. Almost like having someone deconstruct TV commercials while you watch them ("now this image here represents sex"), it gives you a new perspective on almost everything you do. If you don't mind having your mind played with a bit, you should take a look at this book.
Graphics Gems Series
This series is one of those collections any serious programmer should probably have. There are many interesting tweaks useful to the graphics programmer, and I find that they generally stimulate other uses - bounding circles for computer opponent calculations, for instance. I have several of the five (last time I looked) volumes available - some at home, some at work, and I really can't rank them in order. Each volume consists of a collection of "Gems" which range from a paragraph describing a cool idea to a complete specification (in c or pseudo-code) of an algorithm. Gems included in the first two volumes include "Distance from a Point to a Line", "Rotation of Run-Length Encoded Image Data", "Mapping RGB Triples onto 16 Distinct Values", "Three-Dimensional Homogeneous Clipping of Triangle Strips", "A Digital 'Dissolve' Effect", "Spheres-to-Voxels Conversion", "Backface Culling", "Simulating Fog and Haze", and many more.
Every once in a while, when stuck on a problem, I like to just grab one of these books and look at the table of contents, trying to figure out how to apply some specific technique to the problem at hand. It doesn't really work all that often, but it does usually get me around whatever block I'm currently facing (and on to the next one). You might want to try it if you find yourself stuck somewhere in the wilds between virtual Thanksgiving and Christmas.
Other Denominational (or not) Seasonal (or otherwise) Greeting (or parting shot!) of Your Choice!
Copyright © Evan Robinson. All Rights Reserved.