It's been awhile since I did one of these, mostly because I've been busy with other things aside from reading. I'm glad to be looking at textbooks again, because quite a few interesting ones have surfaced in the past year or two. And so today I examine:

"The Art of Game Design: A Book of Lenses" (Jesse Schell)

Now, this book came out about the same time that mine did, and it managed to steal the spotlight, so I really wanted to hate it. But it really is a solid book, and fully deserves the praise it has been receiving.

The information is solid, as I would expect it to be. Game design is a broad field, and Jesse has an even broader skill set, allowing him to effectively write about game design... but also about a variety of other fields that game design can (and should) draw from. This on its own makes the book stand out; many books that are supposedly on game design do not teach the first thing of it, so it is nice to read from someone who actually knows what he's talking about.

The writing is very conversational and even intimate in tone. Only Jesse could have written this, and his voice is very clear in the writing to anyone who has met him. There are no practice problems or quizzes, making it feel more like a guided tour than a stuffy textbook. I found it easy to start reading, easy to keep reading, and very accessible throughout.

Perhaps the best part, the part that I am likely to steal for my own classes, is the organization of the book. Each chapter introduces one aspect of game design, such as story, game worlds, game mechanics, game balance, or the iterative process. The topic is explored in depth, and connected to other topics. Throughout the book, a concept map is built piece by piece, chapter by chapter.

The book is comprehensive, covering not just the core concepts of game design but also everything immediately surrounding it: interfacing with the rest of the development team, dealing with companies and funding and profit-making, player communities, and so on. While a "pure" game design course might eschew these kinds of peripheral topics, I find their inclusion necessary as a way to prepare students for the realities of the industry: you are not going to be creating your own games from whole cloth, you will be designing other people's games according to their own constraints, so get used to dealing with that on multiple levels.

Embedded within each chapter are a series of "lenses" as alluded to by the subtitle. Each lens is one way to evaluate a game-in-progress, and includes one or more direct questions to ask of the current iteration. Many of the lenses directly reference one another (or sets of lenses are grouped together in the text), making something of a concept map between them as well.

If the book has any weakness as a course textbook, it is that it does not give exercises or other tasks that could be assigned as homework, so the teacher will need to provide that on their own. Additionally, the book seems to naturally assume that the reader is already working on their own game idea; it therefore does not provide any direct call to action for readers (particularly students) who may not know where to begin if they have not already started. In this, it actually makes a great companion to my book (which is practically nothing but a series of constraints that can be used to start a game project).

Students: If this textbook is not required reading in your game design courses (or especially if you do not have any game design courses), take some initiative and go read it yourself. Its combined breadth and depth make it an ideal starting point to show you all practical areas of game design and (most importantly) to get you thinking like a designer. Think of it as a foundation, upon which everything else can be built.

Instructors: This book is perfect for an intro game design course. You could cover a selection of topics that are of interest to you (or that best fit your curriculum), or try to cover all of the topics briefly just to give some exposure (as you might in a survey course). Consider having students hang onto this text so that some parts can be referenced in higher-level design courses.

Also, if you are just planning out your first game design course, you could do worse than following this book (addressing each chapter in the order it's presented) as a rough syllabus.

Professionals: A lot of the information here might seem basic if you are an experienced designer. That said, we all have our weaknesses -- a technical designer might not be great at building worlds, while not all story writers are proficient at game balance -- and this provides an accessible way to get at least a minimum baseline of understanding of those other parts of design that are so mysterious to you. The most useful part will probably be the lenses themselves (of which you can purchase a separate deck of cards, one lens per card, as a quick-reference) as they provide an easy way to objectively examine the game you are currently working on.

Raph Koster's A Theory of Fun for Game Design has been out of print for a few years, making it obnoxiously difficult for anyone to actually buy it for less than 200ドル or so.

Happily, it is now back in print for about 15ドル.

I suspect a lot of teachers will suddenly be adding another book to their required texts next term...

"Challenges for Game Designers" (Brenda Brathwaite and Ian Schreiber)

So, it's finally printed and in circulation, and you can buy it now. This is the best textbook ever, and all of you should adopt it for all your classes and buy extra copies from your friends.

Okay, so I'm one of the authors. What, you expect an unbiased review?

This book came about because some people on IGDA's Game_Edu list were complaining that they'd love to have students design games, but they either don't have access to computers or their students don't know programming. Brenda and I were both, like, WTF? You don't need any polygons to play Chess. You don't need any lines of code to play Go. You don't need a development team and millions of dollars to make Settlers of Catan, you just need one guy and five bucks' worth of dice and index cards. So, we decided to write a book about making games without computers.

The original idea was just to take a bunch of exercises that we'd both done in our classes, sets of constraints that serve as starting points. (For example, some of my former students still shudder in horror of the time when I had them create a game concept document based on the Care Bears IP after we studied the use of licenses in games.) Before too long, though, we realized it would be unfair to just give these exercises without any help -- it's fine and good for people who are designers already, but to tell a beginning student they should create a full proposal without telling them how is just unfair. So we added a bit of "how-to"... which incidentally made the book take about three times as long to write, but hopefully a lot easier to understand.

The book is 21 chapters, though one of those is just the introduction to the book. The other twenty all have five exercises each (with a full description of deliverables and suggested process), plus another ten "shorts" (quick ideas to get you started or inspired), for a total of 300 game design exercises... none of which requires any art or programming skill at all (although if you do have programming or art skills and want to take your non-digital design and make a digital game out of it, most of these exercises can be used as a starting point).

Students: If you'd like to design games but don't know where to begin, this should be a reasonable starting point.

Instructors: I expect this to be a good companion to a theory-based textbook like Game Design Workshop . Theory is necessary and all, but at some point anyone learning game design must sit down and design games (lots and lots of games), and Challenges for Game Designers is very practical in nature. You could either combine the two in a single course, or teach an introductory theory-based course to give the basic concepts and then offer a follow-up practical course. I happen to think students would understand more if the theory and practice were combined so that the theories make sense and are contextual, rather than just some abstract thoughts that are meaningless until six months later.

Professionals: When Brenda and I worked at Cyberlore, there was a time when we'd have weekly design department meetings (we worked with two other designers). Once a month, we would use the meeting time to do a design exercise; one of us would be responsible for developing the constraints, and the others would struggle with the problem. It was a way to keep our design skills sharp, and it was one of the few times in the business world where you'd hear people say that they were actually looking forward to attending a meeting. I also ran a couple of these exercises over lunch and invited programmers, artists, and anyone else who had an interest in game design; people had fun, and also gained an understanding of the kinds of things we designers did all day. If you work with other designers (or other people who are interested in game design), we designed this book to be useful in these kinds of skill-building meetings and workshops.

It's been awhile since I did one of these. I just got a new shipment in, but I chose this one first because it was short.

"Teaching Videogames" (Barney Oram & James Newman)

It may seem strange to call this a "textbook" since it's targeted at teachers and not students, but it's a book on teaching and games so of course I had to take a look. It's written by two people with no game industry credits that I could see, it's barely large enough at 88 pages to qualify as a book (at that size it's more like an oversized pamphlet), and they're charging 42ドル.95 for it, so I wasn't in a particularly generous mood when I started reading.

To be clear, this is not a book on game development. It's a book on game studies. This wasn't clear to me from the title, although I suppose being part of the "Teaching Film and Media Studies" series of books (as shown on the cover) should have been a big hint.

What exactly is this book about? It appears to be a primer on games (in the context of media studies) for those unfortunate souls who teach media studies courses, somehow found themselves tasked with teaching a class on video game studies, and feel completely lost because they don't know the first thing about video games. For those people, this book offers an overview of games and the game industry: a brief history of the industry, important types of businesses (developers, publishers, retailers, etc.), ludology and narratology, women in games, and violence in games and its effect on society. It offers workable syllabi for a pair of six-week classes, one on the study of games and one on the study of play, and includes some worksheets that can be given as class assignments (printed in such a tiny font that I had to squint to read it, but thankfully including a link to a soft copy online).

I didn't see any blatant errors; the content is pretty solid for what it is. In fact, my lesson plans for my Game Industry Survey course already contain a lot of this information, so I may not be as hopeless at game studies as I used to think I was. And the book is a fast read, so if you know nothing about video games and need to get up to speed pronto, this is a pretty decent bet. It starts off with a bit of academic jargon in the first few pages, but quickly lapses into a more readable, conversational tone.

That said, the book has what I see as a major conceptual flaw, and it's something that has probably been bugging some of you since a couple of paragraphs ago: this is written to assist those who are teaching a game studies class, but don't know the first thing about it. So I have to ask... for those who don't know anything about a subject, why are they teaching it in the first place? This book doesn't qualify someone to teach a class in game studies, any more than reading the Cliffs Notes version of Hamlet would qualify me to teach a class on Shakespeare in the English department. A teacher who knows nothing about a subject should not teach a course in that subject. Period. Am I the only one who thinks this? Am I oversimplifying? At any rate, it seems to me that if someone needs this book, then really they don't need the book, they need to not teach the class. So I'm suddenly not seeing the point of this book existing in the first place.

For those who teach game studies and are fully qualified, most of the content in this book is a waste of time, because you know it already. You won't see anything new. About the only thing that might be of use is the worksheets and lesson plans, which amount to maybe a tenth of the total book, and you can probably find more and better content in the IGDA Edu Curriculum Knowledge Base. The best reason to buy this book, then, appears to be the picture of Lara Croft wearing glasses and looking all educated on the front cover.

Students: Ironically, I think the people who would get the most use out of this book are students who are contemplating a Game Studies or Media Studies major. The book is short, it's easy to read, you can skip over the academic parts, and it'll give you a head start for your Game Studies 101 class (and give you some idea of the kinds of things you'll be studying). Just be aware that neither this book nor any related course of study will actually help you to make games, it will only let you study them.

Instructors: As mentioned above, either you don't need this book (in which case, buying it is a problem), or you do need this book (which is itself a problem). I did think of one edge case where the book might be useful: if you're teaching a more general Media Studies class (comparing and contrasting various media and how to study them) and you want to include a week or two on games but you're unfamiliar with this medium, then this book would be suitable for you to build that content into an existing class.

Professionals: If you're a practicing professional who knows all about making games but you never actually got to take any game studies courses in college (because you were too busy learning game development), and you'd like to read the books out there like Rules of Play except they're too big and intimidating to fit into your busy schedule, this will give you the quick-and-dirty introduction you're looking for.

Game educator Malcolm Ryan has recently started a blog about books that are useful for game designers. He is planning to review one book per week until his bookshelf runs empty. So, it's no longer just me doing this, which is great because the more critics we have, the better (given how many horrible books there are out there).

So, let's all give Malcolm a warm welcome.

This is part of the series on book reviews.

"Break into the Game Industry: How to get a job making video games" (Ernest Adams)

I almost didn't want to review this book. After all, it's obviously a vocationally-oriented book that has no place in the classroom as a text, right? While there is certainly a strong focus on the "breaking in" aspect, it turns out this book has a surprising amount of overlap with my Game Industry Survey course topics, suggesting that it may have more use than the title suggests.

This book starts with a reasonable (if brief) look at the history of the industry and then goes right into the bits of how the industry is structured today: platforms, game genres, business models, job roles and responsibilities within a developer. This is important stuff for any aspiring developer to know, and it takes up about half of the book.

About a third of the book is devoted to what the title implies: what kind of education and experience to give yourself, and the actual process of applying for a job. This strikes me as the kind of thing that students should read on their own, rather than something that's part of any course material.

Lastly, the book ends with a short section on the minimum everyone should know about legal issues (IP, NDAs, and how to read an employment contract) and a final wild guess on the probable future direction of the industry.

It should be noted that this book was published in 2003. This has the obvious implications: some of the information is woefully out of date. Notably, this was written before the downsizing of E3 and before the ea_spouse letter. Some of the companies mentioned are no longer making games. That said, a surprising amount of the practical information in this book is still valid, although it is definitely living on borrowed time -- I'm not sure how many more years it will be useful before the obsolete material outweighs the usefulness of the rest.

Students: If you are interested in getting into the game industry or you'd just like to know a bit more about what it's like behind-the-scenes, this is a great book to read. I can't say that it's fun to read exactly, but the information contained within is obviously practical and useful which might give you the incentive to keep reading anyway. At least for now, most of the obsolete material involves things that can easily be checked online, so for any specific piece of information you'd do well to confirm it by firing up your browser.

Instructors: It doesn't have any end-of-chapter exercises so you'll have to make your own, and you'll have to supplement it with modern history (the current generation of consoles, the effect of World of Warcraft, etc.), and it has a title that will make other academics glare at you if you use it as a required text in a class. But it still has a lot of useful information about the industry, so if you teach a class about the game industry you might at least consider making it an optional text in your syllabus. And if you have no industry experience, you could do with reading it yourself to supplement your existing course materials.

Professionals: If you already have a job in the game industry, then you probably know most of this stuff already, so it's not really worth your time to read the whole thing. That said, if there are aspects of game development that you don't know much about, this is as good a primer as any to show you what the heck it is that those people in that other department are doing all day; I learned tons about art and game audio, which were always something of a mystery to me.

This is part of the series on book reviews.
"Chris Crawford on Game Design" (Chris Crawford)

Chris Crawford is an interesting character of the industry. He's been in the industry since its very beginnings. He is so animated as a public speaker that it is physically impossible to be bored while listening. He is outspoken, highly opinionated and quite curmudgeonly. He can be egotistical at times; some would say he's earned the right. The industry owes him a debt of gratitude for starting the first incarnation of GDC in his living room. (Personally, I considered this debt paid in full when, at GDC 2006, he told a room full of game developers that games were dead as an artistic medium. Which left me to wonder what he was doing in the Game Developers Conference if he no longer wishes to be a game developer. But I digress.)

It is important to understand at least a little bit of the man when reading this book, because the author projects a lot of his personality into it. This is not a stuffy, academic textbook by any means; this is 100% pure Chris Crawford opinionated ranting. In short, the book is exactly what the title says -- no more, no less. This makes it worthy of study, but also of limited use.

So, what is in this book? Roughly the first half talks about general game design concepts: the nature of play, challenge, interactivity and so on. The second half includes a chapter on every game that Crawford ever designed, and the lessons he feels he learned as a designer. Somewhere in the middle there's a chapter devoted to recommended books to read, and another on games to play, for the aspiring designer -- which both include an overly-biased dose of Crawford's own work. The book ends with a wonderfully entertaining (if not necessarily educational) chapter called "Old Fart Stories".

Anyone who reads this book needs to keep a box of salt at the ready, to take one grain at a time with each sentence. Some of Crawford's assertions are bathed in wisdom. Some are a bit off the mark. Some appear to be the ravings of a madman. It is not immediately clear which are which; readers must make up their own minds. As such, it helps to have a solid academic foundation (if not outright experience) in the field before reading this book; you'll need it to make your own informed opinion.

All that said, it's an easy read, so it's probably worth the weekend that it takes to skim through it. Different people will get different things out of it, but it's worth at least taking a look at so you can decide for yourself what nuggets of brilliance (if any) are embedded in the book. Unless you have absolutely no respect for Chris Crawford, in which case you're not going to buy this book anyway. (I've met developers who worship Crawford, others who despise him, and a few who are in between. Hmm. Maybe you should try meeting him in person before deciding whether to read his book?)

Students: Do not read this until you've already done a lot of other study and practice; otherwise you're likely to just get confused when the things that he says start contradicting what you'll learn in later classes. When you think you're ready, go ahead and read it, being prepared to have your own debates with him in your head.

Instructors: Since this is not a comprehensive text (nor even a particularly focused one), I can't see it being used as the basis for an entire course. As part of a higher-level theory course where students are expected to compare and contrast various designers and their rhetoric, this could be one of several books... although depending on the length of the course, again, it may not be practical to have students read more than an occasional excerpt (and forcing them to purchase five or ten books just to read one chapter from each is just cruel).

Professionals: If you work in the industry you probably know the author, by reputation if nothing else. If you've seen him speak at GDC, imagine all of that dropped into a book and you know what you're in for. You'll probably read about some obscure games that you've never even heard of (mostly Crawford's own) which I suppose has value in itself, and debating the finer points of this book with other designers could be an interesting exercise if you can convince them to read it at the same time. But due to the large amounts of questionable material in this book, I'd leave it until after you've covered the more important works.

This is part of the series on book reviews.

"Introduction to the Game Industry" (Michael Moore)

(No, this wasn't written by that Michael Moore. I think he's generally too busy making movies to do much game development. Not that there's anything wrong with a documentary filmmaker creating a video game.)

Now, with that out of the way...

From the title of this book, I would have assumed it would be looking at the past, present and future of the game industry (without getting into the gory details of actual game development). But it turns out this book is more like a "lite" version of Rabin's "Intro" tome... with a stronger focus on game design, production and business. There is some history of gaming, but it is more of a sidebar to the rest of the book.

The timing on this book's publication was unfortunate. It was finished in late 2006 and published in early 2007, at a transition point in the industry (with the upcoming release of the Wii and PS3 and downsizing of E3, among other things). This means that any modern examples in the book already appear dated, and the poor book hasn't even been out for a year yet.

Maybe I'm a stickler for details, but I was disappointed at the editing of the book. There were a number of embarrassing mistakes; in the first few chapters I saw a comment on the steady decline of the physical boardgame industry in the 1990's, without any mention of the Eurogame resurgence; "A game is a series of interesting decisions" was attributed to Sid Meiers; and the heroine of Tomb Raider is apparently named Laura Croft. These may be little things, but they're exactly the things that end a conversation between a student and some professionals. I could understand sloppiness from an author with no experience who just wanted to cash in on the whole games-in-education trend; I would expect better from an industry veteran who teaches at DigiPen.

Perhaps more dangerous is that in 2007, this textbook largely teaches that games are created through the Waterfall model. It does acknowledge rapid prototyping very briefly, but makes no mention of Agile development that was all the rage as of the time of printing (and still is, to my knowledge).

On the bright side, there are a variety of exercises at the end of each chapter that range from basic multiple-choice regurgitation of the chapter content to some nice design exercises and thought-provoking questions. Also, this book introduces a fairly complete set of industry jargon, which is important to a student who wants to hold a conversation with a professional; however, the terminology is scattered throughout the book and has no unifying quick-reference table or glossary as a reminder.

Students: If you're looking for a basic, high-level overview of game design or production with a little understanding of what those strange artists and programmers are doing (without having to actually learn art or programming), this book will give you a reasonable starting place. As you read, make sure to not take anything as gospel; this book has equal parts good and questionable advice. I'd recommend reading this only as a supplement to other texts, either to fill in some blanks or as a second opinion.

Instructors: Use of this book in the classroom has similar problems to Rabin's book: by covering all disciplines of game development it can't really fit in any of them. Added to the other problems above, I can't see this being useful as a textbook for any course. However, I would definitely recommend picking up an evaluation copy for yourself and taking a look at the end-of-chapter exercises for the chapters that apply to your classes; you may find a few good questions and activities for class discussions, exams and homeworks.

Professionals: As this book explains the game industry to the uninitiated, you are really not the target audience. If you're a programmer or artist who wants to know more about production or game design you might give those sections a read, but you're probably better off finding other books that go more in depth into those respective fields.

This is part of the series on book reviews.
"High Score! the illustrated history of electronic games (2nd Edition)" (Rusel Demaria & Johnny Wilson)

I've used this book in my Game Industry Survey class, but it's not a textbook. It even says on the cover that it's a coffee table book for game geeks, and that's exactly what it is: a trip down the memory lane of the game industry, in full color, featuring much box art, screenshots and developer photos. The authors give a very candid look at the industry, talking not just about the games but also the developers: what it was like to work at Atari in the early days, for example. The writing style is conversational, not academic, making it an easy read (not to mention that the subject material will be interesting to most student game developers).

This book has two glaring weaknesses, and neither is the fault of the authors. The first is that it was published in 2004; the current generation of consoles did not exist yet, nor did World of Warcraft, so there is a period where the information just stops. Second, the book is unfortunately out of print, which makes it impossible to use as a required text. (Luckily, it can still be found used on Amazon and the like, as of the time of this posting.)

Students: If you're a game geek, you'll probably enjoy reading this book anyway. The fact that you'll actually get a great sense of the history of the industry (which will help you appear serious when you start applying for jobs) is purely accidental.

Instructors: If you teach a course about the history of the game industry, this is a great supplement. Being out of print means it's not required, but you might at least pick up a copy for yourself to supplement your lecture material, and suggest that interested students find their own copy for out-of-class pleasure reading.

Professionals: This is more of a game geek book, so it won't exactly help you make better games. You might like to pick it up for fun, or not, depending on your personal taste in books.

This is part of the series on book reviews.

"Introduction to Game Development" (Steve Rabin)

This ginormous book is a fairly comprehensive look at all aspects of game development: art, design, programming, production, audio, business and even a little bit on academic game studies. (As with the rest of the industry, QA is largely ignored.) It's actually a collection of essays and articles written by a wide variety of experienced game developers; Rabin is the editor, not the author. The list of topics was developed according to the IGDA Curriculum Framework and there are exercises at the end of each section; newer editions include a CD-ROM with pre-fabricated Powerpoint presentations ready to use in the classroom... if you're the kind of teacher who likes to read bullet points off of slides. Anyway, this was very clearly meant to be a textbook, possibly the textbook (as in, One Textbook to rule them all, or perhaps the Ultimate Textbook Of Ultimate Destiny).

As might be expected, Programming and Art get the most attention; those disciplines are more quantifiable, have more direct and better understood application outside of game development, and they are the most common entry-level positions (other than QA). As a result, most academic programs already focus on either Programming or Art, so a grand-unified-theory textbook such as this would want to put its attention on the same areas that schools do.

The book's size and scope is in some ways a disadvantage. No single course can cover the entire text, and its sheer bulk is inherently intimidating. It is expensive, and its generality means that any given course probably has other textbooks with a tighter focus that are more relevant.

On the other hand, if several instructors collaborate and agree to use the book in all of their respective courses, this one text could serve as a constant companion to students across an entire curriculum. While Introduction is inherently weak in some areas (notably game design), it gives a solid list of references to other works; any question that a student may have about any aspect of game development is probably either answered in this book, or in one of its direct citations.

Students: Personally, I think every student should own this book as a reference guide, the same way everyone used to own a dictionary and thesaurus before the Web made those obsolete. That said, I went so far as to make this textbook required (and even assigned some readings from it) in several of my courses last year, and for the most part my students ignored it -- whether from the intimidation factor or the expense, I don't know.

Instructors: If you require this book, be prepared to go all the way with it: make sure there are enough assigned readings and problem sets that supplement your existing course that it's worth the trouble. Ideally, work with other professors so that the book is used across several classes. That said, for game design in particular, I think there are better books out there; this is best used in a more general program, or especially an art- or programming-focused curriculum that has a Game Design course on the side.

Professionals: Even at the professional level, this is still a decent reference text. It would come in most handy if you're asked to do something outside of your specialty (a graphics programmer being asked to do some AI, for example) or if you just want a better understanding of what your co-workers do all day. It's probably best to just ask your manager to get a shared copy for the office, rather than having to own your own personal book.

This is part of the series on book reviews.

"Fundamentals of Game Design" (Ernest Adams, Andrew Rollings)

This book covers the core concepts of the field of game design, and for good measure adds an in-depth look at a large number of currently-popular genres and the design elements specific to each.

I love the structure of Fundamentals; the topics flow nicely into one another, and the exercises at the end of each chapter make it easy to design lessons around. The coverage of game genres may be unique to this book; on the other hand, as new styles of gameplay are invented and others lose favor, this book will eventually date itself.

As for the content itself, the majority is (more or less) the sole opinions of the authors, and as such should be taken as a set of theories – not scientific laws. Like a programming code or religious text, this book is meant to be interpreted and discussed, not blindly followed.

Students: This book is absolutely worth reading once you’ve already studied the basics of game design and want to get into specifics. Do not read this as your first book; you’ll be tempted to assume that everything in here must be taken as gospel, and it has the danger of tainting your own artistic vision for years until you un-learn it. But as your study advances, you can properly see this as one approach of many, and the content will give you a valuable perspective.

Instructors: The worst way to use this book is to lecture directly from the text in an introductory course. I have great respect for the authors, but our industry does not need a new generation of Adams and Rollings clones; it needs creative people who can think for themselves. My preferred use of this book would be in an advanced, conceptual class where students already have a foundation in conceptual and practical game design; class time would consist not of lecture, but of moderated discussion. Everything in the book is subject to heated debate (even from the beginning with the definition of what a “game” is) and the debates in an advanced class would be wonderful.

Professionals: Experienced game developers will probably get little out of this book. If you have always been highly specialized and want to learn more about other areas of design then this book can help you, but that’s about it.

This is part of the series on book reviews.

"Game Design, Theory & Practice (2nd Ed.)" (Richard Rouse III)

This relatively well-known book was an early stab at a book about game design for non-designers (by “early” I mean that it’s more than five years old, thus predating many of today’s college curricula and the majority of other textbooks I've reviewed). It includes an eclectic mix of game analysis, best practices, and interviews with influential designers.

Most of the content is at a pretty basic level, making it an easy read. Of course, this also limits its usefulness to more experienced designers. Each chapter is mostly self-contained; this also makes it easy to read (one chapter at a time, and if you put it down for a few months you don't have to repeat old sections that you'd forgotten) but also makes the book feel a bit disjointed.

Students: This book is a great place to start for self-study if you know you want to design games but you don't know where to begin. It will help you understand the field, by showing you how some designers approach their craft, and you will come away with a variety of new perspectives on how to make games.

Instructors: It’s probably my own inexperience as a teacher, but I haven’t figured out how to include this book in a class (much as I’d like to). The topics don’t flow well, every chapter seems disconnected from the others, and there are no exercises or questions at the end of any chapter, so using this book would require a lot of extra prep work on the part of the instructor. This is perhaps not so surprising; it was never written for the express purpose of being used as a classroom text, after all.

Professionals: If you’ve already got a couple of shipped titles under your belt, most of the practical advice in this book will be nothing new to you. You may still find it entertaining, but it will probably not be of great help in honing your craft.

This is part of the series on book reviews.

"The Game Design Reader" (Katie Salen and Eric Zimmerman)

This companion to Rules of Play is simply a collection of important essays and other written works about games. It includes pretty much everything that I'd call "foundational" to the field: Costikyan's I Have No Words, Church's Formal Abstract Design Tools, Bartle's Player Types, and so on.

Unfortunately, it tries to be a little of everything; there's some New Games Journalism, some pieces on players and gamer culture, and other things that don't really have to do with designing a game. And most of the articles are freely available online anyway, making me wonder why I should force my students to pay some exorbitant amount of money for a textbook.

This is not to say that the articles (design-focused and otherwise) aren't useful. They are still important works in their own right, many people in the industry have read them already, and any serious student should read everything in this book. It's just that no matter what the subject of the course, the majority of the works in this book won't be relevant. I suppose you could build a course around the book, "Important Readings in the Game Industry," but I'm not at liberty to do that right now. An alternative is to require this book for several courses in game design and game studies, with each course covering different readings… but that requires a bit of coordination between professors to ensure minimal duplication, and pity the poor students who take half the courses only to have to purchase the same book again if it ever goes to a Second Edition.

Students: If you’re serious about games, you should have at least a passing familiarity with everything in this book. Buy it on your own and read it over a summer when you’ve got nothing else to do. Or, if you’re on a tight budget (and what student isn’t?), find the book in your local bookstore, copy down the table of contents, and track down all of the articles online. For those few readings that can’t be found online, you should be able to check out the appropriate works from a library, or just read them in the bookstore.

Instructors: I’ve gotten by with just assigning relevant online readings, without forcing students to buy this book. I do suggest to my students to track down additional relevant readings from the book on their own time.

Professionals: At the very least, take a look at the table of contents and see how much of it you recognize. If you haven’t seen anything mentioned, you’ve got some wonderful reading experiences ahead of you. More likely, you’ll recognize some important works that you’ve encountered before, and the rest won’t be relevant to you. Take a look and decide for yourself.

This is part of the series on book reviews.

"Game Design: From Blue Sky to Green Light" (Deborah Todd)

This relatively short book covers everything that happens in preproduction; it gives a reasonable treatment to game design documents and the iterative process, and it even has a section on pitching a game to a publisher. It also covers the creative aspects of game design that I myself am weakest at: storytelling, character design and level design.

Overall, the book delivers what it promises, and not much else. You won’t find a lick of material on technical game design, content development during the actual creation of a game, or anything like that.

The only real weakness of the book is that it’s extremely current and uses a lot of very recent examples (as of the time of publication). This means it is likely to obsolete itself in a fairly short time, as the games within become dated and the business of the industry (hopefully) moves beyond the developer/publisher royalty-with-advance model. Although perhaps that’s intentional, if the author hopes and expects to make new editions every few years.

Students: Odds are, the first project you work on will already be in full production by the time you’re hired. Preproduction work, concepting and pitching are usually reserved for experienced design leads (not always, but usually), so this will not be immediately applicable to your first job. That gives you time to read it after you break in to the industry, if you're the procrastinating type. But if you’re curious what the early stages of a game project are like, you’ll get a pretty good overview by reading this book. It’s also not terribly big or intimidating, so reading it while still a student might not seem like such a daunting task.

Instructors: This book is rather specific to the earliest phases of game development, making its use limited in most classes. If you’re teaching a practical game design course where the deliverables include a one-page game concept, a slightly larger game proposal, a game design document and a verbal pitch to a “publisher” (i.e. the instructor), this book will cover you. If the only practical development course you teach involves all of that in the first three weeks and then it’s straight into prototyping, you might not have enough time to make the book worthwhile as a required text.

Professionals: Designers in the industry are still very guild/apprentice-like. If you do indeed start your first design job in the middle of a project, you’ll probably experience a few preproduction cycles vicariously through your leads before you’re forced to do it yourself. Depending on how you look at it, that either makes this book redundant with your experience, or it will reinforce it. In any case, it’s probably worth a read just to see what others have to say on the subject. And if you happen to find yourself in a small studio where you’re thrown into the role of Lead Designer on your first job fresh out of college… then you should read this just so you have some experience backing you up (even if it’s not your own).

This is part of the series on book reviews.

"Rules of Play" (Katie Salen & Eric Zimmerman)

I’m really glad this book was written. It was the first book ever written about game design that actually looks like a textbook. It’s big, it’s heavy, it has lots of small-print writing with exercises at the end of each chapter and a bunch of appendices at the end. Its very existence gives the entire field some modicum of academic merit.

The content does not deal so much with how to design games per se, but instead gives many different ways to critically analyze games. For example, if you consider a game as a system of rules, you are going to see it differently than if you look at that same game as a narrative, or as a sociocultural activity, or… well, you get the idea. It is therefore useful to game designers only in the most abstract sense of gaining a deeper understanding of what these things called “games” are, these things that we work with every day.

As a bonus at the end of each of the four sections, there are the rules for a game you can play (I found most of them to be quite good). In addition to the game itself, we can also see the designer’s notes about how the game started out, what kinds of things were found in playtesting and how (and why) the designer addressed the game’s shortcomings. This insight into the brain of a designer-in-motion is most interesting, and practically worth the (hefty) price tag of the book on its own. There’s also an essay by Reiner Knizia, which also makes for great reading, even if it doesn’t necessarily fit the theme of the rest of the book.

Unfortunately, this book has a few weaknesses in its presentation. The writing is a bit on the long side. As a game designer, I found that if I just read the bullet-point summary at the end of each chapter, I usually got all of the information I needed; actually reading the chapter itself was a waste of time. (Yes, I read every chapter first, just to make sure.) I’m not sure if this is just from my experience; if there are any students in the audience who can say whether this was true for them as well, please post in the comments.

Also, the authors have this unfortunate tendency to create their own vocabulary. Their new terminology mingles liberally with established industry jargon, but with no mention of which is which. I can’t fault the authors for this (what else could they do?) but it does make it more difficult to use this as a textbook: my students who go to GDC should know what an Avatar is, but if they start talking about “schemas” and “constitutive rules” and “transformative social play” they’re just going to embarrass themselves.

Students: I doubt any student would choose to read this on their own. Most of you don’t enjoy reading to begin with, and a book this abstract would probably bore you to tears. You may be forced to read it as part of a game design class (and if so, you have my sympathy) but otherwise, you’re safe avoiding it for the time being if you want to be a game designer. If you’re more interested in game critique or game studies, you’ll probably find this quite useful and fascinating. I could never figure out game studies people.

Instructors: This book would be perfect for a “Critical Game Analysis” class that acts as a dual requirement for Game Studies and Game Development students. I’d expect it to be an upper-level class, simply because of the highly academic writing in the text. For any course focused entirely on game design, there are better texts; as noted above, this book does nothing to explain how to actually design games.

If you do use this book for a class, be sure to differentiate between the terminology used that already exists, versus that which was created by the authors. Your students should be able to speak clearly about games to people who haven’t already read Rules of Play.

Professionals: This book took me about half a year to read through from cover to cover (in my spare time, granted). You can get all the same benefits in a fraction of the time by just skipping to the end of each chapter and reading the summary, then going back and looking up anything that doesn’t make immediate “well, duh” sense to you. Also read the Knizia essay and commissioned games, of course. Do that and you’ll finish reading it in a few days.

This is part of the series on book reviews.

"Game Design Workshop: Designing, Prototyping & Playtesting Games" (Tracy Fullerton, Chris Swain, Steven Hoffman)

This book covers the core concepts and best practices of game design. It is organized into three parts. The first part gives a formal description of all of the different aspects of games, to build a framework for discussing how to design them. The second part talks about the iterative process as it applies to game design (in particular, how to prototype, focus test and playtest, and respond to feedback); in fact, this is the only game design book I've seen so far that does so. The last part gives an overview of the game industry and the job roles and responsibilities of the game designer.

The first part of the book gives a reasonable breakdown of games into their component parts. The second part gives great practical advice on the process of game development from a designer's point of view. The third part is easily the weakest link; it starts out worthless (everyone reading a book like this already knows what a game designer is, why else would they read it?) and proceeds into the realm of actively damaging (giving the waterfall model of production, and a design document template as examples of best practices). It is best for everyone with this book to just pretend the third section doesn't exist; thankfully, the rest of the book is worth the price of admission.

Sprinkled throughout the book are numerous interviews with famous designers, offering many (often conflicting) perspectives on the field; these make great discussion fodder for classes, and also provide some insight into what aspects of game design are universal (where many designers agree) versus those that are a matter of personal style (where designers give opposing answers to the same questions). They don't seem to have much relation to the section of the book they appear in, they're just diversionary sidebars... but they make interesting reading nonetheless.

Students: You can read this book on your own, but you'll probably get the most out of it if you take a class that uses it as a textbook. If no such class exists, reading the first two parts is still a worthwhile use of your time -- certainly better than nothing.

Instructors: The book contains many exercises, some highly conceptual and some quite practical, making it very easy to use as the basis for an intro course in game design. This is, in fact, the book I used myself for just such a class, and I was quite happy with it. I found that, while it does involve a lot of reading, the reading goes quickly; the students taking a game design class are already motivated, and this book contains the material that they want to know. I encouraged students to read those parts of the book that we didn't get to during the course, on their own time... except for the third part of the book, which I advised them to rip out of the book on the first day of class.

Professionals: The first part is worth a read if you're a practicing game designer; many of the concepts will probably not be news to you, but it might give you a few new conceptual ways to think about the design of games in the abstract. The second part is worth reading for both game designers and producers, especially if you're not working at Maxis or Firaxis or some other place that already embraces iterative design; it gives great practical advice for doing so. The third part is even more worthless than it would be for a student; you're already a practicing game designer, so the last thing you need to be taught is "what it's like in the game industry".

This is part of the series on book reviews.

"21st Century Game Design" (Chris Bateman and Richard Boon)

This is a dangerous book. I can recommend it for veteran game designers since it provides an approach to game design that they may have never encountered before, and it's one more tool in their already-large toolbox. For anyone else (especially students), this can take you down the path to ruin if you just follow it as gospel.

The idea behind the book is simple: identify your target audience, then use psychological profiles to predict what games and mechanics are most compelling to the intended market. This basic concept of "designing for the audience" is a useful one, and I can see it being applied successfully in the field if used with care.

Strangely, the authors seem overly fond of MBTI as the preferred player demographic. For those who haven't encountered Myers-Briggs, it defines sixteen personality types and then proceeds to lump all of humankind into one of these compartments. Reading a description of these personality profiles bears a striking resemblance to another method of classifying people, and my understanding is that either one is about as useful as the other in terms of predictive value. (If you're curious, I'm ISTP, and Virgo. Those of you who place great faith in personality types are now saying to yourselves, "ah, of course!" while the rest of you already know me far better from my writing than any category I fit into.)

I find it ironic that Ernest Adams, who writes the foreward to this book, wrote years ago how designers should concentrate on making great games instead of spending all their time talking about marketing and player demographics. He even talks about how Purple Moon -- a company that used a startlingly similar approach advocated to this book in order to make "games for girls" -- died horribly because their designers spent so much time doing market research that they forgot to actually make their games fun.

Students: Avoid this book. (In my experience, most students don't need much convincing to not read something, so that's all I'll say on the matter...)

Instructors: Do not use as the sole text for a book. If you mention this book in your classes, warn the students that it is just one of many approaches... and one that has not yet been used successfully to make a hit game. It may be worthwhile to discuss short excerpts in an advanced class, as one of many methodologies for designing a game; as an exercise, have students rip apart the logic, separating the useful from not-so-useful parts.

Professionals: It's worth reading the first part of the book, before it goes into the actual details of personality types, just to consider the concept of a player-centric approach. The rest of the book is built on the foundation of MBTI, though, so it's not worth considering the remaining content unless you've already drunk the MBTI kool-aid.

This is part of the series on book reviews.

"Patterns in Game Design" (Staffan Bjork and Jussi Holopainen)

If you've never seen a book on Patterns before, this is likely to be different from your usual experience. A "Pattern" is, more or less, a common problem and its established solution. The point of a book of Patterns is to prevent you from reinventing the wheel with each new project.

Most Patterns books are programming-related, because programming is the most expensive part of game development, so a lot of cost savings can (theoretically) come from code re-use. Applying the same concept to game design is intriguing; as far as I know, this is the only book to do so (although similar works like the 400 Project existed first).

This book's concept of a Pattern is slightly different. It is more of an encyclopedia of game design concepts; for each concept, it explains what it is, what design decisions must be made to include it, and links to other related concepts.

Unfortunately, the book has some inherent flaws due to its very nature. For one thing, the field of game design does not have an established critical vocabulary, so the authors had to invent names for a lot of concepts that will be unfamiliar to designers or students. This makes the book read like a foreign-language dictionary: every time you try to look up the definition to a new word, the definition itself contains half a dozen words that you also have to look up. This makes for frustrating and dull reading, and since it's a physical book you don't even have the benefit of having hyperlinks to click on. This would have worked much better as a wiki than a book.

To make matters worse, the publishers decided for some strange reason to put about 200 of the Patterns on an included CD instead of in the printed book. However, many of the Patterns in the book reference those on the CD (and vice versa), so when looking at references you have to go back and forth between the two media.

I found the most useful thing about this book to be the overall taxonomy of concepts, where a game is broken down into major component parts (such as goals, rules and player actions) and then each of those parts has a number of concepts (e.g. different kinds of goals, such as Chase or Capture or Evade). This would fit well into a conceptual class on game design, as it goes into more detail than any other book I've seen on the list of concepts.

Students: You can safely avoid this book for the time being. You get enough tedium from the rest of your classes; there's no need to inflict more of it on yourself. Also, there's no obvious way to tell the difference between the terminology that is in common use in the industry, and that which is purely the invention of the authors; talking about Avatars and Bosses is all fine and good, but if you mention Hovering Closures or Focus Loci in your job interview you'll probably just confuse everyone else.

Instructors: The basic concepts in this book could be used in your lesson plans to supplement a theory-based game design class, when you talk about the component parts of a game. Just don't borrow the terminology that isn't in common use. I wouldn't recommend this as a required text for any class; it's not organized in any fashion that I can imagine being useful for a class, and it doesn't lend itself well to exercises. Keep a personal copy for reference when making your lesson plans, but keep it away from students.

Professionals: The terminology and organization of this book give it a large up-front cost in time; even if you just want to use it as a reference text, it's only practical if you've already read through (or at least skimmed) most of it already. If you do put in the time, it may be a source of inspiration when you're working on the core mechanics of a game... but only if the game is highly derivative by nature, because this book only documents common game features that already exist. In other words, it may help you solve problems that have already been solved in other games, but only in exchange for actively reducing your creativity.

This is the first in a series of book reviews. I'll start of with one of the few useful books I've read.

"A Theory of Fun for Game Design" (Raph Koster).

Everyone involved in game design -- students, teachers, and professionals -- should read this. It's very short, uses a large font, and every other page is a cartoon; you can read through it in an afternoon. It makes the case that learning is the source of fun in games, and that game designers are just a specialized type of educator.

This book is fairly light in content; it's not about how to design games, per se, but about what game design actually is. Probably the most important thing you can get from this book is a way to describe your field to friends and family who aren't gamers (particularly those with the attitude of "why are you wasting your life with those games, instead of studying something real?").

Students: Due to its brevity and tight focus, this is one of the few books that is easy for a student to just pick up and read on their own. If you're broke, you can always just read the thing in your local Borders some random afternoon.

Instructors: I think it would be tough to use as an actual textbook in class; it's too short. For classes where this book would be appropriate, just read it yourself and prepare a lecture that summarizes the key points. And then encourage students to read the entire book on their own time, if they find the topic interesting. Another option would be to require it as one of several short textbooks, and include assigned reading (with a summary report to be handed in) as part of a larger class -- either mandatory, or for extra credit.

Professionals: Pretty much every game designer I know personally has already read this book. If you haven't, you probably should, if only because it comes up in conversation from time to time. But if you work with other designers, they were probably bugging you about reading this long before I made this post.