Game Animation for People Who Cannot Animate
Which animations to build, how long each one runs, and the three properties you can judge without any craft knowledge at all.
You have a character on screen and it slides. Not because the code is wrong, but because nobody decided what the character does when the player lets go of the stick. You cannot animate, you will not learn before this build ships, and what stands between you and a finished-looking game is a list of decisions, not a skill.
Those decisions are separable from the drawing. Somebody produces the frames. Somebody else decides which animations exist, how long each runs, and whether the batch is acceptable. The second job is yours, and it can be learned in an afternoon.
This article is that second job. It will not teach you to draw a walk cycle.
The short version. Animation quality in a small 2D game is decided by three things you control without drawing anything: which animations exist, how long each runs, and whether the character stays anchored to the same ground point across all of them. Drawing skill is the fourth factor and it matters least, because idle and walk carry most of the felt quality and everyone underfunds them. Judge every animation that comes back on three tests: does it loop cleanly, does it stay anchored, does it read at play size.
Specifying animation and producing it are different jobs
Producing animation means understanding arcs, weight, anticipation and follow-through, and it takes years. Specifying and judging it means knowing what the set contains, how long each item runs, and what a defect looks like on arrival. That is a short list of rules and three tests.
It is the division the programmer's overview of game art draws between producing art and judging it, and animation is where the split is widest. A character that pops one pixel up on every transition looks broken to a player who could not say why. A walk cycle with slightly wrong hip rotation looks fine to everyone except an animator. Only the first is on your critical path.
The animation set, ordered by what it carries
Most people build the set in the order they find exciting: attack, then death, then a second attack, and by week six the character is still rigid when the player stops moving. Here is the order that matches how much felt quality each cycle carries.
- Idle. Plays whenever the player is reading, deciding, in a menu, or not touching anything. A rigid idle makes every other animation look worse by association.
- Walk or run. Whichever is primary locomotion. If the player moves at one speed, you need one, not both.
- Attack, or the primary verb. In a non-combat game, whatever the player does most: serving a customer, casting, planting.
- Hit reaction. Short. Communicating that damage registered matters more than how it looks.
- Jump. Usually three states rather than one: rise, fall, land.
- Death. Plays once per failure, then never again that run.
- Everything after this. Second attacks, emotes, celebrations, climbing. Real value, none of it load-bearing.
The second locomotion direction is the usual omission. With a top-down camera, walking north is a different sheet from walking south, and a set with one and not the other is unusable rather than half done. Mira Hearthkeeper, in Wayfarer's Hearth, ships three walk sheets for that reason.
Screen time is the budget, and the arithmetic is lopsided
That ordering is not taste. It falls out of arithmetic. Take a one hour session: twenty minutes moving, twenty standing still while reading or talking, twenty in combat. Idle gets 1,200 seconds of screen time. Walk gets 1,200. Now say the player dies ten times and death runs one second. Death gets 10 seconds. That is 120 to 1.
Now the cost side. A set of idle, walk, run, jump, attack, hit and death at typical frame counts comes to about 47 frames. If idle sits at 4 frames inside that total and death at 8, death costs twice what idle costs and returns under one percent of the screen time. Spreading effort evenly routes most of the budget to animations players glimpse. A mediocre death costs you almost nothing. A rigid idle costs you the whole character.
The three properties you can judge without craft knowledge
These three checks take five minutes per character and catch the defects that make a game look broken.
Does it loop cleanly. Play the cycle on repeat and watch one single point: the front foot, the belt buckle, the tip of a weapon. Watching the whole figure averages out the hitch. A bad loop shows as a stutter at the same instant every cycle. Then flip the last frame against the first: that pair should change by about as much as any other adjacent pair. Larger means the loop jumps; zero means a duplicated frame, which reads as a hesitation.
Does the character stay anchored. Put the character on a flat floor, draw a one pixel line at the contact point, and cycle through every animation with a key press without moving the node. Nothing should rise, sink or slide except where the animation is meant to move it. Almost nobody runs this check. It is the defect players feel most.
Does it read at play size. Scale to the size the character occupies in the real game, run at the final frame rate, sit back to normal viewing distance, and have somebody who has not seen the sheet name the action out loud. If they cannot separate attack from hit reaction, the poses are too similar, and interior detail will not save them.
Does it loop cleanly
Play the cycle on repeat and watch one point: the front foot, the belt buckle, the tip of a weapon. Then flip the last frame against the first. That pair should change by about as much as any other adjacent pair.
Does the character stay anchored
Draw a one pixel line at the contact point, then cycle through every animation with a key press without moving the node. Nothing should rise, sink or slide except where the animation is meant to move it.
Does it read at play size
Scale to the size the character occupies in the real game, run at the final frame rate, sit back to normal viewing distance, and have somebody who has not seen the sheet name the action out loud.
Frame count is a decision, not a skill
Frame count is a two-variable calculation you do before anyone draws anything: duration in seconds times frames per second. Decide duration first, because duration is a design decision about how the game feels and frame count is only its consequence.
An idle breath cycle of about two seconds reads as calm; under one second reads as agitated. A footfall is a full step, and you can time your own by walking across the room. An attack resolves inside the window your combat code already gives it, so that duration is read off your code, not invented.
Then pick a frame rate and multiply. Fewer frames at a lower rate is a style choice, not a compromise. Mixing rates without noticing is not: an idle at one apparent rate and a walk at another reads as an error even to people who cannot name it. For scale, that seven-animation set lands near 47 frames per character at minimum viable counts. A studio bake often runs higher where the animation earns it: Mira's idle sheet holds 18 frames while each of her walks holds 13. A plan several times that size specifies fidelity your game will never display.
The first and last frame matter more than the middle
In a looping animation the middle frames are a sequence somebody drew in order. The seam between the last frame and the first is two frames drawn at opposite ends of the job, and it is the only place the cycle can break.
So review the seam first. A clean seam with a weak middle frame reads as a slightly soft animation. A broken seam reads as broken no matter how good the middle is. The seam also tells you what to ask for: "frame 9 does not match frame 1, please close the loop" is a cheap one-frame request, while "the walk feels floaty" is a rewrite.
Death is the documented exception. It does not loop. It runs once and holds on its final frame, often as long as the failure screen lasts. That inverts the rule: the last frame gets minutes of screen time, everything before it hundredths of a second. Specify death as a pose plus a path to it, and put your attention on the pose. The same holds for any one-shot that ends held.
Anchoring is the failure that survives every other check
Every animation can loop cleanly, read at play size, and still produce a character that twitches on every state change. The cause is almost always a ground line that is not in the same place on every sheet.
Here is a set with the problem solved. Mira Hearthkeeper ships six baked sheets: three walks, an idle, a celebrate and a serve. The cell height is 260 on all six. The cell width is not: it runs from 119 on the idle to 221 on the celebrate, because lateral reach varies by action and height does not. Height locked, width floating. The cast's canvases follow the same pattern at 295 to 311 px wide and 560 px tall.
Locking the height is necessary but not sufficient. The number holding the character still is the gap between the bottom of the drawn art and the bottom of the cell. Across all six sheets that gap runs between 2 and 7 px. Five pixels of variation inside a 260 px cell is under two percent of the character's height. It reads as nothing.
Let one sheet drift well outside that band and the character sinks into the floor or floats above it the instant it enters that animation, then snaps back on exit. The drift is tied to state changes, so it fires when the player is watching: the first frame of an attack, the landing, the moment they stop walking. Players report this as the controls feeling unreliable.
So put the gap in the spec as a number with a tolerance, next to cell dimensions and frame counts, the way the sheet spec handles padding and layout. Measure it on delivery: a four pixel drift is invisible in a still and obvious in motion. When a set is baked as a collection, as Makko does, the locked height and consistent gap belong to the whole set rather than being reconciled sheet by sheet.
One related trap: three of the six sheets carry empty trailing slots, because a grid has to be a rectangle and an animation does not. Idle is 18 frames in 20 slots, each walk 13 in 16. State the frame count separately, or the character vanishes for a beat every cycle.
The order of operations for getting a character animated
Copy this and fill it in per character. Steps 1 to 5 happen before anyone draws a frame.
# [CHARACTER] - animation order of operations
1. LIST THE STATES YOUR CODE ALREADY HAS
From the state machine, not the design doc.
2. CUT TO WHAT SHIPS
idle, locomotion, primary verb, hit, death,
plus one per direction the camera demands.
3. SET DURATION PER ANIMATION, IN SECONDS
idle [ s ] locomotion [ s ] verb [ s ]
hit [ s ] death [ s ] land [ s ]
4. SET FRAME RATE, MULTIPLY OUT FRAME COUNTS
fps = [ ] frames = duration x fps
Check: whole set near 47 frames.
5. LOCK THE CELL CONTRACT
cell height = [ ] px, same on every sheet
cell width = per sheet, set by lateral reach
art-to-bottom = [ ] px, tolerance +/- [ ] px
frame count = per sheet, separate from slots
6. ORDER BY SCREEN TIME. IDLE FIRST, NOT THE ATTACK.
7. ON DELIVERY, TEST EACH ANIMATION
loop seam / anchor line / play size
8. MEASURE THE BOTTOM GAP ACROSS THE SET
One number per sheet. Reject drift.
9. INTEGRATE ONE AT A TIME, BUILD STAYS RUNNING
Step 8 carries the emphasis. The tempting fix for a drifting sheet is a per-animation Y offset in the engine. Do not. Offsets accumulate and get copied to the next character, and six months later nobody knows which numbers are real. Push the correction into the art. The same rule governs swapping placeholder art for real art: the contract lives in the asset, not in compensating code.
What you genuinely cannot judge without an animator
Everything above is learnable in an afternoon. Some things are not.
You cannot reliably judge weight: whether a heavy character reads as heavy, whether a swing carries force. That comes from spacing relationships you will not perceive as separable causes, so you will feel something is off and not be able to say what. You cannot judge arcs, whether limbs travel curved paths rather than straight ones. You cannot judge appeal, where a walk expresses who the character is rather than merely moving them. And you cannot judge cost: an animator knows instantly whether a fix is one frame or a redraw.
The three structural tests get you a character that reads as professional and never looks broken. An animator gets you one with personality. If you cannot buy both, produce the first with your own labor and spend on the second only for your highest screen time character. The decision tree for sourcing art applies unchanged.
Frequently asked questions
How many animations does my first game really need?
Count the states in your character's state machine. That number is usually smaller than the design document implies: idle, one locomotion cycle per direction the camera demands, one primary verb, a hit reaction and a death.
Is it better to have fewer frames or fewer animations?
Fewer frames, almost always. A twelve frame walk and a six frame walk both communicate walking. A game with a walk and no idle communicates that something is broken. Cut depth before coverage, from the bottom of the screen-time list up.
My character slides during the walk cycle. Is that an art problem?
Usually not. Sliding means the distance the feet travel per frame does not match the distance your code moves the character. Measure how far a foot travels across one cycle, divide by the cycle duration, and set movement speed to that. If speed is already tuned for feel, specify the cycle duration to match it instead.
Can I mix animation from different sources on one character?
Only if the cell contract matches: identical cell height, the same art-to-bottom gap within a few pixels, the same apparent frame rate. Drawing style differences are the smaller problem.
Should I animate before or after the game is fun?
After, with one exception. Placeholder rectangles tune everything except the timing of the primary verb, because an attack that feels right against a rectangle can feel wrong once real frames sit in front of the hit. Get one real attack in early and leave the rest until the design stops moving.