Slashdot Mirror

Aeonite (Michael Fiegel) writes "The back cover of Game Creation and Careers says "Reading this book is like being at a round-table discussion with more than 150 of the video game industry's most successful designers, developers and publishers." In fact, it's exactly like that, for better and for worse. Mostly worse." Read on for the rest of Fiegel's lengthy review. Game Creation and Careers: Insider Secrets from Industry Experts author Marc Saltzman pages 744 publisher New Riders rating 4 reviewer Michael Fiegel ISBN 0735713677 summary A poorly organized series of interviews with industry-leading game designers.

Structurally, the main section of the book is broken up into four parts. Part 1 is devoted to Pre-Production, and includes chapters on Game Genres and Player Perspective, General Game Design, and the like. Part 2 is devoted to Production, with chapters on Programming Theory, AI, Game Art and Animation, User-Interface and Game Control, Sound Engineering and Music and Gaming. Part 3 takes a look at Post-Production, with information about Proper Game Testing, Tech Support and Public Relations/Marketing. Part 4, titled "How to Make it Happen," discusses DIY Shareware solutions, Breaking into the Industry, Agents and Headhunters, Design Schools, Internet resources, Conventions and Awards.

The book closes with an Appendix that includes biographies of more than 80 of the interviewees featured in the book. These are interesting but somewhat uneven: some of the artist bios are single paragraphs, while others (such as Don Bluth's) run to two pages long; some of the bios are little more than bulleted lists of games worked on, while others talk about future plans; and of course, one wonders why, if the book features more than 150 interviewees, why did nearly half of them not bother with a bio?

Words of the Prophets

The bulk of the book is devoted to material gleaned from interviews with game industry professionals. None of these is presented as its original whole; rather, bits from each are cut and pasted around, so American McGee's comments about Action Game Design, Game Industry Jobs and Storyboards are all located within the (usually) relevant chapters, rather than being presented as a whole, continuous interview.

I say "usually," because there are some rather questionable decisions made about where to place chunks of information. For example, much of the information in Chapters 15 and 16, which cover Sound Engineering and Music and Games respectively, is instead about breaking into the industry, which belongs in Chapter 21. Chapter 6 (which discusses, in part, Creating Characters) has a Note that says "See Chapter 13, 'Game Art and Animation,' for a discussion from legendary Hollywood animator Don Bluth on how to create a successful game character..." One wonders why, if it's relevant to this chapter, why it's not right here. Earlier, Chapter 5 contains a chunk of text about User Interface Design, even though Chapter 14 is supposed to be about UI Design (and in fact, this text refers to the later chapter before giving the advice). And in Chapter 5, there's a section in Gordon Walton's interview about breaking into the industry, which closes by saying "For more on breaking into the industry, sink your teeth into the meaty Chapter 21!"

Whether these were in-person or e-mail interviews is never clear, but they're all a little uneven, with some relating personal stories and others reciting information verbatim from company websites. Taken individually, many of these interviews are filled with interesting tidbits, insightful commentary and quirky bits of trivia which are worth reading. However, a good deal of the advice is not at all helpful or insightful, except perhaps superficially. For example, here are Yu Suzuki's thoughts on what separates a great game from a good game:

1. Passion.
2. Never give up.
3. Create a game carefully, thinking about the people who will play it.

Certainly good advice for creating a game. Or, with some word substitution, for writing a book, or flying a plane, or developing a cure for cancer, or becoming a Jedi Master. I think Yoda said it better: "Do, or do not. There is no try."

Much of the "advice" throughout the book is like this -- vague and meandering, and only peripherally relevant to game design. It's tempting to read the words of the designers within as if they were carved in some holy rock on the summit of Mount Radeon, but the fact is that when you look past the aura you get the impression that a lot of what they have to say is nothing but common sense. And with the way the book presents their interview excerpts their advice often comes across as, well, less than inspirational:

• Todd Howard on UI design: "Interface is everything. It's the player's way of using the game."
• Richard "Lord British" Garriott on MMORPGs: "Hire experienced personnel."
• Kevin Cloud on becoming a game artist: "You can't learn to be a computer artist unless you spend time on a computer."
• Thomas Warfield on shareware game design: "Make a good game that's fun to play."

I don't know too many people who would intentionally design a bad game that's awful to play by designing a crappy interface with inexperienced personnel without using any computers. But maybe it's just me.

Too Many Cooks

By far the most frustrating aspect of the book is the one I alluded to in my opening paragraph. Namely, that "too many cooks spoil the broth," as goes the old saying. In each chapter, advice from up to two dozen designers is presented, and in many cases one piece of advice contradicts another. In fact, in the few cases where such advice is in agreement, the author feels inclined to point it out, as on page 43, where he tells us, of Scott Miller, "Notice how closely his comments resemble George Broussard's advice? Now that's focus!" In fact, Saltzman addresses the issue himself in the opening to Chapter 14 by saying "...it's likely that you'll find some conflicting advice in areas of this book on art techniques, level design suggestions, or the best way to animate a character..." That's putting it mildly.

"Asked about the importance of design documents," says the author, "(David) Perry directly contradicts Lorne Lanning and others." He does not, however, tell us who to listen to. Nor does he tell us what to think when Ragnar Tornquist contradicts himself with "I said earlier to avoid clichés and stereotypes, but sometimes clichés and stereotypes are great ways to establish a character immediately." Later, John Slagel, asked about job-seeking, says "Don't go through a recruiter," and the author is quick to remind us that "the folks in Chapter 22, 'Game Agents and Headhunters,' may disagree!" On page 386, Greg Thomas tells us that, when it comes to game art, "It's better to make the model simpler at first and continue to add details until the limits are reached," but on page 387 Todd Howard says "Aim high... it's easier to scale down than up later on."

So do you listen to the game designer on page X who says one thing, or do you listen to the contradictory advice on page X+1? Higher or lower? Recruiter or on your own? Design document or not? Red pill or blue pill? Left or right? Up or down? The book leaves all that for the reader to decide, which raises the question: what's the point? It's difficult to understand the true intent of a book which presents such a diverse range of opinions on the topic of game design, except perhaps as an amusing diversion from actually designing games. In order to use this book as a guide to game design, one must inevitably choose which advice to follow. And as presented, that's an impossibility.

This all comes to a head in Chapter 21, "Breaking Into the Industry." "Find a job, any job," says one designer, while another says you should get a Master's degree first. Scott Miller says "with all the ideas that have been sent to me (hundreds), I've yet to see one that's worthy of turning into a game," and Sid Meier says putting together a playable demo and shopping it around is the way to go, and then Minh Le says that building a mod for an existing game is the best route to success. What all this boils down to is this: these people are not telling you what will work for you. Rather, they are telling you what worked for them. Everyone's story is different. Every path to success is different. Even the recruiters themselves disagree in Chapter 22. Melanie Cambron says "...at the early stages of one's career, using recruiting services is not the best approach," but two pages later Jeff Brunner's interview "...explains why a budding artist, programmer or game designer should consider using the services of a recruiting agency." Admittedly, this latter comment comes in the author's own words, which leads me to my next subject.

Wowza

In a book which basically amounts to a series of interviews, the author's voice repeatedly pops up with interjections-cum-interruptions that are annoying, repetitive, and just plain unnecessary. Sometimes it's a throwaway phrase, at other times just a word, but it's always a speed bump in the experience. For example, in his introduction to the book (titled, in unnecessarily casual fashion, "So, You Wanna Make Games For A Living, Huh?"), Saltzman says "... it's no wonder why the video game industry has broken the $10 billion dollar-a-year mark in the U.S. alone, which is significantly more than the revenues generated from movie box office receipts. Wowza." Wowza?

Later, Saltzman tells us to turn to Chapter 21 to read about "...breaking into 'da biz.' Whew!" On numerous occasions, he invites the reader to "pull up a chair," just in case you were reading the book while skipping rope. In Chapter 14 the reader is invited (or perhaps commanded?) to "Enjoy the following paragraphs." And page 247 cheerfully chirps "Pencils in hand?" before listing five points about Level Design. Why would we need to take notes with a pencil when the book has the notes already printed? These are obviously attempts to insert some lighthearted banter into the book, and in some places they do help to provide transitions between thoughts, but in my opinion they're nothing but an indication that the author has misjudged his audience. If they're meant to be ignored, then they shouldn't be there, and if they're truly meant to be read, then, well ... they still shouldn't be there. These little interjections come across as little more than the author jumping up and down at our round-table discussion, shouting "Don't forget me! I'm over here" or else "Don't forget about this other stuff! It's over there."

It is this latter tendency is the largest issue I have with the author's comments, in that most of them are redundant and unnecessary attempts to explain the obvious or refer to other sections of the book. From the introduction to Chapter 2, "General Game Design: Action/Arcade Games," comes this helpful tidbit:

"This chapter features designers from the action/arcade category. Chapter 3, 'General Game Design: Strategy Games,' delves into the strategy game genre. Here we go!"

Each section and interview constantly reminds us of other chapters and sections that we might want to read, like one of those old Choose Your Own Adventure Books. At the end of a section on game design in Chapter 2, we are reminded to go to Chapter 6 to read more about characters. In Chapter 6, we are encouraged to read not only about breaking into the industry in Chapter 21, but also about game design in Chapter 2. Page 187 of Chapter 6 invites the reader to "(f)ling yourself back to Chapter 2." What, right now?

This reaches its climax in Chapter 5 with "For more from the vocal Chris Taylor, jump to Chapters 6, 17 and 21. Whew!" Whew, indeed; which do we choose? Back and forth, back and forth, every page referring to another two pages. Perhaps this is meant to replicate a hyperlinked web page, or to encourage reading the book out of sequence, but in the end it merely comes across as schizophrenic and eminently unhelpful, as in this gem from Chapter 3: "In Chapter 21, 'Breaking Into the Industry,' Bill Roper offers some advice on breaking into the industry." Or how about the first sentence in Chapter 10: "Chapter 8, "Level Design," dealt with level design ..."

You think?

Also sprinkled haphazardly throughout the book are "Notes," which in theory are supposed to explain something but generally tell us nothing relevant. In many cases, the Note does little more than refer us to another chapter, as with the cross references above. An interview with Richard "Levelord" Gray in Chapter 8 mentions John Romero's interview in Chapter 20 for no apparent reason. An interview with Joel Jewett in Chapter 21, "Breaking Into the Industry", closes with a Note that Noah Falstein has more to say about breaking into the industry in Chapter 6; if it's relevant to the current chapter, why is it not in the current chapter? Most egregious, perhaps, is the Note which leads off Chapter 16, "Music and Games", informing us that we should turn back to Chapter 15 to read about Sound Engineering. But we were just there! In fact, later in Chapter 16 an interview excerpt with George "The Fat Man" Sanger leads off with the words "In Chapter 15," and ends with the words "See Chapter 15!"

OK, we get the point -- you like Chapter 15!

The Bad and The Ugly

Graphically, the book is quite unimpressive. The book's black-and-white printing turns the majority of the photographs into ugly blotches that do little to illustrate anything. For example, page 74 features a drab grayscale illustration from Age of Mythology, amusingly captioned with "Talk about gorgeous graphics!" Elsewhere, screencaps from The Sims contain illegible dialogue, images from Red Faction are indecipherable, and a bewildering photo of a parking lot on page 592 adds a certain je ne sais quoi. None of it is pretty.

There are also a few photos of the designers themselves, which range from the typical ("here's me in front of a computer") to the arrogant ("here's me holding a gun next to two hot chicks") to the silly ("here's me in a bunny suit"). Most of these have nothing to do with the text, the book, or anything at all that I can think of. A picture of George "The Fat Man" Sanger is accompanied by a caption informing us that the snakes on his suit were all hand-embroidered. Objection, your honor -- how is this relevant?

Relevance is also a big problem with the artwork; as in, there mostly isn't any to speak of. In but a few cases is the art both appropriate to the text as well as interesting and/or useful (as with the sketches from Twisted Metal: Black on page 35). Some of the artwork is obvious promotional art, as when a pre-rendered still from Diablo II is passed off as a shot from the game, and some of it is merely irrelevant to the text it accompanies, as when two stills of Oddworld's Abe accompany text that talks about how unique his friend Munch is. Later, two random shots from Unreal are dropped in with a caption discussing puzzle design in the middle of a chapter on level design. Then a discussion about User Interface design is accompanied by two shots from The Sims, bereft of any sign of its pie menu interface, the only thing that would have made the images relevant. In Chapter 21, "Breaking Into the Industry," what will you find stuck in between interviews with Donny Thorley of Day 1 Studios and Dave Davis of Electronic Arts? Inexplicably, four screenshots from Rockstar's Grand Theft Auto, Vice City, and a caption that talks about Chapter 19, "Public Relations and Marketing."

The book could also use some updating and at least one more round of editing; though few and far between, there are some embarrassing mistakes to be found. Page 25 mentions "Warcraft: Diablo," and page 242 reverses the name of a popular mod by referring to "Condition Zero: Counter Strike." Other errors are more egregious: page 138 talks about Dungeon Siege 2, slated for a 2004 release, but page 142 tells us that the same game is "not confirmed by the company at the time of this writing." Later, the reader is invited to "peruse Namco's 2002 lineup at www.namco.com"; if Namco still has their 2002 lineup online, they're in trouble. And page 155 tells us that Everquest is "something 400,000 people enjoy almost daily [and for $10 a month!]" while the very next page contains a caption about the same game informing us that "(m)ore than 450,000 gamers are paying $13 a month ..." At that rate, by the time you finish paging through the book, everyone in the world will be paying $1500 a month to play Everquest. Which I guess isn't so inconceivable, come to think of it.

It's also worth mentioning the Cover, Table of Contents and Index here, all of which are poorly organized. The cover is an awful purple mess which lists a number of the interviewees, a list which continues on into the inside front cover of the book. The Table of Contents then gives us more lists of names, showing us who's interviewed in each chapter. Two pages later we are presented with yet another two-page list of the same names. We're 23 pages in and we've seen the list three times. This might be excusable if the Table of Contents was at all helpful, but it's not. Every sub-sub-sub-section of the book is listed; in case you were wondering what page the blank User Interface Detail #2 entry of the Master Design Document Template was on, it's page 225.

Then, of course, there's the 34-page long Index, which includes entries for each interviewee as well as topical entries followed by lists of interviewees in each chapter. Just in case it wasn't confusing enough, the individual interviewee names are organized alphabetically by last name, but their entries under each topic are alphabetized by their first name. And for added fun, how about the fact that the interviews within each chapter are not presented alphabetically at all (either by first name or last)? In sum, there are some 60 pages of the book -- nearly 10 percent -- devoted to repeated lists of names organized differently each time.

Conclusions

In the Introduction, Saltzman points out that this book is an extension and expansion of the popular and commercially successful Game Design: Secrets of the Sages. I've not read that book, but I can't help but think that perhaps an expansion was not the best idea. In some cases, less is more, and this book, while interesting, helpful and at times enlightening, really would have been a whole lot more with a whole lot less of some things. Removing unnecessary banter, unhelpful Table of Contents and Index entries, the ubiquitous page cross-references and some completely useless photographs would make this book 100 pages lighter and a lot more worth reading.

As it stands, the book is worth a look only if you're really interested in what these "gods of gaming" have to say about the industry, or you just want some light reading material to round out your collection. It's fun to hear Scott Miller trash Lara Croft as having "a generic, valueless name that says nothing about her personality" just a few pages before Toby Gard talks about her in glowing terms, but is it helpful? To borrow a Fark tag: Unlikely.

If you're looking for information on how to get into the industry, or any insights into designing and developing better games, there are better books out there, including some others by New Riders (helpfully referenced at the back of this book) which are more focused and better structured. And if you're looking for a magic-bullet solution to landing an industry job, you're not going to find it in here (if anywhere at all). When you boil down the advice in the book and pick out the few things these 150 experts agree on, it comes down to this: go to college, practice your skills, take a job in QA or testing to get your feet in the door, and play lots of games. Outside of that, whatever works for you is what will work for you.

Ultimately, the best piece of advice in the book comes in an anecdote about Nintendo's Shigeru Miyamoto, who signed a fan's Nintendo Power Magazine with the following advice: "To Jeremie, Play Outside on Sunny Days, Shigeru Miyamoto."

You can purchase Game Creation and Careers: Insider Secrets from Industry Experts from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Aeonite (Michael Fiegel) writes "The back cover of Game Creation and Careers says "Reading this book is like being at a round-table discussion with more than 150 of the video game industry's most successful designers, developers and publishers." In fact, it's exactly like that, for better and for worse. Mostly worse." Read on for the rest of Fiegel's lengthy review. Game Creation and Careers: Insider Secrets from Industry Experts author Marc Saltzman pages 744 publisher New Riders rating 4 reviewer Michael Fiegel ISBN 0735713677 summary A poorly organized series of interviews with industry-leading game designers.

Structurally, the main section of the book is broken up into four parts. Part 1 is devoted to Pre-Production, and includes chapters on Game Genres and Player Perspective, General Game Design, and the like. Part 2 is devoted to Production, with chapters on Programming Theory, AI, Game Art and Animation, User-Interface and Game Control, Sound Engineering and Music and Gaming. Part 3 takes a look at Post-Production, with information about Proper Game Testing, Tech Support and Public Relations/Marketing. Part 4, titled "How to Make it Happen," discusses DIY Shareware solutions, Breaking into the Industry, Agents and Headhunters, Design Schools, Internet resources, Conventions and Awards.

The book closes with an Appendix that includes biographies of more than 80 of the interviewees featured in the book. These are interesting but somewhat uneven: some of the artist bios are single paragraphs, while others (such as Don Bluth's) run to two pages long; some of the bios are little more than bulleted lists of games worked on, while others talk about future plans; and of course, one wonders why, if the book features more than 150 interviewees, why did nearly half of them not bother with a bio?

Words of the Prophets

The bulk of the book is devoted to material gleaned from interviews with game industry professionals. None of these is presented as its original whole; rather, bits from each are cut and pasted around, so American McGee's comments about Action Game Design, Game Industry Jobs and Storyboards are all located within the (usually) relevant chapters, rather than being presented as a whole, continuous interview.

I say "usually," because there are some rather questionable decisions made about where to place chunks of information. For example, much of the information in Chapters 15 and 16, which cover Sound Engineering and Music and Games respectively, is instead about breaking into the industry, which belongs in Chapter 21. Chapter 6 (which discusses, in part, Creating Characters) has a Note that says "See Chapter 13, 'Game Art and Animation,' for a discussion from legendary Hollywood animator Don Bluth on how to create a successful game character..." One wonders why, if it's relevant to this chapter, why it's not right here. Earlier, Chapter 5 contains a chunk of text about User Interface Design, even though Chapter 14 is supposed to be about UI Design (and in fact, this text refers to the later chapter before giving the advice). And in Chapter 5, there's a section in Gordon Walton's interview about breaking into the industry, which closes by saying "For more on breaking into the industry, sink your teeth into the meaty Chapter 21!"

Whether these were in-person or e-mail interviews is never clear, but they're all a little uneven, with some relating personal stories and others reciting information verbatim from company websites. Taken individually, many of these interviews are filled with interesting tidbits, insightful commentary and quirky bits of trivia which are worth reading. However, a good deal of the advice is not at all helpful or insightful, except perhaps superficially. For example, here are Yu Suzuki's thoughts on what separates a great game from a good game:

1. Passion.
2. Never give up.
3. Create a game carefully, thinking about the people who will play it.

Certainly good advice for creating a game. Or, with some word substitution, for writing a book, or flying a plane, or developing a cure for cancer, or becoming a Jedi Master. I think Yoda said it better: "Do, or do not. There is no try."

Much of the "advice" throughout the book is like this -- vague and meandering, and only peripherally relevant to game design. It's tempting to read the words of the designers within as if they were carved in some holy rock on the summit of Mount Radeon, but the fact is that when you look past the aura you get the impression that a lot of what they have to say is nothing but common sense. And with the way the book presents their interview excerpts their advice often comes across as, well, less than inspirational:

• Todd Howard on UI design: "Interface is everything. It's the player's way of using the game."
• Richard "Lord British" Garriott on MMORPGs: "Hire experienced personnel."
• Kevin Cloud on becoming a game artist: "You can't learn to be a computer artist unless you spend time on a computer."
• Thomas Warfield on shareware game design: "Make a good game that's fun to play."

I don't know too many people who would intentionally design a bad game that's awful to play by designing a crappy interface with inexperienced personnel without using any computers. But maybe it's just me.

Too Many Cooks

By far the most frustrating aspect of the book is the one I alluded to in my opening paragraph. Namely, that "too many cooks spoil the broth," as goes the old saying. In each chapter, advice from up to two dozen designers is presented, and in many cases one piece of advice contradicts another. In fact, in the few cases where such advice is in agreement, the author feels inclined to point it out, as on page 43, where he tells us, of Scott Miller, "Notice how closely his comments resemble George Broussard's advice? Now that's focus!" In fact, Saltzman addresses the issue himself in the opening to Chapter 14 by saying "...it's likely that you'll find some conflicting advice in areas of this book on art techniques, level design suggestions, or the best way to animate a character..." That's putting it mildly.

"Asked about the importance of design documents," says the author, "(David) Perry directly contradicts Lorne Lanning and others." He does not, however, tell us who to listen to. Nor does he tell us what to think when Ragnar Tornquist contradicts himself with "I said earlier to avoid clichés and stereotypes, but sometimes clichés and stereotypes are great ways to establish a character immediately." Later, John Slagel, asked about job-seeking, says "Don't go through a recruiter," and the author is quick to remind us that "the folks in Chapter 22, 'Game Agents and Headhunters,' may disagree!" On page 386, Greg Thomas tells us that, when it comes to game art, "It's better to make the model simpler at first and continue to add details until the limits are reached," but on page 387 Todd Howard says "Aim high... it's easier to scale down than up later on."

So do you listen to the game designer on page X who says one thing, or do you listen to the contradictory advice on page X+1? Higher or lower? Recruiter or on your own? Design document or not? Red pill or blue pill? Left or right? Up or down? The book leaves all that for the reader to decide, which raises the question: what's the point? It's difficult to understand the true intent of a book which presents such a diverse range of opinions on the topic of game design, except perhaps as an amusing diversion from actually designing games. In order to use this book as a guide to game design, one must inevitably choose which advice to follow. And as presented, that's an impossibility.

This all comes to a head in Chapter 21, "Breaking Into the Industry." "Find a job, any job," says one designer, while another says you should get a Master's degree first. Scott Miller says "with all the ideas that have been sent to me (hundreds), I've yet to see one that's worthy of turning into a game," and Sid Meier says putting together a playable demo and shopping it around is the way to go, and then Minh Le says that building a mod for an existing game is the best route to success. What all this boils down to is this: these people are not telling you what will work for you. Rather, they are telling you what worked for them. Everyone's story is different. Every path to success is different. Even the recruiters themselves disagree in Chapter 22. Melanie Cambron says "...at the early stages of one's career, using recruiting services is not the best approach," but two pages later Jeff Brunner's interview "...explains why a budding artist, programmer or game designer should consider using the services of a recruiting agency." Admittedly, this latter comment comes in the author's own words, which leads me to my next subject.

Wowza

In a book which basically amounts to a series of interviews, the author's voice repeatedly pops up with interjections-cum-interruptions that are annoying, repetitive, and just plain unnecessary. Sometimes it's a throwaway phrase, at other times just a word, but it's always a speed bump in the experience. For example, in his introduction to the book (titled, in unnecessarily casual fashion, "So, You Wanna Make Games For A Living, Huh?"), Saltzman says "... it's no wonder why the video game industry has broken the $10 billion dollar-a-year mark in the U.S. alone, which is significantly more than the revenues generated from movie box office receipts. Wowza." Wowza?

Later, Saltzman tells us to turn to Chapter 21 to read about "...breaking into 'da biz.' Whew!" On numerous occasions, he invites the reader to "pull up a chair," just in case you were reading the book while skipping rope. In Chapter 14 the reader is invited (or perhaps commanded?) to "Enjoy the following paragraphs." And page 247 cheerfully chirps "Pencils in hand?" before listing five points about Level Design. Why would we need to take notes with a pencil when the book has the notes already printed? These are obviously attempts to insert some lighthearted banter into the book, and in some places they do help to provide transitions between thoughts, but in my opinion they're nothing but an indication that the author has misjudged his audience. If they're meant to be ignored, then they shouldn't be there, and if they're truly meant to be read, then, well ... they still shouldn't be there. These little interjections come across as little more than the author jumping up and down at our round-table discussion, shouting "Don't forget me! I'm over here" or else "Don't forget about this other stuff! It's over there."

It is this latter tendency is the largest issue I have with the author's comments, in that most of them are redundant and unnecessary attempts to explain the obvious or refer to other sections of the book. From the introduction to Chapter 2, "General Game Design: Action/Arcade Games," comes this helpful tidbit:

"This chapter features designers from the action/arcade category. Chapter 3, 'General Game Design: Strategy Games,' delves into the strategy game genre. Here we go!"

Each section and interview constantly reminds us of other chapters and sections that we might want to read, like one of those old Choose Your Own Adventure Books. At the end of a section on game design in Chapter 2, we are reminded to go to Chapter 6 to read more about characters. In Chapter 6, we are encouraged to read not only about breaking into the industry in Chapter 21, but also about game design in Chapter 2. Page 187 of Chapter 6 invites the reader to "(f)ling yourself back to Chapter 2." What, right now?

This reaches its climax in Chapter 5 with "For more from the vocal Chris Taylor, jump to Chapters 6, 17 and 21. Whew!" Whew, indeed; which do we choose? Back and forth, back and forth, every page referring to another two pages. Perhaps this is meant to replicate a hyperlinked web page, or to encourage reading the book out of sequence, but in the end it merely comes across as schizophrenic and eminently unhelpful, as in this gem from Chapter 3: "In Chapter 21, 'Breaking Into the Industry,' Bill Roper offers some advice on breaking into the industry." Or how about the first sentence in Chapter 10: "Chapter 8, "Level Design," dealt with level design ..."

You think?

Also sprinkled haphazardly throughout the book are "Notes," which in theory are supposed to explain something but generally tell us nothing relevant. In many cases, the Note does little more than refer us to another chapter, as with the cross references above. An interview with Richard "Levelord" Gray in Chapter 8 mentions John Romero's interview in Chapter 20 for no apparent reason. An interview with Joel Jewett in Chapter 21, "Breaking Into the Industry", closes with a Note that Noah Falstein has more to say about breaking into the industry in Chapter 6; if it's relevant to the current chapter, why is it not in the current chapter? Most egregious, perhaps, is the Note which leads off Chapter 16, "Music and Games", informing us that we should turn back to Chapter 15 to read about Sound Engineering. But we were just there! In fact, later in Chapter 16 an interview excerpt with George "The Fat Man" Sanger leads off with the words "In Chapter 15," and ends with the words "See Chapter 15!"

OK, we get the point -- you like Chapter 15!

The Bad and The Ugly

Graphically, the book is quite unimpressive. The book's black-and-white printing turns the majority of the photographs into ugly blotches that do little to illustrate anything. For example, page 74 features a drab grayscale illustration from Age of Mythology, amusingly captioned with "Talk about gorgeous graphics!" Elsewhere, screencaps from The Sims contain illegible dialogue, images from Red Faction are indecipherable, and a bewildering photo of a parking lot on page 592 adds a certain je ne sais quoi. None of it is pretty.

There are also a few photos of the designers themselves, which range from the typical ("here's me in front of a computer") to the arrogant ("here's me holding a gun next to two hot chicks") to the silly ("here's me in a bunny suit"). Most of these have nothing to do with the text, the book, or anything at all that I can think of. A picture of George "The Fat Man" Sanger is accompanied by a caption informing us that the snakes on his suit were all hand-embroidered. Objection, your honor -- how is this relevant?

Relevance is also a big problem with the artwork; as in, there mostly isn't any to speak of. In but a few cases is the art both appropriate to the text as well as interesting and/or useful (as with the sketches from Twisted Metal: Black on page 35). Some of the artwork is obvious promotional art, as when a pre-rendered still from Diablo II is passed off as a shot from the game, and some of it is merely irrelevant to the text it accompanies, as when two stills of Oddworld's Abe accompany text that talks about how unique his friend Munch is. Later, two random shots from Unreal are dropped in with a caption discussing puzzle design in the middle of a chapter on level design. Then a discussion about User Interface design is accompanied by two shots from The Sims, bereft of any sign of its pie menu interface, the only thing that would have made the images relevant. In Chapter 21, "Breaking Into the Industry," what will you find stuck in between interviews with Donny Thorley of Day 1 Studios and Dave Davis of Electronic Arts? Inexplicably, four screenshots from Rockstar's Grand Theft Auto, Vice City, and a caption that talks about Chapter 19, "Public Relations and Marketing."

The book could also use some updating and at least one more round of editing; though few and far between, there are some embarrassing mistakes to be found. Page 25 mentions "Warcraft: Diablo," and page 242 reverses the name of a popular mod by referring to "Condition Zero: Counter Strike." Other errors are more egregious: page 138 talks about Dungeon Siege 2, slated for a 2004 release, but page 142 tells us that the same game is "not confirmed by the company at the time of this writing." Later, the reader is invited to "peruse Namco's 2002 lineup at www.namco.com"; if Namco still has their 2002 lineup online, they're in trouble. And page 155 tells us that Everquest is "something 400,000 people enjoy almost daily [and for $10 a month!]" while the very next page contains a caption about the same game informing us that "(m)ore than 450,000 gamers are paying $13 a month ..." At that rate, by the time you finish paging through the book, everyone in the world will be paying $1500 a month to play Everquest. Which I guess isn't so inconceivable, come to think of it.

It's also worth mentioning the Cover, Table of Contents and Index here, all of which are poorly organized. The cover is an awful purple mess which lists a number of the interviewees, a list which continues on into the inside front cover of the book. The Table of Contents then gives us more lists of names, showing us who's interviewed in each chapter. Two pages later we are presented with yet another two-page list of the same names. We're 23 pages in and we've seen the list three times. This might be excusable if the Table of Contents was at all helpful, but it's not. Every sub-sub-sub-section of the book is listed; in case you were wondering what page the blank User Interface Detail #2 entry of the Master Design Document Template was on, it's page 225.

Then, of course, there's the 34-page long Index, which includes entries for each interviewee as well as topical entries followed by lists of interviewees in each chapter. Just in case it wasn't confusing enough, the individual interviewee names are organized alphabetically by last name, but their entries under each topic are alphabetized by their first name. And for added fun, how about the fact that the interviews within each chapter are not presented alphabetically at all (either by first name or last)? In sum, there are some 60 pages of the book -- nearly 10 percent -- devoted to repeated lists of names organized differently each time.

Conclusions

In the Introduction, Saltzman points out that this book is an extension and expansion of the popular and commercially successful Game Design: Secrets of the Sages. I've not read that book, but I can't help but think that perhaps an expansion was not the best idea. In some cases, less is more, and this book, while interesting, helpful and at times enlightening, really would have been a whole lot more with a whole lot less of some things. Removing unnecessary banter, unhelpful Table of Contents and Index entries, the ubiquitous page cross-references and some completely useless photographs would make this book 100 pages lighter and a lot more worth reading.

As it stands, the book is worth a look only if you're really interested in what these "gods of gaming" have to say about the industry, or you just want some light reading material to round out your collection. It's fun to hear Scott Miller trash Lara Croft as having "a generic, valueless name that says nothing about her personality" just a few pages before Toby Gard talks about her in glowing terms, but is it helpful? To borrow a Fark tag: Unlikely.

If you're looking for information on how to get into the industry, or any insights into designing and developing better games, there are better books out there, including some others by New Riders (helpfully referenced at the back of this book) which are more focused and better structured. And if you're looking for a magic-bullet solution to landing an industry job, you're not going to find it in here (if anywhere at all). When you boil down the advice in the book and pick out the few things these 150 experts agree on, it comes down to this: go to college, practice your skills, take a job in QA or testing to get your feet in the door, and play lots of games. Outside of that, whatever works for you is what will work for you.

Ultimately, the best piece of advice in the book comes in an anecdote about Nintendo's Shigeru Miyamoto, who signed a fan's Nintendo Power Magazine with the following advice: "To Jeremie, Play Outside on Sunny Days, Shigeru Miyamoto."

You can purchase Game Creation and Careers: Insider Secrets from Industry Experts from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

objectboy writes with a review of Chris Fehily's SQL: Visual QuickStart Guide, writing "This book teaches ANSI SQL-92 programming to database beginners and intermediates. The publisher, Peachpit Press, publishes mostly end-user and novice titles that usually go unnoticed by professional programmers. Its Perl and PHP books, for example, are of little practical or tutorial use to an experienced developer. In fact, I noticed this SQL book only because a junior developer was using it for a course. The book's table of contents, index, and a sample chapter are posted on Amazon.com. The book's official web site contains errata and other information." Objectboy's review continues below. SQL: Visual QuickStart Guide author Chris Fehily pages 424 publisher Peachpit Press rating 9/10 reviewer objectboy ISBN 0321118030 summary A lucid SQL tutorial and professional reference

What this book does right: The myth that it's more important for a programming book to be technically accurate than well written endures even though the opposite situation is true: A lucid explanation of a difficult concept or clever algorithm is more valuable than a bug-free implementation of same.

Consider Ken Henderson's The Guru's Guide to Transact-SQL , a book full of useful examples but so marred by the author's bloated style and disrespect for the language that I cringe every time I'm forced to read the text rather than simply lift a code snippet. Henderson even goes so far as to include an introductory section, titled "On Formality," about how he is going to split infinitives (even though their syntax is a burden for the brain to parse) and how he is going to use "data" in the singular sense (even though doing so can cause confusion) and how he considers "record," "row", and "tuple" to be interchangeable terms (even though they're not) and on and on. Readers would be aghast to find such self-exculpatory nonsense in the pages of Donald Knuth or Patrick Henry Winston. As for SQL: Visual QuickStart Guide, the author, a statistical programmer, presents each topic with a mathematician's sense of restraint and order. I've found few typos, no technical errors, and consistent use of technical terms.

Almost every aspect of SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, and DROP is covered. What distinguishes this book is that every ANSI SQL statement -- and there are hundreds of examples -- was tested on six separate DBMSes: Microsoft Access 2002, Microsoft SQL Server 2000, MySQL 4.0, PostgreSQL 7.1, Oracle 8i, and Oracle 9i (8i and 9i differ considerably in SQL-92 compliance). The examples in each section increase in depth and complexity, so you can stop reading once you've learned what you need to know. When an ANSI SQL statement doesn't work as-is on a particular DBMS, the author shows you how to fix it or offers workarounds (which is particularly useful for MySQL, whose adherence to the SQL standard is poor). These DBMS-specific fixes are given as separate "DBMS Tips" apart from the main body of text, so they don't interfere with the conceptual flow. This organization is especially useful for consultants who have difficulty keeping track of how each implementation deviates from the ANSI standard, and is superior to the alphabetical, segregated approach of O'Reilly's SQL in a Nutshell.

This book was shoehorned into the publisher's Visual QuickStart format, which, as I implied earlier, doesn't work well for procedural languages, but does work for a declarative language like SQL. A two-column layout separates examples from explanatory text. Red type highlights the relevant portions of code and results. The book is extensively cross-referenced and has an 18-page index. This layout also makes the book a good quick reference for experienced programmers. Almost all the examples use a single, sample database (so there's no need to memorize multiple schemas). The code listings and sample database are available for download.

The derivative nature of programming books makes it difficult to determine whether the author truly has mastered the material. Writing a book is a difficult task (perhaps even harder than programming) but, at the risk of exaggerating my point, I suspect that any determined, organized, and competent programmer could write any O'Reilly Nutshell book by paraphrasing existing materials. But if an author establishes his credentials early, the reader gains a sense of trust that remains throughout the entire book. In the introduction to this book, the author avoids an error that almost every other SQL-book author commits: that SQL stands for structured query language. According to ANSI (the only legitimate arbiter here), it stands for S-Q-L and nothing more. Fehily even offers an amusing explanation of why structured query language is the worst possible description of SQL. Throughout the book, the author also scatters bits of practical advice (job candidates are wise to say my-es-kyu-el, not my-sequel), beginner-friendly insights ("Although SELECT is powerful, it's not dangerous: You can't use it add, change, or delete data or database objects."), and advanced topics (optimization, concurrency control, logical data independence). It is these asides and respect for basic research, rather than swaths of expository text, that lend authority.

This book describes the effects of nulls in almost every aspect of SQL, including the interpretation of null-contaminated query results. You can no more be a competent SQL programmer without understanding nulls than you can be a competent LISP programmer without understanding recursion. Particularly useful are the discussion of three-value logic (true/false/unknown) and an algebraic derivation of how a null can cause a subquery to return an empty result unexpectedly (which has bitten me more than once).

As a wizened developer weary of hand-holding users and junior programmers through routine queries, I've found it mollifying to give away copies of this book (it's cheap) to reduce my interrupt stack.

What's Missing: Some missing items that I would have found useful:

• A glossary
• A quick syntax reference
• A chapter about statistics
• A chapter about advanced SQL "tricks"
• DB2 coverage
• Coverage of security commands (GRANT/REVOKE)
• An expanded query-optimization discussion
• Improved normalization examples
• A little more mathematical rigor in the set-theory discussion

You can purchase SQL: Visual QuickStart Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

objectboy writes with a review of Chris Fehily's SQL: Visual QuickStart Guide, writing "This book teaches ANSI SQL-92 programming to database beginners and intermediates. The publisher, Peachpit Press, publishes mostly end-user and novice titles that usually go unnoticed by professional programmers. Its Perl and PHP books, for example, are of little practical or tutorial use to an experienced developer. In fact, I noticed this SQL book only because a junior developer was using it for a course. The book's table of contents, index, and a sample chapter are posted on Amazon.com. The book's official web site contains errata and other information." Objectboy's review continues below. SQL: Visual QuickStart Guide author Chris Fehily pages 424 publisher Peachpit Press rating 9/10 reviewer objectboy ISBN 0321118030 summary A lucid SQL tutorial and professional reference

What this book does right: The myth that it's more important for a programming book to be technically accurate than well written endures even though the opposite situation is true: A lucid explanation of a difficult concept or clever algorithm is more valuable than a bug-free implementation of same.

Consider Ken Henderson's The Guru's Guide to Transact-SQL , a book full of useful examples but so marred by the author's bloated style and disrespect for the language that I cringe every time I'm forced to read the text rather than simply lift a code snippet. Henderson even goes so far as to include an introductory section, titled "On Formality," about how he is going to split infinitives (even though their syntax is a burden for the brain to parse) and how he is going to use "data" in the singular sense (even though doing so can cause confusion) and how he considers "record," "row", and "tuple" to be interchangeable terms (even though they're not) and on and on. Readers would be aghast to find such self-exculpatory nonsense in the pages of Donald Knuth or Patrick Henry Winston. As for SQL: Visual QuickStart Guide, the author, a statistical programmer, presents each topic with a mathematician's sense of restraint and order. I've found few typos, no technical errors, and consistent use of technical terms.

Almost every aspect of SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, and DROP is covered. What distinguishes this book is that every ANSI SQL statement -- and there are hundreds of examples -- was tested on six separate DBMSes: Microsoft Access 2002, Microsoft SQL Server 2000, MySQL 4.0, PostgreSQL 7.1, Oracle 8i, and Oracle 9i (8i and 9i differ considerably in SQL-92 compliance). The examples in each section increase in depth and complexity, so you can stop reading once you've learned what you need to know. When an ANSI SQL statement doesn't work as-is on a particular DBMS, the author shows you how to fix it or offers workarounds (which is particularly useful for MySQL, whose adherence to the SQL standard is poor). These DBMS-specific fixes are given as separate "DBMS Tips" apart from the main body of text, so they don't interfere with the conceptual flow. This organization is especially useful for consultants who have difficulty keeping track of how each implementation deviates from the ANSI standard, and is superior to the alphabetical, segregated approach of O'Reilly's SQL in a Nutshell.

This book was shoehorned into the publisher's Visual QuickStart format, which, as I implied earlier, doesn't work well for procedural languages, but does work for a declarative language like SQL. A two-column layout separates examples from explanatory text. Red type highlights the relevant portions of code and results. The book is extensively cross-referenced and has an 18-page index. This layout also makes the book a good quick reference for experienced programmers. Almost all the examples use a single, sample database (so there's no need to memorize multiple schemas). The code listings and sample database are available for download.

The derivative nature of programming books makes it difficult to determine whether the author truly has mastered the material. Writing a book is a difficult task (perhaps even harder than programming) but, at the risk of exaggerating my point, I suspect that any determined, organized, and competent programmer could write any O'Reilly Nutshell book by paraphrasing existing materials. But if an author establishes his credentials early, the reader gains a sense of trust that remains throughout the entire book. In the introduction to this book, the author avoids an error that almost every other SQL-book author commits: that SQL stands for structured query language. According to ANSI (the only legitimate arbiter here), it stands for S-Q-L and nothing more. Fehily even offers an amusing explanation of why structured query language is the worst possible description of SQL. Throughout the book, the author also scatters bits of practical advice (job candidates are wise to say my-es-kyu-el, not my-sequel), beginner-friendly insights ("Although SELECT is powerful, it's not dangerous: You can't use it add, change, or delete data or database objects."), and advanced topics (optimization, concurrency control, logical data independence). It is these asides and respect for basic research, rather than swaths of expository text, that lend authority.

This book describes the effects of nulls in almost every aspect of SQL, including the interpretation of null-contaminated query results. You can no more be a competent SQL programmer without understanding nulls than you can be a competent LISP programmer without understanding recursion. Particularly useful are the discussion of three-value logic (true/false/unknown) and an algebraic derivation of how a null can cause a subquery to return an empty result unexpectedly (which has bitten me more than once).

As a wizened developer weary of hand-holding users and junior programmers through routine queries, I've found it mollifying to give away copies of this book (it's cheap) to reduce my interrupt stack.

What's Missing: Some missing items that I would have found useful:

• A glossary
• A quick syntax reference
• A chapter about statistics
• A chapter about advanced SQL "tricks"
• DB2 coverage
• Coverage of security commands (GRANT/REVOKE)
• An expanded query-optimization discussion
• Improved normalization examples
• A little more mathematical rigor in the set-theory discussion

You can purchase SQL: Visual QuickStart Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

objectboy writes with a review of Chris Fehily's SQL: Visual QuickStart Guide, writing "This book teaches ANSI SQL-92 programming to database beginners and intermediates. The publisher, Peachpit Press, publishes mostly end-user and novice titles that usually go unnoticed by professional programmers. Its Perl and PHP books, for example, are of little practical or tutorial use to an experienced developer. In fact, I noticed this SQL book only because a junior developer was using it for a course. The book's table of contents, index, and a sample chapter are posted on Amazon.com. The book's official web site contains errata and other information." Objectboy's review continues below. SQL: Visual QuickStart Guide author Chris Fehily pages 424 publisher Peachpit Press rating 9/10 reviewer objectboy ISBN 0321118030 summary A lucid SQL tutorial and professional reference

What this book does right: The myth that it's more important for a programming book to be technically accurate than well written endures even though the opposite situation is true: A lucid explanation of a difficult concept or clever algorithm is more valuable than a bug-free implementation of same.

Consider Ken Henderson's The Guru's Guide to Transact-SQL , a book full of useful examples but so marred by the author's bloated style and disrespect for the language that I cringe every time I'm forced to read the text rather than simply lift a code snippet. Henderson even goes so far as to include an introductory section, titled "On Formality," about how he is going to split infinitives (even though their syntax is a burden for the brain to parse) and how he is going to use "data" in the singular sense (even though doing so can cause confusion) and how he considers "record," "row", and "tuple" to be interchangeable terms (even though they're not) and on and on. Readers would be aghast to find such self-exculpatory nonsense in the pages of Donald Knuth or Patrick Henry Winston. As for SQL: Visual QuickStart Guide, the author, a statistical programmer, presents each topic with a mathematician's sense of restraint and order. I've found few typos, no technical errors, and consistent use of technical terms.

Almost every aspect of SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, and DROP is covered. What distinguishes this book is that every ANSI SQL statement -- and there are hundreds of examples -- was tested on six separate DBMSes: Microsoft Access 2002, Microsoft SQL Server 2000, MySQL 4.0, PostgreSQL 7.1, Oracle 8i, and Oracle 9i (8i and 9i differ considerably in SQL-92 compliance). The examples in each section increase in depth and complexity, so you can stop reading once you've learned what you need to know. When an ANSI SQL statement doesn't work as-is on a particular DBMS, the author shows you how to fix it or offers workarounds (which is particularly useful for MySQL, whose adherence to the SQL standard is poor). These DBMS-specific fixes are given as separate "DBMS Tips" apart from the main body of text, so they don't interfere with the conceptual flow. This organization is especially useful for consultants who have difficulty keeping track of how each implementation deviates from the ANSI standard, and is superior to the alphabetical, segregated approach of O'Reilly's SQL in a Nutshell.

This book was shoehorned into the publisher's Visual QuickStart format, which, as I implied earlier, doesn't work well for procedural languages, but does work for a declarative language like SQL. A two-column layout separates examples from explanatory text. Red type highlights the relevant portions of code and results. The book is extensively cross-referenced and has an 18-page index. This layout also makes the book a good quick reference for experienced programmers. Almost all the examples use a single, sample database (so there's no need to memorize multiple schemas). The code listings and sample database are available for download.

The derivative nature of programming books makes it difficult to determine whether the author truly has mastered the material. Writing a book is a difficult task (perhaps even harder than programming) but, at the risk of exaggerating my point, I suspect that any determined, organized, and competent programmer could write any O'Reilly Nutshell book by paraphrasing existing materials. But if an author establishes his credentials early, the reader gains a sense of trust that remains throughout the entire book. In the introduction to this book, the author avoids an error that almost every other SQL-book author commits: that SQL stands for structured query language. According to ANSI (the only legitimate arbiter here), it stands for S-Q-L and nothing more. Fehily even offers an amusing explanation of why structured query language is the worst possible description of SQL. Throughout the book, the author also scatters bits of practical advice (job candidates are wise to say my-es-kyu-el, not my-sequel), beginner-friendly insights ("Although SELECT is powerful, it's not dangerous: You can't use it add, change, or delete data or database objects."), and advanced topics (optimization, concurrency control, logical data independence). It is these asides and respect for basic research, rather than swaths of expository text, that lend authority.

This book describes the effects of nulls in almost every aspect of SQL, including the interpretation of null-contaminated query results. You can no more be a competent SQL programmer without understanding nulls than you can be a competent LISP programmer without understanding recursion. Particularly useful are the discussion of three-value logic (true/false/unknown) and an algebraic derivation of how a null can cause a subquery to return an empty result unexpectedly (which has bitten me more than once).

As a wizened developer weary of hand-holding users and junior programmers through routine queries, I've found it mollifying to give away copies of this book (it's cheap) to reduce my interrupt stack.

What's Missing: Some missing items that I would have found useful:

• A glossary
• A quick syntax reference
• A chapter about statistics
• A chapter about advanced SQL "tricks"
• DB2 coverage
• Coverage of security commands (GRANT/REVOKE)
• An expanded query-optimization discussion
• Improved normalization examples
• A little more mathematical rigor in the set-theory discussion

You can purchase SQL: Visual QuickStart Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.