Skip to content

Game-Ready

Purpose

Turns baked animation frames into engine-native, drop-in game assets: trimmed sprites, Unity AnimationClips, an AnimatorController, and a prefab a developer drags into a scene and it plays.

This is the supported "game-ready output" feature — framework-agnostic standard Unity assets that work in any project. It is the last mile that turns rendered frames into something usable directly in a game.

It builds one of two shapes, auto-detected from the selected folder:

  • Effect — a self-contained object (fire, explosion, pickup). One clip folder (or an Angle_### directional root) → one clip → one controller → one prefab. The directional variant gets a Direction-switching controller.
  • Character — one rig from many animations (idle/walk/run/jump). A parent folder whose subfolders are the animations (each flat, or its own Angle_### facings) → every clip wired into one AnimatorController and one prefab. Directional animations become a 2D blend tree on MoveX/MoveY.

The Character controller deliberately carries no transitions and no gameplay parameters beyond the MoveX/MoveY its blend trees need — the state-switching logic is the developer's to author. Game-Ready hands over a fully-wired rig, not a finished state machine.

Owns

  • Frame trimming to one uniform, tight crop with a consistent pivot (one shared crop across a whole Effect and across an entire Character — every animation and facing)
  • Sprite-keyframed AnimationClip generation
  • Effect output: AnimatorController + drop-in prefab (single and directional; directional = a clip per facing + a Direction-switching controller)
  • Character output: many animations → one AnimatorController (a state per animation; directional animations as MoveX/MoveY blend trees) + one prefab
  • The Game-Ready Exporter window (shape auto-detection) and menu entry points

Does NOT Own

  • The capture/bake pipeline (this consumes its exported frame folders)
  • The trim / pivot / clip-timing / angle MATH (that lives in the unit-tested Logic kernel)
  • Sprite-sheet / GIF assembly (the Export feature)
  • RuntimeKit (a separate, free, unsupported asset)

Allowed Dependencies

Game-Ready may depend on:

  • Logic — the pure, unit-tested kernels (OpaqueBounds, TrimPlan, PivotMath, SpriteAnimationPlan, AngleFolders)
  • Diagnostics (logging)
  • UI styling helpers (the themed window)
  • UnityEditor (AssetDatabase, AnimationUtility, AnimatorController, PrefabUtility, importers)

Notes

  • Reads {prefab}_Frame_###.png frame folders (glob *Frame_*.png). Shape is auto-detected, Character first: a multi-animation root is a Character — either angle-major (Angle_###/{Animation}/frames, SNAP's directional export) or animation-major ({Animation}/frames or {Animation}/Angle_###/frames). Character detection returns false for the Effect shapes, so a lone Angle_### directional root (frames directly in each angle) stays Effect directional and a single Frame_*.png clip stays Effect single. A token-aligned prefix common to every animation name (e.g. Baruk_Baruk_) is stripped so states read cleanly. The output GameReady/Trimmed subfolders are skipped during discovery so re-runs don't treat prior output as an animation.
  • One shared crop is the load-bearing invariant: an Effect shares it across every facing; a Character shares it across every frame of every animation and facing. Beyond stopping resize/jitter, this preserves the captured inter-animation vertical staging (a jump still reads as rising off the ground rather than being re-baselined to it).
  • Character directional animations use a 2D Simple-Directional blend tree; each facing sits at the unit vector of its capture yaw (0° = +X, counter-clockwise) — the geometric inverse of RuntimeKit's DirectionResolver, so feeding a movement vector into MoveX/MoveY selects the matching facing.
  • All load-bearing math stays in Logic and is unit-tested; this territory is the Unity I/O around it, validated by the manual asset matrix (eyes on real output). Unity 6.0+ APIs only — no legacy sprite-metadata fork.
  • Engine-native output is the supported product. The RuntimeKit one-click path was deliberately descoped (don't couple a paid feature to an unsupported kit).

Future Candidates

  • Flow fps from the export preset instead of the window field.
  • Optional auto-hook into the export pipeline (bake → game-ready in one step).
  • A "known ground pivot" path (PivotMath.Recompute) for precise per-frame pivots when the capture records the model's ground point.