I wish I'd spent more time at the office — Not!

It's been an interesting three months (almost) since Rocket Science pushed us out the door. There have been a few frantic calls from Rocket Science asking for help with this or that, many job and consulting interviews, a really annoying event with a consulting almost-client, worries about money, relaxation, dog shows, lots of time with the kids, the end of a lawsuit, several camping trips — the list goes on and on.

The most interesting thing has been a personal discovery — an epiphany, if you will — that working on computer games for money is not the be-all and end-all of my life. I knew this, of course, because I thought about it every time I told a prospective employer that I had children and was "daddy-tracked," and wasn't interested in a place that planned for 80-hour weeks. But I didn't really KNOW it, if you understand me.

This is the first summer I have been able to go out and enjoy since I started working on computer games 14 years ago. This is the first summer I've been able to go walk on the beach, go camping (we spent three of four weekends in June in a tent — most of them at least three-day weekends), spend hours with the children, and just in general do mostly what I wanted. And I discovered something wonderful and strange — I like it. I like having a life. I was always sure that — if I won the lottery and never had to worry about money again — I would still work at what I loved — making computer games. And suddenly I'm not so sure.

When I was at Electronic Arts, I gave a short speech for ToastMasters which I entitled "Life is Uncertain — Eat Dessert First", and I closed with the idea that, on their deathbed, few (if any) people would say "I wish I'd spent more time at the office". I would appreciate it if everyone out there takes a short break after reading this column to think about that, and make sure that your life is organized as you would wish it.

Speaking of organized, here are a couple of books which may help you write better code to do what you want, and to understand what it is you're writing, and maybe, just maybe, let you get it done quicker, so you can take that walk on the beach while there's still some summer left to enjoy it.

More Effective C++

Scott Meyers
Addison-Wesley Professional Computing Series, PB, 318 pp.
ISBN 0-201-63371-X

More Effective C++ (MEC) is what I call "one of those segmented C++ books", meaning it's broken into sections, each of which stands more or less alone, each of which discusses a salient feature of the language. MEC has 35 Items, broken into six categories: Basics, Operators, Exceptions, Efficiency, Techniques, and Miscellany. Included at the end is a full implementation of auto_ptr <> (see Items 9, 10, 26, 28, 31, and 32) for those of you who lack an STL implementation.

Meyers' writing style is exquisite — tight, understandable, sometimes acerbic and funny. He refers to a code example as "evil, pure and simple", and says that "people who write this kind of code should be shunned". That's by no means the most interesting aside of a rather personal nature in the volume, and I found them very refreshing, as they remind me of conversations around the table at Technical Director meetings at EA (although we were usually discussing people's project planning rather than coding).

MEC is almost two books in one. Most of it is a typical list of "do's and don'ts" like Item 5 "Be wary of user-defined conversion functions" or Item 14 "Use exception specifications judiciously". The rules-of-thumb are useful and witty, and the explanations of why are better than most I've seen. Meyers covers fewer rules, but he covers them in more depth than most of the "segmented C++ books", and you learn more background in the process, which makes it easier for you (well, for me, at least) to remember and follow the rules — and to know when to not follow them (which is at least as important).

The Techniques section is still more in-depth, with more complex content. Each one presents a reasonably real-world, difficult problem, and proceeds to solve it (if possible) by steps, pointing out problems and some alternatives along the way. If you want to know how to make functions virtual with respect to more than one object, see Item 31. If you want a discussion of multidimensional arrays (and how to implement ones which allow you to use variables when declaring dimensions), see Item 30. Reading any of the Techniques will remind you of the many complex issues in creating truly usable (much less Reusable) C++ code.

Even if you never want to do precisely any of the things Meyers presents, you will learn a great deal about C++ from reading this book carefully, and you will discover things about the language you never knew — some good, some not so good, but all of them interesting and useful. Get this book. And after you've read it, you should probably get his earlier book from the same publisher, Effective C++ to sit next to it on your shelf.

STL Tutorial and Reference Guide

David R. Musser, Atul Saini
Addison-Wesley Professional Computing Series, HB, 400 pp.
ISBN 0-201-63398-1

The Standard Template Library (STL) is (depending upon your point of view) either a wonderful new standard set of reusable code, an up-and-coming contender for potentially useful, or a gawdawful mess of cryptic combinations of something called "generic altruisms" and "containuometers" (or something like that :-}).

There's no question that the learning curve for using the STL is steep, and for fully understanding it even steeper (just read some of P.J. Plauger's columns). My initial introduction to the STL was the source code to the HP implementation, which I got off the Net. I got far enough to use the List container, but that's about it. No matter how much I read the source code, I didn't feel as though I understood what was going on well enough to trust the STL in shipping code. P.J. Plauger's columns on STL helped a lot but it's hard to learn an entire system when you have to wait a month between include files.

STL Tutorial and Reference Guide (STLRef) opens (as the title suggests) with an extensive tutorial (240 pages), covering Iterators, Generic Algorithms, Sequence Containers, Sorted Associative Containers, Function Objects, Container Adaptors, Iterator Adaptors, and Function Adaptors. Each chapter is clear and straightforward, with well organized information. Many of the examples are parallel across different containers or different algorithms. There are extensive notes about tweaks necessary to deal with compilers which don't yet implements features necessary to some aspects of STL.

The reference section is equally informative, providing very complete information on each piece of the STL, including everything covered in the Tutorial plus reference information on Allocators. Requirements are clearly stated as appropriate, and the item-specific information is well organized and appears complete. The reference section makes for dry reading, of course, but if you're looking for the guts of the various parts, here they are. I would have preferred that the reference materials include pointers to the examples in the Tutorial instead of referring you to the index, but that's a minor nit.

One place STLRef falls down (for us performance-happy game developers) is performance data. If you are especially concerned with performance (and who among game programmers isn't), you will want to augment the performance information provided (mainly listing the base characteristics of various algorithms) with specific tests of your STL implementation before you write your next Quake engine. Performance is a major goal of the STL, but performance and generality are sometimes at odds, and you will want to be sure when working on high-performance code.

If you are interested in writing less code, and using the standard library more, STLRef is a great book to give you confidence in working with STL. If you can bring yourself to use someone else's code for the 80+% of your game that's NOT performance critical, here's a good place to start.

Evan Robinson is the former Director of Games Engineering at Rocket Science Games, Inc. Before becoming a manager he was a consultant, programmer, technical director, and game developer. He is now eking out a tenuous living writing review columns, going on job interviews, and considering offers — but more to the point, enjoying actually seeing a summer day for the first time in 14 years. You can email him to offer him a consulting opportunity or a job, or just to talk (well, OK, type) about books, software, development, or the meaning of life.

Copyright © Evan Robinson. All Rights Reserved.