Character Rigging and Animation for Mobile Games
The artist submitted final character artwork. PSD layers are neatly organized: torso, head, left arm, right arm, legs. Open Spine 2D — and real work begins: correctly position bone hierarchy so that blend between run and attack doesn't invert shoulders, and mesh deformation on clothing doesn't create artifacts at boundary pixels.
Bone Hierarchy and Common Mistakes
Rigging novices create flat hierarchy: all bones from root. Result — rotating hips doesn't drag legs, animator must animate each bone separately. Correct chain: root → pelvis → spine → chest → shoulder_l → arm_l → forearm_l → hand_l. Then rotating chest pulls everything above, and animator controls pose through few key bones, not twenty.
Weights painting — where weeks disappear. For mobile characters max 2–3 influences per vertex (in Spine: Max Bones Per Vertex in mesh settings). More causes GPU skinning on mobile to tank. On Mali-G57 difference between 2 and 4 influences with 10 characters on screen — about 3ms per frame. Small, but at 30 FPS budget is 33ms, and they add up.
IK vs FK — fundamental choice per limb. Character legs walking on flat surface — FK, simpler and predictable. Character legs adapting to uneven terrain — IK via IK Constraint in Spine with Bend Direction as needed. Attack arms — FK (arc control needed). Arm gripping surface — IK.
Spine 2D Workflow
Spine 4.x is the primary tool for complex characters. Workflow:
Break PSD into separate PNGs via Photoshop script or Aseprite, place in folder. In Spine create skeleton, import images as slots. Position bones strictly by hierarchy, starting with root at character center of mass.
Create mesh only where deformation is needed: clothing, hair, capes. Rigid elements (sword, shield, metal details) — no mesh, just attachment. Fewer vertices in mesh — less GPU work.
AnimationState in Spine Runtime allows animation mixing via tracks: track 0 — base body animation (idle/run/jump), track 1 — arm animation (attack/block/reload). Mix Duration 0.15–0.2 seconds for smooth transition without popping.
PathConstraint — excellent for tails, ropes, braids. Create path (path attachment) along needed curve, bind bones to it. Only animate path points, not each bone. Saves significant time on 10–12 bone tails.
Atlas Optimization and Runtime
After animation finalization, pack textures via Spine's Atlas Packager. Rules:
- Max atlas size — 2048×2048, better 1024×1024 for mid-range
-
Bleedenabled — removes sprite boundary artifacts - Format: PNG → convert to ASTC/ETC2 on Unity import
In Unity use SkeletonAnimation component from Spine Unity Runtime. AnimationState.SetAnimation for animation switching, AddAnimation for queuing. UpdateTiming = InUpdate — standard, don't change without reason.
Object pooling is mandatory: don't Instantiate enemies each time, reuse via SkeletonAnimation.ClearState() + Initialize(true) on pool return.
Unity 2D Animation as Alternative
For simple characters with 5–8 bones — Unity 2D Animation Package (com.unity.2d.animation) is sufficient. PSD Importer reads Photoshop files directly, layers become sprites, Sprite Skin adds deformation.
Animate via standard Unity Animator. Blend Tree for run/walk/sprint by speed. Animation Rigging package — if runtime IK for legs is needed.
Approach advantages: no external runtime, fewer dependencies, standard Unity tools. Disadvantages: mesh deformation weaker than Spine, no powerful track-based mixing.
Stages and Timeline
Work starts with technical specification: list of states per character, IK requirements, target devices, draw call constraints. Without this spec → rigging → review with game designer → basic state animation → engine integration → profiling → final polish.
Simple character (10 bones, 5–7 animations): from one week. Complex hero unit with 20+ animations, IK, attachment swapping, full VFX suite: up to three months. Cost calculated individually after analyzing character list and animation tree requirements.