I just finished reading Tynan Sylvester's Designing Games. The book was published in 2013, but Sylvester is probably best known as the creator of Rimworld, which came out a few years later and is not mentioned in the book. I have read many game design books, but I still learned a lot from this one. This inspired me to share some of my notes here.
Sylvester's core conceit is that games are artificial systems for generating experiences. He presents a model early in the book that undergirds the rest of the text, that a game provides mechanics wrapped in fiction, which produces events with fictional meaning, which produces emotions, which leads to an experience. I am a collector of definitions for "game," and I think this may be the strongest formalized definition I have encountered. I appreciate that it highlights what makes games different from other media, which is a theme that also comes up frequently in the text.
An early chapter discusses emotions and their role in game design. He uses the term "human values" to refer to anything that is important to humans that can move through multiple states, such as life/death, victory/defeat, and friend/stranger/enemy. I am not keen on his terminology here since it sounds relevant to morals or ethics, but I like the hook for thinking about design. It reminds me of the binary opposites that are essential to imaginative education. Sylvester provides a catalog of emotional triggers that can be used here, each of which is given appropriate exposition in the text: learning, character arcs, challenge, social interaction, acquisition, music, spectacle, beauty, environment, newfangled technology, primal threats, and sexual signals.
I would have preferred that Sylvester give more precise definitions around his use of "elegance" and "emergence" since he does not adequately address Kate Compton's 10,000 bowls of oatmeal problem. It's one of a few chapters where I wondered how Sylvester might approach a second edition. No Man's Sky came out a few years after the book was published, and Sylvester's own work on procedural storytelling undoubtedly gave him new insights into these ideas.
Sylvester uses apophenia to describe how humans find patterns in noise, but I wonder if he uses it a bit too broadly. Apophenia describes phenomena like "lucky streaks" in gambling. Seeing a face in the clouds strikes me as different because our visual cortex is programmed specifically to find faces. Similarly, anthropomorphising a non-human character seems like it appeals to our narrative sense, not to a matter of pattern-matching. I wanted to track this observation from my notebook because it's an area where I think precision matters, but I realize I am not completely confident in my own ability to describe the edges of these concepts.
The need for frequent playtesting also recurs throughout the book. I am glad that it does since it is such fundamental advice. In his discussion of balance, he points out that what we should be gathering from playtesting is experiences and not suggestions. Again, the essence of this advice is the same in any game design text, but Sylvester presents it with admirable clarity and succinctness, especially given that he is working within a specific and explicit definition for "experiences." He points out that each playtest is a story, but you need to playtest until you can see past the stories into the systems. This gives me an interesting heuristic that I plan to share with my game production students.
His chapter on multiplayer games includes a section on game theory. I am no expert in this area, and I appreciate his layman's covering of Nash equilibria. He points out that the structure of rock-paper-scissors is the only elegant symmetric game without pure Nash equilibria and matching pennies is the only elegant asymmetric game without pure Nash equilibria. All other (game theoretic) games add more entries to the decision matrix without fundamentally changing the structure and are therefore inelegant. I don't usually turn to game theory in my designs, but I enjoyed this section for its clarity and perspective.
I was a little surprised to see him adopt the term Yomi from David Sirlin to describe how players "read" each other—how they predict, deceive, and outwit each other in multiplayer games. I used to follow Sirlin more closely, and I recently uncovered my copy of Flash Duel. It was fun to see his name show up, and I see he's working on a second version of the eponymous Yomi.
I am guilty of colloquially referring to dopamine as a pleasure-causing drug, but Sylvester is more careful in the book to distinguish between motivation and pleasure. Dopamine causes motivation, not pleasure. Remove dopamine from rats, and they will do nothing, not even eat, even though they can still enjoy sugar syrup that is fed to them. It is an important distinction and one I should be careful not to blur since this biochemical understanding allows us to talk more clearly about how games can motivate us to play past the point of enjoyment.
The third and final part of the book is devoted to process. I expected a recommended series of steps to create a game as offered by other texts. Instead, Sylvester opens the section by pointing out that a lot of our terms around process and management are actually borrowed from other disciplines: director, preproduction/production/postproduction. Here, he applies a similar perspective to the process design problem as he does to the rest of game design. One needs to recognize assumptions and evaluate them, realistically but not cynically. Although he is right, also later uses terms like "production" as if we all know what they mean, and I found myself wishing he was more prescriptive here like he was in the section on emotions and experience.
His advice on process comes down to the same observation made by the signatories of the Manifesto for Agile Software Development: work in tight iterations with good feedback loops. This appeals to my sense of lean production, that we should only as much management as necessary. When it comes to sequencing, his advice is to figure out the dependencies among needs and then work upward from there. Here, I would augment his advice with some observations from story maps a la Jeff Patton, but I don't disagree with him. Sylvester is explicit about keeping the game as low fidelity (that is, grayboxing) as possible throughout so that time is not wasted re-creating assets. He mentions that working with an artist or level designer is important, but he is mum about what those other folks might be doing while this grayboxing is going on. I would have liked to know his thoughts about this, given that I mentor fixed-staff student teams.
The chapter on authority is beautiful, and I plan to use it as an assigned reading. Although he does not use these terms, what he describes is an approach to creative management rooted in natural law and subsidiarity. In particular, he talks about how a team member has natural authority over their work, and how it is a mistake to arrogate that. (Note: I learned the word "arrogate" from reading this book even though I've been battling arrogators in ISS Vanguard for some time without looking it up.) This chapter dovetails nicely with the next, which is on motivation. It is clear that he believes the only way a team can succeed is in an environment of trust and respect. Indeed, he goes so far as to say that one can only succeed by "getting people you can trust and then trust them." I used to recruit undergraduates for special community-engaged game development projects, but now, any student can elect into the game development track that puts them into the game production sequence; I am not sure what it implies for my teaching if Sylvester is right.
Speaking of teaching, I am reminded of the essential challenges presented by the need to grade students in creative projects. Grades are an external reward, and we know that external rewards can kill intrinsic motivation. What then is a professor to do?
One of the final points in the book is that the best way to motivate a creative person is to ensure that they have constant, small, visible progress. This is the progress principle. It turns my mind again toward considering physical task boards to replace the convenient digital ones my teams used the last two years.
I thoroughly enjoyed the book, and I am grateful for how much I learned from it. I will certainly return to my notes once I start pulling together my plans for the next game production sequence, assuming I get assigned to teach a section or two. The book inspires me to draw more from my own learning to build a process that I believe in, which will be easier after having stepped away from team-teaching for now. I am not sure how much of the book would resonate with beginning designers, who, in my experience, need more structured explanation and exercises to get them into the right mindset. I think it's a valuable reading for someone who has already moved beyond the amateur steps though, once one has come to tacitly understand iteration and the challenges of communciation and motivation.
No comments:
Post a Comment