Review: Finite and Infinite Games by James Carse

Book: Finite and Infinite Games
Author: James Carse, academic philosophy/religious studies
Year: 1986

Summary: Unless you are really into dry philosophy books, skip this one. It has little to offer game designers.


I picked up Finite and Infinite Games based on a GDC talk of the same name by Richard Lemarchand. I’ve seen others outside of games comment on how the book changed their life, and know that it was steeped in games terminology, so I felt it would be an interesting read. I hoped to gain insight into games from the perspective of a theologian and philosopher but came away very disappointed.

Finite and Infinite Games is a book on social philosophy. The author defines finite games as the structures in our life – societies, nations, war, dating, careers – that have a clear beginning and end, willing participants, boundaries, opponents, winners and losers, and competition for titles or possessions. As you can tell, the book borrows heavily from games terminology to describe our lives and offers the idea that the way we live, as social humans, mimics that of a game.

This is in contrast to ‘infinite games’ which Carse describes as games played with the intention of continuing play (rather than ending it to declare a winner). These infinite games swap boundaries for horizons – in games terms, that would mean finite games play within a defined magic circle while infinite games seek to expand that circle. As a part of social philosophy, Carse describes infinite gamers as people who think beyond the artificial constructs of our lives (nations, societies, possessions, etc.) and recognize that most of social hierarchy is a form of play (drama, performance, roles).

The first third of the book had some interesting parts in it that I enjoyed, but eventually it devolved into philosophical meanderings that felt completely irrelevant. That’s a harsh way of describing it, I admit, but I can only judge this book as a game designer and not as a philosopher. (Keep in mind that it has a good reputation among the latter, and many people love the book.) A lot of the text relies on defining very abstract concepts using familiar terms, so you get sections on the difference between “being moved” and “being touched” and then the use of these terms in continually more abstract contexts. Below is a quote about halfway through the book:

“A dog taught the action of shaking your hands does not shake your hand. A robot can say words but cannot say them to you.” (51)

This sort of semantic structure full of nearly contradictory statements makes Finite and Infinite Games a difficult book to follow, even when it has something astounding and insightful to offer. Structurally, the book is organized into five parts, but I found these divisions kind of arbitrary. More importantly, all the content in the book is organized into short essays (one-half to two pages in length) that cover a complete thought, totaling 100 discrete philosophical statements. This honestly helps quite a bit with reading comprehension despite the dense, dry, abstract philosophical content.

I have trouble reviewing this book mainly because I can see it have value to those interested in philosophy, but I felt the content was too abstract, too separate from my lived experiences to actually draw any practical knowledge from them. If you are someone who adores theory, then perhaps you will enjoy this book more than I did. I can’t really recommend it, and certainly wouldn’t include it on any reading lists directed towards game developers.

Review: Game Feel by Steve Swink

Book: Game Feel: A Game Designer’s Guide to Virtual Sensation
Author: Steve Swink, independent game designer and academic
Year: 2009

Summary: An excellent deep dive into the topic of “feel”. Required reading if you make fast-paced real-time action games, but a great resource for all designers.

gamefeelGame Feel is one of my favorite game design books, and as far as practical books that improve my games it’s at the very top. “Feel” is a really nebulous, intuition-driven domain of game design and this text attempts to define its boundaries and give designers tools and language to understand and address it in their games. I think it succeeds admirably at this goal.

This is a thick, dense textbook with large pages, lots of text, but broken up with plenty of bullet points, charts, infographics, and annotated screenshots to support the content. I actually want to call out Game Feel as having, hands down, the best charts and infographics I’ve seen in a game design book – both for clarity and usefulness. For better or worse, Game Feel reads like a textbook, so expect to find a lot of introductory content, points repeated throughout, and summaries at the end of every chapter. Unlike a lot of textbooks I didn’t find the writing particularly dry – instead, it’s written in an easy-going and approachable manner while still doing justice to the often technical content. For comparison, I would say the book has a drier tone than Art of Game Design, but much more personable than Rules of Play.

The book can be divided into three main sections: an introduction where Swink defines game feel, several chapters exploring different domains of feel and defining their metrics (input, controls, responsiveness, etc.), and several chapters that act as case studies applying this concept of game feel to well-known games like Super Mario 64.

Game feel, as the author defines it, is a Venn diagram of real-time response, simulated space, and polish. A good portion of the book is devoted to defining these in a very specific manner to give justice to this model of game feel. For example, real-time response doesn’t refer to what we might casually call “real-time”. Instead, it refers specifically to a game that responds within a correction cycle (where a player reads feedback, makes a decision, takes action, and the game reads that action in and delivers new feedback) of under 100 milliseconds (the time required for the computer half of this cycle to occur without any noticeable lag to the player). “Simulated space” specifically refers to a 2D or 3D world with movement and collision, with a sense of speed, gravity, weight, and general physics. (The domain of polish really doesn’t need much elucidation).

There’s really not much in Game Feel that I could call out in criticism. I think it’s really successful as an attempt to put actual metrics behind the vague but familiar phrases like “tight” or “floaty” controls or “unresponsive” movement. Swink goes into a great amount of detail with his examples, such as graphing and explaining the physics behind the feel of a simple jump across different games. As someone whose made a lot of games that fit within his model of game feel, I would say there’s almost equal amounts of retreading familiar ground, expanding upon familiar concepts, and completely new information. Everything in the book also feels practical rather than falling into the familiar trap of theory that has limited real world use.

The author makes sure to point out that whether or not a game fits in the center of this game feel Venn diagram (real-time, simulated space, polish) is not a statement on the quality of the game. While I do recommend the book, keep in mind that it may have limited usefulness if you work doesn’t fall into his model – it’s great for games like platformers, action-adventure, shooters, and racing games, but not so much if your work doesn’t rely on timed reactions or player movement. I think that Game Feel is an excellent book for experienced designers (and other developers) and wouldn’t hesitate to recommend it to my coworkers. I think for students or aspiring designers, as long as you have a firm base on game design (i.e. read one of the fundamentals textbooks) then you should be able to pick up this book with no problem.

Journey Home Dev Update #2: Back to the Drawing Board. Literally.

I promised I would write a blog update once a month on Journey Home (previously). I lied. LIED. I’m a total liar.

Something went terribly wrong, creatively, so I don’t have much to show for my last few months. I took a little time recently to unpack what happened before trying to figure out how to fix it.

What went wrong:

  • I spent too much time in the planning stage, and not enough time in the implementation stage. Normally my side projects have a one-page design doc to work off of and I go right into development. This time I have pages and pages of brainstorms and action items, an excel doc with so many unique tabs, and even a trello schedule I tried setting up. Instead of making the game clearer in my head, it became this massive, unwieldy thing I couldn’t keep track of.
  • I still didn’t know if the game was going to be fun, and whether whole systems I was designing were going to be thrown out. I was afraid to spend the time it would take to prototype these systems (since it required coding knowledge I still don’t have) so I took even more time in planning to try to figure out which of those systems to keep or toss.
  • I attempted to prototype a whole game, rather than make a manageable ‘vertical slice’. All my systems were too integrated that I couldn’t identify the core to create. I couldn’t figure out how to strip it down to something manageable.
  • The game is still not playable. Even now I do not have a working prototype. To be fair, I have a Ren’Py project and a decent amount of coding with something you can click through, but it’s not representative of the gameplay at all.

The longer I went without making a playable version of the game, the bigger the task weighed on me and the less interest I had in the project. This is like a standard list of advice for newbie game designers on what not to do. It kind of goes to show you that even when you have plenty of experience making games you can still fall into the standard traps. My design was completely derailed.

I’m writing about this now because I figured out a way to get back on track.

A few weeks ago I played Eldritch for the first time. It’s a cooperative board game with a lot of pieces, cards and complex systems where players travel the world, discover clues, collect allies and items, and try to prevent the awakening of an Elder One. It took a good five hours before we lost.

I realized something during that game: Journey Home would work really well in that medium since it shares a lot of similar mechanics. Eldritch isn’t the first board game like this that I’ve played, but for some reason I didn’t connect the dots until now. Maybe because I took a long enough break from Journey Home that I could look at it with fresh eyes. Maybe I needed a game as good as Eldritch (it’s really good!) that is always wonderfully complex (lots of if-then statements in cards) to get the ideas rolling in my head.

So I am changing direction a bit and going to adapt my work as a board game – for now. This will help me identify systems more clearly and how they interact with one another and prototype them rapidly in a playable medium. My documentation has shrunk back down to one page again and I can skip the coding that tripped me up in favor of some paper rules a human can follow. I’ve never built a board game before (with one awful exception that shall go unnamed), so in some ways this is new enough territory that I am not falling back on bad habits.

Here’s a bit of progress I’ve made on the board game version. I am keeping it simple right now by making my cards out of the backs of old business cards, and will migrate to better supplies once I run out.

devupdateJourney Home, version 0.1

Some of the pieces I’ve made:

  • Player tokens to represent movement through the jungles
  • Tiles players pull as they explore, representing Jungle, River, or Cave environments
  • Explore Deck, high risk/reward for discovering new environments
  • Forage Deck, low risk/reward for exploring within a previously discovered environment
  • Event Deck, which is probably best called “Catastrophes”. These are new events each round that stack up against the players. They can try to resolve them to get rid of the negative effect, or ignore them, but the longer you play the more catastrophes stack up.
  • Conditions Deck, issues that can effect allies such as poisoned or cannibal
  • Item Deck, low-medium quality items that give bonuses, such as a gun to combat
  • Artifact Deck, high quality items that require skill checks to ‘unlock’ with high risk/reward
  • Character Sheets, with rough ideas on what skills or stats I want in the game (Strength, Survival, Speed, Influence, Lore, Faith, and Health)

Balancing is non-existent. I’m just curious right now about the cadence of play, and am inventing the skill checks and pass/fail scenarios in my head as I step through it. My next goal is to start penciling in those stats onto the cards. Just doing this barebones board game has helped identify a lot of problems – What does it mean to “move” through a space? How long does a catastrophe last? How does the player win or lose? Is it compelling to play in the long run, or does it just get harder and harder until you fail?

I’ve never really done paper prototyping before since I don’t think it’s very useful in the kind of games I normally make – either interactive fiction with minimal systems, or large AAA games that can’t really be distilled into a board game. I don’t think it’s a coincidence that Journey Home is my attempt at a system-centric game and it translates so well to the board game medium.

With that said, I’m going to link to one of my favorite GDC talks, Soren Johnson’s “A Study in Transparency: How Board Games Matter“.

Review: Understanding Comics by Scott McCloud

Book: Understanding Comics: The Invisible Art
Author: Scott McCloud, comics artist/author?
Year: 1993

Summary: An very readable introduction and analysis of the comic book medium, told in the form of a comic book. For designers, it provides a good structure for how to think deeply about any medium, with specific lessons on visual design.


I’m hard pressed to think of a non-game design book that gets recommended to game designers as often as Understanding Comics, and I’ve seen the book more than one designer’s desk. I thoroughly enjoyed it as a text about comics, but not so much as a text for game designers. Instead I’d say you should approach it as a good book for people who create media, rather than one that has any specific lessons for game developer, but I’ll get into that a bit more at the end of the review.

Understanding Comics is a short book (213 pages) with large pages that packs a lot of information, but it’s presentation of that information – in comic book form – makes this an effortless read. The visuals are wonderful and illustrate the concepts in ways that kept my attention (I read this in a single sitting!) and gave me a better understanding than if it were written in the style of a traditional book. I would love to see more serious nonfiction work explored using the comic book medium.

The purpose of the book is to explain comics by giving it form, structure, a shared vocabulary, and generally enlighten readers about the underlining psychology and history of the medium. McCloud gives readers an illustrated definition of comics, grounds it in history (starting with 3,000 year old Mayan texts), explores the relationship between image and text, and goes over specific elements of comics such as showing motion, the use of lines to create emotion, and differences between western and Japanese comic traditions. There’s more, and each subject has its own chapter dedicated to it – with some leaning on prior chapters while others (such as the chapter on color) able to exist on its own.

A few of these concepts are entirely new to me: the gutter, closure, and the use of the iconic form. The gutter is the term for what happens in the space between panels, and closure refers to how our minds often fill in the blanks based on suggestions. While I was vaguely familiar with both of these before, the terms and way the author breaks down their function was invaluable. Last, there’s an entire chapter on the iconic – it’s role in cartoon style, the relationship between realism, pictorial representations, and text – that I think is worth reading in its own right. All three of these feel more in the realm of art direction more than game design, and I could probably describe the book as a giant master class on visual design that happens to use comics as its medium.

Other chapters might resonate a bit more with game developers or gamers. Comics, like games, suffer from a perception that they’re childish, that “cartoony” means “for kids”, that they’re mindless leisure. Comics, like games, is used to refer to both form (comic) and content (superhero stories) interchangeably, and this has held back the growth of the medium. Comics, like games, have to justify that they are art and often find themselves placed outside of that realm. Comics, like games, struggle in defining itself and determining what makes comics unique from other media. And comics, like games, have a sort of order to the creative process that starts at mastering the surface level and continues in layers into craft, structure, form, and so on as the creator digs deeper into the medium.

I think when Understanding Comics was first published in 1993, these lessons may have been new or understated in the games industry, leading game developers to point at this book as a template for how to look at their own medium. Certainly, as far as templates go I think this is one of the best examples of explaining complex ideas with visual information. But by now I feel most of us (or at least I) already understand that games are art, that the medium of games is a formal structure that does not prescribe any specific style of content (see: art games). We have many books – and an entire academic discipline – devoted to understanding the unique and shared elements of games as a medium. This, I think, is why this book didn’t quite resonate with me the way it seems to for many others. These generalized lessons aren’t new to me and while they are presented in a new way I am not, ultimately, thinking about games differently.

I am, though, thinking about comics, cartoons, and art used to convey information VERY differently. As an exploration of visual design and deconstruction of a medium, this resource is absolutely excellent. I think it’s important for designers to know about other fields which is why my library project focuses on “game design (and related fields)” so I definitely appreciate what Understanding Comics has to offer. If I had to pick a book out to give creative professionals a way to understand comics, it would be this one without a doubt. I don’t think I’ll ever read a comic the same way again.

I wouldn’t hesitate to recommend this book to anyone, not because it’s an excellent book for game designers but because it’s an excellent book about media. It’s good for anyone from fan to expert, especially if you are interested in visual design and comic structure. I would probably say it’s required reading for anyone making comic-infographic hybrids I see more and more often on the internet. And lastly, I think it’s great for people who may care for games but not quite grasp how meaningful they are by seeing a similar medium normally treated as idle leisure (comics) deconstructed with such care – in that sense, it’s rather inspirational.

Review: Flow by Mihaly Csikszentmihalyi

Book: Flow: The Psychology of Optimal Experience
Author: Mihaly Csikszentmihalyi, psychologist
Year: First published in 1990, but I read the 2008 reissue with a different forward.

Summary: An important book explaining flow, a concept related to the balance between skill and challenge. However, I recommend skipping the book and just reading the articles instead.


“Flow’ is a term I’ve been reading about at around the same time I entered the game industry. It’s often referenced by game designers, with various articles espousing it, direct references in most (all?) game design textbooks, and academic critiques of the concept. It’s important enough that I believed reading the source material would give me greater insight into flow and how I can use it in my work.

Unfortunately, that was not really the case. While there’s a few new details I learned about flow from reading the book, the bulk of relevant knowledge can be found in the following articles: Jenova Chen’s “Flow in Games“, Sean Baron’s “Cognitive Flow: The Psychology of Great Game Design” and countless others written by game designers that are floating around the internet. I recommend skipping the book (unless you want to check it off from your list like I did) and just read the articles. That said, this whole series is about reviewing game design books, so I’ll get into that now.

Flow: The Psychology of Optimal Experience isn’t particularly long at 240 pages, though the text is compact and the content very dry, dense, and – unfortunately – boring. If flow is supposed to be a state of rapt focus and attention, this book definitely failed to induce it in me.

The content of the book revolves around (unsurprisingly) the concept of flow. For those unfamiliar, a flow state is a perfect balance between skill and challenge that allows people to achieve a very fulfilling, engaging, and focused mental state. Too much challenge leads to anxiety, and too little leads to boredom. Everyone, I think, can recognize the flow state in their own lives. Think of a situation where you are so engrossed in what you’re doing – running, painting, working, reading, anything – that you aren’t consciously aware of what’s around you or the passage of time. This obviously has applications to games – challenge, skill, dynamic difficulty adjustments, pacing, immersion, and fun are all influenced by it.

The key elements of flow don’t differ from other articles, so I won’t repeat them (please read the articles instead). One detail of flow that I find interesting is that it requires internal, self-driven goals – not external goals or rewards. This leads me to think that most games run counter to a flow state, since they are very focused on those external goals to keep players moving (objectives, collectibles, achievements, scores, etc.). Players who want a real flow state need to bring their own goals into the game, not let the game lead them along – so think of Minecraft creations, speed-running, and self-imposed pacifist runs in violent action games.

Another element that strikes me is that that one of the ways to distinguish mindless leisure from a flow state is that with the latter your consciousness becomes more complex as a result. This is hard to explain but essentially the idea is that when you enter the flow state you are at a balance where challenges appropriately match your skills and you develop or mature by engaging in it. This helps identify, say, mindless grinding for loot in an MMO with much more focused goals (which may include grinding, just not mindlessly done) that lead to a more complex consciousness as you internalize new skills, knowledge, or extend your goals.

Flow covers this concept in detail in chapters three and four and then the author spends the rest of the book discussing examples of the flow state in the lives of many people he has interviewed and even pulling from historical records. These examples include everything from assembly line workers, to surgeons, to chefs, to rock climbers, to people who live solitary lives in hard, back-breaking work. He categorizes them as physical, mental and social sources of flow and takes pains to explain how different people reach their flow state in different ways.

These chapters don’t really add a lot to a game designer’s repertoire. They mostly consist of anecdotes, survey responses, and sort of a long, dry list of examples to back up the importance of flow and how happiness is not tied to income or material needs but rather being in a state of flow. This emphasis on happiness, on the harm of “psychic entropy” (the opposite of flow), and so on makes the book read similar to a self-help book yet the author provides no practical way of putting the content into practice. As a game designer, I wanted a book that could help me structure experiences to create that flow state in others. Instead, I learned that if I want to be happy, I should pursue flow, and a long list of examples of people who’ve done that.

So far of the books I’ve read for this Game Design Library, I liked Flow the least. It was not practical, it didn’t provide me with all that much insight, and I found the author’s writing style very dry and boring. I hesitate to recommend it, and I am honestly not sure who would find the book helpful. Csikszentmihalyi has written other books, including one about flow in creativity that may be more relevant to creative professionals, but I am skeptical after this experience.