a series of small challenges is perhaps not ideal for this format, because players don’t get a chance to settle and really understand what they’re doing. next time, it would be interesting to focus on a single, central mechanic: perhaps something currency-based.

when designing experiences that need to be communicated across multiple tiers of execution (designer—>director—>actor), it would be useful to accompany directions with an explanation of design choices.

do people want adventures, or do they want rides? even an MMO or open-ended RPG is carefully crafted to whisk people along predesignated flows of activity; it’s the big set pieces and the scripted conversations that get remembered, not the hours of aimless wandering around and killing monsters to afford a weapon upgrade. when people ask for choice, are they really actually asking for the ILLUSION of choice? “I want to feel like I’m making a difference, but you’d better be damn sure that the difference I’m making is interesting and compelling with lots of cool stuff that happens as a result.”

Games are generally all about learning through failure, building skills, and achieving mastery over time and repeated attempts. What do you do when you make a game that is only played once? That’s what I’m dealing with right now. Actually, come to think of it, I’ve been dealing with it repeatedly, for a long time.

Presumably you have to put more emphasis on the experience as its own ends, rather than a pathway to “winning”. Of course, failure is failure and people generally don’t like that. Do you make failure impossible? Do you pepper the experience with enough inevitable small victories that it all averages out? Perhaps failure needs to be simply another fork in the trail, no less desirable in the long-run than winning. Or, perhaps you just tell the players that failing is part of life, and suck it up, and this is art goddammit.

The experience of being a game creator is fairly novel compared to other media. One part of that is working right alongside the pioneers of the craft, who are all very much alive and mostly pretty young; which is quite a different situation than in, say, film, where many or most of the trailblazers are dead or dying, and the community of experts has become broadly distributed amongst a practically infinite number of film festivals, college courses, and what not. 

I mention this because it leads to a lot of “community”, which is mostly quite a good thing, but can sometimes be mistaken for a cult of personality, which is sometimes weird and uncomfortable when the people who everyone is talking about are (a) your contemporaries, and (b) hopelessly outclass you. Do I really need to know who Jason Rohrer is, and what he thinks? Yes, it’s a good idea to play his games. But do I have to watch his GDC talks? Do I have to watch the five thousand other GDC talks? 

Of course there’s no good argument against any of things, because knowledge is good and community is good and so on. But as a creator, as someone struggling, essentially, to become these people, I find that participating in this culture makes it difficult to actually create. There is such a constant stream of news and conversation in the community that it is very easy to become completely subsumed in it. Ultimately, I find the only way I can remain productive to completely turn off, tune out, and focus on my own work—and occasionally come up for air when I’m in between projects.

I’ve been reading lots of editorials recently about modern games being “dumbed down” and skill gaps being compressed. This has been pretty undeniably going on, but I reject the apparently a priori assumption that this is a bad thing. There’s a missing discussion about the purpose of making and playing games, here.

Playing a game is a pretty meaningless act in itself. Climbing to the top of a leaderboard betters no aspect of the world or of yourself… unless you derive satisfaction, enjoyment, self-esteem, or whatever from the act. Doing well at a game, like any other entertainment or artistic experience, is first and foremost meant to elicit an emotion or thought. The means to that end is far from a relevant, but it’s a fatal mistake to assume that the means are the ends. 

Learning and mastering skills in a game is one way to achieve certain desirable feelings. There are plenty of other ways. Arguably better ways—less frustrating ways. Granted, achieving gratification through hard work and mastery is more character-building than the alternatives, but the reality is that games are (almost always) just entertainment. Pretending otherwise is awfully myopic.

New, natural interfaces—touch, motion, etc.—come with a lot more ambiguity in input and control. Users can develop idiosyncratic techniques and tendencies around their input, which makes planning a good control scheme a lot tougher than it is with buttons and sticks. Here’s the question: how much ambiguity should the controls allow? If people use the controls non-optimally, should the game force them to correct themselves from the get-go? Or should it allow them to do what they feel, and guide them towards optimal behaviour more progressively? Is ambiguity simply  the sign of poor design, even though its an inherent property of the input modality?

How Game Design Can Help Theatre Do Interactivity

Methods for a board game to interact with a separate on-screen software component?

Software to board game…

- software triggers events in the board game at random times

- software triggers events in the board game in set feedback loop

- software generates multiple iterations of the board game

- software presents isolated challenges that when resolved, modify the board game

Board game to software…

- enter state of board game in software when prompted

- enter an aggregate value or particular indicator when prompted

- take action in software as a result of player choice

- board game prompts an action in the software

- AR tracking (madness!!!)

Normally in designing experiences, I seek to minimize chaos. This is the general rule of thumb. One of the interesting things about games, which runs contrary to other manifestations of interactivity, is that there needs to be some impedance on performance; some amount of confusion is often a good thing. I was recently reading a game design textbook that described this phenomenon in a formal sense; it talked about a feeling of emergent randomness within the rules that provided for a sense of possibilities, unpredictability, which can make games exciting. That’s true, but I’ve found that chaos has a certain aesthetic quality as well, which is more immediate and primal than the rational explanation. There is something about short, frenetic bursts of activity, and the scramble in them, that activates the senses in a unique way. I’m sure there’s an evolutionary explanation. Not all games have this, but when it happens, it’s pretty magical.

I’m extremely interested in being clever. I try very hard to be clever: I like all my words to have wordplay, I like my music intricate and layered, and I like my game mechanics to have that kind of “zam-zow” elegance that makes you believe they were created by astronauts from the future. In other words, I’m very into over-designing. My natural inclination is to believe that deep, compelling gameplay only results from deep, compelling game components.

This is often true, of course, but for every rule and asset one adds, there tends to be something lost; simplicity can give rise to more complex behaviour than complexity. It’s a tough rule to learn, and learning it has largely been the fundamental task of my game design career. I find it difficult to picture and predict that something complicated can emerge from something basic; it doesn’t make intuitive sense; I have to take it on faith. Of course, that makes it all the more wonderful when it works out.

I’ve got a quantity that behaves in different ways, depending on stages. Initially the player fills it up, and it only goes in one direction; once filled, it goes in both directions, depending on player performance; and if it drops below a certain threshold, it empties entirely, and returns to the first stage. The idea here is create a binary state for the player, affected by the quantity; either it is empty, and the player needs to fill it; or it has been filled, and the player needs to maintain it. But cramming all this functionality into a single gauge runs contrary to the simplicity of a standard UI element, and the assumptions that underlie it. There are UI design solutions around this, but that’s not something I want to futz around with right now.

Alternate solution: transfer the functionality of the gauge’s second state to a function of gameplay instead. The gauge only fills up, and once full, stays full. But once full, it is targeted by certain attacks from enemies; if those attacks are successful, the gauge is emptied. Players learn that the gauge needs to be protected from a unique threat once full, which is intuitive enough.