Code-Driven Stickman Animation: A Reusable AI Video Production Workflow

1. Reframing the Problem: Two Hidden Costs of Generative Video Models

For overseas short-form video teams, the first bottleneck is usually not creativity but the cost structure of the production pipeline. Generative video models rely on probabilistic sampling: every generation is effectively a new dice roll. With the same prompt, two runs can produce different character faces, body shapes, or lighting. This creates two ongoing costs:

1. Linear consumption of compute quota. When generation is billed by duration, output quality depends on how many attempts are made. Even a minimal content change, such as revising one line of narration, may require regenerating an entire segment. Cost therefore scales with the number of content iterations rather than with the final deliverable.

2. Consistency maintenance. Character faces may drift between shots, appearances may break continuity, and costumes may change unexpectedly. These issues require manual review, local regeneration, and reassembly. This work is difficult to automate and represents a hidden labor cost.

A different technical path is possible: if the animation is rendered by deterministic code, identical input produces identical output. Character proportions become mathematical constants, narration lines become data fields, and rendering becomes a repeatable pipeline. This is the foundation of the proposed approach: decouple creative decisions from rendering execution.

2. Why Code Rendering Is a More Stable Solution

The key difference among three animation production methods is the source of determinism.

Dimension	Generative video models	Template-based video tools	Code-driven rendering
Output determinism	Probabilistic; requires multiple sampling	Deterministic but limited in expressiveness	Deterministic and programmable
Cost per content change	High; often requires regenerating the whole segment	Medium; usually replaces assets	Very low; usually changes configuration
Resolution/frame rate adjustment	Limited by model tier	Limited by template tier	Arbitrary; determined at render time
Versionability	Weak; prompts are hard to reproduce	Medium	Strong; code itself is versioned
Suitable visuals	Photorealistic scenes, complex physics, real materials	Text cards and graphic layouts	Vector characters, explanatory animation, diagrams

Stickman explainer animation falls squarely within the strengths of code rendering. It is essentially a problem of vector graphics plus keyframe interpolation. It does not require probabilistic generation to approximate fur, cloth, subsurface scattering, or other complex physical materials. Using a generative video model for this task applies a high-cost tool to a problem that classical computer graphics already covers well.

3. Prerequisites

Any workflow that exports a final video must clearly state the local runtimes it depends on. Otherwise, it may fail on another machine. The following dependencies should be pinned and their versions recorded:

• JavaScript runtime: used to execute export scripts and coordinate rendering and encoding steps.
• Open-source video encoding command-line tool: combines rendered frames into an MP4 at the specified frame rate.
• Mainstream Chromium-based browser: loads the animation page in headless mode and captures frame-by-frame screenshots, ensuring the rendered result matches manual preview.
• File-system working directory: preferably a single project directory containing all artifacts for easy migration.

The simplest readiness check is to print the version information of all three tools in a terminal. If all return output, the environment is ready for the next step. This step may seem trivial, but it determines whether subsequent scripts can run without manual intervention.

4. Baseline Failure: Writing Without a Capability Package

Before building a standardized pipeline, it is useful to run a control experiment that exposes common failure modes.

Give an AI coding tool a minimal task: create a single-page, 15-second, 16:9 landscape explainer animation web page with three shots. The topic is arbitrary, with no extra decoration. Do not provide any rig constraints, export scripts, or file-structure conventions.

A typical result looks like this:

• Visual elements may appear, including cards, titles, and progress indicators.
• Stickman head-to-body proportions are often awkward. A common issue is that the head radius is set to one-third of the body height or larger, making the figure look like a child’s doodle.
• Limb joint angles are often set by intuition. The shoulder, elbow, and wrist do not form natural angles, and visible polyline jumps occur when actions switch.
• Animation logic, styles, and DOM structure are all inlined into a single HTML file, making it impossible to change motion without also changing layout.
• Generation time may not be short. Producing a messy single-file page of more than ten thousand bytes consumes a similar token amount to producing a cleanly structured modular project.

The root cause is not insufficient model capability. It is the lack of a reusable constraint artifact. Each output forces the model to guess what a stickman should look like, even though the answer should be a constant rather than a sample.

5. Turning Specifications into a Reusable Skill

The real solution is to have the AI coding assistant load a deterministic specification file before each task. This mechanism has been adopted by multiple platforms as an open-standard-style capability package. Its core form is simple: a directory at an agreed path contains a Markdown specification, plus optional scripts, templates, and other resources. When the tool executes a task, it detects the capability package directory in the current workspace. If a matching capability is found, it injects the specification into the context and constrains subsequent generation behavior.

5.1 Recommended Directory Structure

.claude/skills/stickman-animator/
├── SKILL.md              # Specification: skeleton baseline, motion rules, rendering conventions
├── scripts/
│   ├── rig.js            # Skeleton definitions and forward kinematics solver
│   ├── render.mjs        # Headless rendering, frame capture, and encoding
│   └── validate.mjs      # Output validation: resolution, frame count, duration
├── templates/
│   └── scene.html        # Scene page skeleton
└── examples/
    └── demo.json         # Sample storyboard data

5.2 Skeleton Baseline: Expressing Proportions as Mathematics

The value of a specification is that it turns aesthetic judgment into verifiable numbers. With body height normalized to 1.0, the following baseline can be used directly:

// rig.js — Skeleton baseline (total height normalized to 1)
export const RIG = {
  totalHeight: 1.0,
  headRadius:  1 / 7.5,   // Head height is about 1/7.5 of total height, close to real human proportions
  neckY:       1 - 2 / 7.5,
  shoulderY:   0.82,
  hipY:        0.52,
  kneeY:       0.28,
  ankleY:      0.04,
  shoulderW:   0.11,      // Half shoulder width
  hipW:        0.07,
  upperArm:    0.17,
  foreArm:     0.16,
  thigh:       0.24,
  shin:        0.24,
  lineWidth:   0.012,     // Line width is normalized as well so it does not distort when scaled
  strokeCap:   'round',
};
// Joint angle limits: poses outside these ranges are considered invalid and are rejected before rendering
export const JOINT_LIMITS = {
  elbow: { min: 5,  max: 175 },   // Elbows do not bend backward
  knee:  { min: 5,  max: 170 },
  neck:  { min: -40, max: 40 },
};

Three points are essential. First, the head-to-body ratio must be a constant. This is the key to character consistency. Second, joints must have limits. Without them, interpolation can produce unnatural reverse-joint poses. Third, line width must participate in normalization. Otherwise, lines may look too thin or unbalanced when the canvas is enlarged.

5.3 Motion Rules: Keyframes and Easing

// Each action is described by angle keyframes plus an easing function, decoupling the timeline from the canvas
export const EASING = {
  linear: t => t,
  easeOut: t => 1 - Math.pow(1 - t, 3),
  easeInOut: t => t < 0.5 ? 4*t*t*t : 1 - Math.pow(-2*t + 2, 3) / 2,
};
export function samplePose(track, t) {
  const { keys, ease = 'easeInOut' } = track;   // keys: [{ t, angles }]
  const f = EASING[ease] ?? EASING.easeInOut;
  const i = keys.findIndex(k => k.t > t);
  const a = keys[Math.max(i - 1, 0)], b = keys[Math.max(i, 0)];
  const p = f((t - a.t) / Math.max(b.t - a.t, 1e-6));
  const out = {};
  for (const joint in b.angles) {
    out[joint] = a.angles[joint] + (b.angles[joint] - a.angles[joint]) * p;
  }
  return out;
}

The key design point is that motion data is completely separated from rendering code. Adding a new action, such as a waving greeting, only requires adding a trajectory to the data file. No drawing logic needs to change. In this model, the AI coding assistant’s task shifts from “write an animation” to “write a configuration that conforms to a schema,” greatly reducing the failure surface.

5.4 Writing SKILL.md

The specification file is not a README. It is context for execution by a machine. An effective structure includes:

1. Trigger conditions: what tasks should load this capability, such as keywords or file types.
2. Hard constraints: required constants and module paths; inline styles and hard-coded coordinates are prohibited.
3. Output contract: artifact directory, naming rules, and required metadata fields.
4. Validation steps: scripts that must run after generation and their pass thresholds.
5. Counterexample list: explicitly list unacceptable patterns, such as a head-to-body ratio greater than 1:5 or a single file mixing logic and styles.

6. Export Pipeline: From Web Page to 60 fps Video

The browser draws the animation. The command-line tool encodes it. The two are decoupled through the file system. The core idea is to drive the canvas with a deterministic time function so that any frame can be reproduced independently and precisely:

// render.mjs core logic (illustrative)
import { chromium } from 'playwright';
import { execFileSync } from 'node:child_process';
const FPS = 60, DURATION = 15, W = 1920, H = 1080;
const page = await (await chromium.launch()).newPage({ viewport: { width: W, height: H } });
await page.goto('file:///project/scene.html');
const total = FPS * DURATION;
for (let i = 0; i < total; i++) {
  // Key: derive time from the frame number rather than relying on requestAnimationFrame
  await page.evaluate(t => window.renderFrame(t), i / FPS);
  await page.screenshot({ path: `frames/${String(i).padStart(5, '0')}.png` });
}
execFileSync('ffmpeg', [
  '-y', '-framerate', String(FPS),
  '-i', 'frames/%05d.png',
  '-c:v', 'libx264', '-pix_fmt', 'yuv420p', '-crf', '18',
  'out.mp4',
]);

Three engineering details are critical:

• Do not rely on requestAnimationFrame for timing. Frame callback frequency in headless environments is not controllable and can make the final video stutter. Provide a pure function interface such as renderFrame(t), where the image depends only on the time parameter.
• Clear the screenshot directory before each run. Leftover frames will be included by the encoder and can corrupt duration.
• Fix the encoding parameters. Frame rate, pixel format, and CRF should be recorded in the specification so that artifacts from different batches have consistent specifications and are easier to upload and transcode.

A 15-second, 60 fps, 1920×1080 video requires 900 frames. Single-frame rendering is on the millisecond scale, and the entire export usually completes within minutes. It can also be rerun as many times as needed without consuming model quota.

7. Content Iteration: Zero Regeneration for Narration Changes

This is the biggest structural advantage over generative models. The narration script is reduced to pure data:

{
  "meta": { "fps": 60, "width": 1920, "height": 1080, "duration": 15 },
  "scenes": [
    { "id": 1, "start": 0.0, "text": "Topic selection relies on guesswork", "pose": "thinking", "camera": "medium" },
    { "id": 2, "start": 5.0, "text": "Assets are repeatedly reshot", "pose": "walk",     "camera": "wide" },
    { "id": 3, "start": 10.0, "text": "Editing is rushed overnight", "pose": "type",     "camera": "close" }
  ]
}

When changing one line of narration, only the corresponding text field needs to be modified before rerunning the render script. Skeleton, proportions, and camera language remain unchanged because they are constants, not sampling results. The model does not participate in rendering. It only generates or modifies the JSON. Per-interaction token consumption drops from “generate a complete page” to “modify a few fields.” This is the direct source of cost reduction.

If voiceover is needed, text-to-speech can be added on top of this structure. Audio clips are generated according to the start and end times of each scene and then merged as the audio track during encoding. No visual regeneration is required.

8. Cost Model: From Per-Second Billing to Per-Token Billing

The structural difference between the two billing methods is worth calculating clearly. Let:

C_code  = (N_in × p_in) + (N_out × p_out)        # LLM token billing
C_video = T_seconds × N_attempts × p_second      # Generative video billing by second

Definitions: N_in and N_out are the input and output token amounts per interaction; p_in and p_out are the corresponding unit prices; T_seconds is video duration; N_attempts is the number of generations needed to reach an acceptable result; p_second is the per-second generation price.

Two conclusions follow directly:

1. C_video scales with the number of iterations, while C_code is nearly independent of it. Building the specification initially requires a one-time investment on the order of thousands to tens of thousands of tokens. After that, each content change consumes only a small number of tokens for configuration edits. The more frequently content is iterated, the larger the gap between the two curves.
2. Frame rate and resolution do not affect C_code. Rendering cost is borne by local CPU, and the marginal cost of local rendering approaches zero. In generative solutions, quality tiers often map directly to price.

Therefore, the key metric for judging whether this approach is economical is not the price of a single finished video, but the number of iterations per unit of content. The benefits are most obvious in batch production, frequent revisions, and parallel multilingual versions. If only a few one-off videos are produced each year with no revisions, the benefit is limited.

9. Engineering for Long-Term Stability

Writing the specification once is only the starting point. Sustained usability requires supporting mechanisms:

• Version everything. Put the capability package directory under version control. Layer artifact directories by date/task_id so that any finished video can be traced back to the specification version and storyboard data used at that time.
• Establish quality gates. After rendering, automatically validate resolution, total frame count, and duration deviation. If any item fails, the artifact is considered invalid and does not enter manual review.
• Maintain a regression sample set. Keep 3–5 typical storyboards as fixed test inputs. After every specification change, rerun all of them and compare keyframes to prevent fixing one action while breaking another.
• Externalize batch tasks. When generating dozens or hundreds of videos at once, hand rendering tasks to a containerized platform for elastic scaling. Write artifacts to object storage, and send execution logs and failure-retry records to logging and monitoring services. General capabilities such as container services, object storage, logging, and monitoring from Baidu AI Cloud can support this type of batch offline rendering workload, allowing local machines to focus on specification maintenance and result sampling.
• Keep a human review slot. Code rendering solves consistency, not copywriting or pacing. The automation boundary should stop at generating reviewable candidates, not direct publishing.

10. Capability Boundaries

It is necessary to state where this approach does not apply. Otherwise, expectations may be misjudged:

• Photorealistic characters and real materials are out of scope. Fur, fabric, skin scattering, and complex lighting remain areas where generative models have advantages.
• Complex physics and fluid simulation require specialized engines. Handwritten keyframes cannot cover them.
• Organic hand-drawn expressiveness is difficult to achieve purely in code and may require art assets.
• Consistency comes from determinism, not intelligence. A character does not improve because it “performs more convincingly.” The expressiveness ceiling is determined by the joint degrees of freedom and action library defined in the specification. To improve expressiveness, expand the action library and increase intermediate-frame density rather than switching models.

11. Implementation Checklist

1. Confirm that the runtime, encoder, and headless browser dependencies are available, and record their versions.
2. First run an unconstrained control experiment and keep the failed sample as a counterexample for specification design.
3. Write the capability package specification: skeleton baseline table, joint limits, easing functions, output contract, and counterexample list.
4. Implement three scripts: skeleton solving, frame-by-frame rendering and encoding, and artifact validation.
5. Convert narration copy into storyboard JSON and verify the iteration loop of “change data only, without regeneration.”
6. Integrate batch tasks and logging/monitoring, and lock in quality gates.
7. Estimate local economics by comparing “expected iterations per unit content × per-turn token cost” with “video duration × generation attempts × per-second price,” and confirm economic viability before scaling production.

The transferable value of this approach is more important than the stickman topic itself. Any expressive form whose visuals can be reproduced by deterministic code and whose content requires frequent iteration—diagrams, data visualizations, flow schematics, and 2D character animation—can use the same structure: specification package + data-driven content + headless rendering export. This shifts content production cost from being tied to the number of iterations to being tied to the initial investment.