Lessons from the Trenches of Digital Game Design

Bottom-Line Performance has done simulation and learning game design for table-top/live events for many years. However, our foray into digital game design has only been happening for the past three years. When we started, we found lots of books and articles on game design – but not much on learning game design. We leveraged wonderful books from game designers such as Tracy Fullerton and Brenda Brathwaite and gleaned from their experiences designing games, but we didn’t have a ton of peers writing tomes on learning game design. (Exception: Karl Kapp’s book, Gadgets, Games, and Gizmos for Learning came out in 2007. It’s a wonderful book, but it’s not really a how-to guide to creating learning games. His most recent book, The Gamification of Learning and Instruction Fieldbook has more how-to guides within it.)

There are some similarities between learning design and learning game design… but even more differences. Here is a summary of six lessons we’ve learned. We’ll present these – with more detail – at sessions we’re doing at ASTD TechKnowledge later this week as well as at Training 2014 in early February. You can get a sneak peak at the slides we’ll use (and the example) on Slideshare.

1. You need game content – even at your first prototype.

This might sound obvious, but if you have done agile design before, you may have designed HOW a learning interaction is going to work while including only placeholder content in it or Greek text. You cannot do this with a game. You have to have realistic content (e.g. an actual scenario and realistic choices for a player to make) or you cannot assess the fun factor and learning efficacy of the game idea. Trust us on this. We made the mistake of trying to design a game interaction with only place-holder content. People played the prototype and then told us, “Well it might be fun but I can’t really tell without seeing the actual game content.” Once we played, it was like the Mr. Obvious show. However, BLP has lots of smart people and we didn’t recognize this issue until we programmed an initial prototype that we called “Story Shuffle.” We got smart and re-did things. Here’s a later view of the same game, now called “Late for Lunch.” For those who are curious – we used a tool called Construct2 to create the game. You can embed games into course authoring tools such as Lectora or Articulate Storyline.

2. Aesthetics and theme dramatically affect desire to play. They literally can be game-changers in terms of people’s interest in what you create.

Again this seems obvious… but aesthetics are HUGELY powerful. They can take content that an ordinary person would NOT find exciting and make you want to play just because the game is so aesthetically cool looking. You might not be excited by the topic of incident investigation but you might be far more excited to go into an evil alchemist’s laboratory and earn your way out by making gold out of iron. Check out this game to see what I mean.

3. Fantasy has high appeal – even to “corporate” learners. It’s worth fighting for.

Bean counters can be skeptical of fantasy – it can seem frivolous or too fanciful for work. However…that is sort of the point in making someone intrigued enough to want to play a game that would otherwise be rather ho-hum.

Here’s ho-hum.

FantasyInGames

Here’s pretty fun:

FantasyInGames2

4. Most players need help figuring out how to play – but typically won’t opt for it if given a choice.

This lesson is a critical one. Some learning games – in fact, many learning games – require some “show” on how to play to minimize the learner’s cognitive load. You don’t want them to spend so much mental energy figuring out the mechanics of the game that they fail to learn anything. However, when you design a tutorial level of play, if players get a choice, they will often OPT OUT of completing it…because they don’t want to take the time. We’ve learned not to let players have a choice and to require them to go through the tutorial. No, they won’t want to. Yes, it will end up maximizing their enjoyment of the play experience if they do. Either incorporate a “training level” or an actual tutorial into the game unless the game’s mechanics are very, very easy to understand and intuit.

5. Rules and game complexity need to be proportional to the amount of time people will spend playing the game.

If you are designing a multi-hour play experience, you can incorporate lots of game elements and mechanics (aka game rules). If you are trying to create a 10-minute to 60-minute play experience, you NEED TO KEEP IT SIMPLE. Lots of complexity can create a very fun GAME experience, but it has a negative impact on the LEARNING experience. As you play test your game during development, you need to ask both of these questions:

  • How engaged were you in play?
  • What did you learn by playing?

If the game has lots of clever elements and mechanics, you can get very positive responses to the first question – but poor responses to the second.

6. Scoring is the hardest element to get right – and requires far more time than a novice designer will probably assign to the project plan for it.

I created the game Formulation Type Matters four years ago. It was my first digital game (and a finalist this year in the Serious Games Challenge – hooray!). I allocated 8 hours to define the scoring for this game. We actually spent well over 40 hours figuring out the scoring – mostly because I didn’t have a clue what I was doing when I started. I’ve learned a lot since then, and I am now more careful to think through the scoring to make sure it’s relevant to the skill I’m trying to teach, meaningful to the player, motivating (rather than de-motivating to the player,) and, frankly, easy to understand. I also know that it is probably going to take more than 8 hours to figure out the scoring on a game unless the game is super-simple.

Here are the slides I used when presenting “Lessons from the Trenches” at conferences