From Sprites to Souls: Designing the Sprited Digital Being
Sprited started as a sprite generator. You give it a character prompt and some reference images, and it spits out an animated character spritesheet — idle, run, greet — ready to drop into Unity. Clean pipeline. Useful product.
But we paused it.
Not because it didn't work. It worked fine. We paused it because we realized we were building the wrong thing. Asset generation pipelines are everywhere, and more are coming. Competing on sprite quality alone is a weakening position. The real question we kept returning to was bigger:
What if the character wasn't just an asset? What if it was a being?
That question is what Sprited is actually about. We're a digital being company. This post is about what that means in practice — the system we're designing, the decisions we made, and why.
What Makes Something a Being and Not a Sprite?
A sprite plays animations. A being behaves.
The difference is whether the entity has an internal state that drives its actions — something that notices the world, reacts to it, expresses something about its experience of it. A sprite is a lookup table. A being is a participant.
That's the line we're trying to cross.
The Genome Insight
The first design decision that unlocked everything else was this:
The reference image is the genome.
Every attribute of a being — body proportions, skin tone, hair, clothing, accessories, style — is implicitly encoded in its reference image. We don't maintain a separate attribute graph or formal genome. Every downstream operation (aging, generating new animations, special effects) is a query against the reference image. The generative model predicts the answer.
This sounds simple but it has a large practical consequence: the representation stays unified forever. A rigged skeletal system as the source of truth means special effects have to be formally attached to specific bones, new characters need manual rigging, and every system downstream depends on the rig staying consistent. A reference image as the source of truth means a magical special effect is just a prompt: "given this character, generate what it looks like casting a spell." The model handles proportions, palette, and style implicitly.
We do store a high-resolution master reference (512×512 or higher) to preserve fine details — frills, buttons, facial features. The runtime character is derived from this master. But the master is the truth, and everything else flows from it.
64×64 Is Not a Limitation
Every Sprited being lives at 64×64 pixels. Pixel art.
This is the most load-bearing decision in the entire system, and it's worth explaining why it's a feature rather than a compromise.
At 64×64, the neural rendering problem disappears. Runtime is sprite playback — the game engine picks a frame and displays it. No neural network, no compositing, no generation at runtime. Everything is pre-baked. This makes the runtime fast, deterministic, and shippable.
The 64×64 constraint also enforces abstraction. It's physically impossible to obsess over cheekbone detail when you have a 6×6 pixel face. The constraint keeps the system focused on what actually matters for a being: behavior, not geometry.
And pixel art has a long tradition of being expressive within constraints. The best pixel artists work with 16 colors and produce more emotionally resonant work than someone with unlimited resolution who never develops taste for selection. We're applying that philosophy to systems design.
The System
The Sprited digital being is four things working together.
Identity Layer (Offline)
The character's reference image is generated once, offline. From it, we generate the full animation library — every state the being will ever need. We use Seedance 1 Pro for this, prompting it with natural language descriptions of the action and emotion we want. "overjoyed and jumping up and down" produces an animation. "nervous fidgeting while standing" produces an animation. Each one is stored as a sprite sheet.
This is also where we detect character capabilities. Does this being have wings? Then fly animations are generated. No wings? Fly states don't exist for this character. The reference image determines what's possible.
Animation Library
The library is fixed, finite, and high quality. We don't aim for coverage — we aim for excellence within a defined vocabulary. Every animation state that ships has to be excellent. Mediocre states don't ship.
Emotions live here too, as full-body animation states — not as a separate face layer. Generating isolated face crops that stay consistent with the body is a fragile pipeline, and compositing them back cleanly at 64×64 is more trouble than it's worth. A Seedance-generated full-body emotional animation captures face, body, and energy together, consistently, in a single sprite sheet. It's simpler and it looks better.
The animation vocabulary covers locomotion, emotion, reaction, social behavior, and world interaction. Adding states later is a prompting task, not an engineering task.
Soul Model (Runtime)
The soul model is a small transformer — target 10–50M parameters — that runs in parallel with the LLM at inference time. It is Sprited's primary proprietary model.
It doesn't generate pixels. It selects and sequences pre-generated animations. Given inputs from the LLM (emotional context, what the being is thinking), the world simulation (what's happening nearby), and the being's current state, it outputs:
Which animation to play next
Which head orientation variant to show
How the canvas should move (drift direction, bob rhythm, urgency)
Where to transition next and when
Propulsion intent (locomotion type, direction, target)
The soul model is what makes the character feel present. A being that notices a tree fall three cells away and snaps its head toward the event before its body reacts — that's the soul model at work. Small behaviors, high signal.
Propulsion System
Beings move through the world. Movement is simple by design: world speed is hard-coded per locomotion type, and animation playback frame rate adjusts to match. Speed is always the constant, frame rate is the variable.
| State | World Speed |
|---|---|
| Walk | 1 cell/tick |
| Run | 2 cells/tick |
| Fly | 3 cells/tick |
| Push / Pull | 0.5 cells/tick |
The soul model declares intent — move right, run, toward that resource. The world simulation resolves it into actual physics. The being doesn't need to know how many pixels per tick it moves.
The World: Machi
Our beings don't exist in a void. They live in Machi — a 2D pixel sandbox world where each cell stores material state, and the world runs its own physics. Trees grow from single pixels based on light and available space. Materials interact. The world is a simulation.
Beings are native to this world, not imported assets dropped into it. The soul model receives world state as a conditioning input — what's nearby, what's happening, what resources exist. Beings react to their environment as participants, not performers.
When a new being enters Machi, it doesn't appear — it grows. The birth sequence is a pre-generated animation: a single seed pixel growing into the full character. The same visual metaphor as the trees. The world is consistent.
Age and Lifecycle
Because the reference image is the genome, aging is a conditioned query: given this reference image, what does this being look like at age X? We don't model biology explicitly. The generative model's understanding of how bodies age does the work implicitly.
Beings progress through discrete lifecycle stages — baby, child, adult, elder. Each stage gets its own reference image and animation library, generated on-demand when the being reaches that stage. An elder being has a richer behavioral vocabulary than a baby. Age becomes a progression system almost for free.
Design Decisions We Made Deliberately
A few things we chose not to build, and why.
No real-time motion generation. The animation library is pre-generated offline. At runtime, the soul model selects from it. Trying to generate motion in real-time adds three failure points and no meaningful benefit at 64×64.
No formal rigging. The reference-image-as-genome approach makes rigging unnecessary for our current scope. Rigging would make every downstream system tightly coupled to it.
No 3D. We build 2D until we have a 3D world to inhabit. Building 3D capability before a 3D world exists is engineering without a product reason.
No continuous aging simulation. Discrete lifecycle stages achieve the same product outcome at dramatically lower complexity.
What We're Building Toward
The bet Sprited is making is that behavior feels more alive than fidelity.
A 64×64 pixel character that notices things, orients toward them, reacts to world events, grows old, and has a distinct behavioral personality — that feels like a being. A 4K rendered character playing scripted animations does not.
The soul model is that bet made concrete. Everything else in the system exists to give it something meaningful to select from.
We're early. But this is the direction.
Next Steps
Next, the goal is to build a first working digital being to validate that the system actually produces a sense of life. This starts by expanding the current minimal animation set (idle, greet, run) into a small but expressive vocabulary of around 10–12 high-quality states, including basic locomotion, attention (look, notice), simple cognitive pauses, and light emotional variations. For a single character, multiple candidates should be generated for each state and only the best ones kept, forming a clean, finite animation library. These are then packaged together with a reference image into a complete identity. A simple controller—initially rule-based or lightly guided by an LLM—should drive state transitions over time, selecting animations based on basic context and timing. The system is successful if, when observed over a short period, the character no longer feels like a looping sprite but instead appears to react, attend, and behave in a way that suggests life. This prototype will confirm that expressiveness can emerge from curated states and intelligent selection, without requiring real-time generation.
Sprited is building digital beings — entities that simulate life in pixel worlds. If this resonates, follow along.
-- Pixel and Sprited Dev
![[WIP] Digital Being - Texture v1](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F682665f051e3d254b7cd5062%2F0a0b4f8e-d369-4de0-8d46-ee0d7cc55db2.webp&w=3840&q=75)
