Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Image

Game Design: A Practical Approach 85

Aeonite writes "As the title suggests, Game Design: A Practical Approach presents a practical approach to game design — one that is almost too practical in places. The book does a good job of covering many of the foundational elements of game design (called "atoms" by the author), but in places the level of practical detail — and the heavy focus on Lua code examples — is a bit hard to work through. Readers allergic to code may find themselves skipping over swaths of text instead of actually reading it." Read below for the rest of Michael's review.
Game Design: A Practical Approach
author Paul Schuytema
pages 416
publisher Charles River Media
rating 6
reviewer Michael Fiegel
ISBN 978-1-58450-471-9
summary A practical, often code-heavy guide to game design
Schuytema is a game industry veteran, perhaps best known for having worked on the original incarnation of Prey back in 1998 or thereabouts. These days it seems he's employed by the University of Illinois as an Extension Specialist, and it certainly seems to have rubbed off on him, as the book is written in a very scholarly, textbook-like fashion. The preface speaks of "foundational information," and while the exciting parts of working in the game industry are mentioned as well, generally the book's subtitle ("A Practical Approach") is precisely what you get.

The book is broken into three parts. The first, the aptly (and practically) named "Introduction to Game Design," consists of six chapters, covering the basic foundational elements of game design, game design documents, coding tools and the like. The advice in the first four chapters, in particular, comes across as a bit too practical, if not downright pedantic, as the author discusses things like listening, taking notes, and reading. In chapter 4 the author even covers the merits of breathing properly, getting enough sleep and not eating junk food (good luck encouraging that at a game company; we lived on Reese's Peanut Butter Cups at Perpetual Entertainment). One wonders if the current generation of whippersnappers, just entering the industry, really needs to be told to get a good night's sleep; if so, we're in for some interesting games over the next few decades.

Some of the advice here is genuinely useful and interesting, such as methods for helping inspire creative thought, brainstorming and developing memory. Chapters 5 and 6 are also more relevant to game design; the former covers game design documents, pitch docs, functional specifications, and the like, and is one of the tightest and most useful chapters in the book. Chapter 6 then dives headlong into the Lua scripting language, which is where the book's focus on game design sort of drifts sideways into the realm of game development. From this point on, the book is sporadically riddled with code examples, references to the example game on the included CD, and detailed explanations of variables, operators, functions and control structures. This is useful, if dry, but it seems to be directed more at the indie "casual game" industry where game designer, game programmer, game artist, game writer, and game publisher are all the same person.

The second part of the book, "Game Design Theory," covers high level design concepts broken down into what the author calls "game atoms". Examples include things like: having a clear goal for the player; providing subvictories to the player; allowing the player to affect the game world; making the context of the game understandable to the player; and so on. These are insightful, and easy to understand and digest, and were the entire book filled with nothing but these I would find it all the more valuable. Sadly, this section is also the shortest in the book (spanning just over 50 pages), and although later chapters in this section do manage to dive into things like player perceptions and challenges, I find myself wanting more. In covering the concept of game "flow" and losing oneself in the moment, the section does earn geek points for citing Mihaly Csikszentmihalyi, whose name looks like catlike typing should have been detected. But I digress.

Part 3, approximately half of the book, is devoted to "Real-World Game Design," which moves away from "theatrical underpinnings" and into more (you guessed it) "practical" issues. Here, specific "atoms" such as UI, inventory, power-ups, puzzles, conflicts, and the like are covered in some depth, each presented with code to show how the relevant "atom" might be programmed (examples taken from the sandbox game named Eye Opener, included on the accompanying CD). In places the density of code calls to mind the BASIC game programming books I owned in the late '80s, where if I had 6 hours to type I could make a rocket blast off the top of my Apple IIe monitor. In fact, one of the most interesting comments is on page 336 where the author discusses early games on the Apple II, where "(r)eplay of the game meant going for higher scores, since a single pass through the game was maybe 20 minutes tops." Schuytema speaks as if these are games from a bygone era, but it seems to me he's basically describing the modern casual game, of which there are many, many thousands in the wild. Much of the latter material, alas, seems to drift back into the realm of the "overly practical," with the author covering storytelling atoms such as outlining, writing, revising, and working with a writer. The final chapter, "Next Steps," then presents the ever popular "how to break into the industry" section, which covers very practical, but again somewhat obvious topics such as going to school, networking, and following game websites.

Each chapter ends with a summary and a series of "Chapter Exercises" that hammer home the feeling that this book is really more of a textbook, complete with homework assignments, rather than a casual read. Even the index is almost TOO complete and practical, with entries for brief, passing mentions of Barnes & Noble and Yahoo!; I was surprised not to find an entry for Mountain Dew, since it's mentioned a few times more often in the text and seems somewhat more relevant to the game industry. The book also offers a number of "from the trenches" sidebars throughout, each featuring veterans espousing on various elements of the game industry. These are interesting and often insightful, but their overall impact is somewhat reduced considering that fully half of them (11 of 22) feature the author himself. It seems that a broader selection of insights and examples from other designers in the industry would have served to balance the book a bit more.

Also worth at least a passing mention is the issue of the postage-stamp-sized images and screenshots that pepper game books these days. Many of the pictures in this book are difficult to make out due to their clarity and size (Figure 1.1 looks like some guys from Home Depot are about to encounter the Blair Witch), but most can be puzzled through. Even then, although they generally have relevance to the subject being discussed they often don't really reinforce the concept at hand in a useful fashion: Figure 3.1 is a picture of a marble notebook and some pencils, as if the book were written in a future time when knowledge of writing materials was lost; Figure 3.4 is captioned "Use your finger as an eye guide..." and contains a picture of a book with a finger on it; Figure 10.3's caption mentions "the samurai sword" weapon in Shadow Warrior, yet the screenshot apparently depicts a grenade launcher. The capper is probably page 194, which is supposed to illustrate multiplayer gaming, but instead (as far as I can tell) depicts two mid-'90s Inside Sales reps playing Solitaire instead of phoning clients. Possibly they are car salesmen; it's not clear.

Warts aside, as a whole Game Design: A Practical Approach covers quite a lot of terrain in quite a useful fashion, and hits all the major foundational points about game design. Though it does contain quite a lot of Lua code, this is admittedly not as irrelevant as it could have been, since Lua is used in a wide assortment of games, from Far Cry to Natural Selection 2, Warhammer Online to The Witcher. The book is a few years old at this point, but it seems that it will remain relevant as long as Lua remains a viable programming language in the game industry. Left-brainers in search of a fairly crunchy and quite practical book about game design AND development (and in particular those who want to design and develop their own games, rather than work for someone else) will be quite happy with the material here. Those right-brainers more comfortable amidst the fluffier bits of the game industry, however, may find themselves checking their watches halfway through the second act.

You can purchase Game Design: A Practical Approach from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

*

This discussion has been archived. No new comments can be posted.

Game Design: A Practical Approach

Comments Filter:
  • by fooslacker ( 961470 ) on Wednesday June 17, 2009 @02:31PM (#28364307)
    There is a common misconception of the programmer as a commodity. Designers are by far the most important resource just as architects and designers are the most important for enterprise apps. That said crappy programmers can destroy a good design just like a bad design can't be coded around. It's akin to designing a sky scraper and getting a bunch of 15th century hut builders to construct it. Designers are imperative but capable programmers are very important as well. The real question is when do you hit a point of diminishing returns for a more expert programmer. To continue the building metaphor you don't need skyscraper builders to build a hut but you'd better not try to build a skyscraper with hut builders.
  • by vlm ( 69642 ) on Wednesday June 17, 2009 @03:27PM (#28365085)

    I don't understand why the author calls the foundational elements of game design atoms.

    I think it's a requirement of buzzword-labels that they either make no sense or dilute the meaning of the original word, or both.

    Book author is hot for Lua. Lua's data structures innards are kind of lisp list-ish and one funny part of the wikipedia article explains that in small part, they invented Lua because lisp's syntax is "too hard". Lisp lists are made of atoms. So, to summarize, author likes Lua, Lua's list innards are lispish, lisp lists are made of atoms.

    The author probably couldn't help himself but to call the individual foundational elements of game design, atoms.

  • by caywen ( 942955 ) on Wednesday June 17, 2009 @03:42PM (#28365275)

    I think in many cases, embedding a scripting engine is overkill. The only scenarios I can think of where it's advantageous are:

    - If your bots/NPC behavior is sophisticated enough that they need their own programs that run concurrently as mini-virtual machines.
    - If your game accepts user generated content, and a simple scripting language becomes an end user feature.
    - If your team indeed is really big and you have non-programmers designing game logic.

    I'm sure there are more, but for more than one project I've worked on, I ended up abandoning scripting altogether because it just wasn't worth the complexity or performance hit.

  • by cowscows ( 103644 ) on Wednesday June 17, 2009 @05:45PM (#28366757) Journal

    Actually getting a building built is way more complicated than either of those two statements. Any complicated building most likely has a good sized team of people working on it. Besides just deciding what the building is going to look like, the architect(s) on the project need to coordinate all of the engineers and consultants (mechanical, structural, landscape, etc.), deal with lots of code/government issues, keep the project within a workable budget, and then make sure the contractor actually builds what was designed.

    Sadly, the way the construction business often works (in the US at least), the relationship between the the contractor and the architect/client is often adversarial, because there are lots of clients who want their building to be built basically for free, and lots of contractors looking trying to squeeze every dollar out of the client.

    But on occasion I've worked on projects where the contractor is involved from the beginning and generally acting in good faith, and there's a real partnership at work. Those projects are usually much more fun.

    I don't remember what my point was. Make sure your kid never decides to be an architect.

One man's constant is another man's variable. -- A.J. Perlis

Working...