The Agile Approach To Learning Game Design

The Agile Approach to Learning Game Design
Summary: Corporate learning professionals, instructional designers, trainers and eLearning pros… listen up. I want to let you in on a little secret: Game-based learning requires a whole new approach to learning design. It’s not the same as eLearning development, and it’s definitely not a set of skills you can pick up at an in-service day. The ADDIE approach to learning and development simply does not work with games. You have to go Agile instead.

What is Agile Learning Design?

Agile Design is really a term from the software development world. Anyone who writes code knows you must take some sort of agile approach: continuously writing, testing, and refining. Doing all the development, then moving on to implementation all at once, simply does not work.

I’ll spare you the full explanation of Agile Learning Design, as we wrote about it extensively in another blog post. What I’d really like to do is demonstrate the connection between agile design principles and effective game design.

An Agile Approach to Game Design

Even the simplest games have far too many pieces and parts to design and develop once, then move on to launch. By the time you reach the “Evaluate” phase of ADDIE, it will be too late (and too expensive) to make the small tweaks and changes that might have made a world of difference in your game.

Games are filled with variables that affect player experience and, in the case of learning games, knowledge transfer. Is the scoring fair? Should the game be competitive or collaborative? Can the game be completed in a reasonable amount of time? Each time you add a new mechanic or element to your game, you have the potential to significantly alter the player experience.

That’s why it works best to create a simple prototype of your game as quickly and cheaply as you can, have players test, and then add and subtract game mechanics accordingly. A typical game design project will have anywhere from 4 or 5 to 20+ iterations, and the formative assessment opportunities you get through play testing are crucial. The only way to really know if a learning game is going to “work” is through evaluation and refinement.That’s why you should make one or two small changes at a time, playtest, and refine. Rinse and repeat until the game is getting the outcomes you want.

Case in Point
knowledgeguru_agile example

In May of 2013, our company launched a major enhancement to our Knowledge Guru game engine. It’s a web-based tool eLearning developers use to create games that teach or reinforce their instructional content. This launch was the first exposure many people in the corporate learning community had to our Knowledge Guru game, and it surprises some that this “new” game was actually being played, tested, and refined as far back as 2010.

Our first mock-ups were very simple graphically. No fancy mountain. No cute looking Guru. Just three paths up to the top, multiple choice questions, and some basic scoring mechanics. We tested the game internally in this format, and ended up changing quite a few things. For example, the first iteration of Knowledge Guru imposed a time limit for each question players answered. Testers universally hated this mechanic, and rightfully so: skilled learning game designers know that each mechanic in the game should support and drive the desired learning outcome, not distract. Since answering questions quickly is not the primary goal of a Knowledge Guru game, the mechanic did not belong.

If we had taken an ADDIE approach to developing Knowledge Guru, mechanics like this could have easily snuck through and made it into a public beta, which would not have been ideal. It’s taken years of iterations to get the game in its current state, and that’s the agile approach that all games require. When new users request a free trial and start using Knowledge Guru, we can be confident that our up-front development and preparation is ensuring a reliable user experience.

A Time and Place for Both

ADDIE still works great for many learning design projects. In fact, we still use it with many of our clients. More often than not, we simply modify the tried and true ADDIE approach with some agile elements. That means idea-sharing with clients during development instead of waiting until the end to present an Alpha or Beta. It means more iterations, and more frequent testing along the way.

When it comes to game design, Agile is the only way to fly. Make a paper prototype, test it, and refine. Have your programmer make a simple, stripped down version first before adding all the bells and whistles. Trust me… you’ll be glad you did.