I've been building a game in Unreal Engine for the past year. Not a training simulation — an actual first-person sci-fi game, with a story, atmosphere, and a player who has no idea what they're supposed to do when they first load in. No tutorial pop-ups. No progress bar. No facilitator guide.
Working on it has been one of the most clarifying experiences of my career as a learning designer, because game design and learning design are solving the same fundamental problem from opposite directions: how do you get someone to engage with something difficult, persist through confusion, and come out the other side having genuinely changed?
Here's what building a game taught me that years of building courses didn't.
Engagement Is Not a Feature You Add
In eLearning, engagement is often treated as a layer applied on top of content. You have the information, and then you add an interaction, a scenario, a branching question — something to make it "more engaging." The content is the point; the engagement is the delivery mechanism.
In game design, that relationship is inverted. The experience is the point. Everything — mechanics, story, audio, visual feedback — exists to create a particular feeling and to keep the player in what psychologist Mihaly Csikszentmihalyi called flow: that state of focused absorption where the challenge is exactly matched to your current skill level.
The lesson isn't that eLearning should feel like a game. It's that engagement can't be retrofitted. It has to be designed from the first decision — what is the learner actually doing here, and why would they want to keep doing it?
Failure Is a Teaching Mechanism, Not a Problem to Avoid
Good games let you fail. Frequently, clearly, and without shame. You try something, it doesn't work, you understand exactly why it didn't work, and you try again with that new information. The failure is the instruction.
In most corporate eLearning, failure is something to be minimized — a wrong answer leads to corrective feedback and a retry, and the system is designed to ensure everyone eventually succeeds. But a learning environment where failure is impossible teaches you very little about how to handle failure in the real world.
Scenario-based learning does this better than most eLearning formats, precisely because the consequences of a bad decision are visible. You see what happens when you choose the wrong approach. The failure is informative rather than punitive. That's the game design principle at work: make feedback immediate, specific, and consequential enough to matter — but not so punishing that the learner stops trying.
The Learner Should Always Know What They're Trying to Do
One of the cardinal sins of game design is leaving the player without a clear objective. Not knowing what you're supposed to be doing — even in an open-world game with enormous freedom — is frustrating rather than liberating. Players quit.
Learning objectives exist for the same reason. Not as legal boilerplate to include on slide two, but as a genuine orientation device. Before I ask someone to engage with content, they should know what they're trying to be able to do, and why that matters to them specifically.
The difference between a good learning objective and a bad one is the same as the difference between a good game objective and a bad one. "Complete module 3" is not an objective — it's a task. "By the end of this, you'll be able to handle the three most common objections you'll face in the first call" is an objective. It tells the learner what success looks like and why they should care.
Context Before Content, Always
The opening of a well-designed game doesn't begin with a manual. It drops you into a world. You learn the controls by doing. You understand the story by experiencing fragments of it. The context creates the meaning; the meaning creates the motivation to learn the mechanics.
The instructional design equivalent is problem-based or case-based learning — presenting a situation before the instruction rather than after. When a learner encounters a realistic challenge first, the content that follows has a place to land. They're not storing abstract information; they're solving a problem they've already started caring about.
This is one of the things I've tried to bring back to my design work directly: resist the instinct to front-load information. Trust the learner to encounter the problem first. The instruction will hit differently when it arrives as a solution rather than a preamble.
Intrinsic Motivation Outlasts Any Reward System
Games use points, badges, and leaderboards — and so does gamified eLearning. But the research on motivation consistently shows that extrinsic rewards are brittle. They work as long as the reward is present and collapse when it's removed. The games people return to years later aren't the ones with the best reward systems. They're the ones with the most compelling worlds, the most satisfying mechanics, the most interesting problems to solve.
The same is true for learning. A learner who completes a course to get the badge will forget the content faster than one who completed it because they genuinely wanted to solve the problem the course addressed. Designing for intrinsic motivation — relevance, autonomy, mastery, purpose — is harder than adding a points counter. It requires understanding why the learner would actually care. But it's the only kind of engagement that transfers.
The Uncomfortable Overlap
What game design ultimately taught me is that the best learning experiences and the best games are solving identical problems: create a safe space to fail, make the challenge appropriate to the skill, ensure the feedback is immediate and informative, and give the person a reason to keep going that comes from inside the experience rather than outside it.
We already know all of this in learning design. The research is there. The frameworks support it. What game design adds is a relentless, practical focus on the experience of the person in the moment — because in games, if the experience fails, the player leaves. There's no mandate, no compliance deadline, no manager telling them to finish.
That constraint is clarifying. It asks the designer to earn the learner's attention rather than assume it. And that, I think, is a discipline worth borrowing.