The Tamagotchi Problem: Designing a Desktop Pet You Actually Want to Take Care Of
How I'm redesigning care, progression, and attention for Mochi, my Linux desktop pet
One of the original ideas behind Mochi was simple: I wanted something cute living on my Linux desktop. I like Codex Pets, but I wanted more from it.
I didn't want a productivity tool pretending to be cute. I didn't want an AI assistant constantly asking me questions. I just wanted a little creature that exists alongside whatever I'm already doing.
The project was supposed to be simple. But as Mochi has grown, I've run into a surprisingly difficult design problem:
How do you make someone care about a virtual creature without making taking care of it feel like work?
That question has become the central goal of Mochi's next development cycle. Let's call it — drumroll — the Tamagotchi Problem.
The Problem With Traditional Virtual Pets
Virtual pets have been around for decades, and most of them rely on the same loop. Mochi does too, to a certain extent. But most traditional digital pets have needs, and those needs slowly decrease. You perform actions to restore them:
- Hunger goes down, so you feed it.
- Happiness goes down, so you play with it.
- Energy goes down, so you let it sleep.
This loop works because humans are extremely good at becoming attached to things that appear to depend on us — especially when they're cute like Mochi. But there's another side to that design.
Eventually, the pet becomes another responsibility. You open your computer after a long day, and instead of being happy to see your little desktop creature, you're greeted by three empty meters demanding attention.
Feed me. Play with me. Clean something.
Congratulations — your cute desktop companion is now an unpaid internship, minus the recommendation.
That isn't what I want Mochi to become.
Care Without Punishment
For Mochi v0.3, I've been thinking about care differently. Instead of asking:
"What happens if the user doesn't take care of Mochi?"
I've started asking:
"What happens when the user does?"
That distinction sounds small, but it changes the entire system. A punishment-based care system removes something when the user fails to interact. A positive care system adds something when they do.
Imagine Mochi occasionally noticing that you've interacted with him several times throughout the day. Maybe he becomes more energetic. Maybe a new idle animation appears. Maybe he brings out a tiny object he hasn't used before. Maybe he remembers that you pet him often and starts reacting differently.
Nothing bad has to happen if you ignore him for three days. He doesn't die. He doesn't become miserable. You don't return to your computer feeling guilty. He simply continues existing.
Interaction becomes an invitation rather than an obligation.
Software Competes for Attention
This has also made me think about something that applies far beyond virtual pets.
Every piece of software competes for attention. Notifications want attention. Social media wants attention. Email wants attention. Games want attention. Operating systems want attention. Sometimes even apps that are supposedly helping us focus spend half their time telling us about features we haven't used yet.
For something like Mochi, respecting the user's attention has to be part of the design itself.
Mochi lives on the desktop. That means he already occupies an unusually personal space. He's there while someone codes. He's there while they watch YouTube. He's there while they're writing something at 2 AM. He's there while they're doing absolutely nothing.
If Mochi constantly demanded interaction, the entire idea would fall apart.
The goal isn't to make the user interact with Mochi. The goal is to make them want to.
Ambient Interaction
This is why I've become increasingly interested in ambient behavior.
A lot of Mochi's personality already comes from things that don't require the user to do anything. He breathes. He blinks. He falls asleep. He wakes up. He walks around. He reacts to computer activity. He occasionally performs little animations.
None of those behaviors require a button labeled INTERACT WITH MOCHI. They simply happen. The user notices them naturally.
That creates an interesting relationship between the software and the person using it. Instead of the application waiting for commands, Mochi feels like he has his own tiny lifecycle happening alongside the user's.
Sometimes you interact with him. Sometimes you don't. Sometimes you just notice him doing something silly in the corner of the screen.
Those moments are arguably more important than any menu or feature I could add.
Progression Without Grinding
Progression introduces another challenge. People like unlocking things — it creates discovery and gives interactions meaning. But traditional progression systems often rely on grinding.
Do something 100 times. Collect 5,000 points. Maintain a seven-day streak. Log in every day.
That kind of system would feel completely wrong for Mochi.
So I've been experimenting with a much softer idea of progression. Instead of experience points, Mochi could develop through familiarity. Repeated interactions might slowly unlock behaviors. Using your computer at night might eventually reveal a sleepy animation you've never seen. Typing frequently could cause Mochi to occasionally pull out his own tiny laptop. Dragging him around might eventually produce new reactions.
None of this needs to be presented as a progress bar. In fact, hiding some of the system might make it better. The user doesn't need to know:
PET MOCHI 8 MORE TIMES TO UNLOCK ANIMATION #17
They just need to discover one day that Mochi suddenly did something new. That surprise becomes part of the reward.
Building Personality From Systems
This is probably one of the biggest lessons I've learned while working on Mochi.
Mochi is a native Linux desktop pet, currently in active development. Follow along as v0.3 takes shape.
