A quick disclaimer before we dive in: when I say "feelings," I mean state machines, bond progression, and interaction history — not an LLM. Mochi ...
For further actions, you may consider blocking this person and/or reporting abuse
That's such a cool idea. I've thought about something like this but I can't decide on the character. 😄
One thing I'd like to know: how are the animations actually made? I spotted Pixelorama in one of the screenshots, are you drawing frames there and exporting sprite sheets? Curious how they get from the editor into Cairo.
I'm planning to build something like this at some point to make my long coding sessions a bit more fun, so your experience would definitely be helpful.
Yep! You spotted Pixelorama 😄 Most of Mochi’s animations start there. I draw the sprites/frames by hand, usually working at a really small native resolution, then export the individual PNG frames or a sprite sheet.
On the code side, Mochi has an animation player that takes those frames, their timing, looping behavior, etc. and renders them through Cairo. So an animation is basically: draw frames → export → define the animation/timing → Mochi’s state system decides when to play it.
I also use a little AI in the art workflow. I’ve been experimenting with PixelEngine for things like cleaning up animation ideas / generating a rough sequence, and then I go back in and redraw or fix frames manually so they actually match Mochi’s design and move consistently. It’s definitely more of a hybrid workflow than “type prompt → finished animation.”
Funny side story: I actually ended up with a ton of PixelEngine credits because I found an exploit/bug in their credit system and reported it to them 😂 They gave me credits afterward, so now Mochi gets to benefit from my accidental security testing.
The part that surprised me most is how much tiny timing changes matter. Holding one frame for 80ms vs 140ms can completely change whether an animation feels cute, snappy, heavy, sleepy, etc. That’s probably been one of my favorite things to learn while building this.
And honestly, if you’re thinking about building one for your coding sessions, do it. Even a simple idle + blink + little reaction animation already gives the character a ridiculous amount of personality.
Also, learning how much of a pain Wayland is 😂 Getting a little animated creature to sit transparently on the desktop, stay interactive, move around, and behave consistently across Linux setups has honestly been half the project. I thought I was building a cute blob and somehow ended up learning window management, compositors, input handling, GTK, and XWayland compatibility.
That sounds like a lot of hard work, so when I finally make up my mind about what kind of character I want to create, I'd better set aside a solid amount of time for building it. Using an AI workflow is actually a great idea, especially for someone like me who's no animation genius 😄 Maybe I'll come back with a couple of questions if I really get stuck at something.
And your funny story is really interesting, you should write more about that. Finding those kinds of bugs, and actually getting rewarded for it is a hell of an experience. So go ahead and write one of those "I don't wanna brag, but lemme brag about it..." articles 😂
LOL okay, now I really do feel obligated to write the “I don’t wanna brag, but…” article 😂
Seriously though, thank you, I really appreciate the kind words. Mochi has definitely been one of those projects where I keep stumbling into way more work than expected, but also way more learning than expected too. A lot of it has just been me making something weird, hitting bugs, figuring things out, and slowly shaping it into something real.
And yes, if you end up building your own character, absolutely come back with questions. I’d be happy to share what I’ve learned and hopefully save you a little trial and error 😅
Also, thank you to the community curators for the gem that genuinely made my morning 💚
No problem, glad I did. It was so insightful, and it happened to make someone's morning, so it's a win-win situation. 😄
Actually, I've just realized this is the first gem I've ever given out.
Say hello to Mochi from me when he wakes up. 👋
Cute!
GTK timeout callbacks can still run after Mochi has changed state, so an old callback can overwrite the sprite's current animation. A state-generation check at callback time makes that race testable.
ohhh yeah, this is exactly the kind of weird little race condition I’ve been fighting with 😭 GTK is like “yep callback is still valid!” meanwhile Mochi has emotionally moved on to an entirely different state lol. Wayland + GTK have been keeping me humble since v0.1
the state-generation check is actually such a good idea though. especially because it gives me a clean way to ignore stale callbacks and make the bug reproducible in tests instead of just staring at Mochi like “why did you do that”
definitely stealing this for the next lifecycle pass, thank you 💚
A charming and well-written project post. The best parts are the thoughtful design choices: affection instead of obligation, privacy-respecting awareness, and letting Mochi stay quiet. It's also a good example of how a "cute little side project" teaches real skills like state management and handling timing bugs.
This is so ridiculously cute, and I love that there’s actually a lot of thoughtful design behind it too. The whole idea of making the interactions feel affectionate instead of turning it into another thing you have to maintain is such a good call. I’ve been messing around with a tiny desktop creature idea myself, so this was especially fun to read. Also, I have a pixel art app called Gumdrop Studio with a little gumdrop logo, so “a creature shaped approximately like a gumdrop” made me laugh way harder than it probably should have lol. Seriously though, this is awesome!
This is sweet 🥰 Good job!
This is such a good example of a “small side project” quietly turning into a proper systems problem 😄
The part about old GTK callbacks firing after Mochi has already changed state really caught my attention. You start with “make a blob move”, and suddenly you're dealing with lifecycle, state ownership, timers, Wayland and input handling.
I also really like the privacy approach of turning desktop activity into small signals instead of collecting everything happening on the screen. That feels like the right direction for something that's meant to live on your desktop.
The state-management problem you hit is real — I built something similar way back and the moment you add "sleep" as a state, every other interaction needs to check against it, and suddenly you've got a 12-branch switch statement just for click handling. Curious how you structured the state lifecycles — flat enum with timers, or something hierarchical where "sleeping" is a parent state that blocks input? That's usually where these projects either stay clean or turn into spaghetti.
The state machine is structured to prioritize certain states over others, with states like sleeping taking precedence. So if another random emote or interaction tries to fire, it first checks the current state; if Mochi is sleeping, that event gets blocked or deferred instead of interrupting it.
I’m trying to keep that priority logic centralized so individual interactions don’t each grow their own giant pile of conditionals 😭 It’s definitely been one of the trickier parts of keeping Mochi from turning into spaghetti as more behaviors get added.
Very relatable indeed. Once you do something, the problems naturally comes up. It is up to us to solve it and then eventually learn from it. I really like the design of Mochi. It's just sad that I can't draw something close to what you have done hahaha. Kidding aside, this is a great project!
This is such a fun project, but the state-management side is what really caught my attention. It’s impressive how a simple desktop pet turns into a real architecture challenge once you add animations, callbacks, context awareness, and Wayland support. Mochi is a great example of how small projects can teach you way more than expected.
yazi stilleri