Chefs, creativity, diversity, and our old friend risk

Posted September 13, 2015 by Mike Sellers
Categories: Uncategorized

I’m on the outbound leg of a trip from the US to Sweden for the Sweden Game Conference. On the plane from Chicago to Frankfurt I watched the movie “Chef” again. It’s a small but worthwhile movie directed by and starring Jon Favreau. He plays an accomplished chef who is sick and tired of having to cook the same old menu over and over again. He’s lorded over by his money-guy who just wants butts-in-seats and for the chef to give people the mainstream fare they want. This results in a disastrous review, and the chef eventually flips out and leaves. He then goes on a journey of self (and family) discovery, and ends up  opening a small food truck that gathers a big online following.

So you can see, this is really a post-Iron Man/Avengers movie about making movies. It suits the making of games equally well — with the exception of the “all’s well that ends well” ending that most movie and game creators don’t experience.

Which brings me to this article from the Guardian. I fully agree that our range of “acceptable” game genres has narrowed to the point that our diversity issues go far, far beyond “we don’t have enough women represented in games.”  The result of this is that I often don’t find much that’s really interesting to play — and those games that do catch my imagination (and dollars) are often the smaller indie efforts – FTL, Banished, Sunless Sea, Prune, and most recently Kings Quest, which at least feels like an indie effort (which is an accomplishment for the developers in today’s environment).

Like many others, I believe that we are far too insular in many parts of game development, and that increasing our underheard voices (including but not only women) has been a distressing serial failure. As the Guardian article points out though, our lack of diversity extends far beyond how women are represented in games or how many women we have in leadership positions in game development. This narrowing extends well into the kinds of games that get made — and thus the kinds of games that get played. The developers often serve a narrow audience, which further narrows the demographic pool of people who are interested in game development, which sets off a vicious cycle.

In the middle of this though is the problem that game developers, like anyone else, want to be paid for their work. Absent a wealthy and disinterested patron (please let me know if you find one of those), being paid requires running a business — and games are most definitely a business. Businesses are necessarily risk averse; the chances of complete failure are just too high otherwise. Creativity and diversity are inherently risky. Therefore most successful game companies will avoid creativity and diversity as much as possible, and in doing so end up contributing to the (at best) reluctant relationship with diversity, and the narrowing palette of game genres deemed worthy of consideration.

TL;DR: We want to be creative and diverse, but all the necessities of making games professionally are set against this.

What to do about this? I don’t know. I don’t have any answers.

I have a few hopes and hypotheses: for example that as we increase the diversity in the pool of developers, we’ll find new ways to make games without increasing our risk — and that maybe, just maybe, some of the wildly successful game companies we see today will look past their IPO or current stock price (I can dream) and actually invest a certain amount of their healthy profits on on-going,long-term R&D. You know, the kinds of things that fail a lot, but eventually give us iPhones, self-driving cars, or the ability to choose from dozens of movies on a trans-Atlantic flight — the very kinds of investment most game companies have little interest in making.

Systems, game systems, and systemic games

Posted May 18, 2015 by Mike Sellers
Categories: systems design

Tags: ,

Systems are a big deal — they’re much more pervasive and important than games. But, for reasons I’ll get to later, I believe that games, and game design in particular, are a uniquely effective avenue for understanding what systems are and why they’re important.

A full discussion of what systems are is beyond the scope of one blog post. But I want to lay out some basics as the foundation for some later posts. This may be a bit abstract at first, but I’ll bring it back to games in a way that I believe illuminates important parts of game design.

All systems have a few things in common: a system is made of parts that interact to form a purposeful whole. There’s a lot packed in there, so let’s take that bit by bit.

Each ‘part’ in a system can be thought of an object in software terms, with its own state (defined by attributes) and behavior. Importantly, this definition is recursive: each part is itself a whole, a sub-system, with its own internal workings: a part’s attributes are themselves objects with their own states, attributes, and behaviors. This recursive nature is vital to understand and can also be a little dizzying. We often want to cling to (or design to!) a single level of interactions without any additional structure. This leads to a poor understanding of systems and how the world works, and to shallow, lackluster gameplay. In terms of thinking about systems, just remember that whenever you’re looking at a system, there are parts within it to be unpacked — and the system is itself just a part of a larger system.

The behavior of an object in a system may change its own state, and it may communicate with other objects, potentially changing their state and behavior. This communication is the interaction between parts mentioned above. While objects interact, not all objects in a system interact equally often. As is often seen in any network, there are dense interactions between some objects, and far fewer between others. This has the effect of forming hierarchies: dense connections of interactions between one set of objects creates, implicitly or explicitly, a boundary that defines a super-object at the next level up in the hierarchy.

The result of this is that two or more sub-systems (with their own internal sub-systems) interact in ways that create a holistic system and drive the whole system forward with purposeful behavior. “Forward” might be a bacterium traveling along a sugar gradient, a football team traveling down-field, a school of fish evading a predator, or a game player working toward domination of a game world. In each of those, the “system” is a complex whole made up of parts acting together: the bacterium, the football team, the school of fish, and the combination of game and player.

That last example brings up an important point: while we often talk about combat systems, skill systems, etc., in games, we have to remember that the overall system that creates the experience of playing a game involves at least two important sub-systems: the game, and the player (or players!). Each is a complex sub-system with its own internal objects, states, and behaviors; and each interacts with the other to create the overall system of “the game being played.” The game systems are sub-systems within the game that interact together and with the player as the game is played.

This brings us to the last part of the definition I gave above, that of “a purposeful whole.” Systems are often spoken of as having a purpose or teleology: fish avoiding a predator, a football team moving the ball downfield, etc. In a similar way, games are designed to create a particular kind of experience through the use of their internal sub-systems, but it is the system overall, the combination of game and player, that bring that experience to life. That experience is the purpose, the meaning, of any game.

So what is a game system? And how does this relate to what we might call systemic games?

Here I’m going to turn to the MDA framework (or alternatively, its closely parallel cousin the Function-Behavior-Structure ontological framework) as scaffolding for talking about game systems.

In these terms, the mechanics (or structure) of a game system are its objects and their attributes. These are, for example, the pieces on the chessboard or the weapons in an RPG and, just as important, their current state (location on the board, amount of durability) and their behavior (how each chess piece moves, or how a rapier, longbow, or broadsword attack).

The dynamics or behavior of a game system are the events and actions that emerge as the result of game-based objects interacting (though remember that dynamics at one level create the mechanics of the aggregated parts at the next system-level up). As one example, “dribbling” was not found in the original rules of basketball, and didn’t appear as an acknowledged part of the game until several years after its introduction. Players could pass the ball to others to move it down court, and they eventually discovered they could also pass the ball to themselves by bouncing it on the floor as they advanced, passing it back to their own hand. Dribbling is a dynamic behavior that emerges from the mechanics in the stated rules of the game. Creating similar dynamics, as by combining the roles of tank, DPS, and healer characters in many MMOs, is an important part of game systems design. If the game objects don’t create any new, significant combined effects — if each object works pretty much on its own with little value gained by interacting with others — then the game system (if it’s a system at all!) is not likely to engage players for long.

Finally, the aesthetics or function of a system refer to the system’s purpose, or in game terms, the desired experience for the players: the game may engender feelings of achievement, fast-paced action, of hypnotic flow, terror, love, companionship, loss, wonder, etc. This experience requires the interactions of multiple game sub-system and the game and player as sub-systems within an overall system of the game experience.

In these terms then, a game system has well-defined objects with their own (typically recursively defined) attributes, state, and behaviors. Those objects have to interact in ways sufficient to create new aggregate behaviors (the dynamics) that support the creation of a particular game experience. The object interactions aren’t random; they’re carefully constructed to create dependencies between the objects in ways that evoke meaningful dynamics in their combined use. If an object isn’t used in combination with others; or if a mechanic doesn’t support some larger-scope game behavior; or if the in-game behaviors don’t create a cohesive experience for the player — then your system is failing. It lacks purpose (aka teleology, function, aesthetic), and you need to work on the pieces that make it up and how they interact.

It’s worth noting that it can be incredibly difficult to keep this all in your head (or even in your design docs!) at the same time — being able to go from “we have these mechanics to create these dynamics in support of this player experience” taxes the abilities of almost any designer. In my experience, different designers gravitate toward one part of that — usually mechanics or aesthetics — at the expense of others. Some designers are all about the “nouns and verbs” of a design, but don’t really have a solid, intuitive feeling for what kind of game experience the nouns and verbs will create. Others know exactly the feeling, the experience, they want to devise, but are fuzzy on exactly what that means in terms of the specific underlying mechanics that will get them there.

The necessity of being a game designer who can span this range was summed up nicely by Paul Stephanouk (@gamegeek) who said that a systems designer should be able “to turn a game into a spreadsheet and a spreadsheet into a game.”

Okay, given all that, what about systemic games? These are games that depend on their internal sub-systems to generate repeatable, engaging gameplay for the player(s). The most common of these currently are those often called “roguelikes” due to the fact that they procedurally re-generate the game world each time, providing at least some amount of novelty and engagement.

Compare that with other games (often high-end AAA console games) that depend on carefully crafted, often beautiful, and generally expensive set piece levels, characters, cut-scenes, and/or scnearios to create gameplay. These present the same gameplay the to the player each time, with at most minor variations in play. There may be a “combat system” for example, but this often isn’t really much of a system: there’s one sniper rifle that beats the others, one shotgun to use close, a machine gun that does lots of damage, etc. In many role-playing games, players quickly gravitate toward the one best “character build” for making the most effective tank, DPS, healer, etc. And in many strategy games there are at most two or three well-honed ways of playing to win, and all others are doomed to failure. In games designed like this there are game objects but few interactions that support different and effective strategies for playing the game. There are choices for the player, but they quickly separate into “effective” and “ineffective,” with the latter leaving the player frustrated (why have a choice in the game if it only leads to sub-optimal gameplay?). Or there might be endless combinations of objects (as in Borderlands’ or Diablo’s weapons), but these only sometimes create interesting (game-relevant) dynamics, as the interactions between random weapons-parts are too broad and not systemically deep.

Another example that I think sometimes trips up game designers are designer-systems that don’t result in game-systems. For example, World of Warcraft has a complicated and effective quest-creation system — if you’re one of the designers. If you’re a player, the result is much like the set pieces described above: the same quests always contain to the same obstacles and rewards, and lead to the same follow-on quests. As a player these are great for awhile, until you realize that at level 90 you’re still doing essentially the same thing you did at level 1, but the rats you have to fight to bring back ten of their tails are just bigger and meaner. There is a system in there for the designers that helps them create a complicated (but not complex) network of quests. For the players, there are no quest dynamics, as the interactions are all frozen at design time. There are pre-defined quest lines, but no interactive quest system.

Systemic games, by contrast, rely on interactions between game objects, from the setting to available weapons or tools. These are generated new each time the game is played based on underlying algorithms and systemic interactions. This necessarily means the game designers can’t depend on expensive, static set pieces, and so must lean more heavily on the dynamics created by the interactions between game objects and their mechanics.  It also means the designers have to create their actual game system — the system that, via its sub-systems, creates the game-to-be-played each time — in such a way that it will provide both systemic variability and maintain a satisfying desired aesthetic each time.

As difficult as this is, when it works, it works extremely well, creating highly replayable games with great longevity. That leads us to the concept of game depth — but that will have to wait for another (hopefully shorter!) post.

What Makes Game Design Unique?

Posted May 1, 2015 by Mike Sellers
Categories: game design, theory

Tags: , ,

I want to test a pair of assertions: I’ve said for a long time that there are two main things that make games different from anything else that’s “designed.”

The first is that no one has to play a game.

The second is that unlike any other device or software, games are entirely autotelic: the goal of a game is the goal set within the game (or within the player’s head). Games don’t exist to extend, assist, or support some external goal.

Those may not seem like much, but they create conditions that set games wholly apart from any other kind of human creation, and game design apart from any other kind of design. I think this leads in useful directions, but first I want to explore and test these assertions.

First, no one has to play a game. By contrast, if your company adopts new software for accounting or travel, you pretty much have to use it. If your bank changes how their ATMs work, you’re going to get used to it (or switch banks). But with a game, if you don’t like it or don’t get it, you can drop it — the game is entirely optional.

This means that game designers are constantly on the knife-edge in ways that other designers aren’t. Games have to attract a potential player’s attention. They have to draw the player in, help them build a mental model of what the game presents, and make that engaging enough that the player will stick with it and want to put in the energy needed to gain some level of mastery. This means that games are under immense pressure to evolve as fast as possible. There are always other games (now, hundreds of new ones appearing every day for mobile devices) that players can turn to, aside from anything in the player’s life that they have to do.

As a result, game designers spend a lot of time playing games designed by others to learn from them and apply their lessons to their own games. It’s no wonder that games change so rapidly and continuously, or that they consistently lead other forms of technology in the use of graphics, hardware, engagement, narrative, and interaction design.

The second point may be even more important: games are autotelic. Spreadsheets and word processors exist to support an external goal; so do paint programs, flight and process control software, etc. Even in the physical world, hammers, saws, drills, backhoes, scalpels, door handles and everything else you interact with on a daily basis that has been designed exists to further some goal that is external to the artifact themselves. Art, in the sense of paintings, literature, and sculpture, are, like games, concerned only with the goal that the artist sets for them. But unlike games they stand on their own; they are not truly interactive (a statement some will take issue with, but this is a different and longer argument). An artwork may engage someone mentally and emotionally, but it does not create a set of goals and tasks for the viewer. Since only games are both autotelic and interactive, only they enable the player to fulfill some set of goals, changing as the player changes, continually leading them to new internally defined goals.

In the realm of software in particular, only games (and toy-like games in which the player sets their own goals) escape serving some external and pre-existing set of goals and tasks. As a result, there is no “task analysis” that can yield a set of requirements for a game; part of the game designer’s job is to create the player’s tasks and goals out of thin air. Sometimes these may refer to some approximation of the real world (as in a flight simulator), but in some of the most charming examples they have only a tenuous connection to anything like our world, as in Ida’s curious journey in Monument Valley.

If these assertions are accurate, they have huge consequences for how we think about and practice game design, and for the place of game design in the overall sphere of design as practice and as a way of thinking. Games may, I believe, provide us a window into a kind of pure design, unencumbered by pre-defined external goals and tasks. If so, they also illuminate some important aspects of design and how we structure our thinking far beyond games and about the world in general. This is a point I’ll pick up later.

What do you think? Are these assertions accurate? Are there examples of non-game artifacts that are optional and autotelic? Are there other important differences between games and non-game artifacts, or between game design and other kinds of design? Or, are these statements correct as far as they go, but they miss something essential?

I look forward to hearing others’ thoughts on this.

Artisanal Game Development

Posted April 28, 2015 by Mike Sellers
Categories: game development


“Tabletop games are to computer games as plays are to movies.”

This is something I’ve been saying for awhile, with an echo of Terrance Mann’s “movies will make you famous; television will make you rich; but theatre will make you good.” For a game designer, I’m increasingly convinced that there are few ways to better hone design skills than by creating tabletop games. When the only computer available is in the players’ heads, this restricts how much you can hide bad game design behind glitzy graphics or mountains of bookkeeping.

A couple of weekends ago I spent an incredibly enjoyable, exhausting, and enlightening time at Protospiel in Milwaukee WI. This was a gathering of fifty or so game designers and playtesters. I tested my in-process game a couple of times and reaped a wealth of terrific feedback. Playtesting is almost always useful, but this was like tapping into some mainline of game design thought and knowledge.

I should say that I also played a bunch of others’ games. That’s the magic of Protospiel: almost everyone brought a game (or more than one) to test with others, and played others games in turn. The variety of games was huge, from a truly elegant Love Letter-like game (with even fewer cards and possibly more strategy) to an educational (but still fun) game about the invasion of mussels and algae in the great lakes, to games with seeds and zombies and prison breaks and a bunch of other stuff.

Few of those there were full-time game developers; most had day jobs unrelated to games. And yet the quality of games in development was what I would expect from a “professional” gathering. Moreover the dedication to making a good game was equally high, as was the ethos of giving constructive, insightful, egoless feedback to others. Each person I saw or overheard recognized the strengths of a given game along with its rough spots — and inherently the work it took to get the game to where it was.

This, I think, is what I would call artisanal game design. Games made with care, craft, and pride. And in physical, table-top form, and therefore forced into as much design elegance as possible. Many of these are games that the designers hope to sell, so this isn’t some anti-commercial endeavor. On the other hand, this is the furthest thing from being some slick start-up ploy to build and flip a company as fast as you can without real regard for the product you’re making.

I think this is a useful return to the roots of modern game development. I’m sure this is a highly effective way to hone skill in game design. Whether it’s a way that someone could build a career (or even a viable second income stream) remains to be seen.

Complicated vs. Complex: Why Game Development is Hard

Posted April 11, 2015 by Mike Sellers
Categories: games, industry

Tags: , ,

Developing a game is difficult, to put it mildly. And it never quite comes out the way you plan. Despite this, many developers and (especially) project managers — smart, talented, ferociously hard-working people — continue to believe that somehow this time they’ll make the right schedule and be able to predict months in advance when their game will launch.

This never works (okay, unless you’re just copying someone else’s game). And yet, project leaders continue to create Gantt charts of doom, or to try out one production methodology or another in hopes of making game development predictable. As one pervasive example, Agile/Scrum has long been touted as the way to successfully develop a game. Unfortunately, as some have long suspected and recent data has shown, using Agile isn’t a predictor of game development success (but see below). In fact it scores about as well as using a traditional (and long-reviled) Waterfall process!

Okay, so making a game is hard. Really hard. We all know that. But why? And what can we do about it? Read the rest of this post »

Adding Debt to your Daily Scrum

Posted April 7, 2015 by Mike Sellers
Categories: Agile, game development

Tags: ,

Debt in a project (technical or otherwise) is something no one wants in a project.  But I believe it belongs in every Daily Scrum / Stand-up meeting.

Everyone who uses Agile/Scrum knows the the three big questions used in a Daily Scrum or Stand-up meeting:

  • What did I finish yesterday?
  • What am I working on today?
  • What is blocking my progress?

These questions are meant to be the daily pulse of the project. Among other things, this short meeting is how you (as project leader or Scrum master) spot the trouble spots before they become crises.

But a few years ago I noticed — after being stung by it a few times — that there was a question missing. So I’ve added a fourth question that everyone is expected to answer in daily Standups:

  • What debt have I incurred?

I added this to our meetings after noticing that sometimes a task would be called “finished,” would be moved to testing and then acceptance — only to find out later that, in order to make the original time assessment and get the task (and user story/feature) into the current Sprint, someone had to cut corners: some temporary art was used, a bit of unfinished design was papered over, or a single-use function was quickly created, knowing that it would have to be refactored later.

Ideally when this happens, a new task should be added to the backlog to be addressed later — that would keep the debt transparent. But in my experience this often does not happen, whether due to the intense focus in mid-Sprint or the reluctance of someone to point out that their task isn’t really finished.

So, I started including the debt question to be answered by everyone every day. It takes only a moment to answer, so it’s not in danger of burdening the brevity of the meeting. It’s also not always the most comfortable question to answer — no one likes to admit that they had to take a shortcut that’s going to need attention later. But it also gives team members a natural outlet that’s just part of the process to bring this up. Doing so gives everyone a more accurate picture of what actually remains to be done, and just as importantly, helps refine future task scheduling. Most of all, it prevents the dread of instabilities or unfinished bits lurking in the shadows as you come to a release.

Finally, having an open understanding of any debt incurred helps you as a manager spot those who are making a habit of cutting corners and help them to move past it. Left unaddressed, this practice can ultimately undermine the product, making it less robust or require a surprising amount of time in “bug fixing” (when a lot of debt is often silently taken care of). Helping those on your team estimate tasks more effectively, not cut corners — or do so judiciously and consciously — and ultimately make a better, more stable product is good for everyone. Even if it can cause a bit of squirming in a daily meeting.

The Next Book You Should Read

Posted April 6, 2015 by Mike Sellers
Categories: industry, practice

Tags: , , ,

This is a post I’ve been meaning to write for a long time, and its time may have passed. But I keep finding people who haven’t read Ed Catmull’s Creativity, Inc.. If you’re someone who leads creative teams (or is just interested in how this is done), this book should be next on your list. In fact, set aside whatever management book you’re reading now and go get this one. It’ll be better.

Ed Catmull is the President of Pixar, and according to many is largely responsible for its continued success in delivering movie after movie that are both commercial and creative hits. In this book he goes through war stories and “lessons learned” that will be familiar to anyone who’s ever read a leadership or management book. But Catmull adds to this his unique perspective applicable to leading teams that have to be both outstandingly creative and also commercially successful. How to do this is, to point a finer point on it, something that the games industry has yet to figure out.

Among the worthwhile points made in the book are some specific practices that I believe can benefit any creative team, if their management will implement them — and stick to them. The last chapter (actually after the Afterword), “Starting Points,” offers “Thoughts for Managing a Creative Culture.” any of which are useful on their own. You’ve no doubt seen many of these before, but reading about them in context and in actual use at Pixar gives them new life.

The Braintrust
To me the single best practice that I got out of this book was the use and structure of Pixar’s Braintrust. This is a group of people — all experienced enough to get out of their own way and act in a service position rather than feeding their own egos — who review and help develop each of their movies from initial pitch to final cut.

But here’s the significant thing: this isn’t an “executive review committee” that each director comes before as a supplicant, waiting for approval or the ax to fall. It’s not where business decisions are made. It’s not even where creative decisions are made. The Braintrust reviews a movie in progress (and they must be seasoned enough to see past rough cuts) and calls out issues they see. But then they don’t try to fix them. They may not even offer solutions. The director is responsible for taking the feedback and figuring out how best to address it. There’s a story in the book, for example, about a problematic scene in The Incredibles (p102-103). The group discussed the problem, and then later the director returned with a solution that none of them had foreseen — or that anyone would have seen in a typical “management” meeting.

Feeding the Beast and nurturing Ugly Babies
Another key idea that resonates well with any creative team is that of the “Ugly Baby” vs. “the Beast” (pp 129-138).  “The Beast” is that which must be fed — the never-ending pressure and need for commercially viable products. “You’ve got to to feed the beast.” We’ve either all heard that or lived it, often sacrificing creativity and originality to do so — which is how Disney churned out a series of lackluster movies years ago, and how many game studios continue to pump out a seemingly unending array of uninspiring games. The “ugly baby” is a reference to how almost any new idea is at first “awkward and unformed, vulnerable and incomplete.” As Catmull says, these need to be nurtured, but this is in opposition to the needs of the Beast. Which is why we in games so often kill our ugly babies.

As one example, he details the development of the movie Up. The movie as pitched was nothing like it is now: the story originally began with a king and his two sons living in a castle in the sky. The princes, who hate each other, fall off the cloud and land on earth. There they have to learn the lessons of life, and in the process are befriended by a strange tall bird.

As you can imagine, the movie went through many, many iterations to get from there to the masterpiece we have today. In fact, Catmull says, the only two things to survive the entire process are the title and the tall bird. The director, Pete Docter, went through revision after revision, eventually converging on the story and world he and his team wanted to bring to light. Docter’s comments in the book on the difficulty and necessity of failure in finding the right story are illuminating.

I could go on, but I’ll end this with one final quote from the book about failure and the desire management often has to control everything in the creative process:

Whether you’re coming up with a fashion line or an ad campaign or a car design, the creative process is an expensive undertaking, and blind alleys and unforeseen snafus inevitably drive up your costs. The stakes are so high, and the crises that pop up can be so unpredictable, that we try to exert control. the potential cost of failure appears far more damaging than that of micromanaging. But if we shun such necessary investment — tightening up controls because we fear the risk of being exposed for having made a bad bet — we become the kind of rigid thinkers and managers who impede creativity.

If you are someone who leads creative teams, or who ever hopes to do so, I cannot recommend this book highly enough. And by the looks of the mountain of creatively vacant products our industry (and others like it) continues to drive to the market day after day, the wisdom accumulated by Catmull and Pixar is something we desperately need.


Get every new post delivered to your Inbox.

Join 378 other followers