Case Study 1: Shigeru Miyamoto --- Observation, Feeling, and the Design of Joy

The Designer Who Looks at the World Differently

Shigeru Miyamoto does not begin his design process by thinking about games. He begins by thinking about experiences.

This is such a simple idea that it is easy to overlook, but it is the single most important thing that separates Miyamoto from the vast majority of game designers. While most designers start with genre conventions ("I want to make a platformer"), technology ("the hardware can do 3D now"), or market analysis ("open-world games are selling well"), Miyamoto starts with a feeling. Something he noticed in his daily life. Something that made him curious, delighted, or wonder "what if?"

The result is one of the most remarkable creative careers in any medium. Donkey Kong. Super Mario Bros. The Legend of Zelda. Pikmin. Wii Sports. Nintendogs. Super Mario Galaxy. Games so diverse in genre and mechanic that they appear to have nothing in common --- except that every single one of them began with Miyamoto observing something in the real world and asking: how would this feel as a game?

Caves, Gardens, and Dogs: Where Games Come From

The Legend of Zelda (1986)

As a boy growing up in Sonobe, a rural town near Kyoto, Miyamoto explored the hills and forests surrounding his home. One day, he found the entrance to a cave. He stood at the mouth of it, frightened and fascinated. He came back the next day with a lantern and went inside. The cave branched. He chose a path. He found chambers he did not expect.

Decades later, he made The Legend of Zelda.

The connection is not metaphorical. Zelda is a game about entering unfamiliar spaces with limited resources, choosing paths, discovering secrets, and feeling the specific thrill of not knowing what is around the next corner. The cave was the prototype. The game was the iteration.

Miyamoto has told this story many times, and it is worth paying close attention to what he doesn't say. He does not say "I had an idea for an adventure game." He says "I remembered how it felt to explore a cave." The starting point is not a design concept. The starting point is a feeling.

💡 Intuition: Most game design textbooks will tell you to start with a mechanic, a genre, or a core loop. Miyamoto's career suggests a different starting point: start with a feeling. Zelda started with the feeling of childhood exploration. The mechanics --- the items, the dungeons, the combat --- were designed to produce that feeling. If Miyamoto had started with "a top-down action game with items and dungeons," he might have made a competent game. By starting with the experience of exploration and wonder, he made a legendary one.

Pikmin (2001)

In the late 1990s, Miyamoto took up gardening. He spent time in his garden watching ants carry objects --- leaves, crumbs, dead insects --- back to their colony. He noticed that the ants worked together, that they followed trails, that their collective behavior produced results no individual ant could achieve.

Pikmin is a game about commanding tiny plant-like creatures who carry objects, follow trails, and achieve collectively what no individual Pikmin could accomplish. The game is a real-time strategy game, but it does not feel like one. It feels like gardening --- planting, growing, harvesting, nurturing. The Pikmin themselves are vulnerable and endearing. When they die, the player feels guilt. When they succeed, the player feels the satisfaction of a well-tended garden.

The design insight: Miyamoto did not set out to make a real-time strategy game. He set out to capture the feeling of watching small creatures collaborate in a garden. The genre emerged from the feeling. The mechanics --- the plucking, the throwing, the color-coded abilities --- were designed to support that feeling. If the mechanics had not served the feeling, Miyamoto would have changed the mechanics. The feeling was the constant. The mechanics were the variable.

Nintendogs (2005)

Miyamoto got a dog. He observed the joy of interacting with a pet --- the responsiveness, the unpredictability, the way a dog looks at you, the way it reacts to your voice and touch. He wanted to capture that joy on the Nintendo DS.

Nintendogs is not a game by most definitions. There is no win condition. There is no fail state. There is no challenge beyond the mundane tasks of feeding, walking, and grooming a virtual dog. By Salen & Zimmerman's definition, it is not a game. By Costikyan's definition, it is not a game. It sold 24 million copies.

Nintendogs succeeds because Miyamoto was not designing a game. He was designing an interaction. The DS microphone lets you call your dog by name. The touchscreen lets you pet it. The dog responds to your voice with animations that feel --- irrationally, impossibly --- affectionate. The design was not "make a pet simulation." The design was "make the player feel the way I feel when I interact with my dog."

Design Is Systems, Not Ideas

Miyamoto's career illustrates the chapter's central argument with unusual clarity: the idea is not the design. Zelda's idea --- "explore caves and fight monsters" --- is generic. A hundred designers could have had it. Zelda's design --- the specific way items unlock new traversal options, the way dungeons escalate in complexity, the way the overworld rewards curiosity --- is what made it a masterpiece.

What Miyamoto brings to each project is not a better idea but a better process:

1. Observation: He notices something in the world that produces a compelling feeling.
2. Abstraction: He identifies the core elements of that feeling --- what specifically makes it interesting?
3. Mechanics: He designs game systems that reproduce those elements.
4. Testing: He builds prototypes and plays them relentlessly, tuning until the feeling is right.
5. Editing: He cuts everything that does not serve the core feeling.

This process is systematic. It is repeatable. It produces results across wildly different genres and platforms. And it begins --- always --- with looking at the world.

🛠️ Design Exercise: Go outside. Spend 15 minutes observing something --- anything. A playground. A grocery store. Traffic at an intersection. Birds on a wire. Ask yourself: what is interesting about this? What feeling does it produce? Could that feeling be the seed of a game? Write one paragraph describing a game concept inspired by your observation. You are not trying to make a good game concept. You are practicing Miyamoto's first step: seeing the world as design material.

Wii Sports: The Observation That Changed an Industry

Perhaps the most commercially significant application of Miyamoto's observational method came with Wii Sports (2006). Miyamoto observed that non-gamers --- parents, grandparents, people who had never touched a controller --- could understand the physical act of bowling, swinging a tennis racket, or throwing a punch. They did not need to learn button mappings. They already knew the motion.

Wii Sports stripped away everything that makes traditional games intimidating to non-gamers: complex controls, on-screen button prompts, genre conventions, skill trees, progression systems. What remained was the motion itself. You swing the Wii Remote and the on-screen character swings a tennis racket. The motion IS the mechanic.

The result: Wii Sports sold 82 million copies, making it one of the best-selling games of all time. It was played in nursing homes, at family reunions, and by people who had never played a video game before. Miyamoto did not achieve this by having a brilliant idea. He achieved it by observing that the barrier to gaming was the controller, and then designing a system that removed that barrier.

The MDA framework illuminates what happened. The mechanic: physical motion maps to in-game action. The dynamic: social play emerges because anyone can participate, regardless of gaming experience. The aesthetic: fellowship --- the joy of playing together. Miyamoto designed the mechanic. The dynamics and aesthetics emerged from it. And the observation that started it all was simply watching people struggle with traditional controllers and asking: what if they didn't have to?

The Controls Come First

Miyamoto has a famous design principle that is deceptively simple: start with the controls.

"What makes a good game?" an interviewer once asked him. His answer: "A good game is one where, before you even start playing the game properly, just moving the character around is fun."

This explains why Mario's jump is one of the most refined mechanics in gaming history. The variable jump height (tap for a hop, hold for a leap). The momentum (Mario accelerates, decelerates, and slides). The air control (you can adjust direction mid-jump). The weight (Mario feels like he has mass, not like a weightless sprite). These are not afterthoughts. They are the foundation. Everything in Super Mario Bros. --- every enemy, every platform, every power-up --- was designed to interact with the jump. The jump came first.

Super Mario 64 took this further. Miyamoto's team spent months --- months --- just making Mario feel good to control in 3D space before designing a single level. Run, jump, triple jump, long jump, wall jump, ground pound, dive, crawl. The control vocabulary was established first. The levels were designed to exploit that vocabulary. The order matters: controls, then content.

This principle applies far beyond Nintendo. Celeste's dash was refined obsessively before levels were designed around it. Rocket League's car-ball physics were tuned for months before arenas were built. The best action games in every era share this DNA: the feel of the core interaction was perfected first, and everything else was built on top of it.

Consider the contrast with games that get this wrong. There are countless indie platformers where the character moves stiffly, jumps with no sense of weight, and controls as if the designer implemented "jumping" as a checkbox feature rather than a craft. The levels might be clever. The art might be beautiful. But the moment-to-moment experience of controlling the character feels wrong, and no amount of content can fix that. The foundation is cracked, and everything built on top of it is unstable.

Miyamoto understood this intuitively. He did not articulate it as a formal principle until interviewers asked him to explain his process. The principle was embedded in his practice: before designing any content, make the core interaction feel good. In MDA terms: get the mechanic right first. The dynamics and aesthetics will follow.

✅ Best Practice: Before you design levels, enemies, or progression systems, ask yourself: is the core interaction fun in an empty room? If your character does not feel good to move in a featureless gray box, no amount of content will save the game. The controls are the foundation. Build on a solid foundation or build on nothing.

What Miyamoto Teaches About Design

Miyamoto is not a programmer. He is not an artist. He does not write music. His genius is not technical --- it is perceptual. He sees the world differently. He notices the things that most people filter out. And he has the craft to translate those observations into systems that reproduce the feelings he noticed.

This is what the chapter means when it says the designer creates experiences through systems. Miyamoto does not create games. He creates feelings --- the feeling of exploring a cave, of tending a garden, of playing with a dog, of running and jumping for the sheer joy of it --- and the games are the systems that deliver those feelings to millions of people who will never explore a cave in rural Kyoto.

The lesson for every designer:

1. Look at the world. Your best ideas will not come from other games. They will come from the things you notice when you are not playing games.
2. Start with feel. The experience comes first. The mechanics serve the experience. Not the other way around.
3. Prototype relentlessly. Miyamoto does not design on paper. He designs by playing. If it doesn't feel right, change it.
4. Cut what doesn't serve. Miyamoto's games are famously polished because he removes everything that does not contribute to the core experience.
5. Trust the process. The gap between "watching ants in my garden" and "shipping Pikmin" is enormous. But the process that bridges it is the same every time: observe, abstract, build, test, refine.

The idea person says "I should make a game about ants." Miyamoto watches the ants. He asks what makes them interesting. He builds a system that captures that interest. He tests it until it works. He ships it. That is design.

The Counterpoint: What Miyamoto Gets Wrong

No designer is infallible, and Miyamoto's approach has limitations worth understanding.

His observation-first, feel-first philosophy works brilliantly for the types of games he makes: broadly accessible, mechanically refined, family-friendly experiences. But it is less applicable to games driven by narrative complexity (Disco Elysium), systems depth (Dwarf Fortress), or thematic ambition (Death Stranding). Miyamoto's method produces games that feel wonderful to play but rarely challenge the player intellectually or emotionally in the way that narrative-driven design can.

Miyamoto has also been criticized for his approach to story. He famously deprioritizes narrative in favor of gameplay, once telling the Super Mario Galaxy team to reduce the story because players do not play Mario games for the plot. This is true --- but it also means Miyamoto's games rarely achieve the emotional resonance of a Journey, a Celeste, or a What Remains of Edith Finch. His design philosophy trades narrative depth for mechanical polish. That is a tradeoff, not a universal truth.

The lesson is not that Miyamoto's approach is wrong. It is that Miyamoto's approach is one approach. It is extraordinarily effective for its goals. But it is not the only way to design, and understanding its limitations helps you develop your own philosophy rather than simply imitating a master.

Every designer should learn from Miyamoto's observational method and his commitment to feel. Not every designer should be Miyamoto. The best designers take what works from every tradition and combine it into something that serves the specific game they are trying to make.