Animation is where a browser game either feels alive or feels like a slideshow, and it is also where a surprising share of your frame budget goes. There are four fundamental techniques, and choosing between them is less an art decision than a budget decision about file size, CPU time, and how much motion you are willing to author by hand.
Frame by Frame Buys Fidelity With File Size
You draw every frame, pack them into a sprite sheet, and flip through them at a fixed rate. What you drew is exactly what ships, with no rig limitations and no interpolation artifacts, which is why 2D pixel art games still default to it and why the tooling is so mature.
The cost is bytes. A 12 frame walk cycle at 128 by 128 is 12 separate images. A character with 8 animation states at 8 to 12 frames each needs 64 to 96 individual frames, and that is one character. Every extra frame of smoothness is paid for on the network, on the first load, on the slowest connection you support.
Skeletal Animation Trades Bytes for CPU
Instead of storing complete images, you store a hierarchy of bones with positions and rotations at keyframes and interpolate between them at runtime. One set of character art plus compact bone data replaces the entire sprite sheet, so file size drops hard and you gain the ability to retarget the same animation onto a different character.
You pay for it per frame instead. Every bone is transform math on the CPU, every skinned vertex is more work on top, and a crowd of rigged characters on a mid range Android phone is exactly where a 60fps target quietly becomes 40. The tradeoff is not better or worse, it is download time against frame time, and which one hurts more depends entirely on your audience.
Tweening Handles Everything That Is Not a Character
Menus sliding in, a health bar draining, a score counting up, a screen fading, a camera easing toward a target. None of that needs frames or bones. It needs a start value, an end value, a duration, and an easing curve, and the whole thing costs a few floats per update.
Easing is the part people skip and it is most of the perceived quality. Linear motion reads as mechanical because nothing in the physical world starts and stops instantly. Swapping linear for a cubic ease costs nothing and is the single cheapest upgrade available to a web game.
Procedural Motion Reacts to Things You Did Not Author
Physics driven ragdolls, cloth, weapon recoil, camera shake, and inverse kinematics that plant a foot on uneven ground all generate motion at runtime from math rather than from authored keyframes. The payoff is that the animation responds correctly to situations nobody anticipated, which is impossible to reach by drawing more frames.
The cost is control. Procedural systems fail in ways an artist cannot fix by redrawing, so they get tuned rather than authored, and a bad tune produces motion that is technically correct and deeply wrong to look at. Budget debugging time for them the way you would for any other simulation.
Picking the Mix
Almost no game picks one. A typical web game runs skeletal characters, tweened UI, a procedural camera with physics reactions, and hand drawn frames for the handful of moments that have to look exactly right. State machines sit on top and decide which animation plays when, and most of the bugs players notice live there rather than in the animation itself.
The useful question is never which technique is best. It is which one you can afford on the slowest device you intend to support, because that device decides your frame budget and your frame budget decides everything else. A fuller breakdown of the four approaches, state machines, and the performance math behind them is in this guide to game animation for web games.
Top comments (0)