


What if the breathing exercise itself became the game?
Breezy is a tangible interaction prototype for children aged 5–10. Instead of finishing a breathing exercise before you play, your breath is the controller.
- Responsibilities
- Game mechanics · Interaction design · Prototype build · Arduino and pressure sensor · Breath tuning
- Timeline
- 4 weeks
- Industry
- Children's health · Tangible play
Working interaction prototype. Not clinically validated.

A recorder, a sensor box and the game on a tablet.

Recorder, tube, Arduino in a 3D-printed box, game in the browser.
The problem started before the game.
Breathing problems affect
many children in India
Breathing is something we do without thinking about it. But when breathing becomes part of an exercise, children are often required to consciously control something that is otherwise automatic.

estimated prevalence of asthma among children in India
Each square is 1% of children

children included across 33 studies
Each figure is 10,000 children
[Prevalence of asthma among children in India: A systematic review and meta-analysis] — PubMed Central

???What research could and couldn't promise
Game-based interventions have been explored extensively in pediatric care, and tangible interfaces show real potential. But adding game elements alone does not guarantee engagement, and clinical effectiveness can't be assumed.





What children are offered today
The products we found ranged from digital breathing games to simple exercise devices. We compared the experience each one offers a child, not just its breathing function.

Smart breathing trainer for kids

Simple breathing exercise device
Existing tools showed that breathing could be measured or turned into play. The unresolved part was how the experience felt to a child being asked to repeat a breath. We wanted each breath to have an immediate, visible purpose.
What if breathing itself became something a child wanted to do?
Instead of putting a game after an exercise, we made the exercise the input. A breath would change the world on screen as it happened.

Recorder → tube → pressure sensor → Arduino Uno → USB → tablet.
Before making games, we had to understand what a breath could actually control.
We broke common breathing techniques into four behaviours a pressure sensor can actually detect. Each one became a different game mechanic.

Breath control is more than force. Pacing and steadiness matter too.
Different breathing behaviours need different mechanics.
Wind-based interaction is immediately understandable.
Use an object a child already knows how to blow into.
Feedback can make an invisible action like breath visible.
React to the breath instantly, on screen.
Children disengage when something feels harsh.
Support, never punish.
The gap became a design choice: make the controller feel familiar.
Our market scan showed several ways to connect breath and play. We compared those approaches against four design criteria, then chose an object a child could understand the moment they picked it up.
See the full comparison across four design criteria
BreezyFlute (recorder)Our working comparison of breath input, child focus, mechanics and adaptation.


A recorder is the controller.
It is blown straight from the mouth, and the object already tells a child what to do. The recorder was there to carry the interaction, not to become the goal.
Teaching children notes and finger positions on the recorder.

That would make Breezy a music-learning product and push breathing into the background.

One breath system became four game worlds.
Same input. Different breathing behaviour. Different mechanic.
On desktop, press Play when you are ready. Sound starts with the prototype, and scrolling away stops it. Pick a place, then hold SPACE to breathe.


Game mechanics
I looked at different breathing exercises used in lung therapy and checked three things:
Can a child do it independently?
Can it work with a recorder?
What should the sensor measure?
Four exercises stood out. Each trains a different type of breathing.
Little puffs, one after another.
A firefly at night became a frog in a sunny pond.
Information architecture
Designing for children changed even the smallest decisions.
At first, every game was supposed to have the same character.

Chamki

One character, four avatars, one for each place.

So every place had to be night.
Four animals, one for each world.
Each animal already does what its game asks: a frog hops, an owl glides, a bird sings, a butterfly rises. Animals rather than boy or girl avatars keep it universal.
One character with four avatars across the games.

It forced every place to feel like the same night world, rather than giving each game its own setting.

More illustration, sprites and dev time in four weeks. We paid for it with simpler motion.

Each one is a small sprite set: five expressions to react to every breath, and five poses to move without full animation. Tap a character to open its set.
The same instinct softened the cave.
A · Rock corridor
B · Light ribbon
C · Living vines
All three read as dark and narrow. That pushed us to rebuild the cave bright, and let the obstacle be something a child would want to touch.
It worked. It just felt severe for a five-year-old.
Same challenge. Completely different feeling.
A bright cave, where the obstacles are bubbles.
Dark, narrow tunnels felt severe for a five-year-old. Bubbles keep the same challenge but are something a child wants to touch.
A rock corridor, a light ribbon, and living vines for the cave obstacles.

They made the cave feel dark and narrow. Bubbles kept the challenge inviting.

And it changed how the game talks when a child struggles.


Every line on the right is from the working prototype. A weaker breath never ends the activity; it just gets you less far.
Our biggest interaction mistake became Breezy's most important feature.
One fixed number was supposed to count every breath.
The game reacted only when a breath crossed a single pressure threshold. It was simple to build, but our own testing showed how uneven that felt.
A short puff from one of us passed the threshold easily; someone else had to work much harder to reach it.

The fix: start with the child's own comfortable breath.
Two comfortable breaths, no target to hit.
Before each game, Breezy asks the child to breathe out twice at a level that feels ordinary to them.

That becomes this player's baseline.
The breath meter uses their comfortable range, leaving room for gentler and stronger breaths without one universal number.

Calibrate to each child with two comfortable breaths.
The game adapts to a personal baseline instead of asking every player to cross the same pressure threshold.
A fixed threshold would keep the rules simple and consistent across games.

Our team tests showed the same number could demand very different effort from different people.

It also changed how I think about personalization. It does not always mean picking an avatar or a colour. Sometimes it happens inside the interaction itself.
We built the complete breath-to-game loop—and learned where it needed work.
I built the game, wired the Arduino and pressure sensor, and tuned the mechanics against real breath values. The prototype let us test the full interaction with our own team and exposed the variation that led to calibration.

Testing the working prototype: breath through the recorder drives Lily Pad Hop on screen. This is the team testing it. Breezy has not been tried with children.

Arduino Uno + pressure sensor in a 3D-printed enclosure.

Reading raw pressure values while tuning a mechanic.

Recorder → tube → sensor box → game.

The game runs off the real sensor or off the spacebar. We built the fallback so mechanics could be tuned without the hardware attached.
Recorder → sensor → Arduino → game.
Breath genuinely drives all four games.
Building it exposed the threshold problem and let us fix it.
Not tested with children with asthma.
No clinician has reviewed it.
So: no claims about asthma outcomes or medical effectiveness.
Breezy is a working interaction prototype, not a clinically validated medical product.
Breezy changed how I think about designing for an audience.
Most interfaces I had designed before were for adults, where familiar patterns do a lot of the work. Designing for children made me ask very different questions.
The four questions behind every decision
So the cave became bright, and obstacles became bubbles.
So each animal already does what its game asks.
So a weak breath never ends the game; it just goes less far.
So replay comes from new places and stories, not harder levels.


Respiratory experts, parents and children first.
Check the breathing mechanics with clinicians.
Watch real children play, then iterate.
No difficulty levels. Replay comes from new places and stories.
If “harder” just means blow stronger, a child’s breathing ability becomes the difficulty setting.
Easy, Medium and Hard levels.

If harder only means blowing stronger, breathing ability becomes the difficulty setting.

Which structure works best: the loop or the path below.


Loop composition
Return to any place, in any order, as often as you like.

Path composition
A fixed route through the forest, one place after another.
Calibration also taught me that interactions don't have to be fixed. A system can adapt around the person using it.


But what I remember most about Breezy is something more personal.
It brought back the inner child in me.
Alongside everything I was learning about sensors and calibration, I kept coming back to a much simpler question:
“Would I have wanted to play this when I was younger?”
Breezy started as an experiment in connecting breath to a game.















