Design Lessons Posted on January 3, 2013May 4, 2015 by Corvus Elrod Not all game design lessons come from studying games. There are important design lessons to be found just about anywhere we interact with the world. For example, I wrote the following post in 2006 when my wife and I rescued a miniature poodle from a shelter in Philadelphia. Game Design is Going to the Dogs Or is that coming from the dogs? Well… dog to be precise… and my game design to be even more precise. Regardless of the linguistic finickiness, this post is sponsored by my new design-muse, (T.S.) Eliot, the Elder Snout Oopei Choop. You may recall that a little over a month ago I announced the arrival of a rescued poodle to the Attic. Although we were originally informed by the shelter that he was three years old, we’re assured by our vet that while he’s probably not eight, he’s certainly not three. There’s nothing quite like adopting an older dog. While Eliot is very clearly an intelligent animal, he’s got separation anxiety, likes to test boundaries, has stomach issues due to nerves, and clearly didn’t live in an environment which engendered trust in humans. To top it all off… he didn’t know how to play. Dog. Not playing. Dog… not playing. Dog. All right, then. This would not do. We have taken it upon ourselves to teach Eliot to play. While I’m at it, I’m extrapolating whatever game design principles I can from the process and it’s those observations (I’ve settled on nine of them) which will make up the remainder of this post. Incidently, these same principles apply to training the dog to perform other, less play focused, tasks as well, such as sit and stay… which we’ve also managed to turn into a fun game (mostly). 1. Be Patient Eliot doesn’t always get it right off the bat. Even when he does seem to get it, he’s not always interested in participating. Getting frustrated isn’t going to help, so patience is the keyword of the day. Likewise, while seeking feedback on a game’s design, whether via play testing, or social networking, it’s important not to loose patience with other people when your vision isn’t clear. Keeping a cool head means that ultimately, you’ll learn a lot from the miscommunication. Likewise, don’t let your game design itself rush players through the experience. There’s something to be said for frequent direction markers and vacuum plot points, but don’t grab your players by the nose and speed them through the game, let them find their own pace. 2. Be Supportive Eliot doesn’t always trust his instincts around us. It’s a new environment, we’re different people than he’s used to and we don’t react to his behavior in the same manner as his previous owners. Because of this, he’s often hesitant, or worse, he cringes if we move quickly (breaks my heart). I have to confess that he’s gotten much better and I attribute that to the supportive environment we provide him. By supportive environment, I mean that we constantly provide him with positive feedback. When he’s hesitant, we encourage him. When he cringes from a sudden movement, we take some time to hug and pet him. Likewise, have your game’s design be supportive of your players. Very few things turn me off faster than a game that mocks my need to quit and go to work, or one that triumphantly proclaims, “You loose!” when I fail at a task or mission. Let your design focus on players successes and refrain from pointing out their failures. 3. Be Reasonable With Praise This one ought to be pretty obvious and it ties in closely with the previous design rule. Together they represent a simple three word concept – Reward. Successes. Appropriately. When Eliot first started obeying simple commands, we made a big deal out of each occurrence. Once we moved on to more complex tasks, we shifted our focus and stopped making a big scene for every successful ‘sit’ performance. Otherwise, the act itself becomes minimized by the love-fest afterward. In other words, take time to praise thoroughly and well without detracting from the positive experience of accomplishment itself. Windwaker, in my opinion, has too many animations surrounding the fetching and opening of every single sunken chest. They lavish too much praise for a minor accomplishment. The music and light while opening the chest would be enough, without the triumphant pose afterwards. It’s cute the first time, but gets tedious very quickly. I think perhaps, it is better to reward the player a little too much rather than not enough, but keep in mind that most of them just want to play, without a lot of interruptions. 4. Be Filled With Joy This is one of the two sappier rules in the set. But seriously, be happy to do what you’re doing. A joyous approach to design will be reflected in your final product. A stressful, tense, unhappy experience designing a game will not do you, or your audience, any favors. Eliot reacts quite well when we’re not stressed out about his training, or his play. We we are stressed… well, it’s when he chooses to test boundaries the most. 5. Be Filled With Love This, clearly, is the second of the two sappier rules. We are teaching Eliot to play (and to obey) because we love him. We want the best for him and we want him to be happy. Setting boundaries and helping tailor behaviors out of love makes all the difference in the experience. Treat your audience with the same respect and sense of responsibility with which you’d raise an emotionally wounded poodle. It will shine through in your final design. 6. Take Breaks When Needed Eliot can only handle to much training in one day before he loses interest. We watch for the signs of this and try to quit right before he does. This keeps him interested in the training and has proven very effective. This translates into two design rules: One – take breaks when you feel your brain starting to overheat. Whether you read a book, have a conversation, listen to some music, or watch a bit of a movie, it’s important to let your brain rest every once in a great while. Two – give your players time to catch their breaths. The quiet moments immediately before or after a large challenge are some of my favorites throughout my game playing history. The exciting moments are the ones I talk about, but the quite ones are the ones I reflect on. 7. Quit When They Do The above rule can be hard to gauge correctly. So if we haven’t taken a break and Eliot quits, we do to. This works well for us, because he’s intelligent and far from lazy. I imagine that it might be different if he weren’t such a motivated dog. The gist of this rule as a design goal is simple: allow your players to save and quit… whenever they want. Now, you may need to restart them at the beginning of a level when they come back, but don’t undo their accomplishments. Save features no longer need to be limited as they once were. Save the important information and quit when they do. You’ve seen the next two rules on this blog before, they’re not new. But, while teaching Eliot to play (we’ve been having success at this, by the way) and to obey (even better successes on this front), these two rules have proven invaluable. 8. Reward Desired Behavior Treats, joyous and love-filled praise, and plenty of petting await Eliot whenever he behaves appropriate… even when it’s accidental. Your game design should work the same way. Wether the reward system be comprised of points, character bonuses, items, or a mixture of many things, you should always reward players for exhibiting desired behavior. 9. Discourage Undesired Behavior Note that this rules doesn’t say punish or disallow, but discourage. Your game should not be a battlefield between designer and player. You should not take an adversarial stance with your audience. Remember that even negative attention is attention and gently discourage undesired behavior with non-threatening, non-harmful guidance. Die-and-repeat gameplay only appeals to a small segment of the game playing public, so give the rest of your audience plenty of gentle discouragement when they wander astray. So there you have it. Nine quick-and-dirty design principles based on teaching a poodle to play. Most of these were not new concepts to me and probably weren’t to you. It’s merely a slightly new application of them. Still, it’s interesting to see them in effect in an area and context in which I hadn’t considered them before.