What if the way games get made is the reason so many educational games don’t work?
We think it is. The most-cited framework in game design was published in 2004 — and it’s good. We’ve used it. But it wasn’t built for games that have to actually change something, and it wasn’t built for how studios work today. So we extended it.
After years of building games that had to move the needle — on what students know, what employees do, how communities understand something — we formalized what we’d been doing all along into a production framework of our own: MADE Games.
The field has a playbook. That playbook has a gap.
Mechanics, Dynamics, Aesthetics — MDA for short — gave game designers and researchers a shared vocabulary for how games work as systems. It was published in 2004, it was built for practitioners, and it genuinely clarified a lot of muddled thinking. It became the most-cited framework in the field for good reason.
But it runs in a line. First you design the rules and systems. Then you watch how players interact with them. Then — at the very end — you evaluate whether the experience landed the way you hoped.
By the time you’re asking “did this work?” the game is already built.
For commercial games, that gap doesn’t always matter. For the work we do, it’s the whole problem.
When a game has to change what a student believes about water systems, or what a new employee actually does in a crisis, or how a community understands a public health issue — “hope it lands” isn’t a production strategy. You need to know what you’re building toward before you build anything.
We Start at the End
MADE stands for Mechanics, Aesthetics, Dynamics, and Experience. Three of those words will look familiar. What changed is where the process begins.
What should be different about the player when the game is over?
Before we touch a mechanic, before we talk about art direction, before we write a line of code, we ask one question: what do we want the player to walk away with? Not just how we want them to feel in the moment — but what should be different about them when the game is over. What they know. What they believe. What they’ll do next. Everything else gets designed in service of that answer.
From there, Mechanics and Aesthetics develop on parallel tracks.
Developers build and iterate on the systems players interact with. Artists build and iterate on the sensory and emotional world those systems live in.
Dynamics emerge from all of it.
Dynamics are what actually happens when a real player sits down with the finished game — the behaviors and patterns that emerge from mechanics and aesthetics working together. You can’t write them into a design document. You can only create the conditions for the right ones to appear, and then watch for whether they do. That’s why we test early, often, and keep adjusting.
Those two tracks aren’t separate — they’re in constant conversation.
A loan mechanic in a financial literacy game means something completely different depending on whether the visual design makes the player feel calm or anxious. Our Designers hold that conversation and keep the end Experience in view.
The result is a production process that’s iterative, team-based, and oriented around a question most frameworks only ask at the end: did the game actually do what we set out to do?
We’re formalizing that process in a peer-reviewed paper now — because if it works for us, it might work for other teams too.