Below is my response in the comments section to this story, posted on NPR this morning, which I found quite offensive and misleading.
I am a 6 year professional game designer that uses analytics to make my games more fun. I do collect various anonymous data — for instance, I gather the aggregate number of players that will visit a particular game area in a day. If that area (or character, or mechanic) proves to be unpopular, I ask myself why, and use that iterative process to create more enriching and fun experiences. My goal is to become better at my art, and yes, like anyone, I want to create experiences and products that people will pay for.
What I do -not- do is “watch” and “track” your children playing games so I can make them more “addicted”. Those are loaded words that imply an intent that does not exist. I entered this industry to create experiences that are enjoyable, provide engaging challenges, and ignite the imagination. To best do that, I often do need to gather broad, behavioral feedback of what players do en masse… which, is a pretty common thing to do in just about any service or humanities directed profession.
Did you know that your local grocery store “watches” what you buy so they can stock their shelves with stuff that you’ll be more “addicted” to? Unlike me, they even video tape you doing it!
If a child gets to play my game for an hour, I’m going to give him or her the most amazing hour I can. I’m going to make sure he or she has the time of their life. That’s my job, and I’m so proud to do it. Fun and play are deeply rewarding and enriching parts of the human experience for everyone, in many different forms.
What I can not do from my position as a game designer, is discipline children to forego fun for more productive ends. I’ll provide the fun, but unless I really do “watch” your children, I can’t be the one to tell them when to stop.
Getting Familiar with Forgiveness
As a game designer, your primary concern will be in planning and executing all the ways in which players will interact with your game system. These interactions may include anything from orchestrating a graceful ballet of fisticuffs with a deranged hippopotamus, or designing a shop interface so your player can purchase a piping hot dragon burger.
Regardless of what interaction you create, right down to basic functionality such as turning the sound on and off, you create opportunities for the player to make mistakes in interacting with your system. Because of this, you should be familiar with the general design principle of forgiveness.
Forgiveness is a system’s ability to easily recover from user error. If you were tasked with designing a word processor, forgiveness at a basic level entails luxuries like a backspace button, or an undo command. At a more advanced level, you may design a real-time spell checking feature, or automatic, periodic draft saving. The body of features that relieve or prevent the consequences of user error in your interactive system define your system’s forgiveness. Forgiveness is the safety net a user can rely on to catch and facilitate their mistakes.
Creating forgiveness in a system that is designed to fulfill user intentions perfectly is a delicate art. You must anticipate the mistakes they may make, while not burdening them with needless features or command confirmations. Every misstep must be recoverable in a painless and intuitive way, and irrecoverable actions must be surrounded by intention checks.
In your game, a simple UI forgiveness feature may be a confirmation screen ensuring the player does indeed want to delete Spleen Smoker, their level 70 troll shaman. Your user interface, by and large, will follow the best practices of forgiveness in any other usability system. However, how does the concept of forgiveness affect your actual game mechanics? Thinking about forgiveness in this regard becomes more complex.
Forgiveness in Game Mechanics is not so Straight Forward
Imagine you have designed a character creation menu for a role-playing game, and in addition to a wide variety of stylish mustaches to sport, you have given your player eighteen points to spend among some statistics: strength, intelligence, and dexterity. Your alpha tester wants to create a two-handed-hammer wielding thief, aptly named “Sneak and Smash”.
She intuitively knows big hammers are probably going to require strength to swing around, and she knows dexterity will be important for all the sneaking she is planning on doing, so she puts nine points in strength, nine in dexterity, and accepts that she’s not going to be shooting many sparkles from her eyes.
You do your best through tool tips to explain the importance of each stat to the player on creation, but unfortunately for this particular player, you made a couple of balance decisions that impede her vision. The most powerful two-handed-hammer in your game requires twelve strength, and your ultimate sneak skill, “Sneak in Plain Sight”, requires ten dexterity. Furthermore, you made a mistake yourself, and intelligence is actually the most effective late-game stat by a small but noticeable margin. She finds all of this out after thirty hours of play.
Now she accepts she cannot have both the best hammer and “Sneak and Plain Sight” together, and that she may not have the most powerful character possible, but she is understandably disappointed to find she can have none of these things. These were all goals she originally set out to achieve: be the best hammerer, be the best sneaker, and be the most powerful. If you are an avid RPG fan, you know this is a common problem with many possible solutions.
How Much, and What Type?
What forgiveness will you design for this situation, if any? Will you aim to supply better feedback on character creation about the late-game effects of particular stats, or will you engineer a stat redistribution mechanic as an “undo”. If this were a word processor, and your user had just misspelled a word, equivalents for both (a display for the correct spelling of the word, and a backspace button to fix the error) would be immediately desirable.
In a game design situation, too much early information may ruin the excitement of discovery, and a stat redistribution mechanic that is too easily utilized may trivialize the intended user experience of assigning statistics in the first place. Naturally, you do not want to leave your alpha tester with a disappointing experience, but you also understand that working within the stats she chose accounted for much of her enjoyment up to this point.
Forgiveness is a complicated issue in game design because ultimately, we want our players to make some mistakes. If a player jumps too early and falls down a pit, we don’t necessarily want a readily available undo button, even though the player will clearly perceive this as user error. Much of the art of game design is exploring which mistakes are fun to learn not to make, and which mistakes are going to suck the fun out of your system without extensive forgiveness included.
Which mistakes are you going to forgive your player, and when will you hold the line? Will you give them three lives, or five?
Now that the concept of forgiveness and its challenges in game design have been introduced, part two will explore specific cases under which forgiveness can be helpful or harmful in your design.
To paraphrase a study cited in Jane McGonigal’s Reality is Broken:
The University of Rochester published a study in 2009 studying the overall reported happiness and well-being of 150 recent graduates while measuring both their achievements of extrinsic rewards (money, fame, power, everything psychologically external to a person) and intrinsic rewards (personal growth established by self-directed goals.) Their conclusion: “The attainment of extrinsic, or ‘American Dream,’ goals — money, fame, and being considered physically attractive by others — does not contribute to happiness at all.”
The same study also found that participants who focused on intrinsic rewards, like working hard to develop their own personal strengths and personal relationships, were measurably happier over the two-year period of the study, completely regardless of external life circumstances like wealth or social status.
Jane McGonigal points out that games are a perfect facilitator for enabling the pursuit of intrinsic rewards, and that pursuing intrinsic rewards (working to develop personal strengths, habits, talents, and relationships) is a key ingredient in the recipe of enduring happiness. Americans and other consumer cultures around the world have been wrongly taught that extrinsic rewards create happiness, much to their own detriment.
This line of logic led to a depressing realization about the field of social and mobile games — that in order to make themselves profitable, freemium games have largely abandoned the noble goals of creating intrinsically rewarding experiences, and have instead fallen back on providing extrinsic reward structures that prey on and reinforce consumer culture’s misunderstanding of how to attain happiness.
Games like Rage of Bahamut and Blood Brothers (the current #1 and #2 top grossing games on the Google Play Store) offer very little challenges that offer opportunities for intrinsic rewards (low difficulty, superficial social interaction, very little mental challenge) and instead encourage extrinsic rewards like ownership and social status. The end result is a hedonistic addiction to acquiring more and more possessions that ultimately loses its luster and never really generates happiness — at least no more than compulsive shopping would, which is perhaps the point.
The pessimistic view of this model is that it’s easiest to keep people purchasing the promise of happiness when they are perpetually unhappy. Another pessimistic view might be that the overriding cultural assumption for what creates happiness is so powerful that games -must- cater to it to thrive. The end result is the same though — players will be left with a vague dissatisfaction and eventual disillusionment with the product. Participants are driven to consume as in an alcohol binge, only to wake up with a hangover and a sense of confusion as to why they began in the first place.
I believe a more ethical pursuit, and perhaps a more profitable one, is a way to offer the opportunity to achieve intrinsic rewards as micro-transaction. I’m looking forward to seeing the industry produce ways to craft personal growth as monetization, rather than simple virtual possession as monetization.
My friend and Level Designer on Team Fear, Chris Diller, has put together a mash-up video of some of the best YouTube reactions to the monster in Erie. Hilarity ensues:
Wow. Erie has seen 750,000 hits on this YouTube Let’s Play by Pewdiepie. Erie is a smash success! Our strategy of going for the quick, raw thrill of being hunted has worked wonders, and now there are volumes of screams on YouTube in the form of over a hundred response and reaction videos. My personal favorite: (NSFW)
We knew the game would inflict terror, but we never anticipated inducing -that- much terror. Now on to honing what we’ve learned even further.
A game I pitched and designed during my MFA Thesis, a short horror title named Erie, was released on the indie publishing service Desura three days ago. Even though it is scarcely finished, and very rough around the edges, it has held the number one most popular spot on the service since.
Check out the fantastic two-part “Let’s Play!” bit below, and check out Erie for yourself here on Desura.
PewDiePie Erie “Let’s Play” Pt. 1:
PewDiePie Erie “Let’s Play” Pt. 2:
At the Game Design Conference yesterday my colleague Justin Gibbs and I spoke on the potential process of gamifying Kickstarter. After our success with the Evil Baby Orphanage Campaign, we’ve been brainstorming concepts for how to orchestrate even more effective kickstarter campaigns, with a specific interest in retaining trendsetters post-campaign and making more attractive experiences to incentivize higher funding per funder.
The result of these talks resulted in several methods of gamifying Kickstarter. We now consider Kickstarter the gateway to our game world, not simply an ends to its creation. Our talk at the Game Design Conference suggested methods to run funding as a Faction-based Competition, writing a community narrative through a Choose-Your-Own Kickstarter Adventure, and orchestrating a campaign as the entry point to an alternate reality game. The benefits of gamifying Kickstarter campaigns are many, but the short list includes getting your audiences to contextualize themselves as part of your game universe early, increase funder engagement through involving them in a fun, democratic process, and driving funder discussion well past the completion of your campaign.
Regardless of how you gamify Kickstarter, we believe the next evolution of Kickstarter will focus not just on giving funders a sense of investment in the creation of the product, but giving funders a personal sense of emotional investment in the product’s universe.
Most starting indie developers recognize postmortems as those handy four or five page documents seen on Gamasutra that break down project development for public consumption. While these are awesome for the reader — they give us a window into another team’s successes and failures — there are more useful methods for ensuring that your own team learns from its successes and failures.
The below method for performing a postmortem was taught to me by Jeff Peters, Executive Producer, and Marty Clayton, Art Director, at the local branch of Electronic Arts. Every time I’ve performed this postmortem I’ve had revelations about how I can make my next games even better, so I hope you find it as useful as I have. Without further ado:
What You’ll Need:
First Step: Timeline
First, find a long, large whiteboard on which you can create a horizontal project timeline. The first point should be the project conception, and the final point should be product launch (with a slight extension for any immediate post-launch support.) I find it useful to break the line up into pre-production, production, and post-production (or, pre-pro, alpha, and beta.) After it is blocked out, work together with your team to fill this out with every major event during production. Examples include:
5/29: Phil, our lead tech, got sick with the flu for two weeks.
6/7: Major milestone hit, grappling hook feature fully implemented. Looked great!
6/8: Client hates grappling hook, three weeks scrapped.
6/15: Phil gets back.
6/16: Implementation of AI changed due to Phil’s epiphany during fever hallucination.
Etc. etc… Make sure every event that affected development in a notable way is included — design changes, vacations, and on and on. This can be a bit of an exercise, as you’ll find your team won’t remember the development process perfectly. You will need to help each other remember.
Second Step: Sticky Notes
After your timeline is complete, give each team member a sticky notepad and pen. Each person can now add comments to each event on the timeline regarding whether or not they think that event was helpful or unhelpful in development, and why. If the comment is positive, write the comment on a sticky and post it -above- the event on the timeline. If the comment is negative, post it -below- the associated event. Pretty soon, you should have a colorful white board full of both good and bad sticky notes.
It’s important during both this step and the following steps to keep all comments impersonal, objective, and professional. If your postmortem ends in a fist fight, it’s not a very successful postmortem. For instance, if I think Phil was a dick for taking two weeks off for the flu when I know he was only sick for three days, I might say “Not having the full tech team during the implementation of the grappling hook was really difficult.” Better results will ensue.
Third Step: Checkmarks and Culling
When everyone has posted all the sticky notes they want to, you will probably have far more comments than you have time to discuss in depth. Because of this, it’s important to find out what the most important comments really are. Give everyone on the team five to ten checkmarks and ask them to write a checkmark next to each of the comments they agree with the most. After everyone has marked which comments they agree with (good and bad) you’ll quickly start to see comments that stand out as most prominent.
Fourth Step: Discussion and Review
Now it’s time to discuss the most relevant comments as a team. Go from the start of the timeline to the end, and discuss all of the comments that received a large amount of checkmarks. If the comments are negative (i.e. there are seven checkmarks next to “Not having a full tech team . . .”) have a discussion about how to mitigate it next time. Don’t leave the point alone until you have a solution in place. Likewise, if a positive comment gets a lot of checkmarks, make sure you and the team understand why it works so well, and that you know how to replicate it again. Through this process, you and your team will learn how to overcome your mistakes and accentuate your strengths. If you keep the discussion high brow, you’ll also grow better team relations as well — working through production problems together is a great team bonding exercise.
About half way through my time at GDC, the popular design and development instructional company Design3 interviewed all of the 2012 GDC IGDA Scholars about their experience as part of the program. I’ve got about a minute and a half in the below, but it’s an interesting video all around, containing interviews with IGDA Executive Director Gordon Bellamy and Community Manager Ashley Zeldin.
Also, just for fun, they asked all of us to describe our experience in a word. Check it out here:
On the second day of the scholarship, we got the unbelievable opportunity to tour two studios much closer to my heart, Three Rings and Double Fine. These studios intrigued me more than Zynga and LucasArts the prior day, because they are smaller, more agile, and have a strong sense of artistic integrity. All in all, they demonstrated the environment I’d like to work in, or even run in a few years.
Three Rings was incredible for a few reasons. As I said prior, it is a smaller studio, running around 40 people, and produces some incredible titles: Puzzle Pirates, Spiral Knights, and the Dr. Who MMO. The president of the company, Daniel James, was a true gentleman, absolutely informative, gracious, and a pleasure to interact with. I learned an enormous amount from him about running an indie studio. Questions I asked included whether or not they had been able to subsist purely on their own IP (the answer was a resounding no,) and whether or not having been recently acquired by Sony was a difficult transition from having been an indie studio for so long. Apparently, they are largely hands off, which was encouraging.
Beyond the incredible knowledge I gained from Daniel and just observing the inner workings of the studio, the internal aesthetic of the building made me feel very much at home — some strange coincidental hodge-podge of everything I love. Victorian steampunk, Dr. Who’s Tardis, a giant squid couch, secret rooms hidden behind library bookcases… truly incredible. Daniel was nice enough to let us take pictures of the inside of his studio, so I’ll share a few here.
After Three Rings we had some lunch at Whole Foods and headed over to Double Fine. Double Fine has always been a studio I admired — headed by Tim Schafer, their artistic vision is strong and sound. Psychonauts was a titled I played through at least twice, and both Ron Gilbert and Tim Schafer’s older adventure titles, like Day of the Tentacle and The Secret of Monkey Island, were childhood favorites of mine. In addition to getting a walk through of the studio, we got to pick the staff’s collective brains, including the indomitable Tim Schafer himself, who I am now convinced is incapable of saying anything that isn’t funny. Luckily, Design3 caught this Q&A with Tim Schafer as a video — I like to think we asked intelligent questions. Take a look!