Three layers: mechanics, dynamics, aesthetics.

Hunicke, LeBlanc and Zubek introduced MDA at the AAAI Workshop on Challenges in Game AI in 2004. It was a small paper with an outsized half-life: twenty-two years later it's still the lens designers reach for when they need to talk to engineers, and the lens engineers reach for when they need to talk back. The reason is structural — MDA is a flow of cause and consequence, and flows are how programmers think.

The framework's key claim is asymmetric travel. A designer walks the chain in the order Mechanics → Dynamics → Aesthetics: they ship a rule, observe the runtime behaviour it creates, and measure the feeling that behaviour produces. A user walks it the other way: they feel something first (Aesthetics), notice the patterns (Dynamics), and only then — if they care — work backward to the underlying rules (Mechanics). Get the order wrong as a designer and you ship aesthetics you can't refactor.

For an engineering buyer the practical version is: every gamification claim Hatched makes needs a clear owner in one of these three layers. If a vendor cannot tell you which layer a feature lives in, you cannot extend, replace, or unit-test it. Hatched uses package boundaries to keep Mechanics, Dynamics, and Aesthetics separate enough to reason about, and the SDK lets you extend Mechanics-layer surfaces without forking the others.