Build a Simple Digital Puppet for an Animated-Series Pitch Test
Build a Simple Digital Puppet for an Animated-Series Pitch Test
A simple digital puppet is a small set of layered artwork with controls attached to it, built so that one character response can be performed instead of described. That is the whole job. It is not a demonstration that a series can be animated, staffed, scheduled or paid for, and it becomes less useful the moment it starts implying otherwise.
So the sequence is short: write one action. Build only the parts that action needs. Inspect the rig before you trust it. Record the action once. Then hand over the reusable puppet and the viewable performance as two separate things, and check each one on its own.
Everything below runs on an invented example — a rain-jacketed courier who notices something offscreen, reconsiders, and reaches for it. No puppet has been built and no take has been recorded for this article. The steps are the ones you would take, in the order that saves the most rework.
Write the action before you decide what the character has
The temptation is to build a character and then ask what it can do. That produces a rig with eyebrows, hand swaps, a mouth set, and no answer.
Start with the response instead. Write it as a sentence with three beats:
The courier notices something off to the right, half-comes back from it, then reaches across with the right hand.
Now sort the character into two piles.
Must move: the head (the turn), the two eyebrows (the lift and settle), the right arm and hand (the reach).
Stays still: the torso, the left arm, the satchel strap and bag, everything from the waist down if you frame it waist-up.
That sort is the actual design work. Everything in the second pile is scope you just declined, and you declined it because a viewer watching four seconds will not miss it. The satchel strap matters for a different reason: it crosses the chest, so it is a part that must stay welded to the torso while other parts move nearby. That becomes a rig question in a minute.
Also write down what you are deferring, out loud, so it does not sneak back in: lip-sync, hand-shape swaps, a second expression set, a walk. Each one is another claim you have to support in the room, and pitch rooms are unkind to claims you cannot back. Lip-sync in particular is a separate engineering job with its own artwork requirements; it does not belong in a test whose question is "can this character reach for something in a way you believe?"
Layers are the rig
The artwork is the rig in this class of tool. Adobe's Character Animator takes layered PSD or AI artwork and turns it into a puppet, and the page on preparing artwork is explicit that named layers and tags are what map your drawing to controls, and that independent groups, handles and attachment origins are what determine how a region deforms. Nothing about that is decorative bookkeeping. A layer you forgot to name is a part that will not move.
Keep two files, not one:
- The untouched master artwork. You will want it when a repair goes sideways.
- A working copy, organized for movement.
In the working copy, group artwork by the pile it landed in. Head and its features together, torso and satchel together, right arm and hand together as its own thing, left arm as its own thing. Name the layers the way the documentation's conventions expect — the head layer is the head, the eyebrow layers are eyebrows, and so on — because those names are how the rig knows what it is holding. Read Adobe's tag list rather than guessing at it; the names are a fixed vocabulary, not a private shorthand, and a near-miss name is a part that silently does nothing.
There is one more decision hiding in the artwork, and it is the one that separates a rig that looks right from a rig that behaves.
Rigid or deforming? The head is flat and drawn from the front. It does not need to squash when it turns; it needs to rotate. Treat it as rigid. The right arm is a sleeve shape with a hand at the end. You could add warp handles so the elbow bends organically. Do not — not for this test. A straight arm that pivots at the shoulder answers "can it reach?" completely. A bendy elbow answers "how does it reach?", which is a question for a later, better-funded pass.
The satchel strap is the interesting one. It is rigid, it belongs to the torso, and it crosses territory that other groups sit near. Get that wrong and it will slide up the courier's neck every time the head turns. Check it early.
Inspect the rig before you trust it
Once artwork is imported and tagged, you have a puppet. You do not yet have a puppet that does what you drew.
Before recording anything, move each part on its own and watch what else moves. Where does the head pivot — at the neck, or somewhere near the middle of the head layer's bounding box? Does the reach originate at the shoulder, or does the whole body swing? Does the strap stay on the chest?
This is where the example earns its keep, so here is the failure, in detail.
What went wrong. In the first working file, the courier's right arm and hand were left inside the same group as the torso — one "Body" group holding jacket, sleeve, hand, strap and bag. The group's attachment origin sat near the middle of the composite, which is where a default origin lands when nobody sets one. When the reach was driven, the whole group rotated around that midpoint. The torso swung with the arm, the satchel strap tilted off the chest, and the belly silhouette stretched sideways toward the hand. The arm technically moved. The character looked like it was being pulled by a rope attached to its stomach.
The focused repair. Two changes, no new controls:
- Move the sleeve and hand artwork out of the body group into their own independent group, leaving the torso, strap and bag behind. Independent groups move independently; that is the point of the split.
- Set that arm group's attachment origin at the shoulder — the point on the torso where the sleeve meets the body — instead of accepting the default center.
Nothing else. No warp added, no extra joints, no new tags. The reach now pivots at the shoulder, the strap stays put, and the jacket silhouette holds.
Keep the broken version. Save it as its own project state or its own export, labeled. It is the clearest record you will ever have of what an attachment origin actually controls, and if you show the repair to anyone, it is the "before" half of a two-beat comparison. Do not open the pitch with it. A blooper reel is entertaining; a labeled before-and-after is evidence that you know your own rig.
One sequencing note that will matter later: Adobe documents that artwork edits update the puppet, while a replaced track source can retain existing recordings if the general puppet structure is retained. Do the artwork and origin work first. Record the take you intend to keep afterwards. Recording early and fixing the art later can change how a retained performance reads, especially when the rig's structure or attachment changes.
Record the bounded action and judge what it reads as
Now perform it. Four seconds, three beats, using the controls you actually have: head turn, brows, shoulder rotation on the right arm.
Before you commit to a keeper take, cheat a little. Push the arm control to its end position and look at the pose as a still. In an early pass at this example, the arm pivoted correctly from the shoulder but finished level with the chest and close to the body, so the outstretched arm read as the courier hugging itself. That is not a control problem and it does not need a new control. It needs the end pose changed — arm raised further, more air between hand and torso — which is an artwork edit, best made before recording rather than after.
Then record once and watch the take at full speed without scrubbing. Ask what a viewer sees, not whether the puppet moved.
If someone watching it cannot tell whether the courier is reaching for the object or recoiling from it, the reach is not legible yet, and the fix is usually in the silhouette and the gaze direction rather than in more controls. If the gesture only reads when you explain which three controls you moved and in what order, simplify the gesture. A viewer does not get narration.
What you have at the end of this is one response, performed, legible. That is a real result. It is also the only result it is honest to present.
Two deliverables, checked separately
Two different things need to leave your machine, and they are not interchangeable.
The puppet asset — the reusable rig, exported through the supported export route. Adobe documents that this export does not include recorded takes or timeline-track parameter changes. Anything you performed lives in the scene, not in the puppet.
The performance — the recorded action exported as viewable media through the route your installed version supports, so a person can watch it without your software, your project file, or your explanation.
Check each one as itself.
Reimport the puppet into a fresh project and drive the head, the brows and the right arm. If the shoulder origin survived and the arm still pivots where it should, the asset is sound. If a part has lost its behavior, you have learned exactly what the export carries, which is worth knowing before you hand it to anyone.
Play the media file on a machine that is not yours. Full screen, no editor, sound off. That is the audience condition for this kind of material, and it is the only test that tells you whether the reach survived the trip.
What a four-second test is allowed to claim
One readable response, two checked outputs. Name the application version you built it in, since rig behavior is version-specific and someone rebuilding your file needs to know.
What this does not claim: stylistic range across episodes, throughput, schedule, animation budget, or readiness for volume. A responsive arm proves the courier can reach for something on cue, in this rig, in this take. A series needs recurring characters, scene-to-scene consistency, revision under notes, and a cost structure — none of which a small rig test touches.
That modesty is the advantage. A creator who says "here is one thing this character can do, and here is the file, and here is what it cannot do yet" is making a claim the room can check. A creator who implies the pipeline is solved is making a claim the room will test, and the test will be about a satchel strap sliding up a neck.
Frequently asked questions
What should be written before deciding what the character has?
Write the response as a bounded action with three beats—for the rain-jacketed courier, noticing something offscreen, half-coming back, then reaching with the right hand. Then sort parts into must move (head, eyebrows, right arm and hand) and stays still (torso, left arm, satchel strap and bag, lower body if framed waist-up). Building a character first tends to produce controls with no answer.
Why should lip-sync, hand-shape swaps, a second expression set, and a walk be deferred in a short pitch test?
Each is another claim that must be supported in the room. Lip-sync is a separate engineering job with its own artwork requirements and does not belong in a test asking whether one reach reads as believable. Write down deferrals so they do not sneak back in.
How should artwork layers and groups be organized for this kind of rig?
Keep an untouched master and a working copy. Group artwork by whether it must move or stay still: head with features, torso with satchel, right arm and hand as its own independent group, left arm separately. Use named layers and documented tags, because a forgotten or near-miss name is a part that silently does nothing. Independent groups, handles, and attachment origins determine how a region deforms.
What went wrong in the courier rig example, and what fixed it?
The right arm and hand were left inside the same 'Body' group as the torso, so the group's default attachment origin near the composite's middle made the whole group rotate when the reach was driven: the torso swung, the strap tilted, and the belly stretched toward the hand. The repair was to move the sleeve and hand into their own independent group and set that group's attachment origin at the shoulder. No warp, joints, or new tags were added.
What can a four-second puppet test honestly claim?
It can claim one readable response and two checked outputs: the reusable puppet asset and the viewable performance. The puppet export does not include recorded takes or timeline-track parameter changes. The test does not claim stylistic range, throughput, schedule, animation budget, or readiness for volume. Name the application version because rig behavior is version-specific.