[SEPTEMBER] Game Design Workshop by Tracy Fullerton

[Liz England]

This month's reading is Game Design Workshop: A Playcentric Approach by Tracy Fullerton

Author Tracy Fullerton demystifies the creative process with a clear and accessible analysis of the formal and dramatic systems of game design. Examples of popular games, illustrations of design techniques, and refined exercises strengthen your understanding of how game systems function and give you the skills and tools necessary to create a compelling and engaging game.

The book puts you to work prototyping, playtesting, and revising your own games with time-tested methods and tools. It provides you with the foundation to advance your career in any facet of the game industry, including design, producing, programming, and visual design.

(Text from publisher, CRC Press)

There's now three editions but I'm not sure what the differences are. I'll be reading from the third edition.

[Liz England]

I'm at the halfway mark but figured I'd comment on it so far.

I tried reading this book about a year ago and found it really, really dry at the time and gave up early. This time through though I was able to keep up without a problem. It is still kind of on the drier side and I'd definitely put it in "textbook" category. I like it though - I think it goes into more breadth and depth (both) than the other game design 101 books I've read so far. I also like the player-first approach that comes up with every section. Also I think the book is pretty good at dancing between being practical and relevant for the mainstream industry and also catering to designers who'd be more interested in art/serious/experimental games.

Some of the aside articles are really good too. I am not really into the interviews (I don't usually get much out of them) but the guest articles like "What is a puzzle?" are pretty solid.

One thing that's bugging me: I don't think I fully understand the difference between a PROCEDURE and a RULE. I understand that "the player presses A to make the character jump" is a procedure (related to actions the player can take) but I don't understand why that's not also a rule. I don't understand why procedures are called out separately as their own thing. Is it pretty much the same as the difference between a mechanic and a dynamic?

-Liz

[Dog Eighty]

I've only read first and second editions. There wasn't much difference between the two, other than 2e added a token chapter on digital prototypes.

I describe the book this way:
* The first third of the book is just laying down the terminology and concepts of the field. It's necessary, it's dry, and it's mostly a repeat of the same portion of every other competent game design textbook ever. And I agree that the procedure vs. rule distinction is foggy and not really that relevant to practical game design (I can make games just fine without remembering the difference in the book, and I remember struggling with that same thing when I first read it years ago). Looking it up online, the distinction is that what Tracy calls "procedures" are like the printed rules of a board game, defining the setup / initialization, rules of play, special cases, conditions of resolution, and determining outcome. Rules specifically govern player behavior, what the player can and can't do. So "avatar jumps when player presses A and they were standing on the ground" is both a procedure and a rule, "player can press A at any time and as many times as they like, whether it does something or not" is a rule but not a procedure, and "avatar starts on the extreme left side of each level" is a procedure but not a rule, would be my understanding. But I tell students they don't need to know the distinction. (I prefer talking about the three kinds of rules from Rules of Play in this context, as those distinctions are easier to justify.)

* The last third of the book talks about the game industry, and feels very out of place in a textbook on game design - it'd be like having chapters on major biotech corporations in a cell biology textbook. It also struck me as pretty basic stuff that any student should hopefully know BEFORE they commit to a four-year undergrad degree in games (though I admit that not all of them do). Most of the time I just want to rip the last third out and pretend it didn't happen.

* The middle part is the meat of the book and worth the price of admission. Most design texts either don't mention rapid prototyping and playtesting and iteration, or mention it in an offhand "yeah, this is super important, you should make games that way" sort of way. This one goes into deep detail with the why and how-to, giving the best treatment I've seen in any book to the subject of how to make a paper prototype quickly and run a competent playtest session to answer critical design questions.

Guest interviews in game design books (in general) are usually not there for people like us :). They are there so that beginner-level students give the book some legitimacy in their minds, that it's not just a textbook written by some know-nothing academic, it's written by someone who knows what they're doing and is backed up by other people who know what they're doing.

- Ian

[Nick Lalone]

* The last third of the book talks about the game industry, and feels very out of place in a textbook on game design - it'd be like having chapters on major biotech corporations in a cell biology textbook. It also struck me as pretty basic stuff that any student should hopefully know BEFORE they commit to a four-year undergrad degree in games (though I admit that not all of them do). Most of the time I just want to rip the last third out and pretend it didn't happen.

While that should be true (they should know), I have yet to see a student that does. In fact, most of the time the comments i've gotten from students about this book are more about how instructive the interviews are moreso than the activities. However, I saw more creativity and interest from the "Up the River" design than anything I have ever asked students to do. Sadly, I rarely see a bridge between rapid prototyping and software-based prototyping. The sudden appearance of computation seems to thwart and remove all of that learning.