Recently I was asked to make an article about making great learning games, a textual companion to my 10 minute video ramble on the same topic. It’s a…big topic. But I’m happy to cover a couple of the key starting steps that are project agnostic. I more or less use these methods every time I’m making a thing, sometimes formally and sometimes as rules of thumb as I go.
So we’re going to go with two articles. One focusing on learning objective design, and the following article focusing on game mechanics that are built using those objectives. Onward!
Learning Objective Development
When designing a Game About a Thing, it’s often a surprise when the team comes together and discovers that no one is completely sure what the aforementioned Thing actually is. The first step to responsible learning game design is the identification and locking down of the actual Learning Objectives.
The Learning Objectives themselves aren’t exotic or difficult to produce. They should, in simple language, state what the player should be able to do or understand at the end of the game, provided they’ve mastered the game during play. They can come from formal standards, the client, or collaboratively with the team, depending on the project.
“The Player will know…,” “The Player will be able to describe,” “The Player will be able to accomplish…” are all acceptable openers for a learning objective. Like learning objectives in other instructional material, these can be too big or too small for your purposes. If you find it difficult to think about gameplay components that can encompass all of an objective at once, consider revisiting your objective and breaking it into smaller parts. If your gameplay seems too “quizzy” or granular, you might consider looking for a way to bundle your objectives into bigger ideas (more on that later).
Identification of Learning Objectives is absolutely essential to the learning game design process. The process alone will unify your entire team and make it clear to all parties the goals you’re trying to meet in development. It serves as your bedrock during development as well: when you’re looking at new shiny features, you can ask yourself if they serve the learning objectives- if you can’t find a clear connection between the feature and the impact content, then you’ve got yourself an optional feature. Producers love this one crazy trick!
I’m a huge advocate for the idea that in life, responsibility needs to be tied with empowerment- there is nothing more frustrating than being responsible for something you don’t have control over. When you’re working with clients who are new to game design and development, they’re not going to be completely clear on where their job starts and yours begins- making it clear that they have the authority to craft these objectives and then the responsibility of articulating them and sticking to them makes everyone’s job a little clearer.
If learning objectives aren’t defined, subject matter experts will see their shaping of the learning goals as an iterative part of the design process- which it isn’t. Much like budget, timeline, platform etc., the learning objectives need to be finalized and fixed during your formative design stages so that they can be relied on as an assumption during development. Alter your objectives midstream at your own peril, Reader!
Identifying learning objectives is also a diplomatic process- it lets your clients and subject matter experts articulate what they know and why it’s important, and puts your designer in the role of an advocate, learning about what they want to express. Essentially, if done well it should serve as a trust-building exercise.
If you can get your learning objectives thoroughly documented, and can write simple summaries on how you expect them to work using your mechanics, then you have realistically prepared your documentation and planning for a good learning game design.
After The Game
Another important component of learning objective definition is your post-game goals. Maybe you’ve made a great game mechanic that clearly demonstrates the art and technique of canning fruits- but don’t you want to be assured that the player can actually produce canned fruit outside of the game when they are done?
Human beings aren’t always naturally inclined to transfer their knowledge from one domain to another. As designers we know that games can meaningfully create a Way of Knowing, allowing a player to confront a challenge, struggle and master it- but we also know that this Way of Knowing is deeply embedded into the play of the game itself.
The best strategy for starting in on this problem during design is to explicitly state your transfer goals as part of your learning objectives. Do you want the player to be able to discuss an idea competently with an expert once they’re done with the game? Write that down, and explain how the game will get you there. Do you want the player to improve in taking a written test once the game is over? For heaven’s sakes, write that down, because it will have a big impact on how you design your game!
Getting your transfer goals written and agreed upon can help clarify the shape of your game’s core mechanics, and can even help you craft supplemental “transfer mechanics.”
What is this “transfer mechanic?” A transfer mechanic is a gameplay mechanic that allows the player to approach your objectives from a secondary or even tertiary perspective. They ask the player to think and justify their actions taken in another, new context.
For example, in Filament’s ancient and venerable game You Make Me Sick, we ask the player to design a disease to infect a particular host, based on that host’s strengths and weaknesses. This mechanic is designed to encourage the player to think about the methods of infection. On top of that core game experience, we have the game dynamically generate a question after an infection, showing a random attribute of their previous victim and an attribute of their previous disease. The player is asked if there is any strategic connection between that host attribute and disease attribute. Sometimes there is, sometimes there isn’t. Successfully re-articulating the strategic connection increases the player’s score, and allows them more points to spend on their next disease design.
So this reflection uses the player’s direct experience in play, but has them re-approach their choices and articulate them as a strategic choice. So we have an assessment, but we also have a modelling activity for the player to practice transfer. Cool, right?
Another example is the game Eco Defenders, made with The JASON Project. In that game the player designs an invasive species to place into an environment with the purpose of eliminating one and only native species. After the player completes a round, the player is shown a series of charts and graphs that demonstrate predation and population. The player is then asked a series of questions (“What did your creature eat?”, “Who went extinct?”) that lead the player to interpret and de-construct what they did in the game. It’s…slightly boring, but the player is more engaged than you might expect, because they are being asked questions about THEIR EXPERIENCE, not just recalling facts that were announced to them earlier.
So again, we’re asking the player to unpack and articulate their game experience- from a forest of hopping critters to graphic data. We’re modelling transfer while assessing understanding. Cool stuff!
Transfer mechanics are tricky. You don’t want them to feel like intrusive quiz questions, but you *do* want them to be moments in which the player is forced to reinterpret or justify their play decisions in another way. If you can pull this off, you’ll have demonstrated transfer before the player has even left the game, and that’s a good thing!
Internal transfer mechanics are pretty exciting stuff, but as a learning game designer, we don’t have to rely on them if our game is being deployed in a supported environment. For example, many of the games we’ve designed have been deployed in classrooms. These games can have developed surrounding curriculum that lets teachers use the game experience like a “digital field trip” or “lab” connecting the experience to other activities, worksheets, even textbooks or traditional assessments. This again is something that should be documented as a strategy when you’re drafting your learning objectives.
Don’t use external sources as a crutch- if the game just supplies “engagement” and doesn’t offer a real play-based embedding of learning objectives, you might be entertaining your learners, but you’re also wasting their time.
Next article, we’ll cover how to port those learning and transfer objectives into gameplay mechanics. Stay tuned!