When I was a first-year student at Carnegie Mellon’s Entertainment Technology Center, I was required along with the other first-years to take an improvisational acting class. At first glance it may seem like a weird requirement for a graduate level non-theatre program, but man, improv can teach you SO MUCH about working on teams in a creative environment. We had the added benefit that this class was taught within the context of “creating entertainment via technology,” so all the games and tricks were learned in such a way that they directly applied to what we were making on our projects.
It didn’t take long for me to start using what I’d learned in the class in my projects and eventually my internships and for-reals game development job. In hindsight, I’m very happy about spending part of my graduate school education running around with no shoes on, jumping into scenes, and playing crazy improv games. In this article I’m going to share several improv acting concepts that I feel like I use consistently in game development, both in making the game itself and in working on a team.
Table of Contents (since this article is lengthy)
What’s Improv?
Who's Line Is It Anyway? Perhaps you've seen it
Alright alright, definitions time. Improv is short for improvisational acting, which refers to techniques for a type of theater that’s all about performing spontaneously. Many times when people hear “improv”, the first thing they think of is the show, Whose Line is it Anyway? It is often but not always comedic, and actors take content prompts, like suggestions of scenarios or general directions, and then extemporaneously create the setting and plot and dialogue as they go. Wikipedia says…
“Some of the basic skills improvisation teaches actors are to listen and be aware of the other players, to have clarity in communication, and confidence to find choices instinctively and spontaneously.”
In fact, if you want to learn more about improv, the wikipedia article would be a good place to start.
Though there is a wealth of useful information in all of improv acting, today I’m going to focus on three principles.
- Yes, and…
- Status
- CROW
Yes, and…
Not to be confused with “Yes, if,” this is the process in improv where one actor makes an offer, and the other accepts it and makes a new offer building on the earlier one. This goes back and forth and lets the actors build information about their scene and their characters. The important part is that each actor accepts what the other one says as true and part of the scene, and avoids “blocking” (doing something to invalidate or reject what the other actor has offered).
To clarify, here’s an example of an improv game we played when we were taught this technique. Four people were told to pretend that they were observing a big painting. One person starts by making a comment on something in the imaginary painting, then the next person starts by saying “yes, and…” and then comments on another part of the painting, and so on and so forth, each new description starting with “yes, and…” By the end of it, the group had described a coherent scene, with everyone’s description relating to each other (the activity was stopped when someone uttered the dreaded “yes, but…” which is the first sign of blocking).
Here’s a clip of “Yes, and” being used as a warm-up
In the Game
This principal comes into play when thinking about how the player interacts with your game. Too often we designers get caught up in having in mind exactly what we want the player to do, and designing in such a way that we force them to solve a problem or approach a setup in a very specific way. This can create a rather linear experience, and it’s no fun when a player suspects that he’s being funneled down a cattle shute.
Think about the player as an actor in your scene. If she does something unexpected or wacky, is your game built in such a way that it can say “yes, that is a valid way of approaching this problem, and here’s how I’m going to respond so that it makes sense.” In the simplest sense, are there multiple solutions to the problem you’re giving the player to solve? On a more complicated level, do your basic mechanics and the tools you are giving your player allow her to be expressive in how she is solving your problems? Even if you are not making a sandbox game, or have been tasked with a very linear design, you can still search for ways to accept offers made by the player that you were not expecting.
Resistance 3 Mutator
On Resistance 3, there was some debate over our exotic weapons being overpowered in specific situations, and whether we should try and mitigate that beyond how much ammo we fed players for that weapon. There was always something like “well if they save up all of their Mutator ammo from the previous level they could just totally rock this setup that I wanted to be really hard!”
In the end we decided against nerfing. If the player saved up all her Mutator ammo and destroyed an entire building-full of enemies with convenient mutation chain-reactions, then yeah, it would make the setup way easy, but the player would feel so good and clever for doing it! The player feeling like a brilliant badass is way more important than a setup always rolling out the way the designer expected it.
On the Team
“Yes, and…” is also a great principal to apply when working with your team. It’s particularly relevant in brainstorming, but you can use it when you and your teammates are trying to solve any problem at hand. Have you ever been working at a problem, and had a teammate suggest some idea that you secretly thought was the most ridiculous idea you’d ever heard? What did you do? Maybe you nodded absently, or chuckled, or said “uh-huh,” and then ignored the offer completely and continued on with the conversation. Perhaps you immediately pointed out what was wrong with the idea or why it wouldn’t work. And maybe the idea wasn’t ridiculous, maybe you reacted in these ways because it wasn’t you who thought it up. I use these examples only because I’ve seen people do them to their teammates first hand, so I know this behavior exists.
The next time this situation occurs, try this: No matter how ridiculous/it-wouldn’t-work/I-didn’t-think-of-it the idea is, think to yourself “what if this person is right?” Accept the teammate’s offer, build on it, and make a counter-offer. Just roll with the train of thought for awhile, see how far you can “Yes, and…” along. Perhaps by the end of the train of thought, you and your teammate will have riffed on the idea to the point where some useful solution does come out of it, but even if you don’t and the idea remains unworkable, your teammate will likely feel more trusting towards you since you actually listened to him. I know this can be a difficult habit to pick up, especially for us game designers when we tend to be naturally critical risk mitigators, but I promise you it’s a skill worth practicing.
Status
Another improv construct that I’ve used to great effect in game development is the concept of “status,” which is about a character’s sense of self-esteem in dominance and submission situations. This is not directly related to social status, and in fact the most amusing situations often come when a character’s status is the reverse of his social standing (the wise fool situation). This construct is a way for actors to quickly establish how characters behave towards one another in a scene by adopting the traits of high or low status. High-status characters, for example, behave confidently, make direct, sustained eye contact, stand up straight and are very still. Low status characters maintain minimal eye contact, touch their faces a lot, slouch, fidget, and apologize frequently.
One exercise used to teach us this principal was this: two actors were picked to do a scene wherein a boss called an employee in to fire him, reading from a script. First they played out the scene where the boss was high-status and the employee-to-be-fired was low-status. Then they did the same scene, reading from the same script, but with the statuses reversed. It was incredible how drastically the implications of the scene changed even when the lines did not, purely based on the actors adopting status traits into their behavior when reading the roles. In the first scene, the employee was wormy and submissive and the boss clearly had more important things to do with his time and was just getting this firing off his to-do list so he could go golfing or whatever. In the second scene, the employee was totally at ease with the situation while the boss was squirming in his seat, it seemed like the employee felt the firing was an opportunity for freedom to go do bigger and better things, while the boss, though in a higher position in the company, was stuck forever in this dead-end job. Remember, the lines were exactly the same, but the stories that formed in the audience’s head about the situation were completely different.
Here are some examples of Improv games involving status:
- Actors draw cards with numbers on them and stick them on their forehead (the numbers represent status rank). They can’t see their own number but everyone can see everyone else’s, and so behave accordingly towards that person based on their status. The actors eventually have to figure out their own status based on how other people are behaving towards them and towards each other.
- Actors enter a scene one by one, and each one tries to maintain a higher status than the person who came before
- A high-status and low-status character swap statuses at some point in the scene
- “Pecking order” exercises, where’s everything from the high status person to the low status person has to be passed through the middleman
Watch for the status swap in this exercise:
In the Game
A status swap, perhaps? Check out the eye contact on that red ghost!
The most obvious example of how you can use the principal of status in game design is if you happen to be making a narrative-heavy game with a big focus on characters. If your characters feel like they’re falling flat, think, “what is this character’s status when relating to this other character? What is her status when relating to the player?” Then, how can you use the traits of that status to flesh out the character? Even if your game is not highly-rendered with realistic animations, can you still incorporate status traits into your art? (eye contact, posture, fidgeting or being very still, etc).
You can also think about status in terms of your enemies, both how they relate to the player and how they relate to each other. Halo is oft-cited for its behavior of the Grunt enemy, which flees in terror when a nearby Elite is killed, but shifts to decidedly high status when it gets a pair of sticky grenades in its mitts and does a suicide run straight towards the player.
One of the past projects at the Entertainment Technology Center was Project Improv, and the goal was to research and make prototypes for status-driven play in games. I encourage you to check it out to see some good examples of how status could be effectively used in games.
On the Team
So you’ve probably realized by now, these status traits aren’t just a made-up complex used for the whims of improv actors. They work so well because they are distilled versions of how we behave towards other humans in real life. You probably do it yourself, and adopt status traits when talking with your boss that are different than the ones you adopt when playing with your kids. The trick is that once you recognize that you can change your behavior based on status, you can actually change it for the scenario at hand. For example, someone once said that when you are going in for an interview, you should try and adopt a status that is 1 or 2 levels lower than the person giving the interview (but not too low!). The next time you are in a meeting, look around and see if you could assign a status number to every person based on how they are behaving when interacting with one another.
How can you think about your own status when working with your team? When I am working on a new team for the first time, I have a habit of going slightly low status to my new teammates. This is particularly because I’m relatively new to the industry, and my teammates may have been working in it for years and years and have vast knowledge and talent about their craft, and there is much I can learn from them, and I want to relay the sense that I respect that talent and knowledge. Meanwhile, with the same team when we are in a high stress situation (perhaps a new problem has unearthed itself right at the approach of a deadline), and if people are getting a little panicky, I tend to go high-status. This doesn’t mean I start barking orders, mind you, I might not have any leadership powers in the situation at all, but I stand up straighter and sustain eye contact longer and try and set people at ease and get everyone confident that we can solve the problem that has been thrown at us.
C.R.O.W.
This stands for “Character, Relationship, Objective, and Where.” Also referred to as creating your “Who, What, and Where”, CROW is an acronym for the basic building blocks of any scene, and what the actors need to establish quickly so that the scene can be built upon and carried forward. If one of these pieces is missing, the scene runs the risk of devolving into chaos or nonsense.
Character – who am I? Who is the other actor?
Relationship – what is my character’s relationship to this other character? (Status comes into play well here)
Objective – what is our goal? What are we trying to achieve in this scene?
Where – what is the setting?
Many times improv actors will solicit one of these pieces of information from the audience to use as a starting point, like asking for a location. Then one actor will start the scene and they will quickly build this information by listening and responding to one another’s offers in the “Yes, and” fashion.
Here’s an example…
In the Game
Just as CROW helps keep a scene from devolving into chaos, it can help keep you game from devolving into confusion. At any point in your game, your player should know who she is, what is her relationship is to other entities in the game (are they enemies? Helpful NPCs? Can I even interact with that thing?), what is her goal, and where she is. Sometimes confusion about these things doesn’t present in such an articulated way, though, and the only symptoms are a puzzled player who isn’t doing what you would expect. Maybe the player is exploring some insignificant detail of the environment when a battle has erupted, gets shot in the back and dies, and then is confused about what has happened. In these cases it’s up to you to figure out what information is not being communicated to the player. Is it clear that his objective is to survive the battle? Does he understand his character’s relationship with the entities in the game, not understanding that they are actually enemies that will hurt him? Does he think that he is in a safe place instead of hostile territory? Then, what can you do to more appropriately convey the missing information?
On Resistance 3, our writer, Jon Paquette, did story usability testing late in production to see if players understood the scenarios they were in and if there were any late adjustments we could make to clarify confusion. He had them play parts of the game and at certain stopping points asked questions to see if the player was unclear about anything:
- Briefly summarize what you played/saw
- What do you think is going to happen next?
- When does the game take place?
- <shows a picture of an NPC> Who is this?
- Where are you right now?
- <show picture of an enemy> What is this creature?
- Where are you going? Why?
- What is your ultimate goal in the game?
FREAKIN BEARS!!
From this information we were able to make lots of little clarifications where needed (dialog changes, changing the wording on an objective, removing or adding ambient creatures, changing the timing on when a radio message) and remove red herrings that we’d unintentionally placed that wound up giving false CROW information.
Also, remember, you don’t have to be making an epicly narrative game to be able to establish CROW. Take TripleTown, for example. It naturally establishes the “where” and the objective through its art and gameplay goals, but think about how it conveys the character of the bear and that character’s relationship to the player. The grumpy but not-too-mean face, the occasional roaring and stomping animations that scare all the ambient villagers away, these are subtle little details that help clarify the relationship. It’s not a mortal threat that the player should fear, nor is it a chance-driven obstacle of nature, it’s “this jerk bear is trying to get in my way and foil my plots! STUPID JERK BEAR!”
On The Team
Since this technique is so much about establishing the building blocks of story, the effects it has on “how to work on a team” are somewhat ancillary. I suppose you could draw parallels between relationships and objectives and your teammates and goals, but that feels a little forced. Instead, I want to talk about things that happen to make good CROW exercises and how those are relevant in teamwork.
CROW revolves around establishing the basics early. People who are new to improv often make the mistake of thinking that improv acting is all about trying to be funny. They’ll get into scenes like these, and instead of taking the offer and thinking “okay, what other pieces of CROW still need to be established? What can I do to establish them?” they will think “okay, how can I say something funny?” Scenes like this often end up being awkward and crude. Sometimes new actors are so caught up in what they were hoping to play out, that they try and brute force the scene ahead their way, and ignore or reject offers by the other actor that would have changed their plans.
Blocked :(
This is what I referred to in the “Yes, and” section as “blocking,” and it often results in a dominance conflict over the scene, becoming all about the struggle between the two actors. When this happens the actual story of the scene is lost or greatly diminished. What’s worse is that blocking might get a laugh from the audience, so the blocker gets rewarded, but it can have a bad effect on the trust between the two actors.
Does this situation feel vaguely familiar? Have you ever seen coworkers attempting to solve a problem be thwarted by their own attempts to dominate the chain of thoughts? Have you ever been in a meeting that turns so much into two people wanting to take the solution in their own direction that the struggle becomes more of a focus than the actual problem that needs solving?
Always remember, “have we established the basics?” If the answer is No and the discussion is spiraling in an unhelpful direction, see if you can drag things back on board by trying to clarify the problem you are trying to solve.
Learning More
“Okay, I’m intrigued,” you may think, “where can I learn more about this improv stuff?” If you are curious to see more improv techniques in action, there are plenty of videos online demonstrating games and principals. alth of improv information for watching. Better yet, look up a local improv troupe that is performing near you and go check them out in person. See if you can identify some of the techniques being used in the moment.
For a related article here on altdev, check out Mike Jungbluth’s Stanford Business Magazine.
If you’re the reading sort, I would recommend Impro: Improvisation and the Theatre, by Keith Johnstone. This book was written in 1979, but it still considered by many to be the “improv bible,” and is still very popular today in the theatre scene. It explains improv techniques and includes exercises, but is written in such a way that anyone of any discipline can take away some juicy insights about creativity in general, and will perhaps challenge you in your thoughts over intellect vs. creativity. Give it a read!
Lastly, and probably the best way to learn more about how you can use improv to your advantage in game development: take a class!
What was that? Did I hear someone’s heart rate increase? “No way,” you may say, “this stuff is great to watch and read about, but me? Out there in front of other people? Saying things unscripted?? NO WAY! I’m not funny, I can’t act, I’m too shy. Too scary!”
If you feel this fear, I implore you to give it a shot. There is so much to learn by actually doing it than you can absorb in just reading an article or a book. There are far scarier things in life. Consider it professional development, do it!
Closing Thoughts
Hopefully I’ve convinced you that improvisational acting techniques can be extremely helpful and relevant in our work (possibly in any work!), but for some additional context, I asked some of my past classmates who also took improv if they had examples of how it came into play in their day-to-day life as game developers. Here are a few quotes:
- “The biggest thing I learned in improv is that everyone is more interesting than they first appear. I had so many classmates who only came out of their shell in improv. Now I make a point to try to create those situations at work so that everyone expresses their opinions.” – Stephen Dewhurst
- “I would say the bit of improv that has served me best is the notion of “support the narrative”. Asking at each step of development ‘What can I do through my gameplay that reinforces the our central premise/story?’ Going along with this, the ability to continue the narrative and keep it moving forward is not only helpful within the design of our games, but in working well as a team.” – Rich Marmura
- “in general, being positive and supportive (in a “yes, and” kind of way) has helped me in production roles.” – Freddie Sulit
In closing, I will leave you with one more improv principle, but will let you try and gleen its applications to your day-to-day work in game development.
The three rules of improv:
- Be fun to play with
- Make the other person look good
- Serve the narrative
Good luck, have fun!