Game Prototyping With Real Motion Not a T Pose

Game Prototyping With Real Motion Not a T Pose

Every prototype starts the same way. A capsule, a graybox, and a character sliding around in a T pose because animation is a later problem. Then you playtest, and the feedback is confusing.

The reason is that testers cannot separate how a game feels from how it presents. Ask someone whether the dodge timing is right while the character is gliding motionless across a gray floor, and they will answer a question you did not ask.

This piece covers why placeholder motion corrupts a playtest, what the minimum motion set for game prototyping actually is, and how to produce it in an afternoon rather than deferring it to a milestone that never arrives.

Because it removes the cues players use to read timing and space. Without those cues, testers substitute guesses, and the guesses arrive as confident feedback.

Three specific distortions turn up over and over, and they are worth recognizing because each one sends you fixing the wrong system.

None of those are animation notes. They are gameplay notes caused by missing animation, which is the most expensive kind of feedback because it sends you into the wrong file.

A prototype does not need an animation set. It needs the smallest number of clips that let a tester read the game correctly. That is roughly nine, and the discipline is refusing to add a tenth.

PINOC’s own walkthrough of the capture-to-export pipeline, posted by @Viggle_PINOC on X.

Nine clips, not a production set. Blend trees, directional variants and combo chains come later. Anything beyond nine is production work wearing a prototype badge, and it will slow down the change of direction that prototyping exists to enable.

Film the movement you can perform, prompt the action you cannot, and hand key nothing at this stage. The whole point is that the set is disposable.

The split is usually predictable. Locomotion is the part you can film: stand up, walk across the room, stop, and capture the motion from that clip. Your core verb, reactions and traversal are usually moves nobody in the room can perform, and high energy action is exactly what text to motion handles best. Ambient behavior can go either way.

Prototype capture test at 230 FPS, filmed by Jerron Jacques (@jerron_jacques) in collaboration with PINOC. View the original reel on Instagram .

An afternoon is a realistic target for nine clips including retargeting, which is what makes this worth doing at prototype stage rather than deferring.

Retargeting is the step most likely to blow that estimate, and it is worth setting up before you generate anything. Blender has no native retargeting despite what several tutorials imply, so you will need the free Retarget extension , which requires Blender 5.0 or newer, or a paid add on such as Auto-Rig Pro. Unreal users have the IK Retargeter built in and free.

Whichever you use, build the mapping once against your prototype character and then run all nine clips through it as a batch. Doing this per clip is the single most common way an afternoon becomes two days.

PINOC produces the clips from either a written description or a phone clip, and exports them as FBX or GLB straight into Unity or Unreal.

For prototyping specifically, text to motion carries most of the load, because at this stage you are inventing the game rather than reproducing a reference. You rarely have footage of the thing you are trying to test.

Two properties matter more here than elsewhere. Every run returns several takes, so choosing a feel is a comparison rather than a regeneration. And every clip lands on the same rig with Mixamo bone naming, so the nine clip set retargets as one batch rather than nine separate jobs.

What it does not do is finish anything, which at this stage is the correct behavior. A prototype clip that looks finished invites the wrong review.

Something, almost anything, rather than nothing. An empty world reads as a bug during a playtest, and testers will tell you the level is boring when the actual problem is that it is unpopulated.

Ambient motion is where generated clips are least controversial and most useful, because nobody is studying the arcs on a character forty meters away. Describe the behavior and take whatever comes back.

Offset the loops so twenty characters are not breathing in unison, and vary the playback speed slightly. Those two tricks do more for the illusion than better animation would.

The feedback gets specific, which is the only outcome that matters. Vague notes become actionable ones.

The typical before and after is stark. Before, testers say combat feels floaty, enemies are unfair and the level is boring. After, they say the recovery after the heavy attack is too long, the second enemy attacks from off screen, and the corridor before the arena has nothing in it. Those are three fixable problems instead of three moods.

This is worth doing early rather than at a milestone. The GDC 2026 survey found that 52% of developers believe generative AI is having a negative impact on the industry, so it is worth being precise about what is being claimed here. Nobody is suggesting generated clips ship. They are prototype scaffolding, and they get deleted.

When the design questions stop changing the answers. Until then, better animation is money spent defending a decision you have not made.

The promotion decision is worth making explicitly rather than by drift. Most of the nine clips die. A small number become the basis for real work.

One opinion stated plainly. The reason teams prototype with T poses is not that animation is expensive, it is that rough animation feels embarrassing to show. That instinct costs more than it saves, because it means every early playtest is measuring presentation instead of design. Hero characters earn hand keyed polish. During a prototype, the other twenty just need to behave.

You need enough for testers to read timing and space accurately, which is far less than a full set. Roughly nine short clips covering locomotion, your core verb, reactions, traversal and one ambient behavior will do it. Without them, feedback about pacing, spacing and weight is unreliable, because testers substitute guesses for missing visual cues.

Around nine, and the discipline is stopping there. Three locomotion, two action, two reaction, one traversal, one ambient. Directional variants, combo chains and blend trees are production work and will slow down the direction changes prototyping exists to enable. If you are building a tenth clip, check whether you are still prototyping.

No, and polishing it is actively counterproductive. Polished clips invite reviews of the animation rather than the design, and they create advocates who resist changing direction. Leave soft contact frames alone at this stage. The clips exist to make a playtest legible, not to look good.

Some of it, if it was exported on a standard skeleton rather than trapped in a scene file. Ambient and background motion frequently ships close to its prototype state. Locomotion almost always gets rebuilt as a proper blend tree. Decide which category each clip is in before you start polishing anything.

An afternoon is a realistic target for a nine clip set including retargeting, using generated motion rather than hand keying. That figure is what makes doing this at prototype stage worthwhile rather than deferring it. If it is taking a week, the set has grown beyond what a prototype needs.

Substantially, and usually in ways that are hard to spot at the time. The common pattern is testers reporting design problems that are actually legibility problems, such as calling an enemy unfair when the real issue is that nothing telegraphs its attack. Running the same test with and without real motion is the fastest way to see the difference yourself.

Prototyping exists to answer questions cheaply, and a T pose makes the answers unreliable. Not because it looks bad, but because it removes the information testers use to judge timing and space.

Nine clips fix that, and nine clips is now an afternoon rather than two weeks. That change in cost is the actual argument for doing this differently.

Build the set, run the test, then throw most of it away. Prototype animation that survives to launch was probably never a prototype.

Recommended articles