ESSAY · EMBODIED & POETIC INTERACTIONS
Most game controllers are remote controls.
You sit on a couch, thumbs on plastic sticks, pressing buttons that tell a character on a screen to run, jump, shoot. Your body is neutral. Still. The only parts of you that matter are your thumbs and your eyes. The rest is irrelevant.
This is a choice, not a necessity. It's a design pattern inherited from early arcade cabinets and television interfaces, calcified over decades into an assumed default. But it's only one way to play.
What if we designed games where the body wasn't a remote control, but the system itself? Where your posture, your breath, your involuntary tremors became part of the gameplay? Where the physical cost of an action matched its narrative weight?
This is embodied play. And the 4E framework—Embodied, Embedded, Enactive, Extended—gives us a rigorous way to think about designing for it.
This essay applies the 4E framework specifically to games and alternative controllers. It's a companion to the broader frameworks discussion, but focused on practical questions: How do we move from buttons-as-input to bodies-as-systems? What does it mean to design a controller that has its own "will"? How can we make the struggle with a tool part of the meaning?
Before we begin: these frameworks are structures for thinking, not templates for copying. Use them to organize your initial thoughts, to see patterns, to ask better questions. Don't use them as checklists that guarantee "good design." Design is messier than that. Frameworks are scaffolding—helpful while you're building, but not part of the final structure.
Cognition isn't just "thinking"—it's the state of your physical hardware. Your body isn't a vehicle for your mind. It is your mind, in a very real sense. How you're positioned, how tired you are, what sensations you're experiencing—these shape what you can think and how you experience the world.
In game design, this means the player's physiological state should be part of the system, not external to it.
Using the body only as a "joystick"—simple input, mechanically translated. You wave your arms, the character waves their arms. You tilt the controller, the car turns. The mapping is literal and the body is instrumentalized.
This isn't embodied design. It's just moving the buttons to different body parts.
How can the game state be driven by the player's physiological limits?
Not just their actions, but their capacity. Their endurance. Their heart rate. The micro-tremors in their hands that reveal nervousness they're trying to hide.
If the game character is doing something difficult—climbing a cliff, holding a heavy door, staying perfectly still while hiding—the player should feel a corresponding physical strain.
Don't just hold a button to "sprint." Make the player pump their arms. The input becomes their actual physical energy, depleting in real-time. When they're tired, the character is tired. When they're shaking from holding a pose, the character is shaking.
Complete this sentence:
"After 5 minutes of playing, my player's physiological state will change to [Exhausted / Calm / Tense / Heavy] because..."
Example: You're designing a game where the player is a tired, wounded animal trying to reach safety. The controller is a weighted object they must hold at arm's length. The longer they play, the heavier it feels. Their shaking arms translate to the animal's exhaustion on screen. The game doesn't end when they press "quit"—it ends when their arms literally can't hold the weight anymore.
The body sets the limit. The game respects it.
We don't play in a vacuum. We play in a world with gravity, furniture, walls, and distance. The physical environment shapes what's possible and what has meaning.
Most controllers ignore this. They work the same whether you're sitting at a desk, lying in bed, or standing in the middle of a room. The context is stripped away.
Designing a controller that's "universally accessible" to the point of being context-agnostic. It works everywhere, which means it belongs nowhere.
How can the physical environment or the player's posture affect the game?
What if the game demands a specific relationship to space? What if you can't play it sitting down? What if the room you're in becomes part of the level design?
The way a player positions themselves in physical space should be load-bearing for the game experience. Not incidental. Not convenient. Necessary.
If the game is about being a small creature navigating a dangerous world, maybe the player needs to physically crouch low to the ground to see from that perspective. The sensors only activate when they're in that position. The posture creates the emotional frame.
Complete this sentence:
"The player cannot play this sitting at a desk. They must [Crouch / Stand on one leg / Lean / Touch a surface] because..."
Example: A game about a bird in flight. The controller only works when the player stands with arms outstretched, mimicking wings. If they lower their arms, the bird falls. They can't cheat by sitting down—the accelerometers detect orientation. The physical impossibility of holding your arms up forever becomes the challenge of staying aloft. The room's ceiling height becomes a design constraint you work with, not around.
Context isn't a variable to eliminate. It's a material to design with.
We "know" the world by acting in it. Meaning isn't transmitted—it's enacted. It emerges through the negotiation between your intentions and the resistance of the world.
A perfectly transparent tool teaches you nothing. It's only through struggle, through the tool pushing back, that understanding develops.
The controller is perfectly responsive. It does exactly what you want, exactly when you want it. There's zero friction, zero delay, perfect 1:1 mapping between hand and screen.
This feels satisfying in a traditional game context. But it eliminates the possibility of relationship. A transparent tool is just an extension of your will. It can't surprise you. It can't teach you. It can't have a personality.
How can the controller have its own "physiological will"?
Not bugs. Not randomness. But something that responds to you in ways that aren't perfectly predictable. Something you have to learn to work with, not just command.
The controller should respond to how you use it, creating a conversation rather than a command structure. If you're rough, it gets skittish. If you're gentle, it opens up. The game character isn't just your avatar—it's a creature with its own internal state that you influence but don't fully control.
Complete this sentence:
"The player will 'struggle' with the controller by [Moving slowly / Balancing / Applying pressure]. This struggle represents the animal's [Fear / Weight / Personality]."
Example: You're controlling a wild, frightened animal using an ESP32 with an accelerometer. If you move the controller suddenly, the digital animal panics and runs in a random direction. You can't force it to go where you want through aggressive motion—that makes it worse. You have to learn to move slowly, deliberately, earning its trust through gentle guidance. The "correct" way to play emerges through practice, through feeling when the animal relaxes and when it tenses.
The meaning isn't in the controller or in the game. It's in the space between them, enacted through use.
The controller isn't an external tool you pick up and put down. At its best, it becomes a prosthetic—an extension of your body and mind. It changes how you perceive and think.
When you use a blind person's cane, you don't just feel the cane touching the ground. You feel the texture of the sidewalk through the cane. The cane becomes part of your sensory system. It extends your body.
Game controllers can do this too.
The controller is just a visual representation of your hand. You move your hand left, the screen hand moves left. It's a mirror, not an extension.
How can the controller change how the player perceives the world?
Not just what they can do, but what they can sense. What if the controller gives them a new way of experiencing space, sound, or time? What if it maps one sense to another?
Don't just map hand position to screen position. Map unexpected things to unexpected outputs. Squeeze pressure controls screen brightness. Head tilt changes audio frequency. Distance from the floor affects the game's time scale.
These mappings shouldn't be arbitrary—they should create a new sensory logic that makes sense through use.
Complete this sentence:
"When using this controller, the player's physiological senses are extended. Their sense of [Sight / Hearing / Balance] is now controlled by [Sensor Input]."
Example: A game about an animal with heightened hearing. Moving the puppet's head doesn't turn the camera—it changes the frequency spectrum of the audio you hear. High frequencies emphasize when looking up, low frequencies when looking down. You navigate by listening for the right pitch, not by seeing where to go. The controller extends your sense of hearing into a spatial navigation tool you didn't have before.
After playing for a while, you start to "hear" space differently even outside the game. The tool has changed your perception.
These aren't laws. They're practical heuristics that push you away from remote-control thinking and toward embodied experiences.
In standard games, actions are free. Pressing a button to run costs you nothing. In embodied play, actions have a cost.
The Rule: If a character is doing something difficult (climbing, sprinting, holding a heavy door), the player should feel a physiological strain.
Application: Don't just hold a button to "Sprint." Make the player shake the controller, pump their arms, or hold a physically uncomfortable position. The input is their actual physical energy. When they're tired, they feel it in their body, not just see it on screen.
Your controller should dictate how the player's body sits or stands in the room. The way a player stands or sits changes how they feel emotionally.
We don't just move because we're happy; we're happy because we move. This is the core of somatic theory—posture creates mood.
The Rule: Design the controller so it's impossible to use while sitting comfortably.
Application: If the game is about a "Sneaky Cat," place sensors so the player must crouch on the floor to reach them. The posture creates the mood. You can't fake the embodied experience by cheating the position.
Don't clean up the "messy" sensor data; use it. The most honest part of the body is the part we can't control.
The Rule: Standard engineering tries to remove "shaking" or "jitter" from sensors. Embodied design uses that shaking as a window into the player's nerves.
A joystick only records what you want to do. A physiological sensor records what you're actually doing.
Application: If the ESP32's accelerometer detects micro-tremors (shaking hands), make the character in the game "panic." The "mistakes" of the body become the gameplay. Nervousness isn't a bug—it's a feature.
Don't make the controller look like the animal; make it act like the animal's senses.
The Rule: Avoid "Literal Mapping" (moving a puppet arm to move a screen arm). Instead, use cross-modal mapping.
Application: Squeezing the controller (touch) doesn't make the character "squeeze" something—it makes the character's vision (screen brightness) change. You're giving the player a new, non-human sense. The point isn't mimicry. It's transformation.
Use the parts of the body the player cannot easily control. A button is a choice. A heartbeat or a breath is a fact.
The Rule: If the player has 100% control, it's a tool. If the player has 10% control, it's a relationship.
The game should have its own "internal life." The controller is just a way to influence it, not command it.
Application: Use sensors to track breathing or skin contact. If the player tries to "lie" to the game by playing fast, but their breathing is slow, the game should react to the breath, not the speed. The body tells the truth even when the hands try to fake it.
Before you call your design "finished," run it through these three tests. If it fails any of them, you're probably still in remote-control territory.
Question: If the player plays this for 10 minutes, will they be physically different (tired, calmer, warmer) than when they started?
If the answer is no—if they could play for hours without any physiological change—you're using the body as a button, not as a system.
Question: When I turn off the monitor, does the movement still feel interesting or challenging to perform?
If the physical action only makes sense because of what's happening on screen, you haven't achieved embodiment. The body's experience should be compelling on its own terms. The screen should enhance it, not create it.
Question: Is there a "delay" or "resistance" between the hand and the screen?
If it's a perfect 1:1 copy—hand goes left, screen goes left instantly and predictably—it's a tool, not an experience. There should be negotiation. The character should have some autonomy, some personality. The relationship should require learning.
Perfect transparency = remote control.
Productive resistance = embodied play.
I want to end where we began: frameworks are not templates.
The 4E structure, these thumb rules, the three-test checklist—they're all scaffolding. They help you see patterns, ask better questions, avoid common traps. But they don't tell you what to build.
Design is an act of creation, not template-filling. These frameworks are most useful at the beginning, when you're trying to organize vague intuitions into structured thoughts. They're less useful—maybe even harmful—if you treat them as recipes to follow.
Use them to start thinking clearly. Then, when you've found your direction, set them aside and make something that surprises you.
The best designs come from understanding the principles deeply enough that you can break them in interesting ways. Know the frameworks. Then forget them. Then, when you encounter a design problem, you'll find they've become part of how you see, not a separate thing you have to remember.
That's when they're actually useful.
If you want to explore these ideas further: