Local Code-Generated Stick Figure Animation: From Random Drawing to a Reusable Workflow
This guide explains how to build a reusable local workflow for generating stick figure animations with code. It covers goal setting, skeleton modeling, animation and content separation, project specifications, browser preview, video export, cost evaluation, and further engineering improvements. The focus is on creating a stable system that supports repeatable editing instead of generating a new animation page from scratch each time.
Building a Reusable Local Workflow for Stick Figure Animation
Stick figure animation is well suited to narrated short-form videos because it is inexpensive to produce, visually direct, and easy to keep stylistically consistent. Compared with frame-by-frame illustration or complex 3D production, a browser-and-script workflow makes it easier to validate ideas quickly. Characters can be built from circles, lines, and simple geometric shapes. Their movements are created by changing joint coordinates over time, and the resulting browser output can then be recorded as a video.
However, asking an AI coding tool to generate an animation page does not automatically produce a stable result. Without a clearly defined skeleton structure, motion conventions, and export process, common problems include inconsistent character proportions, disconnected joints, skipped frames, mixed page logic, and the need to regenerate every scene after changing the script.
The reusable asset is therefore not a single webpage, but a constrained, extensible, and repeatable animation workflow.
1. Define the Goal and Technical Boundaries
The goal is not to create complex cinematic animation. Instead, the objective is to build a lightweight workflow for landscape short-form videos with the following capabilities:
- Generate a narrated animation lasting approximately 15 seconds;
- Use a consistent stick figure character;
- Divide the content into approximately three scenes;
- Provide real-time previewing in a local browser;
- Support changes to dialogue, subtitles, and scene content;
- Use an existing local browser and media encoding tools to export video;
- Avoid regenerating all assets after every small change.
The main advantage of this approach is that the visual elements are controlled by code rather than by one-time static assets. Character movement, subtitle placement, scene duration, and background layout can all be adjusted through parameters.
Before starting, make sure the local environment includes:
- A local runtime capable of executing JavaScript or another scripting language;
- A modern browser that can open local webpages;
- A local media tool for encoding browser output as video;
- A dedicated project directory;
- Enough disk space and reliable file read/write permissions.
It is recommended to place the project in a short path without special characters. This helps avoid escaping and permission problems when scripts access project files.
2. Run an Unconstrained Generation Test First
To understand the problems caused by a lack of specifications, first ask an AI coding tool to generate a simple single-page animation. The prompt should include the working directory, video topic, aspect ratio, number of scenes, and output filename, but should not provide a skeleton library or motion templates in advance.
For example:
Please check whether the current working directory contains any specificationfiles related to stick figure animation.Only inspect the current directory. Do not scan other locations.If no such files exist, create a landscape single-page animation,approximately 15 seconds long, about the content, filming, and editingpressures faced by a one-person team producing short videos.Divide the animation into three scenes, use code to draw the characters,and explain the generated result.
The purpose of this stage is not to produce the final work. It is to create a comparison sample. Without structural constraints, the following problems commonly appear:
- The head, torso, and limbs do not follow consistent proportions;
- The left and right arms have different lengths or incorrect connection points;
- The same character changes height between scenes;
- Motion is implemented through many independent hard-coded coordinates;
- Page structure, animation logic, and subtitle content are all placed in one file;
- Adding a new scene can easily break existing code.
This demonstrates that a large language model can quickly produce a page that appears to move, but it cannot reliably maintain long-term quality without explicit structural rules.
3. Represent the Character with a Stable Skeleton
The key to consistent characters is to replace “a set of arbitrary lines” with “a skeleton model based on fixed proportions.”
A simple stick figure can include the following nodes:
Head centerNeckLeft shoulder, right shoulderLeft elbow, right elbowLeft hand, right handHip centerLeft knee, right kneeLeft foot, right foot
These nodes are connected through bones. Instead of entering large numbers of coordinates for every scene, use relative coordinates and proportional parameters, such as:
Head radius = height × 0.08Torso length = height × 0.28Upper arm length = height × 0.16Forearm length = height × 0.15Thigh length = height × 0.22Lower leg length = height × 0.21
The project does not need to use these exact values. The important principle is that every scene shares the same calculation rules. When the character is standing, walking, waving, or typing, only the joint angles should change—not the bone lengths.
The character state can be represented as follows:
const pose = {root: { x: 0.5, y: 0.72 },headAngle: 0,leftShoulder: -0.35,rightShoulder: 0.35,leftElbow: -0.6,rightElbow: 0.6,leftKnee: 0.15,rightKnee: -0.15};
The renderer uses the character height, root position, and joint angles to calculate the actual coordinates of each endpoint. This makes it possible to move the character by changing only the root node, or to resize the character by changing only the scale parameter.
4. Separate the Animation Engine from the Content
The project should be divided into at least three layers.
1. Rendering Layer
The rendering layer is responsible only for drawing and should not contain story-specific content. It should handle:
- Drawing the head, torso, and limbs;
- Connecting joints;
- Character colors and line widths;
- Simple facial features;
- Objects, backgrounds, and scene elements.
2. Motion Layer
The motion layer calculates poses based on time. For example:
function wave(t) {return {leftShoulder: -0.8 + Math.sin(t * 5) * 0.15,leftElbow: -1.2 + Math.sin(t * 5 + 0.8) * 0.2};}
Motion functions should return pose objects instead of directly modifying page elements. This makes actions reusable across different scenes and allows them to loop cleanly.
3. Content Layer
The content layer should describe scenes and dialogue only, for example:
const scenes = [{start: 0,end: 5,title: "Finding Topics",subtitle: "Every day starts with finding something worth expressing"},{start: 5,end: 10,title: "Filming Is Complicated",subtitle: "Scripts, visuals, and audio require repeated coordination"},{start: 10,end: 15,title: "Editing Takes Time",subtitle: "Small revisions often take longer than expected"}];
With this layered design, changing the script does not affect skeleton calculations. Updating a subtitle also does not risk breaking the animation.
5. Use Skills or Project Specifications to Enforce Rules
To make an AI coding tool follow the same standards every time, create a dedicated specification file in the project directory. It should define at least:
- Default canvas aspect ratio;
- Target frame rate;
- Character skeleton proportions;
- Permitted motion types;
- Scene transition methods;
- Subtitle safe areas;
- File naming conventions;
- Pre-export checks;
- Core interfaces that must not be modified.
The character engine and video export script should also be saved as separate files. The character engine provides drawing and motion capabilities, while the export script launches the local webpage, captures frames at the specified frame rate, and encodes them into a video.
The specification should not simply say “generate a good-looking animation.” It should contain verifiable constraints, such as:
Every character must use the shared skeleton calculation function.Do not redefine character proportions inside an individual scene.Every scene must include a start time and an end time.Subtitles must not be placed close to the canvas edges.Before export, check the total duration, aspect ratio, and frame rate.
The more specific the constraints are, the more stable the generated result will be.
6. Browser Preview and Video Export
After completing the webpage, preview it in a local browser before exporting. Check the following points:
- Does the animation start correctly from the first frame?
- Does the character jump unexpectedly when scenes change?
- Do subtitles remain inside the safe area?
- Is the text still clear at different resolutions?
- Is there noticeable stuttering in the motion?
- Does the page depend on external network resources?
- Could missing audio or fonts cause layout changes?
Once the visuals are correct, run the local export script. The script can use a workflow based on browser playback, frame-by-frame capture, and media encoding instead of temporarily installing a large runtime environment. This reduces setup time and avoids export failures caused by network or permission issues.
The following parameters should remain fixed during export:
- Canvas width and height;
- Landscape or portrait aspect ratio;
- Frame rate;
- Total duration;
- Video encoding format;
- Whether audio is included;
- Output file path.
If only the dialogue changes, there is usually no need to rebuild the motion system. Replace the content-layer data and export the video again. This is one of the main advantages of code-based animation over one-time generated assets.
7. Evaluating Cost and Efficiency
The cost of this workflow should not be measured only by the price of the first generation. Modification time, waiting time, and manual rework also matter.
A simple estimate is:
Total cost = initial generation cost+ structural adjustment cost+ cost of multiple revisions+ export and review cost
If an animation relies entirely on random generation, every change may alter the character, scenes, and motion at the same time. The cost of later revisions can therefore grow quickly.
By contrast, once the skeleton library and motion engine are fixed, changing the script, adjusting scene duration, or replacing an action usually affects only a limited part of the project.
For this reason, investing time in specifications early is often more efficient than focusing only on the speed of the first generation. For accounts or teams producing content in batches, a unified character system also improves visual consistency, handoffs, and asset reuse.
8. Further Engineering Improvements
Once the basic workflow is stable, consider adding the following capabilities:
- Use a configuration file to manage scenes centrally;
- Add motion transitions to prevent abrupt pose changes;
- Add debug boundaries and time markers to each scene;
- Automatically check subtitle length and safe areas;
- Generate a low-resolution preview before export;
- Manage characters, backgrounds, and subtitles as separate layers;
- Create composable parameter templates for different actions;
- Save historical versions for rollback;
- Add retry handling and export logs.
The animation project can also be treated as a small compilation pipeline: content configuration is the input, skeleton calculation and rendering are the intermediate stages, and the final video is the output.
As long as the input structure remains stable, the same system can generate short videos on different topics in batches.
Conclusion
The core of local code-generated stick figure animation is not asking an AI tool to write a complex page in one attempt. It is building a production system that can be repeated, inspected, and modified.
Unconstrained generation is useful for quickly validating an idea, but it is not suitable for long-term maintenance. Once skeleton proportions, motion interfaces, scene configuration, and export scripts are standardized, problems such as character deformation, unstable motion, and expensive revisions become much easier to control.
For individuals and small teams that want to produce narrated animations at low cost, the most valuable investment is not decorative detail. It is the underlying architecture: a consistent character system, separated logic, explicit specifications, and a fixed export process.
After these foundations are in place, creating a new video no longer means rebuilding an animation page from scratch. It becomes a matter of arranging new content on top of the same reusable engine.
